A ransomware note is obvious. A suspicious process, unexplained sign-in or security alert may not be. In either case, the first objective is not to make the screen look clean. It is to stop avoidable harm while preserving enough truth to understand what happened.

That distinction matters. Rebooting, wiping or restoring immediately may remove visible symptoms while destroying volatile evidence, reconnecting a compromised identity or allowing the same access path to be used again.

Treat credible suspicion as an incident

Start an incident record as soon as the signal is credible. Record who noticed it, the time and time zone, the affected user/device/service, what was observed, and every action taken. Photograph or capture the visible message if that can be done without interacting with it. Preserve the original alert and relevant email rather than forwarding it repeatedly.

Use simple status labels: known, suspected, not yet checked and confirmed unaffected. “We have only seen it on one PC” is not the same as “only one PC is affected.”

If the organisation has an incident plan, cyber insurer, managed security provider, privacy officer or legal adviser, activate the appropriate route early. Contract and reporting requirements can affect which evidence must be retained and who may negotiate, notify or communicate externally.

Contain what you can identify

Disconnect a suspected endpoint from wired and wireless networks without continuing to browse, email or log into administration portals from it. Do not connect removable drives. If several systems or a subnet show active impact, broader switch-, VLAN-, VPN- or service-level isolation may be necessary; balance that decision against safety and essential operations.

Contain identities as well as machines. A malicious sign-in, remote-management tool, mailbox rule, application consent or stolen session can survive a clean PC. From a known-clean device, responders may need to disable or restrict affected accounts, revoke sessions, rotate credentials and protect privileged access. The exact sequence depends on the identity platform and evidence: changing a password from the suspected computer can simply disclose the new one.

Protect backup systems and administrative consoles from the suspected trust boundary. Do not delete snapshots, rotate every key or take all systems offline reflexively. Each action has operational and evidential consequences; use the narrowest containment that credibly interrupts attacker access, then expand when evidence shows a wider scope.

Preserve evidence before it disappears

Logs roll over. Cloud audit records expire. Memory is lost at shutdown. Security agents may quarantine files. Preserve high-value, short-lived evidence before routine cleanup when doing so does not prolong active harm.

A capable responder may collect memory and a disk image from representative systems, security and application logs, identity and remote-access events, network telemetry, alerts, timestamps, suspected files and indicators. Keep originals read-only where practical, record who collected them, and calculate hashes for files transferred as evidence.

Do not ask an untrained user to execute unknown files, disable security tools or improvise forensic commands. If the compromise may involve privileged access, regulated data or criminal investigation, bring in an incident-response specialist. Evidence copied carelessly can expose customer data or spread malware.

Establish scope, not just symptoms

Build a timeline across endpoint, identity, email, firewall, VPN, cloud, server, backup and remote-management evidence. Ask:

  • What was the earliest credible sign, not merely the first alert noticed?
  • Which identities, endpoints, servers, tenants, mailboxes and repositories were accessed?
  • What initial-access route is supported by evidence?
  • Was data viewed, staged or transferred before encryption?
  • Which accounts, tokens, API keys, certificates or remote tools could preserve access?
  • Can the backup environment be trusted, and when was the last verified clean recovery point?

Ransomware often follows an earlier compromise. Encryption may be the final disruptive action, while credential theft, reconnaissance, persistence and data theft happened days or weeks before. A decryptor or restored server does not answer those questions.

Separate containment, eradication and recovery

These activities overlap, but they are not interchangeable.

Containment interrupts current access and spread. Eradication removes the supported root cause and persistence. Recovery restores trustworthy service and watches for recurrence.

Define an eradication plan from evidence: close the exploited exposure, remove unauthorised persistence, repair or rebuild affected systems, rotate affected secrets from clean administration paths, and correct the control gap that allowed access. For material compromise, rebuilding from known-good media is usually more defensible than declaring a heavily altered system clean after one scanner reports no threats.

Avoid downloading “cleanup” or decryptor utilities from search results. Use the affected vendor, government response bodies or established security organisations, and validate signatures or hashes where provided. A tool written for one ransomware family or product build can damage another case.

Recover in business order on a clean path

Prioritise services by safety, dependency and operational impact. Identity, name resolution, networking and management may need to be restored before applications, but the right order depends on the environment.

For every recovery set, confirm:

  • it predates the relevant compromise or has been assessed for contamination;
  • it is complete and readable on an isolated recovery path;
  • the target system is patched and configured against the confirmed entry route;
  • affected credentials, tokens and certificates are handled deliberately;
  • restored systems cannot communicate with untrusted remnants by default; and
  • application owners validate data consistency and business function.

Reconnect in controlled stages. Increase endpoint, identity and network monitoring during recovery. A service that boots and answers requests is not necessarily safe, current or complete.

Communicate facts without creating a second incident

Give decision-makers regular, time-stamped updates that distinguish confirmed facts from working hypotheses. Centralise external communication. Do not speculate about attribution, stolen data, recovery time or ransom payment.

Notification duties vary by jurisdiction, contract, sector and the kind of information involved. Preserve the facts needed for qualified legal, regulatory, insurance and law-enforcement decisions. Paying a ransom involves legal, ethical and operational risks and does not guarantee recovery or deletion of stolen data; it requires specialist advice, not an improvised technical decision.

Close only when the risk is understood

Closure needs more than a clean scan or successful restore. Confirm that the scope and likely entry route are understood, persistence is addressed, affected identities and secrets are controlled, recovery objectives are met, monitoring shows no recurrence and required notifications are managed.

Then run a blameless review. Turn lessons into owners and due dates: backup isolation and restore exercises, privileged-access changes, patching, logging retention, remote-access controls, staff reporting and an updated incident plan. The value of the review is not a polished report; it is fewer surprises during the next incident.