PDPA Data Breach Notification Singapore: The 3-Day Rule
Published 18 September 2026 · 10 min read
Singapore PDPA breach rules: the 30-day assessment, the 3-day PDPC deadline, the 500-individual threshold and what a notification must contain.
The short answer
Under Singapore's Personal Data Protection Act (PDPA), an organisation that has credible grounds to believe a data breach has occurred must assess whether it is notifiable — and the Personal Data Protection Commission (PDPC) expects that assessment to be completed within 30 calendar days. Once the organisation determines the breach is notifiable, it must notify the PDPC as soon as practicable and in any case no later than three calendar days, and notify affected individuals at the same time or after notifying the Commission.
A breach is notifiable if it is likely to result in significant harm to affected individuals, or if it affects 500 or more individuals. Both tests matter: a small breach of prescribed data types is notifiable even if it touches ten people, and a large breach of ordinary data is notifiable purely on scale.
Stratgik is a technology firm, not a law firm. Everything below is drawn from the legislation and PDPC guidance and is written to help engineering and operations teams build the right systems. It is not legal advice, and organisations should take Singapore-qualified legal advice on their specific facts.
Where the obligation comes from
The Data Breach Notification Obligation sits in Part 6A of the PDPA, introduced by the Personal Data Protection (Amendment) Act 2020 and in force since 1 February 2021. The operating detail is in the Personal Data Protection (Notification of Data Breaches) Regulations 2021, which prescribe the thresholds and the exact information a notification must contain. The PDPC's Guide on Managing and Notifying Data Breaches under the PDPA sets out how the Commission expects the obligation to be met in practice.
Three sections do most of the work: section 26C creates the duty to assess "in a reasonable and expeditious manner", section 26D sets the notification deadlines, and section 26B read with the Regulations defines what counts as notifiable.
The two thresholds, precisely
Significant harm
Regulation 3 deems a breach to result in significant harm where it relates to the individual's full name, alias or identification number together with personal data set out in Part 1 of the Schedule to the Regulations — broadly, financial data such as salary, income or a card or bank account number; certain health and insurance information; information on investigations, arrests or court proceedings; adoption information; and private keys. Part 1 is read subject to Part 2, which narrows its effect in certain circumstances, so the Schedule itself is the authority, not a summary of it.
Regulation 3(1)(b) adds a separate limb that catches a very common breach pattern: an account identifier (an account name or number) combined with any password, security code, access code, answer to a security question, biometric data or other data used to access the account. A leaked credentials table is notifiable on its own terms — no financial or health data required.
Significant scale
Regulation 4 fixes the prescribed number at 500 affected individuals. Where a breach touches 500 or more people, it must be notified to the PDPC even if no prescribed data category is involved. The PDPC's guide is explicit that where the exact count is not yet known, an organisation should notify once it has reason to believe the number is at least 500, based on an initial appraisal, and update the Commission with the actual figure later.
| Question | Requirement | Source |
|---|---|---|
| How long to assess? | Reasonable and expeditious steps; PDPC expects assessment within 30 calendar days, with an explanation ready if longer | s 26C PDPA; PDPC guide |
| How long to notify the PDPC? | As soon as practicable, no later than 3 calendar days after the assessment concludes the breach is notifiable | s 26D(1) |
| When does the 3-day clock start? | The first day is the day after the determination. Determine on 1 January, notify by 4 January | PDPC guide, footnote to timeframes |
| When to notify individuals? | As soon as practicable, at the same time as or after notifying the PDPC | s 26D(2) |
| Harm threshold | Prescribed data in Part 1 of the Schedule with name/ID, or account identifier plus credentials | reg 3 |
| Scale threshold | 500 or more affected individuals | reg 4 |
| Processor duty | A data intermediary must notify the organisation it processes for, without undue delay | s 26C(2) |
| Maximum financial penalty | Up to 10% of annual turnover in Singapore where that exceeds S$10 million, otherwise up to S$1 million | In force 1 October 2022 |
What goes into the notification
Regulation 5 lists nine items the PDPC notification must contain, and it is more than an incident summary: the date and circumstances of first becoming aware; a chronological account of the steps taken since, including the section 26C assessment itself; how the breach occurred; the number of affected individuals; the data involved; the potential harm; the action taken or planned to mitigate harm and remedy the underlying failure; the plan for informing individuals or the public; and business contact details for at least one authorised representative.
Two consequences follow. A late notification must additionally state the reasons for the delay and include supporting evidence, so there is no quiet way to miss the deadline. And the chronological account means the evidence has to exist before the incident does — teams that cannot reconstruct who knew what and when will struggle to produce a credible account inside three days.
Notification is filed through the PDPC's data breach reporting e-service. Regulation 6 sets out the separate, shorter list of what must be told to affected individuals, including what happened, what data of theirs was involved, the potential harm, what the organisation is doing, and — importantly — the steps the individual can take to protect themselves.
When you do not have to tell individuals
Section 26D provides narrow exceptions to notifying individuals — not to notifying the Commission. They apply where the organisation takes remedial action after the assessment that makes significant harm unlikely; where it had already implemented, before the breach, a technological measure that makes harm unlikely; where a law enforcement agency or the Commission directs otherwise; or where the Commission waives the requirement on written application.
The second exception is the one worth engineering for. Strong encryption of data at rest, with keys held separately and not compromised in the same incident, is the difference between an internal remediation exercise and a mass customer notification. The PDPC's own Singapore's Data Breach Landscape 2023/24 report puts encryption of sensitive data at rest and in transit among its four headline mitigations.
The enforcement picture
Since 1 October 2022 the maximum financial penalty has been the higher of 10% of annual turnover in Singapore (where that turnover exceeds S$10 million) or S$1 million, as confirmed in Allen & Gledhill's note on the commencement. The PDPC assesses turnover from the most recent audited accounts available when the penalty is imposed.
The direction of travel is clear from the PDPC's own numbers. Its 2023/24 landscape report records a 41% year-on-year increase in large-scale breaches (those affecting more than 500 individuals) reported to the Commission, and a 200% increase in enforcement actions. Cyber incidents accounted for 82% of the cases where the PDPC took enforcement action for weak security measures, and ransomware accounted for 62% of those cyber incidents.
That last figure is the one to plan around: for most organisations the realistic scenario is a ransomware operator who has been in the network for weeks, so the 30-day assessment window is consumed by forensics still establishing what was exfiltrated rather than merely encrypted.
Two adjacent obligations that catch teams out
First, the data intermediary duty. If you process personal data for another organisation, you must notify it without undue delay once you have credible grounds to believe a breach has occurred. You do not make the notifiability assessment — they do — but their three-day clock cannot start until you tell them. If your processor contracts do not name a notification window in hours, they are not fit for the deadline they sit inside.
Second, the NRIC change. On 2 February 2026 the PDPC announced that private organisations must cease using NRIC numbers for authentication by 31 December 2026, with enforcement — directions or financial penalties — from 1 January 2027. NRIC numbers may still be used to identify individuals; what stops is using them, whole or partial, to prove that someone is who they claim to be, including as default passwords built from an NRIC plus a name or date of birth. Any team still running that pattern in a customer portal has a hard deadline this year, and an identification-number-plus-prescribed-data breach is precisely the combination regulation 3 deems significantly harmful.
A practical readiness checklist
- Write down who declares an incident, who owns the section 26C assessment and who signs the PDPC notification — by role, with named deputies. Three calendar days includes weekends.
- Maintain a current data inventory that maps each system to whether it holds Schedule Part 1 data, account credentials, or 500-plus individual records. Without it, the assessment starts with discovery.
- Make logging sufficient to reconstruct a chronology: authentication events, database access, data egress, and the timestamps of your own response actions.
- Pre-draft the notification. Regulation 5's nine fields become a template; only the facts change. Pre-draft the individual notice under regulation 6 too, including the self-protection steps.
- Encrypt personal data at rest with keys managed separately, so the section 26D technological-measure exception is genuinely available to you.
- Put a contractual notification window on every data intermediary — hours, not "promptly" — and test it once a year.
- Enforce multi-factor authentication, patch on a defined cycle, and audit backend service accounts. These are the specific failures the PDPC has repeatedly cited in ransomware decisions.
- Keep offsite, offline backups you have actually restored from. Recovery speed shortens the assessment window.
- Run one tabletop exercise a year against the clock: hour zero to filed notification, with the 30-day and 3-day deadlines marked.
- Close out the NRIC-for-authentication review before 31 December 2026.
Where the engineering work usually sits
The notification deadline is rarely missed for want of a policy. It is missed because nobody can answer "whose data, how many, and which fields" fast enough — a data architecture problem of inventory, classification, logging and egress monitoring, solved before the incident.
If you are working through this for a Singapore entity, our Singapore PDPA compliance page sets out how we approach the implementation side, and the Singapore market hub covers the wider picture for companies operating here. Where the gap is monitoring and response capacity rather than design, managed technology is usually the faster route; where the systems themselves need rebuilding around the data model, that is custom software work.
Frequently asked questions
How many days do I have to report a data breach to the PDPC in Singapore?
Three calendar days from the point at which you determine the breach is notifiable, and as soon as practicable within that. The PDPC's guide clarifies that the first of the three days is the day after the determination — determine on 1 January and you must notify by 4 January. Separately, the assessment that leads to that determination is expected to be completed within 30 calendar days of having credible grounds to believe a breach occurred.
Is a breach affecting fewer than 500 people still notifiable?
Yes, if it is likely to result in significant harm. The 500-individual test in regulation 4 is an alternative threshold, not a floor. A breach exposing a handful of account identifiers together with passwords, or names together with bank account numbers, is notifiable regardless of how few people are affected.
Do I have to tell affected individuals if the data was encrypted?
Possibly not. Section 26D provides an exception where the organisation had implemented, before the breach, a technological measure that makes significant harm unlikely. Whether your encryption qualifies depends on the implementation and on whether the keys were also compromised, so put it to Singapore-qualified counsel with the technical facts in hand. The exception does not remove the obligation to notify the PDPC.
What if I miss the three-day deadline?
Notify anyway, immediately. Regulation 5(2) requires a late notification to state the reasons for the delay and include supporting evidence. Unreasonable delay is itself a contravention of the notification obligation and can attract enforcement action, so a documented, evidenced explanation is materially better than a quiet late filing.
Does the obligation apply to my cloud provider or IT vendor?
If they process personal data on your behalf they are a data intermediary, and they must notify you without undue delay when they have credible grounds to believe a breach has occurred. The duty to assess and to notify the PDPC stays with you. Because your three-day clock depends on their speed, the notification window belongs in the contract in hours.
What is the maximum fine for a PDPA breach?
For contraventions occurring on or after 1 October 2022, up to 10% of the organisation's annual turnover in Singapore where that turnover exceeds S$10 million, and up to S$1 million in any other case — whichever is higher on those facts. The PDPC determines turnover from the most recent audited accounts available when it imposes the penalty.
Breach notification is the visible end of a data protection programme, but the deadline is only meetable if the inventory, logging and response roles are already in place. If you are assessing where your Singapore operation stands, start with our Singapore PDPA compliance page, and take Singapore-qualified legal advice on how these obligations apply to your organisation.
Written by the Stratgik team. Stratgik is a technology strategy and engineering firm headquartered in Gurugram, India, serving India, the United States, the United Kingdom, Singapore, the UAE and Saudi Arabia. We are not a law firm and this article is not legal advice.
Keep reading
More from Stratgik

20 Sep 2026
Custom Software Development Cost in Saudi Arabia (2026)
What a custom software build really costs in Saudi Arabia: PDPL data residency, ZATCA Phase 2 e-invoicing, Arabic locali...

19 Sep 2026
AI WhatsApp Agents for Dubai Real Estate: Cost and Rules 2026
What an AI WhatsApp agent costs a Dubai brokerage in 2026, Meta's 1 Oct fee change, and the Trakheesi, TDRA and UAE PDPL...

18 Sep 2026
Singapore NRIC Deadline 2026: Masking Was Never Protection
Singapore bans NRIC numbers for authentication by 31 Dec 2026 - and says masking them never worked. What to change, and...

