---
title: "Singapore PDPA Breach Notification Workflow"
canonical_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/breach-notification-workflow"
source_url: "https://www.sorena.io/artifacts/apac/singapore-pdpa/breach-notification-workflow"
author: "Sorena AI"
description: "A grounded Singapore PDPA workflow for containing a personal data breach, assessing notifiability, notifying PDPC or affected individuals, and retaining evidence."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "Singapore PDPA"
  - "data breach notification"
  - "PDPC notification"
  - "notifiable data breach"
  - "PDPC"
  - "Incident response"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

# Singapore PDPA Breach Notification Workflow

A grounded Singapore PDPA workflow for containing a personal data breach, assessing notifiability, notifying PDPC or affected individuals, and retaining evidence.

*Workflow* *Singapore* *PDPA Breach Notification*

## Singapore PDPA Breach Notification Workflow

Use this workflow to move a suspected personal data breach from containment through notifiability assessment, PDPC notification, affected-individual notification, and post-incident evidence.

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

A Singapore PDPA breach workflow should not start with a filing form. It should first preserve 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 PDPC or affected individuals must be notified.

## 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.

Sources for this answer:

- [Guide on Managing and Notifying Data Breaches Under the PDPA](https://www.pdpc.gov.sg/help-and-resources/2021/01/data-breach-management-guide?ref=sorena.io) - Supports immediate containment steps, activation of the breach management team, incident record logs, forensic copies, and the C.A.R.E. response model.
- [Advisory Guidelines on Key Concepts in the PDPA](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/03/advisory-guidelines-on-key-concepts-in-the-personal-data-protection-act?ref=sorena.io) - Supports the data intermediary step: an intermediary processing on behalf of another organisation must notify that organisation without undue delay after credible grounds exist.

## 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 states this assessment should be completed within 30 calendar days, and that unreasonable delay can breach the Data Breach Notification Obligation.

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

- 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 significant harm 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 significant scale 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.

Sources for this answer:

- [Guide on Managing and Notifying Data Breaches Under the PDPA](https://www.pdpc.gov.sg/help-and-resources/2021/01/data-breach-management-guide?ref=sorena.io) - 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.
- [Personal Data Protection (Notification of Data Breaches) Regulations 2021](https://sso.agc.gov.sg/SL/PDPA2012-S64-2021?ref=sorena.io) - Supports the prescribed significant-harm data categories and the 500-affected-individual threshold for significant scale.
- [PDPC Data Breach Self-Assessment](https://www.pdpc.gov.sg/report-data-breach/self-assessment?ref=sorena.io) - Supports using PDPC self-assessment as an aid while making clear that organisations do not need to report every breach.

## 3. Decide who must be notified

The notification decision depends on why the breach is notifiable. A breach likely to cause significant harm requires notification to the PDPC and affected individuals unless an exception, prohibition, waiver, or other written law changes the individual-notification position. 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 significant harm and no supported ground for not notifying applies.
- If affected individuals will not be notified despite a significant-harm breach, record the PDPA, other written law, prohibition, waiver, or exception relied on and 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.

Sources for this answer:

- [Guide on Managing and Notifying Data Breaches Under the PDPA](https://www.pdpc.gov.sg/help-and-resources/2021/01/data-breach-management-guide?ref=sorena.io) - 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.
- [PDPC Report Your Organisation's Data Breach](https://www.pdpc.gov.sg/report-data-breach?ref=sorena.io) - Supports the public PDPC reporting trigger for breaches likely to cause significant harm or affecting a significant scale of individuals.
- [PDPC Guidance on Notification to Affected Individuals](https://www.pdpc.gov.sg/report-data-breach/before-you-report-a-data-breach-4/info-2?ref=sorena.io) - 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.

## 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.

Sources for this answer:

- [Personal Data Protection (Notification of Data Breaches) Regulations 2021](https://sso.agc.gov.sg/SL/PDPA2012-S64-2021?ref=sorena.io) - Supports the required content for notifications to the Commission and affected individuals, including late-notification reasons and supporting evidence.
- [Guide on Managing and Notifying Data Breaches Under the PDPA](https://www.pdpc.gov.sg/help-and-resources/2021/01/data-breach-management-guide?ref=sorena.io) - Supports practical notice content, clear affected-individual notices, and consulting PDPC first where adoption matters or vulnerable individuals are involved.

## 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.

Sources for this answer:

- [Guide on Managing and Notifying Data Breaches Under the PDPA](https://www.pdpc.gov.sg/help-and-resources/2021/01/data-breach-management-guide?ref=sorena.io) - Supports post-breach evaluation, root cause analysis, prevention planning, audits, policy updates, training changes, and review of data intermediaries.

*Recommended next step*

*Placement: after the workflow guidance*

## Operationalise the Singapore PDPA breach workflow

Turn PDPC notification criteria into intake fields, incident owners, evidence packets, and review tasks that teams can use during a breach.

- [Open Assessment Autopilot for Singapore PDPA](/solutions/assessment.md): Create scoped breach-assessment questions, ownership fields, and notification evidence requests.
- [Review Singapore PDPA source evidence](/solutions/research-copilot.md): Use Research Copilot to check PDPC and statutory source support before finalising breach records.
- [Talk through a Singapore PDPA breach workflow](/contact.md): Review containment, notifiability, notification sequencing, and evidence gaps with Sorena.

## Primary sources

- [Guide on Managing and Notifying Data Breaches Under the PDPA](https://www.pdpc.gov.sg/help-and-resources/2021/01/data-breach-management-guide?ref=sorena.io) - PDPC guide used for the C.A.R.E. workflow, containment actions, assessment expectations, notification timing, notice content, and post-breach evaluation.
  - Quote: "Contain, Assess, Report, Evaluate"
- [Personal Data Protection (Notification of Data Breaches) Regulations 2021](https://sso.agc.gov.sg/SL/PDPA2012-S64-2021?ref=sorena.io) - Singapore subsidiary legislation used for significant-harm criteria, the 500-individual significant-scale threshold, and required notification contents.
  - Quote: "the prescribed number of affected individuals is 500"
- [PDPC Report Your Organisation's Data Breach](https://www.pdpc.gov.sg/report-data-breach?ref=sorena.io) - 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.
  - Quote: "likely to cause significant harm"
- [PDPC Data Breach Self-Assessment](https://www.pdpc.gov.sg/report-data-breach/self-assessment?ref=sorena.io) - PDPC self-assessment page used to support the notifiability assessment step and the point that not every breach must be reported.
  - Quote: "Organisations do not need to report every breach"
- [PDPC Guidance on Notification to Affected Individuals](https://www.pdpc.gov.sg/report-data-breach/before-you-report-a-data-breach-4/info-2?ref=sorena.io) - PDPC guidance used for affected-individual notification sequencing and the instruction to notify PDPC first for breaches likely to attract widespread public attention.
  - Quote: "at the same time or after notifying the PDPC"
- [Advisory Guidelines on Key Concepts in the PDPA](https://www.pdpc.gov.sg/guidelines-and-consultation/2020/03/advisory-guidelines-on-key-concepts-in-the-personal-data-protection-act?ref=sorena.io) - PDPC advisory guidelines used for the data intermediary obligation to notify the organisation without undue delay after credible grounds for a breach.
  - Quote: "notify the organisation without undue delay"

## Related Topic Guides

- [Singapore PDPA Anonymisation and DPIA Records](/artifacts/apac/singapore-pdpa/anonymisation-and-dpias.md): Build Singapore PDPA anonymisation and DPIA records around PDPC guidance: release model, re-identification risk, data flows, action plans, safeguards, and monitoring.
- [Singapore PDPA anonymisation FAQ](/artifacts/apac/singapore-pdpa/faq/anonymisation.md): FAQ on anonymisation under the Singapore PDPA: de-identification, pseudonymisation, re-identification risk, when PDPA may no longer apply, and evidence records.
- [Singapore PDPA Applicability Test](/artifacts/apac/singapore-pdpa/applicability-test.md): Test whether Singapore PDPA obligations apply by checking personal data, organisation role, data intermediary status, public agency and individual boundaries, and business contact information.
- [Singapore PDPA Breach Notification Playbook](/artifacts/apac/singapore-pdpa/breach-notification-playbook.md): A grounded Singapore PDPA breach-notification playbook covering assessment, notifiable-breach thresholds, PDPC and affected-individual notification steps, roles, records, and citations.
- [Singapore PDPA breach notification thresholds FAQ](/artifacts/apac/singapore-pdpa/faq/breach-thresholds.md): 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 Compliance Checklist](/artifacts/apac/singapore-pdpa/checklist.md): A grounded Singapore PDPA checklist for scope, DPO accountability, consent, data intermediaries, breach notification, DNC checks, transfers, and evidence records.
- [Singapore PDPA Compliance Guide](/artifacts/apac/singapore-pdpa/compliance.md): Build a Singapore PDPA compliance plan covering DPO accountability, consent and notification, protection, retention, access and correction, transfers, breach notification, and DNC checks.
- [Singapore PDPA Consent and Deemed Consent Workflow](/artifacts/apac/singapore-pdpa/consent-and-deemed-consent-selection-workflow.md): Choose express consent, deemed consent by conduct, contractual necessity, notification, or the legitimate interests exception under Singapore PDPA with grounded intake fields and evidence records.
- [Singapore PDPA Consent, Notification and Purpose Rules](/artifacts/apac/singapore-pdpa/consent-notification-and-purposes.md): 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](/artifacts/apac/singapore-pdpa/cross-border-transfers.md): Grounded 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](/artifacts/apac/singapore-pdpa/breach-notification-thresholds.md): Grounded Singapore PDPA breach notification thresholds covering significant harm, the 500-individual significant-scale test, assessment records, and notification timing.
- [Singapore PDPA Data Intermediaries FAQ](/artifacts/apac/singapore-pdpa/faq/data-intermediaries.md): FAQ guidance on Singapore PDPA data intermediary roles, direct obligations, organisation accountability, contracts, retention, protection, and breach escalation.
- [Singapore PDPA Data Intermediary Responsibilities](/artifacts/apac/singapore-pdpa/data-intermediary-responsibilities.md): Practical Singapore PDPA guide to data intermediary role boundaries, organisation accountability, protection, retention, breach escalation, and contract evidence.
- [Singapore PDPA Deadlines and Compliance Calendar](/artifacts/apac/singapore-pdpa/deadlines-and-compliance-calendar.md): A grounded Singapore PDPA compliance calendar for breach notification, DNC checks, access and correction requests, retention reviews, and DPMP maintenance.
- [Singapore PDPA Deemed Consent and Legitimate Interests](/artifacts/apac/singapore-pdpa/deemed-consent-and-legitimate-interests.md): 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 Deemed Consent FAQ](/artifacts/apac/singapore-pdpa/faq/deemed-consent.md): 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 and Marketing Messages Guide](/artifacts/apac/singapore-pdpa/dnc-and-marketing-messages.md): A grounded Singapore PDPA guide to DNC checks, specified marketing messages, Singapore telephone numbers, consent evidence, opt-outs, sender duties, and excluded messages.
- [Singapore PDPA DNC checking FAQ: when to check the DNC Registry](/artifacts/apac/singapore-pdpa/faq/dnc-checking.md): 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 DNC Marketing Checks](/artifacts/apac/singapore-pdpa/dnc-marketing-checks.md): 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](/artifacts/apac/singapore-pdpa/dnc-marketing-workflow.md): Workflow for Singapore PDPA DNC marketing campaigns: classify specified messages, check Singapore telephone numbers, document consent, suppress opt-outs, and approve sends.
- [Singapore PDPA DPIAs: when to run and what to document](/artifacts/apac/singapore-pdpa/faq/dpias.md): 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](/artifacts/apac/singapore-pdpa/faq/dpmp-accountability.md): FAQ for implementing Singapore PDPA accountability through a DPMP: DPO designation, policies, evidence, training, monitoring, incident logs, and review records.
- [Singapore PDPA DPMP Accountability Guide](/artifacts/apac/singapore-pdpa/dpmp-accountability.md): 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](/artifacts/apac/singapore-pdpa/faq.md): 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 legitimate interests FAQ](/artifacts/apac/singapore-pdpa/faq/legitimate-interests.md): FAQ guidance on Singapore PDPA legitimate interests: assessment fields, adverse effects, mitigation, balancing, disclosure, records, and marketing limits.
- [Singapore PDPA NRIC Handling FAQ](/artifacts/apac/singapore-pdpa/faq/nric-handling.md): 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 NRIC Handling Rules](/artifacts/apac/singapore-pdpa/nric-handling.md): When Singapore organisations may collect, use, disclose, retain, mask, or replace NRIC numbers under PDPC guidance.
- [Singapore PDPA Penalties and Enforcement Cases](/artifacts/apac/singapore-pdpa/pdpa-penalties-and-enforcement-cases.md): 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](/artifacts/apac/singapore-pdpa/penalties-and-fines.md): Singapore PDPA penalty ceilings, PDPC directions, undertakings, breach notification context, and practical controls grounded in official PDPC and Singapore Statutes sources.
- [Singapore PDPA Privacy Policy Template](/artifacts/apac/singapore-pdpa/pdpa-privacy-policy-template.md): 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](/artifacts/apac/singapore-pdpa/requirements.md): 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](/artifacts/apac/singapore-pdpa/scope-exclusions-and-data-intermediaries.md): Classify Singapore PDPA coverage, business contact information, personal or domestic activity, employee acts, and data intermediary obligations with grounded implementation records.
- [Singapore PDPA Transfer Assessment Workflow](/artifacts/apac/singapore-pdpa/transfer-assessment-workflow.md): 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](/artifacts/apac/singapore-pdpa/transfer-clauses.md): Draft Singapore PDPA transfer clauses for overseas vendors, affiliates, data intermediaries, onward transfers, breach support, ASEAN MCCs, and APEC CBPR or PRP evidence.
- [Singapore PDPA transfer clauses FAQ](/artifacts/apac/singapore-pdpa/faq/transfer-clauses.md): FAQ guidance on Singapore PDPA transfer clauses, comparable protection, ASEAN MCCs, APEC CBPR and PRP certifications, onward transfers, and evidence records.
- [Singapore PDPA Vendor Outsourcing and Contracts](/artifacts/apac/singapore-pdpa/vendor-outsourcing-and-contracts.md): 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](/artifacts/apac/singapore-pdpa/singapore-pdpa-vs-gdpr.md): Compare Singapore PDPA and GDPR implementation work across consent, DPO accountability, processors, transfers, breach notification, DNC marketing, rights, retention, and penalties.


---

[Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/apac/singapore-pdpa/breach-notification-workflow