The Incident Commander Should Not Be Googling the Plan During the Incident
A cyber incident is a terrible time to discover that nobody knows who is in charge. Yet that is exactly how many organizations operate…
The Incident Commander Should Not Be Googling the Plan During the Incident

A cyber incident is a terrible time to discover that nobody knows who is in charge. Yet that is exactly how many organizations operate. They buy tools, attend conferences, approve a policy, upload the incident response plan into SharePoint, and congratulate themselves for having a “program.” Then the real incident hits. Ransomware on a file server. Suspicious activity in Microsoft 365. A vendor breach. A compromised admin account. Suddenly, the calm policy language turns into a room full of people asking the same question in different ways: “Who is supposed to make this decision?” That question should have been answered six months ago.
The incident commander should not be Googling the plan during the incident. The legal team should not be digging through old contracts to find notification obligations while systems are offline. The communications team should not be writing its first breach statement while reporters are already calling. The CIO should not be asking whether the cyber insurance carrier has to be notified before forensic work begins. The CEO should not be deciding, in the middle of operational chaos, whether downtime procedures are good enough to keep the business running. By then, the clock is already eating you alive. Incident response is not a document. It is a rehearsed chain of command.
NIST’s incident response guidance now pushes organizations to weave incident response into broader cybersecurity risk management, not treat it as a dusty binder that comes out after the damage is done. The goal is preparation, lower impact, and better detection, response, and recovery, not heroic improvisation after the attacker has already taken the wheel. HHS guidance for healthcare organizations says incident response policy should define who responds to events, roles and responsibilities, documentation, and reporting requirements, while incident response plans should include senior management approval, team communication, and ways to measure response capability. That is not paperwork for auditors. That is the difference between controlled response and executive panic. The first failure is usually authority. During an incident, everyone has opinions. Security wants containment. IT wants uptime. Legal wants precision. Compliance wants reporting clarity. Communications wants approved language. Operations wants the system back. Finance wants cost control. Executives want certainty, which is adorable, because certainty is usually the first casualty of a real breach.
That is why the incident commander role matters. Someone has to coordinate the room, establish priorities, document decisions, separate facts from rumors, and keep the organization from thrashing. The incident commander does not have to be the smartest technical person in the room. In many cases, they should not be. Their job is command and coordination, not packet analysis. They need enough technical understanding to know when they are being fed nonsense, enough operational knowledge to understand business impact, and enough authority to make people stop debating and start executing. The second failure is legal notification confusion. Every organization has legal obligations. Healthcare has HIPAA. Public companies have SEC disclosure rules. State breach laws may apply. Vendor contracts may include reporting windows. Cyber insurance policies often require prompt notice and may have approved forensic vendors, breach counsel, or panel requirements. None of that should be discovered during the incident.
For healthcare, HHS states that covered entities must notify affected individuals of breaches of unsecured protected health information without unreasonable delay and no later than 60 days after discovery. Breaches affecting more than 500 residents of a state or jurisdiction also require media notice, and covered entities must notify the Secretary of HHS. Business associates must notify covered entities without unreasonable delay and no later than 60 days after discovery. Public companies face a different clock: the SEC requires disclosure of material cybersecurity incidents within four business days after the company determines the incident is material, not four days after discovery. Those timelines do not care that the incident commander is still trying to find the right phone number. The third failure is communications.
Bad incident communication causes damage almost as fast as malware. Internally, staff need to know what to do, what not to touch, what systems are down, whether email can be trusted, whether calls should be routed differently, and where updates will come from. Externally, customers, patients, vendors, regulators, law enforcement, insurers, and media may all need different messages at different times.
This is where organizations embarrass themselves. They say too much too soon. They say nothing for too long. They contradict themselves. They promise facts they do not have. They let technical staff speak publicly without legal review, or they let legal review suffocate the message until it sounds like it was written by a hostage negotiator trapped inside a compliance seminar.
Comms templates should already exist. Not final statements, templates. Holding statements. Internal alerts. Executive briefs. Patient or customer FAQs. Vendor notification language. Law enforcement contact scripts. Board update formats. Staff instructions for suspected phishing, workstation isolation, phone tree escalation, and downtime operations. The first time communications sees these templates should not be at 2:13 in the morning while ransomware notes are appearing on screens. The fourth failure is insurance. Cyber insurance is useful, but it is not magic. It is a contract. Contracts have conditions. If the policy requires specific notice steps, approved counsel, approved forensic firms, documented incident handling, or carrier approval before major expenses, the organization needs to know that before it starts writing checks. Otherwise, leadership may discover that the policy they bragged about during budget season has sharp edges during claim season.
This is why the cyber insurance contact list belongs inside the incident response plan, along with the policy number, broker contact, carrier breach hotline, outside counsel, approved forensic providers, retainer status, and internal owner. Someone should test those numbers. Not once. Regularly. People leave jobs. Brokers change. Policies renew. Hotlines move. A stale contact list during an incident is just another way of saying, “We prepared for a version of the company that no longer exists.” The fifth failure is decision authority. Who can shut down a system? Who can disable remote access? Who can force password resets? Who can take email offline? Who can approve emergency firewall blocks? Who can authorize network isolation for a clinical system? Who can call law enforcement? Who can approve ransom negotiation discussions, even if the organization has no intention of paying? Who speaks to the board? Who speaks to the press? Who decides when systems return to production? If the answer is “we’ll figure it out,” the organization does not have an incident response plan. It has a hope document.
Decision authority must be mapped before the attack. Not just titles, actual named primary and backup decision-makers. The plan should account for vacations, illness, travel, after-hours events, and the very real possibility that the compromised account belongs to someone in the approval chain. The plan also has to define escalation thresholds. A single infected workstation is not the same as domain controller compromise. A vendor notification is not the same as confirmed data exfiltration. A suspicious login is not the same as active lateral movement. Severity levels should drive response posture, not volume level in the war room. Testing is where the fantasy dies. A tabletop exercise is not supposed to make everyone feel brilliant. It is supposed to expose weak spots while the stakes are low. The first tabletop should be ugly. People should miss steps. Contacts should be outdated. The legal path should have gaps. Communications should struggle. IT should realize it lacks clean asset ownership. Executives should discover they cannot make decisions as quickly as they thought. That discomfort is the point. Better to look foolish in a conference room than helpless during a breach.
A mature test should include executives, legal, compliance, security, IT, operations, communications, HR, finance, vendor management, and insurance contacts. It should walk through realistic injects: systems unavailable, attacker claims data theft, media inquiry received, vendor implicated, backup integrity uncertain, privileged account compromised, EDR alert volume increasing, patient care or business operations disrupted, board requesting status, insurer requesting documentation. The exercise should end with assigned remediation items, owners, and deadlines. Otherwise it is theater with snacks. The harsh truth is simple: incidents punish vague leadership. Attackers do not need your organization to be completely incompetent. They only need hesitation, confusion, and internal disagreement. They need the CFO to question containment costs while the attacker keeps moving. They need legal and security to debate notification language while evidence ages. They need executives to demand perfect certainty before approving imperfect but necessary action. They need your team to spend the first critical hours finding the plan instead of executing it.
An incident response plan should be boring before the incident so the incident does not become catastrophic during the response. Roles should be assigned. Legal paths should be documented. Communications should be templated. Decision authority should be clear. Insurance contacts should be tested. Downtime procedures should be practiced. Executives should know their role before the ransom note appears, before the phones light up, before patients, customers, regulators, or reporters start asking questions. Because when the breach begins, the organization does not rise to the quality of its policy. It falls to the quality of its rehearsal.
If this was useful in any way: Give it a clap Follow & subscribe for more Content Send me a coffee… =) (Link Below) Support: https://buymeacoffee.com/saltinehacy
메타데이터
- post_id
- 34ab3f3ad0ef
- slug
- the-incident-commander-should-not-be-googling-the-plan-during-the-incident-34ab3f3ad0ef
- url
- https://medium.com/@saltinehacker/the-incident-commander-should-not-be-googling-the-plan-during-the-incident-34ab3f3ad0ef
- canonical_url
- https://medium.com/@saltinehacker/the-incident-commander-should-not-be-googling-the-plan-during-the-incident-34ab3f3ad0ef
- author_url
- https://medium.com/@saltinehacker
- status
- ok
- fetched_at
- 2026-07-18 06:34:01