Customer receives another customer's data

Your preparation

0 of 0 safeguards ready

What this means

Treat this as a personal data incident until you prove otherwise.

The first report may mention one file and one recipient. The real problem can be wider. The same export job may have run for other customers. A download link may have been opened more than once. A support attachment may have been forwarded. A cache may have served the same file to several accounts.

Your job is to answer four questions:

What data left the correct customer boundary?
Who could receive or open it?
What harm could the data cause?
Has the same failure happened anywhere else?

Do not promise that the incident is contained before you can answer those questions.

If the data includes passwords, authentication tokens, payment information, government identifiers, health information, information about children, private communications, or other highly sensitive data, contact qualified security and privacy counsel immediately.

Warning signs

A customer sees another person, company, invoice, order, or account in an export.
A generated filename contains the wrong customer name or tenant ID.
The export request belongs to one tenant, but the output rows belong to another.
A download link works after the intended user signs out.
A support agent attaches a file from the wrong conversation.
A background job uses tenant context from a previous job.
Two customers receive files with the same object-storage key.
A cache key contains an export ID but no tenant ID.
An administrator can generate exports without selecting or confirming the customer.
Export logs record the request but not the resolved tenant, file, recipient, or download.

Recover now

First 15 minutes

Open an incident record and start a UTC timeline. Record who reported the problem, the exact discovery time, the affected customer, the unintended recipient, the file or link, and every action you take. This establishes the investigation record and helps track legal deadlines.
Disable the smallest unsafe path. Pause the affected export type, report template, support macro, attachment workflow, or download route. If you cannot isolate it safely, disable all customer exports temporarily. Confirm a fresh request can no longer produce or retrieve a file.
Expire access without destroying evidence. Revoke signed URLs, sharing tokens, CDN links, and application download sessions. Remove public access from the object. Do not delete the only copy, job record, or access log. Move the affected artifact to a restricted evidence location when necessary.
Preserve the original artifact securely. Save the exact file, filename, object key, export ID, request ID, template version, code version, and a cryptographic hash. Restrict this evidence to the incident team. Do not paste customer data into chat, tickets, or screenshots.
Preserve logs before retention removes them. Protect application, job queue, database, object storage, CDN, email, support, identity, and audit logs covering the likely exposure window. Record time zones and known clock differences.
Contact the unintended recipient through a trusted channel. Ask them not to open, use, copy, or forward the data. Ask whether they downloaded, viewed, printed, synced, or shared it. Request secure deletion from downloads, email, trash, synced folders, and backups they control. Their confirmation reduces uncertainty; it does not erase the fact that disclosure occurred.
Notify the incident owner and privacy decision-maker. Start the legal and contractual review now. Some laws start notification clocks when the organization becomes aware of a breach, not when the investigation finishes.

Build the scope table

Create one row for every known or suspected disclosure:

Field	What to record
Request	Request ID, user, intended tenant, time, IP, session
Resolution	Tenant and customer IDs actually used by the query
Artifact	Export ID, object key, filename, hash, row count
Data	Fields included, sensitivity, date range, number of people
Delivery	Email, support ticket, browser download, API, shared link
Recipient	Intended recipient and actual recipient
Access	Created, sent, delivered, opened, downloaded, forwarded
Containment	Link expired, object restricted, recipient contacted
Evidence	Log locations and retention deadlines

Do not collapse “sent,” “delivered,” “opened,” and “downloaded” into one status. They mean different things.

Today

