What are the signs that a security programme is failing because it has not been tested realistically?

A programme is failing when leaders cannot explain what would happen during a breach, when teams have no playbooks, and when critical owners are unprepared for a drill. Those symptoms usually mean the organisation has controls on paper but not in practice. Realistic testing exposes where assumptions, ownership, and response steps are still missing.

What failure looks like when testing has stayed theoretical

A security programme often looks healthy on paper long before it works under pressure. The clearest sign of failure is that senior leaders cannot describe the breach sequence, recovery owners, or decision points with confidence because the organisation has never exercised them against a realistic scenario.

That gap usually shows up in a few ways: plans exist but are fragmented, handoffs are unclear, and teams rely on assumptions about who will call whom, who approves containment, and what evidence will be preserved. If the programme has not been tested in a way that resembles a real incident, these assumptions stay hidden until the first live event.

Another symptom is that response capability depends on a few people remembering how things should work. Mature programmes can explain not just the policy, but the practical sequence for triage, escalation, containment, communications, and recovery. When the team cannot produce that sequence consistently, the programme is still aspirational rather than operational.

How to recognise the gaps in drills, ownership, and recovery

Unrealistic testing does not just miss technical weaknesses, it misses coordination failures. A drill that is fully announced, lightly scripted, or run only by the people who already know the answer can create false confidence because it never pressures the organisation’s real dependencies, such as business approval, legal review, crisis communications, or service restoration.

One useful signal is that critical owners cannot act quickly without improvising. If application owners, infrastructure teams, communications leads, or incident commanders do not already know their role in a breach, the programme has not translated governance into executable practice. The same is true when playbooks exist but are too generic to guide real decisions under time pressure.

Testing also needs to surface recovery realities, not just detection. A programme is weak when it can describe alerting and containment but cannot show how systems, data, and business operations return to a trustworthy state. For that reason, realistic exercises should probe whether recovery criteria are defined, whether evidence of validation is collected, and whether the organisation can tell when it is safe to resume normal operations.

Why the problem persists and what it tells you about control maturity

When testing does not resemble the environment, it mostly validates documentation. ISO/IEC 27002:2022 Information Security Controls is a useful reminder that controls must be implemented and operated, not merely stated. A programme that has never been exercised realistically is usually failing the transition from design intent to dependable execution.

The deeper issue is usually control ownership. The organisation may have many security activities, but no one has been made accountable for cross-functional response, decision speed, or recovery readiness. That is why a realistic test is so revealing: it shows whether the control set is integrated enough to function as a programme, or whether each team is only handling its own fragment.

Testing realism also exposes whether the security team is measuring the right thing. If the only evidence of readiness is that a tabletop happened or a checklist was completed, the programme is measuring participation, not response quality. Mature testing asks whether the organisation can execute, coordinate, and recover under conditions that still preserve business pressure and uncertainty.

Standards & Framework Alignment

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

NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
ISO/IEC 27001:2022	A.5.24 — Information security incident management planning and preparation	Realistic testing is central to preparing incident response capability.
	A.5.26 — Response to information security incidents	The question is about whether response capability actually works during a breach.
Recommendation — Test incident response plans under realistic scenarios and validate decision ownership before an event occurs. Verify that response procedures are executable, not just documented, through live or realistic exercises.
NIST CSF 2.0	RS.RP-01 — Response Plan Execution	Failure appears when the organisation cannot carry out its response plan in practice.
	RC.RP-01 — Recovery Plan Execution	The symptom includes not knowing how restoration and return to service will happen.
Recommendation — Exercise response plan execution so teams can prove they can follow it under realistic conditions. Test recovery execution to confirm restoration steps, owners, and validation criteria are workable.
CIS Controls v8	CIS-17 — Incident Response Management	The subject is the operational maturity of incident response, including drills and playbooks.
Recommendation — Run scenario-based incident exercises and update playbooks based on observed execution gaps.

Practitioner Guidance

What to verify: Confirm that exercises include real decision owners, realistic time pressure, and at least one scenario that forces a cross-team decision about containment or restoration. If every drill is fully pre-briefed, assume it is under-testing coordination risk.

What good looks like: The best indicator is not that people remember the answers, but that they can show who decides, what evidence they use, and how the response path changes when the incident affects production systems or critical services.

Common mistake: Treating tabletop success as proof of readiness. A team can talk through a breach smoothly and still fail when the first real outage, reputational concern, or legal hold creates friction.

Practitioner takeaway: If the organisation cannot demonstrate response behaviour under believable pressure, the programme is not mature enough to trust, even if the controls look complete in policy and audit material.