Incident Response Management

A login, a software update, and a web request are all events: observable occurrences involving computing assets. Most events are normal. An adverse event has a negative consequence, such as a disk failure, a power outage, or a malware infection.

Decide when security response is needed

A cybersecurity incident actually or imminently jeopardizes the confidentiality, integrity, or availability of information or systems without lawful authority. It also includes actual or imminent violations of laws, security policies, security procedures, or acceptable use policies. The organization writes incident criteria so analysts can apply this definition consistently.

An attacker using a stolen password is an incident even before anyone confirms data theft. A routine power outage is an adverse event but usually does not meet security incident criteria. A data breach is a type of incident involving unauthorized access to or disclosure of data. A denial-of-service attack can be an incident without a data breach.

An alert is a signal to investigate. When the evidence meets the written criteria, an analyst declares an incident: opens the incident record, assigns an owner, and activates the plan's severity, response, and communication rules. Treating every alert as an incident creates noise; waiting for proven theft misses incidents that already threaten systems.

Connect the phases

The classic life cycle groups the work into four phases:

1. Preparation: establish authority, contacts, access, tools, logging, backups, and practiced procedures.
2. Detection and analysis: validate signals, establish what happened, find the affected assets, and assess impact.
3. Containment, eradication, and recovery: stop harm, remove attacker access and its causes, and restore trusted services.
4. Post-incident activity: review the response and track improvements.

Certification outlines may split the middle work into separate steps, giving seven steps in total. This describes the same work at a finer level. The phases overlap. An analyst can discover a second compromised account during containment and return to scoping. A failed cleanup can send a system back into isolation.

Read the current NIST model

NIST SP 800-61 Revision 3, published in April 2025, places incident response within the six functions of the Cybersecurity Framework (CSF) 2.0. Govern, Identify, and Protect support preparation through wider risk management. Detect, Respond, and Recover organize incident response itself. The Improvement category within Identify gathers lessons from any activity, including an ongoing incident.

For example, a team discovers during containment that its cloud contact list is obsolete. It updates the contact list immediately and records the change for review. It does not need to wait for all services to recover before improving readiness. Incidents can take weeks or months to resolve, so sharing lessons only at the end would leave a known gap open throughout that time.

A response needs both authority and a practical way to use it. Three levels of documentation connect management decisions to actions at a console.

Give each document a clear job

The policy sets management's commitment, scope, definitions, and authority, including who may disconnect a system. The plan explains how the organization responds: roles, incident categories, severity levels, escalation paths, communication, resources, and documentation. Procedures and playbooks explain the steps and decisions for particular situations.

A usable plan includes contact lists, deputies, evidence requirements, links to playbooks, and a review schedule. It assigns roles that survive staff changes. If only one named executive can approve isolation and that person is unreachable, the plan has a single point of failure. Pre-authorize containment for defined situations and name backup decision makers.

Match decisions to roles

The incident manager, also called the incident commander, coordinates work, assigns tasks, tracks status, and makes decisions within the plan's authority. Incident handlers validate findings, preserve evidence, and carry out response actions. System, network, cloud, and development staff make changes to their services.

Leadership supplies resources and approves high-impact actions. Asset owners explain business impact and recovery priorities. Legal advises on preservation, contracts, and notifications; public relations handles public statements. Human resources joins employee-related cases, and physical security supports facility access.

An in-house CSIRT is a computer security incident response team. An outsourced model may use a managed security services provider (MSSP) or a retained response firm. A hybrid combines internal responders with outside specialists. For cloud services, record which layers the provider manages and which remain the customer's responsibility, including how to obtain provider evidence.

Plan communication before the incident

The communication plan says who receives an update, who sends it, when, through which channel, and with what detail. Internal audiences include responders, leadership, owners, the help desk, and affected staff. External audiences may include customers, partners, regulators, law enforcement, insurers, and the media. Leadership and legal decide external notifications; analysts follow the assigned route.

Use out-of-band communication if email, chat, or identity systems may be compromised. A separate phone bridge or independent messaging service prevents an attacker in the main environment from following the response. Share incident details on a need-to-know basis.

At 02:10, an analyst confirms encryption on a payroll server. The plan rates this severity 1. The analyst pages the incident manager, who opens a separate phone bridge and informs the CISO. Legal assesses the personal-data implications. Public relations prepares a holding statement for approval. The incident record captures each action and time.

Make readiness practical

Keep offline plans, current vendor and staff contacts, an asset inventory, network diagrams, synchronized centralized logs, activity baselines, and pre-approved responder access. A jump kit contains a clean laptop, forensic tools, write blockers, storage, cables, evidence bags, and custody forms. Review the plan at least annually and after major incidents or significant changes; test whether the contacts and access actually work.