Find the first possible bad export. Start with the last known-good code, template, query, cache, support process, or worker deployment. Expand the search earlier if the defect may have existed before that point.
Search for every affected execution. Query export jobs by template version, code version, worker release, query name, storage prefix, recipient domain, and mismatch between requested and resolved tenant IDs. Include failed and retried jobs.
Trace every copy. Follow the artifact into object storage, CDN caches, email attachments, support tickets, browser downloads, audit exports, backups, analytics events, and employee devices. Record which copies you can revoke and which require recipient action.
Determine whether the recipient accessed the data. Use delivery, open, download, CDN, and object-access logs where available. Be precise:
- “We found no download event in retained logs” is supportable.
- “Nobody accessed the file” is not supportable when logs are missing.
Classify the exposed data. List the exact fields. Do not write “customer information.” Separate names, email addresses, billing history, support conversations, credentials, financial information, health data, identifiers, and private files.
Count people and organizations separately. One export sent to one company can still contain data about thousands of people.
Identify the failure mode. Common causes include:
- a query missing tenant_id;
- tenant context taken from the request body instead of the authenticated identity;
- a cache key shared across tenants;
- a storage object key reused by another export;
- a signed URL that checks possession but not current authorization;
- a background worker reusing stale context;
- an administrator choosing the wrong customer;
- a support agent attaching the wrong local file.
Fix the failure in a controlled environment. Add the tenant boundary at the lowest reliable layer. A UI check is not enough. The database query, repository, storage path, cache key, and download handler must all enforce the correct customer context.
Test old links after the fix. Verify the application, CDN, object store, and direct URL all reject revoked artifacts. Test in a signed-out browser and as a user from another tenant.
Make the notification decision with qualified advice. Consider applicable privacy law, contracts, data-processing agreements, insurance requirements, industry rules, and customer commitments. You may need to notify a regulator, affected customer, affected individuals, insurer, payment provider, or another business.

Assess likely harm

Use this table to structure the decision. It is not a substitute for legal advice.

Factor	Lower-risk evidence	Higher-risk evidence
Recipient	Known recipient, reported the mistake, cooperates	Unknown, hostile, unresponsive, or many recipients
Access	Delivery failed or logs prove no retrieval	Opened, downloaded, forwarded, or access unknown
Protection	Strong encryption and key remained separate	Plaintext, weak password, key sent with file
Data	Limited business contact data	Credentials, finance, health, children, identity documents
Volume	Few records and fields	Many people, long history, complete profiles
Harm	Little practical misuse available	Fraud, discrimination, identity theft, account takeover
Containment	Every link revoked and copy deleted	Cached, indexed, forwarded, or copies cannot be located

Which regulator you owe a notification to, and how long you have, depends on where you and the affected people are.

Reporting a data breach to the regulator

Most data protection regimes give you around 72 hours from becoming aware of a breach to notify the regulator. Find your national authority and its notification form before you need it.

Everywhere in the EU and EEA

The GDPR is a regulation rather than a directive, so the wording below is identical in all thirty countries. You have 72 hours from realising a breach happened, and that clock does not pause while you work out the details.

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Easy to get wrong. Treating the 72 hours as time to finish investigating. A partial, honest report on day one complies; a complete one on day five does not. The related error is thinking that telling the regulator discharges the duty to tell the individuals — Articles 33 and 34 are separate obligations with different thresholds, one at "a risk" and the other at "a high risk".

Your regulator is Österreichische Datenschutzbehörde.

We have not checked the local mechanics for Austria yet, so only the rules that apply bloc-wide are shown above.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is Autorité de la protection des données.

We have not checked the local mechanics for Belgium yet, so only the rules that apply bloc-wide are shown above.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is the Commission for Personal Data Protection.

We have not checked the local mechanics for Bulgaria yet, so only the rules that apply bloc-wide are shown above.

Your regulator is the Office of the Privacy Commissioner of Canada.

Under PIPEDA you report to the Privacy Commissioner whenever a breach creates a real risk of significant harm, notify the people affected, and keep a record of every breach whether or not you reported it.

Contain it, then assess real risk of significant harm on the two statutory factors: how sensitive the information is, and how likely it is to be misused. The OPC has a self-assessment tool.
If the threshold is met, report through the OPC's secure online form.
Include the cause, when it happened, what information was involved, how many people, what you have done to reduce harm, and a contact person.
Notify affected individuals directly and conspicuously, as soon as feasible, telling them what they can do to mitigate.
Tell anyone else who could reduce the harm, such as law enforcement or your payment processor.
Record every breach, reportable or not, and keep the records for two years.
If you operate in Quebec, notify the Commission d'accès à l'information separately under Law 25 and keep its own register.

Bring

For each breach record: the date, a description of the circumstances, the nature of the information, and whether you reported it
Where you decided not to report, your written reasoning for concluding there was no real risk of significant harm

