PDPA for Websites in Singapore: Contact Forms, Cookies and Analytics

The PDPA applies to a business website as soon as the site collects personal data: names and contact details from a form, customer accounts and orders, and visitor data from analytics or ad tags when it can be tied to a person. In practice, that means telling people why you collect their details at the point of collection, using them only for that, asking separately for marketing, protecting and deleting what you hold, knowing where your third-party tags send data, publishing a contact for your data protection officer, and being ready to report a breach. Singapore has no cookie law of its own; PDPC guidance applies these general rules to cookies.

We build and maintain business websites in Singapore, and check existing sites through our website audit. This guide goes through the rules that matter on a website, with the PDPC page or section of the Act behind each one, worked examples and a free checklist. It is general information, not legal advice. Where the PDPC has not said something directly, we say it is our reading.

What does the PDPA require of a business website?

The PDPC groups the Act’s duties into a set of data protection obligations, summarised on its one-page overview of the obligations. Each one shows up somewhere on a typical business website.

Obligation	Where it is in the PDPA	What it means on a website
Notification	Section 20	Say what the details are for on or before collecting them: a line at each form, and your privacy policy
Consent	Sections 13 to 17	Collect and use data only with consent, deemed consent or an exception. Marketing needs its own opt-in.
Purpose limitation	Section 18	Use form data only for purposes a reasonable person would consider appropriate in the circumstances, and that you have told people about
Protection	Section 24	Reasonable security for form entries, accounts, uploads, backups and admin logins
Retention limitation	Section 25	Delete old enquiries, uploads and exports once you no longer need them
Transfer limitation	Section 26	Make sure tools that store data overseas (form tools, email platforms, analytics, ad tags) protect it to a comparable standard
Access and correction	Sections 21 and 22	Answer requests for a person’s data, and correct errors
Accountability	Sections 11 and 12	Name a data protection officer (DPO), publish their business contact, have policies and a complaints process
Data breach notification	Sections 26A to 26E	Assess a leak quickly and report it to the PDPC, and to affected people when required

What should a contact form say under the PDPA?

A contact form needs a short notice of purpose next to the submit button, and a separate, optional, unticked box if you also want to send marketing.

Section 20(1) of the PDPA requires you to tell people the purposes for collecting their data on or before collecting it. When someone fills in your form to ask a question, section 15(1) treats them as consenting to purposes that are objectively obvious from what they did, such as a reply. PDPC’s Key Concepts Guidelines give the example of a taxi booking: the number given to book a taxi can be used to say the taxi has arrived, but not to market a limousine service.

A notice for a fictional online homeware shop could read:

We will use your name, email and phone number to reply to your enquiry. See our privacy policy.

☐ Send me new arrivals and offers by email. (Optional, unticked)

Four rules decide how the form is built:

• Marketing is a separate choice. The Key Concepts Guidelines (chapter 12) say consent for direct marketing should be an opt-in, such as ticking an unchecked box, and that a pre-checked box is not appropriate.
• It cannot be a condition of the reply. Section 14(2)(a) says you must not require consent beyond what is reasonable to provide the product or service. In our reading, making the marketing box compulsory to send an enquiry runs into this.
• Check the Do Not Call Registry before texting or calling. For marketing calls, texts and faxes to Singapore numbers, including WhatsApp messages (the PDPC’s Advisory Guidelines on the DNC Provisions name data apps that use a Singapore number), the PDPC’s guide to the DNC provisions says to check the number within 21 days before sending, unless the person gave clear and unambiguous consent through a positive action, such as ticking a box that names the SMS messages. Messages whose sole purpose relates to an ongoing relationship, such as a membership or account, are outside these rules on any channel (PDPA Eighth Schedule, paragraph 1(1)(e)), but a one-off purchase is not an ongoing relationship.
• Ask only for what you need to reply. Every extra field is more to protect and more to delete later. If a phone number is not needed, make it optional.

If the form also feeds an advertising platform, for example through enhanced conversions or Meta’s advanced matching (see below), say so in the privacy policy. The Key Concepts Guidelines (chapter 14) suggest highlighting purposes that a person would not expect from the context.

Does Singapore need a cookie banner under the PDPA?

The PDPA does not require one by name, and it has no cookie-specific rule. The PDPC explains how the general rules apply to cookies in chapter 7 of its Advisory Guidelines on the PDPA for Selected Topics (revised May 2024):

