Section 20 requires you to inform people of the purposes for which you collect, use or disclose their personal data, on or before you collect it. Most generated policy text describes a business that is not quite yours. Here are eleven things worth covering in a Singapore privacy policy, which of them the Act actually requires, and how to check yours.
Most Singapore websites have something at /privacy-policy. Far fewer
have a document that describes what their site actually does.
The policy is not decoration. Under section 20 it is the instrument through which you discharge the Notification Obligation, and under section 14(1)(a) notification is a precondition of valid consent. If the policy does not describe what you collect, the consent built on top of it is standing on nothing.
This is compliance research, not legal advice. Sitetals is an independent scanner, not a law firm and not affiliated with the Personal Data Protection Commission.
Whether a specific obligation applies to your organisation is a question of fact and law. For a decision that carries risk, take advice from a Singapore-qualified practitioner.
An organisation must inform the individual of “(a) the purposes for the collection, use or disclosure of the personal data … on or before collecting the personal data; (b) any other purpose of the use or disclosure … before the use or disclosure …; and (c) on request by the individual, the business contact information of a person who is able to answer on behalf of the organisation the individual’s questions about the collection, use or disclosure of the personal data.”
Section 20(1) operates for the purposes of sections 14(1)(a) and 18(b) — it is the notification that makes consent valid and that fixes the purposes you may act on, rather than a standalone duty to publish a document. And section 20(3) switches it off where the individual is deemed to have consented under section 15 or 15A, or where you collect without consent under section 17.
Three duties sit behind a website privacy policy, and it is worth keeping them apart because they are satisfied differently.
| Section | Obligation | How a website satisfies it |
|---|---|---|
| s.20(1)(a) | Inform the individual of the purposes for collection, use or disclosure, on or before collecting | A published policy, linked from every point of collection, that states the actual purposes |
| s.20(1)(c) | On request, provide the business contact information of a person who can answer questions about the collection | A named contact route in the policy, so no one has to ask for it |
| s.11(5) | Make available to the public the business contact information of at least one designated individual | A published data protection contact — a separate duty, not satisfied by a general enquiries form |
Section 18 adds the outer limit: purposes must be ones a reasonable person would consider appropriate in the circumstances. This is why the catch-all clause that appears in so many templates — “and any other purpose we deem fit” — does no work. It is not a purpose. It is the absence of one.
Section 14(2)(b) prohibits obtaining, or attempting to obtain, consent by providing false or misleading information. A policy that describes retention schedules you do not operate, or a consent mechanism you never deployed, is not a harmless overstatement — it is a written record that the notification did not match the processing.
This is not a criticism of the platforms. A default template has to work for a merchant in any jurisdiction, so it is written at the level of generality that survives everywhere — which is exactly the level at which it stops being notification.
| What the template usually says | What a Singapore reader needs |
|---|---|
| “We share data with third-party service providers.” | Which ones. Payment processing, order fulfilment, email, analytics and advertising are different disclosures with different recipients. |
| “We retain data as long as necessary.” | A stated basis for how long, mapped to s.25: cease retention once the purpose is served and retention is no longer needed for legal or business reasons. |
| Silence on overseas transfer | That the platform, payment and analytics infrastructure is outside Singapore, and on what basis the transfer is made (s.26). |
| A generic support email, if any contact at all | A data protection contact published under s.11(5). |
| “By using this site you consent to…” | Consent obtained where it is needed, not asserted by browsing. Section 14(1) requires notification first and then consent for that purpose. |
| GDPR language about legitimate interests and DPIAs | PDPA framing. The PDPA has its own legitimate-interests exception in Part 3 of the First Schedule, with its own pre-collection assessment and a carve-out for marketing — GDPR wording describes a different test, and its presence usually means the document was not localised. |
Scan observations, not findings of breach: section 11(5) can also be satisfied by filing the contact with ACRA on BizFile+, which a website scan cannot see. Source: Sitetals production scan database, Singapore country set, completed scans 17–27 August 2026 (n = 10,298), extracted 27 August 2026.
Work through these against your live site. Where an item does not apply, say so explicitly in the policy rather than leaving it silent.
Not all eleven are statutory requirements: what the Act requires you to tell people is the purposes (section 20(1)(a)) and a data protection contact (sections 11(5) and 20(1)(c)), plus a written summary of overseas protection where you rely on the individual’s consent to transfer data out of Singapore (regulation 10(3)(a), Personal Data Protection Regulations 2021). The rest are PDPC-recommended or our own practice, and they are here because they are what makes a policy an accurate description of the business.
List it by category. Walk every form: contact, newsletter, account registration, checkout, support chat, reviews, wishlist. Include what you collect automatically — IP address, device and browser information, pages viewed — because that is personal data too when tied to an identifier.
Purposes must be specific enough that a reader can tell what will happen. “To fulfil and deliver your order, including passing your address to our delivery partner” is a purpose. “For business purposes” is not. If you use order data for marketing as well as fulfilment, that is a second purpose and it needs stating.
Name them. A Singapore store typically discloses to a platform (Shopify or the hosting provider), a payment processor (Stripe, PayPal, a local acquirer), a delivery partner, an email platform, analytics, and advertising networks.
The Act does not require you to name your recipients — section 20(1)(a) is about purposes, not about who receives the data — but naming them is the difference between a disclosure a reader can act on and one they cannot.
For most e-commerce sites the answer is yes, because the platform, the payment processor and the analytics all sit overseas. Section 26 permits this subject to prescribed requirements ensuring comparable protection — it does not prohibit it. Say where data goes and how the transfer is covered.
One point of precision: section 26 and regulation 10(1) are a transfer duty — satisfy yourself that the recipient is bound to a comparable standard — rather than a duty to tell anyone. It becomes a notification duty on one route: where you rely on the individual’s consent for the transfer, regulation 10(3)(a) means that consent does not count unless the individual was first given a reasonable summary in writing of how the transferred data will be protected. The mechanics are here.
Section 25 requires you to stop retaining personal data, or to strip the link to the individual, once the purpose is no longer served and there is no remaining legal or business need. State the periods you actually apply. If you have never set any, that is the finding — set them before you write the sentence.
Describe the mechanisms: the tick-box at signup, the consent banner, the unsubscribe link. Section 16 requires that consent can be withdrawn on reasonable notice, so give a route and say what happens after — for instance, that withdrawing marketing consent does not delete an order record you are required to keep.
Individuals may request access to their personal data and correction of it. Say how to make such a request and where it goes.
Section 11(5)
requires the business contact information of at least one designated individual to be
publicly available. A functional address such as dpo@yourdomain.com that
reaches the designated person is fine, and is more durable than a personal address.
More on designating and publishing here.
While you are there, add the complaint route. Section 12 requires you to have a process for receiving and responding to complaints about your handling of personal data, and to make information about that process available on request. Publishing it next to the contact costs one line and removes the request step.
Either in the policy or in a linked cookie notice, describe the categories of trackers, what each does, and how the visitor controls them. Consent mechanics here.
Marketing consent must be a distinct choice, not a condition of buying. Section 14(2)(a) prohibits requiring consent, as a condition of providing a product or service, beyond what is reasonable to provide it.
In practice: no pre-ticked marketing box, no bundling marketing into the terms tick-box, and a separate unsubscribe route. If you send marketing messages to Singapore telephone numbers, the Do Not Call provisions in Part 9 are a separate regime with their own requirements.
Date the policy and mean it. If you change what you collect or who receives it, the policy changes on the same day, and material changes to purposes may require fresh notification rather than a silent edit.
Sitetals checks whether a privacy policy is discoverable from your homepage and footer, whether a data protection contact appears on the pages we fetch, and whether third-party trackers load before any consent choice is offered.
These are observations from outside your site, not findings of breach: under the PDPA a tracker may run on deemed consent, and a data protection contact filed with ACRA on BizFile+ is not visible to a scan.
Run a free PDPA scanFree scan. Full PDF report with the PDPA references and a fix list from S$68.
The PDPA does not name a document called a privacy policy, but section 20 requires you to inform individuals of the purposes for collection on or before collecting, and section 12 requires organisations to develop and implement policies and practices necessary to meet their obligations. For a website that collects personal data, a published policy is the practical way to do both.
As a starting structure, yes. As a finished document, no. A generator does not know which processors you use, how long you keep data, whether it leaves Singapore, or who your designated individual is — and those are precisely the elements that make the notification real. Generate, then rewrite against your actual site.
Treat it as a template rather than a finished document. Generated policy text — Shopify’s generator, the WordPress and WooCommerce suggested text, the free online generators — is written for merchants worldwide, so it tends to describe third parties generically, say little about retention, and leave out both a Singapore data protection contact and any Singapore-specific transfer framing. What each tool produces changes over time and depends on what you edited afterwards, so read your own text rather than ours: in our experience it needs localising before it does the job.
Not necessarily. A clearly marked section in the privacy policy is enough, provided it accurately describes the categories of trackers, what they do, and how a visitor controls them. What matters is accuracy and findability, not the number of documents.
It is a worse position than saying nothing. Section 14(2)(b) prohibits obtaining or attempting to obtain consent by providing false or misleading information, and an overstated policy is exactly the kind of representation that does not survive examination. Describe what you do; then improve what you do.