Do we need to report a data breach? Deadline and notification steps

TL;DR — If personal data was exposed, accessed, altered, lost, or made unavailable, treat it as a potential personal data breach first and decide quickly whether it is likely to risk people’s rights and freedoms. The most common safe path is: record the facts immediately, identify what personal data was involved, decide whether the risk is unlikely / likely / high, then notify your privacy lead or legal contact and, if required, report to the regulator within 72 hours of becoming aware. Reading time: ~6 min

The scenario

It is 3:40 p.m. on a Tuesday. A client emails saying a customer received someone else’s invoice by mistake, and at the same time your cloud provider sends an alert that a storage bucket was publicly reachable for part of the morning. You are not sure whether this is a true breach, a near miss, or just a configuration issue that was fixed in time. The immediate question is not technical anymore: do you need to report it, by when, and who needs to be told?

Symptoms

• A user reports seeing another person’s data, for example: "I can see someone else’s order history" or "This attachment contains another customer’s address and phone number."
• Internal logs show unexpected access, for example:

GET /exports/customers.csv 200
GET /invoices/2026-10-30-accounts.pdf 200

• Your email system shows a message sent to the wrong recipient, for example:

Status: delivered
To: jane@example.com
Attachment: payroll-october.pdf

• A cloud audit log shows public access or unusual downloads, for example:

Anonymous access granted
ListBucket succeeded
GetObject succeeded

• A ransomware (malware that encrypts files) note appears, systems are unavailable, or backups are being restored.
• Staff say a laptop, phone, or USB drive containing customer data was lost or stolen.
• A database restore, deploy, or import overwrote records or exposed test data in production.

Likely causes

Step-by-step diagnosis

1. Start an incident record now Use your ticketing system or an internal document and write: time first noticed, who reported it, systems involved, and what personal data may be affected.

   This is your problem if you cannot answer "when did we become aware?" That timestamp matters because many laws and contracts measure the deadline from awareness, not from full root-cause analysis. If you have no record yet, create one now and continue to Step 2.

2. Confirm whether personal data is involved Check the affected screen, file, export, email, or database table. Look for names, email addresses, phone numbers, postal addresses, account IDs, IP addresses, payroll data, health data, or anything that can identify a person.

   This is your problem if the incident touches identifiable people. If no personal data is involved, jump to Fixes → Not a personal-data breach / document and close.

3. Work out what happened: confidentiality, integrity, or availability Use this quick test:

[Incident]
   |
   | 1. Someone else saw data?
   v
[Confidentiality loss]

[Incident]
   |
   | 2. Data changed incorrectly?
   v
[Integrity loss]

[Incident]
   |
   | 3. Data unavailable or encrypted?
   v
[Availability loss]

If any answer is yes, treat it as a personal data breach candidate and continue. If all are no, jump to Fixes → Not a personal-data breach / document and close.

1. Check whether the data was actually exposed or only potentially exposed

   • For email: review the sent message and recipient.
   • For cloud storage: open your provider dashboard and inspect object/bucket permissions and access logs.
   • For app bugs: reproduce with a normal user account.
   • For devices: check device-management status for encryption and wipe.

   This is your problem if you can confirm unauthorized access, disclosure, alteration, loss, or unavailability. If you cannot confirm but there is a credible possibility, keep treating it as a breach candidate and continue to Step 5.

2. Assess risk to people Ask four plain-language questions:

   • How sensitive is the data? (basic contact details vs payroll, health, ID documents)
   • How many people are affected?
   • Can the recipient or attacker identify the people easily?
   • Could this cause fraud, identity theft, embarrassment, discrimination, financial loss, or loss of confidentiality?

   Use this rule of thumb:

   • Unlikely risk: encrypted laptop lost, strong encryption keys not exposed; email recalled before delivery; test data with no real people.
   • Likely risk: wrong customer got another customer’s invoice with address and account details; public export of customer list; attacker accessed support tickets.
   • High risk: passport scans, payroll, health data, passwords, or vulnerable individuals exposed.

   If risk is likely or high, jump to the matching fix section. If risk is unlikely, jump to Fixes → Unlikely risk / document why you are not reporting.

3. Work out who is the controller and who is the processor A controller (the party deciding why/how personal data is used) usually reports to the regulator. A processor (the party handling data for the controller) usually notifies the controller without undue delay.

   Quick check: read the contract, data processing agreement, statement of work, or privacy annex. If your client decides the purpose of the data processing, they are usually the controller.

   This is your problem if you are a processor: jump to Fixes → You are a processor / notify the controller. If you are the controller, continue to Step 7.

4. Set the reporting deadline For many privacy regimes, including GDPR-style rules, the regulator deadline is within 72 hours of becoming aware of a reportable personal data breach.

   This is your problem if the breach is likely to risk people’s rights and freedoms. Set a calendar deadline now. If the risk is high, also prepare to notify affected individuals without undue delay. Jump to the relevant fix section below.

Fixes

Misdirected email or attachment sent to the wrong person

1. Contain it immediately:
   • In your mail admin, try message recall if your system supports it.
   • Contact the unintended recipient and ask for deletion and written confirmation.
2. Preserve evidence:

Record: sender, recipient, subject, attachment name, sent time, delivery status

1. Assess risk:
   • Basic invoice to an existing customer: often likely risk.
   • Payroll, health, ID docs: often high risk.
2. Notify the right party:
   • If you are a processor, notify the controller.
   • If you are the controller and risk is likely, prepare regulator notice within 72 hours.

Verify it worked: you have delivery evidence, recipient response status, and a documented risk decision in the incident record.