A playbook gives steps and decisions for one incident type, such as phishing, ransomware, account compromise, or data exfiltration. A runbook often means a narrower technical procedure, such as isolating a host in the endpoint detection and response (EDR) console. Teams sometimes use the terms differently, so define them in the plan.

Write decisions responders can follow

A useful playbook names its trigger, initial triage questions, evidence to collect, responsible roles, containment and recovery actions, escalation criteria, communication steps, and closure conditions. A checklist alone cannot decide whether a compromised administrator needs a different response from an ordinary account.

Consider the report, "I entered my password on a phishing page." A playbook can guide the handler through these actions:

1. Confirm the report and locate the message.
2. Use mail and proxy logs to identify recipients, clicks, and users who entered credentials.
3. Reset exposed passwords, revoke sessions and tokens, and remove attacker-added MFA devices.
4. Search sign-in logs for attacker access and check mailbox rules that forward or hide messages.
5. Block the sender and URL, remove the message from mailboxes, and inform affected users.

Attach decisions to the steps. For example, escalate if the account is privileged or attacker sign-ins appear. State who approves disruptive changes. Automation can perform routine steps, but an action such as shutting down a critical server retains its human approval point.

Train for different responsibilities

Responders practice with the SIEM, EDR, forensic tools, and evidence procedures. Leaders practice time-sensitive decisions about service disruption and resources. All staff learn how to report suspicious activity quickly and preserve the situation for investigation. Wiping a laptop after finding a ransom note can destroy evidence and delay scoping.

A tabletop exercise tests decisions through discussion. A facilitator introduces a scenario and then adds new information in stages, called injects. Participants use the plan to explain their next actions. This exposes unclear authority, missing contacts, and conflicting assumptions without changing production systems.

A simulation, or functional exercise, makes participants carry out actions with tools in a test environment under time pressure. It can reveal that an isolation command fails or that an evidence export takes longer than expected. A full-scale exercise brings several teams, and often external partners, into the response.

Turn exercise findings into improvements

In a ransomware tabletop, five help-desk calls report shared-drive encryption at 07:30. At 08:15, an inject reveals leaked human resources files. At 10:00, a journalist calls. The team must decide who declares the incident, who approves taking servers offline, who speaks publicly, and which backups can be restored first.

If nobody knows the restore time, record an action such as, "Storage lead: test a full file-server restore by the end of the quarter and record the measured duration." Update the playbook and retest. An exercise is useful when it reveals gaps that the organization can close; treating it as a performance to pass encourages people to hide the very weaknesses it should find.

Security signals arrive through SIEM and EDR alerts, antivirus, network detection tools, cloud and identity logs, data loss prevention tools, and reports from people inside or outside the organization. A precursor points to a possible future incident, such as scanning or a new exploit for software in use. An indicator points to activity that may already have happened or be happening.

Build context around the signal

Log collection brings records from endpoints, servers, network devices, identity systems, and cloud services into reach. Synchronized clocks, commonly maintained with Network Time Protocol (NTP), help compare them. Correlation links records by attributes such as host, account, address, and time. Enrichment adds asset criticality, ownership, user role, location, and threat reputation.

A large upload from a backup server during its scheduled job has a different meaning from the same upload by an unfamiliar process on a reception laptop. Reputation can help investigate a domain, but it is only one part of the context.

Work through triage

1. Read the alert and understand what the rule detected.
2. Identify the host, user, process, and time.
3. Check asset importance, privilege, normal behavior, and relevant change tickets.
4. Examine surrounding logons, parent processes, connections, and files.
5. Check domain, address, and file-hash reputation.
6. Decide whether the activity is benign, a false positive, or a suspected incident. Escalate unresolved concerns.

An alert that correctly identifies malicious activity is a true positive. A false positive fires on benign activity. A false negative is malicious activity that produced no alert; it is missing from the queue. A true negative is benign activity with no alert.

Follow the evidence to declaration

At 07:55 UTC, an EDR alert reports an encoded PowerShell command on FIN-LT-042. Its parent, WINWORD.EXE, opened "Invoice_0310.docm" from email. PowerShell then contacted a domain registered three days earlier. These findings justify treating the case as a suspected incident and investigating promptly.

The analyst decodes the command and finds that it downloads and runs a script in memory. Proxy records corroborate the download, and the script's content establishes malicious execution. The alert is now a confirmed true positive. The organization's criterion, "confirmed execution of malicious code on a company endpoint," supports declaring the incident.

A recent domain or an encoded command alone can also occur in legitimate work. The decision rests on the combined findings and the written criterion. A user's denial is likewise insufficient to close the case without checking the data.

Keep the response record from the start

Record the ticket number, reporter, detection time in UTC, observations, evidence sources, and every action with its operator and time. Document false positives and route useful findings into tuning. If antivirus says, "Threat removed," investigate delivery and execution before closure: removal of one file leaves unanswered whether other code ran, credentials were exposed, or persistence remains.

