What Is a Data Breach and What Must Your Business Do in the First 72 Hours?

Most business owners picture a data breach as a dramatic cyberattack: masked hackers, compromised servers, ransom demands. The reality is more mundane and far more common. A data breach is any incident in which personal data is accidentally or unlawfully accessed, disclosed, altered, lost, or destroyed — regardless of whether it was intentional.

That misdirected email containing a client’s financial details. The laptop left on a train. The shared Google Drive folder that was accidentally set to public. The former employee whose access was never revoked. Under GDPR and most national data protection laws, all of these are notifiable data breaches if they meet the threshold of risk to the rights and freedoms of individuals.

And once it happens, you have 72 hours to notify your supervisory authority.

What counts as a personal data breach

A breach does not require malicious intent. The legal definition covers three types of failure:

Confidentiality breach: unauthorised or accidental disclosure of personal data. Someone outside the organisation sees data they should not.

Integrity breach: unauthorised or accidental alteration of personal data. Records are modified without authorisation.

Availability breach: accidental or unauthorised loss of access to personal data. Data is lost, encrypted by ransomware, or deleted and cannot be recovered.

Any of these, affecting any personal data of individuals in your jurisdiction, may trigger notification obligations. The key question is not whether a breach occurred but what risk it creates.

The risk threshold

Not every breach must be reported to the supervisory authority. Notification is required when the breach “is likely to result in a risk to the rights and freedoms of natural persons.” Notification directly to affected individuals is required when the risk is “high.”

Assessing risk means considering:

• The sensitivity of the data affected (financial data, health records, passwords, and identity documents carry higher risk than names and work email addresses)
• The number of individuals affected
• The ease with which the data could be used to harm those individuals
• Whether the data has actually been accessed or only potentially exposed

A laptop with encrypted data that was lost and never accessed carries lower risk than an unencrypted database left accessible on a public server for three weeks.

When in doubt, report. Supervisory authorities treat a late notification far more harshly than an over-cautious one.

The 72-hour clock

From the moment your organisation becomes “aware” of a breach — meaning any member of staff who would reasonably be considered responsible has knowledge of it — the clock starts. You have 72 hours to notify your supervisory authority.

This does not mean you need all the answers within 72 hours. The initial notification can acknowledge what you know, what you do not yet know, and what steps you are taking to find out. You can supplement the notification with further information as your investigation progresses.

What you cannot do is wait until you have completed a full investigation before notifying. The 72-hour window exists precisely to enable regulators to advise and assist during the response phase, not after it.

What your initial notification must include

Each supervisory authority publishes its own notification form, but the required information is broadly consistent across GDPR-based frameworks:

• Nature of the breach: what type of data was affected, who was affected, and approximately how many records
• Name and contact details of your Data Protection Officer or the person responsible for data protection
• Likely consequences of the breach: what harm could result for affected individuals
• Measures taken or proposed to address the breach and mitigate its effects

If you cannot provide all of this within 72 hours, state what you know and indicate when you will be able to provide the rest.

The actions to take immediately

Hour 1: Contain Stop the bleeding before counting the wound. Revoke compromised access credentials. Take affected systems offline if necessary. Secure or retrieve exposed data where possible. Document every action taken from this moment forward.

Hours 1–12: Assess Identify what data was affected and who it belongs to. Determine whether the breach is ongoing or contained. Establish the likely cause. Assign a named incident lead. Begin the documented log of your response — regulators will ask for this.

Hours 12–48: Decide Evaluate the risk using the framework above. Make a documented decision about whether notification is required and at what level (supervisory authority, affected individuals, or both). If notification is required, begin drafting.

Hours 48–72: Notify Submit to your supervisory authority. If affected individuals are at high risk, notify them directly with clear, plain-language communication explaining what happened, what data was involved, what steps you have taken, and what they should do.

The breach register

GDPR and most equivalent laws require you to maintain an internal record of all breaches, including those that do not meet the notification threshold. This register must include: the date and nature of the breach, its effects, and the remedial actions taken.

The breach register serves two purposes. First, it gives you the documented basis for decisions not to notify — demonstrating that you assessed the risk and concluded it fell below the threshold. Second, it provides auditors and supervisory authorities with a record of your incident management capability over time.

A spreadsheet maintained informally by the compliance officer does not constitute a reliable breach register. It will be asked for under regulatory investigation, and the integrity of its timestamps and entries will be questioned.

What the supervisory authority looks for

When a breach is reported, the authority assesses two things: the breach itself and your response to it. Organisations that respond well — containing quickly, notifying promptly, communicating clearly with affected individuals, and demonstrating that the breach was not caused by a systemic failure — consistently receive lower sanctions than those that respond poorly.

The worst outcome is not a breach. It is a breach discovered by the regulator through a data subject complaint, weeks after it occurred, with no notification, no breach register, and no evidence of any response. That combination results in the highest sanctions available.

Building the capability before the breach happens

A breach response capability is not something you build under pressure. The breach register, the incident response procedure, the notification templates, the list of who to call and in what order — these need to exist before the moment of crisis.

Every business that handles personal data will experience a breach event. The question is whether the response is structured and evidenced, or improvised and undocumented. Regulators know the difference, and so do the individuals whose data you are responsible for.