How should teams respond when compliance, engineering and security all own parts of access governance?

Why Shared Ownership Needs a Single Access Model

When compliance, engineering, and security each own a slice of access governance, the first failure is usually inconsistency. Teams approve different things, use different evidence, and apply different timelines for the same account or entitlement. A shared operating model creates one policy baseline, one evidence model, and one revocation path so the decision is consistent even when the execution is distributed.

That does not mean centralizing every task. It means separating specialist work from final policy, so engineers can implement controls, security can set risk thresholds, and compliance can verify proof without turning access decisions into three competing interpretations.

• One baseline keeps role design, approvals, and exceptions from drifting across business units.
• One evidence model avoids duplicate screenshots, duplicate exports, and contradictory audit trails.
• One revocation process prevents delays when access must be removed quickly across systems.

A useful test is whether the same access request would receive the same answer if it moved from one team to another. If the answer changes, governance is fragmented rather than shared.

Where Fragmentation Shows Up in Practice

Fragmented ownership usually produces the same patterns: one team treats access as an audit artefact, another treats it as a deployment concern, and another treats it as a control exception. The result is often stale approvals, role sprawl, slow removals, and access that remains in production because nobody owns the full path from request to revocation.

This is also where access reviews become unreliable. A review can look complete while missing context about inherited roles, dormant entitlements, temporary access, or the business trigger that should have ended access already. IAM and IGA basics are useful here because they separate policy, request, certification, and lifecycle responsibilities into a model that teams can share without confusing ownership.

For teams that need to clean up existing messes, lifecycle discipline matters more than process theatre. The most reliable way to reduce drift is to tie provisioning and revocation to the same lifecycle record, not to a series of disconnected tickets. Joiner-Mover-Leaver guidance is especially relevant when access changes follow people, roles, contractors, or automated actors through multiple systems.

Shared governance also breaks down when roles are designed locally and then reused globally. That creates entitlement overlap, SoD conflicts, and exceptions that no one can explain cleanly during review. Role mining and role design helps teams make role structure an explicit governance object instead of an accidental by-product of application administration.

How to Run the Shared Operating Model Without Blurring Accountability

The practical goal is not a committee that approves everything. It is a model with clear decision rights: one team owns the policy, one owns the evidence standard, and one owns technical enforcement. When that structure exists, specialist teams can still do the work, but they work to one set of rules and one revocation trigger.

Teams should also define what counts as acceptable proof before the review cycle starts. If compliance wants evidence of control operation, engineering should know which system records satisfy it, and security should know which exceptions require escalation. Access reviews and certification are most effective when they are closed-loop, because review without removal simply documents the problem.

For broader governance, IGA buyer guidance is useful not as a product checklist, but as a reminder that lifecycle, approvals, roles, and connectors have to support one operating model rather than three separate ones. The control works only when the system can prove who decided, who enforced, and who confirmed removal.

If access includes privileged paths or shared responsibilities, segregation rules should be part of the same policy baseline rather than a separate control island. Segregation of duties is the right lens when the risk is not just excess access, but conflicting access that no single team can safely own on its own.

Risk and Threat Considerations

Fragmented access governance creates a control gap that attackers and internal users alike can exploit. When approvals, revocation, and evidence live in different teams, stale access tends to persist, exceptions become harder to trace, and revocation slows down exactly when the organisation needs speed.

Failure mechanism: Each function optimizes for its own objective, so the organisation ends up with inconsistent policy, incomplete evidence, and delayed removal of access. That increases the chance that over-privileged or expired access remains active in production.

Impact: The business inherits higher exposure to unauthorized access, audit failure, and privilege abuse, while incident response becomes slower because no single team can prove the full access history or revoke it cleanly.

Practitioner Guidance

What to prioritise: Define one policy owner, one evidence owner, and one revocation owner before you try to standardize tools. The operating model comes first, otherwise the platform just automates disagreement.

What to verify: Check that every access path has a single authoritative revocation trigger and that the evidence trail proves both approval and removal. If either is missing, treat the process as incomplete even if reviews are being completed on schedule.

Decision rule: If a team cannot explain who can revoke access in production within minutes, the governance model is too fragmented to trust for high-risk entitlements.

Practitioner takeaway: Shared access governance succeeds when teams share the rules and the proof, but not the responsibility boundaries that keep control decisions accountable.

Related resources from NHI Mgmt Group

• Who should own governance for model access when both security and engineering teams depend on it?
• How should security teams govern non-human identities for compliance?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?