PDPA data breach notification: the 3-day rule for SMEs

PDPA data breach notification runs on two clocks. A breach of personal data is notifiable if it involves 500 or more people or data that PDPC treats as likely to cause significant harm, such as a full name with a bank account number. Once you determine that it is, you must tell PDPC as soon as practicable and no later than three calendar days afterwards; the day after your decision is day one.

The decision is the first clock: PDPC’s guidelines say organisations should generally decide within 30 calendar days of having credible grounds to believe a breach occurred. Affected individuals must also be told as soon as practicable, at the same time as or after PDPC, when the harm test is met and no exception applies.

This is general information from PDPC’s published guidance, not legal advice. Our glossary explains the terms.

What counts as a data breach, and does the PDPA cover small businesses?

PDPC’s guide to managing and notifying data breaches (revised 15 March 2021) defines a data breach as any unauthorised access, collection, use, disclosure, copying, modification or disposal of personal data, including losing a device where such access is likely. Its examples include hacking, phishing, theft of devices, losing a storage device and sending personal data to a wrong email address.

Small size is no exemption. PDPC’s Key Concepts guidelines (revised 29 April 2026) quote the PDPA’s definition of an organisation as “any individual, company, association or body of persons” and say every organisation must comply unless expressly excluded. One carve-out helps: a breach contained within your own organisation, such as HR emailing data to another department, is not notifiable (paragraph 20.6). An email to an outside address is not that case.

Which two tests make a breach notifiable in Singapore?

Either test is enough.

• Test 1, significant harm. PDPC’s guidelines say the Notification of Data Breaches Regulations 2021 prescribe data deemed likely to cause significant harm if compromised. If any is involved, you notify PDPC and the affected individuals however few they are (about 50 patients in PDPC’s clinic example), subject to the exceptions below.
• Test 2, significant scale. If 500 or more individuals are affected you notify PDPC even without prescribed data. If you cannot count yet, notify once you have reason to believe it is at least 500, and update PDPC later.

The prescribed list is at paragraph 20.15 of PDPC’s guidelines. In summary:

• A full name, alias or full national identification number (NRIC, FIN or passport number, for example) combined with non-public financial information (pay, card or bank account numbers, loans, credit history, debts), life, accident or health insurance details, specified medical information, data identifying certain vulnerable people or adoption information, among other categories.
• An account name or username with the password, security code or biometric data that opens the account. No name is needed.

None of the categories in paragraph 20.15 covers a name, mobile number or delivery address on its own. In PDPC’s example, an online shop whose 700-customer database was accessed had to tell PDPC, because of the number, but not the customers.

How do the 30-day and three-day clocks work?

• Day 0, discovery. The first clock starts when you have credible grounds to believe a breach occurred. Contain first (reset passwords, recall the email), alert your response lead and open an incident log. For suspected crime or a cyber incident the guide says to consider the police and SingCERT.
• Day 0 to day 30, assess. Take reasonable and expeditious steps to establish the facts and document each one. The 2026 guidelines say organisations should generally decide within 30 calendar days and be ready to explain to PDPC if they cannot. The 2021 guide’s Part III words it as a duty to assess “within 30 calendar days”, while its Part II says “In general”. Unreasonable delay in assessing is itself a breach of the obligation, so treat 30 days as an outer marker rather than a target.
• Determination, the second clock starts. Write down the date and time. Day one is the next day: PDPC’s example is a determination on 1 January with notification due by 4 January.
• Within three calendar days, tell PDPC. Notify as soon as practicable; do not wait for the last day. We read “calendar” as including weekends (our inference): the breach-notification chapter gives no weekend or public-holiday allowance. A footnote on access requests elsewhere in the guidelines mentions a Sunday or public-holiday extension to a 30-day period, but nothing like it appears here, so do not count on one. A late notification must give reasons and evidence, which PDPC says bear on any penalty.
• Individuals. As soon as practicable, at the same time as or after PDPC. You need not notify them if timely remedial action makes significant harm unlikely, or if encryption or similar protection applied beforehand left the data inaccessible or unintelligible to an unauthorised party; you must not if a prescribed law enforcement agency or PDPC instructs. PDPC is still notified, with your grounds for not telling individuals. The remedial-action exception has prescribed requirements that we did not read, so confirm it rather than assume it.

Who decides, and what if a supplier reports the breach?

The guide says a response plan should name who staff report to and set a clear command structure for the managers who assess risk and make time-critical decisions. The guidelines say the authorised contact named in the PDPC notification need not be your Data Protection Officer, although PDPC’s reporting page lists the DPO’s contact details among what to prepare; see how to appoint and register one.

