1. Purpose
This procedure defines how the organization identifies, assesses, contains, investigates, reports, and manages suspected or confirmed personal data breaches.
The objective is to ensure that data breaches are handled in a timely, controlled, and documented manner, while minimizing harm to affected individuals, protecting organizational information, and meeting applicable legal, regulatory, contractual, and customer requirements.
2. Scope
This procedure applies to:
- Employees
- Contractors
- Consultants
- Temporary personnel
- IT and security teams
- Engineering teams
- Privacy and compliance teams
- Third-party service providers where applicable
- Personal data processed by the organization
- Cloud and SaaS environments
- Corporate applications and systems
- Customer and employee information
- Physical and electronic records
The procedure applies whether a breach is caused by:
- Cyberattack
- Human error
- Lost or stolen device
- Unauthorized access
- Misconfiguration
- Insider activity
- Supplier/processor incident
- Malware or ransomware
- Accidental disclosure
- Software vulnerability
- Physical security incident
3. What Is a Data Breach?
A data breach may involve the unauthorized or accidental:
- Access
- Disclosure
- Acquisition
- Loss
- Alteration
- Destruction
- Availability disruption
of personal data or other protected information.
A suspected breach should be investigated even when the organization does not yet know whether personal data was actually accessed or disclosed.
4. Data Breach Response Principles
The organization should follow these principles:
4.1 Report Immediately
Employees and third parties should report suspected data breaches without waiting for complete confirmation.
4.2 Protect First
Take reasonable steps to prevent further unauthorized access, disclosure, alteration, or destruction.
4.3 Preserve Evidence
Relevant logs, emails, files, system records, and other evidence should be preserved.
4.4 Assess Before Communicating
Determine what is known, what is suspected, and what remains uncertain before making external statements.
4.5 Meet Applicable Requirements
Legal, regulatory, contractual, and customer notification requirements should be assessed for the relevant jurisdictions and circumstances.
4.6 Document Decisions
Important decisions, assessments, notifications, and actions should be recorded.
4.7 Learn and Improve
The organization should identify the cause of the breach and implement appropriate corrective actions.
5. Data Breach Response Lifecycle
The organization should follow:
Detect / Report
↓
Record
↓
Initial Assessment
↓
Contain
↓
Investigate
↓
Assess Impact & Risk
↓
Determine Notification Requirements
↓
Notify Where Required
↓
Remediate
↓
Recover
↓
Document & Close
↓
Lessons Learned
6. Step 1 – Identify and Report
A suspected data breach may be identified through:
- Employee report
- Customer complaint
- Security monitoring
- Data-loss prevention alert
- Cloud security alert
- Email security system
- Vulnerability assessment
- Internal audit
- Supplier notification
- External researcher
- Regulatory inquiry
Examples:
- An employee accidentally emails a customer database to the wrong recipient.
- An AWS S3 bucket is incorrectly configured.
- A compromised account accesses customer records.
- A laptop containing personal information is lost.
- A supplier reports unauthorized access to customer information.
The person discovering the incident should report it through the approved incident reporting channel.
7. Step 2 – Create a Breach Record
The response team should create a breach record.
Initial Record
| Field | Example |
|---|---|
| Breach ID | DBR-2026-001 |
| Date/Time Detected | [Date/Time] |
| Reported By | [Name] |
| Detection Source | Security Alert |
| Incident Type | Unauthorized Access |
| Affected System | Customer Portal |
| Personal Data Involved | Under Assessment |
| Initial Severity | High |
| Breach Owner | Privacy/Security Lead |
| Status | Investigating |
The record should be updated as the investigation progresses.
8. Step 3 – Initial Assessment
The organization should determine:
- Did a security event occur?
- Does it involve personal data?
- What categories of personal data may be involved?
- Whose data may be affected?
- How many individuals may be affected?
- What systems or locations are involved?
- Was the information accessed, disclosed, modified, lost, or destroyed?
- Is the breach ongoing?
- Has the breach been contained?
- Which jurisdictions may be relevant?
- Which customers or suppliers are involved?
- Are legal, regulatory, or contractual notification requirements potentially triggered?
At this stage, clearly distinguish confirmed facts from assumptions or information still under investigation.
9. Step 4 – Containment
Immediate containment should focus on preventing further exposure.
Possible actions include:
- Disable compromised accounts
- Revoke sessions
- Reset passwords
- Rotate credentials/API keys
- Restrict database access
- Remove public access from cloud storage
- Isolate affected systems
- Block malicious activity
- Disable compromised integrations
- Remove unauthorized access
- Preserve affected systems for investigation
Example – AWS S3 Exposure
If a storage bucket containing personal data is accidentally public:
Detect
→ Confirm exposure
Contain
→ Remove public access
Preserve
→ Capture configuration and relevant logs
Investigate
→ Determine whether the data was accessed
Assess
→ Determine affected information and individuals
Notify
→ Assess applicable requirements
Remediate
→ Correct configuration and access controls
10. Step 5 – Investigation
The investigation should establish, as far as reasonably possible:
What happened?
Describe the event.
When did it happen?
Establish the timeline.
How did it happen?
Identify the attack vector, human error, configuration issue, vulnerability, or other cause.
What information was involved?
Identify affected datasets and data categories.
Who may have accessed it?
Identify unauthorized recipients, users, accounts, systems, or external parties.
Was the information actually accessed?
Use available evidence rather than assuming that exposure automatically means access.
Is the breach still active?
Determine whether additional containment is required.
11. Categories of Personal Data
The organization should identify the types of information potentially affected.
Examples include:
- Name
- Email address
- Telephone number
- Address
- Employee information
- Customer information
- Identification information
- Financial information
- Authentication credentials
- Account information
- Business information
- Health-related information where applicable
- Other sensitive or regulated information
The classification should reflect the organization’s actual data inventory and applicable legal requirements.
12. Step 6 – Assess Impact and Risk
The organization should assess the potential consequences of the breach.
Consider:
- Nature of the data
- Sensitivity of the information
- Number of affected individuals
- Vulnerability of affected individuals
- Likelihood of misuse
- Potential financial impact
- Identity theft/fraud risk
- Confidentiality impact
- Integrity impact
- Availability impact
- Customer impact
- Regulatory impact
- Contractual impact
- Geographic scope
- Whether the information was encrypted or otherwise protected
The organization should document the reasoning behind the assessment.
13. Breach Severity
An organization may define severity levels appropriate to its risk profile.
| Severity | Example |
|---|---|
| Critical | Confirmed large-scale exposure of highly sensitive personal data |
| High | Confirmed unauthorized access to significant customer information |
| Medium | Limited personal-data exposure with potentially limited impact |
| Low | Accidental disclosure of limited information with low assessed impact |
Severity should be reassessed as additional evidence becomes available.
14. Step 7 – Determine Notification Requirements
The organization should determine whether notification is required under applicable:
- Data protection laws
- Cybersecurity regulations
- Industry regulations
- Customer contracts
- Processor/controller agreements
- Insurance requirements
- Other contractual obligations
The assessment should consider:
- Applicable jurisdiction
- Organization’s role
- Type of data
- Nature of breach
- Potential impact
- Applicable notification threshold
- Required notification timeframe
- Required notification content
- Relevant authority
- Whether affected individuals must be informed
Legal or privacy specialists should be consulted where the requirements are complex or high-risk.
The organization should not assume that every data breach requires notification to every regulator or affected individual.
15. Regulatory Notification
Where notification is required:
Confirm Breach
↓
Determine Applicable Law/Jurisdiction
↓
Assess Notification Requirement
↓
Identify Deadline
↓
Prepare Notification
↓
Legal/Privacy Review
↓
Management Approval Where Required
↓
Submit Through Official Channel
↓
Record Submission
↓
Track Follow-up
The Authority & Regulatory Contact Register should be used to identify the appropriate authority and official reporting channel.
The organization should retain evidence of:
- Date/time of notification
- Authority contacted
- Information submitted
- Person responsible
- Submission/reference number
- Authority response
- Follow-up actions
16. Notification to Affected Individuals
Where required or otherwise determined appropriate, communication to affected individuals should be:
- Clear
- Accurate
- Timely
- Understandable
- Consistent with verified facts
- Appropriate to the circumstances
The communication may include, as applicable:
- What happened
- When it happened
- What information may be affected
- What the organization has done
- What individuals can do to protect themselves
- How to contact the organization
- Relevant support information
The final content should be reviewed by the appropriate legal/privacy and management functions.
17. Customer Notification
Where the organization processes information on behalf of customers, contracts may establish specific breach notification obligations.
The organization should:
- Identify affected customer(s).
- Review the applicable contract.
- Determine notification requirements.
- Notify the customer through the agreed channel where required.
- Provide verified information.
- Coordinate follow-up requests.
- Maintain records of communication.
Example
A SaaS provider discovers unauthorized access to a production database containing customer information.
The provider should assess:
- Which customer environments were affected?
- What information was involved?
- Whether the customer contract contains notification requirements?
- Whether the provider acts as a processor/service provider or in another role?
- Whether regulatory obligations apply?
- What evidence supports the assessment?
18. Third-Party / Processor Breach
If a supplier or processor reports a breach:
- Record the notification.
- Identify affected information.
- Identify affected customers.
- Obtain available incident details.
- Assess contractual obligations.
- Assess regulatory requirements.
- Evaluate containment.
- Monitor supplier remediation.
- Update supplier risk assessment where necessary.
- Record all communications.
Supplier contracts should establish appropriate security and breach-notification obligations where relevant.
19. Evidence Preservation
Relevant evidence should be preserved, including:
- Access logs
- Authentication records
- Cloud logs
- Database logs
- Email records
- System configurations
- Security alerts
- Screenshots
- Incident tickets
- Data-access records
- Communications
- Investigation notes
Evidence should be protected from unauthorized alteration or deletion.
Where forensic or legal proceedings are possible, appropriate legal or forensic guidance should be obtained.
20. Step 8 – Remediation
After containment and investigation, corrective measures should address the cause of the breach.
Examples:
- Correct cloud configuration
- Strengthen access controls
- Implement MFA
- Reduce excessive privileges
- Patch vulnerabilities
- Improve encryption
- Improve monitoring
- Update data handling procedures
- Improve employee awareness
- Strengthen supplier controls
- Modify application security controls
Remediation should be prioritized according to risk.
21. Step 9 – Recovery
Before returning affected systems to normal operation:
- Confirm containment.
- Confirm unauthorized access has been removed.
- Validate security configurations.
- Rotate compromised credentials where necessary.
- Confirm monitoring.
- Validate data integrity.
- Confirm required remediation.
- Obtain appropriate system/business-owner approval.
Enhanced monitoring may be appropriate after recovery.
22. Step 10 – Breach Closure
A breach may be closed when:
- Investigation is substantially complete.
- Impact has been assessed.
- Required notifications have been addressed.
- Containment and recovery are complete.
- Corrective actions have been assigned.
- Relevant evidence has been preserved.
- Required communications are complete.
- Risk assessment has been reviewed.
- The breach owner approves closure.
Closure does not necessarily mean that every long-term corrective action has already been completed. Outstanding actions should remain tracked separately.
23. Post-Breach Review
A significant breach should undergo a formal post-breach review.
Questions should include:
Detection
- How was the breach detected?
- Could it have been detected earlier?
Cause
- What caused the breach?
- Was the cause technical, procedural, human, supplier-related, or a combination?
Data
- What information was involved?
- Was the data appropriately protected?
Controls
- Which controls worked?
- Which controls failed or were missing?
Response
- Was containment timely?
- Was the correct team involved?
- Were escalation procedures effective?
Notification
- Were applicable notification requirements assessed correctly?
- Were communications timely and accurate?
Improvement
- What changes are required?
24. Corrective Action Register
| Action ID | Issue | Corrective Action | Owner | Due Date | Status | Evidence |
|---|---|---|---|---|---|---|
| DB-CA-001 | Excessive database access | Review database permissions | CTO | [Date] | Open | Access review |
| DB-CA-002 | Cloud configuration weakness | Implement configuration monitoring | IT | [Date] | Open | Monitoring report |
| DB-CA-003 | Awareness gap | Conduct targeted training | HR | [Date] | Open | Training record |
Corrective actions should be tracked until completion and reviewed for effectiveness where appropriate.
25. Risk Register Update
A significant breach should trigger a review of relevant information security risks.
Example:
Data breach
↓
Root Cause
Misconfigured cloud storage
↓
Existing Risk
Unauthorized access to customer data
↓
Risk Register Review
↓
Risk Treatment
Improve cloud security configuration and monitoring
↓
Control Implementation
Configuration management + access control + monitoring
↓
Evidence
Configuration records + alerts + access reviews
↓
Effectiveness Review
Internal audit / control testing
26. Data Breach Record
The organization should maintain a central breach register.
| Breach ID | Date | Data Type | Cause | Severity | Individuals Affected | Notification Required | Status |
|---|---|---|---|---|---|---|---|
| DBR-001 | [Date] | Customer Data | Unauthorized Access | High | [Number] | Under Assessment | Open |
| DBR-002 | [Date] | Employee Data | Accidental Disclosure | Medium | [Number] | No | Closed |
Access to the breach register should be restricted because it may contain sensitive personal, security, legal, or investigative information.
27. Roles & Responsibilities
| Role | Responsibility |
|---|---|
| Top Management | Major decisions and escalation |
| Privacy Lead / DPO | Privacy assessment and coordination |
| Security Lead / CISO | Technical investigation and containment |
| IT / Engineering | Technical remediation and recovery |
| Legal | Legal assessment and external communication |
| Compliance | Regulatory assessment and coordination |
| HR | Employee-related breaches |
| Customer Success | Customer coordination where authorized |
| System Owner | Business impact and system recovery |
| Employees | Prompt reporting |
| Internal Auditor | Independent review where appropriate |
For small organizations, one person may perform multiple responsibilities, but appropriate independence and approval controls should be maintained.
28. Data Breach Communication Matrix
| Stakeholder | When | Owner | Channel |
|---|---|---|---|
| Security Team | Immediately | Incident Owner | Security channel |
| Management | Significant breach | Incident Manager | Approved channel |
| Legal/Privacy | Potential personal-data breach | Security Lead | Secure communication |
| Regulator | Where legally required | Legal/Privacy | Official portal |
| Customer | Contract/legal requirement | Account/Legal | Approved channel |
| Affected Individuals | Where required/appropriate | Privacy/Communications | Approved channel |
| Supplier | Supplier-related breach | Vendor Owner | Contractual channel |
29. Data Breach Response Checklist
Detection & Reporting
- Breach reported
- Breach ID created
- Initial facts recorded
- Breach owner assigned
- Relevant systems identified
Assessment
- Personal data confirmed/assessed
- Data categories identified
- Affected individuals assessed
- Jurisdictions identified
- Potential impact assessed
- Severity assigned
Containment
- Ongoing exposure stopped
- Compromised accounts restricted
- Credentials rotated where required
- Systems isolated where required
- Evidence preserved
Investigation
- Timeline established
- Root cause investigated
- Data access assessed
- Logs reviewed
- Scope assessed
Notification
- Legal requirements assessed
- Regulatory requirements assessed
- Contractual requirements assessed
- Customer notification assessed
- Individual notification assessed
- Required notifications completed
- Evidence of notification retained
Recovery
- Vulnerability corrected
- Unauthorized access removed
- Systems validated
- Monitoring enabled
- Business recovery completed
Improvement
- Post-breach review completed
- Corrective actions recorded
- Risk Register reviewed
- Controls reviewed
- Policies/procedures updated where required
- Lessons learned communicated
30. Evidence for ISO 27001 Audit
Potential evidence includes:
- Data Breach Response Procedure
- Incident Management Policy
- Incident Response Plan
- Data breach register
- Incident tickets
- Investigation records
- Access and security logs
- Evidence preservation records
- Breach impact assessments
- Regulatory notification records
- Customer notifications
- Corrective action records
- Updated risk assessments
- Post-breach review
- Incident response testing
The organization should be able to demonstrate that it can identify, assess, respond to, and learn from data breaches, rather than simply maintaining a written procedure.
31. Relationship With the ISMS
The Data Breach Response Procedure should connect with:
Security Incident Management Procedure
→ Identifies and manages the security incident
Data Breach Response Procedure
→ Determines whether personal data or other protected information was affected and manages the breach response
Authority & Regulatory Contact Register
→ Identifies relevant external authorities
Risk Register
→ Captures changes in information security risk
Corrective Action Register
→ Tracks remediation
Management Review
→ Reviews significant incidents, trends, risks, and improvement actions
32. Startup-Friendly Approach
A startup does not need a complex privacy incident platform to implement this procedure.
A practical setup can use:
- Security monitoring
- Cloud logs
- Incident ticketing
- Data inventory
- Contract repository
- Risk Register
- Breach Register
- Authority Contact Register
- Secure communication channel
- Corrective Action Tracker
The important requirement is that the organization can demonstrate a repeatable and controlled process.
33. Final Principle
A data breach response process should answer:
What data was affected?
What happened?
Who may be affected?
What is the potential impact?
What must we do immediately?
Who must be informed?
What legal, regulatory, and contractual requirements apply?
What must change to prevent recurrence?
The complete cycle is:
Detect → Report → Contain → Investigate → Assess → Notify → Remediate → Recover → Document → Learn → Improve