Website Hacked? Your PDPA Data Breach Duties in Singapore (October 2026)

A PDPA data breach is any unauthorised access, collection, use, disclosure, copying, modification or disposal of personal data, or the loss of a device holding it, so a hacked website that holds customer data counts even if you can't prove anything was downloaded. That's the definition in section 26A of the Act's Part 6A. Unauthorised access is enough.

Two details catch website owners out:

• Made-up names still count. When Fortytwo, an online furniture store, suggested some customers had given incomplete or fictitious names, the PDPC pointed out that personal data means data about an individual "whether true or not", and applied the obligation to the entire customer database.
• Outdated software is a named cause. The PDPC's Guide on Managing and Notifying Data Breaches lists "usage of outdated software" among the computer system weaknesses attackers exploit to reach personal data.

A breach that stays entirely inside your organisation, like a staff member opening a file they shouldn't, is deemed not notifiable under section 26B(4). A website hack comes from outside, so that exception rarely helps.

A typical small business website holds more personal data than its owner expects: contact form entries, WooCommerce orders and customer accounts, newsletter sign-ups, uploaded CVs and documents, and the backups that copy all of it. On a WordPress site it usually sits here:

WordPress stores passwords hashed rather than in plain text. That may matter for the exception covering technological protection, discussed below, but it's a judgement to make in your assessment, not an automatic pass.

The cheapest breach is data you never kept. The PDPA already says not to retain personal data once you no longer need it, so delete form entries you've dealt with, old order exports, and backups sitting in public folders. Fewer records also means a smaller number in any future breach.

A data breach is notifiable under the PDPA if it affects 500 or more people, or if it's likely to cause significant harm to anyone affected, and some data is deemed to cause significant harm however few people are involved. Section 26B sets the two tests, and the Notification of Data Breaches Regulations 2021 fill in the detail:

• Significant scale: 500 or more affected individuals. If you can't count them yet, the PDPC's guide says to notify once you have reason to believe it's at least 500, and update the figure later.
• Deemed significant harm: a person's full name, alias or identification number together with any item on the regulations' list, which includes credit and debit card numbers, bank account numbers, salary, and some health, insurance and adoption details.
• Also deemed significant harm: an account identifier, such as a username or login email, together with its password, security code or the answer to a security question.

Applied to websites, roughly:

The PDPC has a self-assessment tool on its data breach reporting page that walks you through the same tests.

You have up to 30 calendar days to assess whether a breach is notifiable, counted from when you have credible grounds to believe it happened, and then no more than 3 calendar days to notify the PDPC once you decide it is. The two clocks are separate. Plenty of what's written online starts the 3 days at discovery, which isn't what the Act says.

The PDPC's own example: decide on 1 January that a breach is notifiable, and the deadline is 4 January, because day one is the day after the decision. Notification goes through the PDPC's e-service form, which asks how the breach happened, how many people, what data, the possible harm, a timeline of your steps, and what you're doing about it. If you're late, you have to give reasons and evidence, and the PDPC says those reasons go toward how seriously it treats the lapse.

Two practical points. The guide says you must document the steps you took to assess the breach, so keep the server logs and a dated record from day one. And if the assessment runs past 30 days, be ready to explain why.

You must tell each affected customer about a notifiable breach that is likely to cause them significant harm, at the same time as or after you notify the PDPC, unless an exception applies. A breach that's notifiable only because of its size doesn't, on its own, require individual notices under section 26D(2).

The exceptions in section 26D are narrow:

• after the breach, you took action that makes significant harm unlikely
• before the breach, you had a technological measure in place, encryption for example, that makes significant harm unlikely
• a law enforcement agency or the PDPC tells you not to notify
• the PDPC waives the requirement on your written application

The PDPC's guide asks for a notice in plain language covering what happened and how you found out, which of their data was affected, the possible harm, what you've done, what they can do, and a person to contact. For a hacked website, "what they can do" is usually concrete: you force a password reset and tell them to change that password anywhere else they used it, or you tell them to watch their card statements and call their bank.

The PDPC can fine an organisation up to 10% of its annual Singapore turnover if that turnover is above S$10 million, or up to S$1 million otherwise, for breaches from 1 October 2022. That's section 48J(3) of the Act. The penalty is for a failed obligation, usually the Protection Obligation in section 24 (reasonable security arrangements) or the notification rules themselves. Being hacked isn't, on its own, a breach of the Act, as the Sembcorp Marine case below shows.

Website cases have landed far below the cap, from directions with no fine to S$58,000. In the Goldheart decision the PDPC set out what it weighs: the organisation's turnover, how culpable it was, the harm to individuals, the number of people and type of data, and how long the failure lasted. It then reduced the figure for prompt remedial action, cooperation, and admitting the facts under its expedited procedure. Directions cost money too: security audits, penetration tests and upgrades on a deadline.

The PDPC has penalised Singapore businesses whose websites were breached through unpatched software, an unsupported platform, or a web vendor nobody was supervising. These come from its published decisions; quoted words are the PDPC's.

And one where the PDPC found no breach at all. Sembcorp Marine ([2023] SGPDPCS 2) was attacked through the Log4J flaw as early as 4 January 2022, weeks after it was first reported, and the personal data of 25,925 people was taken. But it had started hunting for Log4J across its systems on 14 December 2021, applied patches as soon as vendors released them, used the vendors' workarounds where no patch existed yet, and ran regular vulnerability assessments and penetration tests. The PDPC found it had met the Protection Obligation and took no enforcement action.