A supplier that processes personal data on your behalf and for your purposes is a data intermediary; in our reading that usually includes a cloud or payroll platform. It must tell you without undue delay once it has credible grounds to believe a breach occurred; assessing and notifying stay with you. PDPC’s guidelines (paragraph 20.9) say organisations should set out clear procedures for complying when they sign service agreements with data intermediaries, so put the notice terms in the contract (AI vendor questions before you sign covers breach notice).

Worked example: one misdirected email, step by step

Everything here is fictional and illustrative. Greenlane Print Studio, nine staff, holds a refund list of 180 customers: full name, mobile number, bank account number and refund amount. On Tuesday 17 November 2026 the sales coordinator emails it to the bookkeeper, but autocomplete picks an outside supplier’s similar address.

1. Tuesday 17 November (day 0). At 5:15 pm the coordinator tells the director, the named decision-maker. Credible grounds exist, so the log starts. The director asks the recipient to delete the message unopened and confirm in writing, and asks the IT supplier about a recall.
2. Wednesday 18 November, morning. The recipient says it deleted the email unopened; the log records that as a statement, not proof. The director assesses: the recipient is outside the studio; 180 is under 500, so Test 2 is not met; but each row pairs a full name with a bank account number, so Test 1 is met. At 11:00 am the director determines the breach is notifiable and logs the time. The three-day window runs from Thursday 19 to Saturday 21 November, so on our reading the last day is a Saturday.
3. Wednesday 18 November, afternoon. The director submits PDPC’s notification rather than waiting: facts, steps taken in order, action to reduce harm and stop a repeat, the plan to tell customers, and a contact.
4. Thursday 19 November. After PDPC, the studio tells the 180 customers what happened, which data, the potential harm, what it has done, what they can do and who to call. It considers the remedial-action exception. In PDPC’s travel-agency example (1,000 customers’ details emailed to the wrong vendor) the vendor, contacted at once, confirmed that the attachment had not been accessed and that it had permanently deleted the email; the agency judged it could rely on the exception but still had to notify PDPC. The studio’s facts are close, but the exception depends on prescribed requirements we did not read and it holds only a written statement, so in this illustration it tells the customers anyway (the fictional studio’s choice, not PDPC’s view).
5. Afterwards (our suggestion). The log closes with the cause, the fix (a check before sending outside; password-protected files), an owner and a review date. Had the facts been unclear, 17 December (30 days after 17 November, by our count) was the marker to decide or be ready to explain the time taken to PDPC.

How would the answer change with a different file?

Same mistake, different file. These variants are our reading of PDPC’s examples, not PDPC cases.

• 620 customers, names, mobile numbers and delivery addresses. No prescribed data, but over 500: PDPC must be told within three calendar days. On the reasoning of PDPC’s 700-customer example, customers need not be.
• 40 customers, names and mobile numbers. Neither test is met, on the reasoning of PDPC’s examples of ten cyclists’ names and of customers’ names and contact details. You may tell PDPC voluntarily; the guide says PDPC may treat that as a mitigating factor. Record the assessment either way.

What goes in a one-page incident log?

The guide asks for an incident record log and documented assessment steps. This layout is ours:

• Incident and discovery (day 0): title, log owner, date, time, how you learnt of it.
• What happened: cause, whether it is ongoing, whether the recipient is inside or outside your organisation.
• Data: fields, number of individuals (or an estimate and its basis), whether public or encrypted beforehand.
• Containment: each action, who, when, and every reply.
• Tests 1 and 2: prescribed data; 500 or more. Each yes or no, with reasons.
• Determination: notifiable or not, who decided, date and time; if yes, the last day.
• PDPC: date, time, who submitted; reasons and evidence if late.
• Individuals: date, time and method, or the exception or instruction relied on.
• Others told: police, SingCERT, any sector regulator (telling one does not satisfy the PDPA), business clients.
• Evaluate: root cause, fix, owner, due and review dates.

How do you report a data breach to PDPC?

Use the e-service form linked from PDPC’s page on reporting a breach (last updated 22 April 2026); for urgent major cases the guide also gives +65 6377 3131 during working hours. A notification covers the facts, the handling and a contact (paragraph 20.38 of the guidelines). If the breach involves adoption information or identifies vulnerable people, tell PDPC first and ask for guidance on notifying them.

What should a small business set up before a breach?

PDPC’s guide says a response plan should explain what a breach is, how staff report one, how to respond and who is on the response team. This small-business version is ours:

• A decision-maker, a deputy, someone who can reach your IT supplier and whoever submits the PDPC form, with mobile numbers, written down.
• A paragraph telling staff what a breach is, including wrong-recipient emails and lost devices, and who to tell at once.
• The log above, saved where any manager can open it, and draft wording for customers.
• Breach-notice terms in supplier contracts.
• A walkthrough with the log; the guide encourages periodic exercises.

For AI tools, see the AI use policy template; for marketing messages, our Do Not Call guide. More compliance guides are under operations.

Common questions