Most cyber incidents are not won or lost in the technical fight. They are won or lost in the first six hours of the business response. The technology question is whether the attacker gets in. The business question is whether your company knows how to operate while they are there. Almost every executive I work with has spent money on the first question. Almost none of them have answered the second.

The questions below are the ones I see deciding outcomes. They are not technical. Your IT team cannot answer them for you. They are governance questions, and the answers have to exist before the incident, written down, distributed, and rehearsed at least once. After the incident is too late by definition.

I have watched recoverable incidents become existential because nobody had thought through these. I have also watched bad incidents stay contained because somebody had. The difference between those two outcomes is rarely the firewall.

This is not an incident response plan

An incident response plan is a runbook. It tells the technical team what to do when an alert fires. Most companies of any size have one, often a good one. The questions in this piece sit upstream of that runbook. They are about who decides, how fast, with what authority, and on what evidence.

The runbook fails when those questions are unanswered. The technical team finds something ugly at three in the morning, escalates it, and runs into a governance vacuum. Nobody is authorized to spend, nobody is authorized to speak, nobody is sure whether to call the FBI or wait until the lawyer is awake. Hours pass. The attacker is operating on a clear schedule. The defender is improvising one.

The runbook tells your technical team what to do. The questions below tell them whether they are allowed to do it.

Read each question with your specific company in mind. If the answer is "we would figure it out," that is not an answer. That is the gap.

Question 01Who has the authority to declare an incident, and at what threshold?

Most companies do not formally declare incidents. They drift into them. An IT person notices something odd, mentions it in a chat, somebody else notices something else odd, a conversation happens, and three days later a vendor is on a call asking why the company did not engage them sooner.

The reason for the drift is usually that no one person has been told, in writing, that they are allowed to call it. Calling it is expensive. It triggers vendor engagement, sometimes insurance notification, sometimes legal counsel. Nobody wants to be the person who pulled the alarm on a false positive. So everybody waits for somebody else to be sure.

Meanwhile, the indicators that should have triggered the call sit in a ticket queue, getting worked but not escalated. By the time the call gets made, the attacker has had the time they need.

What to do: name one person, with a named backup, who is authorized to declare an incident on their own judgment. Write down three or four trigger conditions that would compel that call regardless of how busy anyone is. Distribute the list. Make sure the named person knows that calling a false alarm is not a career event. The cost of being wrong twice a year is dramatically less than the cost of being right once and silent.

Question 02What can your IT lead authorize to spend in the first six hours, with no quote and no committee?

In the first six hours of a real incident, every minute that a spending decision waits for sign-off is a minute the attacker is still operating. The cost of that delay is almost always larger than the cost of the spend. Owners know this in theory. They have not built the discretion in practice.

The dollar amount matters less than the existence of one. Some companies set it at five thousand. Some at fifty. The point is that the IT lead, or whoever holds the equivalent role, can call an outside forensics firm, buy emergency licenses, or stand up replacement infrastructure without writing a justification memo first. The justification can come after. The hours cannot.

A specific failure mode I have watched. A company hit by ransomware on a Saturday afternoon had a policy that any spend over two thousand dollars required CFO approval. The CFO was hiking. The IT lead spent the next eleven hours doing what he could in-house instead of calling the forensics firm whose retainer was already signed. By the time the CFO landed and approved, the encrypted volume had been overwritten. The recovery cost was forty times the threshold.

What to do: set a written first-six-hours discretionary spend limit for the incident commander role. Pre-authorize specific vendor categories: forensics, legal, communications, infrastructure. Put the vendor names and emergency numbers on a printed card. Practice making the call in a tabletop. The first time should not be the actual incident.

Question 03If the press calls in the first 24 hours, who speaks, and who is forbidden from speaking?

