What To Do Immediately After a Cyberattack

The moment you realize your business has been hit by a cyberattack is one of the most disorienting experiences in modern professional life. Systems are down or behaving strangely. Files are encrypted or missing. An employee is panicking about an email they clicked. A customer just called to say their credit card was used fraudulently. Something is wrong — and the pressure to act immediately is overwhelming.

That pressure is exactly what attackers count on. Panic-driven decisions in the first hours after a cyberattack are responsible for some of the most expensive mistakes organizations make: destroying forensic evidence by rebooting infected machines, tipping off attackers still in the network by acting too visibly, paying ransoms before exhausting alternatives, or failing to notify the right parties within legally required timeframes.

This guide is the resource you want to have read before an attack happens — and the one to return to when it does. It covers every critical action in the correct sequence, from the first five minutes to the first thirty days, including what to do, what not to do, and who needs to be involved at every stage.

Before Anything Else: Stay Calm and Think Before You Act

This is not a platitude. In the immediate aftermath of discovering a cyberattack, the instinct to act fast and decisively can cause more damage than the attack itself. Before touching anything, take sixty seconds to assess what you know, what you do not know, and who you need to contact.

The specific things you do not know in the first moments matter enormously:

You do not know the full scope of the attack — which systems are affected, which are not, and whether the attacker still has active access
You do not know the attack vector — how the attacker got in, and whether that vector is still open
You do not know what data has been accessed, exfiltrated, modified, or destroyed
You do not know whether the visible symptoms are the full extent of the compromise or the visible tip of a much deeper one

Acting aggressively on incomplete information — shutting everything down, wiping systems, resetting all passwords simultaneously — can destroy forensic evidence, alert an attacker who still has access that they have been discovered, and complicate the recovery process substantially. Measured, sequential action based on the best available information produces better outcomes than reactive chaos.

Designate a single person to lead the response immediately. In a small business, this is typically the owner or IT lead. In a larger organization, this is the Incident Response Lead or CISO. All actions and communications should flow through this person to prevent conflicting decisions and information leaks.

The First 30 Minutes: Contain, Don’t Clean

The goal in the first thirty minutes is not to fix the problem. It is to stop it from getting worse. Containment — limiting the attacker’s ability to move, access more systems, or exfiltrate more data — is the exclusive priority at this stage. Remediation comes later, once you understand what you are actually dealing with.

Step 1: Identify and isolate affected systems

The first operational task is to identify which systems show signs of compromise and isolate them from the rest of the network without shutting them down. Isolation prevents lateral movement — the attacker’s ability to spread from an initial foothold to other systems on the same network. Keeping systems running preserves the volatile memory (RAM) that may contain evidence of how the attack was conducted.

How to isolate a system without shutting it down:

Disconnect the ethernet cable from the affected device
Disable Wi-Fi on the affected device (through the operating system settings, not by turning off the router)
Do not log out of active sessions on the affected device — open sessions may contain forensic evidence
Do not run antivirus scans, system cleaners, or remediation tools on the affected device yet — these can overwrite evidence
Place a physical sign or marker on the device indicating it is under investigation and must not be touched

Isolation should extend to network segments where possible. If the affected system is on a subnet that can be isolated at the network level without taking down unaffected systems, do so. This requires network segmentation to have been implemented in advance — which is one of the strongest arguments for segmentation as a proactive security control.

Step 2: Do not turn off affected systems (with one exception)

This is the instruction that counterintuitive but technically critical. Turning off a compromised system destroys the contents of RAM — volatile memory that may contain encryption keys (critical in ransomware recovery), active attacker processes, credential tokens, network connections, and other forensic artifacts that exist only in memory and are lost permanently on shutdown.

The one exception: if you are watching active data destruction or encryption in real time — files visibly disappearing, a ransomware encryption screen actively progressing — the calculus changes. In that specific scenario, the evidence already being generated by the live encryption process may be less valuable than stopping the damage immediately. Even then, a hard power-off (holding the power button) is preferable to a clean shutdown, which allows the operating system to flush memory contents in a more organized (and evidence-destroying) way.

Step 3: Preserve evidence before anything else

A cyberattack is simultaneously a security incident and potentially a legal matter — for insurance claims, regulatory notifications, law enforcement involvement, or civil litigation. Evidence that is not preserved in the first hours may be lost permanently, and lost evidence can affect insurance payouts, legal proceedings, and the ability to understand and remediate the attack fully.

Immediate evidence preservation actions:

