To get approval for chaos experiments in a regulated company, present them as controlled resilience tests, not random breakage. Bring a written hypothesis, a small blast radius, a stop condition, a rollback plan and an evidence template. Then ask for a standing approval for a defined class of low-risk tests.
Speak the approver's language
Change advisory boards and risk teams care about three things: what could go wrong, who is accountable, and what proof exists afterwards. A request that says we want to break production to learn something will be refused. A request that says we will test our failover on one non-critical service for ten minutes, with a named owner and an abort button, is a normal change.
The Principles of Chaos Engineering support that framing. They state that limiting and containing the fallout of an experiment is the responsibility of the person running it, and that experiments start from a hypothesis about steady state.
What to put in the request
- Hypothesis. One sentence, see writing a chaos hypothesis.
- Scope. Which service, which environment, which fault, how long, what time window.
- Blast radius. Who could be affected and how many. Start with staging or a small slice of traffic.
- Stop conditions. The metrics and thresholds that end the test, and who presses stop. See stop conditions and guardrails.
- Rollback. Exactly how to undo the fault, and how long it takes.
- Comms. Who is told before and after, including support.
- Evidence. What you will record and where it will be stored.
Standing approval for a class
Asking for approval every time kills the practice. Propose a pre-approved category: for example, single instance failure on non-customer-facing services in a given window, with a standard template. Anything outside the class goes through normal change. Review the class every quarter.
Link it to existing obligations
Many regimes already expect resilience testing. The EU's DORA regulation has a digital operational resilience testing chapter, covered in DORA digital resilience testing, Article 25. SOC 2 style audits often ask for evidence of disaster recovery and continuity tests, see SOC 2 disaster recovery and business continuity test. A chaos experiment with good records can feed that evidence. Check the actual regulation text or ask your auditor which tests count; this post is not legal advice.
Keep the paper trail
For each run, store the approved request, the timeline, the metrics before and after, any incident tickets raised and the follow-up actions with owners. Keep it somewhere the auditor can reach without a hunt.
Quick check
Do we have to test in production?
Not to begin with. Staging and pre-production tests are valid and easier to approve. Move up gradually as evidence builds.
What if the board still says no?
Offer a game day first, a tabletop where the team talks through the failure. See a game day plan for a security control outage.
Sources
Last reviewed: 19 October 2026.
