They should ask whether the control could have achieved its objective if performed correctly. If the answer is no, the design is faulty. If the design is sound but the review was skipped, poorly executed, or done by an unqualified person, the issue is operating effectiveness.
How auditors separate design failure from operating failure
The cleanest test is whether the control, as designed, could have met its objective at all. If the answer is no, the problem sits in design. If the design would work but the control was not carried out, was carried out badly, or was carried out by someone without the right competence, the issue is operating effectiveness. That distinction matters because it changes what the auditor tests and what management must fix.
What “could have worked” really means in practice
Design is about the control logic, not the event outcome. A control can be perfectly executed and still fail if it is inherently incapable of preventing or detecting the stated risk. That usually shows up when the control does not cover the full population, lacks a required threshold, depends on an unverified assumption, or is too weak for the threat it is meant to address.
Operating effectiveness is about whether the designed control actually ran as intended, consistently enough, with the right evidence. A sound review that was skipped, performed after the fact, or signed off without sufficient skill is not a design issue. The design exists, but the operating process did not deliver it.
Evidence that helps auditors make the call
Auditors normally need two things: the stated control objective and proof of how the control is supposed to work. Then they compare that design to the evidence of execution, such as review sign-offs, exception handling, timestamps, reviewer qualifications, and samples showing the control was performed over time. If the paper process and the actual execution diverge, the issue is usually operating effectiveness, not design.
Where the distinction gets tricky is when the control has an assumed safeguard built into it. If the control depends on manual judgment, segregation of duties, or timely escalation, the auditor should test whether that dependency is realistic and consistently evidenced. A control that only works under ideal conditions may be a design weakness even if the documented procedure looks complete.
Risk and Threat Considerations
When auditors confuse design and operating problems, remediation can miss the real failure mode. A design defect usually creates repeated exposure because the control is incapable of stopping the issue, while an operating defect may create intermittent exposure tied to missed performance, poor evidence, or weak supervision.
Failure mechanism: The control either lacks the logic needed to achieve its objective, or the logic exists but execution breaks the control chain through omission, delay, poor quality, or unqualified performance.
Impact: Misclassification can lead to the wrong fix, such as retraining people when the real issue is a flawed control, or redesigning a control when the real issue is weak execution and monitoring.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CA-2 — Control Assessments | Auditor testing hinges on assessing whether the control design and operation meet the intended objective. |
| Recommendation — Assess the control’s design and operating evidence separately against the stated objective. | ||
| NIST CSF 2.0 | GV.OV-01 — Oversight and Accountability | The question is an audit judgement about evaluating control effectiveness and oversight evidence. |
| Recommendation — Use oversight reviews to distinguish control design flaws from execution failures. | ||
| ISO/IEC 27001:2022 | A.5.35 — Independent review of information security | Independent review requires checking whether a control is suitably designed and consistently operating. |
| Recommendation — Review controls independently to validate both design adequacy and operating performance. | ||
Practitioner Guidance
What to verify: Start by comparing the control objective to the exact design steps. If the steps, as written, would not prevent or detect the stated risk even when followed correctly, treat it as a design issue.
Decision rule: If one correct execution would still leave the risk materially uncontrolled, the problem is design; if correct execution would likely have worked but the actual execution failed, the problem is operating effectiveness.
What good looks like: The control has a clear objective, a plausible mechanism for achieving it, and repeatable evidence that the mechanism was performed by the right person at the right time.
Practitioner takeaway: Do not let a visible process lull you into calling something “designed” if the process cannot succeed in principle, and do not call a weak execution “design” if the control itself would have worked.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org