Photograph or screenshot everything visible — error messages, ransom notes, unusual processes, locked screens, anomalous network activity in monitoring tools. Use a phone to photograph screens rather than taking screenshots on the affected machine, which may alter timestamps or metadata
Document the timeline — write down (on paper, not on a potentially compromised system) exactly when the issue was first noticed, what was observed, and what actions have been taken since. Timestamps matter in forensic investigation and in meeting regulatory notification deadlines
Preserve logs — if you have access to centralized logging (SIEM, firewall logs, email gateway logs) from an unaffected system, preserve a copy of the logs from the period surrounding the suspected compromise. Logs are the primary forensic record of what occurred and are often the first thing attackers attempt to delete
Record network traffic — if your infrastructure has packet capture capability, initiate or preserve captures from the period of suspected compromise

The First Two Hours: Assess and Communicate

With immediate containment underway, the next priority is understanding what you are dealing with and ensuring the right people know about it. These two activities should proceed in parallel — you do not need a complete picture before beginning notifications, and you will learn more during the notification process than before it.

Step 4: Assess the scope and type of attack

Gathering enough information to categorize the attack type and estimate its scope is the prerequisite for every decision that follows. Different attack types require meaningfully different responses, and some decisions — particularly around regulatory notification timelines — depend on knowing what kind of data was involved.

Key assessment questions to answer as quickly as possible:

Question	Why it matters
What type of attack appears to have occurred?	Ransomware, data breach, account compromise, DDoS, and malware infections require different response approaches
Which systems and data are confirmed affected?	Determines the scope of the response, the notification requirements, and the recovery path
What data may have been accessed or exfiltrated?	Critical for determining regulatory notification obligations and assessing harm to individuals
Is the attacker still active in the network?	Determines whether containment is complete or ongoing, and whether remediation can begin
When did the compromise likely begin?	Informs the scope of log review, data exposure assessment, and backup integrity evaluation
How did the attacker gain initial access?	Required to close the attack vector and prevent reentry during recovery

You will not have complete answers to all of these questions in the first two hours. The goal is to gather enough information to make informed decisions about next steps — not to conduct a complete forensic investigation before acting.

Step 5: Activate your incident response plan

If your organization has a documented incident response plan — and every organization that uses computers should have one — now is when you activate it. The plan should specify who is in the response team, what their roles are, what external resources to contact, and what the decision thresholds are for various response actions.

If you do not have an incident response plan, use this crisis as the catalyst to create one once the immediate incident is resolved — and in the meantime, work through the steps in this guide sequentially.

The core incident response team typically includes:

Incident Response Lead — coordinates all activities and serves as the single decision-making authority during the response
IT/Security lead — manages technical containment, investigation, and remediation
Legal counsel — advises on regulatory notification obligations, law enforcement involvement, and liability considerations
Communications lead — manages internal and external communications, including customer and media notifications
Senior executive or owner — provides organizational authority for major decisions (engaging external resources, making ransom payment decisions, initiating regulatory notifications)

Step 6: Contact your cyber insurance provider

If your organization has cyber insurance — and this incident illustrates exactly why it should — contact your provider immediately. Do not wait until you have a complete picture of the incident. Most cyber insurance policies have notification requirements that, if not met promptly, can affect coverage. Many also provide direct incident response resources: access to forensic investigators, legal counsel with data breach experience, public relations support, and ransom negotiation services, all covered under the policy.

Your insurer is a resource, not just a payer. Contact them as early in the response as possible, even if you are uncertain whether the incident will result in a claim.

Step 7: Engage external incident response support

Most small and medium businesses do not have the internal security expertise to conduct a full incident response investigation and remediation independently. Attempting to do so risks missing attacker persistence mechanisms that will result in reinfection, failing to collect forensic evidence properly, and missing regulatory compliance requirements that require specific investigation documentation.

External resources to consider engaging immediately:

Managed Security Service Provider (MSSP) or incident response firm — if you have a retained IR firm, activate them now. If not, your cyber insurer may have a preferred provider list. CISA (Cybersecurity and Infrastructure Security Agency) also maintains a list of vetted incident response resources for businesses that cannot afford commercial IR firms
Forensic investigators — for any incident involving significant data exposure, regulatory notification obligations, or likely legal proceedings, professional forensic investigation produces evidence that is legally defensible and catches persistence mechanisms that internal investigations frequently miss
Legal counsel with data breach experience — general corporate attorneys are typically not equipped to advise on the specific regulatory landscape of data breach notification. Engage counsel with specific data breach experience as early as possible

The First 24 Hours: Notifications and Decisions

Within the first 24 hours, several decisions and notifications need to occur — some because they are legally required within specific timeframes, some because the people affected deserve to know, and some because early notification enables others to take protective action on your behalf.