Untrained executives talking to reporters in the first day of a cyber incident create regulatory, litigation, and insurance problems that frequently exceed the cost of the incident itself. The temptation is high. The CEO wants to reassure customers. The owner wants to defend the brand. The technical team wants to clarify what is true. All three impulses are correct, and all three create exposure if the speaker has not been briefed by counsel.

Words like "breach," "exposed," or "compromised" carry legal weight in most state notification statutes. A well-meaning quote on day one can preempt the investigation that would have determined whether any of those words actually applied. Insurers read every public statement. So do plaintiffs' attorneys.

The opposite failure is also expensive. Silence on day one, especially if the incident is already visible, signals panic and concedes the narrative. The right answer is not silence. It is a single, designated, prepared spokesperson, and a clear list of who else is forbidden from speaking until cleared.

What to do: name the on-record spokesperson and the legal counsel they check with before any statement. Write a one-page holding statement template now. Brief every other senior employee, in writing, that any inquiry from the press, regulators, or large customers gets routed to that single point of contact. Repeat the briefing annually, and after any senior hire.

Question 04Will your cyber insurance respond, or will it dispute coverage?

Most owners have a cyber policy. Few have read it carefully against their actual operating reality. The gap between the two is where coverage disputes live. Common gaps I see in mid-market policies:

None of these are bad faith on the carrier's part. The application asked specific questions and the company answered them. When the claim hits, the carrier validates the answers. If the operational reality has drifted from the application, the policy does what policies do. It pays less, slower, with more dispute.

What to do: pull your current cyber insurance application out of the file. Read each control statement. For each one, ask the person responsible whether it is currently true and whether they could prove it on twenty-four hours notice. If the answer is anything other than yes, the gap is a coverage gap, not just an operational one. Close the operational gap and document the closing. The cost of doing this is tiny compared to the cost of a disputed claim.

Question 05What evidence will your insurer or regulator require in 30 days, and could you produce it tomorrow?

The recovery from a cyber incident is rarely the technical recovery. The technical recovery takes days or weeks. The evidentiary recovery, the part where you reconstruct who did what, when, with what permissions, on what data, takes months and often determines the financial outcome.

Regulators want logs. Insurers want logs. Plaintiffs want logs. A company that cannot reconstruct the timeline is treated, fairly or not, as a company that may have been negligent. Even when the underlying incident was small, a documentation gap can convert it into a finding.

The questions to test against your own environment: do your authentication logs go back at least 90 days, ideally a year? Do your endpoint logs cover the systems that hold your sensitive data? Do you retain admin actions on your cloud platforms long enough to satisfy the longest-look-back regulator that applies to you? Can your incident commander pull all of this without a vendor escalation? Have you ever tested doing so?

A useful exercise: ask your IT lead to produce, by end of business tomorrow, the authentication history for any one administrator account for the past 60 days. If the answer is "we can get that, give us a few weeks," your evidentiary posture is not where you think it is.

What to do: write down the evidence categories your industry's regulators and your insurer would request. Map each one to a system and a retention period. Where the retention is short or the system does not log what you need, fix the configuration before the incident. Most fixes here are zero-cost setting changes that companies have simply never made.

The cost of not asking

Cyber incidents are no longer rare events that happen to other companies. They are routine operating conditions. A company that has not had one is statistically due, not statistically lucky. The right time to think through the questions in this piece is the quiet period before, not the loud period after.

None of these questions cost much to answer. The decision-authority memo is a page. The spending discretion is a paragraph in a board resolution. The communication governance is a named person and a template. The insurance check is an afternoon. The evidence map is a week of effort across IT and operations. Total cost: a few days of senior attention and almost no money.

Total cost of leaving them unanswered: regularly, the company. I have seen otherwise healthy mid-market businesses lose six and seven figures in margin to incidents that were technically modest and governmentally botched. The gap was always the questions above.

If your team cannot answer them clearly today, the questions are doing their job. They are showing you exactly where to invest the next few days of attention. That is the kind of cyber work that pays for itself the first time you do not need it.