Leading Through a Major IT Incident: Decisions and Communication

Sooner or later, every IT leader faces the call: systems are down, something looks like an attack, or a vendor outage has taken a critical service with it. In those first hours, technical skill matters, but so does leadership. Who decides? Who talks to whom? What do you say when you do not know yet?

This guide is about the leader's role during a major incident, not the technical response playbook. It draws on NIST Special Publication 800-61 Revision 3, published in April 2025, which replaced the 2012 Revision 2 and frames incident response as part of overall cybersecurity risk management under the NIST Cybersecurity Framework 2.0. It also uses CISA guidance and ideas borrowed from emergency management.

Most of what makes a crisis go well happens before it starts.

Before: decide who decides

NIST SP 800-61r3 describes several incident response roles. Leadership "oversees incident response, allocates funding, and may have decision-making authority on high-impact response actions, such as shutting down or rebuilding critical services." Incident handlers verify and analyze the incident and act to limit damage and restore operations. Legal, public affairs and human resources all have parts to play.

Write down, in advance:

• Who can declare a major incident, and the criteria for doing so. NIST's profile includes the outcome that "Incidents are declared when adverse events meet the defined incident criteria."
• Who leads the response once it is declared, and who can authorize drastic steps such as taking systems offline.
• Who handles communication with staff, customers, regulators and the media.
• How you will reach each other if email, chat or phones are affected.

Emergency management offers a useful model. FEMA describes the Incident Command System as a management system that integrates "facilities, equipment, personnel, procedures, and communications operating within a common organizational structure," organized around functional areas including command, operations, planning, logistics, and finance and administration. You do not need the full structure, but the core idea, one clearly named incident lead with defined supporting roles, prevents a crowd of executives from all directing the technical team at once.

Then practice. CISA's Tabletop Exercise Packages provide "template exercise objectives, scenarios, and discussion questions," including cyber scenarios such as ransomware. A two-hour tabletop with executives often surfaces more gaps than any document review.

The first hour: stabilize the response

When a major incident is declared:

1. Name the incident lead and confirm it out loud, so everyone knows.
2. Assign a scribe to keep a timestamped log of events, actions and decisions.
3. Assign a communications lead so technical responders are not fielding status requests.
4. Set a fixed rhythm for internal updates, such as every hour or every two hours.
5. Bring in legal early if there is any chance of a breach, criminal activity or regulatory reporting.

If the incident may involve an attacker, be careful about how the team talks. CISA's #StopRansomware Guide advises using "out-of-band communication methods such as phone calls to avoid tipping off actors that they have been discovered." Preserve evidence where you can; NIST's guidance includes formal evidence gathering and handling, and wiping systems too quickly can destroy the information you need to understand what happened.

Making decisions under uncertainty

NIST SP 800-61r3 is candid that "Every response strategy decision has trade-offs." Observing an attacker or investigating thoroughly may conflict with the need to restore operations quickly. The same guidance recommends prioritizing how quickly each incident is handled based on its scope, likely impact, time-critical nature and resource availability.

A few habits help leaders decide well with incomplete information:

• Separate reversible from irreversible decisions. Move quickly on the first; slow down for the second.
• State your assumptions explicitly, and revisit them when new facts arrive.
• Timebox decisions: "We will decide on restoring from backup at 3 p.m. with whatever we know then."
• Record every significant decision, who made it and why, in the incident log.
• Know the difference between escalation and elevation. NIST notes that escalation generally means adding resources or time, while elevation means involving a higher level of management.

Recovery is a decision too. NIST's profile includes applying defined criteria for when to start recovery, taking into account the operational disruption that recovery itself can cause.

Communicating inside the organization

NIST describes four kinds of incident communication: coordination among responders, formal notification of affected parties, public communication and voluntary information sharing with others. It also recommends that organizations "Regularly update senior leadership on the status of major incidents."

A simple, repeatable update format keeps everyone aligned:

• What we know.
• What we do not know yet.
• What we are doing now.
• What we need from you.
• When the next update will come.

Keep staff informed too. Tell people what to do and what not to do, such as avoiding a particular system or reporting suspicious messages, and where to get updates. Silence breeds rumors.

Communicating outside: customers, regulators and the public

External communication should go through the people designated in your plan, with legal review. Stick to confirmed facts, avoid speculation about causes or attackers, and promise only what you can deliver.

Notification duties vary by sector, location and contract. NIST notes that incident notification "is an evolving topic, and new laws and regulations are being established frequently." For US public companies, SEC rules adopted in 2023 require disclosure of a material cybersecurity incident on Form 8-K, generally within four business days after the company determines the incident is material. CISA's #StopRansomware Guide also encourages reporting incidents to CISA, the FBI or the FBI's Internet Crime Complaint Center.

Take care of the people doing the work

Major incidents can run for days. Set shifts, enforce rest, arrange food and make sure no single person becomes the only one who understands the situation. Tired responders make mistakes. Afterward, acknowledge the effort and give people time to recover. Your organization's employee assistance program can help anyone who is struggling; this is not a substitute for professional care, and in a crisis in the US, people can call or text 988.

After: learn without blame

Once services are stable, hold a lessons-learned review focused on systems and decisions, not on finding someone to blame. Ask what helped, what slowed you down and what you would change. Update your plans, contact lists and runbooks, track the follow-up actions to completion and brief leadership on what changed.

Key takeaways

• Decide before a crisis who declares incidents, who leads and who communicates.
• Name one incident lead, keep a decision log and set a fixed update rhythm.
• Expect trade-offs between fast recovery and thorough investigation, and make them deliberately.
• Use a simple update format: what we know, what we do not, what we are doing and when we will update next.
• Involve legal early for any possible notification duty, and review lessons without blame.

Sources

• NIST, SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile (April 2025)
• CISA, #StopRansomware Guide (September 2023)
• CISA, CISA Tabletop Exercise Packages
• FEMA, NIMS Components - Guidance and Tools
• U.S. Securities and Exchange Commission, SEC Adopts Rules on Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure by Public Companies (July 26, 2023)