Should resilience programmes prioritise simulation over another policy update?

Yes, when the main weakness is judgement, coordination, or escalation under pressure. Policies are useful, but they do not reveal whether leaders can make the right call when information is incomplete and stakes are rising. Simulation should come first when the organisation already has documents but has not tested how people actually behave together.

Why Simulation Should Usually Come Before Another Policy Update

Policy updates improve consistency, but resilience programmes fail when they assume written rules are the same as executed behaviour. Simulation is the faster test of judgement under stress: it shows whether escalation paths are clear, whether decision rights are understood, and whether teams can coordinate when the situation is ambiguous or time constrained.

That matters because resilience is not only about having the right document set. It is about whether the organisation can actually absorb disruption, make decisions with incomplete information, and keep recovery moving when normal assumptions are broken. A policy can say what should happen; a simulation reveals what people will do.

When the weakness is operational coordination, simulation is usually the higher-value control because it exercises the handoffs between security, operations, legal, communications, and leadership. Those are the points where real incidents tend to slow down, especially when people wait for clarification instead of acting on pre-agreed authority.

What Simulation Tests That Policy Cannot

Simulation tests timing, escalation quality, and the organisation’s ability to improvise inside guardrails. It exposes gaps that are invisible in a policy review, such as unclear ownership, slow approvals, conflicting instructions, or leaders who are comfortable with the text but not with the pressure of a live decision.

It also validates whether the programme’s assumptions still hold. A policy may be accurate on paper and still fail in practice if the business has changed, the on-call model is outdated, or recovery dependencies are more fragile than the documentation suggests. In that sense, simulation is a control for the current operating reality, not just the written standard.

For that reason, simulation is especially valuable when the organisation already has a policy baseline and needs evidence of response readiness. If the policy is missing, broken, or legally stale, update it first. If the policy exists and the issue is execution, test the execution path.

When to Prioritise the Update Instead

Policy work should come first when the organisation has no agreed authority model, no escalation rule, or no common standard for how incidents are classified and handled. In those cases, simulation can only reveal confusion faster, not fix the underlying ambiguity.

Another policy update is also the right first move when the problem is governance, not behaviour, for example where accountabilities are undefined, approval thresholds are missing, or the current policy no longer reflects regulatory, contractual, or architectural reality. A simulation built on a broken policy can create the illusion of preparedness while leaving the core rule set unchanged.

The practical decision is simple: update the policy first when the question is “what is the rule?”; simulate first when the question is “can we follow the rule under pressure?”

Risk and Threat Considerations

Resilience failures often arise from control gaps that only appear during stress, not from the absence of policy language. If an organisation updates documents without testing decision-making, it can overestimate its ability to contain disruption, prolong recovery, or coordinate a crisis response.

Failure mechanism: Teams rely on the existence of approved policy, but the real failure sits in escalation latency, unclear authority, or inconsistent cross-functional execution. Under pressure, the organisation discovers that the document did not define who decides, who communicates, or who can override normal process.

Impact: Delayed containment, slower recovery, contradictory messaging, and avoidable business disruption can follow. In severe cases, the organisation learns its limits during a live event rather than in a controlled exercise, which raises operational, reputational, and regulatory exposure.

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 and DORA define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.RR-02 — Roles, Responsibilities, and Authorities	Simulation exposes whether incident and resilience roles are actually understood under pressure.
	RC.RP-01 — Recovery Plan Execution	The question is about whether teams can execute resilience actions, not just write them.
Recommendation — Define and test decision rights so escalation and recovery actions happen without hesitation. Exercise recovery plans to confirm they work during realistic disruption.
ISO/IEC 27001:2022	A.5.29 — Information security during disruption	Resilience programmes must maintain security and response behaviour during disruptive events.
Recommendation — Test whether security and recovery controls remain effective under disruption.
CIS Controls v8	CIS-17 — Incident Response Management	Simulation is a core way to validate response coordination, escalation, and decision-making.
Recommendation — Run exercises that validate incident roles, communications, and escalation paths.
DORA	Operational resilience testing	Operational resilience testing is directly about proving the organisation can withstand and recover from disruption.
Recommendation — Use resilience tests to validate response and recovery capability under stress.

Practitioner Guidance

What to prioritise: Start with simulation if your current documents are broadly complete and the open question is how the organisation behaves during uncertainty. Prioritise policy updates if the incident roles, escalation thresholds, or decision rights are not actually settled.

What to verify: Before trusting the programme, verify that simulations cover the specific failure mode you worry about, not just a generic table-top. The exercise should test who makes the call, how quickly they escalate, and whether recovery dependencies are understood by the people who will be accountable in a real event.

Practitioner takeaway: Use policy to define the expected state, but use simulation to prove the organisation can reach that state when conditions are messy, compressed, and incomplete.