• Cookies that collect no personal data need no consent (paragraph 7.9). The PDPC’s example is a session cookie that only stores technical data to play a video.
• Functions the visitor asked for may not need consent where they know the purpose and gave the data voluntarily (7.10). The examples include storing what a user types into a web form for a purchase, authentication, security, user preferences and streaming.
• Browser settings can reflect consent, but doing nothing does not (7.12). Someone who never changed their browser’s cookie settings has not, by that alone, consented to every website’s purposes.
• Targeted advertising through cookies needs consent (7.14). As good practice, the PDPC says websites should let people set their cookie preferences to switch such cookies on or off.
• A third party collecting through your site carries the consent obligation where you, the site operator, are not collecting the data yourself (7.13).

The guidelines also say an IP address on its own may not be personal data, but the more data points an organisation ties to an IP address over time, the more likely it identifies a person (7.3 to 7.5).

Our reading, as a practical split:

So a cookie banner is not required by name, but if your site runs ad pixels or remarketing tags, PDPC’s own good practice points to giving visitors a real choice. In our reading, a site that only uses essential cookies and analytics that cannot identify anyone has a much weaker reason for one.

Can website analytics rely on deemed consent by notification or legitimate interests?

Both came into the PDPA with the 2020 amendments, and both have conditions that are easy to miss.

Deemed consent by notification (section 15A, which applies from 1 February 2021) needs three things before you collect: an assessment that the collection is not likely to have an adverse effect on the person, a notice of your intention and purpose, and a reasonable period and way for the person to opt out. The Key Concepts Guidelines (chapter 12) add that collection should start only after the opt-out period ends. They describe it as useful for new uses of data you already hold, and give the example of exhibition sensors where it cannot be used, because visitors have no reasonable chance to opt out first. It cannot be used for sending direct marketing messages.

Our reading: analytics that start on the first page view leave no opt-out period before collection, so deemed consent by notification is a poor fit for them. It fits better when you want to use existing customer data for a new purpose and can email customers first.

The legitimate interests exception (First Schedule, Part 3, paragraph 1) lets you collect without consent if your legitimate interests outweigh any adverse effect on the person. You must assess this before collecting, keep the assessment, and tell people you rely on the exception, for example in your privacy policy, with a contact for questions. It cannot be used for direct marketing. The PDPC’s examples are security, fraud prevention and preventing misuse of services.

Our reading: legitimate interests fits a spam filter or bot check on your forms more naturally than ad tracking. For analytics, the safer route is to make the data less identifying: no names, emails or phone numbers sent to analytics tools, short retention, and no linking of visits to ad profiles.

One more exception helps after collection. The business improvement exception (First Schedule Part 5, and Second Schedule Part 2, Division 2) lets you use personal data you collected properly to improve your services or understand customer behaviour without fresh consent, if the purpose cannot reasonably be achieved without identifiable data and a reasonable person would consider it appropriate.

Are Meta Pixel, GA4 and Hotjar overseas data transfers under the PDPA?

In our reading, usually yes when they collect personal data, because the data can be stored or processed on the vendor’s servers outside Singapore. Section 26 says you must not transfer personal data overseas except under the prescribed requirements. The Key Concepts Guidelines (paragraphs 19.4 to 19.7) explain them: you can transfer if the recipient is bound by legally enforceable obligations, such as a contract that gives comparable protection and names the countries, or holds a recognised certification such as Global CBPR, and the PDPC encourages relying on these, especially in an ongoing relationship. The Selected Topics guidelines (paragraph 9.3) add that when you engage a cloud provider as a data intermediary, processing data for you, you are responsible for its overseas transfers, wherever the provider is based. A platform such as Meta that also uses the data for its own purposes is not simply your data intermediary, which is one more reason to read its terms.

In practice, that means knowing what each tag does with the data, and accepting the vendor’s data processing terms in its admin settings where it offers them. Some details that change what you write in your privacy policy:

• Meta Pixel with automatic advanced matching looks for recognisable form fields on your site, such as first name, surname and email address, and sends that information, hashed in the visitor’s browser, to Meta with the event, according to Meta’s help page on advanced matching. Your contact form can feed Meta without any extra code.
• Hotjar stores data in Amazon Web Services’ eu-west-1 region in Ireland, according to its security FAQs. Its suppression settings hide what visitors type by default, and also hide numbers and email addresses shown on the page, but other page text is not suppressed by default. So a recording of an account or order page can show the name and address displayed on it unless you suppress those elements.
• GA4: Google’s policies on personally identifiable information say no data that Google could use or recognise as identifying a person may be passed to Google Analytics, and warn that it often slips in through page addresses and titles. A form that puts the visitor’s email in the thank-you page address is the usual culprit, so check your thank-you URLs.