Easy to get wrong. Organisations treat the real-risk threshold as the trigger for all their obligations when it only triggers two of the three. Record-keeping is unconditional: you must log every breach including those you assessed and chose not to report, keep it two years, and hand it over if the OPC asks — so your reasoning for not reporting is itself a required compliance artefact. A business that quietly resolved a small incident with no paperwork has already breached PIPEDA regardless of whether the incident was reportable. Note too that there is no numeric floor, so a breach affecting one person is reportable if the risk is real, and outsourcing to a processor does not move the duty off you.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is Agencija za zaštitu osobnih podataka.

We have not checked the local mechanics for Croatia yet, so only the rules that apply bloc-wide are shown above.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is the Office of the Commissioner for Personal Data Protection.

We have not checked the local mechanics for Cyprus yet, so only the rules that apply bloc-wide are shown above.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is Úřad pro ochranu osobních údajů.

We have not checked the local mechanics for Czechia yet, so only the rules that apply bloc-wide are shown above.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is Datatilsynet.

We have not checked the local mechanics for Denmark yet, so only the rules that apply bloc-wide are shown above.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is Andmekaitse Inspektsioon.

We have not checked the local mechanics for Estonia yet, so only the rules that apply bloc-wide are shown above.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is the Office of the Data Protection Ombudsman.

We have not checked the local mechanics for Finland yet, so only the rules that apply bloc-wide are shown above.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is Commission Nationale de l'Informatique et des Libertés (CNIL).

In France

The CNIL takes the notification, and the 72-hour clock starts when you have a reasonable degree of certainty that personal data was affected, not at the moment of the incident.

Contain the incident and establish its nature. During genuine preliminary investigation you are not yet considered aware.
Assess the risk as none, some, or high. That single judgement drives everything else.
Log it in your registre des violations in all three cases, including your reasoning if you decide not to notify.
Notify through the CNIL téléservice within 72 hours, filing an initial notification and completing it later if needed.
If the risk is high, tell the affected people too, in clear terms. CNIL's own advice is that when in doubt you notify and let them tell you.

Easy to get wrong. For cross-border processing the CNIL may not be your regulator at all. It states plainly that the lead supervisory authority is the single point of contact and is not necessarily the CNIL, even where the breach affects people living in France and even where it happened on French soil. A company whose main EU establishment is elsewhere and which reflexively notifies Paris has notified the wrong authority. Missing 72 hours also does not excuse you: you still notify, and state the reasons for the delay in the form.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is the data protection authority of your Bundesland.

In Germany

Germany has no single national regulator for the private sector. Supervision of private companies is devolved to an authority in each Bundesland, while the federal BfDI covers public bodies and telecoms providers.

Establish that you are a private body. Under § 40(1) BDSG, state authorities supervise data protection at private bodies, so the BfDI is not your regulator in the ordinary case.
Check whether you are an exception. § 9(1) BDSG puts federal public bodies and companies commercially providing telecommunications services under the BfDI.
Identify your state authority by establishment. With several German sites, § 40(2) BDSG applies the GDPR main-establishment test to fix which single authority is competent.
Notify within 72 hours using that authority's own online form, since each state runs its own.
If the breach is likely to be high risk, tell the affected individuals as well.

Easy to get wrong. Outsiders look for "the German DPA", find the BfDI because it is federal and the most visible in English, and file there. For a normal private company the BfDI is not competent, and filing with the wrong authority burns the 72-hour clock while you find out. Companies with sites in several Länder cannot simply pick one either: the main-establishment test decides it for you.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is the Hellenic Data Protection Authority.

We have not checked the local mechanics for Greece yet, so only the rules that apply bloc-wide are shown above.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is Nemzeti Adatvédelmi és Információszabadság Hatóság.

We have not checked the local mechanics for Hungary yet, so only the rules that apply bloc-wide are shown above.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is Persónuvernd.

We have not checked the local mechanics for Iceland yet, so only the rules that apply bloc-wide are shown above.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is the Data Protection Commission.

We have not checked the local mechanics for Ireland yet, so only the rules that apply bloc-wide are shown above.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is Garante per la protezione dei dati personali.

We have not checked the local mechanics for Italy yet, so only the rules that apply bloc-wide are shown above.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is Datu valsts inspekcija.

We have not checked the local mechanics for Latvia yet, so only the rules that apply bloc-wide are shown above.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is Datenschutzstelle.

We have not checked the local mechanics for Liechtenstein yet, so only the rules that apply bloc-wide are shown above.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is Valstybinė duomenų apsaugos inspekcija.

