WooCommerce itself is restrained about tracking. The PDPA exposure arrives through plugins that load tags on every page before your consent banner has rendered — and through a checkout marketing opt-in configured in a way sections 14(1) and 14(2) do not support.
wp_head for every plugin on every page load. A plugin that injects an analytics or advertising tag there will load before your consent banner unless it is explicitly gated.This guide follows the same structure as our Shopify PDPA guide, because the obligations are identical. What differs is where the problems hide.
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.
| Obligation | Section | What it means on a WooCommerce store |
|---|---|---|
| Notification | s.20(1)(a) | Tell customers what you collect and why, on or before collection — at the contact form, the newsletter box and the checkout, not only in a footer link. |
| Consent | ss.13–15 | Collection needs consent. Consent can be deemed under s.15 where a customer voluntarily provides data for a purpose he would reasonably expect — but profiling for analytics or advertising is not that, so those tags need a real choice, offered before they load. |
| Accountability | s.11(3), s.11(5) | Designate an individual, and publish their business contact information. |
| Protection | s.24 | Reasonable security arrangements. On self-hosted WordPress this includes patching core, themes and plugins. |
| Retention | s.25 | Stop keeping personal data once the purpose is spent and no legal or business need remains — form entries and old order data are where this bites on a store. |
| Transfer | s.26 | Your host, payment gateway, email service and analytics are probably not in Singapore. Permitted, but it must meet the prescribed requirements and be disclosed. |
wp_headThis is the single most common cause. A marketing, analytics or “site
kit” plugin hooks wp_head or wp_enqueue_scripts and
outputs its tag on every page load. Your consent plugin renders later, in the body. By
the time the visitor sees a choice, the request has gone.
Installing a consent plugin does not fix this by itself. Consent plugins block what they know how to block: their own script-blocking rules, tags routed through a supported tag manager, or scripts they can rewrite. A tag hard-coded by another plugin usually sits outside that.
Configuration screens tell you what a plugin intends. The network tab tells you what your site does. Load your homepage in a fresh private window with recording on, touch nothing, and read the requests.
WooCommerce and its extensions make it easy to add a newsletter opt-in at checkout, and easy to pre-tick it. Section 14(2)(a) prohibits requiring consent, as a condition of providing a product or service, beyond what is reasonable to provide that product or service. Marketing is not reasonably necessary to fulfil an order.
What that means in configuration terms: the marketing checkbox is unticked by default, it is separate from the terms and conditions tick, and the order completes whether or not it is ticked. If you send marketing to Singapore telephone numbers, Part 9 of the PDPA (the Do Not Call provisions) applies separately and has its own requirements.
WordPress generates a privacy policy draft, and themes often ship one. Both are scaffolding. Neither knows your payment gateway, your email platform, your retention periods, or that your host is in another country. Our eleven-point checklist covers what to add; the short version is that generic third-party language does not tell a customer who actually has their data.
Many form plugins keep a copy of every submission in your WordPress database, and many merchants do not know the entries table exists — storage behaviour differs between plugins and between versions, so check your own. Section 25 requires you to cease retaining personal data once the purpose is served and there is no remaining legal or business need.
In Re Goldheart Jewelry Pte. Ltd. [2025] SGPDPC 4 the platform was Magento rather than WooCommerce, but the finding generalises exactly: a patch for CVE-2022-24086 had been available since 13 February 2022 and was not applied until January 2023 — eleven months — and the vulnerability was exploited while the site was exposed, disclosing the personal data of 41,379 individuals. The Commission was not persuaded that vendor management removed the organisation's responsibility.
WordPress plugin vulnerabilities are disclosed continuously and are widely scanned for. If nobody owns updating your plugins, nobody is meeting your section 24 obligation for that layer.
_ga,
_gid, _fbp, _gcl_au. Repeat on a product page and
at checkout — some plugins only load on certain templates.Working through these nine steps closes the gaps that are visible from outside your store. It does not make a store PDPA-compliant, and no checklist can: consent records, vendor contracts, access control, breach response and whether your notices actually match what you collect all sit behind the login and are assessed on their own facts.
Free scan. Full PDF report with the PDPA references and a fix list from S$68.
We are deliberately not publishing a list of named plugins as risky. Plugin behaviour changes between versions, and a plugin is not unsafe in itself — the risk is in what it loads and when. Check by category instead, against your own install.
| Category | What to check |
|---|---|
| Analytics and site-kit plugins | Do they output the tag on wp_head regardless of consent state? Can they be set to wait for a consent signal? |
| Advertising and pixel plugins | Same question. These are the clearest case for pre-consent blocking, since profiling for advertising is not reasonably expected. |
| Live chat and support widgets | Third-party scripts that set their own identifiers on load. Many can be loaded on click instead of on page load. |
| Heatmap and session-recording tools | Session recording captures what a visitor types. Treat consent as required, and check whether form fields are masked. |
| Form builders | Where are submissions stored, for how long, and who can read them? |
| Backup and migration plugins | Backups contain customer personal data. Where are they written, and is that destination covered by your section 26 position? |
| Social sharing and embed plugins | Many load third-party scripts on every page even when nothing is shared. |
| Abandoned-cart and marketing automation | These collect email addresses before checkout completes. Notification must precede that collection. |
Sitetals fetches your homepage, a privacy or legal page linked from it, and one further page from your site, exactly as any visitor or complainant could. It reports what is visible from outside. It has no access to your servers, your contracts or your internal processes.
| Question | Visible to the scan? | Why |
|---|---|---|
| Is a privacy policy published and reachable? | Yes | Detected from homepage and footer links. |
| Is a data protection contact published? | Yes | Detected in the footer, homepage and linked legal pages. |
| Are third-party tracking or advertising scripts present with no consent mechanism? | Yes | Read from the page source of the pages we fetch. |
| Is the site served over HTTPS? | Yes | Observed at fetch time. |
| Is the policy adequate for your actual processing? | No | That depends on what you collect and why. A scan cannot read your business. |
| Was consent validly obtained and recorded? | No | Consent records are internal. |
| Is your patching, VAPT or access control reasonable? | No | Internal processes are not website-visible. |
| Are your vendor contracts adequate? | No | Contracts are not published. |
| The order in which scripts actually fire in a real browser | No | We read the page source; we do not execute your JavaScript. The network-tab test above is the check for this. |
A finding is a prompt to look, not a determination that the PDPA has been contravened. Only the Commission can make that determination.
No platform is compliant out of the box, because compliance depends on what you collect, what you disclose and what you load. A clean WooCommerce install with no marketing plugins is a reasonable starting point — it is not especially tracker-heavy by default.
The requirement is behavioural, not brand-specific: the tool must actually prevent non-essential scripts from executing before a choice is made, offer reject as readily as accept, and let a visitor change their answer. Several mainstream consent plugins can do this when configured for blocking rather than display.
Name the recipients of personal data, not every plugin. A plugin that only formats a page receives nothing. A plugin that transmits customer data to a third-party service means that service receives your customers' data, and the customer should be able to tell who it is.
Yes. The PDPA applies to the collection, use and disclosure of personal data in Singapore regardless of where the organisation or its infrastructure sits. Overseas hosting brings section 26 into play as well — covered here.
The PDPA sets a standard of reasonableness, not a schedule. The enforcement record is the practical guide: an eleven-month gap on a known, patched vulnerability was found unreasonable in Goldheart, and in People Central the absence of network vulnerability assessments together with a two-year interval between vulnerability scans supported a finding that periodic security reviews were not reasonable — that decision also noted external guidance putting penetration testing at least annually and vulnerability assessments quarterly. Weekly review of security releases, with someone named as responsible, narrows the gap the Commission has criticised. Whether it is enough for your store depends on what data you hold, and that is a judgement we cannot make from outside the site.