Ask security teams how quickly they could respond to a serious cyber incident and the answer often sounds reassuring.
Kroll’s 2026 cyber resilience research found that 72% of organisations believe they can respond within one to 24 hours. Only 19% believe they can respond within minutes.
Now set that against the attacker’s clock.
CrowdStrike’s 2026 Global Threat Report found that the average eCrime breakout time, the time between initial access and lateral movement to another system, fell to 29 minutes in 2025, down from 48 minutes the year before. The fastest observed breakout took only 27 seconds.
Put those figures together and the mismatch is clear. Attackers can begin moving laterally within half an hour, while many organisations still think about response in hours rather than minutes.
But technology is only part of the problem.
An organisation may detect suspicious activity quickly and still lose critical time deciding whether to isolate a system, shut down a service, cut off a supplier, inform a customer or escalate an incident to regulators.
Cyber resilience is increasingly becoming a decision-speed problem, not only a detection-speed problem.
The purpose of first-hour readiness is therefore not to make executives think faster during a crisis. It is to eliminate decisions that should never have been left until the incident.
Key takeaways
- The attacker’s clock now runs in minutes. The average eCrime breakout time fell to 29 minutes in 2025.
- The first hour is a decision problem as much as a technical one. The actions that can change the outcome often require business, legal or executive authority.
- Regulation has put business judgement on a clock. Organisations may have hours, not days, to assess serious incidents and begin reporting them.
- Cyber resilience requires a decision architecture. Authority, escalation thresholds, continuity priorities and reporting ownership should already be clear.
- The first hour should contain very few new decisions. The organisation should not be discovering who is allowed to act while an attack is underway.
The first hour is a decision problem
Consider what happens between the first alert and the first consequential action.
Someone notices something wrong. An identity behaves unusually. A supplier reports a breach. A ransom note appears on a shared drive.
The security team can investigate. But can it take a revenue-critical system offline? Cut a strategic partner’s access? Move an essential service into degraded operation? Tell a major customer their data may have been exposed? Determine that the incident has crossed a regulatory reporting threshold?
These are not purely technical decisions. They carry operational, financial, legal and reputational consequences.
And the person who knows what needs to happen may not be the person authorised to make it happen.
That is where time disappears.
Who owns the incident? Does legal need to approve containment? Who can disconnect a system supporting revenue? Who determines whether the event is serious enough to notify a regulator?
The attacker does not wait for that chain of approvals to resolve.
Recent research supports the concern. Sygnia’s 2026 survey of 600 senior security decision-makers found that 90% expected difficulties coordinating stakeholders during a major incident, 89% cited limited executive or board involvement, and 75% said legal and communications involvement could slow decision-making.
The issue is not simply whether organisations have incident response plans.
It is whether they have decision architecture.
Build a first-hour decision architecture
A good incident response plan explains what needs to happen.
A first-hour decision architecture answers a different question:
Who is allowed to make it happen?
Six decisions should already have an owner before an incident begins.
01 Recognition
What threshold turns a security event into a business crisis?
↓
02 Containment
Who can isolate a critical system without multiple levels of approval?
↓
03 Continuity
Who can activate degraded, manual or alternative operations?
↓
04 Classification
Who decides whether an incident is significant, major, material or reportable?
↓
05 Communication
Who can notify regulators, customers, insurers and partners?
↓
06 Recovery
Who can declare a restored system safe to return to production?
The objective is not to centralise authority. It is to remove ambiguity.
A serious incident should not trigger a debate about organisational structure. The organisation should know who owns each decision, what evidence they need and who takes over if they are unavailable.
The same applies externally. Legal counsel, insurers, incident responders, communications advisers and critical suppliers may all become part of the response.
If activating them depends on finding the right person, locating a contract or searching someone’s inbox, valuable response time is being spent on administration.
The incident may not look like an incident
The first critical decision is becoming harder because attackers do not always look obviously malicious.
CrowdStrike found that 82% of detections in 2025 were malware-free. Attackers increasingly operate through compromised identities, legitimate applications and trusted tools rather than relying solely on traditional malware.
Instead of an obviously malicious file, the security team may see a valid account behaving slightly differently. Instead of an attack tool, it may see legitimate administrative software being misused.
The first-hour problem therefore starts before containment:
When does unusual activity become serious enough to escalate?
If teams wait for certainty, attackers gain time. If every anomaly becomes a crisis, the organisation creates unnecessary disruption and alert fatigue.
First-hour readiness requires clear escalation thresholds, not certainty. Certainty is often unavailable while the most important early decisions are being made.
The second clock is regulatory
The attacker is not the only one imposing time pressure.
Across major regulatory regimes, organisations are increasingly required to classify and report serious cyber incidents while the facts are still developing.
Under NIS2, in-scope EU entities must provide an early warning within 24 hours of becoming aware of a significant incident, followed by a fuller incident notification within 72 hours.
Under DORA, financial entities must make an initial notification as early as possible and within four hours of classifying an ICT-related incident as major, while also meeting the outer limit of 24 hours after becoming aware of the incident.
Under GDPR, qualifying personal data breaches generally need to be reported to the relevant supervisory authority within 72 hours of awareness.
For US public companies, the SEC framework uses a different trigger. The disclosure deadline generally runs from the determination that a cybersecurity incident is material, and that determination must be made without unreasonable delay.
The deadlines differ.
The governance problem does not.
Someone has to assess what the organisation knows, how serious the incident is, whether a reporting threshold has been crossed and who has authority to act on that judgement.
These decisions often have to be made while the investigation is still underway.
That makes regulatory preparedness part of first-hour readiness. An incident plan that identifies technical responders but leaves classification, disclosure and escalation authority unclear is incomplete.
Define your minimum viable business
During a serious incident, organisations also need to answer a narrower question:
What absolutely has to keep running while the rest is disrupted?
Call it your minimum viable business.
It is the small set of services and processes whose loss would create unacceptable operational, financial, safety or regulatory consequences.
The list should be deliberately short. If everything is critical, nothing is prioritised.
But minimum viable business is not simply a recovery list. It represents pre-agreed trade-offs.
Which services must survive? Which systems are you prepared to deliberately take offline to contain an attack? What degraded or manual alternatives exist? Who has authority to activate them? How long can they operate?
Those decisions become considerably harder when revenue, customer commitments, regulation and security pull in different directions.
IBM’s 2025 breach research reinforces the broader importance of time. The average breach took 241 days to identify and contain, roughly eight months. Breaches with lifecycles under 200 days cost an average of $3.87 million, compared with $5.01 million for those that continued beyond 200 days.
The first hour will not determine every breach cost. But it can disproportionately shape what happens next.
Measure the decisions, not just the detections
Security teams already measure how quickly alerts are generated, triaged and contained.
Those metrics matter. But organisations should also measure the decisions between them.
Five clocks can reveal whether your organisation is actually ready to respond:
01 → Recognise
How long before we know this is more than routine IT trouble?
02 → Decide
Can someone approve high-impact action without an extended approval chain?
03 → Activate
How quickly can essential services move into degraded operation?
04 → Coordinate
Can we reach legal, insurers, responders and critical suppliers immediately?
05 → Recover
Do we know restored systems are safe and working correctly?
An organisation might detect an intrusion in five minutes and still take an hour to authorise containment.
That is not a detection failure.
It is a decision failure.
And another detection tool will not fix an approval chain.
Defensible speed, not speed at any cost
None of this means every suspicious event should trigger the most severe response.
Fast decisions do not compensate for weak detection, poor containment or unreliable recovery. Overreacting can create unnecessary disruption. Underreacting can give an attacker more time to expand access.
The objective is defensible speed.
The right person needs to make the right decision, using agreed criteria and the best information available at that moment.
Speed without judgement can create a faster mistake. Judgement without authority creates paralysis.
First-hour readiness requires both.
Test where the organisation hesitates
Your next tabletop exercise should test more than whether the security team can follow the playbook.
Ask:
- Could we recognise a serious business incident quickly enough?
- Could someone authorise a difficult containment decision without an unclear approval chain?
- Could we keep our critical services operating?
- Could we reach every external party we depend on?
- Could we demonstrate that recovered systems were safe before returning them to production?
Then remove the easy assumptions.
The CEO cannot be reached. Legal wants more evidence. Taking the compromised system offline will disrupt customers. A critical supplier is also investigating an incident. You still do not know whether data has been taken.
The purpose of the exercise is not to prove that the plan works.
It is to find where the organisation hesitates.
The bottom line
The first hour should contain very few new decisions.
The investigation will produce new facts. The attacker may create new problems. The organisation will have to adapt.
But authority, escalation paths, critical business services, external contacts, regulatory ownership and recovery criteria should not be discovered during the crisis.
That is the real purpose of first-hour readiness.
Not to make executives react faster. Not to create another incident response checklist. And not to assume that faster technology automatically creates a faster organisation.
It is to make the difficult decisions before the clock starts.
Because if your organisation needs the first hour to work out who can make the hard calls, the failure happened before the incident began.
ThreatScene helps organisations close these gaps through incident readiness, cyber resilience exercises, regulatory preparedness and incident response support built around real operational and decision-making requirements.
Stay ready. Stay resilient. Stay operational.
Curated with purpose, delivered with precision | ThreatScene Team
Sources
- CrowdStrike, 2026 Global Threat Report (average eCrime breakout time 29 minutes, fastest 27 seconds, 82% of detections malware-free). https://www.crowdstrike.com/en-us/press-releases/2026-crowdstrike-global-threat-report/
- Kroll, State of Cyber Resilience 2026 (72% believe they can respond within 1–24 hours, 19% within minutes). https://www.kroll.com/en/publications/cyber/state-of-cyber-resilience-2026
- Sygnia, CISO Survey 2026 (stakeholder coordination, executive involvement and incident decision-making). https://www.sygnia.co/guides-and-tools/ciso-survey-2026/
- IBM, Cost of a Data Breach Report 2025 (241-day breach lifecycle; $3.87m vs $5.01m based on breach lifecycle). https://www.ibm.com/think/x-force/2025-cost-of-a-data-breach-navigating-ai
- NIS2: Directive (EU) 2022/2555, Articles 20 and 23. https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng
- DORA: Regulation (EU) 2022/2554 and Commission Delegated Regulation (EU) 2025/301. https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng
- GDPR: Regulation (EU) 2016/679, Article 33. https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng
- US Securities and Exchange Commission, Cybersecurity Risk Management, Strategy, Governance and Incident Disclosure. https://www.sec.gov/resources-small-businesses/small-business-compliance-guides/cybersecurity-risk-management-strategy-governance-incident-disclosure