We have not checked the local mechanics for Lithuania yet, so only the rules that apply bloc-wide are shown above.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is Commission Nationale pour la Protection des Données.

We have not checked the local mechanics for Luxembourg yet, so only the rules that apply bloc-wide are shown above.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is the Office of the Information and Data Protection Commissioner.

We have not checked the local mechanics for Malta yet, so only the rules that apply bloc-wide are shown above.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is Autoriteit Persoonsgegevens.

In Netherlands

The Autoriteit Persoonsgegevens takes breach reports only through its online Meldformulier datalekken. It will not accept one by phone, post, or email.

Investigate straight away to establish whether this is actually a breach. The clock starts at kennisname, when you can be reasonably certain personal data was compromised, not at first suspicion.
Assess the risk against the AP's factors: nature of the breach, sensitivity and volume, how easily people can be identified, and how severe the consequences are. If in doubt, their advice is to report.
Submit the form within 72 hours. For something complex like ransomware, file the provisional report inside 72 hours and follow with a vervolgmelding.
Save or print the confirmation immediately, because you cannot view the report again and you need the meldingsnummer to amend or withdraw it.
Tell the victims if the risk to them is high. If you decide not to, you must say so in the report and give reasons.

Easy to get wrong. "It happened over the weekend" will not fly. The AP names the excuses it rejects outright: weekend, holiday, illness, and being busy. It also rejects "the DPO was told too late", since a DPO can never be responsible for the timeliness of a notification, and you cannot report a breach to your own DPO instead of the regulator. One reassurance in the other direction: the AP usually sends no reply at all, and silence means your report was fine.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is Datatilsynet.

We have not checked the local mechanics for Norway yet, so only the rules that apply bloc-wide are shown above.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is Urząd Ochrony Danych Osobowych.

We have not checked the local mechanics for Poland yet, so only the rules that apply bloc-wide are shown above.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is Comissão Nacional de Proteção de Dados.

We have not checked the local mechanics for Portugal yet, so only the rules that apply bloc-wide are shown above.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is Autoritatea Naţională de Supraveghere a Prelucrării Datelor cu Caracter Personal.

We have not checked the local mechanics for Romania yet, so only the rules that apply bloc-wide are shown above.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is Úrad na ochranu osobných údajov.

We have not checked the local mechanics for Slovakia yet, so only the rules that apply bloc-wide are shown above.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is the Information Commissioner.

We have not checked the local mechanics for Slovenia yet, so only the rules that apply bloc-wide are shown above.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is Agencia Española de Protección de Datos (AEPD).

In Spain

The AEPD accepts breach notifications only through the electronic form on its Sede Electrónica, and you will need a recognised certificate, DNIe, or Cl@ve Permanente to sign it.

Assess the risk. The AEPD publishes a tool called ASESORA BRECHA specifically to support that judgement.
Notify within 72 hours of becoming aware if there is a risk to people's rights, filing an initial notification and modifying it later if you lack detail.
Sign with DNIe or a digital certificate, which needs the Autofirm@ application at version 1.7.2 or higher.
If the risk is high, tell the affected people as well. The Comunica-Brecha RGPD tool helps decide that.
If you conclude there is no risk and do not notify, document the breach anyway so the AEPD can verify your reasoning.

Bring

Electronic certificate, DNIe, or Cl@ve Permanente belonging to an authorised representative
Autofirm@ 1.7.2 or newer installed

Easy to get wrong. Treating notification as self-incrimination and stalling while lawyers argue. The AEPD says directly that notifying does not necessarily open proceedings and that doing it properly evidences your diligence, while failing to notify is itself an infringement. Organisations that run past 72 hours debating whether to report convert a possibly clean incident into a certain breach.

Everywhere in the EU and EEA

Fix the moment you became aware, because that is when the clock starts. Not when the breach happened, and not when your investigation finishes.
Judge the risk to people, not to the business. Notification is the default, and you skip it only where the breach is unlikely to put anyone's rights at risk.
Notify the supervisory authority within 72 hours with what you have: the nature of the breach, rough numbers of people and records, your contact point, likely consequences, and what you are doing about it.
File partial rather than late. Article 33(4) explicitly allows reporting in phases, so an incomplete report on day one beats a complete one on day five.
Decide separately whether to tell the people affected. That is a different and higher test, and clearing the first says nothing about the second.
Write up every breach internally, including the ones you decide not to report, with your reasoning.

