WorkflowSingaporePDPA Breach Notification

Singapore PDPA Breach Notification Workflow

This workflow helps move a suspected from containment through notifiability assessment, PDPC notification, affected-individual notification, and post-incident evidence.

It is based on PDPC breach guidance and the Personal Data Protection (Notification of Data Breaches) Regulations 2021, and supports implementation planning.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
Overview

A Singapore PDPA workflow starts by preserving the facts: what happened, whether personal data was involved, whether the breach is still ongoing, how many individuals may be affected, what data classes are exposed, what containment has already happened, and whether the PDPC or affected individuals must be notified.

Section 1

1. Activate containment and ownership

Treat both suspected and confirmed personal data breaches as intake events. PDPC guidance says an assigned individual or group should be notified when suspected or confirmed breaches are detected, and that the data breach management team should act according to assigned roles.

If a vendor is processing personal data as a data intermediary, the workflow should capture whether it is notifying the customer organisation without undue delay. The customer organisation remains responsible for assessing notifiability and making any PDPC or individual notifications required under the PDPA.

  • Open an incident record with the detection source, time discovered, reporting person, affected product or service, and suspected breach type.
  • Assign the DPO, incident response lead, legal/privacy reviewer, technical owner, communications owner, and vendor contact where a data intermediary is involved.
  • Start containment before the notification assessment is complete: isolate affected systems, reset or disable compromised accounts, change access rights, stop the practice that caused the breach, and attempt recovery or recall of wrongly sent data where applicable.
  • Preserve evidence needed for incident resolution and legal proceedings, including logs, forensic copies, affected-system details, actions taken, and the chain of events.
Section 2

2. Assess whether the breach is notifiable

Once the organisation has credible grounds to believe that a data breach has occurred, the workflow should require reasonable and expeditious assessment of whether the breach is notifiable under the PDPA. PDPC guidance uses 30 calendar days as the expected assessment period. An organisation that needs longer should be ready to explain the time taken, and an unreasonable delay can breach the Data Breach Notification Obligation.

The assessment record should separate two questions: whether the breach is likely to result in to affected individuals, and whether it is of .

  • Record the cause of the breach, whether it is still ongoing, affected systems, affected personal data classes, estimated and confirmed individual counts, and actions already taken to reduce harm.
  • Assess by checking whether the compromised data includes prescribed personal data under the DBN Regulations, such as a full name, alias, or identification number together with listed data classes, or account credentials that enable account access.
  • Assess by checking whether the breach involves personal data of 500 or more individuals, or whether there is reason to believe the affected count is at least 500.
  • If the assessment cannot be completed within 30 calendar days, prepare an explanation for the time taken or required, because PDPC guidance expects the organisation to be able to explain the delay.
Section 3

3. Decide who must be notified

The notification decision depends on why the breach is notifiable. A breach likely to cause requires notification to the PDPC and affected individuals unless an exception, prohibition, waiver, or other written law changes the individual-notification position. The individual-notification exceptions include timely remedial action that makes significant harm unlikely and a technological measure that makes the affected data inaccessible or unintelligible. The Commission may still direct the organisation to notify individuals. A breach that only meets the significant-scale threshold requires notification to the PDPC even if it does not involve prescribed personal data.

For affected individuals, the workflow should not release messages before confirming the PDPC sequencing. PDPC guidance says affected individuals must be notified as soon as practicable, at the same time or after notifying the PDPC. For breaches likely to attract widespread public attention or interest, PDPC says to notify PDPC first before notifying individuals or issuing public or media statements.

  • Notify PDPC as soon as practicable and no later than three calendar days after determining that the breach is notifiable.
  • Notify affected individuals as soon as practicable, at the same time or after PDPC, when the breach is notifiable because it is likely to result in and no supported ground for not notifying applies.
  • If affected individuals will not be notified despite a significant-harm breach, record the remedial action or technological measure, the evidence that the exception is satisfied, or the other written law, prohibition, waiver, or exception relied on. Include the grounds in the PDPC notification.
  • If sectoral regulators, law enforcement, clients, or public communications are involved, track those channels separately; PDPC guidance says other legal reporting requirements do not replace PDPA notification where PDPA notification is required.
