Ransomware Incident Response: First 24 Hours for Enterprises

When a ransomware attack hits, the first 24 hours can determine how an organisation contains the damage. It must manage the financial and operational impact, communicate with those affected, and coordinate the organisation’s response. In the immediate aftermath, there is little room for anyone to panic. Security teams and business leaders are often forced to make critical decisions under intense pressure, with limited information and little time to act.

Consider this scenario, it's 2 a.m. when the Chief Information Security Officer (CISO) calls. Files have been encrypted, a ransom note has appeared across employees’ screens, and the question of whether to pay is already being raised. What begins as a cybersecurity incident can quickly escalate into a wider business crisis, disrupting operations while legal, financial, customer and reputational risks begin to unfold.

Most business leaders will not be the people disconnecting systems, isolating devices or analysing logs. Their role is different, but no less important. In the hours that follow, they will need to make decisions about containment, communication, recovery and potentially ransom negotiations. Those decisions can have a lasting impact on the cost of the attack, how customers and the board are informed, and how quickly the organisation can restore normal operations.

This type of situation is the reality most executives aren't prepared for. Ransomware incident response is usually written as an IT playbook which includes network isolation steps and forensic checklists. This guide is written for the people who don't touch a keyboard during the incident but own the outcome anyway normally the CEO, the CFO, the general counsel or the board. It covers what enterprises should do in the first 24 hours, framed around the decisions leadership actually has to make, not the technical work your team handles beneath you.

The timing works against you from the start. Chester Wisniewski, Director, Global Field CISO at Sophos, has pointed out in a discussion of Sophos's Active Adversary Report that more than 87 per cent of the ransomware attacks his team investigates happen after 6 p.m., before 8 a.m., or on a weekend. This is not because attackers necessarily plan it that way, but because a lot of ransomware operators are simply working their own business hours on the other side of the world. Either way, the practical effect is the same for leadership: the call almost always comes when you least expect it. So let's break down the 24 hour cycle on what you need to do if the time ever arises for your organisation.

Why Your Involvement in Hour One Matters

Executives don't need to understand encryption algorithms. They need to understand that the speed of the first response sets the ceiling on total damage and that speed depends heavily on whether the organisation already has a plan, or is inventing one live.

Sophos's incident response data illustrates the gap starkly. For organisations that call in outside help only after an attack often because their cyber insurance carrier makes the referral; the median time to full response is around five days. For organisations with a managed detection and response (MDR) relationship already in place, that median drops to roughly two and a half days, according to Wisniewski's own incident response caseload data. He attributes the difference to experience: professionals who see these alerts every week know what to do immediately, while a team encountering ransomware for the first time has to figure it out under pressure.

For a board, that gap translates directly into dollars, every additional day of operational disruption is a day of lost revenue, idle staff, and mounting recovery costs. This is the argument for pre-approving an incident response plan and a retainer with outside specialists before an incident, not during one. It's a governance decision, and it belongs on your risk committee's agenda now, not after the ransom note appears.

Hour 0–2: What Leadership Needs to Know

In the first two hours your technical team must quarantine infected systems and take affected networks offline. In those first two hours your goal is to learn what happened as fast as possible and prevent further damage. So make sure you do the following: 

• Ask for an estimate based on the actual scope of the threat. It's important to remember that sometimes the early reports are often wrong. So please resist the urge to send a company-wide broadcast message that “we have been hacked”. Just make sure the wider team understands which systems may be affected while the facts are still being confirmed.
• Confirm the incident response plan is actually being used. This means if your organisation doesn't have a plan that is documented in cases like this with named decision-makers it could cause a huge problem. This is the moment that the gap becomes very expensive in a short space of time.
• Don't authorise any public statement yet. In situations like this, don’t panic. Legal and communications teams need time to assess what has happened and understand the full extent of the exposure. Making a statement too early, even internally, can create problems if it later reaches the public. You may end up having to correct claims that were made before all the facts were clear. For example, if you announce that “the entire network has been compromised” and later find that only one system was affected, you’ll have to publicly correct the statement.
• Bring general counsel in early, even if you’re not yet sure how serious the incident is. Getting legal involved from the start can help protect privileged communications and make sure the investigation is handled properly if questions arise later.

