Singapore PDPA Requirements: Duties, 3-Day Breach Rule, Penalties
What Singapore's PDPA requires: core duties, the 3-calendar-day breach notification rule, PDPC penalties up to 10% of turnover, and a checklist.
What does Singapore's PDPA require? The Personal Data Protection Act 2012 (PDPA) makes any organisation that handles personal data in Singapore follow a set of data protection obligations: get consent, use data only for stated purposes, protect it, keep it no longer than needed, and control transfers abroad. Since 2021 it also requires breach notification: once you assess a breach as notifiable, you tell the regulator within 3 calendar days.
This is not legal advice. I am not a lawyer: this is CyphrQ.ai explaining the PDPA in simple terms. Follow the links to check the sources with your legal adviser.
What is the PDPA and who must follow it?
The PDPA is Singapore's general data protection law. It is administered by the Personal Data Protection Commission (PDPC), which publishes the Act's obligations, guidance and its enforcement decisions on pdpc.gov.sg. The statute itself is on Singapore Statutes Online.
It applies to organisations, not to individuals acting in a personal capacity. "Organisation" is defined broadly in the Act, so assume companies, associations and sole traders are all in scope.
In practice: if you collect names, phone numbers, ID numbers or email addresses of people in Singapore, you hold personal data. The question is not whether the law applies but which of its duties you are meeting today.
The 2020 amendments, in the Personal Data Protection (Amendment) Act 2020, added two big changes: mandatory breach notification and a much higher financial penalty ceiling. Both are covered below.
What are the main PDPA obligations for organisations?
The PDPC groups the Data Protection Provisions into named obligations. The plain-language version:
| Obligation | What it means for you |
|---|---|
| Consent | Get the person's consent before collecting, using or disclosing their data, unless an exception applies. Let them withdraw it. |
| Purpose limitation | Use data only for purposes a reasonable person would consider appropriate and that you told the person about. |
| Notification | Tell people the purposes before or when you collect the data. |
| Access and correction | Let people ask what you hold and fix errors. |
| Accuracy | Make a reasonable effort to keep data correct, especially if you use it to decide something about the person. |
| Protection | Put reasonable security arrangements in place to prevent unauthorised access, copying, loss and similar risks. |
| Retention limitation | Stop keeping data when you no longer need it for a business or legal purpose. |
| Transfer limitation | Make sure data sent outside Singapore stays protected to a comparable standard. |
| Accountability | Appoint a person responsible for compliance, write policies, and be able to show them. |
| Data breach notification | Assess breaches, then notify the PDPC and affected people when the breach is notifiable. |
The PDPC publishes this list on its data protection obligations page. Some summaries count nine obligations, others eleven. The count depends on whether breach notification and data portability are included, and on the date of the guide. Count less and check more: the table above is a working list, not a legal one.
Two of these show up in the decisions covered below: Protection and Accountability. The next sections show how.
Do I have to report a data breach in Singapore?
Yes, if the breach is notifiable. The Act's breach notification regime sits in sections 26A to 26E of the PDPA and has two steps: assess, then notify.
Step 1: assess. When you have credible grounds to believe a breach has happened, you must assess whether it is notifiable. Singapore's government stated the time limit in Parliament on 22 November 2023: organisations must assess "within 30 calendar days from when the organisation has credible grounds to believe that a data breach has occurred" (MDDI).
Step 2: notify. If the breach is notifiable, the same reply says you must notify the PDPC "no later than three calendar days" after that finding (MDDI). The PDPC's own breach-reporting page says a notifiable breach should be reported "as soon as practicable", and that unreasonable delay is itself a breach of the obligation (PDPC).
The two figures add up to the 33-calendar-day outer limit the government quoted from discovery for a mandatory report (MDDI). Treat 33 days as a ceiling, not a target. The wording is "as soon as practicable", so waiting out the clock is a poor defence.
What makes a breach notifiable? The regime uses two tests: likely significant harm to the people affected, or significant scale. The PDPC's guidance, rather than my summary, should be your reference for the exact thresholds and the list of data types treated as causing significant harm. Start from the PDPC's Guide on Managing and Notifying Data Breaches.
Do you also tell the people affected? Where the breach is likely to cause them significant harm, yes. The PDPC's page says to notify them as soon as practicable, at the same time as or after notifying the PDPC (PDPC).
How much can the PDPC fine under the PDPA?
Up to S$1 million, or for larger organisations, up to 10% of annual turnover in Singapore. Section 48J of the PDPA sets the cap. The 2020 amendments raised it, and the higher figure applies to organisations whose annual Singapore turnover exceeds S$10 million; for everyone else the ceiling stays at S$1 million (PDPA, section 48J; PDPC Advisory Guidelines on Enforcement). The enforcement guidelines are dated 1 October 2022, the date the higher cap took effect.
That is a ceiling, not a typical outcome. The PDPC sets the amount case by case, and its decisions are public, so you can read how it reasons.
What does PDPC enforcement look like in practice?
Two decisions show the pattern, one older and one recent.
SingHealth and IHiS, 2019. The PDPC fined the IT vendor IHiS S$750,000 and the healthcare group SingHealth S$250,000 after a 2018 attack exposed the records of about 1.5 million patients. Both the party running the systems and the party owning the data were penalised. The full case file, including the attack path, is in our SingHealth breach analysis.
Marina Bay Sands, 2025. On 28 October 2025 the PDPC announced a financial penalty on Marina Bay Sands Pte Ltd for breaching the Protection Obligation (PDPC press release). The amount was S$315,000. According to the PDPC, the breach followed a large software migration in March 2023: one API identifier was left out of the new configuration, exposing the data of 665,495 patrons, and the company had relied on one employee to compile the list of API configurations by hand, with no second layer of checks. The omission went undiscovered for six months. The data was later found offered for sale on the dark web.
The full reasoning is in the PDPC's grounds of decision, [2025] SGPDPC 6. The cause was not a sophisticated attack on the front door. It was a migration step with one person and no review.
In practice: both cases involve the Protection Obligation, and neither involves a defence that "we were hacked". The PDPC asks whether the security arrangements were reasonable before the incident, not whether the attacker was clever.
The PDPC also publishes smaller decisions. In May 2026 it published a decision titled "Breach of the Accountability and Protection Obligations" involving MCST 4869, a management corporation (PDPC). The page text I could read gave the title and date only, so I do not describe its facts. The title alone shows that the PDPC applies these obligations to small bodies as well as large ones.
What should an organisation do now? A checklist
- Name a person responsible for data protection and publish a contact for it.
- List the personal data you hold, where it sits, and which vendors touch it.
- Check each purpose against what you told people at collection.
- Set a retention period for each data type and delete on schedule.
- Write a breach plan with one rule: who decides "this is notifiable" and how fast.
- Put a second pair of eyes on every migration, configuration change or bulk export that touches personal data.
- Review vendor contracts for how quickly a vendor must tell you about an incident.
Start with item 5. A written decision-maker is what turns a 3-day deadline from a scramble into a routine.
Going deeper: for security and IT teams
Treat the breach clock as two timers. The statutory structure is a 30-calendar-day assessment window that starts when you have "credible grounds to believe" a breach occurred, then a 3-calendar-day notification window that starts when you conclude it is notifiable (MDDI). Neither timer is a licence to wait. The two steps sit in the breach notification sections of the PDPA, and the PDPC says unreasonable delay breaches the obligation (PDPC). Document the timestamp of "credible grounds" and the timestamp of the notifiable decision. Those two records are the evidence that you met the timelines.
Build the assessment into incident response. Add a data breach triage step to your runbook, ahead of containment sign-off:
- What personal data was involved, and for how many people?
- Is it the kind of data that could cause significant harm, such as identity numbers, financial account details or authentication data? Check the PDPC guide's list rather than relying on memory.
- Was the data encrypted, and was the key exposed too?
- Who decides, and who is the named deputy?
Keep the assessment record even when you conclude the breach is not notifiable. The PDPC can ask why you decided as you did.
Protection Obligation: what "reasonable security arrangements" looks like after a decision. The Marina Bay Sands decision turned on a change-management failure: one person compiled a list of API configurations manually with no second check, and one identifier was omitted. The controls that map to this failure are mundane and testable:
- A peer-reviewed, ticketed change for any migration that moves or exposes personal data.
- An inventory of API endpoints and their authentication settings, compared automatically before and after a migration.
- External attack-surface scanning after each change, to find endpoints that respond without authentication.
- Logging of bulk reads from APIs, with an alert on volume spikes per client or key.
- Monitoring of paste sites and dark web markets for your customer data, to shorten the time between exposure and discovery.
Data intermediaries. A data intermediary processes personal data on your behalf, such as a cloud host, payroll provider or marketing platform. As the organisation that owns the data, you stay responsible for it. The SingHealth case is the reference point: the IT vendor and the data owner were both penalised (PDPC decision). Contractually, define how fast an intermediary must tell you about an incident, and what information it must give you. The PDPC's Guide on Data Protection Clauses for Agreements is the document to start from. Your 30-day clock starts when you have credible grounds, which may be later than when your vendor does, so ask for a notification period of hours or a few days, not weeks.
Accountability evidence. A DPO appointment, policies and a record of your processing are what you show when the PDPC asks. Keep:
| Evidence | What good looks like |
|---|---|
| DPO appointment | Named person, published business contact, board-level reporting line |
| Data inventory | Data types, locations, vendors, retention period per type |
| Breach register | Every incident and assessment, with timestamps and the decision-maker |
| Vendor register | Contract, security terms, incident notification period |
| Change records | Reviewer sign-off on any migration touching personal data |
What to verify. Ask your legal adviser to confirm the current thresholds for notifiable breaches, the data types treated as significant harm, and any exceptions to notifying individuals, using the Act and the PDPC guide above. Ask your vendors for their breach notification period in writing. Test your own process with a tabletop exercise: from a simulated alert, can you reach a documented "notifiable or not" decision within a day?
Key takeaways
- The PDPA applies to organisations handling personal data in Singapore, and it sets named obligations from consent through to protection, retention and transfer.
- You must assess a suspected breach within 30 calendar days of having credible grounds, and notify the PDPC no later than 3 calendar days after finding it notifiable.
- The financial penalty cap is S$1 million, or 10% of Singapore turnover for organisations above S$10 million in turnover.
- Recent decisions turn on the Protection Obligation: reasonable security before the incident, including change control and vendor management.
- Outsourcing does not outsource responsibility. Name a decision-maker for breaches, and keep the assessment record.
Sources
- PDPC: Data protection obligations
- PDPC: Required to notify the PDPC
- PDPC: Guide on Managing and Notifying Data Breaches under the PDPA (15 March 2021)
- PDPC: Advisory Guidelines on Enforcement of the Data Protection Provisions (1 October 2022)
- PDPC: Guide on Data Protection Clauses for Agreements Relating to the Processing of Personal Data (1 February 2021)
- PDPC: PDPC imposes financial penalty on Marina Bay Sands for data breach (28 October 2025)
- PDPC: Breach of the Accountability and Protection Obligations by MCST 4869 (7 May 2026)
- PDPC: Grounds of Decision, SingHealth and IHiS (January 2019)
- Singapore Statutes Online: Personal Data Protection Act 2012
- Ministry of Digital Development and Information: Reply to parliamentary question on a data security incident (22 November 2023)
- CyphrQ: SingHealth data breach 2018