Going by these decisions, being hacked through a brand-new flaw you were already working on wasn't treated as a failure. Leaving a known patch unapplied for months, or running software its maker had stopped supporting, was.

No. Outsourcing your website to a developer or maintenance vendor doesn't move the PDPA obligation, and the business that collects the personal data stays responsible for protecting it. In the full Goldheart decision, the PDPC repeated its line from an earlier case: organisations "may delegate work to vendors to comply with the PDPA", but "the organisations' responsibility for complying with statutory obligations under the PDPA may not be delegated."

Most web vendors aren't even your "data intermediary" in the legal sense. Goldheart argued its Magento vendor was; the PDPC disagreed, because the vendor's job was maintenance on request, not processing personal data on Goldheart's behalf. The contractors in the Horizon Fast Ferry case weren't data intermediaries either. So the duty to watch for patches stayed with the business.

The same decision shows what reasonable reliance looks like. The PDPC contrasted Goldheart with The Law Society of Singapore, whose reliance on a vendor for security patching it had found reasonable, because the Society kept maintenance logs of the vendor's work and so had a way to monitor it. Goldheart had no such process.

This matters a lot right now. Reporting on CSA's PHP advisory, AsiaOne noted CSA's warning that smaller businesses relying on outside IT providers and hosting companies "may not realise that their systems are affected." Based on what the PDPC has criticised, this is what I'd put in writing with whoever looks after your site:

• Who watches for security updates to WordPress, plugins, themes and PHP, and how fast they're applied.
• A log of every update and fix, which you actually receive.
• Vulnerability scans after launch, which Kingsforce never had done.
• Telling you straight away about any suspected breach, since your 30 days may already be running.
• Handing back and disabling every login, server key and account when the contract ends, which is what went wrong at Horizon Fast Ferry.

Whoever looks after your site, me included, ask them for that monthly log of updates. It's the record the PDPC looked for.

The PDPC hasn't ruled on PHP2Shell, but its decisions treat a security patch that's available and not applied, or software past its end of support, as a failure to make reasonable security arrangements. That puts this week squarely in scope. PHP released fixed versions (8.5.12, 8.4.27, 8.3.36 and 8.2.35) on 21 October 2026, per php.net, and CSA's advisory says to "patch immediately". AsiaOne quoted CSA's chief executive, Gwenda Fong: "The threat is immediate."

Hold the cases up against PHP2Shell:

• PHP 8.1 or older gets no fix from the PHP project at all. That's Fortytwo's position after Magento 1 lost support, and the PDPC's direction there was to upgrade to a supported version.
• A supported PHP branch that nobody has updated looks like Goldheart: a known patch, a vendor waiting to be asked, and nobody asking.
• Sembcorp Marine shows the other side. It moved on Log4J as soon as fixes existed and used workarounds where they didn't. PHP's advisory lists interim mitigations too, while saying only an update is a complete fix.

Check with your host first. Many shared hosts patch PHP on their own servers, and if yours already has, that part costs you nothing. If it hasn't, or the site is pinned to an old version, this is work I do: a fixed price in writing before I start, covering the PHP update and anything it breaks, from SGD 850. After that, my content retainer at SGD 550 a month keeps WordPress, plugins and PHP updated. Both are on my website maintenance page. Staying on WordPress this way is a fair choice, and my WordPress security checklist sets out how to keep it patched.

Or take PHP out of the picture. A statically built site has no PHP or database on the server for a flaw like this to reach. It still collects personal data through its forms, so the PDPA still applies, but there's far less on the server to lose. I build these on Astro, and MET Interior's 176-page site moved off WordPress that way. I'll quote a rebuild next to the fix so you can compare: Starter from SGD 2,535, the One Week Website at SGD 3,545, or Growth from SGD 7,585 if your team edits the site itself. The tiers are in my website design packages.

Yes, the PDPA applies to small businesses and sole proprietors, because the Act's definition of "organisation" includes any individual, company, association or body of persons, incorporated or not. The PDPC has penalised a sole proprietorship: in 2024 the owner of a phone shop trading as Top Mobile Gallery was fined S$7,000 for failing to protect customers' personal data ([2024] SGPDPCS 1).

A hacked contact form is a notifiable data breach if the entries cover 500 or more people, or if they hold data deemed to cause significant harm, such as an NRIC number with bank or salary details, or a login with its password. A smaller set of names, emails and phone numbers usually isn't on the deemed tests, but you still have to assess it, consider the context, and keep a record of how you decided.

You report it, because the business that controls the personal data carries the duty to assess the breach and notify the PDPC. If your developer or host processes personal data for you as a data intermediary, the PDPA requires it to tell you without undue delay. A vendor that only maintains the site usually isn't a data intermediary, so make sure your contract says it will tell you anyway.

Missing the PDPC's 3-day deadline is itself a breach of the PDPA's notification obligation, and the PDPC can take enforcement action for it. You still notify, and the form makes you give the reasons for the delay with supporting evidence. The PDPC's guide says those reasons go toward how serious it considers the contravention, and so toward any penalty.