There's also the human side to consider. Kevin O'Connor, Director of Threat Research at N-able, has described in an interview on AI-driven social engineering how even security-trained staff fall for the most basic tactics. For instance, at one cybersecurity conference, researchers used a fake "scan to skip the line" QR code and got roughly 20 security professionals to scan it. The takeaway for leadership isn't that your people are careless; it's that no amount of training makes an organisation immune to this kind of exposure. Also ransomware operators increasingly target IT vendors and managed service providers specifically because compromising one gives them a gateway into many client networks all at once. Use what you’ve learned from this incident when deciding how much risk you’re willing to accept from the vendor you have in future.

Hour 2–6: The Decisions Only You Can Make

This is where the incident stops being purely technical and becomes a responsibility. Your response team, which includes IT, security, legal, communications and an incident commander should already be assembled. Your role as the leader is to make the calls that require business judgment, not expertise. In cases like this it is important to lean on your team. Also you must ensure to do the following:

• Approve the engagement of outside forensic and legal specialists. If you do not already have a cyber insurance policy and pre‑vetted partners this is the moment that absence becomes visible. Most policies require carrier notification early. Come with specialists who can move faster than anyone you would find cold.
• Decide who holds ransom‑payment authority and do not decide it in this meeting. That authority should already be defined in your incident response plan. If it is not assigned it is now formally in writing so it is not re‑litigated at 3 a.m. Under pressure.
• Set your communication cadence. Board members and senior leadership need honest updates on a fixed schedule so they know what is known, what is not, what is being done and what you need from them. You cannot have updates driven by whoever has time to write one.
• Ask directly if data was stolen, not just encrypted. This single fact changes your exposure, your notification obligations and your messaging strategy more than almost anything else in the first day.

Hour 6–12: Understanding Your Exposure

While the technical team is figuring out what happened, you also need to work out how the incident has affected the business.

That includes looking at:

• Financial impact: How much money could the incident cost?
• Legal impact: Could the company face legal action, fines or other obligations?
• Reputation: Could this damage the company’s relationship with customers or partners?

Ask your team if the entry point has been identified, and whether it points to a control gap the board will ask about later. For instance, this could be a phishing email, an exposed remote access port, or a compromised vendor. You don't need the forensic detail, but you do need to know if this was preventable, because that question is coming from your board and possibly your regulators.

You also need to confirm if backups are verified and usable. This single answer often determines whether the ransom conversation is even relevant. Ransomware operators routinely target backups before triggering encryption specifically to remove that option, so don't assume yours are clean until your team confirms it.

O'Connor's interview points to another executive-level risk worth raising and being aware of. AI-generated voice cloning has gotten good enough that a five- to ten-second audio clip, easily pulled from an earnings call or a conference talk can produce a convincing impersonation of an executive's voice. If your team spots unusual wire transfer requests or account changes during this period, treat it as a possible second attack layered on top of the ransomware, not a coincidence.

Hour 12–24: Communication, Compliance, and the Ransom Question

By the second half of the day, you will need three executive responsibilities to take priority namely: external communication, regulatory compliance, and the ransom decision. Let’s take a look at each of them in depth.

1. Communication needs your direct oversight. Customers, partners, employees, and regulators all expect different things, and every public or semi-public statement should be reviewed legally before it goes out. A statement that overstates or understates the incident can create liability that outlasts the technical recovery by years. Internally, silence is worse than an incomplete update as employees will fill information gaps with speculation, and that often ends up outside the building.
2. Regulatory reporting clocks are running whether or not your investigation is finished. Under GDPR Article 33, organisations must notify the relevant supervisory authority within 72 hours of becoming aware of a breach, unless the incident is unlikely to pose a risk to individuals and the clock starts at awareness, not once the investigation wraps up. In the U.S., the HIPAA Breach Notification Rule gives covered entities up to 60 calendar days, GLBA expects "as soon as possible," and a patchwork of state laws each carry their own deadlines, some as short as 30 days. Missing one of these windows turns a contained security incident into a separate compliance problem, one that's entirely avoidable with the right legal counsel engaged early.
3. The ransom decision is the one most boards fixate on, and it deserves a clear-eyed framing:

• Paying doesn't guarantee usable decryption. A meaningful share of organisations that pay either get nothing back or receive keys that don't fully work, per multiple industry surveys of ransomware victims.
• Organisations that pay are frequently targeted again, sometimes by the same group, within weeks as payment signals willingness and capability to future attackers.
• Paying a sanctioned group can carry real penalty exposure regardless of whether you knew the recipient was sanctioned, per the U.S. Treasury's OFAC advisory on ransomware payments.

None of this means payment is automatically the wrong call, sometimes it's the fastest path to restoring operations that matter more than the payment itself. But it should be a deliberate decision made with legal counsel, your insurer, and the executive team in the room, not a reflexive answer given under duress at hour four.

Why This Keeps Happening After Hours

It's worth returning to the timing pattern one more time, because it has direct governance implications. If the majority of ransomware incidents start outside business hours, then a security function with coverage only during business hours has, structurally, already lost the first several hours of the incident before anyone notices.

Round-the-clock detection and response coverage is no longer just an IT cost, it's a board-level risk decision. Wisniewski's team has noted that part of why response times are shrinking industry-wide isn't purely better defense; it's that AI is accelerating attackers at the same rate it's accelerating defenders. That's a reasonable thing to ask your CISO about directly by stating is our coverage keeping pace, or are we relying on someone checking a dashboard once a day against tooling that runs continuously?

The Visibility Question Worth Asking Your CISO

O'Connor raised a point that's easy for non-technical leadership to miss: many organisations still think about security almost entirely in terms of network edge devices like firewalls, routers and laptops. But attackers increasingly move through identity systems and the SaaS stack like email, single sign-on, cloud storage which is long before anything shows up on a traditional network alert. You don't need to evaluate the technical architecture yourself. But it's a fair board-level question to ask: does our detection and response coverage extend across the full technology stack, including identity and cloud platforms, or only the traditional network perimeter? The answer shapes how much warning you'd realistically get next time.

Common Leadership Mistakes in the First Day

A few patterns show up repeatedly in postmortems, and they're leadership failures more often than technical ones:

• No pre-assigned decision authority. Executives spend the first hours debating who's in charge instead of executing a plan that should already exist.
• Assuming backups work without verification. Discovering a backup was also encrypted, or was never tested, at the exact moment you need it.
• Public statements made before legal review. A routine incident described publicly in language that overstates or understates severity, creating liability either way.
• Treating the ransom decision as purely a security call. It's a business, legal, and financial decision that belongs with executive leadership, not delegated entirely to IT.
• Skipping law enforcement engagement. This isn't an admission of failure as agencies occasionally hold decryption keys recovered from prior takedowns of the same ransomware operators, and early reporting can materially help your case.

What Boards Should Require Before the Next Incident

The organisations that handle ransomware best did their hardest work months before the attack, at the governance level, not during the crisis. A few things worth putting on your next board or risk committee agenda:

1. A ransomware-specific incident response plan with named decision owners and is approved by leadership, not just written by IT.
2. Verified, tested, offline backups, confirmed on a recurring schedule rather than assumed.
3. 24/7 detection and response coverage, given how heavily attacks skew toward off-hours, ask directly whether current coverage is in-house or through an MDR provider, and what the actual response time looks like.
4. Pre-vetted external partners of forensic investigators, breach counsel, a ransomware negotiator which is under retainer so you're not vetting vendors mid-crisis.
5. An annual executive tabletop exercise that walks your leadership team through the exact first-day decisions above, using our tabletop exercise template as a starting point, so the first time you make these calls isn't during a real incident.

The organisations that emerge from a ransomware attack with the least disruption are rarely those with the biggest security budgets. They are the ones whose leadership has established, before an incident occurs, who has authority to make critical decisions and what those decisions should involve. For the CEO, the role is not technical execution but oversight: bringing in external specialists, confirming authority over ransom decisions, overseeing communications, and ensuring legal and regulatory obligations are addressed. IT, security teams and forensic partners handle containment and technical recovery. Initial containment may happen within the first 24 hours, but restoring normal operations can take weeks. A rehearsed incident response plan and tested backups give organisations a clearer path through the crisis, enabling faster decisions and a more controlled return to normal operations.