The First 24 Hours After Ransomware

This is the sequel to The First Hour of a Cyber Incident. Read that one first if you have not - it covers isolating machines, touching nothing, and getting help on the phone. This one starts where it ends: the machines are off the network, nothing has been wiped, the note has been photographed, and someone competent is on their way or on the line.

The first hour is instinct. The next twenty-four are a different discipline: communication in the right order, two tracks of decisions running at once, and a business that has to keep functioning while its systems are evidence. Here is how that day actually goes.

Who needs to be told, and in what order

The order matters more than the speed. Getting it backwards - telling customers before counsel, or the whole staff before leadership - creates problems you cannot take back.

Your response team and your IT provider, if they are not already engaged from the first hour. One channel, one place where updates live, so you are not re-explaining the situation to each party separately.

Your cyber insurance carrier, through the notice process in your policy, and your attorney - ideally one who handles incidents - early in the day, not after decisions have been made. These two calls shape everything else. The carrier because the policy controls what is covered, what must be pre-approved, and often which outside specialists you use. The attorney because questions that arrive in the next day - what must be reported, to whom, whether the note should be answered, what you can say to employees and customers - are legal questions wearing technical clothes, and some of the work that follows should run under counsel's direction.

Your leadership and owners, plainly and without reassurance you do not yet have. What happened, what is affected, what is being done, when the next update comes. Then keep the promise on updates even when the update is "nothing new."

Your staff, with a short, controlled message: systems are down due to an incident, do not attempt to fix or work around it, do not discuss it outside the company, route anything unusual to a named person. Staff who are not told a story will invent one, and the invented version reaches customers.

Bank and financial contacts, if there is any chance payment systems, banking credentials, or financial data were in reach of the affected machines. Fraud attempts following an intrusion are common enough that the call is cheap insurance.

Customers and partners come last and only on advice - once you know what happened, whether their data or their service is affected, and what you are required or committed to tell them. What those obligations are, and their deadlines, varies by state, by regulation, and by contract; that is a determination for counsel, made from the facts as the investigation establishes them, not from the ransom note.

What the carrier needs from you, and when

Read the notice and cooperation clauses of your policy the day this starts, not from memory. In practice, the carrier will want:

• Prompt notice through their stated channel, which is usually a hotline or portal, and usually not your broker alone. Late notice is one of the ordinary ways coverage fights begin, and notifying them is not the same as making a claim.
• The timeline as you know it so far - which is why the contemporaneous notes from the first hour matter. When it was discovered, how, what was observed, what was done and when.
• Approval before spending. Forensics, outside counsel, negotiators, restoration work, ransom decisions - many policies require the carrier to approve vendors and spend in advance. Work done first and expensed later can become your money.
• Preservation. Do not rebuild, wipe, or discard affected systems until the carrier and the forensics team say so, however much you want the machines back. The carrier's investigators will want the environment in the state you found it, and destroying it can put both the investigation and the coverage at risk.

If you do not have a policy, everything in this section becomes out-of-pocket decisions to make with counsel and the response team - and the discipline is the same minus the approvals.

Why you do not talk to the attacker yourself

The note gives you an address and invites contact. Do not use it, and do not let anyone else in the company use it.

The practical reasons first. Anything you say begins a negotiation you are not equipped to run, against people who run them daily, and everything you write is evidence - in an investigation, in a coverage dispute, potentially in litigation. A reply also tells the attacker the address is read, which raises the value of everything they demand next. And payment is not a simple transaction even if you were inclined: it sits in a thicket of sanctions rules and legal exposure that counsel has to evaluate, it may or may not be reimbursed under your policy, and it reliably produces a working decryptor less often than the note implies. There is also the quieter problem: attackers share lists. A business that responds, let alone pays, is a business that gets approached again.

That does not mean the note goes unanswered forever. It means any contact - including the decision to make none - goes through counsel and, if it comes to it, professional negotiators retained through the carrier or the response team. Your job in this lane is to preserve the note, photograph it, and say nothing into it.

The decisions that cannot wait, and the ones that must

Two tracks run through the day and they move at different speeds. Mixing them up is how businesses make the expensive mistakes - rushing the slow track, dithering on the fast one.

Cannot wait:

• *Scope of the shutdown.* What stays offline, and whether anything trusted - a server that seems clean, a cloud service the affected machines touched - has to come down too. The response team advises; someone in your business owns the call.
• *Credentials.* Every password that was stored on, entered on, or reachable from the affected machines gets treated as known to the attacker: email accounts, banking, line-of-business systems, vendor portals. Reset them from a clean machine, starting with email and money.
• *Today's operations.* Payroll, shipping, answering customers - the interim plan from the next section. Revenue does not pause because the network did.
• *Staff instructions.* Silence is a decision too, and a bad one.

Must wait - for facts, forensics, counsel, or the carrier:

• *Ransom decisions.* Pay or refuse is a legal, financial and coverage judgement made late in the process, with information you do not have yet.
• *Rebuild versus restore.* Until forensics says how they got in and how far they got, any rebuild risks reseating the same open door.
• *Notification decisions.* What has to be reported - to individuals, regulators, or under contract - depends on what data was actually affected, which the investigation establishes. The obligations and their deadlines exist and vary; counsel maps them to your facts.
• *Public statements.* Anything said before the facts settle will be compared against the facts later.

Keeping the business running on paper

Assume the systems are gone for longer than a day and plan the interim operation like it has to survive the week.

Start with the work that has a date on it: payroll, invoices due, shipments, appointments, court or filing deadlines. For each, write down how it was done before the system existed, because that is how it is done now - paper ledgers, printed order forms, a phone tree, a whiteboard schedule. Pull the records that live outside the affected systems: the contact list in someone's phone, the price book in a drawer, the bank's own website reached from a clean machine, the backups the accounting software vendor keeps on their side. Most small businesses discover they know more than they feared, once they stop reaching for the server and start asking people what they remember.

Set a clean communications channel - personal phones, a new group chat on accounts that never touched the company network - and tell staff and key customers to use it. Assume the attacker can read company email until told otherwise.

And set expectations honestly with customers: you are experiencing a systems issue, here is how to reach us, here is what is unaffected. Most customers have lived through someone else's outage and will work with a business that answers the phone. They will not work with one that vanishes.

What the recovery team will ask for - collect it now

The response team's first day is partly investigation and partly intake, and the intake questions are predictable. Every item you gather in advance is an hour you do not pay for later.

• Your notes and timeline from the first hour onward, with times.
• A system inventory: what machines and servers exist, what runs on each, what is on-premises and what is cloud, and who provides what.
• Backup details: what is backed up, where the backups live, how they connect to the network, and when the last one completed. Whether they survived is the question the whole recovery turns on, and it is answered by looking, not by assuming - backups that share the network with what encrypted everything else are often encrypted too, which is why nothing gets wiped.
• Remote access paths: VPNs, remote-desktop gateways, vendor support tools, anything that reaches in from outside.
• The security tools you have: antivirus or endpoint products and who manages them, and any log or alert history that survived.
• Vendor and account lists: your IT provider, your software vendors, your bank contacts, your insurance policy and claim number, your attorney.
• The ransom note and anything that came with it, untouched.
• A list of what the business cannot live without, in your words - which systems, which data, in what order. The rebuild sequence comes from this, and nobody can write it for you.

Hand this over as it is, gaps included. The team has seen worse, and a candid inventory beats a polished one that turns out to be wrong.