72 hours from awareness to notify the supervisory authority (Article 33(1)), unless the breach is unlikely to result in a risk to people.
Still notify if you miss it, with reasons for the delay attached (Article 33(1)).
Tell the affected people without undue delay where the breach is likely to be a high risk to them (Article 34(1)).
A processor tells its controller without undue delay (Article 33(2)). The 72 hours is the controller's deadline, not the processor's.

Your regulator is Integritetsskyddsmyndigheten.

We have not checked the local mechanics for Sweden yet, so only the rules that apply bloc-wide are shown above.

Your regulator is the Information Commissioner's Office (ICO).

The ICO wants notification within 72 hours of becoming aware, but only where the breach is likely to risk people's rights. Every breach goes on your internal record either way.

Contain it and assess the risk to the individuals affected, not to the business. The ICO has a self-assessment tool that takes about five minutes.
If a risk to people is likely, notify within 72 hours of awareness, and give reasons if you take longer.
Report through the ICO's online form. It takes around 30 minutes and cannot be saved partway, so gather details first.
Submit what you know and follow up. The ICO's guidance is to report early and update later.
If the risk is high, tell the affected individuals directly, in plain language, including what they should do about it.
Record the facts and your reasoning for every breach, including the ones you decided not to report.

Cost

No fee to report. Failing to notify a notifiable breach can attract up to £8.7 million or 2% of global turnover

Easy to get wrong. The 72 hours runs from awareness, not from finishing your investigation, and organisations routinely blow it waiting for the full picture. A partial report on time complies; a complete one late does not. The mirror error is over-reporting, since notification is only required where risk to individuals is likely — but either way you must write the decision down, because "we judged it low risk" is only a defence if it was recorded at the time. Two sector traps: communications providers report under PECR on a different form, and UK trust service providers have 24 hours under eIDAS rather than 72.

There is no single federal breach regulator. Every state plus DC and the territories has its own notification statute, and which ones apply is decided by where the affected people live, not where your company sits.

Secure operations and preserve evidence. Take affected machines offline but do not power them down before forensics arrive.
Work out which state laws apply from the residency of every affected individual, and get counsel involved: content requirements differ by state.
Notify the relevant state Attorney General where required. California wants a sample of the notice whenever more than 500 California residents are involved.
If health data is in scope, establish which regime applies. HIPAA entities notify HHS; health apps that are not HIPAA entities fall under the FTC's Health Breach Notification Rule instead.
If the company is an SEC registrant, file Form 8-K Item 1.05, generally within four business days of judging the incident material.

Cost

HHS: notify individuals within 60 days of discovery; notify HHS within 60 days if 500 or more people are affected, otherwise annually

Easy to get wrong. Companies scope the obligation to their own state and get it badly wrong. The trigger is the residency of each affected person, so one breach of a national customer list can activate fifty-odd statutes at once, with different thresholds and different content rules. The second common miss is assuming health data is only a HIPAA problem: if you are a health app and not a covered entity, you are not exempt, you just report to the FTC instead.

Communicate with the unintended recipient

Use a message like this after confirming the correct contact:

We sent you a file that was not intended for your organization. Please do not open, use, copy, or forward it.

If you already opened or downloaded it, tell us which actions you took. Please delete every copy you control, including downloads, email attachments, trash, and synced folders, then confirm deletion in writing.

We have disabled the original link. Reply to [incident contact] or call [number] if you need help.

Do not send another copy of the exposed data to identify it. Use the filename, delivery time, and message subject.

Communicate with the affected customer

Have privacy counsel review the message when legal duties may apply. A useful notice answers:

What happened?
When did it happen and when did you discover it?
What exact data was involved?
Who received or could access it?
What have you confirmed about access?
What did you do to contain it?
What should the customer or individual do now?
When is the next update?
Who can answer questions?

Separate facts from unknowns. Say “we are still determining whether the file was downloaded” instead of filling the gap with reassurance.

Verify recovery