Scoping establishes the affected hosts, accounts, applications, data, and locations, as well as the entry point and whether the attacker remains active. The first alerted host is the starting point of this search. New findings can expand the scope during containment and eradication.

Follow each useful indicator

Pivoting means searching other evidence with an attribute found in the case: a hash, file name, domain, address, account, registry key, or task name. A malicious domain on one laptop may appear in two other laptops' proxy records. A logon from one of those devices to a file server introduces another host and account to investigate.

For each branch, ask how access began, what ran, what persistence was installed, which accounts were used, where the attacker moved, which data was accessed or exported, and when activity first and last appeared. Record systems as affected, suspected, or checked with no matching findings; explain the evidence and search window behind each status.

Normalize time before sorting

A timeline combines time, source, host, user, and a description of the event. Keep original timestamps and offsets, convert them to UTC, and record known clock errors. Raw local timestamps from different zones can reverse the apparent order of an attack.

Consider these records from one investigation:

Subtract a positive offset to obtain UTC. After conversion, delivery precedes logon, execution, and connection. Preserve the date too, because conversion can cross midnight. An offset recorded with the event resolves daylight saving changes more reliably than a city name alone.

Use volumes and time gaps carefully

Flow records show 2.4 GB sent externally over 40 minutes. Decimal SI units give 2,400 MB, and the duration is 2,400 seconds:

The average is 1 MB/s. On a workstation that usually sends only a few megabytes daily, this is a strong reason to investigate exfiltration. The volume does not identify the files; combine it with file access, process, and destination evidence.

Dwell time runs from initial compromise to detection. From 2 February at 14:00 UTC to 19 February at 09:30 UTC is 16 days 19.5 hours. Longer dwell gives an attacker more opportunity and can put the earliest activity beyond log retention.

Keep uncertainty visible in the timeline

Mark confirmed findings separately from hypotheses and cite each evidence source. Write, "Records before 1 March are unavailable because retention is 30 days," when that is the gap. Writing, "The attacker arrived on 1 March," would convert the beginning of available evidence into an unsupported start date. Revisit containment when new pivots reveal another access path.

Severity describes incident impact. Priority determines work order using impact and urgency. An active upload of confidential files may need immediate containment even while another serious case is already stable. The organization's plan supplies the scale, criteria, and response expectations.

Assess business impact

Consider functional impact: which business services are unavailable or impaired? Consider information impact: was private or proprietary information exposed, or was data integrity damaged? Then assess recoverability: can existing resources restore service predictably, are extra resources needed, is the recovery effort uncertain, or is the loss irreversible?

Also examine the asset's importance, affected users and systems, data sensitivity, and whether the attacker still has access. One compromised domain controller can put many systems at risk. Counting alerted hosts without considering their role can badly understate severity.

Apply the scale in the plan

An example four-level scale is:

• Severity 1, critical: a business-critical service is down, confidential or regulated data is confirmed stolen, or an attacker holds domain administrator rights.
• Severity 2, high: servers or privileged accounts are compromised, or malware is spreading.
• Severity 3, medium: one standard account or workstation is compromised and contained.
• Severity 4, low: an attempt was blocked or a policy violation has no impact.

Under such a plan, severity 1 might require a response within 15 minutes at any hour. These labels and times belong to that example scale; apply the actual organization's criteria in a real response.

Choose the next case on risk and urgency

Three cases arrive: adware on a standard user's laptop; an unexpected addition to Domain Admins at 03:12, recorded by Security event 4728; and a defaced website with no current evidence of data access. Investigate the privileged-group change first because attacker control there threatens the whole domain. The website's integrity loss and public impact come next; the limited adware case follows.

The group-addition record still needs validation. Determine whether it was authorized, identify the added account, and check its activity. A high-risk signal deserves fast analysis even before every implication is confirmed. Classification by type, such as account compromise, ransomware, or web application attack, selects the playbook and the specialist team.

Escalate and elevate deliberately

NIST distinguishes escalation, increasing response resources or time frames, from elevation, bringing a higher management level into response decisions. A forensic specialist or retained firm adds response capacity; a CISO deciding whether to stop a critical service adds management authority. Both can happen in the same case.

Follow triggers in the plan: critical incidents reach the CISO, personal-data involvement brings in legal and the privacy officer, and suspected employee misuse brings in human resources. Update severity when evidence changes, with the time and reason. A case first treated as adware may reveal a credential stealer and wider access; its rating must change with those findings.

Evidence includes memory, disk data, logs, packet captures, messages, screenshots, cloud audit records, and responders' notes. Collection begins with the case questions and the risk of losing the data needed to answer them.

Work in order of volatility

Volatility describes how readily data changes or disappears. RFC 3227 gives this example order, from most to least volatile:

