Glossary Terms

Data Breach

A security incident that causes accidental or unlawful loss, alteration, disclosure of or access to personal data.
On this page

What is a personal data breach?

A personal data breach is a security incident that affects the confidentiality, integrity or availability of personal data. It can involve unauthorised access, accidental disclosure, alteration, destruction, loss or the inability to access information when it is needed. Examples include sending records to the wrong recipient, ransomware, stolen devices, exposed cloud storage, unauthorised employee access and corrupted backups.

Not every security incident is a personal data breach, but many incidents involve personal data even when the initial alert appears purely technical. The organisation should quickly determine what information was affected, which people may be involved and whether the event creates a risk of harm.

Why do data breaches matter?

A breach can expose people to fraud, identity theft, discrimination, embarrassment, physical risk or loss of control over sensitive information. The impact depends on the data, volume, context, people affected and whether safeguards such as encryption were effective. Availability incidents can also create harm when healthcare, payroll or essential services become inaccessible.

Organisations may face notification deadlines, investigations, contractual duties, remediation costs and reputational damage. A well-prepared response can reduce the impact and demonstrate responsible management.

How should an organisation respond?

The response should begin with containment and preservation of evidence. Teams need to identify the systems, data and accounts involved, stop ongoing exposure and maintain a reliable timeline. Privacy, security, legal, communications and business owners should coordinate through a documented incident process.

A risk assessment should consider the nature and sensitivity of the data, identifiability, scale, likely consequences, affected groups and existing protections. The organisation should document notification decisions, even when it concludes that reporting is not required.

What happens after containment?

Recovery includes restoring systems, supporting affected people, rotating credentials, correcting records and monitoring for misuse. The organisation should investigate the root cause and assign corrective actions with clear owners and deadlines. Lessons learned should feed into training, vendor management, security architecture and process design.

Records of the incident should be accurate and proportionate, including the facts, effects, assessment, decisions and measures taken. They may be required for regulators, insurers, customers or internal assurance.

Frequently asked questions

Is accidentally emailing data to the wrong person a breach?

Yes, it may be an unauthorised disclosure. The risk depends on the content, recipient, retrieval actions and likelihood of misuse.

Does encrypted data still count as a breach?

The incident may still be a breach, but strong encryption and secure key management can reduce the risk and influence notification obligations.

How quickly must a breach be reported?

Deadlines vary by law and contract. Some frameworks require notification within a defined period, so organisations should escalate incidents immediately.

Should every affected person be notified?

Not always. The requirement depends on applicable law and the assessed risk or likelihood of harm. The decision should be documented.

Do processors need to report breaches to controllers?

Processors commonly have legal and contractual duties to notify controllers promptly and provide information needed for assessment and response.

Book your personalised demo!
And see how leading organisations are already powering their Privacy and AI Governance with context-aware operations.