1. Purpose
This playbook defines the immediate and coordinated response to a suspected or confirmed ransomware incident.
The objective is to:
- Detect and validate ransomware activity quickly.
- Contain the attack and prevent further spread.
- Protect critical systems, accounts, and information.
- Preserve evidence for investigation.
- Assess whether information has been accessed or exfiltrated.
- Recover systems safely from trusted backups or clean environments.
- Verify that ransomware persistence has been removed.
- Meet applicable legal, regulatory, contractual, and customer notification requirements.
- Identify root causes and improve security controls.
The playbook should be used together with the organization’s Information Security Incident Management Policy and Incident Response Procedure.
2. Scope
This playbook applies to ransomware affecting:
- Employee laptops and desktops
- Servers
- Production systems
- Cloud environments
- Databases
- File storage
- Network infrastructure
- SaaS applications
- Identity and access systems
- Backup systems
- Source-code repositories
- CI/CD environments
- Containers and Kubernetes environments
- Customer environments where contractually applicable
- Third-party or supplier environments affecting the organization
- Customer, personal, confidential, financial, or regulated information
3. What Is a Ransomware Incident?
Ransomware is malicious activity in which an attacker typically attempts to deny access to systems or information, often through encryption, and may additionally threaten disclosure of stolen information.
A ransomware incident may involve:
- File or database encryption
- System encryption
- Destruction or deletion of backups
- Credential compromise
- Privilege escalation
- Lateral movement
- Malware deployment
- Data exfiltration
- Persistence mechanisms
- Ransom demands
- Extortion
- Compromise of cloud resources
- Compromise of suppliers or managed services
A ransom note by itself does not establish the full scope of the incident. The organization should investigate what systems, identities, data, and backups were actually affected.
4. Ransomware Response Lifecycle
Detect → Report → Validate → Classify → Contain → Preserve Evidence → Investigate → Protect Backups → Eradicate → Recover → Verify → Assess Data Impact → Communicate → Improve
5. Ransomware Trigger Conditions
Activate this playbook when one or more of the following occurs:
- Large numbers of files suddenly become encrypted.
- File extensions change unexpectedly.
- A ransom note appears.
- Endpoint protection detects ransomware.
- Multiple systems become unavailable simultaneously.
- Backup repositories show suspicious deletion or modification.
- Security monitoring detects mass file modification.
- Privileged credentials are used unexpectedly.
- Security tools are disabled without authorization.
- Suspicious PowerShell, scripting, or administrative activity is detected.
- Network shares are being accessed or modified unusually.
- Cloud resources show unexpected destructive activity.
- A supplier reports ransomware affecting a connected service.
- An employee reports suspicious encryption activity.
- Threat intelligence indicates possible compromise matching observed activity.
6. Immediate Response – First 15 Minutes
The first objective is containment, not investigation perfection.
6.1 Start the Incident Record
Record:
- Incident ID
- Date/time detected
- Reporter
- Detection source
- Affected system
- Initial symptoms
- Current business impact
- Initial severity
- Incident Manager
6.2 Declare the Incident
Notify the appropriate:
- Incident Manager
- Security/CISO function
- IT/Infrastructure
- Cloud/DevOps
- Application Owner
- Management
- Privacy/Legal/Compliance where appropriate
- Business Continuity/DR owner where required
6.3 Do Not Destroy Evidence
Do not immediately:
- Reformat affected systems
- Delete malware
- Wipe compromised devices
- Delete suspicious accounts
- Destroy logs
- Delete ransom notes
- Restore systems without understanding the incident
- Shut down every system indiscriminately
Actions should balance containment, evidence preservation, and business continuity.
7. Initial Validation
Determine whether the activity is actually ransomware.
Check:
- What systems are affected?
- What files/data are affected?
- Is encryption occurring?
- When did it begin?
- Which user/account initiated the activity?
- Is the attacker still active?
- Are systems still being encrypted?
- Are network shares affected?
- Are backups affected?
- Are cloud resources affected?
- Are production systems affected?
- Is there evidence of data exfiltration?
- Is the activity isolated or spreading?
Document the evidence supporting the determination.
8. Incident Severity
Severity should be determined using the organization’s approved incident classification methodology.
Low
Examples:
- Suspected ransomware blocked on a single isolated endpoint.
- No evidence of successful execution.
- No material business impact.
Medium
Examples:
- Confirmed ransomware on a limited number of endpoints.
- Limited business disruption.
- No evidence of critical-system compromise.
High
Examples:
- Multiple systems affected.
- Production service disruption.
- Privileged account compromise.
- Critical business application affected.
- Backup systems potentially compromised.
Critical
Examples:
- Widespread encryption.
- Customer-facing production outage.
- Critical business services unavailable.
- Significant customer/personal/regulated information potentially exposed.
- Backup destruction or compromise.
- Major supplier/cloud environment compromise.
- Evidence of extensive attacker persistence or lateral movement.
Severity examples are illustrative. The organization’s approved incident classification criteria should determine the final classification.
9. Immediate Containment
Containment should focus on stopping the attack from spreading.
Depending on the situation:
- Isolate affected endpoints.
- Disable compromised user accounts.
- Disable compromised privileged accounts.
- Revoke active sessions.
- Disable suspicious remote access.
- Block known malicious infrastructure.
- Restrict affected network segments.
- Disable compromised service accounts.
- Restrict access to network shares.
- Stop suspicious processes where safe.
- Restrict administrative access.
- Isolate affected servers.
- Temporarily restrict affected integrations.
- Block compromised API credentials.
- Restrict cloud IAM permissions.
- Stop affected workloads where necessary.
Important
Do not automatically disconnect every system from the network without considering:
- Evidence preservation
- Business continuity
- Safety
- Critical services
- Cloud dependencies
- Backup integrity
- Incident-response requirements
Containment decisions should be documented.
10. Protect the Backup Environment
Backups are a critical ransomware recovery asset.
Immediately determine:
- Which backups exist?
- Which backups are online?
- Which backups are offline or isolated?
- Are backups encrypted?
- Who can modify/delete backups?
- Were backup credentials compromised?
- Were backup retention settings changed?
- Were snapshots deleted?
- Were backup repositories encrypted?
- Are immutable backups available?
- Is there evidence of attacker access to backups?
- When was the last known clean backup?
Where necessary:
- Restrict backup administration.
- Disable compromised backup credentials.
- Isolate backup infrastructure.
- Protect immutable copies.
- Prevent unauthorized deletion.
- Preserve known-good recovery points.
- Validate backup integrity before restoration.
Never assume a backup is clean simply because the backup job completed successfully.
11. Preserve Evidence
Evidence should be preserved according to the organization’s incident and evidence-handling procedures.
Potential evidence includes:
- Ransom note
- Malware samples where safely handled
- Endpoint alerts
- EDR records
- Antivirus records
- Authentication logs
- VPN logs
- Firewall logs
- DNS logs
- Proxy logs
- Cloud audit logs
- IAM logs
- Application logs
- Database logs
- Network traffic information
- File-system timestamps
- Process information
- Memory or disk images where appropriate
- Backup logs
- Administrative activity
- Email/phishing messages
- Source-code repository activity
- CI/CD activity
- Security-tool alerts
- Attacker indicators of compromise
Record:
Evidence ID → Source → Date/Time → Collector → Description → Storage Location → Integrity/Handling Information
12. Determine Initial Attack Vector
Investigate how the ransomware entered the environment.
Possible vectors include:
- Phishing
- Stolen credentials
- Compromised privileged account
- Remote-access compromise
- Vulnerable internet-facing application
- Unpatched software
- Malicious attachment
- Malicious download
- Compromised supplier
- Remote administration tools
- Exposed cloud credentials
- Compromised API key
- Software supply-chain compromise
- Insider activity
Do not assume the initial infection vector without evidence.
13. Investigate Identity Compromise
Review:
- User accounts
- Privileged accounts
- Administrator accounts
- Cloud identities
- Service accounts
- API credentials
- SSH keys
- OAuth applications
- CI/CD credentials
- VPN accounts
- SSO activity
- MFA changes
- Password resets
- New authentication methods
- Privilege changes
Look for:
- Unusual login locations
- Unusual authentication times
- Impossible-travel indicators
- New devices
- New MFA methods
- Suspicious sessions
- Privilege escalation
- Unexpected administrative activity
14. Investigate Lateral Movement
Determine whether the attacker moved between systems.
Review:
- Domain/identity systems
- Administrative shares
- Remote administration
- RDP/SSH
- VPN
- Server-to-server connections
- Cloud role assumptions
- Service accounts
- Network segmentation
- Shared credentials
- File shares
- Database access
- Endpoint-to-server activity
Create an affected-system map:
Initial System → Account → Privilege → Connected System → Data → Further Access
15. Assess Data Exfiltration
Ransomware incidents may involve data theft in addition to encryption.
Assess whether attackers may have:
- Accessed customer data
- Accessed personal data
- Accessed financial information
- Accessed credentials
- Accessed source code
- Accessed intellectual property
- Downloaded databases
- Exported files
- Accessed cloud storage
- Accessed backups
- Created unauthorized archives
- Transferred data externally
Review available:
- Network logs
- Proxy logs
- Cloud logs
- Storage access logs
- Database logs
- DLP alerts
- EDR telemetry
- Identity logs
- Firewall logs
- Cloud audit trails
Do not state that data was or was not exfiltrated until the investigation supports that conclusion.
16. AWS Cloud Ransomware Scenario
For an AWS-hosted SaaS platform, investigate:
- IAM users
- IAM roles
- IAM Identity Center
- CloudTrail
- CloudWatch
- GuardDuty
- Security Hub
- S3
- RDS
- ECS/EKS/EC2
- KMS
- Secrets Manager
- Security Groups
- WAF
- Backup services
- Snapshots
- CI/CD pipelines
Example scenario:
A compromised developer identity obtains excessive AWS permissions and begins modifying production resources. The attacker attempts to delete backups, access S3 data, deploy unauthorized workloads, and disrupt the application.
Immediate actions may include:
- Disable or restrict the compromised identity.
- Revoke active sessions where appropriate.
- Rotate compromised credentials.
- Review CloudTrail activity.
- Identify assumed roles.
- Review S3 access.
- Review RDS activity and snapshots.
- Review EC2/ECS/EKS activity.
- Review security-group changes.
- Review KMS and Secrets Manager activity.
- Protect known-good backups.
- Identify unauthorized resources.
- Preserve relevant logs.
- Investigate data access/exfiltration.
- Restore affected services only after the environment is considered sufficiently contained.
17. Ransomware Eradication
After containment and sufficient investigation:
- Remove malicious software.
- Remove persistence mechanisms.
- Remove unauthorized accounts.
- Remove unauthorized scheduled tasks.
- Remove unauthorized applications.
- Remove malicious scripts.
- Revoke compromised credentials.
- Rotate secrets where required.
- Rebuild compromised systems where appropriate.
- Patch exploited vulnerabilities.
- Correct insecure configurations.
- Remove unauthorized cloud resources.
- Review administrative privileges.
- Strengthen MFA.
- Validate security tools.
- Confirm monitoring is operational.
For highly compromised systems, rebuilding from trusted sources may be preferable to attempting to clean the original system.
18. Recovery
Recovery should use trusted systems, configurations, and recovery points.
Possible recovery sequence:
Clean Identity → Clean Infrastructure → Security Controls → Applications → Databases → Storage → Integrations → Monitoring → Business Services
Before restoring production:
- Validate backup integrity.
- Confirm recovery point.
- Confirm malware is not present.
- Confirm compromised credentials are addressed.
- Patch vulnerable systems.
- Apply secure configuration.
- Validate IAM.
- Enable MFA.
- Confirm logging.
- Confirm monitoring.
- Validate network controls.
- Validate application security.
- Test restored systems.
19. Recovery Verification
Do not consider recovery complete merely because systems are online.
Verify:
- Systems operate normally.
- Data integrity is acceptable.
- Applications function correctly.
- Authentication works securely.
- MFA is enabled.
- Privileged access is controlled.
- Logging is active.
- Monitoring is active.
- Backups are functioning.
- Vulnerabilities are addressed.
- No unauthorized accounts remain.
- No persistence mechanism remains.
- No suspicious network activity continues.
- Security controls are operational.
20. Business Continuity Considerations
If ransomware causes service disruption, activate the applicable Business Continuity/Disaster Recovery arrangements.
Assess:
- Critical business services
- Customer impact
- RTO
- RPO
- Manual workarounds
- Alternative infrastructure
- Alternative communication channels
- Customer support
- Supplier dependencies
- Regulatory obligations
- Recovery priorities
RTO/RPO values should come from the organization’s approved recovery requirements; they should not be assumed universally.
21. Communication and Notification
Communication should be coordinated through authorized personnel.
Potential stakeholders include:
- Employees
- Management
- Customers
- Suppliers
- Cloud providers
- Cyber insurance provider
- Legal counsel
- Regulators
- Law enforcement
- Contractual partners
Before external communication, verify:
- What happened?
- What is confirmed?
- What remains under investigation?
- What services are affected?
- What information may be affected?
- What actions have been taken?
- What actions are required from recipients?
Avoid speculation or unsupported statements.
Legal, regulatory, contractual, and customer notification requirements should be assessed based on the applicable jurisdiction, contracts, data involved, and incident facts.
22. Ransom Demand Handling
The organization should have a predefined management/legal process for handling ransom demands.
Record:
- Ransom note
- Amount demanded
- Deadline
- Cryptocurrency/payment instructions
- Attacker communication
- Threatened consequences
- Claimed stolen data
- Any communication received
Do not independently negotiate, pay, or communicate with attackers without authorization and appropriate legal/security assessment.
Any potential payment decision should consider applicable law, sanctions requirements, legal advice, insurance requirements, business continuity, and the likelihood of restoring operations.
23. Root Cause Analysis
After stabilization, determine:
Initial Cause
How did the attacker gain access?
Enabling Conditions
Examples:
- Weak authentication
- Missing MFA
- Excessive privileges
- Unpatched vulnerability
- Exposed service
- Poor network segmentation
- Weak endpoint protection
- Inadequate logging
- Insufficient backup protection
- Poor credential management
- Security awareness gap
Contributing Factors
Identify organizational or technical conditions that allowed the attack to spread or increase its impact.
24. Corrective Action Plan
Each significant finding should result in an action where appropriate.
| Finding | Risk | Corrective Action | Owner | Due Date | Evidence | Status |
|---|---|---|---|---|---|---|
| Excessive administrator access | High | Implement least privilege | Cloud Owner | Date | IAM review | Open |
| Backup deletion possible | High | Implement stronger backup protection | Infrastructure | Date | Backup configuration | Open |
| Missing MFA | High | Enforce MFA | IAM Owner | Date | MFA report | Open |
| Unpatched system | High | Patch and validate | IT | Date | Patch evidence | Open |
| Insufficient monitoring | Medium | Improve detection rules | Security | Date | SIEM/EDR evidence | Open |
25. Lessons Learned
Conduct a post-incident review after stabilization.
Discuss:
- What happened?
- How was it detected?
- How quickly was it detected?
- How did the attacker gain access?
- How did the attack spread?
- Were backups protected?
- Did recovery work as expected?
- Were RTO/RPO requirements achieved?
- Were logs sufficient?
- Was evidence preserved?
- Were communication processes effective?
- Were customers affected?
- Were suppliers involved?
- Which controls failed or were insufficient?
- Which controls worked?
- What should change?
26. Security Control Improvements
Potential improvements may include:
- Stronger MFA
- Privileged Access Management
- Least privilege
- Network segmentation
- EDR/XDR
- Improved vulnerability management
- Secure configuration baselines
- Backup isolation/immutability
- Improved logging
- Centralized monitoring
- Credential rotation
- Secrets management
- Phishing protection
- Security awareness
- Application security
- Cloud security monitoring
- Incident-response exercises
- Recovery testing
The improvements should be based on actual findings and risk assessment rather than implementing every possible control.
27. Ransomware Incident Closure Criteria
The incident may be considered for closure when:
- Attack activity has been contained.
- Affected systems have been investigated.
- Persistence has been removed.
- Compromised accounts are secured.
- Credentials/secrets have been rotated where required.
- Malware has been removed or systems rebuilt.
- Data impact has been assessed.
- Backups have been validated.
- Recovery has been completed.
- Recovery has been verified.
- Security monitoring is operational.
- Required notifications have been completed.
- Root cause has been documented.
- Corrective actions have been assigned.
- Residual risks have been assessed.
- Required management approval has been obtained.
- Incident records and evidence are complete.
Closure should not mean that every corrective action has already been completed; outstanding actions may continue through the organization’s corrective-action and risk-management process.
28. Required Incident Evidence
Maintain appropriate evidence such as:
- Incident record
- Detection alert
- Ransom note
- Timeline
- Affected asset list
- Affected user/account list
- Network evidence
- Endpoint evidence
- Cloud logs
- Identity logs
- Backup records
- Recovery records
- Data-impact assessment
- Communication records
- Notification decisions
- Root-cause analysis
- Corrective-action register
- Risk assessment
- Management approval
- Lessons-learned report
Evidence should be protected against unauthorized modification or deletion.
29. Startup-Friendly Implementation
A startup does not necessarily need a large dedicated ransomware-response team.
A practical model can assign:
| Role | Responsibility |
|---|---|
| Incident Manager | Coordinates response |
| Security Lead | Investigation and security decisions |
| Cloud/DevOps | Cloud containment and recovery |
| IT | Endpoint/server response |
| Application Owner | Application validation |
| Business Owner | Business impact |
| Privacy/Legal | Data and notification assessment |
| Management | Major decisions and risk acceptance |
| Communications | Approved external communication |
| Supplier Owner | Provider coordination |
For a small SaaS company, several responsibilities may be performed by the same person, provided critical decisions have appropriate oversight.
30. Ransomware Readiness Checklist
Preparation
- Incident response procedure approved
- Ransomware playbook available
- Critical assets identified
- Critical suppliers identified
- Backup requirements defined
- RTO/RPO defined where required
- Backup restoration tested
- MFA enabled
- Privileged access controlled
- Endpoint protection deployed
- Cloud logging enabled
- Security monitoring enabled
- Contact/escalation list maintained
During Incident
- Incident record created
- Incident classified
- Incident Manager assigned
- Affected systems identified
- Accounts investigated
- Attack contained
- Evidence preserved
- Backups protected
- Lateral movement assessed
- Data exposure assessed
- Supplier/cloud provider engaged where required
- Communications coordinated
Recovery
- Root cause identified
- Compromised credentials addressed
- Systems rebuilt/cleaned
- Vulnerabilities remediated
- Trusted backups validated
- Recovery completed
- Recovery verified
- Monitoring restored
- Business services validated
Closure
- Data impact assessed
- Required notifications completed
- Corrective actions recorded
- Residual risk assessed
- Lessons learned completed
- Management review completed
- Incident formally closed
31. Relationship With Other ISMS Documents
This playbook should connect with:
- Information Security Incident Management Policy
- Incident Response Procedure
- Cloud Incident Response Procedure
- Account Compromise Playbook
- Business Continuity Plan
- Disaster Recovery Plan
- Cloud Backup and Recovery Procedure
- Vulnerability Management Procedure
- Patch Management Procedure
- Access Control Policy
- Privileged Access Management
- Cloud Security Policy
- Cloud Secure Configuration Standard
- Risk Assessment
- Risk Register
- Corrective Action Register
- Supplier Security Incident Response Procedure
- Data Breach Response Procedure
- Evidence/Records Management Procedure
The playbook provides the ransomware-specific operational response; it should not replace the organization’s broader incident-management framework.
32. ISO 27001 Connection
Ransomware response supports the organization’s information-security risk management and incident-management arrangements.
Relevant areas may include:
- Information security incident management
- Information security event reporting
- Assessment and response to incidents
- Learning from information-security incidents
- Evidence collection
- Backup
- Access control
- Identity management
- Privileged access
- Malware protection
- Vulnerability management
- Logging and monitoring
- Cloud security
- Business continuity
- Supplier security
- Data protection
The exact controls and implementation should be determined through the organization’s ISMS scope, risk assessment, applicable requirements, and Statement of Applicability.
This playbook itself is not evidence that ransomware controls are operating. Auditors may look for evidence such as incident records, exercises, backup restoration tests, logs, access reviews, corrective actions, and management review.
33. Internal Audit Checklist
An auditor can verify:
- Is ransomware included in the organization’s incident-risk scenarios?
- Is the playbook approved and maintained?
- Are roles and escalation paths defined?
- Are critical systems identified?
- Are backup and recovery requirements defined?
- Are backups protected from unauthorized deletion?
- Are restoration tests performed?
- Is MFA implemented?
- Is privileged access controlled?
- Are cloud logs available?
- Are security events monitored?
- Can incidents be reported?
- Are incident records maintained?
- Is evidence preserved?
- Are data-impact assessments performed?
- Are corrective actions tracked?
- Are lessons learned documented?
- Are incident-response exercises performed where appropriate?
- Are residual risks reviewed?
- Is management involved in significant incidents?
34. Final Ransomware Audit Trail
A complete ransomware response should create an evidence chain:
Suspicious Activity → Incident Reported → Incident Validated → Severity Classified → Response Activated → Systems Identified → Attack Contained → Evidence Preserved → Backups Protected → Investigation Conducted → Lateral Movement Assessed → Data Impact Assessed → Root Cause Identified → Threat Eradicated → Systems Recovered → Recovery Verified → Notifications Assessed/Completed → Corrective Actions Assigned → Residual Risk Assessed → Lessons Learned → Management Review → Incident Closed
35. Final Principle
Ransomware Response = Detect Quickly + Contain the Attack + Protect Evidence + Protect Backups + Investigate the Compromise + Recover From Trusted Sources + Verify Security + Learn and Improve.
The objective is not simply to remove ransomware.
The organization must be able to demonstrate:
What happened → How it happened → What was affected → What was contained → What data was impacted → How systems were recovered → What evidence supports the response → What risks remain → What was improved.