A quarterly access review is documented, approved and assigned an owner. The evidence shows it was performed in January and in September, and not in the other two quarters. The auditor calls the control ineffective. The owner argues the control is well designed. Who is right?

The mechanism

A control is assessed twice, against two different questions, and they have different answers.

Design effectiveness asks: if this control were performed exactly as written, would it prevent or detect the risk? That is a question about the procedure. A quarterly access review that compares entitlements against a current joiners-and-leavers list, with a named approver and a remediation path, is well designed.

Operating effectiveness asks: was it performed, throughout the period, as designed? That is a question about evidence. Two performances out of four is a failure of operation, and it is not softened by the quality of the design.

Separating them is what makes the finding actionable. A design failure means rewriting the control. An operating failure means the control is right and something about capacity, ownership or timing is wrong. Those are different remediations owned by different people, and a report that merges them produces the wrong fix.

Why the other options fail

• "The control exists and is documented." Existence is design. Auditors sample evidence precisely because documented controls that are not performed are the common case, not the exception.
• "A control that is not performed was never well designed." Tempting and wrong as stated, though it contains a real insight: a control that is chronically not performed often is badly designed, because it asks for effort nobody has. That belongs in the root cause of the operating finding, not in a design finding.
• "Two performances is sufficient." The control says quarterly. A control performed at a different frequency than specified is not the control that was assessed, and the gap between January and September is precisely where an unremoved leaver's access would sit.

When this is the wrong distinction to draw

For a control that is fully automated and enforced by the system — a policy that rejects a non-compliant deployment — design and operation converge, because the system cannot perform it differently than it is written. That convergence is the strongest argument for automating a control: it removes an entire category of finding rather than making one easier to evidence.

It does not converge for anything requiring a human judgement, which is most of governance, and that is where the distinction earns its keep.

Choose automation when the control is performed more than about 4 times a year and its judgement can be expressed as a rule. What that costs is a policy to maintain and a bypass path to govern; what it buys is that an operating finding becomes impossible for that control. It flips where the judgement is genuinely contextual — deciding whether an access request is reasonable — since automating it produces a control that passes while checking nothing, which is the worse outcome. Control frameworks have drawn the design-versus-operation line this way since the internal-control model published in 1992, and it has survived every revision because the two findings need different owners.