Ransomware Incident Response: A Beginner’s Practical Guide

Escalate and establish a shared picture

Use the approved incident channel and identify the person coordinating the response. Record the trigger, affected service, observation time and source of the report. A single encrypted file, ransom note or security alert may justify urgent investigation without establishing the full scope.

Avoid sending sensitive incident details through a system that may be compromised. Use the organisation’s trusted communication plan. Do not improvise contact with an attacker or make commercial, legal or recovery commitments outside your authority.

Contain with operational context

The purpose of containment is to limit further harm while preserving a workable response. Qualified responders may isolate affected systems or restrict specific access paths under the incident process. Consider dependencies: cutting off a critical service or shared network path can have consequences beyond the visible endpoint.

If isolation cannot be achieved and destructive activity continues, the responder must weigh the immediate harm against loss of volatile evidence. This is a context-dependent response decision, not a universal instruction to power off every machine. Record the choice, the authority and the reason.

Review response phases and priorities →

Understand containment boundaries →

Preserve evidence before it disappears

Keep relevant logs, alert records, timestamps and system observations through approved evidence-handling procedures. Preserve originals, note collection methods and restrict access. Avoid cleanup or restoration that would erase the only evidence of the access path before responders have assessed it.

Build a working timeline that distinguishes event time from discovery time. “The file share became unavailable at 10:20” does not establish when the intrusion began. Make uncertainty visible so later analysis can refine the timeline without rewriting unsupported claims.

• Record which systems and accounts are in scope now.
• Preserve the time zone and source of each important event.
• Document response actions and who performed them.
• Keep evidence in an approved location with controlled access.

Do not confuse encryption with proof about exfiltration

An encryption event does not tell you whether data was also taken. The absence of a visible transfer in a small log sample is not proof that no transfer occurred. State what evidence is available and which periods, services or accounts still require review.

In a fictional scenario, a backup job succeeds at 02:00 and encryption is reported at 08:30. Those two facts do not prove the backup is clean, the attacker arrived after 02:00 or the incident is limited to the encrypted server. Your response note should avoid all three assumptions.

Recover into a validated environment

Prioritise restoration with the service owner and response lead. Establish that the selected recovery data is suitable, that the environment is controlled and that the access path being investigated will not simply reintroduce the problem. Test the recovery process and business function before broad reconnection.

A successful restore job is one observation, not the whole recovery outcome. Check the application, required identity and network dependencies, monitoring and the ability to detect renewed suspicious activity. Keep the response team involved while service is restored.

Review backup and recovery design →

Check recovery reasoning →

Communicate in facts, decisions and next updates

A concise executive update should describe service impact, what is known, what is being contained, the important uncertainties and when the next update will be provided. Separate a working estimate from a committed recovery time. Avoid “everything is safe” when the investigation remains incomplete.

Practise with this structure: observed impact; current scope; actions taken; unresolved questions; decision needed; next update. The released Pro ransomware lab provides a synthetic scenario and worked reviews so you can compare your priorities without handling malware or changing a real system.

Explore the ransomware first-response lab →