Because an audit measures design and documentation, not misuse under attack conditions. A control can be approved, written down, and even consistently reviewed while still being bypassed through cloud misconfiguration, excessive privilege, or weak trust relationships across systems.
Why audits can be green while controls still fail at runtime
An audit usually tests whether the control exists, is documented, and was reviewed on schedule. It does not fully recreate hostile conditions, cross-system dependencies, or the messy edge cases where access is abused, inherited, or bypassed. That is why identity controls can satisfy the audit trail yet still leave room for real-world compromise.
The gap is especially visible when the control depends on assumptions that are true in a spreadsheet but brittle in production. A clean approval record does not guarantee the right identities, privileges, trust boundaries, or cloud settings are actually enforced the way the control design intended.
One useful way to think about the problem is that the audit asks, “Is the control present and governed?” while operations ask, “Does it still hold when attackers, integrations, and misconfigurations stress it?” In practice, the answer can diverge whenever a control is too broad, too static, or too dependent on surrounding systems behaving perfectly.
Where the practice gap usually appears
Most failures come from the control plane around the control, not from the policy statement itself. Excessive privilege, stale access, weak segmentation, and cloud configuration drift can all make a formally approved control ineffective without obviously violating the audit evidence that was collected.
That is why identity and access controls often need audit and regulatory perspective alongside operational validation. A review may confirm recertification happened, but not whether the entitlement still reflects current business need, whether the secret was reused elsewhere, or whether a trust relationship extends beyond the intended boundary.
The same problem shows up in lifecycle and ownership gaps. If no one owns the account, service, or token after deployment, controls can remain approved on paper while drift accumulates in the live environment. Lifecycle management matters because provisioning, rotation, and offboarding are what keep the control aligned with reality.
It also helps to look at control failure as an inventory and privilege problem, not just an audit problem. Common NHI issues such as secret sprawl, reused identities, and excessive permissions are exactly the kind of conditions that let a compliant control collapse under actual use.
What to test beyond the audit evidence
To know whether a control works in practice, test the behaviour that the audit did not simulate. That means checking whether privilege is bounded in real workflows, whether authentication still resists misuse after integration changes, and whether a control remains effective when cloud policy, token scope, or delegation settings are altered.
Practitioners should also verify that the control is observable. If the only evidence is a quarterly attestation, you may know the review happened but not whether the control is currently effective. Runtime signals such as privilege anomalies, failed assumptions about trust, and unexpected access paths are often more revealing than a signed-off policy.
For identity-heavy environments, the most practical question is whether the control can survive account compromise, delegated access, or configuration drift without turning into a hidden path to production. Identity security programme design is useful here because it forces ownership, governance, and operating model questions that audits often surface only indirectly.
External control frameworks reinforce the same lesson. SOC 2 Trust Services Criteria can tell you whether the control is being governed, but practitioners still need separate runtime testing to prove it behaves safely under abuse, not just under review.
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 CIS Controls v8 set the technical controls, while SOC 2 (AICPA) and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SOC 2 (AICPA) | CC6.1 — Logical and Physical Access Controls | Identity controls can pass audit while still failing if access paths are broader in production. |
| Recommendation — Test live access paths and revoke any entitlement that exceeds intended operating scope. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Excess privilege is a core reason approved identity controls still fail in practice. |
| Recommendation — Enforce least privilege and review actual entitlements against current job or workload need. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question is about why documented access control can still break at runtime. |
| Recommendation — Validate that access control settings match the approved design in the live environment. | ||
| CIS Controls v8 | 5 — Account Management | Account and entitlement drift often explains audit-pass, runtime-fail identity controls. |
| Recommendation — Continuously manage accounts, ownership, and removal of stale access paths. | ||
Practitioner Guidance
What to verify: Treat any audit pass as a starting point, not proof of resilience. Verify the control against live privileges, active cloud settings, and current trust relationships, especially where the control depends on periodic review rather than continuous enforcement.
Decision rule: If a control can be bypassed by excess privilege, stale credentials, or an unreviewed integration path, prioritise fixing the runtime weakness before adding more documentation or another attestation cycle.
What good looks like: The control is narrow, observable, and revocable, with clear ownership and evidence that the live environment still matches the approved design after deployment, change, or rotation.
Practitioner takeaway: A passing audit tells you the control was acceptable at review time; operational confidence only exists when the control still works after the environment, privileges, and trust paths have changed.