A chaos hypothesis states that, when a specific fault occurs, a named control will behave a certain way and a measurable steady state will hold. For a security control the measure is usually denials, alerts and latency, not just uptime. Write it before you inject anything.
Start with steady state
The Principles of Chaos Engineering define steady state as a measurable output of the system that indicates normal behavior, and say to measure outputs, not internal attributes. Throughput, error rates and latency percentiles are the examples they give.
For a security control, add outputs that prove the control still works: the rate of denied requests for known-bad test traffic, the time to alert, and the share of requests that carry a valid identity.
A hypothesis template
AWS suggests this shape: if a specific fault occurs, the workload will use certain mitigating controls to maintain a business or technical metric. Adapt it:
If the token validation service is unreachable for five minutes, the API gateway will keep honoring already validated sessions for up to two minutes, reject new logins, and raise an alert within one minute, while the rate of accepted requests with an invalid token stays at zero.
Notice the parts. A named fault. A duration. Specific behavior. A security metric that must not change.
Three more examples
If the secrets manager returns errors, services keep running on cached credentials for their remaining lifetime and no service falls back to a hard coded value.
If the pipeline policy service times out, deployments to production pause instead of proceeding, and the on-call is paged.
If the log shipper is blocked, the host buffers security events locally and drops no audit records for one hour.
Rules for picking a fault
Prioritize by impact or frequency, as the principles suggest. Use past incidents and near misses. And only run an experiment you expect the system to survive. AWS is direct that if you know the workload will fail, you should not run the experiment, because it teaches you nothing new. Fix the known problem first.
Record the result
After the run, note whether steady state held, what surprised you, and what changed. If the hypothesis held, keep the experiment as an automated regression test. If it did not, the failure is the finding.
Quick check
Do I need production to test a security control?
Production is preferred by the principles, but AWS advises trying faults in pre-production first and verifying your stop conditions work.
What if the hypothesis fails?
That is useful. Fix the design, then rerun the same experiment to confirm.
Sources
- Principles of Chaos Engineering
- AWS Well-Architected REL12-BP04: Test resiliency using chaos engineering
Last reviewed: 19 October 2026.