1. CPU registers and cache.
2. Routing and ARP tables, process tables, kernel statistics, and memory.
3. Temporary file systems.
4. Disk contents.
5. Remote logging and monitoring data.
6. Physical configuration and network topology.
7. Archival media, including backups.

Use this order to plan collection, while checking actual retention and conditions. A cloud log about to expire needs prompt preservation. Several responders can preserve different sources in parallel while the evidence lead tracks the work.

Preserve live data before rebooting

Live response gathers memory, processes, connections, logged-on users, open files, and other changing data from a running system. Rebooting removes memory-only malware, active connections, and possible encryption keys. Network isolation can stop communication while keeping that evidence available.

Use trusted tools from read-only external media or an EDR platform. The suspect host's own utilities may have been changed by an attacker. Loading a collection tool still changes a live system: record its commands, time, output, and unavoidable effects so another analyst can understand the acquisition.

Choose the right acquisition method

A forensic disk image is a bit-for-bit copy, including unallocated space and recoverable deleted data. Common formats include raw dd images and Expert Witness (E01). A logical copy collects selected visible files and leaves other storage areas behind.

For an offline drive, use a write blocker to prevent writes to the source during imaging. Live systems and cloud volumes use live tools or provider snapshots; an offline write blocker does not fit those acquisitions. Document the collection method and the changes it can cause.

Export cloud audit and identity logs before retention removes them. Capture virtual disk snapshots and obtain application administrator exports where appropriate. The provider contract may determine how to request evidence from layers the provider manages. A disk snapshot preserves a disk state; collect memory separately when that volatile evidence is needed.

Work through a live server collection

An EDR alert shows credential dumping on a production file server. The responder first isolates it through EDR containment, retaining the security management channel. Next, the responder captures memory to external storage and hashes the capture immediately. The team then records processes, connections, and autostart entries; exports Security, System, and PowerShell logs; and captures a virtual disk snapshot or disk image.

Only after preservation does the team decide on shutdown or rebuilding. A full antivirus scan before collection can remove samples and alter file metadata. When active destruction cannot be stopped through isolation, stopping the damage takes precedence; record why the evidence loss was accepted.

Evidence is trustworthy when the team can explain where it came from, how it was handled, and whether its contents changed. Chain of custody, integrity checks, and protected storage answer different parts of that question.

Record every handover

The chain of custody is the continuous record of collection, handling, transfer, and storage. Assign each item an identifier linked to the case. Record its description, device make and model where relevant, serial number, collection location, collector, time, and hash values. Each transfer needs the sender, receiver, time, purpose, signatures, and new storage location.

Seal and label physical items. Store digital evidence in controlled storage with access logging. A matching hash cannot explain an undocumented period when a drive was outside controlled storage; that is a custody gap even if the bytes later verify correctly.

Establish an integrity baseline

A cryptographic hash converts data into a fixed-length fingerprint. SHA-256 is a common choice. MD5 and SHA-1 have known collision weaknesses, although tools may record them alongside SHA-256. A matching SHA-256 value gives strong evidence that a later copy has the same bytes as the recorded item; it does not identify who created those bytes.

For a stable source such as a powered-down drive, calculate the source hash at acquisition and verify the image against it. The source must remain stable for this comparison to be meaningful. For live memory, capture first and hash the resulting file immediately. Memory changes during acquisition, so trying to hash the running memory twice does not provide a repeatable source baseline.

A tiny content change can produce a very different fingerprint. The text "Case IR-2026-0142" has a SHA-256 prefix of 45a24047; changing the last digit to make "Case IR-2026-0143" gives 8e5320c9. Record the full hash for evidence verification; these short prefixes illustrate the change.

Verify transfers and analyze copies

Suppose memory capture item M-03 is hashed when acquired. Before a second analyst opens a transferred copy, that analyst recalculates its SHA-256 and compares it with the recorded acquisition value. A mismatch means the copy has failed verification. Check the source item, transfer, storage, and acquisition errors before relying on it; reacquire when possible.

Hash at acquisition, after transfers, and before analysis. Keep the preserved original as the reference and analyze verified working copies. Place hashes in the evidence record where their relationship to the item and time is clear.

Preserve data for as long as required

Preservation includes read-only or write-once storage, encrypted evidence containers, controlled access, and exports of logs that would otherwise expire. Pause deletion or rotation for records the investigation needs.

A legal hold, normally issued by legal counsel, requires preservation of information relevant to actual or reasonably expected litigation or investigation. It overrides normal deletion schedules for the named data, people, and systems. IT confirms that deletion has stopped and maintains the hold until legal releases it. Rebuilding a laptop does not authorize wiping its held original drive.

Digital forensics turns preserved data into answers about entry, execution, account use, persistence, movement, and data loss. Start with these case questions so examination has a purpose.

Follow the four forensic phases

