PDPA Data Breach: Your Business Has 3 Days to Respond. Here's Your Checklist.
A laptop containing customer information disappears. An employee's Microsoft 365 account is compromised.
A ransomware attack encrypts your server. A spreadsheet containing hundreds of customer records is accidentally sent to the wrong recipient.
What happens next?
For businesses in Singapore, a personal data breach is not simply an IT problem. It can also trigger obligations under the Personal Data Protection Act (PDPA).
And one deadline matters in particular: Once your organisation determines that a data breach is notifiable, you must notify Singapore's Personal Data Protection Commission (PDPC) as soon as practicable - and no later than three calendar days after the day you make that determination.
But there is an important distinction.
The three-day clock does not automatically start the moment an incident happens.
First, your organisation needs to investigate and assess whether the breach meets the criteria for mandatory notification. Here is what Singapore businesses should know - and what to do when every hour counts.
Quick Answer: What Should You Do After a PDPA Data Breach?
If you suspect that personal data has been compromised:
1. Contain the incident: Stop further unauthorised access or disclosure without unnecessarily destroying evidence.
2. Preserve evidence: Keep relevant logs, emails, system information, and records needed for investigation.
3. Determine what happened: Identify the systems, data, and individuals potentially affected.
4. Assess whether the breach is notifiable: Consider whether it is likely to result in significant harm to affected individuals and/or is of significant scale.
5. Notify the PDPC if required: Once you determine that the breach is notifiable, notify the PDPC as soon as practicable and no later than three calendar days after that determination.
6. Notify affected individuals where required.
7. Remediate the underlying weakness: Reset credentials, patch vulnerabilities, strengthen access controls and address the root cause.
8. Document everything.
That is the short version. The difficult part is doing it properly under pressure.
What Counts as a Data Breach Under Singapore's PDPA?
A data breach is broader than "a hacker stole our database."
It can involve unauthorised: access; collection; use; disclosure; copying; modification or disposal of personal data; or the loss of a storage medium or device containing personal data where unauthorised access or disclosure is likely.
That means a data breach can result from a cyberattack. But it can also result from human error.
Examples could include:
an employee emailing customer information to the wrong person;
a stolen laptop containing personal information;
a compromised Microsoft 365 account;
ransomware affecting HR records;
an exposed cloud storage folder;
an unauthorised person accessing customer records;
a former employee retaining inappropriate access;
information being disclosed through a misconfigured system; or
a third-party service provider experiencing a breach involving your organisation's data.
This is why data protection and cybersecurity overlap, but they are not identical. A security incident becomes a PDPA concern when personal data is involved.
The Most Important Misunderstanding: When Does the 3-Day Clock Start?
Many businesses hear: "You have three days to report a breach." That statement is incomplete. Under Singapore's Data Breach Notification Obligation, the three-calendar-day deadline applies after your organisation determines that the data breach is notifiable.
For example:
Monday: Your company discovers suspicious access to a server.
Tuesday: Your IT team investigates the affected systems and begins identifying the information involved.
Wednesday: The investigation establishes enough facts for your organisation to determine that the breach meets the mandatory notification criteria.
The three-day notification period relates to the determination that the breach is notifiable — not simply the original date of the cyber incident. However, this does not mean a business can delay the investigation to postpone the deadline.
Once your organisation has reason to believe that a personal data breach has occurred, it must conduct its assessment in a reasonable and expeditious manner.
PDPC guidance states that organisations should generally aim to complete the assessment within 30 calendar days. If an organisation cannot do so, it should be prepared to explain why.
So there are effectively two important timeframes to understand:
Calendar days include weekends and public holidays.
When Is a Data Breach Notifiable in Singapore?
Not every data breach must be reported to the PDPC. A breach generally becomes notifiable when it:
1. Is likely to result in significant harm to affected individuals
2. Is of significant scale.
Under the current framework, a breach involving the personal data of 500 or more individuals is considered significant in scale. The 500-person threshold can be based on the actual number affected or an estimate from a preliminary assessment. A breach involving fewer than 500 people may still be notifiable if the information involved is likely to cause significant harm.
What Does "Significant Harm" Mean?
This is where businesses need to look beyond the number of records. Imagine two incidents.
Incident A: An email list containing 600 customers' basic information is accidentally exposed.
Incident B: Sensitive information relating to 20 individuals is compromised.
Incident B involves fewer people, but the nature of the information may create a greater risk to those individuals. Certain prescribed categories or combinations of personal data are considered particularly sensitive for assessing significant harm.
That is why businesses should not use: "It only affected a few people." as the sole basis for deciding that a breach does not need to be reported.
The type of information matters.
Your First 24 Hours: Contain First, Panic Never
Imagine arriving at work at 9:00 AM. Employees cannot access the shared server. Files have unusual extensions. A message appears demanding payment.
Your first instinct might be: "Get everything working again."
Recovery is important.
But immediately wiping computers, reinstalling systems or deleting suspicious files could remove information needed to understand what happened. Your initial priorities should include:
Isolate affected systems: Prevent the incident from spreading where possible.
Secure compromised accounts: Disable or restrict accounts believed to be compromised and take appropriate credential-security measures.
Preserve evidence: Maintain relevant logs, emails, system records and other information that may help determine the cause and scope.
Establish an incident team: Depending on the business, this could include: management, Data Protection Officer (DPO), IT team or managed IT provider, legal advisers, cybersecurity specialists, communications personnel; and relevant vendors.
Start an incident timeline
Document:
What happened?
When was it discovered?
Who discovered it?
Which systems were affected?
What actions have been taken?
Who authorised those actions?
During a serious breach, memories become unreliable very quickly. Write it down.
The PDPA Data Breach Response Checklist
Use this as a practical starting point if your Singapore business suspects a personal data breach.
-
☐ Activate your incident-response process.
☐ Inform your DPO or responsible management personnel.
☐ Identify potentially affected systems.
☐ Isolate affected devices or systems where appropriate.
☐ Secure compromised accounts.
☐ Preserve logs and other relevant evidence.
☐ Record the discovery time and circumstances.
☐ Contact your IT or cybersecurity provider where necessary.
☐ Avoid making assumptions about the scale before investigating.
-
☐ Determine how the incident occurred.
☐ Identify the systems affected.
☐ Identify what personal data may have been accessed, disclosed, lost or altered.
☐ Estimate how many individuals may be affected.
☐ Identify whether sensitive categories of information are involved.
☐ Determine whether the information was encrypted or otherwise protected.
☐ Identify whether information may have been exfiltrated.
☐ Determine whether the attacker or unauthorised party still has access.
☐ Review relevant system, firewall, endpoint and cloud logs.
☐ Identify third-party vendors involved.
-
Ask: Is the breach likely to cause significant harm to affected individuals? Does it affect 500 or more individuals?
☐ Document your assessment.
☐ Record the date on which the organisation determines whether the breach is notifiable.
☐ Escalate uncertain legal or regulatory questions to appropriate professional advisers.
If the breach is determined to be notifiable: the three-calendar-day PDPC notification deadline begins from the day after that determination.
-
Where notification is required, the organisation must notify the PDPC as soon as practicable and no later than three calendar days after determining that the breach is notifiable.
The notification should provide relevant information available to the organisation about the breach and its response.
Your incident records become extremely valuable here.
You should already be documenting:
when the breach occurred or was discovered;
how it was discovered;
what systems were affected;
the types of personal data involved;
the estimated number of individuals affected;
potential consequences;
containment actions;
remediation measures; and
the organisation's response plan.
Do not wait until the notification deadline to reconstruct the incident from memory.
-
A requirement to notify the PDPC does not automatically mean every affected individual must always be notified.
Where notification to affected individuals is required, they should be informed as soon as practicable, at the same time as or after the PDPC is notified.
The communication should help affected individuals understand the incident and what they can do to protect themselves.
Depending on the breach, practical steps might include monitoring accounts, changing credentials or being alert to impersonation attempts.
The communication should be factual.
Avoid speculation.
Avoid minimising the incident.
And avoid sending a vague message that leaves customers wondering what information was actually affected.
What If the Breach Happened at Your IT Vendor?
Outsourcing IT does not mean outsourcing all responsibility for personal data.
Suppose your payroll provider, cloud application, IT provider or another data intermediary detects a breach involving personal data processed on your behalf. Under the PDPA framework, a data intermediary that has reason to believe a breach occurred must notify the organisation for which it processes the data without undue delay.
The organisation can then assess whether the breach is notifiable. This is why vendor contracts and incident-response procedures matter.
Before an incident happens, your business should know:
which vendors process personal data;
what information they hold;
who they contact during an incident;
how quickly they will notify you;
what evidence they can provide;
who investigates;
and who is responsible for regulatory assessment and notification.
If nobody knows the answers until a breach occurs, valuable time will be lost.
A Real Singapore Ransomware Case: What Businesses Can Learn
A recent PDPC case provides a useful example of why basic security controls matter. A ransomware attack affected systems belonging to Lian Beng Group subsidiaries and compromised files containing personal data belonging to 5,001 current and former employees.
The affected information included items such as names, bank account information, addresses, contact information and identity-document details.
PDPC's published account states that the threat actor likely obtained access through a brute-force attack.
The case also identified security weaknesses including the absence of Multi-Factor Authentication for remote VPN access and unpatched systems with vulnerabilities, including systems that had reached or were approaching end of life.
Following the incident, remediation included rebuilding systems, enforcing MFA for critical systems and VPN access, security testing and additional infrastructure protection. The lesson for an SME is straightforward: A data breach response plan matters. But preventing avoidable weaknesses matters just as much.
Microsoft 365 Compromise: A Common SME Scenario
Consider a hypothetical 30-person Singapore professional-services company. A finance employee receives a convincing Microsoft 365 login request. The employee enters their credentials.
An attacker gains access to the mailbox and begins reviewing conversations containing:
customer names;
invoices;
supplier information;
contracts; and
contact information.
The attacker also creates a mailbox forwarding rule. Three days later, the employee notices unusual activity.
What should the company do? Not simply: Change the password and move on. The company needs to investigate questions such as:
When did unauthorised access begin?
Which emails were accessed?
Were attachments downloaded?
What personal data was contained in the mailbox?
Were other accounts compromised?
Were forwarding rules created?
Were fraudulent messages sent?
How many individuals may be affected?
Is the breach likely to cause significant harm?
Does it meet the threshold for mandatory notification?
Changing the password helps contain the incident. It does not answer the PDPA questions.
Where Advance IT Fits Into PDPA Data Breach Readiness
Legal responsibility for PDPA compliance remains with the organisation. Your IT provider should not pretend to replace your DPO, legal advisers or management. But many of the facts needed to assess and respond to a cyber-related data breach come from your IT environment.
For example:
Which account was compromised?
When was it accessed?
Which endpoint was involved?
What did the firewall record?
Was MFA enabled?
Were files downloaded?
When was the device patched?
Was the backup successful?
Can the affected system be isolated?
Can operations be restored?
This is where A Managed IT Partner can become part of your incident-response capability. Advance IT supports Singapore SMEs with areas including: Microsoft 365 administration and security, endpoint protection, user-access management, infrastructure monitoring, firewall and network management, patch management, backup and recovery, remote and onsite troubleshooting, IT documentation; and infrastructure assessments.
The goal is not only to help when an incident happens. It is to make sure your IT environment is better prepared before one happens.
10 Questions to Ask Your IT Provider Before a Data Breach
Do not wait for ransomware to discover that nobody knows who is responsible for what.
Ask your IT provider:
If we suspect a breach, who do we contact?
How quickly can compromised accounts be disabled?
Can you retrieve the logs needed to investigate an incident?
How long are our important logs retained?
Is MFA enabled on our critical accounts and remote access?
How are administrator privileges controlled?
Are our operating systems and network devices actively patched?
Are our backups monitored and restoration-tested?
Do we have unsupported or end-of-life systems?
What would happen technically if ransomware affected us tomorrow?
If these questions cannot be answered clearly, your organisation has already identified something worth reviewing.
PDPA Data Breach: What Not to Do
During a breach, avoid these common mistakes. Don't wait for perfect information. Investigation takes time. Begin containment, documentation, and assessment immediately.
Don't destroy evidence in the rush to restore systems: Recovery matters, but so does understanding what happened.
Don't assume "no ransomware = no data breach": Unauthorised access or disclosure of personal information can occur without ransomware.
Don't assume "fewer than 500 people = no notification": The nature of the compromised information and potential for significant harm also matter.
Don't assume your IT vendor handles PDPC notification automatically: Technical incident response and regulatory responsibility are different functions.
Don't delay deciding who owns the incident: Your DPO, management, IT team, and relevant professional advisers should have defined responsibilities before an emergency.
PDPA Data Breach FAQ
-
Once an organisation determines that a data breach is notifiable, it must notify the PDPC as soon as practicable and no later than three calendar days after the day it makes that determination.
The three-day deadline does not automatically begin when the incident first occurs.
-
No. Mandatory notification generally applies when a breach is likely to result in significant harm to affected individuals and/or is of significant scale.
-
Under the current notification framework, a breach involving the personal data of 500 or more individuals is considered significant in scale.
-
The breach may still be notifiable if it is likely to result in significant harm to affected individuals.
The sensitivity and nature of the compromised data therefore matter.
-
Once an organisation has reason to believe a data breach occurred, it must assess it in a reasonable and expeditious manner.
PDPC guidance states that organisations should generally aim to complete the assessment within 30 calendar days. An organisation taking longer should be prepared to explain the delay.
-
Yes. The notification period is measured in calendar days, not business days.
-
The first day starts on the day after the organisation determines that the breach is notifiable.
For example, if the determination is made on 1 January, notification must be made by 4 January.
-
Where notification to affected individuals is required, the organisation should notify them as soon as practicable, at the same time as or after notifying the PDPC.
-
This depends on the organisation, but response commonly involves management, the DPO, IT or cybersecurity personnel and, where appropriate, legal or other professional advisers.
The responsibilities should be agreed before an incident happens.
-
No IT provider can guarantee PDPA compliance simply by installing cybersecurity products.
An IT provider can support the technical side of data protection - such as security controls, access management, backups, logging, patching and incident response - while the organisation remains responsible for its broader legal, organisational and data-protection obligations.
This article provides general information about cybersecurity and Singapore's PDPA. It is not legal advice. Organisations should refer to current PDPC guidance and seek appropriate professional advice when assessing specific data breaches.
Is Your Business Ready Before the Clock Starts?
Advance IT helps Singapore SMEs manage the technical side of cybersecurity and IT resilience - from Microsoft 365 and endpoint security to networks, patching, backups and recovery. If your business does not have an internal IT department, our team can review your current environment, identify technical gaps and help build a practical roadmap around your business.
Don't start with more software. Start by understanding your risks.
Book a 30-Minute IT Consultation
Talk to Advance IT about your current IT environment, cybersecurity controls, backup and recovery readiness, and the technical gaps that could make a future data breach harder to contain.
····························································
With over 15 years of experience and a strong focus on IT support and Managed IT, we’re proud that 99.5% of our customers stay with us long-term.
‣ Website: https://www.advanceit.sg/
‣ Address: 8 Burn Road, #11-11 Trivex Singapore 369977
‣ Email us at: contact@advanceit.sg
‣ Call our team: +65 6592 8458
Is your Singapore clinic ready for the Health Information Act? Learn the 2027 HIA deadline, NEHR requirements, cybersecurity rules and practical steps private clinics should take now.