A user from Tenant A cannot request, list, download, or infer an export belonging to Tenant B.
Export queries include the authenticated tenant at the data-access layer.
Cache keys include tenant and authorization-relevant context.
Storage paths cannot collide across tenants.
Signed links expire, cannot be reused after revocation, and do not bypass current authorization where current authorization is required.
Background workers receive immutable tenant context per job and clear it before the next job.
Old links fail at the application, CDN, and object-storage layers.
The affected export template works for authorized users.
Replayed and retried jobs do not send duplicate files.
Every suspected execution has a documented outcome.
Every exposed data field, person, organization, and recipient is counted or explicitly marked unknown.
Legal, contractual, insurance, regulator, customer, and individual notification decisions are recorded with an owner and deadline.
Monitoring covers tenant mismatches, unusual export volume, repeated downloads, and authorization failures.

After recovery

Write an incident report while the details are fresh. Include:

the detection source and timeline;
the first and last affected execution;
the root cause and contributing controls that failed;
every affected tenant, person, artifact, and recipient;
evidence that reduced or increased likely harm;
containment and deletion confirmations;
notification decisions and copies of notices;
the permanent technical fix;
tests added;
owners and dates for remaining work.

Keep the report and breach decision record for the period required by your laws, contracts, and internal policy.

Prepare now

Tenant isolation

The backend derives tenant_id from the authenticated identity or trusted server context, never from an untrusted request field.
Every export query filters by tenant at the shared data-access layer.
Database row-level security or an equivalent second control protects the highest-risk tenant tables.
Cache keys include tenant ID, user authorization scope, export version, and relevant parameters.
Object-storage paths include a non-guessable tenant namespace and unique artifact ID.
Every download request verifies the current user’s access to the export.
Administrative cross-tenant access is explicit, time-limited where possible, and logged.

Export safety

The confirmation screen shows customer name, tenant ID, record count, date range, fields, and recipient before generation or delivery.
High-risk exports require a second confirmation or reviewer.
Generated files use unique names and cannot overwrite another customer’s artifact.
Links have short expiry, can be revoked, and are never written to analytics or referrer logs.
Email delivery is separate from file generation, so the recipient can be rechecked before sending.
Support agents attach files from a controlled picker, not an unrestricted local file chooser.
Test and staging exports contain generated data rather than copied production records.

Evidence and detection

Each export records request ID, authenticated user, intended tenant, resolved tenant, query version, artifact ID, recipient, and row count.
Creation, delivery, open, download, revocation, and deletion are separate audit events.
Export audit logs are stored outside the application database and retained for the defined investigation period.
An alert fires when requested, resolved, artifact, and recipient tenant IDs do not agree.
An alert fires on unusual export volume, size, frequency, or recipient changes.
The team knows exactly how long email, CDN, object, and application access logs are retained.

Response ownership

One named person can disable exports without deploying code.
One named person owns privacy risk and notification decisions.
Security, privacy counsel, insurer, regulator, and customer communication routes are recorded outside the affected system.
A pre-approved recipient deletion request and customer holding message are ready.
The breach record includes awareness time, decision deadlines, evidence, and notification status.

Practice

Automated tests create Tenant Alpha and Tenant Beta, generate an export for Alpha, and prove Beta cannot list or download it.
Tests repeat the same export through browser, API, background job, cache hit, expired link, revoked link, and administrator paths.
A tabletop drill traces one synthetic export from request to storage, delivery, download, revocation, scope assessment, and customer message.
A second person can find every related audit event and disable the export path within 15 minutes.

Common mistakes

Treating one recipient as one affected person. The file may contain records about many people.
Deleting the file before preserving evidence. You lose the artifact, hash, metadata, and a reliable basis for scoping.
Accepting deletion confirmation as proof that no breach happened. It can reduce risk, but the disclosure still occurred.
Checking only the visible export endpoint. Caches, background jobs, admin tools, APIs, support tools, and direct object links may use different paths.
Fixing the UI but not the authorization layer. A hidden button does not protect the underlying object.
Waiting for perfect scope before starting notification review. Some clocks begin when you become aware of the breach.
Using vague language with customers. “Some information may have been involved” prevents people from making useful protective decisions.
Adding tenant IDs to logs but not access decisions. Better evidence does not prevent another cross-tenant disclosure.

Sources

Last reviewed July 19, 2026Guidance changes. Confirm provider-specific actions in the linked official sources.