Breach Management
A personal data breach is a security incident that results in accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. This definition, drawn from GDPR Article 4(12), encompasses three distinct breach categories: confidentiality breaches where data is disclosed to or accessed by unauthorised recipients, availability breaches where data is lost or destroyed, and integrity breaches where data is altered without authorisation. The definition is broader than common understanding suggests. A breach occurs regardless of intent, regardless of whether the data leaves organisational control, and regardless of whether harm results. An employee accessing a colleague’s personnel file without authorisation constitutes a breach even if they disclose nothing. A ransomware attack that encrypts beneficiary records constitutes a breach even if the attacker never exfiltrates data. A system error that corrupts case management records constitutes a breach even if the corruption is immediately detected and corrected.
- Personal data breach
- A security incident leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored, or otherwise processed.
- Confidentiality breach
- Unauthorised or accidental disclosure of, or access to, personal data. The most commonly recognised breach type.
- Availability breach
- Accidental or unauthorised loss of access to, or destruction of, personal data. Includes temporary unavailability where this affects data subject rights.
- Integrity breach
- Unauthorised or accidental alteration of personal data, affecting its accuracy or completeness.
- Controller
- The entity that determines the purposes and means of processing personal data. Bears primary breach notification obligations.
- Processor
- An entity that processes personal data on behalf of a controller. Must notify the controller without undue delay upon becoming aware of a breach.
Breach Identification
Breach identification requires distinguishing security incidents that affect personal data from those that do not, and recognising that personal data involvement triggers specific legal obligations regardless of incident severity from a technical perspective. A denial-of-service attack against public-facing infrastructure that contains no personal data is a security incident but not a data breach. The same attack against a beneficiary registration system constitutes a breach because personal data becomes unavailable, even if no data leaves the system.
The identification challenge lies in the word “aware.” Notification obligations under GDPR begin when the controller becomes aware of a breach, yet awareness is not the moment an incident occurs but the moment the organisation has reasonable certainty that personal data has been compromised. An organisation detecting anomalous network traffic is not yet aware of a breach. Upon investigation revealing that the traffic represented data exfiltration from a database containing personal data, awareness crystallises at the point where the investigation confirms personal data involvement, not at the point of initial detection.
+-------------------------------------------------------------------+| BREACH IDENTIFICATION FLOW |+-------------------------------------------------------------------+| || +------------------+ || | Security Event | || | Detected | || +--------+---------+ || | || v || +--------+---------+ +-------------------+ || | Initial Triage +---->| No Personal Data +---> Security || | Assessment | | Involved | Incident Only || +--------+---------+ +-------------------+ || | || | Personal data potentially affected || v || +--------+---------+ || | Investigation | || | Phase | || | (72 hours max) | || +--------+---------+ || | || +------------------+------------------+ || | | | || v v v || +--------+------+ +--------+------+ +--------+------+ || | Confirmed | | Confirmed | | Cannot | || | Breach | | No Breach | | Determine | || +--------+------+ +---------------+ +--------+------+ || | | || v v || +--------+------+ +---------+-------+ || | Awareness | | Treat as | || | Established | | Breach | || | Clock Starts | | (Precautionary) | || +---------------+ +-----------------+ || |+-------------------------------------------------------------------+Figure 1: Breach identification flow from initial detection to awareness establishment
Organisations must establish clear criteria for what constitutes reasonable certainty. Waiting for forensic confirmation of every detail before acknowledging awareness violates the spirit of notification requirements. The European Data Protection Board guidance indicates that a controller should be regarded as aware when it has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised. In practice, this means awareness occurs when investigation reveals that personal data was accessible to the threat actor, stored on compromised systems, or transmitted through compromised channels, even if exfiltration cannot be definitively confirmed.
The processor notification requirement operates on a shorter timeline with a lower threshold. Processors must notify controllers without undue delay after becoming aware of a breach, which the EDPB interprets as immediately and in any case within 48 hours. Processors are not required to conduct detailed assessments before notifying controllers; notification should occur as soon as the processor recognises that personal data processed on behalf of the controller has been affected.
Assessment Methodology
Breach assessment determines notification obligations, response priorities, and remediation requirements. The assessment examines four dimensions: the nature of the breach, the categories and volume of data affected, the categories and number of data subjects affected, and the likely consequences for data subjects.
The nature of the breach encompasses the breach type (confidentiality, integrity, availability), the threat actor profile (external attack, insider, accident), and whether the breach is ongoing or contained. A contained confidentiality breach affecting encrypted data presents different risk than an ongoing availability breach affecting critical humanitarian case management data.
Data categories divide into ordinary personal data and special category data. Special category data under GDPR Article 9 includes racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data for identification, health data, and data concerning sex life or sexual orientation. Humanitarian organisations frequently process special category data through health programmes, protection case management, and beneficiary registration systems. Criminal conviction data under Article 10 carries similar sensitivity. The presence of special category data in a breach elevates risk assessment by default.
+-------------------------------------------------------------------------------+| BREACH SEVERITY MATRIX |+-------------------------------------------------------------------------------+| || Data Categories Affected || || Ordinary Special Criminal Protection/ || Personal Category Conviction Safeguarding || Data Data Data Data || +------------+------------+------------+------------+ || | | | | | || < 100 | LOW | MEDIUM | HIGH | CRITICAL | || subjects | | | | | || +------------+------------+------------+------------+ || | | | | | || 100- | MEDIUM | HIGH | HIGH | CRITICAL | || Data 1,000 | | | | | || Subjects +------------+------------+------------+------------+ || Affected | | | | | || 1,000- | HIGH | HIGH | HIGH | CRITICAL | || 10,000 | | | | | || +------------+------------+------------+------------+ || | | | | | || > 10,000 | HIGH | CRITICAL | CRITICAL | CRITICAL | || | | | | | || +------------+------------+------------+------------+ || |+-------------------------------------------------------------------------------+Figure 2: Severity matrix combining data subject volume with data category sensitivity
Volume assessment requires reasonable estimation when exact figures are unavailable. If a database backup was exfiltrated, the volume is the number of unique data subjects represented in that backup, not the number of records. If email archives were accessed, estimation requires examining the date range of accessible archives and typical correspondence patterns. Expressing volume as a range (between 5,000 and 8,000 data subjects) is acceptable when precision is impossible.
Consequence assessment examines potential harms to data subjects. These include discrimination, identity theft or fraud, financial loss, reputational damage, loss of confidentiality of data protected by professional secrecy, unauthorised reversal of pseudonymisation, physical harm, and emotional distress. For humanitarian contexts, consequences extend to protection risks: identification of vulnerable individuals to hostile actors, exposure of survivors to perpetrators, and compromise of witness or informant safety. A breach affecting 50 individuals in a protection programme may present higher consequence severity than a breach affecting 5,000 donors.
The assessment combines these dimensions to determine whether notification to the supervisory authority is required (if the breach is likely to result in a risk to rights and freedoms), whether notification to data subjects is required (if the breach is likely to result in a high risk to rights and freedoms), and the urgency of notification and remediation actions.
Risk Evaluation Framework
Risk evaluation translates assessment findings into notification decisions. The evaluation addresses two distinct thresholds: risk to rights and freedoms (triggering supervisory authority notification) and high risk to rights and freedoms (triggering data subject notification). These are not percentage probabilities but qualitative judgments informed by the assessment dimensions.
A breach is unlikely to result in risk when technical and organisational measures render the personal data unintelligible to unauthorised recipients. Properly implemented encryption with secure key management means that encrypted data accessed by an unauthorised party presents minimal risk, provided the encryption keys were not also compromised. Similarly, a breach affecting data that is already publicly available by the data subject’s choice presents lower risk than a breach affecting confidential information.
+-------------------------------------------------------------------+| RISK EVALUATION DECISION TREE |+-------------------------------------------------------------------+| || +------------------+ || | Breach | || | Confirmed | || +--------+---------+ || | || v || +--------+---------+ +----------------------------------+ || | Data encrypted +---->| Keys also compromised? | || | at rest? | Yes +------------------+---------------+ || +--------+---------+ | || | No +----------+----------+ || | | | || v v v || +--------+---------+ +-------+-------+ +-------+-------+ || | Risk likely | | Yes: Proceed | | No: Risk | || | Notify authority | | as unencrypted| | unlikely | || +--------+---------+ +-------+-------+ | Document only | || | | +---------------+ || v | || +--------+---------+ | || | Special category |<------------+ || | or protection | || | data involved? | || +--------+---------+ || | || +-----+-----+ || | | || v v || +--+--+ +--+--+ || | Yes | | No | || +--+--+ +--+--+ || | | || v v || +--+----------+--+ +-------------------------+ || | High risk | | Evaluate consequences: | || | presumed | | - Identity theft risk | || | Notify subjects| | - Financial loss risk | || +----------------+ | - Physical safety risk | || | - Discrimination risk | || +------------+------------+ || | || +------------+------------+ || | | || v v || +------+------+ +-------+------+ || | High risk | | Risk but not | || | Notify | | high risk | || | subjects | | Authority | || +-------------+ | only | || +--------------+ || |+-------------------------------------------------------------------+Figure 3: Risk evaluation decision tree for determining notification obligations
The evaluation must document reasoning regardless of outcome. If the organisation concludes that a breach does not require notification, the documentation must explain why risk to rights and freedoms is unlikely. This documentation serves two purposes: demonstrating accountability to supervisory authorities who may later review the decision, and creating institutional memory that improves consistency across breach assessments.
Worked example: An organisation discovers that a laptop stolen from a staff member’s vehicle contained an unencrypted spreadsheet with 340 beneficiary names, phone numbers, and household sizes collected during a distribution exercise. The assessment identifies this as a confidentiality breach affecting ordinary personal data (names, phone numbers) for 340 data subjects. The laptop was password-protected but not encrypted. Password protection without encryption provides minimal security against a motivated attacker who can remove the hard drive and access files directly.
The consequence evaluation considers that names and phone numbers in isolation present limited identity theft risk, but the context matters: these are beneficiaries of humanitarian assistance in a specific geographic area during a specific time period. If the operating context involves conflict or displacement, this data could identify vulnerable populations to hostile actors. If the context is stable, the primary risk is unwanted contact or petty fraud.
Assuming a stable context with low protection sensitivity, the evaluation concludes: risk to rights and freedoms is likely (supervisory authority notification required within 72 hours) but high risk is not established (data subject notification not required, though the organisation may choose to notify as good practice). The reasoning and decision are documented in the breach register.
Notification Requirements
Supervisory authority notification under GDPR Article 33 requires submission within 72 hours of becoming aware of a breach that is likely to result in a risk to rights and freedoms. The 72-hour period is not a target but a maximum; notification should occur as soon as feasible. Where notification cannot be made within 72 hours, the notification must be accompanied by reasons for the delay.
The notification must include the nature of the breach including, where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned. It must describe the likely consequences of the breach. It must describe the measures taken or proposed to address the breach, including measures to mitigate possible adverse effects. It must provide contact details for the data protection officer or other contact point for further information.
Phased notification is explicitly permitted. If complete information is not available within 72 hours, the initial notification can provide available information with a commitment to supplement. This approach is preferable to delayed notification while awaiting complete forensic analysis.
Data subject notification under Article 34 is required when the breach is likely to result in a high risk to rights and freedoms. The notification must describe in clear and plain language the nature of the breach and provide the same contact point and consequence information as the authority notification, along with the measures taken and recommendations for individuals to mitigate potential effects.
Data subject notification is not required in three circumstances: the controller has implemented appropriate technical and organisational measures that render data unintelligible (such as encryption); the controller has taken subsequent measures that ensure high risk is no longer likely to materialise; or notification would involve disproportionate effort, in which case public communication or similar measure is required instead.
+------------------------------------------------------------------+| NOTIFICATION TIMELINE |+------------------------------------------------------------------+| || Hour 0 || Awareness established || | || +---> Assessment begins || | Document breach register entry || | || v || Hour 24 || | || +---> Initial assessment complete || | Notification decision documented || | Draft notification prepared || | || v || Hour 48 || | || +---> Notification reviewed and approved || | Data subject notification drafted (if required) || | || v || Hour 72 || | || +---> DEADLINE: Supervisory authority notification || | submitted or delay justification provided || | || v || Hour 72+ || | || +---> Data subject notification (if required) || | "Without undue delay" - typically within days || | || +---> Supplementary authority notification || As investigation reveals additional information || |+------------------------------------------------------------------+Figure 4: Notification timeline from awareness to completion
Jurisdictional complexity arises when organisations operate across multiple countries, process data of subjects in multiple jurisdictions, or maintain establishments in multiple EU member states. The lead supervisory authority concept under GDPR means that for organisations with establishments in multiple member states, the authority of the main establishment handles cross-border breaches. However, where the breach affects data subjects only in specific member states, those authorities may be competent.
For non-EU organisations processing EU resident data, notification goes to the authority of each member state where affected data subjects reside. Practical guidance: if the organisation has designated a representative in the EU, begin with the authority in the representative’s member state.
| Jurisdiction | Authority Notification | Data Subject Notification | Notes |
|---|---|---|---|
| UK (UK GDPR) | ICO within 72 hours | Without undue delay if high risk | Post-Brexit separate regime |
| EU (GDPR) | Lead supervisory authority within 72 hours | Without undue delay if high risk | Cross-border rules apply |
| Kenya (DPA 2019) | ODPC within 72 hours | As expeditiously as possible if high risk | Similar to GDPR framework |
| South Africa (POPIA) | Information Regulator as soon as reasonably possible | As soon as reasonably possible if identity theft or fraud risk | No specific hour deadline |
| Brazil (LGPD) | ANPD within reasonable time | Not explicitly required but recommended | Evolving guidance |
| USA | Varies by state | Varies by state | No federal standard; check each state |
Documentation Requirements
Every breach, regardless of whether notification is required, must be documented. GDPR Article 33(5) requires controllers to document the facts relating to the breach, its effects, and the remedial action taken. This documentation serves as accountability evidence and enables supervisory authorities to verify compliance.
The breach register functions as the authoritative record. Each entry contains: a unique identifier for the breach; the date and time of detection; the date and time awareness was established; a description of the breach including type and attack vector if applicable; the categories of data affected; the categories of data subjects affected; the estimated number of data subjects; the estimated number of records; the assessment of risk; the notification decision with reasoning; notification dates and recipient authorities; data subject notification details if applicable; remediation actions taken; root cause analysis findings; and preventive measures implemented.
The register must be maintained contemporaneously. Entries should be created when breaches are identified and updated as investigation proceeds, not reconstructed after the fact. The register should be protected as confidential and retained for the period required by the organisation’s retention policy, with a minimum of 6 years to cover potential regulatory review or litigation.
Supporting documentation includes forensic reports, communication records, notification submissions and acknowledgements, and evidence of remediation. This documentation should be organised by breach identifier and stored securely with access limited to those with legitimate need.
Remediation Framework
Remediation addresses three objectives: containing the breach to prevent further data compromise, recovering from the immediate impact, and preventing recurrence through systemic improvements.
Containment actions depend on breach type. For ongoing unauthorised access, containment means revoking the access vector: resetting compromised credentials, blocking attacker IP addresses or disabling compromised accounts, isolating affected systems from network access. For malware infections, containment means preventing spread through network segmentation and endpoint isolation before remediation. For accidental disclosure, containment means requesting return or destruction of data from unintended recipients and, where data was publicly exposed, working with hosting providers or search engines to remove cached copies.
Recovery restores normal operations and data integrity. For availability breaches, recovery means restoring data from backup after ensuring the restoration environment is secure. For integrity breaches, recovery means identifying the point before corruption and restoring from known-good backup, or manually correcting data where possible and appropriate. For confidentiality breaches, recovery may be limited since disclosed data cannot be “undisclosed,” but monitoring for misuse and providing identity protection services to affected data subjects constitute recovery actions.
+------------------------------------------------------------------+| REMEDIATION WORKFLOW |+------------------------------------------------------------------+| || +------------------+ || | Breach | || | Confirmed | || +--------+---------+ || | || v || +-----------------------------------------------------------+ || | CONTAINMENT PHASE | || | +---------------+ +---------------+ +---------------+ | || | | Revoke access | | Isolate | | Preserve | | || | | vectors | | systems | | evidence | | || | +---------------+ +---------------+ +---------------+ | || +-----------------------------------------------------------+ || | || v || +-----------------------------------------------------------+ || | RECOVERY PHASE | || | +---------------+ +---------------+ +---------------+ | || | | Restore data | | Verify | | Resume | | || | | integrity | | security | | operations | | || | +---------------+ +---------------+ +---------------+ | || +-----------------------------------------------------------+ || | || v || +-----------------------------------------------------------+ || | PREVENTION PHASE | || | +---------------+ +---------------+ +---------------+ | || | | Root cause | | Control | | Process | | || | | analysis | | improvements | | updates | | || | +---------------+ +---------------+ +---------------+ | || +-----------------------------------------------------------+ || | || v || +--------+---------+ || | Close breach | || | Update register | || +------------------+ || |+------------------------------------------------------------------+Figure 5: Three-phase remediation workflow from containment through prevention
Prevention transforms incident response into security improvement. Root cause analysis identifies not just the immediate failure but contributing factors and systemic weaknesses. A phishing attack that compromised credentials succeeded because the user clicked a malicious link (immediate cause), the organisation lacked phishing-resistant MFA (contributing factor), and security awareness training had not been refreshed in 18 months (systemic weakness). Prevention addresses all three levels: targeted training for the affected user, MFA upgrade across the organisation, and revised training schedule with phishing simulations.
Prevention measures should be documented as action items with owners, deadlines, and verification criteria. The breach register entry is not complete until prevention measures have been implemented and verified, or a documented decision has been made to accept residual risk.
Implementation Considerations
For Organisations with Limited IT Capacity
Breach management capability does not require dedicated security staff. The essential elements are: a designated breach coordinator (often the DPO or a senior staff member with data protection responsibilities), a documented procedure that staff know exists and can locate, a breach register maintained in a secure location, and access to legal or consultancy support for complex assessments.
The procedure should be simple enough to follow under pressure. A single page flowchart showing detection, assessment, and notification steps, with contact details for the breach coordinator and external support, provides sufficient guidance for initial response. Complex assessment can follow with support.
Pre-drafted notification templates reduce response time. Templates for supervisory authority notification and data subject notification, requiring only incident-specific details to be completed, enable rapid response even without specialist expertise.
Rehearsal improves response quality. An annual tabletop exercise walking through a hypothetical breach scenario identifies procedure gaps and builds staff familiarity before a real incident occurs.
For Organisations with Established IT Functions
Mature breach management integrates with broader security operations. Detection capabilities feeding from SIEM and EDR systems should include automated triage that flags potential personal data involvement. Incident response procedures should include breach assessment checkpoints that ensure data protection implications are evaluated alongside technical response.
Automation reduces response time and improves consistency. Workflow tools that guide responders through assessment questions, automatically populate breach register entries, and generate draft notifications based on assessment inputs reduce manual effort and ensure required information is captured.
Metrics enable improvement. Tracking mean time from detection to awareness, mean time from awareness to notification, breach sources by category, and prevention measure implementation rates identifies response weaknesses and demonstrates programme effectiveness to leadership and regulators.
Humanitarian and Protection Contexts
Breaches affecting protection data require modified assessment criteria. Standard risk evaluation may underweight physical safety consequences that predominate in humanitarian contexts. Assessment should explicitly consider whether the breach could enable identification of protected individuals by hostile actors, expose survivors to perpetrators, compromise witness safety, or endanger staff operating in hostile environments.
Notification decisions in humanitarian contexts must weigh regulatory compliance against protection of affected individuals. In extreme cases, notifying data subjects may increase their risk if notification channels are insecure or if the notification itself draws attention to their protected status. These decisions require coordination between data protection, protection, and security functions, and should be documented with full reasoning.
Coordination with humanitarian coordination mechanisms (clusters, working groups) may be appropriate for breaches with sector-wide implications, such as compromise of shared beneficiary registration systems or attacks targeting multiple organisations.
Breach Notification Template
The following template provides a foundation for supervisory authority notification. Adapt language and detail to the specific jurisdiction and breach circumstances.
PERSONAL DATA BREACH NOTIFICATION
To: [Supervisory Authority Name]
From: [Organisation Name]
Date: [Notification Date]
Breach Reference: [Internal Reference Number]
- Nature of the Breach
On [date awareness established], [Organisation Name] became aware of a personal data breach involving [brief description of what occurred].
The breach is categorised as: [confidentiality/integrity/availability] breach.
[If known: The breach occurred on [date of occurrence]. The breach was detected on [date of detection].]
- Categories and Volume of Data
Categories of personal data affected: [List data categories, noting any special category data under Article 9 or criminal conviction data under Article 10]
Approximate number of data subjects affected: [number or range]
Approximate number of personal data records affected: [number or range]
Categories of data subjects affected: [e.g., beneficiaries, staff, donors, partner organisation contacts]
- Data Protection Officer Contact
Name: [DPO Name] Email: [DPO Email] Phone: [DPO Phone]
- Likely Consequences
Based on our assessment, the likely consequences of this breach include: [List specific consequences based on data types and subject categories]
- Measures Taken
Measures taken to address the breach: [List containment and recovery actions]
Measures taken to mitigate adverse effects: [List mitigation actions for data subjects]
- Data Subject Notification
[If notifying data subjects:] Data subjects are being notified via [method] on [date/timeline].
[If not notifying data subjects:] Data subject notification is not required because [reason: encryption, subsequent measures eliminating high risk, or disproportionate effort with alternative measures].
- Additional Information
[Any supplementary information, including indication if this is a phased notification with further information to follow]