Who should own the answer to what an account can reach across the enterprise?

Who should own the answer, and why does ownership matter?

The answer should be owned jointly by identity governance and platform teams, because “what an account can reach” is not just a permissions question. It is a combined view of entitlements, shared credentials, service-to-service trust, and the operational dependencies that make access usable in practice. If only one team owns it, the reach picture is usually incomplete or stale.

Identity governance is the natural home for entitlement logic, role scope, and reviewability. Platform teams hold the system knowledge needed to explain where access is technically effective, where inheritance occurs, and where an apparently narrow account can still reach broadly through delegated paths or shared infrastructure.

What counts as enterprise reach in practice?

Enterprise reach is broader than direct login permission. It includes application roles, API scopes, inherited group membership, federated access paths, service credentials, and any shared secret or token that can be reused elsewhere. A defensible answer has to trace the path from the account to the resource, not just list the account’s nominal owner or title.

This is why the question should be answered as a scope-and-path problem, not as a static access review. A reach map should show where the account can act, what it can invoke, and which systems trust it. In cloud and API-heavy environments, that means checking both human-administered entitlements and machine-driven access paths such as service account and automation.

For teams that need a control baseline, CIS Controls v8 is useful because it ties account management, access control, and audit logging together instead of treating them as separate workstreams. For cloud estates, the CSA Cloud Controls Matrix gives a similar governance lens across IAM and operational control domains.

How should organisations make the answer defensible?

A defensible answer depends on evidence, not opinion. Teams should be able to show the source of truth for entitlements, the inherited access relationships, the credentials or tokens involved, and the systems that introduce exception paths. That means documenting who approves access, who can see the full blast radius, and who can execute containment when a reach path is too broad.

The practical test is whether another team can independently reproduce the answer from logs, configuration, and ownership records. If the answer changes depending on whether you ask identity, infrastructure, application, or operations, then no one truly owns the reach question yet. This is also where shared accountability matters: one team may curate entitlement data, but platform owners must validate runtime reach and security operations must be able to act on it quickly.

External control guidance points in the same direction. NIST SP 800-53 Rev 5 Security and Privacy Controls supports this ownership model through access control, identification and authentication, audit, and configuration management controls. Where access reaches into cloud services, NIST Cybersecurity Framework 2.0 reinforces the need for governance, protection, detection, response, and recovery to be connected rather than siloed.

Risk and Threat Considerations

When no single owner can answer what an account can reach, organisations tend to underestimate blast radius and overtrust stale permissions data. That creates exposure not only to misuse of overbroad access, but also to delayed containment when an account is compromised or a shared credential leaks.

Failure mechanism: Entitlements, shared secrets, and platform dependencies drift apart, so the visible access record no longer matches actual runtime reach.

Impact: A compromised or misused account can move farther than expected, and responders may lose time arguing over scope instead of containing the path.

Practitioner Guidance

What to prioritise: Build the answer around the highest-risk accounts first, meaning privileged users, automation, service accounts, and anything with cross-environment reach. Those are the accounts where incomplete ownership creates the biggest gap between policy and actual blast radius.

What to verify: Confirm that the ownership model covers both entitlement review and runtime validation. If identity governance can approve access but platform teams cannot explain inherited or shared reach, the control is not yet trustworthy.

Practitioner takeaway: Treat reach as a living control boundary, not a periodic report, and assign ownership to the teams that can explain both who granted access and how that access actually behaves in production.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• Why is single-provider AI agent governance not enough for enterprise security?
• When does a service account become a compliance problem?
• Who should own stale-account remediation in an enterprise?