Section 4

4. Build the PDPC and individual notice records

The workflow should produce two evidence packets: one for PDPC and one for affected individuals when individual notification is required. The PDPC packet is broader because it must explain the breach facts, the chronology after awareness, the notifiability assessment, harm mitigation, remediation, any plan to inform affected individuals or the public, and the authorised representative.

The affected-individual notice should be clear and practical. It should tell the affected person what happened, what personal data classes relating to them were affected, potential harm, what the organisation has done or will do, and what the individual can do to reduce misuse risk.

  • PDPC packet: date and circumstances of awareness, how the breach occurred, affected count, affected data classes, potential harm, chronological response, assessment basis, mitigation and remediation, individual/public communication plan, and authorised representative contact.
  • Late PDPC notification packet: reasons for notifying after the required period and supporting evidence for the delay.
  • Affected-individual packet: circumstances of awareness, affected data classes for that individual, potential harm, organisational mitigation and remediation, protective steps for the individual, and business contact details for help.
  • Special handling: where the breach involves adoption matters or identification of vulnerable individuals, PDPC guidance says to notify the Commission first for guidance on notifying affected individuals.
Section 5

5. Evaluate the breach and close the workflow

Closure should not mean only that the form was filed. PDPC guidance expects organisations to evaluate the response and consider changes that prevent similar breaches. The closeout record should connect the root cause, containment actions, notification decisions, evidence preserved, remediation owner, and follow-up controls.

Use the post-breach review to test whether the workflow itself worked: whether the breach management plan was activated quickly, whether roles and communications were clear, whether vendor responsibilities were defined, whether logs and forensic evidence were preserved, and whether containment and recovery actions were audited.

  • Root cause record: chronological timeline, exploited weakness, missed signs, prior known issues, probable causes, and underlying cause.
  • Prevention record: short-term containment, long-term containment, backups or restoration evidence, monitoring period, and what monitoring should look for.
  • Governance record: senior management involvement, employee training gaps, vendor or partner responsibilities, policy changes, and evidence that action items were completed.
  • Workflow improvement: update intake questions, escalation owners, contact lists, data maps, vendor clauses, notification templates, and exercise scenarios based on what the incident exposed.
Primary sources

References and citations

pdpc.gov.sg6 citations
Referenced sections
  • PDPC guide used for the C.A.R.E. workflow, containment actions, assessment expectations, notification timing, notice content, and post-breach evaluation.
  • Supports immediate containment steps, activation of the breach management team, incident record logs, forensic copies, and the C.A.R.E. response model.
  • Supports the 30-calendar-day assessment expectation, required documentation of assessment steps, and assessment factors such as data type, affected individuals, context, and containment effectiveness.
Show 3 more
  • Supports PDPC notification within three calendar days after determining notifiability, affected-individual sequencing, and the rule that other regulator reports do not replace PDPA notification.
  • Supports practical notice content, clear affected-individual notices, and consulting PDPC first where adoption matters or vulnerable individuals are involved.
  • Supports post-breach evaluation, root cause analysis, prevention planning, audits, policy updates, training changes, and review of data intermediaries.
"CONTAIN, ASSESS, REPORT, EVALUATE (C.A.R.E)"
More quoted passages
"within 30 calendar days"
"no later than three (3) calendar days"
"clear and easily understood"
"prevent the recurrence of similar data breaches"
sso.agc.gov.sg3 citations
Referenced sections
  • Singapore subsidiary legislation used for significant-harm criteria, the 500-individual significant-scale threshold, and required notification contents.
  • Supports the prescribed significant-harm data categories and the 500-affected-individual threshold for significant scale.
  • Supports the required content for notifications to the Commission and affected individuals, including late-notification reasons and supporting evidence.
