Yes, when the main risk is that live application behaviour no longer matches what access records imply. Another review cycle may certify intent again, but execution observability is what reveals whether non-human identities, agents, or users are actually operating within policy.
When execution observability should outrank another access review
access review answer whether a permission should exist. Execution observability answers whether the permission is being used the way policy intended, which is often the faster signal when live behaviour, delegated access, or automation has drifted away from the reviewed record. That is why observability is the sharper control when the question is not “who was approved?” but “what is actually happening now?”
For identity-heavy environments, the practical issue is not just entitlement count, it is entitlement behaviour. A clean review can still miss a secret being reused, a service account acting outside its expected workload, or an agent invoking tools in ways the approver never saw. The relevant control question becomes whether the organisation can see execution, correlate it to the actor, and decide quickly whether the activity is expected.
That distinction is reflected in the broader identity governance stack, where lifecycle, access review, and visibility are complementary rather than interchangeable. IAM and IGA Basics is useful here because it separates approval logic from governance outcomes, while Identity Visibility and Intelligence Platforms (IVIP) Guide explains why effective access and observed activity need to be viewed together.
What execution observability adds that reviews cannot
Execution observability gives you runtime evidence: command paths, API calls, session context, privilege use, agent actions, and unusual timing or destination patterns. That matters because access reviews are retrospective certifications, while observability is a control over current behaviour. If the objective is to detect policy drift, shadow use, overbroad automation, or a compromised account that still looks approved on paper, runtime evidence is the more direct control.
It also changes how you handle non-human and delegated access. A periodic review may still say a service account, token, or agent is “owned,” but ownership does not tell you whether it is being used only for the intended application or has become a reusable path to production systems. When behaviour matters, Privileged Access Management Guide is relevant because session-level controls and just-in-time access only work when you can see what happened during the session, not just who was granted entry.
Execution observability is also better at exposing stale approvals that remain technically valid but no longer reflect the true operating model. If the organisation has strong change velocity, large numbers of service identities, or agent-driven workflows, the gap between certified access and actual use grows quickly. In that setting, Access Reviews and Certification Guide is best treated as a governance backstop, not the primary answer to live control drift.
How to decide which control should come first
The right order depends on the failure mode you are trying to prevent. If the main concern is entitlement cleanup, role hygiene, or audit attestations, another review cycle may still be the right first move. If the main concern is that production behaviour is already out of sync with the approved state, observability should come first because it can reveal real exposure before the next review window.
What to prioritise: Prioritise execution observability when you have high-change environments, shared credentials, service identities, or agents whose runtime actions can materially affect systems. Prioritise another review cycle when your biggest gap is governance completeness, missing reviewers, or stale ownership data rather than uncertain behaviour.
What to verify: Verify that observed activity can be tied to a specific identity, workload, or delegated actor, and that you can distinguish normal automated execution from unexpected human use, lateral use, or cross-environment access. If you cannot make that distinction, an additional review alone will not close the control gap.
What good looks like: Good practice is a closed loop where reviews establish the intended state and observability confirms the operating state, with exceptions routed into remediation rather than the next routine campaign. Top 10 NHI Issues is a helpful reminder that visibility gaps, overprivilege, and unmanaged credentials are often discovered at runtime, not during the annual certification window.
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 governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Runtime execution observability depends on reviewing and acting on audit evidence. |
| AC-6 — Least Privilege | The topic is about judging whether observed execution exceeds intended access. | |
| IA-5 — Authenticator Management | Observed use often exposes stale, reused, or poorly governed credentials. | |
| Recommendation — Review audit records for suspicious execution and escalate deviations from policy. Limit permissions to what the observed workload or user actually needs. Manage credential lifecycle tightly and revoke unused authenticators quickly. | ||
| NIST CSF 2.0 | DE.CM-01 — Continuous Monitoring | Execution observability is a continuous monitoring concern for active behaviour. |
| PR.AA-05 — Manage Access Permissions | The comparison is between certified access and actual use of permissions. | |
| GV.OV-01 — Oversight of Risk Management Strategy | The decision is a governance choice between attestation and runtime evidence. | |
| Recommendation — Monitor executed activity continuously and alert on policy drift. Align granted access with current business need and remove excess privilege. Set oversight rules that require runtime evidence where entitlement drift is material. | ||
Practitioner Guidance
Decision rule: If the question is whether access should exist, use review. If the question is whether access is being exercised in a way that still matches policy, use observability first and treat the next review as supporting evidence rather than the main control.
Common mistake: Teams often mistake completed recertification for control effectiveness. A reviewed entitlement can still be abused, shared, or repurposed, so the operational test is whether the organisation can detect and explain actual execution before the next governance cycle.
What to measure: Track how many high-risk identities, sessions, or agent actions are visible with sufficient context to judge policy compliance, and how quickly suspicious execution is investigated or contained. The useful metric is not review completion alone, but time from anomalous execution to confirmed disposition.
Practitioner takeaway: Use access review to validate the decision to grant access, but use execution observability to validate the decision to trust it in production, because live behaviour is what determines current risk.
Related resources from NHI Mgmt Group
- Should organisations prioritise patching exposed SAP kernel defects over routine access review cycles?
- When should organisations prioritise deeper review of one vendor relationship over another?
- When should organisations prioritise a cybersecurity audit over waiting for the annual review cycle?
- When should organisations prioritise preventive access checks over more review cycles?