Governance Under Pressure
The Executive Perspective
Every organization says it is prepared for a serious cyber incident.
There is usually an incident response plan.
There are escalation procedures.
There are contact lists.
There are monitoring systems.
There are security teams.
There may even be regular tabletop exercises.
But the real test of incident management does not happen when the plan is written.
It happens when the first phone call comes at 2:00 a.m.
A critical business application is unavailable.
Customer data may have been exposed.
The security team is investigating.
The business wants to know when operations will resume.
Legal wants to understand the implications.
Communications wants to know what can be said publicly.
Regulators may need to be notified.
Customers may be asking questions.
The Board wants answers.
And nobody yet knows exactly what has happened.
This is where incident management becomes much more than a technical response function.
A serious cyber incident is a leadership event.
The technical team may contain the attack.
But leadership must decide what happens next.
1. The Incident Is Bigger Than the Alert
A security alert is an operational event.
An incident is an organizational event.
That distinction matters.
A SOC may detect suspicious authentication activity.
An analyst may investigate it.
A compromised account may be disabled.
All of this may happen without involving executive leadership.
But imagine the same compromised account is associated with a privileged identity and the attacker has accessed a critical business platform.
Now the situation has changed.
The organization may need to consider:
- Operational disruption.
- Customer impact.
- Data exposure.
- Regulatory obligations.
- Contractual obligations.
- Financial consequences.
- Reputation.
- Legal exposure.
- Business continuity.
- Executive communication.
The technology remains important.
But technology is no longer the whole incident.
The moment cyber risk becomes business impact, incident management becomes executive management.
2. The First Few Hours Define the Quality of the Response
During a major incident, organizations rarely have complete information.
They have fragments.
An unusual login.
A suspicious process.
An unavailable server.
A ransom note.
A notification from a supplier.
A customer complaint.
A security alert.
At this stage, leadership faces a difficult problem.
Decisions must often be made before the facts are complete.
Should the system be isolated?
Should operations be stopped?
Should credentials be reset?
Should customers be notified?
Should law enforcement be contacted?
Should regulators be informed?
Should the Board be briefed?
Waiting for perfect information may not be an option.
This is why mature incident management depends on predefined decision authority.
People must know who can make which decisions before the crisis begins.
3. Incident Response Plans Often Fail for a Simple Reason
Many organizations have detailed incident response plans.
Some are dozens of pages long.
They contain escalation procedures, contact lists, technical steps, severity definitions, communication protocols, and recovery procedures.
But during an actual incident, nobody starts reading the entire document.
People need clarity.
Who is leading?
Who makes decisions?
Who owns technical containment?
Who owns business continuity?
Who contacts legal?
Who communicates externally?
Who engages the relevant authorities?
Who briefs executives?
Who has authority to shut down a critical service?
A plan that does not provide clarity under pressure is not an effective plan.
The objective of incident management is not to create documentation.
The objective is to create organizational readiness.
4. Incident Management Begins Before the Incident
The best incident response starts long before an incident occurs.
Preparation includes:
- Clearly defined roles.
- Escalation criteria.
- Contact information.
- Decision authority.
- Critical asset identification.
- Business impact understanding.
- Communication procedures.
- Legal and regulatory coordination.
- Technical response capabilities.
- Backup and recovery arrangements.
- Supplier coordination.
- Crisis management processes.
- Regular exercises.
Preparation also means understanding what the organization cannot afford to lose.
If leadership does not know which business services are critical, it becomes difficult to prioritize recovery during a crisis.
Incident management therefore depends heavily on the work performed before the incident.
You cannot improvise organizational readiness after the crisis begins.
5. Who Is Actually in Charge?
One of the first questions during a serious incident should be:
Who is leading this incident?
This sounds obvious.
It often isn’t.
The SOC may assume the CISO is leading.
The CISO may assume the crisis management team is leading.
The business may assume the CIO is leading.
The executive team may assume someone else is coordinating.
Meanwhile, everyone is working hard—but the organization lacks unified command.
A mature operating model defines incident leadership clearly.
Technical teams should have technical authority.
Business leaders should make business decisions.
Legal should provide legal guidance.
Communications should manage communication strategy.
Executive leadership should make decisions requiring executive authority.
The incident leader coordinates these perspectives.
The objective is not to centralize every decision.
It is to establish clear command and accountability.
6. The CISO’s Role During a Major Incident
The CISO has a particularly important position during a cyber crisis.
The CISO must understand the technical situation without becoming trapped entirely inside the technical response.
Leadership needs answers to questions such as:
- What happened?
- What do we know?
- What do we not know?
- What systems are affected?
- What business services are affected?
- Is the threat contained?
- What could happen next?
- What decisions are required?
- What is the current business impact?
- What is the confidence level in our assessment?
The CISO must translate technical uncertainty into executive decision support.
That is a leadership responsibility.
7. Facts, Assumptions, and Unknowns
During an incident, one of the most dangerous mistakes is presenting assumptions as facts.
A mature incident-management structure distinguishes between:
Confirmed
What do we know with reasonable confidence?
Suspected
What do we believe may have happened?
Unknown
What do we still need to establish?
This distinction allows leadership to make decisions without creating false certainty.
For example:
Confirmed: A privileged account was compromised.
Suspected: The account was used to access a production environment.
Unknown: Whether sensitive data was exfiltrated.
This may appear simple.
But maintaining this discipline under pressure can significantly improve executive decision-making.
8. Communication Is Part of Incident Management
A technically successful response can still become a business failure if communication is poorly managed.
During a serious incident, different audiences require different information.
Employees need instructions.
Customers need appropriate information.
Regulators may require specific notifications.
Partners may need coordination.
Executives need business impact and decision information.
The Board needs assurance and oversight.
The public may require carefully controlled communication.
Communication must therefore be coordinated.
Different teams should not independently communicate conflicting versions of the incident.
This is why legal, communications, business leadership, and security should work together during significant incidents.
9. The Board Does Not Need a SOC Dashboard
When the Board is informed about a major cyber incident, providing hundreds of technical indicators is rarely helpful.
The Board needs to understand:
What happened?
What is affected?
What is the business impact?
What are we doing about it?
What decisions have been made?
What risks remain?
What should the Board be concerned about?
The Board does not need to know every IP address involved in the attack.
It needs to understand the organization’s risk position and management response.
That is the difference between technical reporting and executive communication.
10. Business Continuity and Incident Management Must Work Together
One of the biggest mistakes organizations make is treating cyber incident response and business continuity as separate disciplines.
They are connected.
Imagine a ransomware incident affecting a critical business application.
Security may successfully contain the attacker.
But the business still cannot operate.
The next question becomes:
How does the business continue?
That requires:
- Alternative processes.
- Manual workarounds.
- Recovery priorities.
- Backup availability.
- Crisis communications.
- Customer management.
- Supplier coordination.
Incident response focuses on understanding and controlling the cyber event.
Business continuity focuses on keeping critical business services functioning.
Recovery brings the organization back toward normal operations.
These capabilities must work together.
11. Recovery Is Not the Same as Restoration
This distinction is particularly important.
Restoring a server does not necessarily mean restoring the business.
A system may be technically available while:
- Data integrity remains uncertain.
- Dependencies are unavailable.
- Users cannot authenticate.
- Interfaces are not functioning.
- Customers cannot access services.
- Security monitoring is incomplete.
Recovery must therefore be measured in terms of business service restoration, not simply technology restoration.
The executive question should be:
“When can the business safely resume this critical service?”
Not merely:
“When can IT bring the server back online?”
12. The Pressure to Recover Quickly
During a major incident, business leaders naturally want services restored immediately.
That pressure is understandable.
But premature recovery can create additional risk.
If attackers still have access, reconnecting systems may allow the compromise to continue.
If the organization’s understanding of the attack is incomplete, restoring from an untrusted environment may reintroduce the threat.
This creates a difficult balance:
Speed versus assurance.
Leadership must understand the trade-off.
Security should explain the risk.
Technology should explain the technical dependencies.
Business leaders should explain the operational consequences.
Together, leadership must determine the appropriate recovery decision.
That is governance under pressure.
13. Incident Severity Must Reflect Business Impact
Incident classification should not depend solely on technical severity.
A technically sophisticated attack against an isolated, low-impact system may not require executive escalation.
A relatively simple compromise affecting a critical business service may require immediate executive attention.
Severity should therefore consider:
- Business impact.
- Customer impact.
- Data sensitivity.
- Regulatory implications.
- Operational disruption.
- Financial exposure.
- Reputational consequences.
- Geographic scope.
- Criticality of affected services.
- Potential for further compromise.
The objective is to ensure that organizational attention is proportional to business consequence.
14. Third Parties Can Become Incident Participants
A major incident may originate outside the organization’s environment.
A cloud provider may experience an outage.
A software supplier may be compromised.
A managed service provider may become the attacker’s entry point.
A partner may accidentally expose sensitive information.
In these situations, incident management must extend beyond the organization’s own security team.
Contracts should establish:
- Notification requirements.
- Investigation cooperation.
- Evidence preservation.
- Access requirements.
- Communication responsibilities.
- Recovery obligations.
- Regulatory coordination.
Third-party incident management should be tested before the organization actually needs it.
15. The Human Dimension of a Cyber Crisis
Incident response is often described in technical language.
Containment.
Eradication.
Forensics.
Recovery.
But major incidents are also human events.
People are under pressure.
Teams may work for long hours.
Business leaders may be anxious.
Customers may be angry.
Employees may be confused.
Executives may demand answers that do not yet exist.
This is where leadership matters.
The incident leader must create structure.
Meetings need discipline.
Information needs to flow.
Responsibilities need to remain clear.
People need to understand what is expected from them.
A crisis without leadership quickly becomes chaos.
16. Exercises Are Not Optional
An incident response plan cannot be validated by simply reading it.
It needs to be exercised.
A good tabletop exercise should create realistic pressure.
For example:
The organization discovers that a critical supplier has been compromised.
Thirty minutes later, suspicious activity is identified internally.
An hour later, a critical service becomes unavailable.
Then a journalist contacts the organization.
Then a regulator asks for information.
Then the Board requests an update.
The purpose is not to see whether participants know the right technical command.
The purpose is to discover:
- Who makes decisions?
- Who communicates?
- Where does information go?
- Which dependencies are unclear?
- Where do escalation processes fail?
- Which assumptions are wrong?
- Which capabilities are missing?
An exercise should expose weaknesses while there is still time to fix them.
17. Lessons Learned Should Change the Programme
An incident should not end when systems are restored.
The organization should ask:
Why did this happen?
But also:
Why were we vulnerable to this happening?
Perhaps asset visibility was incomplete.
Perhaps privileged access was excessive.
Perhaps a supplier had inadequate controls.
Perhaps monitoring did not cover critical systems.
Perhaps the response process was unclear.
Perhaps leadership had never tested the crisis-management model.
The lessons learned should feed back into:
- Risk management.
- Security strategy.
- Security programme priorities.
- Architecture.
- Policies.
- Training.
- Third-party governance.
- Business continuity.
This creates a valuable cycle:
Incident → Lessons → Risk → Improvement → Resilience
An incident should therefore improve the organization rather than simply close a ticket.
18. Incident Management Is a Governance Capability
The deeper CISM lesson is that incident management is not merely about responding to attackers.
It is about helping leadership make informed decisions during uncertainty.
Governance establishes:
- Authority.
- Accountability.
- Escalation.
- Communication.
- Decision rights.
- Oversight.
Incident management operationalizes those principles under pressure.
That is why incident preparedness belongs at the executive level.
19. What the Board Should Expect
The Board should be able to ask management:
- Do we have a tested incident-management capability?
- Who leads a major cyber crisis?
- Who has decision authority?
- What are our critical business services?
- How quickly can they be recovered?
- Have executives participated in exercises?
- How do we manage third-party incidents?
- How do we communicate during a major incident?
- How do lessons learned feed into risk management?
- What are our biggest response and recovery gaps?
These questions are more meaningful than simply asking whether the organization has an incident response plan.
20. The Executive Incident Management Model
A mature incident capability can be viewed through five phases.
Prepare
Build capabilities, roles, procedures, dependencies, and readiness.
Detect and Assess
Understand what is happening and determine whether escalation is required.
Respond
Contain the threat, protect the business, communicate, and make critical decisions.
Recover
Restore critical business services safely and progressively.
Learn and Improve
Determine what failed, what worked, and what must change.
The cycle then returns to preparation.
Because the objective is not merely to respond to the next incident.
It is to become better prepared for the one after that.
Executive Recommendations
For the Board
Ask whether incident management has been tested under realistic business pressure—not merely whether a response plan exists.
For the CEO
Ensure cyber crisis management is treated as an enterprise capability involving business, technology, legal, communications, and security leadership.
For the CISO
Build a response model that translates technical events into business decisions and provides executives with clear, timely, and honest information.
For Business Leaders
Know your critical services, recovery priorities, dependencies, and responsibilities before a crisis occurs.
For CIOs and Technology Leaders
Ensure recovery architecture, backups, identity, infrastructure, and technology dependencies support the organization’s business recovery objectives.
For Risk Leaders
Ensure significant incident lessons are incorporated into the enterprise risk profile and security programme.
Leadership Reflection
Most organizations do not get a second chance to make their first major incident response.
When the crisis begins, there is no time to discover who owns the decision.
There is no time to build the contact list.
There is no time to determine which business services matter most.
There is no time to discover that the backup strategy does not support the recovery objective.
There is no time to decide whether executives should participate.
Those decisions belong to the preparation phase.
The incident itself is where the organization executes them.
That is why incident management should never be viewed simply as a security operations function.
It is a test of organizational preparedness.
Closing Thought
A cyber incident will test much more than technology.
It will test leadership.
It will test governance.
It will test accountability.
It will test communication.
It will test business continuity.
It will test the organization’s ability to make decisions without having perfect information.
The organizations that respond well are not necessarily those that never experience serious incidents.
They are the organizations that have prepared themselves to make good decisions when serious incidents occur.
Preparation creates readiness.
Governance creates clarity.
Leadership creates direction.
Response contains the crisis.
Recovery restores the business.
Lessons learned create resilience.
The real measure of incident management is therefore not whether the organization can stop an attack.
It is whether, when the attack cannot be stopped immediately, the organization can remain in control of its decisions, protect what matters most, recover its critical business services, and emerge stronger than it was before the incident.
That is what mature incident management looks like.