NIST SP 800-86 describes collection, identifying and acquiring data; examination, extracting relevant information while preserving integrity; analysis, interpreting those findings; and reporting, explaining findings, methods, tools, and recommendations. Extracting a command line is examination. Deciding what it shows about the incident is analysis.

Read Windows records in context

The Security log can show the following, when the relevant auditing is enabled:

Event 7045 in the System log records service installation. PowerShell script block logging uses event 4104 in a PowerShell log. Keep the channel with the event ID so another analyst can retrieve the right record.

Repeated failures followed by a success for the same account suggest password guessing, but also check the source and authorization. A group addition may be routine administration or attacker privilege gain. The record establishes the action; surrounding evidence establishes its meaning.

Windows persistence can appear in Run and RunOnce registry keys, scheduled tasks, or services. Prefetch can show that a program ran, when, and how often on systems where it is enabled. Browser history, downloads, Recycle Bin contents, and Master File Table ($MFT) metadata add file and user activity.

Check Linux, memory, and network evidence

Linux authentication records commonly appear in /var/log/auth.log on Debian and Ubuntu and /var/log/secure on Red Hat-based systems. Examine shell history such as ~/.bash_history, cron jobs, systemd units, /etc/passwd, added keys in ~/.ssh/authorized_keys, and web access logs. History and local logs can be incomplete or changed, so seek independent records.

Memory analysis, for example with Volatility, can expose processes, injected code, loaded modules, command lines, and connections that never reached disk. Packets and flow records supply destinations, timing, and volumes. Encrypted traffic still leaves useful metadata even when its content is unavailable.

Build and challenge an explanation

At 02:09 UTC, event 4624 type 10 records svc_backup logging in from an internal host. Prefetch shows RCLONE.EXE first ran at 02:14. Firewall flows show 2.4 GB sent externally between 02:15 and 02:55. The sequence supports a hypothesis of RDP access followed by an rclone upload.

To establish the connection, seek process-linked network telemetry, the command line, rclone configuration or logs, and evidence that this account use was unauthorized. A legitimate administrator can use the same software. Report observed facts separately from the interpretation and state which gaps remain.

Anti-forensics attempts to hide activity through log clearing, deletion, or changed timestamps, called timestomping. Event 1102 can expose Security-log clearing. NTFS creation times in $STANDARD_INFORMATION that precede those in $FILE_NAME can indicate timestomping. Investigate these clues alongside other artifacts; missing local records leave a question to test against remote logs and other evidence.

Containment limits damage, spread, and data loss while creating time for investigation. Choose it early using the plan, the known scope, and the consequences of leaving the attacker active.

Compare the trade-offs

Consider the potential damage and theft of resources, evidence preservation, service availability, the time and resources needed, effectiveness, and duration. A measure that works for hours may be unsuitable for several weeks. Record the expected effect and the cost to the business so the decision can be reassessed as the scope changes.

Short-term containment acts immediately: isolate a host, disconnect a network path, block an attacker domain or address, disable a compromised account, revoke sessions and tokens, or stop a service. Long-term containment keeps essential work operating under restrictions while eradication is prepared. It may use a restricted network segment, tighter permissions, temporary firewall rules, emergency patches, and increased monitoring.

Distinguish levels of restriction

Segmentation limits which systems can communicate. Isolation cuts a host off except, possibly, for its security management channel. Removal takes a system out of service entirely, for example by powering it off. A shutdown loses volatile memory; successful network isolation can preserve that evidence while blocking attacker communications.

An EDR console may report an isolation request before it succeeds. Check the resulting state and traffic. Also verify that the allowed management channel reaches only the security infrastructure needed for response.

Coordinate known access paths

If an attacker has several footholds, blocking one host can alert them while leaving other access available. They may switch accounts, destroy data, or launch encryption. Coordinated containment removes known paths together after sufficient scoping. Active encryption or exfiltration requires immediate action to stop harm; waiting for perfect knowledge can make the loss worse.

In a phishing case, FIN-LT-042 and FIN-LT-057 contacted the attacker domain, and a finance administrator account reached a file server. At 10:30 UTC, responders isolate both laptops, block the domain at DNS and the proxy, disable the administrator account, and revoke its sessions. They then restrict file-server access, add logging, and continue environment-wide indicator searches.

The coordination covers hosts, network access, and identity. Disabling an on-premises account alone can leave an existing cloud token usable. Include those sessions in the containment plan and verify the result in identity logs.

Check that containment is holding

Confirm EDR isolation status, inspect DNS and proxy logs for new attacker connections, and check whether compromised accounts still authenticate successfully. Search for activity from newly discovered indicators and revise the containment boundary when necessary.

Some organizations choose controlled observation to learn more about an intruder before containment. Because this leaves a route for further harm, it requires leadership and legal approval. Deleting the detected malware file is also insufficient as a containment strategy: other access, persistence, and exposed identities can remain active even after that file disappears.