Step 8: Notify law enforcement

Reporting a cyberattack to law enforcement is not universally mandatory, but it is generally advisable for incidents above a minimal threshold of severity. Law enforcement notification serves several purposes: it creates an official record of the incident, may trigger intelligence resources and investigative capabilities not available to private organizations, can assist in ransom payment decision-making and cryptocurrency tracing, and is required in some regulatory contexts.

In the United States, relevant reporting channels include:

FBI Internet Crime Complaint Center (IC3) at ic3.gov — the primary federal reporting mechanism for cybercrime, including ransomware, BEC, and data theft
CISA (Cybersecurity and Infrastructure Security Agency) at cisa.gov/report — particularly relevant for critical infrastructure sectors; CISA can also provide technical assistance
Local FBI field office — for significant incidents, a direct call to the local field office initiates a faster response than the IC3 online form
Local law enforcement — while cyber capabilities vary significantly, a local police report creates a paper trail useful for insurance and legal proceedings

Reporting to law enforcement does not obligate you to cooperate in ways that are not in your interest, does not make the incident public, and does not prevent you from taking any independent action. The primary reason organizations avoid reporting is fear of reputational damage — but law enforcement reports are not automatically public, and the investigative resources they can unlock often outweigh this concern.

Step 9: Assess and fulfill regulatory notification obligations

This is the step where legal counsel becomes essential rather than advisable. Data breach notification law is complex, jurisdiction-dependent, and carries significant penalties for non-compliance. The regulatory landscape relevant to your incident depends on the nature of the data involved, your industry, the location of affected individuals, and the jurisdictions in which you operate.

Key regulatory frameworks with notification requirements:

Regulation / Framework	Notification Deadline	Applicability
GDPR (EU)	72 hours to supervisory authority; “without undue delay” to affected individuals if high risk	Any organization processing EU residents’ personal data
HIPAA (US)	60 days to HHS; 60 days to affected individuals; immediate media notification if 500+ in a state	Healthcare providers, health plans, and their business associates
PCI DSS	Immediately upon suspected compromise	Any organization that stores, processes, or transmits cardholder data
SEC (US public companies)	4 business days of determining material impact	SEC-reporting public companies
US State breach notification laws	Varies by state — from 30 to 90 days; some require “expedient” notification	Organizations holding personal data of residents in relevant states
NIS2 Directive (EU)	24 hours initial warning; 72 hours incident notification; 1 month final report	Essential and important entities in designated sectors across EU member states

Missing notification deadlines carries consequences that range from regulatory fines (potentially in the millions under GDPR) to personal liability for executives. Engage qualified legal counsel immediately rather than attempting to navigate this landscape independently under the pressure of an active incident.

Step 10: Notify affected customers and partners

Beyond regulatory requirements, there is an ethical obligation — and a practical business interest — in notifying affected customers, clients, and business partners promptly and transparently. People whose data has been exposed or whose systems may be at risk because of their relationship with your organization deserve to know so they can take protective action.

Effective customer breach notification includes:

A clear, plain-language description of what happened and when
Specific information about what data was or may have been accessed
What the organization is doing in response
Specific, actionable steps the recipient should take to protect themselves
Contact information for questions and concerns
Where applicable, information about credit monitoring or identity theft protection services being provided

What to avoid in breach notifications: vague, minimizing language designed to limit perceived severity (“a security incident that may have affected some users”); delays beyond what regulatory and ethical obligations permit; and notifications that provide no actionable guidance to the recipient.

Research consistently shows that transparent, prompt breach notification — while uncomfortable — produces better long-term customer trust outcomes than delayed or minimized disclosure that customers later learn was inadequate.

Step 11: Communicate internally with employees

Employees who are not part of the incident response team need to know what happened, what they should and should not do, and where to direct questions — from both operational and communications perspectives. Leaving employees in the dark creates rumors, encourages speculation, and results in uncoordinated, potentially damaging external communications as employees discuss the incident with customers, vendors, or on social media.

Internal communication should be:

Issued promptly — before employees hear about the incident through other channels
Clear about what employees should do differently right now (stop using certain systems, change specific passwords, refer customer inquiries to a specific contact)
Clear about what employees should not do (do not discuss details externally, do not attempt to investigate independently, do not speculate about the cause or scope with anyone outside the designated team)
Followed by updates as significant developments occur — sustained silence after the initial notification creates as much anxiety as no notification at all

The Ransomware Decision: To Pay or Not to Pay

If your incident is a ransomware attack, the question of whether to pay the ransom demand will arise quickly — often within the first 24 hours as attackers impose deadlines designed to prevent thoughtful deliberation. This is one of the most consequential decisions you will make, and it deserves specific, detailed guidance.

