Fail-Closed Control

A pipeline gate calls a scanner. The scanner's credential has expired. The gate catches the error, logs a warning, and lets the build proceed.

From that moment the control does not operate, and everything looks normal. Builds pass, the dashboard is green, and the next audit — months later — finds a control that was well designed and did not run.

Why this is the dominant way controls decay

The distinction that matters in assurance is between design effectiveness (would it address the risk if operated) and operating effectiveness (did it actually operate, throughout the period, on every occurrence). A control that did not run provides no protection whatsoever, and the design assessment is the cheap half.

Failing open is the most common cause, because it is the path of least resistance for whoever wrote the gate: blocking builds on an infrastructure error is unpopular, and swallowing the error is one line.

Implementation patterns

• Deny when the control cannot evaluate, with a clear message naming what could not be checked.
• A deliberate, time-bounded bypass for genuine infrastructure failure, requiring an approval and producing a record — rather than an implicit bypass in an exception handler.
• Monitoring the control itself: execution count, coverage percentage, failure rate. A control that stopped running produces silence, and silence looks like success.
• Coverage measured against the authoritative inventory, not against the systems the control already knows about — scope drift means a control operating perfectly on a shrinking share of the estate.
• A named owner with the control's health in their operational dashboard.
• Alert on absence, since the absence of findings is ambiguous between "nothing wrong" and "not running".

Industry example

Organisations that instrument their controls consistently discover the same set of dormant ones: a scanner whose API moved, a policy check bypassed for an urgent release two years ago, a gate that only ever ran on services created through the original template. None of these produced an error anyone saw.

The reframing that fixes it is to treat controls as production systems — with owners, monitoring, alerting, on-call and change control. Organisations that treat them as compliance artefacts get compliance artefacts, which stop working and nobody notices until an audit.

Failure scenarios

• Errors swallowed in the gate, the root cause.
• Bypasses added under pressure and never removed.
• Scope drift, where new services are created outside the pipeline the control lives in.
• No control-health monitoring, so silence is read as success.
• Noisy detective controls muted, which is the usual end state when severity is not tied to consequence.

Trade-offs

Failing closed blocks legitimate work when the control's own infrastructure fails, and a scanner outage can halt every deployment across the organisation. That is a real availability cost and it is the reason teams fail open in the first place.

The resolution is not to fail open but to make the bypass explicit, approved and recorded — which preserves the ability to ship during an outage while ensuring the gap is visible and bounded. An invisible bypass is the problem; a visible one is a managed risk.

Interview question

"Your dependency scanner has been failing to authenticate for three months and every build passed. What should have happened at the moment it first failed, and what signal would have told you?"