When cyber risk is pushed into IT alone, it is often underfunded, deprioritised, and poorly practiced. The article argues that board and executive ownership matters because cyber incidents affect revenue, continuity, reputation, and legal exposure. If leaders do not see it as business risk, they will not invest in resilience, preparedness, or cross-functional response when an attack happens.
Why cyber response breaks when risk is treated as an IT problem
Cyber risk weakens response and recovery when it is framed as a technology issue instead of an enterprise risk, because the organisation then assigns ownership, budget, and decision rights to the wrong layer. IT can operate controls, but it cannot on its own prioritise service continuity, legal exposure, customer communication, or crisis trade-offs. That is why frameworks such as the NIST Cybersecurity Framework 2.0 place governance and business outcomes alongside technical safeguards.
The practical problem is not that IT is unimportant. It is that incident response and recovery require coordinated authority across legal, finance, communications, operations, HR, and leadership, especially when outages, extortion, or data theft force rapid business decisions. When the issue sits inside IT, exercises tend to focus on tool operation and ticket handling rather than executive escalation, resource commitment, and cross-functional recovery sequencing. In practice, many security teams discover this only after a real incident exposes who can actually approve downtime, disclosure, and recovery priorities.
How shared ownership changes response speed, recovery quality, and decision-making
Effective cyber response depends on more than containment. It requires clear decision paths for shutdowns, third-party coordination, evidence preservation, communications, and restoration order. If cyber risk is treated as an IT issue, the response often becomes narrower: the team works to restore systems first, while the business is left to interpret consequences later. That separation usually slows recovery because leaders have not previously agreed what must come back first, what evidence must be retained, or which outages are acceptable while controls are verified.
A stronger model starts with business impact and then assigns technical work to IT in support of that business priority. The organisation should know which services are critical, which dependencies matter most, and who can approve actions that trade speed for confidence. Recovery is often where this becomes visible. Restoring from backups, rotating credentials, re-enabling integrations, and reconnecting suppliers are all technical tasks, but the order in which they happen is a business choice because each step changes exposure and continuity.
- Business continuity planning defines what needs to be restored first.
- Legal and compliance functions decide what evidence, notices, and preservation steps are required.
- Communications teams handle stakeholder messaging while the technical team stabilises systems.
- Executives resolve trade-offs when the safest path is not the fastest path.
The same logic applies to modern attacks that involve trust abuse, stolen access, or malicious automation. CISA threat advisories help teams understand current adversary methods, but the response still fails if only the technical team is rehearsed and the wider business is not. Response and recovery break down when the organisation has tools but no agreed authority model, or when restoration work resumes before the root cause and blast radius are understood.
Where the IT-only model still appears to work, and where it fails
Tighter technical control often increases coordination overhead, requiring organisations to balance quick restoration against governance, evidence, and business continuity. That trade-off is manageable for a contained outage, but it becomes dangerous when the incident affects shared infrastructure, customer data, or revenue-generating services.
There is genuine consensus that IT must lead technical containment, but there is less consensus on how much authority should sit with central security versus business leadership during recovery. The best answer depends on incident severity, regulatory impact, and how many business functions are touched. A small workstation event may stay mostly within IT. A ransomware event, identity compromise, or major cloud outage usually should not, because the business consequences extend well beyond system repair.
The common failure is assuming that a technical fix equals recovery. In reality, restoration can reintroduce the same vulnerability, miss hidden persistence, or bring back services in the wrong order. Another frequent mistake is over-indexing on tools and under-investing in exercises that test who makes decisions under pressure. Organisations that plan only for IT-led remediation often struggle with the first hours of a crisis, when clarity, escalation, and authority matter more than raw technical skill.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Cyber risk must be governed as enterprise risk, not isolated IT work. |
| RS.RP-01 — Response Plan Execution | The question concerns how response and recovery break when ownership is too narrow. | |
| RC.RP-01 — Recovery Plan Execution | Recovery quality depends on agreed restoration sequencing and authority. | |
| Recommendation — Align cyber decisions to enterprise risk tolerance and recovery priorities. Test response plans across business, legal, and technical owners. Define restoration order and decision rights before an incident occurs. | ||
| CIS Controls v8 | CIS 17 — Incident Response Management | The issue is organisational response coordination, not only technical remediation. |
| CIS 11 — Data Recovery | Recovery weakens when restoration is not planned and validated as a business process. | |
| Recommendation — Run cross-functional incident exercises and update playbooks from lessons learned. Validate backups, restoration steps, and recovery sequencing against business needs. | ||
| MITRE ATT&CK | T1486 — Data Encrypted for Impact | Ransomware-style impact forces business-led recovery, not just IT repair. |
| Recommendation — Map impact techniques to recovery priorities and executive escalation triggers. | ||
Practitioner Guidance
What to prioritise: Treat response and recovery as a business resilience capability, not a helpdesk extension. The first question should be who owns impact decisions, not which tool will be used first.
What to verify: Confirm that executives, legal, communications, and operations have rehearsed their roles in at least the high-impact scenarios. If the recovery plan only names technical owners, it is not ready for a serious event.
Decision rule: If an incident can affect revenue, regulated data, customer trust, or critical services, escalate it beyond IT immediately and use a cross-functional command structure. If it cannot, IT may lead containment, but business ownership should still be explicit.
What good looks like: The organisation can state, before an incident, who declares severity, who approves service restoration order, who authorises external messaging, and what evidence must survive recovery.
Practitioner takeaway: Recovery becomes faster and safer when IT is responsible for execution but not for defining business priorities, because the real bottleneck in a major cyber event is usually decision authority, not tooling.
