Cookie Consent and Website Tracking Under PDPA: What Singapore Businesses Get Wrong

Most Singapore business websites run tracking scripts before a visitor has agreed to anything. Here's what the PDPA actually requires, and how to fix it properly.

A Banner That Doesn’t Do What It Looks Like It Does

Visit most Singapore SME websites and you’ll see a cookie banner in the corner — “This site uses cookies” with an OK button. Check the network traffic behind the scenes, and you’ll often find Google Analytics, Meta Pixel, and two or three ad-retargeting scripts had already fired before the visitor clicked anything. The banner is decorative. The tracking already happened. This is the single most common PDPA gap we find when auditing a client’s existing website, and it’s rarely deliberate — it’s just how most website builders and plugins ship by default.

What PDPA Actually Requires

Singapore’s PDPA doesn’t specifically legislate “cookies” the way the EU’s ePrivacy rules do, but it does regulate the collection of personal data, and tracking cookies that build a profile of a visitor’s behaviour, device, or identity fall within that scope. The PDPA relies heavily on the concept of consent, with a narrower carve-out called deemed consent for situations where collection is reasonably necessary to provide something the visitor asked for. Strictly necessary cookies — the ones that keep a shopping cart working or remember a login — generally fall under deemed consent. Analytics, advertising, and retargeting cookies almost always don’t, because the site would function perfectly well without them from the visitor’s point of view.

The Mistakes We See Most Often

  • Tracking fires before consent — the script loads on page load regardless of what the visitor clicks, so the banner is legally meaningless
  • No real “reject” option — only “Accept” is offered, or “reject” is hidden two menus deep, which undermines the idea that consent was freely given
  • One bucket for everything — necessary, analytics, and advertising cookies are lumped into a single toggle, so visitors can’t decline advertising tracking without also breaking the site
  • No record of consent — if the PDPC ever asks, there’s no log showing what a given visitor actually agreed to and when
  • Third-party scripts nobody remembers adding — a marketing team member pastes in a new pixel eighteen months ago and nobody revisits what data it’s collecting

What a Compliant Setup Actually Looks Like

A properly built consent flow blocks non-essential scripts by default, only firing analytics and advertising tags after a genuine opt-in, and gives visitors an equally easy way to say no as to say yes. This usually means a consent management platform sitting in front of your tag manager, rather than a cookie banner bolted on as a separate plugin that has no actual control over what fires. It also means someone periodically auditing what scripts are actually running on the site — because tracking tags accumulate quietly over years and rarely get removed.

Why This Is Worth Fixing Proactively

PDPC enforcement against SMEs for cookie-specific breaches is still relatively rare compared to enforcement for data breaches, but the exposure is real: an aggrieved customer complaint, a due diligence check ahead of a partnership or acquisition, or a platform like Google or Meta tightening its own consent requirements can all surface this gap suddenly. Fixing it properly, once, is far cheaper than fixing it under pressure.

How Oasis Web Asia Handles This

Every website we build for a Singapore client ships with consent-gated tracking by default — scripts stay off until a visitor genuinely opts in, categorised clearly between necessary, analytics, and marketing. If you’re not sure what’s actually firing on your current site, we can run a quick tracking audit and show you exactly what’s collecting data before a visitor has said yes to anything. Get in touch with our team if you’d like that audit done.