How do organisations know whether internal controls are actually working?

Why This Matters for Security Teams

Controls are only meaningful if they change outcomes: fewer unsafe approvals, fewer exceptions that slip through, and faster detection when something drifts. The practical test is whether the control still behaves under pressure, not whether it exists on paper. NHI-heavy environments make this harder because service accounts, API keys, and automation often bypass the human workflows that traditional reviews were designed to observe. NHIMG notes that only 5.7% of organisations have full visibility into their service accounts, which is why control testing often starts with incomplete evidence rather than a clean baseline. The NIST Cybersecurity Framework 2.0 is useful here because it treats governance, detection, and response as operational functions, not documentation exercises.

In practice, teams discover that a control is ineffective when the process is being followed but the risk is unchanged: access remains broad, recertifications are rubber-stamped, and reconciliation never forces remediation. The signal is not whether a control owner can point to a policy, but whether they can explain why the last exception mattered and what changed because of it. In practice, many security teams encounter control failure only after an audit, incident, or entitlement review has already exposed the gap, rather than through intentional control testing.

How It Works in Practice

Working controls create a consistent chain between request, approval, enforcement, and review. That chain should be testable end to end. For NHIs, this means checking whether a credential or entitlement was issued for a defined purpose, whether its scope matched the approved use case, whether the access was actually consumed as expected, and whether the control produced evidence that an owner can verify. The Ultimate Guide to NHIs — Standards is a useful reference for aligning those checks to lifecycle, rotation, and visibility expectations.

Teams usually validate controls through a mix of sampling, continuous monitoring, and reconciliation. Good practice is to compare what was requested, what was approved, what was provisioned, and what was used. If those records diverge, the control is weak even if the workflow completed successfully.

• Review whether approvals include a clear business justification and an owner who can be held accountable.
• Check whether actual access matches the minimum scope needed for the task or system.
• Confirm that logs show use, expiry, and revocation rather than only creation events.
• Reconcile periodic reviews against live entitlements to see whether anything changed.

For broader control design, the NIST Cybersecurity Framework 2.0 is helpful because it encourages evidence-based control assurance across identify, protect, detect, respond, and recover. The strongest controls are the ones that keep producing the same result even when staff rotate, systems change, or the approval path is partially automated. These controls tend to break down when entitlements are granted outside the standard workflow because the evidence trail becomes fragmented and no longer supports reliable reconciliation.

Common Variations and Edge Cases

Tighter control testing often increases operational overhead, requiring organisations to balance assurance against speed and user friction. That tradeoff is especially visible where automation is high, because frequent changes can make a control look noisy even when it is functioning correctly. Current guidance suggests treating that noise as a signal to refine the control threshold, not to abandon the control entirely.

There is no universal standard for perfect control efficacy scoring yet. Some organisations rely on exception rates, others on time-to-detect, and others on whether reviewers consistently revoke access that no longer has a current justification. The right metric depends on the control objective. A payment approval control should be judged differently from a secrets rotation control, and a detection control should not be measured the same way as a preventative one.

Edge cases matter. A control can be technically sound but still fail in practice if the underlying data is stale, if logs are incomplete, or if ownership is unclear. That is common in environments with multiple identity stores, ad hoc automation, or third-party integrations. NHIMG research also shows that 71% of NHIs are not rotated within recommended time frames, which is a strong indicator that a control may exist while its enforcement is inconsistent. When that happens, the next question is not whether the control is documented, but whether it actually changes behaviour when it should.

Related resources from NHI Mgmt Group

• How do organisations know whether detective controls are actually working?
• How do organisations know whether NHI controls are actually working?
• How do organisations know whether mobile asset controls are actually working?
• How do organisations know whether data disclosure controls are actually working?