Access control bug exposed one user’s data to another

1. Stop exposure first.

⚠️ Disabling a route, feature, or account can cause user-facing downtime. Warn your support team before changing production access.

1. Use the fastest safe control:
   • In your app admin, disable the affected feature or export.
   • If needed, temporarily block the route in your reverse proxy.

location /reports/export {
    return 403;
}

1. Reproduce with a normal user account and capture the exact URL, user role, and record shown.
2. Check logs for scope:

GET /account/12345 200
GET /account/12346 200

1. If unauthorized data was visible, treat as a confidentiality breach and notify based on risk.

Verify it worked: the same normal user now gets 403 or only sees their own records.

Publicly exposed storage, backup, or export file

1. Remove public access in your provider dashboard.
   • Example path: your provider dashboard → Storage/Buckets → select bucket → Permissions/Access → disable public or anonymous access.
2. Rotate any exposed signed URLs or credentials if they were embedded near the files.
3. Review access logs for downloads during the exposure window.
4. If personal data was reachable and not strongly protected, assess as likely or high risk depending on sensitivity.

Verify it worked: opening the object URL without authentication now returns 403 Forbidden or equivalent access denied.

Lost or stolen device containing personal data

1. In your device-management dashboard, check whether full-disk encryption was enabled.
2. If available, trigger remote lock or wipe.
3. Revoke the user’s active sessions and reset passwords if local tokens or mail were accessible.
4. If the device was encrypted and keys were not exposed, risk may be unlikely; document why. If not encrypted, treat as likely or high risk depending on data stored locally.

Verify it worked: device status shows locked/wiped or last-seen disabled, and user sessions are revoked.

Data altered, deleted, or encrypted by attacker or mistake

1. Contain first: disable compromised accounts, isolate affected admin access, pause destructive jobs.
2. Check whether personal data became unavailable or was altered.
3. Restore from backup only after preserving evidence.

⚠️ Restoring data can overwrite newer records and cause downtime. Confirm the restore point and impact before proceeding.

1. If people could be harmed by incorrect or unavailable data, this can still be a reportable personal data breach even without public disclosure.

Verify it worked: service is restored, audit logs show no ongoing unauthorized changes, and affected records match the chosen restore point.

Processor/subprocessor incident at a vendor

1. Open the vendor notice or support ticket and capture:

What data was involved
Which customers/tenants were affected
When the vendor became aware
What containment is complete

1. If you are the controller, do not wait for perfect detail before starting your own 72-hour assessment.
2. If you are the processor, notify your controller customer according to the contract timeline.

Verify it worked: you have the vendor’s written statement attached to your incident record and your own notification sent.

You are a processor / notify the controller

Send a short factual notice immediately. Template:

Subject: Urgent: potential personal data breach affecting [system/client name]

We became aware at: [timestamp, timezone]
What happened: [plain description]
Data involved: [types of personal data]
People affected: [known/estimated number]
Containment taken: [actions]
Current risk view: [unlikely/likely/high, if known]
Next update by: [time]

Verify it worked: the controller has acknowledged receipt or you have delivery evidence and a follow-up time booked.

Likely risk / report to the regulator

Prepare the report with the facts you have now; you can supplement later. Include:

Nature of the breach
Categories and approximate number of people affected
Categories and approximate number of records affected
Likely consequences
Measures taken or proposed
Contact point for follow-up

Use your regulator’s breach-report form or portal in your jurisdiction.

Verify it worked: you have a submission receipt/reference number and the incident record shows the submission time within the deadline.

High risk / notify affected individuals

Notify people without undue delay in clear language. Include:

What happened
What data was involved
What the likely impact is
What you have done
What they should do now (reset password, watch for phishing, contact bank, etc.)
How to contact you

Do not hide behind legal jargon.

Verify it worked: notifications were sent to the affected population and support staff have a prepared response script.

Unlikely risk / document why you are not reporting

If you decide not to report, write down the reasoning:

Why the data was not accessible or intelligible
Why harm to individuals is unlikely
What evidence supports that view
Who approved the decision and when

Examples: encrypted device with keys protected; email blocked before delivery; inaccessible backup with no access logs showing retrieval.

Verify it worked: your incident record clearly shows the evidence and approval trail.

Not a personal-data breach / document and close

If no personal data was involved, close it as a security or operational incident, not a personal-data breach. Keep the evidence anyway.

Verify it worked: the record states "no personal data involved" with the exact system, dataset, and reviewer.

Prevention

• Add an incident template with mandatory fields so the 72-hour clock is captured consistently:

{
  "aware_at": "",
  "reported_by": "",
  "systems": [],
  "personal_data_types": [],
  "estimated_people_affected": 0,
  "controller_or_processor": "",
  "risk_level": "unlikely|likely|high",
  "next_update_at": ""
}

• Turn on audit logging for exports, downloads, and admin actions in your app and cloud storage. At minimum log actor, object, timestamp, and IP address.

{"event":"export_download","actor_id":"123","file":"customers.csv","ip":"203.0.113.10","ts":"2026-10-30T15:41:00Z"}

• Block public storage by policy in your cloud platform so buckets and objects cannot be made public accidentally. Use your provider’s organization/account policy controls for "block public access".
• Encrypt laptops and phones, and enroll them in device management with remote wipe enabled. Check this in your device dashboard before allowing access to customer data.
• Add a release check for authorization bugs in CI (continuous integration): run at least one test that a normal user cannot access another user’s record.

npm test -- access-control.spec.ts

• Prepare notification templates now for controller notice, regulator report, and customer notice so you are not drafting from scratch during the incident.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.