The arguments against paying

Payment does not guarantee recovery. Approximately 20–25% of organizations that pay a ransomware demand do not receive a working decryption key, or receive one that only partially restores their data. Payment is a transaction with criminals who have no legal obligation to honor it.
Payment funds future attacks. Ransomware operators reinvest ransom payments into infrastructure, tools, and team expansion. Paying perpetuates the ecosystem that attacked you.
Payment may violate sanctions regulations. Several ransomware groups are subject to OFAC (Office of Foreign Assets Control) sanctions. Paying a sanctioned entity may constitute a federal crime, regardless of whether the paying organization knew of the sanctions status. Legal counsel must assess this risk before any payment is made.
Payment marks you as a payer. Ransomware groups share information about successful extortions. Organizations that pay are more likely to be targeted again.
Payment does not address the underlying compromise. Even if you pay and recover your data, the attacker still has access to whatever was exfiltrated before encryption, and the initial access vector may still be open.

The arguments for paying (in specific circumstances)

If backups are unavailable, incomplete, or compromised, and the encrypted data is critical to business continuity, payment may be the only path to operational recovery within an acceptable timeframe.
If the attacker has threatened to publish exfiltrated data and that data’s exposure would cause catastrophic harm to individuals or the organization, the calculus changes — though it is worth noting that publishing threats are sometimes executed even after payment.
If the cost of recovery without payment significantly exceeds the ransom demand and the downtime risk is existential.

Before making a payment decision

Exhaust all backup recovery options first — verify backup integrity and determine the realistic recovery timeline from backup
Engage a ransomware negotiation specialist — cyber insurers and IR firms often have specialists who can verify that a decryptor exists and works, negotiate the demand down (typically by 30–70%), and handle cryptocurrency procurement
Have legal counsel assess OFAC sanctions risk against the identified or suspected threat actor
Consult with law enforcement — the FBI actively discourages ransomware payments but can provide intelligence about the specific group and whether payment is likely to result in working decryption
Do not negotiate directly with attackers without professional guidance — untrained negotiation can increase demands, accelerate deadlines, and eliminate leverage

The First Week: Remediation and Recovery

Once immediate containment is in place, evidence is preserved, notifications are underway, and the scope of the attack is reasonably understood, the focus shifts to remediation — removing the attacker’s access and tools — and recovery — restoring systems and operations to a functional state.

Step 12: Confirm the attacker is fully evicted

This step is skipped, rushed, or performed inadequately more often than almost any other in the response process — and it is the cause of the reinfection events that turn a manageable incident into a catastrophic one. Before restoring from backup or rebuilding systems, you must be confident that the attacker no longer has active access to your environment.

Incomplete eviction leaves several common persistence mechanisms in place:

Backdoors and remote access tools installed by the attacker on compromised systems
Compromised credentials that still grant legitimate access to your systems
Attacker-controlled accounts created during the compromise
Malicious scheduled tasks or startup items that will reactivate malware after reboot
Compromised supply chain access through vendor or third-party accounts that the attacker used as an entry point

Full eviction requires a thorough forensic investigation of all potentially compromised systems — ideally by professional IR investigators who can identify attacker tools and techniques that internal staff may not recognize. This investigation must precede system restoration, not follow it.

Step 13: Reset credentials across the organization

Any credentials that were potentially exposed during the incident — and when uncertain, assume all credentials were exposed — must be reset. This includes:

All employee account passwords, prioritizing administrative and privileged accounts first
Service account passwords for automated processes and integrations
API keys and tokens for any connected services
VPN and remote access credentials
Any credentials stored on systems confirmed to have been compromised
MFA enrollment — review and revoke any MFA devices or authenticator enrollments on affected accounts, as attackers may have enrolled their own devices

Credential resets should be completed before systems are reconnected to the network or restored from backup — restoring a system with compromised credentials still in place simply provides the attacker with a fresh entry point into a clean environment.

Step 14: Restore from clean backups

When restoring from backup after a ransomware attack or destructive malware incident, the most critical question is: how far back does the compromise predate the visible attack? Ransomware operators commonly establish initial access weeks or months before triggering the visible encryption event — a period during which they are exploring the network, exfiltrating data, and specifically compromising backup systems to maximize the effectiveness of the attack.

Restoring from a backup taken one day before the visible attack may restore a backup taken in the middle of an active, undetected compromise. Forensic investigation of the initial access timeline is the prerequisite for selecting a trustworthy backup point.

When selecting backup restoration points:

