They should validate controls with live technical evidence, not just documents or questionnaires. The key test is whether identity settings, cloud permissions, and remediation status still match the approved posture when measured in production. If the environment can drift between audits, the programme must measure drift continuously and treat mismatches as control failures.
Why Posture Proof Has to Be Live, Not Documentary
Compliance controls only stay meaningful if they still work after the point-in-time assessment. The practical test is whether the system in production still matches the approved posture for identity, access, configuration, and remediation. Evidence has to come from the running environment, because drift can appear the day after the review closes.
That means teams should treat screenshots, policy exports, and questionnaire answers as supporting material, not proof by themselves. The stronger question is whether the control remains effective under current conditions, with real permissions, real accounts, and real operational change.
Where a programme depends on cloud or identity controls, the gap between design and operation is often the failure point. A control that was correct during assessment can become stale through role sprawl, permission creep, missed deprovisioning, or untracked configuration change.
What Counts as Proof That a Control Still Works
Proof should show that the control is both present and effective in production. For access controls, that means verifying actual entitlements and privileged paths, not just approved role design. For configuration controls, it means checking the live state of the account, workload, or cloud service against the intended baseline.
This is where technical validation matters more than process statements. If a remediation ticket says access was removed, the control is only proven when the permission is no longer active in the target system. If a policy says least privilege is enforced, the evidence should show that excessive access is not still reachable through another role, inherited group, or stale token.
A useful way to think about the evidence is: can the team demonstrate the current state, the expected state, and the delta between them? If the delta exists, even briefly, the control is not continuously effective.
- Validate live access paths, not only documented role models.
- Check that remediation has actually propagated into production systems.
- Compare current state against the approved baseline, then record any drift as a control exception.
How to Prove the Programme Can Detect Drift Continuously
The best programmes do not wait for the next audit cycle to discover that something changed. They instrument controls so that drift is visible as soon as it appears, whether through scheduled checks, continuous monitoring, or event-driven validation.
That matters because compliance risk is often temporal. A short-lived privilege escalation, stale service credential, or mis-scoped cloud permission can create exposure long before the next review. Continuous drift measurement turns that hidden window into an observable control failure.
For cloud and identity-heavy environments, teams should compare the live system state to the approved posture on a recurring basis and retain evidence that the control alerted, not only that the issue was eventually fixed. In practice, the most credible programme can answer three questions: what changed, when it changed, and how quickly it was detected.
Risk and Threat Considerations
When compliance controls are checked only at assessment time, organisations can mistake paper compliance for operational control. That creates a window for access creep, misconfiguration, and delayed remediation to persist undetected, especially where cloud permissions and identity settings change often.
Failure mechanism: The control drifts after the review, but the programme lacks continuous measurement, so the exception is not discovered until the next audit or incident.
Impact: Excess privilege, stale access, or incorrect remediation can remain active long enough to create unauthorised access, policy breach, or a failed audit assertion about control effectiveness.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Continuous Monitoring | Live control validation depends on ongoing monitoring of production state. |
| Recommendation — Instrument continuous checks to detect posture drift as soon as it appears. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Evidence of control effectiveness requires reviewing and analyzing live audit data. |
| CM-3 — Configuration Change Control | Post-assessment drift is often caused by unmanaged configuration changes. | |
| AC-2 — Account Management | Identity state can drift through stale, unremoved, or mis-scoped accounts. | |
| Recommendation — Review production audit signals to confirm controls still operate as intended. Require controlled change processes and verify changes against the approved baseline. Validate account lifecycle state in production and revoke stale access promptly. | ||
| ISO/IEC 27001:2022 | A.8.16 — Monitoring activities | Monitoring is needed to show controls continue working after assessment. |
| Recommendation — Monitor live control state and alert on deviations from the approved posture. | ||
Practitioner Guidance
What to verify: Verify the live production state, not just the control design. For any control that depends on permissions or configuration, confirm the current effective state in the target system and keep the evidence tied to a timestamped check.
What to measure: Measure drift as a control health signal, not a housekeeping metric. The most useful indicators are the number of mismatches, how long they persist, and whether remediation closes the gap or merely documents it.
Common mistake: Treating an attestation, spreadsheet, or remediation ticket as proof that the control still works. Those artefacts show intent; they do not prove the production control remained effective after change.
Practitioner takeaway: If a control can drift, then the real control is the mechanism that detects and proves the drift, not the policy that promised it would not happen.
Related resources from NHI Mgmt Group
- How should security teams govern non-human identities for compliance?
- How should security teams govern non-human identities for SOC 2 compliance?
- How should security teams prove that GRC controls are actually working?
- How should security teams use audit tooling to prove identity controls are working?