1. Purpose
The Incident Response Playbook provides a practical, repeatable method for detecting, assessing, containing, investigating, recovering from, and learning from information security incidents.
It is designed to help the organization respond consistently while protecting:
- Information
- Customer data
- Systems
- Cloud environments
- Applications
- Identity and access
- Business operations
- Evidence
- Regulatory and contractual obligations
- Customer trust
The playbook is the master response process. Where a specific incident type is identified, the organization should transition to the appropriate specialized playbook.
Examples:
- Phishing
- Account Compromise
- Cloud Compromise
- Data Breach
- Ransomware
- Malware
- Supplier Incident
- Vulnerability Exploitation
- Unauthorized Access
- CI/CD or Source-Code Compromise
- Production Availability Incident
2. Core Incident Response Lifecycle
The master lifecycle is:
Detect → Report → Validate → Classify → Escalate → Contain → Preserve Evidence → Investigate → Eradicate → Recover → Verify → Communicate → Learn → Improve → Close
The organization should not assume that every alert becomes an incident.
The initial assessment should determine whether the event is:
- False positive
- Routine security event
- Security weakness
- Suspected incident
- Confirmed incident
- Major/critical incident
3. When to Activate This Playbook
Activate formal incident response when there is credible evidence of:
- Unauthorized access
- Account compromise
- Privilege escalation
- Malware
- Ransomware
- Data exposure
- Data loss
- Unauthorized disclosure
- Cloud compromise
- Production compromise
- Security-control manipulation
- Significant vulnerability exploitation
- Customer-impacting security event
- Supplier security incident
- Insider activity
- Source-code or CI/CD compromise
- Significant availability impact
- Other events meeting the organization’s incident criteria
4. Incident Response Principles
4.1 Protect People and Business First
Where there is an immediate threat to people, critical operations, or safety, address that risk first.
4.2 Contain Before the Situation Gets Worse
Do not allow an active attacker or malicious activity to continue unnecessarily.
4.3 Preserve Evidence
Containment should be performed in a way that preserves important evidence where reasonably possible.
4.4 Facts Before Assumptions
Separate:
- Confirmed facts
- Observations
- Assumptions
- Hypotheses
- Unknowns
- Conclusions
4.5 Least Privilege
Only authorized responders should receive access to incident information and evidence.
4.6 Need-to-Know Communication
Do not unnecessarily disclose:
- Customer information
- Personal information
- Credentials
- Security architecture
- Vulnerability details
- Investigation evidence
- Internal response information
4.7 Reassess Continuously
Severity, scope, impact, and response requirements can change as evidence becomes available.
5. Incident Response Team
The response team may include:
| Role | Primary Responsibility |
|---|---|
| Incident Commander | Overall incident coordination |
| Security Lead | Security assessment and response |
| Incident Investigator | Evidence and technical investigation |
| IT / Cloud Lead | Infrastructure containment and recovery |
| Application / DevOps Lead | Application and CI/CD investigation |
| Privacy / Data Protection | Personal-data impact assessment |
| Legal / Compliance | Legal, regulatory, contractual assessment |
| Business Owner | Business-impact decisions |
| Customer Success / Communications | Customer communication |
| HR | Employee-related incidents |
| Supplier Owner | Third-party coordination |
| Executive Management | Major incident decisions |
| BCP / DR Lead | Business continuity and recovery |
In a startup, one person may perform multiple roles, but decision conflicts and independence requirements should be considered.
6. Incident Record
Create an incident record as soon as formal incident response is activated.
Minimum Information
Incident ID:
INC-YYYY-0001
Date/Time Detected:
Reported By:
Incident Owner:
Incident Commander:
Incident Type:
Initial Severity:
Affected Systems:
Affected Information:
Customer Impact:
Current Status:
Initial Description:
7. Step 1 — Detect
Identify the signal or event that triggered investigation.
Possible sources:
- Employee report
- Customer report
- Supplier report
- Security monitoring
- SIEM
- EDR
- Cloud security service
- Vulnerability scanner
- Application monitoring
- Identity monitoring
- Network monitoring
- Email security
- Audit
- Security testing
- Threat intelligence
- Automated alert
Record:
- What was detected
- When it was detected
- Who detected it
- System involved
- Initial evidence
- Initial impact indicators
8. Step 2 — Report
The event should be reported through the organization’s approved reporting mechanism.
Capture:
- Reporter
- Date/time
- Description
- Affected system
- User/account
- Suspicious activity
- Available evidence
- Initial impact
- Immediate actions taken
Employees should:
- Report quickly
- Preserve evidence
- Avoid deleting suspicious messages/files
- Avoid conducting unauthorized investigation
- Avoid communicating externally
- Never include passwords or secrets in the incident report
9. Step 3 — Validate
Determine whether the reported activity is genuine.
Review:
- Authentication records
- Identity activity
- System logs
- Cloud logs
- Application logs
- Security alerts
- Network activity
- Configuration changes
- User activity
- Approved changes
- Maintenance activity
- Known business activity
Decision
Is the event genuine?
If No
Record the evidence and close or monitor as appropriate.
If Yes
Continue assessment.
10. Step 4 — Classify
Determine the event classification.
Typical classification:
| Classification | Meaning |
|---|---|
| CE-0 | False Positive |
| CE-1 | Routine Security Event |
| CE-2 | Security Weakness |
| CE-3 | Suspected Incident |
| CE-4 | Confirmed Incident |
| CE-5 | Major/Critical Incident |
Classification should be based on evidence and organizational incident criteria.
11. Step 5 — Assess Severity
Assess:
Confidentiality
Was information accessed, disclosed, copied, or exposed?
Integrity
Was information, configuration, code, or system behavior changed?
Availability
Was a system or service unavailable or degraded?
Business Impact
Consider:
- Revenue
- Critical operations
- Customer service
- Production
- Contracts
- Reputation
- Business continuity
Information Impact
Consider:
- Customer information
- Personal information
- Financial information
- Health information
- Credentials
- Intellectual property
- Source code
- Confidential information
- Regulated information
Scope
Determine whether the incident is:
- Isolated
- Limited
- Broad
- Widespread
- Unknown
12. Step 6 — Escalate
Escalate according to the organization’s severity and escalation criteria.
Immediate escalation should be considered when there is:
- Privileged account compromise
- Cloud administrator compromise
- Active attacker
- Ransomware
- Significant data exposure
- Customer impact
- Personal or regulated information exposure
- Significant exfiltration
- Production compromise
- Major outage
- Critical vulnerability exploitation
- Security logging disabled or manipulated
- Major supplier compromise
- Financial fraud or BEC
- Regulatory or contractual implications
Escalation should involve the appropriate technical, business, legal, privacy, and management stakeholders.
13. Step 7 — Contain
The objective is to stop or limit the incident.
Possible actions:
- Disable compromised accounts
- Revoke active sessions
- Revoke tokens
- Rotate credentials
- Rotate API keys
- Remove unauthorized access
- Restrict network access
- Isolate affected endpoints
- Isolate workloads
- Block malicious domains/IPs
- Disable compromised integrations
- Restrict cloud permissions
- Disable unauthorized IAM roles
- Isolate affected applications
- Protect backups
- Stop malicious processes where appropriate
Containment should be documented.
Containment Record
Action:
Performed By:
Date/Time:
Reason:
Expected Impact:
Actual Impact:
14. Step 8 — Preserve Evidence
Identify and preserve relevant evidence before it is lost or overwritten, where practical.
Potential evidence includes:
- Authentication logs
- IAM activity
- CloudTrail
- CloudWatch
- GuardDuty
- Security Hub
- EDR data
- Firewall logs
- WAF logs
- DNS logs
- Network logs
- Application logs
- Database logs
- Email headers
- Phishing messages
- Endpoint artifacts
- Configuration changes
- Source-code changes
- CI/CD logs
- Access records
- Backup records
- Security alerts
- Screenshots
- Communications
Record:
Evidence ID → Source → Collector → Date/Time → Method → Location → Hash/Integrity Evidence → Storage → Access
Never store credentials or secrets as investigation evidence unless specifically authorized and securely handled.
15. Step 9 — Investigate
Establish what actually happened.
The investigation should determine:
- What happened?
- When did it happen?
- How did it happen?
- Who or what initiated the activity?
- Which identity was involved?
- Which systems were accessed?
- What permissions were used?
- Was privilege escalated?
- Was persistence established?
- Was lateral movement performed?
- What information was accessed?
- Was information copied or exfiltrated?
- What systems were changed?
- What was the initial attack vector?
- Is the attacker still active?
- What was the root cause?
- What controls failed or were bypassed?
16. Identity Investigation
Review:
- User accounts
- Administrator accounts
- Service accounts
- IAM users
- IAM roles
- SSO identities
- API keys
- Access tokens
- OAuth applications
- MFA activity
- Authentication locations
- Authentication times
- Privilege changes
- Group membership
- Role assumptions
Look for:
- Unusual login
- Impossible travel
- New device
- New MFA method
- Password change
- Token creation
- New API key
- New privileged role
- Unexpected privilege escalation
17. System Investigation
Determine which systems were affected.
Review:
- Endpoints
- Servers
- Cloud workloads
- Containers
- Kubernetes
- Databases
- Storage
- Applications
- Networks
- APIs
- CI/CD
- Source repositories
- SaaS platforms
- Backup systems
Document:
System → Activity → Evidence → Impact → Status
18. Cloud / AWS Investigation
For AWS environments, investigate as applicable:
- AWS IAM
- CloudTrail
- CloudWatch
- GuardDuty
- Security Hub
- S3
- RDS
- ECS
- EKS
- EC2
- Lambda
- VPC
- Security Groups
- WAF
- KMS
- Secrets Manager
- Systems Manager
- Backup
- CI/CD services
Review:
- Authentication
- Role assumption
- Permission changes
- Resource creation
- Security-group changes
- Public exposure
- S3 access
- Database access
- Secret access
- Key usage
- Logging changes
- Data downloads
- Network activity
19. Data Impact Assessment
Determine whether information was:
- Accessed
- Viewed
- Modified
- Deleted
- Copied
- Downloaded
- Exfiltrated
- Disclosed
- Lost
- Unavailable
Classify affected information.
Examples:
- Customer information
- Personal information
- Financial information
- Authentication information
- Confidential business information
- Intellectual property
- Source code
- Security credentials
- Regulated information
Determine:
- What information?
- Whose information?
- How much?
- Which systems?
- Which timeframe?
- Which individuals/customers?
- Was it actually accessed or only potentially accessible?
- Is notification assessment required?
20. Lateral Movement Assessment
Determine whether the attacker moved from the initial system to other systems.
Review:
- Authentication activity
- Remote access
- Privilege escalation
- Network connections
- Service accounts
- Cloud role assumptions
- Administrative activity
- Endpoint activity
- Application access
- Database access
Document:
Initial System → Identity → Privilege → System 2 → System 3 → Data/System Impact
21. Persistence Assessment
Determine whether unauthorized access may remain.
Look for:
- New accounts
- New IAM roles
- New access keys
- Scheduled tasks
- Services
- Startup mechanisms
- OAuth applications
- Tokens
- SSH keys
- Backdoors
- Modified CI/CD pipelines
- Web shells
- Unauthorized cloud resources
Do not close the incident until reasonable persistence checks have been completed.
22. Step 10 — Eradicate
Remove the cause and attacker access.
Actions may include:
- Remove malicious accounts
- Remove unauthorized IAM roles
- Remove unauthorized permissions
- Revoke sessions
- Rotate credentials
- Rotate secrets
- Revoke tokens
- Remove persistence
- Remove malware
- Patch exploited vulnerabilities
- Correct insecure configurations
- Remove unauthorized resources
- Rebuild compromised systems
- Secure CI/CD
- Update detection rules
23. Step 11 — Recover
Restore affected systems to a trusted state.
Recovery sequence may include:
Identity → Security Controls → Network → Infrastructure → Database/Storage → Application → Integrations → Monitoring → Business Service
Validate:
- Security configuration
- Access controls
- MFA
- Logging
- Monitoring
- Encryption
- Backups
- Vulnerability status
- Application integrity
- Data integrity
- Service functionality
24. Step 12 — Verify Recovery
Do not treat restoration as successful merely because the system is running.
Verify:
- Threat removed
- Unauthorized access removed
- Credentials secured
- Persistence removed
- Security controls restored
- Logging functioning
- Monitoring functioning
- Data integrity verified
- Vulnerabilities addressed
- Application functioning
- Business service functioning
- Increased monitoring implemented where necessary
25. Step 13 — Communication
Communications should be:
- Timely
- Accurate
- Authorized
- Fact-based
- Need-to-know
- Consistent
- Appropriate to the audience
Potential stakeholders:
- Incident Response Team
- Management
- Business owners
- Employees
- Customers
- Suppliers
- Legal
- Privacy
- Regulators
- Cloud providers
- Cyber insurers
- Law enforcement
Do not speculate about:
- Root cause before evidence supports it
- Attacker identity
- Number of affected customers before confirmed
- Data exposure before investigation
- Regulatory conclusions before appropriate assessment
26. Customer Communication
Where customer communication is required:
- Confirm facts.
- Identify affected services.
- Determine known impact.
- Coordinate with Legal/Privacy where appropriate.
- Obtain required approval.
- Communicate only verified information.
- Explain actions taken.
- Provide appropriate next steps.
- Maintain communication records.
27. Regulatory and Contractual Assessment
Determine whether the incident creates:
- Regulatory notification requirements
- Customer notification requirements
- Contractual notification requirements
- Insurance notification requirements
- Supplier notification requirements
- Legal obligations
Record:
Requirement → Applicability → Decision → Approver → Action → Date → Evidence
The organization should obtain appropriate legal/privacy advice where required.
28. Step 14 — Root Cause Analysis
After containment and stabilization, determine why the incident occurred.
Consider:
Technology
- Vulnerability
- Misconfiguration
- Missing security control
- Insecure architecture
People
- Lack of awareness
- Training gap
- Human error
- Role ambiguity
Process
- Missing procedure
- Inconsistent execution
- Weak review
- Poor escalation
Governance
- Unclear ownership
- Inadequate risk treatment
- Missing management oversight
- Poor control design
Supplier
- Third-party failure
- Subprocessor issue
- Supplier control weakness
The root cause should be supported by evidence.
29. Step 15 — Corrective Actions
Create corrective actions for identified weaknesses.
Examples:
- Improve MFA
- Reduce privileges
- Improve monitoring
- Patch vulnerability
- Update procedures
- Improve supplier controls
- Improve backup protection
- Improve security awareness
- Automate detection
- Improve incident escalation
- Improve logging
- Improve cloud configuration
- Update security architecture
Link each action to:
Finding → Root Cause → Action → Owner → Deadline → Evidence → Verification → Risk
30. Step 16 — Risk Reassessment
After remediation, reassess the relevant risk.
Determine:
- Original risk
- Controls implemented
- Remaining weakness
- Residual risk
- Risk owner
- Risk acceptance, if applicable
Do not assume that completing a corrective action automatically eliminates the risk.
31. Step 17 — Post-Incident Review
Conduct a post-incident review for significant incidents and where organizational criteria require it.
Review:
- What happened?
- What worked?
- What failed?
- Was detection timely?
- Was escalation timely?
- Was containment effective?
- Was evidence preserved?
- Was communication effective?
- Was recovery successful?
- Were customers affected?
- Were controls effective?
- What should change?
Record lessons in the Lessons Learned Register.
32. Step 18 — Continual Improvement
Convert important lessons into improvements.
Possible outputs:
- Policy changes
- Procedure changes
- Technical controls
- Monitoring improvements
- Training
- Automation
- Architecture changes
- Supplier changes
- Risk treatment
- Security objectives
- Incident playbook updates
The improvement should be tracked until effectiveness is verified.
33. Incident Closure Criteria
An incident should not be closed simply because the immediate threat has stopped.
Confirm:
- Incident scope established as far as reasonably possible
- Containment completed
- Evidence preserved
- Investigation completed
- Attacker access removed
- Persistence assessed
- Credentials secured
- Systems recovered
- Recovery verified
- Data impact assessed
- Customer impact assessed
- Notification requirements assessed
- Root cause identified where reasonably possible
- Corrective actions assigned
- Residual risk assessed
- Lessons learned recorded
- Required communications completed
- Management review completed where required
- Closure approved
34. Incident Closure Record
Incident ID:
Final Classification:
Final Severity:
Summary:
Root Cause:
Impact:
Data Impact:
Customer Impact:
Actions Completed:
Open Corrective Actions:
Residual Risk:
Lessons Learned:
Management Decision:
Closed By:
Closure Date:
35. Specialized Playbook Selection
After classification, select the appropriate specialized playbook.
| Incident | Specialized Playbook |
|---|---|
| Phishing | Phishing Response Playbook |
| Account Compromise | Account Compromise Playbook |
| Cloud Compromise | Cloud Compromise Playbook |
| Data Breach | Data Breach Playbook |
| Ransomware | Ransomware Response Playbook |
| Malware | Malware Response Playbook |
| Supplier Incident | Supply Chain Incident Playbook |
| Vulnerability Exploitation | Vulnerability Exploitation Playbook |
| CI/CD Compromise | CI/CD Security Incident Playbook |
| Production Security Incident | Production Incident Playbook |
If multiple incident types are involved, the Incident Commander may activate multiple playbooks.
Example:
Phishing → Credential Compromise → AWS Account Compromise → Data Breach
36. Startup-Friendly Incident Response Model
A startup can operate a practical incident response process with:
1. One Incident Register
Central record of incidents.
2. One Incident Commander
Clear decision authority.
3. One Evidence Repository
Controlled location for investigation evidence.
4. One Severity Matrix
Consistent classification.
5. One Escalation Matrix
Clear escalation rules.
6. Specialized Playbooks
Use only when applicable.
7. One Corrective Action Tracker
Central tracking of improvements.
8. Regular Tabletop Exercises
Test the process before a real incident.
37. Minimum Incident Response Toolkit
A practical ISMS should maintain access to:
- Incident Reporting Form
- Incident Register
- Event Register
- Event-to-Incident Decision Checklist
- Incident Severity Matrix
- Incident Escalation Matrix
- Incident Response Team RACI
- Evidence Preservation Procedure
- Incident Timeline
- Incident Investigation Template
- Root Cause Analysis Template
- Corrective Action Tracker
- Lessons Learned Register
- Post-Incident Review
- Incident Closure Report
- Communication Procedure
- Specialized Incident Playbooks
- Incident Metrics
- Tabletop Exercise Template
38. Incident Response Testing
The organization should periodically test its incident response capability.
Testing can include:
- Tabletop exercises
- Phishing simulations
- Account-compromise scenarios
- Cloud-compromise scenarios
- Ransomware scenarios
- Data-breach scenarios
- Supplier incidents
- Recovery exercises
Record:
Scenario → Participants → Decisions → Observations → Gaps → Corrective Actions → Improvements → Retest
39. Incident Response Metrics
Useful metrics include:
Time to Detect
Incident occurrence → Detection
Time to Report
Detection → Formal report
Time to Validate
Report → Validation
Time to Escalate
Validation → Required escalation
Time to Contain
Incident activation → Containment
Time to Recover
Containment → Verified recovery
Recurrence Rate
Similar incidents occurring again after remediation
Metrics should be analyzed in context rather than used as isolated performance targets.
40. Audit Evidence
Maintain appropriate evidence of:
- Incident reports
- Incident records
- Event assessments
- Severity decisions
- Escalation records
- Evidence collection
- Investigation timelines
- Containment actions
- Recovery validation
- Communication records
- Notification assessments
- Root Cause Analysis
- Corrective actions
- Lessons learned
- Risk reassessment
- Management review
- Tabletop exercises
- Effectiveness verification
41. ISO 27001 Alignment
The incident response process supports the organization’s information-security incident management arrangements, including:
- Reporting of information-security events
- Assessment and decision-making
- Response activities
- Evidence preservation
- Learning from incidents
- Corrective action
- Continual improvement
- Communication
- Risk management
The exact playbook structure, severity levels, forms, registers, roles, and workflows are organizational implementation choices. They should be tailored to the organization’s context, risk, size, technology, contractual requirements, and applicable legal/regulatory obligations.
42. Master Incident Response Audit Trail
Security Event Detected → Event Reported → Incident Validated → Classification Determined → Severity Assessed → Incident Escalated → Response Team Activated → Evidence Preserved → Containment Completed → Investigation Conducted → Scope Determined → Data/Business Impact Assessed → Root Cause Identified → Threat Eradicated → Systems Recovered → Recovery Verified → Communications Completed → Notification Requirements Assessed → Corrective Actions Assigned → Risk Reassessed → Lessons Learned → ISMS Improvement Identified → Management Review → Incident Closed
Final Principle
Detect Quickly + Validate Carefully + Contain Effectively + Preserve Evidence + Investigate the Facts + Protect Information + Recover From a Trusted State + Verify Recovery + Learn From the Incident + Improve the ISMS.