Eradication removes the attacker and what they left behind: malware, backdoors, web shells, tasks, services, registry entries, accounts, SSH keys, and other persistence. Remediation repairs the weaknesses that made the intrusion possible. Both depend on checking the full incident scope.

Decide whether trust can be restored by cleaning

Rebuilding from a known-good image or infrastructure-as-code template is more reliable when an attacker had administrator rights, used a rootkit, or left unknown persistence. Targeted cleaning can be suitable for well-understood commodity malware on a low-value system, provided verification covers the known changes.

A backup made after compromise may restore the attacker's access along with legitimate files. Check when compromise began, what the backup contains, and whether the image or template is trusted before using it. Preserve required evidence before rebuilding an affected system.

Remove identity access as well as files

Contain compromised accounts and sessions promptly. Coordinate durable credential replacement after closing attacker access paths and establishing a clean place to use the new secrets. Otherwise an intruder can steal the replacements from the same compromised host.

Reset exposed user and service credentials, revoke tokens, sessions, and API keys, and rotate application secrets. Remove attacker-added MFA methods, forwarding rules, and unauthorized accounts. Consider every credential exposed on compromised systems, including accounts that have not yet raised their own alert.

For suspected forged Kerberos tickets, coordinated Active Directory recovery includes resetting the KRBTGT password twice with replication between resets. Domain controllers can accept tickets protected by the current or previous password, so one reset leaves the previous key relevant. This is a coordinated domain action with verification, not an isolated workstation cleanup step.

Repair the cause and verify the repair

Patch exploited software, correct misconfigurations, require MFA where it was missing, remove excess privileges, and close exposed services. If a full fix is unavailable, apply a compensating control such as a web application firewall rule or VPN-only access, and record the remaining risk.

A public server contains a web shell introduced through an unpatched upload flaw. The team checks for other vulnerable servers and finds two more. It rebuilds all three from a hardened template, deploys the patched application, rotates the database secret stored in the application configuration, and hunts for requests to the web shell across server logs.

A vulnerability scan confirms the flaw is fixed. The team checks persistence locations, scans with current signatures, searches all known indicators, and monitors for attacker logons and connections. In this case, seven days of monitoring show no successful requests to the web shell path. The plan's eradication criteria determine whether this evidence is sufficient.

Patching the upload flaw would close one entry path but leave any existing backdoor untouched. Deleting only the web shell would remove one artifact while leaving the exploitable application in place. Verification therefore needs evidence about both remaining attacker access and the repaired weakness.

Recovery returns systems and services to normal operation through restoration, rebuilding, reconnection, and functional testing. It can begin for unaffected or verified-clean systems while eradication continues elsewhere.

Select trusted restoration sources

Check backups for corruption, encryption, and signs of compromise. Choose a point before the attacker entered, and verify the version or hash of rebuild images. A recent backup may contain the same persistence the team just removed. Its date alone does not establish that it is clean.

Identify the work that restoration will omit. A backup from 3 March at 23:00 UTC is 7 hours 20 minutes older than a compromise beginning on 4 March at 06:20 UTC. That interval describes the backup's age at compromise. Restoring it loses every later change until the system went out of service unless clean changes can be recovered elsewhere, including legitimate work done after 06:20.

Possible sources include verified clean files or users' local copies. Validate them before merging recovered changes so restoration does not reintroduce malicious content or overwrite trusted data.

Restore in dependency order

Business priorities and technical dependencies work together. An ERP application needs its database; the database and application may need network, DNS, and identity services first. A typical order is network and identity, database, ERP, then reporting tools. Starting the application first can produce a running process with no useful service behind it.

Use agreed recovery targets, including acceptable downtime and data loss, as inputs to the order. Confirm that the dependencies themselves are trusted before connecting restored systems to them. A critical application joined to a compromised identity service remains exposed.

Apply release-from-isolation criteria

Before reconnecting, verify that the system is rebuilt or cleaned, patched, and free of known persistence. Rotate exposed credentials, confirm that security tools are running and reporting, establish enhanced monitoring, and obtain asset-owner sign-off. Reconnect in stages so unexpected behavior can be contained before it affects the entire service.

For the rebuilt file server, the team restores a checked backup, scans the data for known indicators, restores permissions, and asks the owner to test opening and changing representative files. Security checks include EDR reporting and expected connections. The owner approves service release after these tests, and the team starts its agreed monitoring period.

Distinguish release from the end of recovery

Compare processes, connections, performance, and service behavior with the normal baseline. Enhanced monitoring might run for 30 days in one response plan, with added alerts for the incident's indicators. Set the period and criteria according to the case and the plan.

The incident manager declares recovery complete when services are restored and stable, the monitoring period shows no attacker activity, and response documentation is complete.