"the prescribed number of affected individuals is 500"
More quoted passages
"include any supporting evidence"
pdpc.gov.sg2 citations
Referenced sections
  • PDPC advisory guidelines used for the data intermediary obligation to notify the organisation without undue delay after credible grounds for a breach.
  • Supports the data intermediary step: an intermediary processing on behalf of another organisation must notify that organisation without undue delay after credible grounds exist.
"notify the organisation without undue delay"
pdpc.gov.sg2 citations
Referenced sections
  • PDPC self-assessment page used to support the notifiability assessment step and the point that not every breach must be reported.
  • Supports using PDPC self-assessment as an aid while making clear that organisations do not need to report every breach.
"Organisations do not need to report every breach"
pdpc.gov.sg2 citations
Referenced sections
  • PDPC guidance used for affected-individual notification sequencing and the instruction to notify PDPC first for breaches likely to attract widespread public attention.
  • Supports notifying affected individuals as soon as practicable at the same time or after PDPC, and notifying PDPC first for breaches likely to attract widespread public attention.
"at the same time or after notifying the PDPC"
pdpc.gov.sg2 citations
Referenced sections
  • PDPC reporting page used for the public trigger that organisations must notify PDPC and affected persons for breaches likely to cause significant harm or affecting significant scale.
  • Supports the public PDPC reporting trigger for breaches likely to cause significant harm or affecting a significant scale of individuals.
"likely to cause significant harm"
Show all related guides (37)

Singapore PDPA Consent, Notification and Purpose Rules

How Singapore PDPA consent, notification, purpose limitation, deemed consent, withdrawal, and consent exceptions should be handled in product and privacy workflows.

Singapore PDPA Cross-Border Transfers

Source-cited Singapore PDPA guidance for overseas personal data transfers, comparable protection, ASEAN MCCs, APEC certifications, vendor roles, and evidence records.

Singapore PDPA Data Breach Notification Thresholds

Source-cited Singapore PDPA breach notification thresholds covering significant harm, the 500-individual significant-scale test, assessment records, and notification timing.

Singapore PDPA Data Intermediary Responsibilities

Practical Singapore PDPA guide to data intermediary role boundaries, organisation accountability, protection, retention, breach escalation, and contract evidence.

Singapore PDPA Deadlines and Compliance Calendar

A Singapore PDPA compliance calendar for breach notification, DNC checks, access and correction requests, enforcement responses, retention reviews, and DPMP maintenance.

Singapore PDPA Deemed Consent and Legitimate Interests

How to apply Singapore PDPA deemed consent by conduct, contractual necessity, notification, and legitimate interests with opt-out, adverse-effect, disclosure, and assessment records.

Singapore PDPA DNC and Marketing Messages Guide

A source-cited Singapore PDPA guide to DNC checks, specified marketing messages, Singapore telephone numbers, consent evidence, opt-outs, sender duties, and excluded messages.

Singapore PDPA DNC Marketing Checks

Operational checklist for Singapore PDPA DNC marketing checks: account evidence, register status, 21-day result validity, consent evidence, and campaign owner records.

Singapore PDPA DNC Marketing Workflow

Workflow for Singapore PDPA DNC marketing campaigns: classify specified messages, check Singapore telephone numbers, document consent, suppress opt-outs, and approve sends.

Singapore PDPA DPMP Accountability Guide

Build a Singapore PDPA Data Protection Management Programme with DPO ownership, policies, data inventories, DPIAs, training, monitoring, breach logs, and review records.

Singapore PDPA FAQ: scope, DPO, consent, breaches and DNC

FAQ answers for Singapore PDPA implementation, covering scope, accountability, consent, access and correction, security, retention, transfers, data intermediaries, breach notification, and DNC checks.

Singapore PDPA NRIC Handling Rules

When Singapore organisations may collect, use, disclose, retain, mask, or replace NRIC numbers, including the 31 December 2026 authentication deadline.

Singapore PDPA Penalties and Enforcement Cases