Use forensic investigation findings to identify the earliest possible compromise date
Select backup restoration points that predate that date by a meaningful margin
Verify the integrity of selected backups before restoration — some attackers specifically corrupt backup files to prevent recovery
Restore into a clean environment with all attacker tools removed and credentials reset — not onto systems that may still be compromised

The First 30 Days: Post-Incident Review and Hardening

Recovery from the immediate incident is not the end of the response — it is the beginning of the work that prevents a recurrence. The post-incident period is when the lessons learned from the attack should be systematically translated into security improvements that close the vulnerabilities that made the attack possible.

Conduct a thorough post-incident review

A post-incident review — sometimes called a “lessons learned” exercise — is a structured examination of what happened, how the response performed, and what should change as a result. It is most effective when conducted within two to four weeks of the incident, while details are still fresh, with participation from everyone involved in the response.

The review should address:

Root cause — the specific vulnerability, misconfiguration, or human action that enabled the initial compromise. Without identifying and addressing the root cause, the vulnerability remains open.
Detection gap — how long did the attacker have access before detection, and why? What monitoring or detection capabilities would have caught it earlier?
Response performance — what worked well in the response? What caused delays or complications? What decisions were made with insufficient information?
Policy and control gaps — what security controls, if they had been in place, would have prevented or significantly limited the attack?
Prioritized remediation plan — a specific, time-bound list of security improvements with assigned ownership and deadlines

Close the attack vector

The specific vulnerability that enabled the initial access must be identified and closed before operations return to normal. Rebuilding a clean environment without closing the initial access vector simply invites the same attacker — or a different one — to use the same entry point again. Common vectors to address include unpatched software, misconfigured remote access, stolen credentials, and third-party access that exceeded appropriate privilege.

Improve monitoring and detection

Most breaches are not detected at the point of initial access. They are detected days, weeks, or months later when visible symptoms appear. The detection gap — the period between initial compromise and discovery — is the window during which data is exfiltrated, systems are explored, and damage accumulates. Reducing the detection gap through improved monitoring is one of the highest-value post-incident investments available.

Monitoring improvements to consider after an incident include: centralized log management (SIEM) if not already in place, endpoint detection and response (EDR) on all devices, network monitoring for anomalous traffic patterns, and identity monitoring for unusual authentication events — after-hours logins, logins from unexpected geographies, multiple failed authentication attempts.

Test your incident response plan

Every organization that has survived a cyberattack knows something that an organization that has not cannot: how the incident response plan performs under real-world conditions. The improvements identified in the post-incident review should be incorporated into an updated incident response plan that is then tested through tabletop exercises before the next incident forces the test in production.

The Most Common Mistakes Made After a Cyberattack

The post-attack response period is one of the highest-stakes operational environments a business will face — and the mistakes made under that pressure are well-documented and remarkably consistent across organizations and incident types.

Wiping systems before forensic investigation

The desire to “clean” a compromised system is understandable and almost always premature. Wiping and reimaging before forensic investigation destroys the evidence needed to understand the attack, identify all compromised systems, close the attack vector, meet evidentiary standards for legal proceedings, and verify that the attacker has been fully evicted. Always investigate before you remediate.

Restoring to production before confirming clean eviction

Restoring systems before the attacker has been confirmed evicted — or restoring into an environment that still contains attacker persistence mechanisms — leads directly to reinfection. This is the cause of the “we thought we fixed it and then it happened again” scenario that drives some organizations to repeated ransom payments. Eviction must be confirmed before restoration begins.

Missing regulatory notification deadlines

Organizations focused entirely on technical recovery sometimes lose track of the regulatory notification clock running in parallel. GDPR’s 72-hour supervisory authority notification requirement, for example, begins at the point when the organization becomes “aware” of a personal data breach — a threshold that can be reached before the full scope of the incident is known. Engaging legal counsel at the earliest possible point in the response is the only reliable way to avoid this mistake.

Making ransom payment decisions without professional guidance

Ransomware payment decisions made in isolation — without legal counsel, without IR specialist input, without backup assessment, and without law enforcement consultation — consistently produce worse outcomes than those made with appropriate guidance. The time pressure attackers impose is deliberate and should be resisted long enough to engage qualified advisors.

Failing to communicate transparently with affected parties

Organizations that delay, minimize, or obscure breach notifications consistently suffer worse long-term reputational damage than those that communicate promptly and transparently. Customers, partners, and regulators who discover a breach through channels other than the affected organization — through media reporting, through their own incident detection, or through unauthorized disclosure — react with significantly more anger and loss of trust than those who received timely, honest communication from the organization directly.