Who is accountable when exposure drifts between reporting cycles?

Why This Matters for Security Teams

Exposure drift between reporting cycles is where organisations lose visibility, not necessarily where they lose control. If ownership is vague, a finding can sit in a queue long enough to become accepted risk, duplicated effort, or an untracked exception. That matters for cloud assets, privileged accounts, non-human identities, and agent-driven workflows because each can change faster than quarterly governance cycles.

The practical issue is accountability, not just detection. NIST SP 800-53 Rev. 5 emphasises that monitoring, access control, and incident response should work as a connected control set, not as separate reporting functions. When teams only measure exposure at review time, they miss the period in which drift accumulates through new integrations, stale tokens, forgotten service accounts, or unapproved permission changes. The same lesson applies to AI-enabled operations, where autonomous actions can widen exposure outside the cadence of manual review, as highlighted in the Anthropic — first AI-orchestrated cyber espionage campaign report.

In practice, many security teams encounter accountability gaps only after a drifted entitlement, orphaned secret, or exposed system has already been exploited, rather than through intentional review ownership.

How It Works in Practice

Clear accountability usually sits with three parties: the asset owner, the identity or access owner, and the operational responder who validates and closes the issue. That model is strongest when reporting is treated as a control checkpoint, not as the control itself. The owner of the system should be accountable for the exposure source, the identity owner should be accountable for privilege and trust changes, and the response function should be accountable for escalation and containment.

In environments with NHIs or service accounts, the question often becomes who owns the identity lifecycle, because the exposed object may outlive the application that created it. The OWASP Non-Human Identity Top 10 is useful here because it frames common failure modes such as overprivilege, secret leakage, and weak lifecycle governance. That is especially relevant when exposure drifts between cycles and no one is actively reconciling inventory against effective access.

• Assign a named business owner for each asset and each identity trust relationship.
• Track exposure state continuously, then reconcile it against the reporting baseline at each cycle.
• Escalate ownership changes immediately when assets are transferred, retired, or repurposed.
• Use response workflows that require closure evidence, not just ticket assignment.
• Distinguish temporary exceptions from accepted risk, and set expiry dates for both.

For control design, NIST guidance is still the clearest operational anchor. The NIST SP 800-53 Rev 5 Security and Privacy Controls supports this by tying ongoing assessment, access enforcement, and response actions to accountable control ownership. These controls tend to break down when responsibility is split across teams that do not share a single source of truth for assets, identities, and remediation status.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, requiring organisations to balance rapid remediation against the cost of maintaining accurate ownership metadata. That tradeoff becomes visible in hybrid estates, M&A environments, and managed service arrangements, where the “owner” may be a business unit, a platform team, or an external operator.

There is no universal standard for this yet when exposure crosses multiple domains. For example, a drifted cloud permission may be owned by the platform team, but the affected workload may be controlled by an application team and monitored by a SOC. In those cases, current guidance suggests using a RACI-style model with one primary accountable party and explicit supporting roles, rather than shared accountability that dilutes response.

Agentic AI adds another edge case: if an autonomous system can create or alter access paths, then accountability must extend to the people who approved its tool access, execution scope, and review process. In emerging practice, that responsibility may sit between AI governance, identity governance, and security operations, and there is no universal standard for this yet. Where regulated data or critical services are involved, the ownership model should also define who can pause automation, revoke credentials, and trigger containment without waiting for the next reporting cycle.

For teams building policy around faster-changing identity surfaces, the safest assumption is that accountability follows control over change, not control over visibility alone.

Related resources from NHI Mgmt Group

• Who is accountable when a product fails CRA conformity or reporting expectations?
• What is the difference between attack surface management and NHI governance?
• What is the difference between reviewing human access and reviewing NHIs?
• When does secret exposure become a broader identity risk?