Ransomware encrypts data or locks systems and demands payment for access. In double extortion, attackers also steal data and threaten publication. Data extortion can occur without encryption, so visible file damage is only one part of the investigation.

Recognize the activity before encryption

A common attack sequence begins with phishing, stolen remote-access credentials, or an exposed vulnerability. Attackers discover systems, steal credentials, move laterally, disable security tools, attack backups, and exfiltrate data before mass encryption.

Warning signs include unexpected remote management tools, new privileged accounts, large uploads, and shadow-copy deletion. A command such as vssadmin delete shadows needs investigation in its process and user context. These precursors can give defenders a chance to intervene before widespread encryption starts.

Follow the first three response steps

CISA's ransomware checklist places these actions in order:

1. Identify and isolate affected systems immediately. Prioritize critical systems. If several systems or subnets are affected, disconnect at the switch level when needed. Protect unaffected critical systems and backups from the same access paths.
2. Power down only if network disconnection is impossible. Shutdown sacrifices volatile evidence, including possible keys and memory-only activity, but may be necessary to prevent further spread when isolation cannot be achieved.
3. Triage systems for restoration. Use the critical-asset list and technical dependencies to identify which services must return first.

Coordinate using a phone call or another out-of-band channel. Attackers may monitor company email or chat and react by accelerating destruction. Verify isolation succeeded before relying on it.

Preserve evidence and establish the attack's reach

Capture memory and disk evidence from a representative sample of affected systems, and snapshot relevant cloud volumes. Preserve ransom notes, encrypted-file extensions, malware samples, logs, and indicators. These help identify the variant, reconstruct entry and movement, and support the response partners' investigation.

Use the note, extension, and samples to check for an available decryptor through trusted services such as No More Ransom or law enforcement. Also investigate earlier access and exfiltration. Recovering encrypted files does not explain whether attackers still have an account, token, or backdoor.

At 03:40 UTC on a Saturday, two file servers show about 1,200 renames per minute, or 20 per second, with the extension ".lckd". The responder isolates the servers and the domain controller used by the attacker account, and the network team disables the affected segment's uplink. Systems stay powered on. A handler captures one server's memory and saves the note while another checks protected backups.

Activate the plan's response partners

The incident manager involves leadership, legal, the insurer, and law enforcement according to the plan. Insurance terms can require prompt notice or approved response firms. Legal determines applicable notification duties when data is involved. Track these workstreams while technical containment continues. Immediate reinstallation would destroy evidence and could return a server to a network where the attacker still has access.

Ransomware recovery must remove the attacker's ability to repeat the damage. Contain known access, eradicate persistence, establish a clean environment, replace exposed credentials, and restore checked data onto rebuilt systems. Release only verified-clean systems back into service.

Protect and test the recovery source

Offline, immutable, or otherwise protected backups can survive attempts to delete online copies. Before use, check that the selected point predates compromise, is not encrypted, and contains no known attacker tools or persistence. An unencrypted backup from the attacker's dwell period can still be unsafe.

Measure restore throughput in advance. In decimal SI units, 48 TB is 48,000,000 MB. At a measured 400 MB/s, continuous transfer takes:

That is 120,000 seconds, or about 33.3 hours. If critical services require only 6 TB, their transfer is:

That is about 4.2 hours. These are transfer times. Rebuilds, validation, dependencies, and reconnection also take time, so they must appear in the operational recovery estimate. Restore critical services in dependency order instead of queuing every data set equally.

Investigate identity infrastructure

Human-operated ransomware often involves stolen privileged credentials. Establish whether privileged accounts, domain controllers, or KRBTGT were compromised. When domain compromise is established or reasonably suspected, coordinate domain recovery: rebuild or restore trusted controllers, reset privileged and service credentials, review Group Policy, and perform the required KRBTGT resets with replication between them.

Group Policy can distribute changes across many machines. Leaving a malicious policy or trusted attacker-controlled identity in place can undermine otherwise clean server rebuilds. The scope determines how wide this work must be; encryption on one workstation alone does not establish domain compromise.

Understand what payment can and cannot settle

CISA and the FBI advise against ransom payment. A payment gives no guarantee of a working decryptor or deletion of stolen data. Decryptors may be slow, faulty, or incomplete. Payment funds further crime, and the victim may be targeted again. In 2021, the US Treasury's Office of Foreign Assets Control (OFAC) warned that ransomware payments can violate sanctions. Leadership works with legal counsel and usually the insurer; an analyst does not decide to pay.

Present leadership with verified recovery options, measured restore times, known data exposure, and unresolved questions. Check trusted decryptor sources before treating payment as the only route. A decryptor does not remove persistence or repair the initial access path.

Continue the stolen-data response

Restored service does not resolve disclosure. Identify which data was taken and who is affected, support legal's notification assessment, and monitor relevant leak sites. An attacker's promise to delete copies cannot be verified.