What happens under the PDPA if a website leaks personal data?

You assess the breach, and if it is notifiable you tell the PDPC within 3 calendar days of deciding so. Part 6A of the PDPA and chapter 20 of the Key Concepts Guidelines set out the steps:

1. Contain it. Take the exposed file, folder or page offline, change passwords and close the hole.
2. Assess it reasonably and quickly (section 26C). The PDPC expects this generally within 30 calendar days and asks you to document every step (paragraphs 20.4 and 20.5).
3. Decide whether it is notifiable (section 26B). It is if it is likely to cause significant harm to someone, or affects 500 or more people (paragraph 20.20). The prescribed data that is deemed to cause significant harm includes a full name or ID number with financial details, and an account’s username together with its password or security answer (paragraph 20.15).
4. Tell the PDPC as soon as practicable and no later than 3 calendar days after you decide it is notifiable (section 26D(1)), through its data breach e-service.
5. Tell the people affected when there is likely significant harm, at the same time as or after telling the PDPC (paragraph 20.22).

Two more points matter for websites. If your web host, agency or form provider finds the breach, it must tell you without undue delay, but the assessment and notification stay your responsibility (paragraphs 20.7 and 20.8). And a breach confined to your own organisation, such as an email to the wrong colleague, is not notifiable (section 26B(4)).

Common website causes are worth checking now: a form plugin that saves uploads in a public folder, a staging copy with real customer data, an admin account without two-factor login, and old exports left on the server. Our guide to what a website maintenance plan should cover covers the routine that prevents most of them.

Can a website form ask for NRIC numbers?

In most cases it should not. PDPC’s advisory guidelines on NRIC numbers say organisations are generally not allowed to collect, use or disclose NRIC numbers or copies (paragraph 2.1), unless the law requires it or identity must be verified to a high degree of fidelity. A partial number of up to the last 3 digits and the checksum letter, such as “567A”, is not treated as the full number (5.2), but it can still be personal data where a person can be identified from it (5.3). The PDPC notes on that document that the guidelines will be updated after MDDI’s statement of 13 December 2024, and remain valid meanwhile.

The PDPC and CSA’s joint advisory against using NRIC numbers for authentication (updated May 2026) goes further for websites. Organisations using full or partial NRIC numbers to authenticate people should stop as soon as possible, and should not use them as default passwords or combine them with other easily found data such as a birth date. The advisory’s examples of alternatives include an account with multi-factor login, and a link that expires or works once, with a unique password sent separately. In our reading, a “check your booking” page that asks for the last four characters of an NRIC should move to one of these, or to a booking reference plus a code sent to the customer’s email.

What changes when children use your website?

You need more care with their data, and a parent’s consent for children under 13. PDPC’s Advisory Guidelines on the PDPA for Children’s Personal Data in the Digital Environment (March 2024) apply to online services likely to be accessed by children, meaning anyone under 18, including services not aimed at them.

• Under 13: get consent from a parent or guardian (paragraph 4.5).
• 13 to 17: a child can give valid consent if the policies are readily understandable to them (4.2), so write the notice in plain words for that age.
• Protect it more: the guidelines say children’s personal data is generally considered sensitive and must be given a higher standard of protection.

For most business websites the practical effect is in the forms. In our reading, a tuition centre, enrichment school or kids’ sports club should design its enquiry form for the parent, ask only for the child details needed to reply, and keep marketing pixels away from pages where children fill in anything.

What should a website privacy policy include in Singapore?

It should say what your site actually collects, why, where it goes and who to contact, in plain words. The Key Concepts Guidelines (chapter 14) allow you to notify purposes through a data protection policy, suggest a layered notice with the summary at the point of collection, and warn that purposes stated too generally may need a more specific notice. They also say purposes stated in vague terms, an illegible font or an obscure place can count as misleading under section 14(2)(b).

A website privacy policy usually covers:

• What you collect, form by form, plus cookies, analytics and ad tags by name
• Why, one purpose per kind of data, including any that a visitor would not expect, such as ad measurement
• Who receives it, including service providers and ad platforms, and that some store data outside Singapore
• How long you keep it, or how you decide
• How to withdraw consent and what happens if they do (section 16)
• How to ask for access or correction (sections 21 and 22). The PDPC expects a reply as soon as reasonably possible; if you cannot reply within 30 days, tell the person in writing within 30 days when you will (paragraph 15.18).
• Any reliance on legitimate interests, with a contact for questions
• Your DPO’s business contact. PDPC guidance says it can be on BizFile+ or a readily accessible part of your website, working in Singapore business hours, and phone numbers should be Singapore numbers (paragraph 21.7).

Check the policy against the site each time you add a form, a tag or a new tool. A policy copied from another business, or written for European law, rarely matches what your site does.

How would Singapore businesses apply the PDPA to their websites?

These are fictional businesses, set up to show the decisions in context.

Saltpan Goods: an online homeware shop

Saltpan Goods sells online with customer accounts, a newsletter sign-up, GA4 and a Meta Pixel for its Instagram ads.

• Forms: checkout relies on deemed consent for the order itself, and account sign-up asks for consent with its own purpose line. The newsletter is a separate unticked box at checkout, never a condition of buying.
• Tags: automatic advanced matching was on, so the pixel read names and emails from the checkout form. The shop added a cookie preference setting for advertising cookies, and named Meta and the hashed matching in its privacy policy.
• Breach readiness: customer accounts hold usernames with their (hashed) passwords, which fall in a prescribed class, so a leaked account table would likely be notifiable. The shop turned on two-factor login for every admin account and rehearsed who decides on notification.

Larkspur Tuition: a tuition centre

Larkspur’s website has a trial class form, a WhatsApp button and GA4.

• Who consents: most students are under 13, so the form is written for the parent: parent’s name and contact, child’s first name, level and subject. No NRIC, no school name.
• Notice: one plain line says the details are used to arrange the trial class and reply, with the privacy policy linked.
• Tags: the Meta Pixel was removed from the trial class page, because the centre could not explain why ad platforms needed visits to it.

Tidewell Physio: a physiotherapy clinic

Tidewell’s booking form asks for the injury and preferred times, and the site runs Hotjar.

• Sensitive details: the Key Concepts Guidelines (17.2 and 17.3) ask for security that fits how sensitive the data is. The clinic keeps the injury field short and optional, and form entries go to the booking system rather than staying in the website’s database.
• Recordings: Hotjar recordings are switched off on booking pages, and page content suppression is on for the rest of the site.
• NRIC: the clinic stopped asking for NRIC numbers on the website form; identity is checked at the first visit if the treatment requires it.

How does our own website handle personal data?

We built our own analytics, Pulse, into jin-design.com, so the choices are ours to explain. This is what the code does today:

• Visitor IDs, not identities. Pulse gives each browser a random visitor ID, kept in local storage and in a first-party cookie set by our own server, plus a visit ID that is cleared when the tab closes. Once someone sends an enquiry, the visitor and visit IDs are saved with it, which links their earlier visits to their name and email. Our privacy policy describes all of this.
• No IP addresses in the analytics records. The server uses the IP address to limit how many requests one connection can send and to leave out our own team’s visits, and the visit and page-view tables have no IP column.
• Addresses are cleaned before they are stored. The tracker drops every query parameter except a short list, because anything else in a URL could carry personal data, such as an email in a thank-you page address. One kept parameter, q, can hold what a visitor typed into our site search, and it is cut to 60 characters.
• Old visit records are deleted. Visits and page views are removed automatically after a set period, 400 days unless we change it.

Enquiries are different: when someone contacts us, we keep what they send, with the IP address and device details, in our enquiry inbox, and our privacy policy explains when hashed contact details go to Google and Meta for ad measurement. We also run GA4 and Hotjar, which are named in the policy.

Need help checking your website against the PDPA?

Start with the website PDPA checklist, which shows what needs fixing and who owns each fix. Our website audit covers your site’s security and technical setup, our tracking and analytics service sets up tracking that fits your privacy policy and shows you exactly what is collected, and our website maintenance plans keep the software, backups and logins looked after. Talk to us if you want a second pair of eyes.

For more on the parts of a website that collect the most data, see our guides to landing pages for Google Ads in Singapore, which covers PDPA wording on lead forms, AI chatbots on Singapore websites, which covers what a chat widget collects, and website analytics tools.