1. Purpose
This playbook defines the process for responding to a suspected or confirmed data breach involving unauthorized access, disclosure, loss, alteration, destruction, or exposure of information.
The objectives are to:
- Detect and validate the suspected breach.
- Contain unauthorized access or disclosure.
- Identify the information affected.
- Determine whose information may be affected.
- Preserve evidence.
- Assess the scope and impact of the breach.
- Determine whether information was accessed, acquired, disclosed, modified, or exfiltrated.
- Meet applicable legal, regulatory, contractual, and customer notification requirements.
- Recover affected systems and information securely.
- Identify root causes and corrective actions.
- Prevent recurrence.
This playbook should be used together with the organization’s Information Security Incident Management Policy and Incident Response Procedure.
2. Scope
This playbook applies to data breaches involving:
- Customer information
- Personal information
- Employee information
- Financial information
- Health or other regulated information
- Confidential business information
- Intellectual property
- Source code
- Authentication information
- Credentials and secrets
- Database records
- Cloud storage
- SaaS applications
- File-sharing platforms
- Production applications
- Endpoints and servers
- Mobile devices
- Paper or physical records
- Third-party and supplier environments
- APIs and integrations
- Cloud environments
3. What Is a Data Breach?
A data breach is an information-security incident in which information is exposed, accessed, disclosed, lost, altered, destroyed, or otherwise handled without appropriate authorization.
Examples include:
- Unauthorized database access
- Customer data accidentally sent to the wrong recipient
- Public exposure of an S3 bucket
- Lost laptop containing sensitive information
- Stolen credentials used to access customer records
- Accidental publication of confidential information
- Unauthorized employee access
- Compromised SaaS account
- API exposing another customer’s information
- Malware or ransomware resulting in data access
- Source-code repository containing secrets
- Supplier exposing organizational information
- Unauthorized download or export of customer records
A suspected breach should not automatically be treated as a confirmed breach. The organization should investigate and document the evidence supporting its conclusion.
4. Data Breach Response Lifecycle
Detect → Report → Validate → Contain → Preserve Evidence → Identify Information → Determine Scope → Assess Impact → Investigate → Remediate → Recover → Notification Assessment → Communicate → Learn → Close
5. Data Breach Trigger Conditions
Activate this playbook when one or more of the following occurs:
- Unauthorized access to a database is detected.
- Customer information appears outside an authorized system.
- A file is sent to the wrong recipient.
- Confidential information is publicly accessible.
- A cloud storage resource becomes unintentionally public.
- An employee reports accidental disclosure.
- A customer reports seeing another customer’s information.
- Security monitoring detects unusual data downloads.
- A compromised account accesses sensitive information.
- An API exposes information to an unauthorized user.
- A supplier reports unauthorized access to organizational information.
- A device containing sensitive information is lost or stolen.
- Credentials or secrets are exposed.
- A security incident may have resulted in unauthorized data access.
- A regulator, customer, partner, or third party reports possible exposure.
6. Immediate Response – First 15 Minutes
The immediate priority is to stop ongoing unauthorized access while preserving evidence.
6.1 Create an Incident Record
Record:
- Incident ID
- Date/time detected
- Reporter
- Detection source
- Suspected information involved
- Affected system
- Initial business impact
- Initial severity
- Incident Manager
6.2 Activate the Response Team
Notify appropriate personnel:
- Incident Manager
- Security/CISO function
- IT/Cloud/DevOps
- Application Owner
- Data/Privacy Owner
- Legal/Compliance
- Business Owner
- Management
- Supplier Owner where applicable
- Communications team where required
6.3 Preserve Evidence
Do not immediately:
- Delete affected records
- Destroy logs
- Wipe compromised devices
- Remove evidence
- Modify systems unnecessarily
- Contact affected parties before facts are established
Containment and evidence preservation should be coordinated.
7. Initial Validation
Determine whether a data breach actually occurred.
Ask:
- What information is potentially affected?
- Where is the information stored?
- Who accessed it?
- Was the access authorized?
- When did the access occur?
- How was the information exposed?
- Was information actually accessed or only potentially exposed?
- Was information downloaded or copied?
- Was information disclosed to another party?
- Is the exposure still active?
- Is the information publicly accessible?
- Is the information encrypted?
- Can the information be used without additional credentials?
- Is there evidence of exfiltration?
Document the evidence and assumptions separately.
8. Identify the Information Involved
Determine the categories of information affected.
Examples:
| Information Category | Example |
|---|---|
| Customer Identity | Name, customer ID |
| Contact Information | Email, phone |
| Account Information | Username, account details |
| Financial Information | Payment-related information |
| Authentication Data | Passwords, tokens, credentials |
| Personal Information | Employee/customer personal data |
| Sensitive Information | Information requiring additional protection |
| Confidential Business Information | Contracts, pricing, strategy |
| Source Code | Application source code |
| Security Information | Keys, secrets, configurations |
| Operational Information | Internal systems/process information |
Do not collect or copy unnecessary sensitive information into the incident record.
9. Determine the Data Population
Where possible, determine:
- Number of affected records
- Number of affected customers
- Number of affected employees
- Geographic locations
- Countries/jurisdictions involved
- Customer categories
- Data-subject categories
- Date range of affected information
- Systems containing the information
- Data owner
- Processing purpose
- Retention status
Where exact numbers are not yet available, document the current estimate and investigation status.
10. Determine the Breach Type
Classify the event where appropriate.
Confidentiality Breach
Unauthorized access or disclosure.
Example:
Customer records accessed by an unauthorized user.
Integrity Breach
Unauthorized alteration or manipulation.
Example:
Customer records modified by an unauthorized account.
Availability-Related Data Incident
Information becomes unavailable or destroyed.
Example:
A database is deleted during a security incident.
Loss
Information or a device containing information is lost.
Example:
Employee laptop containing locally stored confidential files is lost.
Accidental Disclosure
Information is unintentionally provided to an unauthorized recipient.
Example:
Customer report emailed to the wrong customer.
An incident may involve more than one category.
11. Immediate Containment
Containment should prevent additional unauthorized access or disclosure.
Depending on the situation:
- Disable compromised accounts.
- Revoke active sessions.
- Reset compromised credentials.
- Rotate exposed secrets.
- Remove public access.
- Restrict database access.
- Disable exposed APIs.
- Remove unauthorized file sharing.
- Block unauthorized external access.
- Disable compromised integrations.
- Restrict cloud storage access.
- Remove excessive permissions.
- Isolate affected systems.
- Suspend unauthorized data exports.
- Restrict supplier access.
- Disable exposed API keys.
Example
If customer information is accidentally exposed through a public cloud storage resource:
- Confirm the exposure.
- Restrict public access.
- Preserve relevant logs.
- Identify the exposure period.
- Determine whether the data was accessed.
- Identify affected information.
- Investigate the configuration change.
- Validate that public access is removed.
- Review similar resources for the same weakness.
12. Preserve Evidence
Potential evidence includes:
- Application logs
- Database logs
- Cloud audit logs
- IAM logs
- Authentication logs
- API logs
- Web-server logs
- Firewall logs
- Proxy logs
- DLP alerts
- EDR records
- Email records
- File-access logs
- Storage access logs
- Access-control configurations
- Screenshots where appropriate
- Data export records
- Database query logs
- Incident communications
- Supplier notifications
- Customer reports
- Configuration history
- Change records
Record:
Evidence ID → Source → Date/Time → Collector → Description → Storage Location → Handling/Integrity Information
13. Establish the Incident Timeline
Create a factual timeline.
| Time | Event | Source | Evidence | Confidence |
|---|---|---|---|---|
| 09:10 | Suspicious login detected | IAM | Authentication log | High |
| 09:18 | Customer database accessed | DB logs | Query record | High |
| 09:25 | Large export detected | Monitoring | Export alert | High |
| 09:40 | Account disabled | IAM | Admin log | High |
Separate:
- Confirmed facts
- Probable events
- Assumptions
- Unknowns requiring investigation
14. Investigate Unauthorized Access
Determine:
- Identity used
- Authentication method
- Source location/IP where available
- Device
- Session
- Application
- API
- Database
- Cloud role
- Privilege level
- Information accessed
- Duration of access
Review whether the attacker or unauthorized user:
- Escalated privileges
- Created new accounts
- Changed MFA
- Created API keys
- Created OAuth connections
- Downloaded information
- Deleted logs
- Modified records
- Accessed additional systems
15. Investigate Data Access and Exfiltration
Determine whether information was:
- Viewed
- Queried
- Downloaded
- Exported
- Copied
- Emailed
- Shared
- Printed
- Transferred externally
- Uploaded elsewhere
- Modified
- Deleted
Where possible, identify:
Who → Accessed What → From Where → When → How → How Much → Where It Went
Do not assume that a successful login means that all information in the system was accessed.
16. Cloud / AWS Data Breach Scenario
For an AWS SaaS environment, investigate:
- IAM
- IAM Identity Center
- CloudTrail
- CloudWatch
- S3
- RDS
- DynamoDB
- ECS/EKS/EC2
- KMS
- Secrets Manager
- WAF
- VPC/network logs
- Backup/snapshot activity
Example
A compromised support employee account obtains unauthorized access to an AWS role and queries an RDS customer database.
Investigation should determine:
- Which identity was compromised?
- Which AWS role was assumed?
- Which database was accessed?
- What permissions existed?
- What queries were executed?
- Which records could be accessed?
- Were records exported?
- Were S3 buckets accessed?
- Were credentials or secrets accessed?
- Was there lateral movement?
- Was the access contained?
- What security weakness allowed the access?
Evidence may include CloudTrail, database audit logs, IAM records, application logs, network telemetry, and relevant monitoring alerts.
17. Application / API Data Breach
For an application or API incident, investigate:
- Authentication
- Authorization
- Session management
- API tokens
- Object-level authorization
- Tenant isolation
- Database queries
- API endpoints
- Rate limiting
- Logging
- Application errors
- Recent deployments
- Configuration changes
SaaS Example
Customer A reports that an API response contains Customer B’s information.
Investigate:
Customer Request → Authentication → Authorization → Tenant ID → API Endpoint → Database Query → Response
Determine:
- Whether tenant isolation failed.
- How long the issue existed.
- Which customers could have been affected.
- Whether the issue was actively exploited.
- Whether logs can identify affected requests.
- Whether any data was cached or stored elsewhere.
18. Employee / Insider Data Breach
If the incident involves an employee or contractor:
Review:
- Business justification for access
- Authorized role
- Actual permissions
- Data accessed
- Data downloads
- Email activity
- File transfers
- USB activity where monitored
- Cloud storage activity
- Printing where monitored
- Recent access changes
- Termination/offboarding status
Avoid assuming malicious intent without evidence.
The investigation should focus on:
Access → Activity → Information → Authorization → Impact
19. Third-Party / Supplier Data Breach
If a supplier reports a breach:
Obtain, where available:
- Incident date/time
- Affected service
- Information potentially affected
- Affected customer population
- Exposure period
- Attack vector
- Containment status
- Evidence of access
- Evidence of exfiltration
- Subprocessors involved
- Data locations involved
- Security controls involved
- Corrective actions
- Relevant assurance/investigation reports
Do not automatically treat a supplier’s initial statement as the final determination.
Assess the incident against the organization’s own:
- Supplier Risk Assessment
- Contractual requirements
- DPA
- Supplier Security Requirements
- Supplier Monitoring records
- Data inventory/RoPA
- Risk Register
20. Assess Data Sensitivity
Assess:
- Information classification
- Personal data
- Sensitive personal information where applicable
- Financial information
- Health information
- Authentication information
- Credentials/secrets
- Customer confidential information
- Intellectual property
- Source code
- Regulatory information
Consider:
Sensitivity + Volume + Accessibility + Duration + Exposure + Misuse Potential + Affected Population
Risk assessment should consider the actual circumstances rather than relying only on the data label.
21. Assess Impact
Consider impact on:
Individuals
- Privacy
- Identity theft/fraud risk
- Financial harm
- Security risk
- Reputational impact
Customers
- Confidentiality
- Service trust
- Contractual obligations
- Customer security requirements
Organization
- Financial impact
- Operational disruption
- Legal/regulatory exposure
- Contractual impact
- Reputation
- Intellectual property loss
Security
- Credential compromise
- Further unauthorized access
- Persistence
- Lateral movement
- Additional data exposure
22. Notification Assessment
A suspected breach does not automatically mean that every stakeholder must be notified.
Assess applicable:
- Data-protection/privacy laws
- Sector-specific regulations
- Contractual requirements
- Customer agreements
- Insurance requirements
- Regulatory obligations
- Law-enforcement considerations
Document:
- Requirement considered
- Applicable jurisdiction
- Relevant deadline
- Decision
- Decision-maker
- Supporting facts
- Legal/privacy advice where applicable
Where notification is required, coordinate the content and timing through authorized Legal/Privacy/Compliance personnel.
23. Customer Communication
If customer notification is required or appropriate, communication should clearly distinguish:
- What is known
- What is still under investigation
- What information may be affected
- What the organization has done
- What customers should do
- Contact information
- Further update process
Avoid unsupported statements such as:
- “No data was accessed”
- “No customers were affected”
- “The incident is completely resolved”
unless supported by the investigation.
24. Regulatory / Legal Coordination
For significant incidents, involve appropriate:
- Legal counsel
- Privacy Officer
- Compliance
- Regulatory liaison
- Management
Assess:
- Applicable notification requirements
- Evidence preservation
- Contractual obligations
- Cross-border requirements
- Customer obligations
- Regulatory reporting
- Law-enforcement considerations
- Insurance requirements
Legal requirements vary by jurisdiction, sector, type of data, and incident circumstances.
25. Eradication and Remediation
Remove the cause of the breach.
Possible actions include:
- Patch vulnerable systems.
- Correct access-control weaknesses.
- Remove public exposure.
- Implement stronger authorization.
- Rotate credentials.
- Revoke compromised tokens.
- Remove malicious accounts.
- Disable unnecessary access.
- Correct API authorization.
- Fix tenant-isolation weaknesses.
- Correct cloud configuration.
- Remove unauthorized integrations.
- Improve logging.
- Improve monitoring.
- Rebuild compromised systems where necessary.
26. Recovery
Recovery should include:
- Restoration of affected systems
- Validation of data integrity
- Validation of access controls
- Credential rotation
- Security configuration review
- Application testing
- API testing
- Monitoring validation
- Backup validation
- Customer-service validation
Before closing the incident, verify that the original exposure is no longer present.
27. Verify Containment
The incident should not be considered contained merely because the initial account or vulnerability was disabled.
Verify:
- No unauthorized access remains.
- Compromised credentials are addressed.
- Sessions are revoked.
- Public exposure is removed.
- API authorization is corrected.
- Cloud access is restricted.
- Unnecessary permissions are removed.
- Data exports have stopped.
- Monitoring shows no continuing suspicious activity.
- Similar systems have been checked for the same weakness.
28. Root Cause Analysis
Determine:
Primary Cause
What directly enabled the breach?
Examples:
- Broken access control
- Compromised credentials
- Misconfigured cloud storage
- Software vulnerability
- API authorization failure
- Insider misuse
- Supplier compromise
- Lost device
- Accidental disclosure
Contributing Factors
Examples:
- Excessive privilege
- Lack of MFA
- Weak tenant isolation
- Inadequate logging
- Insufficient monitoring
- Poor configuration management
- Lack of access review
- Inadequate security testing
- Weak supplier oversight
29. Corrective Action Register
Track significant findings.
| Finding | Risk | Corrective Action | Owner | Due Date | Evidence | Status |
|---|---|---|---|---|---|---|
| Public storage exposure | High | Restrict public access and implement preventive controls | Cloud Owner | Date | Configuration evidence | Open |
| Excessive database access | High | Apply least privilege | DBA/Cloud | Date | Access review | Open |
| API authorization weakness | High | Implement object-level authorization | Engineering | Date | Test results | Open |
| Insufficient monitoring | Medium | Improve data-access monitoring | Security | Date | Monitoring evidence | Open |
30. Lessons Learned
Conduct a post-incident review covering:
- How was the breach detected?
- How long did unauthorized access exist?
- What information was involved?
- How was the information accessed?
- Was exfiltration confirmed?
- Were logs sufficient?
- Was the affected data accurately identified?
- Was containment effective?
- Were notification decisions made on time?
- Were customers/suppliers/regulators handled appropriately?
- Did existing controls work?
- What controls failed?
- What should be improved?
31. Data Breach Closure Criteria
The incident may be considered for closure when:
- Unauthorized access has been contained.
- The affected information has been identified as far as reasonably possible.
- The affected systems have been investigated.
- Data access/exfiltration has been assessed.
- Compromised accounts/credentials have been secured.
- The root cause has been identified.
- Remediation has been implemented or formally tracked.
- Recovery has been verified.
- Required notification assessments are complete.
- Required notifications have been made.
- Customer communication has been completed where required.
- Residual risk has been assessed.
- Corrective actions have owners and due dates.
- Lessons learned have been documented.
- Required management approval has been obtained.
- Evidence has been retained.
Outstanding corrective actions may continue after incident closure through the organization’s risk and corrective-action process.
32. Required Evidence
Maintain appropriate evidence such as:
- Incident record
- Initial report
- Data classification
- Affected-system list
- Affected-data assessment
- User/account investigation
- Access logs
- Cloud logs
- Database logs
- API logs
- Data-export records
- Timeline
- Containment evidence
- Root-cause analysis
- Notification assessment
- Legal/privacy review where applicable
- Customer communication
- Regulatory communication
- Corrective-action records
- Risk assessment
- Management approval
- Lessons-learned report
Do not place unnecessary personal or sensitive information directly into general incident notes.
33. Startup-Friendly Implementation
A startup can operate a practical breach-response model without creating a large dedicated privacy incident team.
| Role | Responsibility |
|---|---|
| Incident Manager | Coordinates the incident |
| Security Lead | Technical investigation and containment |
| Cloud/DevOps | Cloud and infrastructure response |
| Engineering | Application/API investigation |
| Data/Privacy Owner | Data-impact assessment |
| Legal/Compliance | Regulatory and contractual assessment |
| Business Owner | Business/customer impact |
| Management | Major decisions and risk acceptance |
| Communications | Approved external communication |
| Supplier Owner | Third-party coordination |
For a small organization, one individual may hold multiple roles, but sensitive notification and major risk decisions should have appropriate independent review.
34. Data Breach Readiness Checklist
Preparation
- Data inventory maintained
- Information classification defined
- Critical data identified
- Data owners identified
- Access controls implemented
- MFA implemented where appropriate
- Logging enabled
- Monitoring implemented
- Data-breach playbook approved
- Incident contacts maintained
- Supplier breach-notification requirements defined
- Backup and recovery arrangements tested
During Incident
- Incident record created
- Incident validated
- Response team activated
- Affected information identified
- Unauthorized access contained
- Evidence preserved
- Affected systems identified
- Data population assessed
- Access/exfiltration investigated
- Root cause investigated
- Supplier involvement assessed
- Privacy/legal assessment initiated
Recovery
- Vulnerability/configuration corrected
- Credentials/tokens rotated where required
- Access controls corrected
- Systems recovered
- Security controls validated
- Monitoring validated
- Similar systems checked
- Containment verified
Closure
- Data-impact assessment completed
- Notification requirements assessed
- Required notifications completed
- Customer communication completed where required
- Corrective actions recorded
- Residual risk assessed
- Lessons learned completed
- Management review completed
- Incident formally closed
35. Relationship With Other ISMS Documents
This playbook should connect with:
- Information Security Incident Management Policy
- Incident Response Procedure
- Account Compromise Playbook
- Cloud Incident Response Procedure
- Ransomware Playbook
- Data Classification Policy
- Access Control Policy
- Data Protection/Privacy Policy
- Data Inventory
- Records of Processing Activities (RoPA)
- Risk Assessment
- Risk Register
- Supplier Security Requirements
- Supplier Incident Response Procedure
- Cloud Security Policy
- Cloud Security Risk Assessment
- Cloud Access Review
- Vulnerability Management Procedure
- Corrective Action Register
- Business Continuity Plan
- Disaster Recovery Plan
- Evidence/Records Management Procedure
The Data Breach Playbook provides the data-focused response layer within the organization’s broader incident-management framework.
36. ISO 27001 Connection
Data-breach response supports the organization’s information-security incident management and risk-management arrangements.
Relevant areas may include:
- Information security incident management
- Reporting information-security events
- Assessment and response to information-security incidents
- Learning from information-security incidents
- Evidence collection
- Access control
- Identity management
- Information classification
- Data leakage prevention
- Logging
- Monitoring
- Cloud security
- Supplier security
- Privacy and protection of personally identifiable information
- Secure authentication
- Vulnerability management
- Backup and recovery
The exact controls applicable to an organization should be determined through its ISMS scope, risk assessment, Statement of Applicability, contractual obligations, and applicable legal/regulatory requirements.
This playbook is not itself evidence that the controls are operating. Auditors may look for actual incident records, access reviews, logs, monitoring evidence, breach exercises, corrective actions, notification assessments, and management review.
37. Internal Audit Checklist
An auditor can verify:
- Is the data-breach response process documented?
- Are roles and responsibilities defined?
- Is sensitive information identified?
- Is information classification implemented?
- Are data owners identified?
- Are access controls appropriate?
- Is MFA implemented where required?
- Are data-access activities logged?
- Are security events monitored?
- Can employees report suspected breaches?
- Are data breaches investigated?
- Is evidence preserved?
- Is the affected data population assessed?
- Is unauthorized access investigated?
- Is exfiltration assessed?
- Are privacy/legal requirements assessed?
- Are supplier breaches addressed?
- Are corrective actions tracked?
- Are lessons learned documented?
- Are residual risks assessed?
- Is management involved in significant incidents?
38. Final Data Breach Audit Trail
A complete data-breach response should create the following evidence chain:
Potential Exposure → Incident Reported → Breach Validated → Information Identified → Affected Population Determined → Access Contained → Evidence Preserved → Timeline Established → Unauthorized Access Investigated → Data Access/Exfiltration Assessed → Business/Privacy Impact Assessed → Root Cause Identified → Remediation Completed → Recovery Verified → Notification Requirements Assessed → Required Notifications Completed → Corrective Actions Assigned → Residual Risk Assessed → Lessons Learned → Management Review → Incident Closed
39. Final Principle
Data Breach Response = Identify the Information + Stop Unauthorized Access + Preserve Evidence + Determine What Was Accessed + Assess Impact + Meet Applicable Obligations + Remediate the Cause + Verify Protection.
The objective is not simply to close the security incident.
The organization should be able to demonstrate:
What happened → What information was involved → Who could access it → What was actually accessed or exposed → How the exposure was contained → Whether data was exfiltrated → Who was affected → What obligations applied → What was communicated → What was remediated → What evidence supports the conclusion.