How PDPC enforcement under Singapore's PDPA works: directions, voluntary undertakings, published decisions, financial penalty caps, and implementation lessons from cases.

Singapore PDPA Penalties and Fines

Singapore PDPA penalty ceilings, PDPC directions, undertakings, breach notification context, and practical controls based on official PDPC and Singapore Statutes sources.

Singapore PDPA Privacy Policy Template

A Singapore PDPA privacy policy template for writing notices, DPO contact details, access and correction routes, retention, transfers, protection, withdrawal, and complaint handling without overclaiming compliance.

Singapore PDPA Requirements: Core Obligations

Map Singapore PDPA obligations across consent, notification, access, security, retention, transfers, accountability, breaches, DNC checks, and data intermediaries.

Singapore PDPA Scope, Exclusions, and Data Intermediaries

Classify Singapore PDPA coverage, business contact information, personal or domestic activity, employee acts, and data intermediary obligations using cited statutory boundaries and processing records.

Singapore PDPA Transfer Assessment Workflow

A Singapore PDPA workflow for assessing overseas personal data transfers, comparable protection, ASEAN MCCs, APEC CBPR/PRP certifications, vendor due diligence, onward transfers, and evidence records.

Singapore PDPA Transfer Clauses

Draft Singapore PDPA transfer clauses for overseas vendors, affiliates, data intermediaries, onward transfers, ASEAN MCCs, and APEC or Global CBPR and PRP evidence.

Singapore PDPA Vendor Outsourcing and Contracts

Contract and operating checklist for Singapore PDPA vendor outsourcing: data intermediary status, written terms, security, retention, breach, transfers, sub-contracting, and exit evidence.

Singapore PDPA vs GDPR Comparison

Compare Singapore PDPA and EU GDPR rules for legal bases, DPOs, intermediaries and processors, transfers, breaches, marketing objections, rights, retention, and penalties.

Singapore PDPA anonymisation FAQ

FAQ on anonymisation under the Singapore PDPA: de-identification, pseudonymisation, re-identification risk, when PDPA may no longer apply, and evidence records.

Singapore PDPA breach notification thresholds FAQ

FAQ on Singapore PDPA notifiable data breach tests: significant harm, significant scale, 500 affected individuals, assessment timing, PDPC notices, and affected-individual notices.

Singapore PDPA Data Intermediaries FAQ

FAQ guidance on Singapore PDPA data intermediary roles, direct obligations, organisation accountability, contracts, retention, protection, and breach escalation.

Singapore PDPA Deemed Consent FAQ

FAQ on Singapore PDPA deemed consent by conduct, contractual necessity, notification, opt-out periods, adverse-effect assessment, withdrawal, and direct-marketing limits.

Singapore PDPA DNC checking FAQ: when to check the DNC Registry

FAQ guidance on Singapore PDPA DNC checking: when to check the DNC Registry, which registers apply, 8-digit numbers, 21-day result validity, consent evidence, on-behalf checks, opt-outs, and supported exclusions.

Singapore PDPA DPIAs: when to run and what to document

FAQ-style implementation guidance on Singapore PDPA DPIAs, including when PDPC guidance recommends them, data-flow mapping, risk treatment, DPO review, and evidence records.

Singapore PDPA DPMP Accountability FAQ | DPO, Policies, Evidence

FAQ for implementing Singapore PDPA accountability through a DPMP: DPO designation, policies, evidence, training, monitoring, incident logs, and review records.

Singapore PDPA legitimate interests FAQ

FAQ guidance on Singapore PDPA legitimate interests: assessment fields, adverse effects, mitigation, balancing, disclosure, records, and marketing limits.

Singapore PDPA NRIC Handling FAQ

FAQ guidance on when Singapore organisations may collect, use, disclose, retain, mask, or replace NRIC and other national identification numbers under PDPC guidance.

Singapore PDPA transfer clauses FAQ

FAQ guidance on Singapore PDPA transfer clauses, comparable protection, ASEAN MCCs, APEC CBPR and PRP certifications, onward transfers, and evidence records.