Afterward, strengthen protected backups and restore tests, require MFA on remote access, and detect early activity such as backup deletion. Share appropriate indicators with authorities or sector groups through the organization's approved process.

A post-incident review, or lessons-learned review, examines what happened, how the response worked, and what should change. Share useful lessons as soon as they appear during the incident. Hold a structured review after significant incidents while the evidence and decisions are still fresh.

Prepare a shared account of the incident

A review commonly takes place within a few days to two weeks of closure. Bring the responders, technology staff, asset owners, management, and other involved parties. Use a facilitator to keep the discussion focused. A severe incident deserves its own review; minor cases can be grouped in regular sessions.

Prepare the incident timeline, action log, scope, impact, and relevant measurements. Distinguish what was known at a decision's time from information discovered later. Otherwise the team may judge a reasonable early choice using facts that were unavailable to the person making it.

Ask about the response as well as the attack

Work through what happened and when, how detection occurred, and which steps worked well. Then examine delays, unclear instructions, missing tools, missing permissions, and information needed sooner. Identify the precursors or indicators that could reveal another attempt.

A blameless review focuses on systems, processes, and decisions. Recording that someone clicked a phishing link is necessary to explain entry. Stopping there gives little guidance on why one click allowed access to a file server. Ask which controls, privileges, and response arrangements allowed the impact to grow.

Keep what worked and repair what failed

In a phishing response, EDR detected execution within 15 minutes. Keep the detection and verify it remains effective. Containment took 2.5 hours because the on-call analyst lacked EDR isolation rights. Create a specific access change with an owner and a test, using the plan's authority limits.

The file server lacked file access auditing, so the team could not establish which files were read. Record that evidence gap and enable suitable auditing. The account playbook omitted cloud token revocation; update it and have responders practice the revised step. These findings address different failures and need separate actions.

Write an after-action report people can use

The report contains an executive summary, incident description and timeline, scope and impact, root cause and contributing factors, timed response actions, what worked and failed, corrective actions with owners and due dates, and incident metrics. Use the evidence to support the findings and keep unresolved questions visible.

Feed approved changes into the plan, playbooks, detections, contact lists, training, and risk register. Share indicators or lessons with appropriate groups through the approved process. Give the action list a tracking location so later meetings can check progress.

"Communicate better" leaves the owner, change, and success test undefined. A useful action could specify a separate incident phone bridge, its owner, a due date, and a test that on-call staff can join without company identity access. The review is complete as a meeting; the improvement work continues until its actions are verified.

Root cause analysis (RCA) asks why the conditions for an incident existed. The proximate cause is the direct technical cause. Contributing factors made the incident more likely or more damaging. An underlying process failure can explain why those factors remained in place.

Follow the causes beyond the first failure

The 5 Whys technique repeatedly asks why a failure was possible. The name describes an approach, not a requirement to stop at exactly five questions. In a ransomware case:

1. Servers were encrypted because the attacker gained domain administrator rights.
2. Those credentials were harvested from a reachable server.
3. The attacker reached it through a contractor VPN account without MFA.
4. The account had a temporary MFA exemption from a migration two years earlier.
5. Exemptions had no expiry date or review process.

The missing review process is an underlying cause in this chain. MFA absence and exposed privileged credentials remain technical factors to fix. A fishbone diagram, also called an Ishikawa diagram, groups possible causes under headings such as people, process, technology, and environment. Timeline analysis asks which control could have stopped or revealed each stage.

Write actions with a proof of completion

A corrective action needs a specific change, owner, due date, measurable result, and verification. For example: "Enforce MFA on all 214 VPN accounts by 30 November; owner: identity and access management lead; verify with a report showing zero VPN accounts without MFA."

Track actions in the ticket or risk system and test whether they work, including in a later exercise. Preventive actions reduce recurrence; detective actions reveal the next attempt sooner. Adding an expiry review addresses the exemption process, while an alert for use of exempt accounts adds detection. One action need not carry every part of the remedy.

Define the metric before calculating it

Mean time to detect (MTTD) averages the interval from malicious activity starting to its detection. Containment time commonly runs from detection to containment; remediation time runs from detection to the fix. Teams also track dwell time, incident categories and severity, and internally detected versus externally reported cases. State endpoints because organizations use some metric names differently.

Four detection delays are 2, 30, 6, and 82 hours:

The mean is 30 hours. Sort the values as 2, 6, 30, and 82; the median is the average of the middle two:

The 82-hour case raises the mean substantially. Report both measures and investigate that case. If containment took 1.5, 4, 3, and 9.5 hours, the mean is 18 divided by 4, or 4.5 hours.

Compare trends only with consistent definitions and suitable context. A team rewarded only for fast ticket closure may close cases before analysis is finished. Pair speed with evidence of complete response and verified actions so the metric supports improvement.