Join our Newsletter — 33% off our NHI Course
Home› FAQ› Governance, Ownership & Risk› What are the signs that an incident response…
Governance, Ownership & Risk

What are the signs that an incident response programme is not operational?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated October 11, 2026 Domain: Governance, Ownership & Risk

Common signs include unclear escalation paths, no incident register, ad hoc documentation in email or chat, and tabletop exercises that never test reportability or evidence preservation. If the team cannot explain who files, who approves, and what gets preserved, the programme is still theoretical.

When an Incident Response Programme Is Still Only Paper

An incident response programme is not operational when it exists as policy text but cannot reliably direct action under pressure. The clearest signal is not the absence of documents, but the absence of repeatable decisions: escalation, ownership, evidence handling, reporting, and containment all have to be worked out in the moment.

A mature programme turns uncertainty into a known workflow. If the team cannot show that workflow in practice, through tickets, logs, runbooks, approvals, and exercised handoffs, the programme is not yet a functioning control.

What the Team Can and Cannot Do During a Real Incident

The operational test is whether people can state, without improvising, who declares an incident, who approves containment, who preserves evidence, and who communicates externally. When those answers vary by person or by shift, the programme is fragile because it depends on memory and personality rather than process.

Another sign is that incidents are discussed only after the fact, with no consistent incident register or case history. That usually means the organisation cannot trend recurring failure modes, measure response timeliness, or prove that lessons learned are being converted into control changes.

Evidence discipline matters as much as speed. Tabletop exercises that never ask teams to preserve logs, retain timestamps, protect chain of custody, or decide when reportability begins are rehearsing discussion, not response.

How to Tell Whether Response Is a Control or a Conversation

If the primary artefacts are scattered across email and chat, the programme is usually too informal to sustain investigation quality. Useful response programmes create an audit trail that can be reviewed later, not a set of informal decisions that disappear when people leave the channel.

One practical distinction is whether exercise outcomes change the playbook. If the same gaps appear repeatedly, but nothing is updated, the programme is describing itself instead of improving itself.

Operational response also depends on clarity around reportability. A team that cannot tell when an event becomes a reportable incident, or which legal, regulatory, customer, or internal notifications are triggered, has not translated policy into decision rules.

Risk and Threat Considerations

A non-operational incident response programme increases the chance that a real event will be contained late, documented badly, or escalated inconsistently. That creates avoidable exposure because the organisation may lose evidence, miss notification deadlines, or make containment decisions without a reliable authority structure.

Failure mechanism: Response steps exist in theory, but no one has rehearsed the handoffs, preservation steps, or reporting thresholds well enough to execute them under stress.

Impact: The organisation can end up with delayed containment, incomplete forensic records, weak post-incident learning, and a poor position for legal or regulatory scrutiny.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST SP 800-53 Rev 5AU-6 — Audit Record Review, Analysis, and ReportingIncident response needs reviewed, usable records to reconstruct actions and timelines.
IR-4 — Incident HandlingThe subject is whether the organisation can execute incident handling as a live capability.
IR-6 — Incident ReportingReportability is a core sign of operational incident response readiness.
Recommendation — Review incident records regularly and route findings into response improvements. Define and exercise incident handling steps, roles, and escalation paths. Establish reportability thresholds and test notification workflows.
ISO/IEC 27001:2022A.5.24 — Information security incident management planning and preparationPreparation and exercised response are central to judging programme operability.
A.5.25 — Assessment and decision on information security eventsOperational response requires clear decisions on what becomes an incident.
A.5.28 — Collection of evidenceEvidence preservation is one of the clearest operational readiness tests.
Recommendation — Prepare and test incident response roles, channels, and procedures. Set decision rules for classifying events and escalating incidents. Define evidence handling steps and preserve admissible incident artefacts.
CIS Controls v8CIS-17 — Incident Response ManagementCIS explicitly addresses incident response capability, testing, and improvement.
CIS-8 — Audit Log ManagementOperational incident response depends on logs that can support investigation.
Recommendation — Maintain and exercise an incident response process with clear ownership. Retain, review, and protect logs needed for incident investigation.

Practitioner Guidance

What to verify: Test the programme against a live or realistic scenario and confirm that someone can produce the incident record, explain the escalation chain, identify the evidence set to preserve, and name the approval points for containment and disclosure.

What good looks like: Exercises should end with concrete artefacts, not just notes, including a case record, time-stamped decisions, preservation actions, and a short list of changes that were actually fed back into the runbook.

Common mistake: Treating a tabletop as proof of readiness even when it never forces the team to decide reportability, ownership, or evidence retention.

Practitioner takeaway: If the programme cannot survive a realistic exercise without informal memory, side conversations, or after-the-fact reconstruction, it is not operational, it is aspirational.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org