Who should own SoD and user access governance when business and IT teams both influence access?

Ownership should be shared, but accountability must be explicit. Business process owners define the tasks and risk boundaries, while IT translates those requirements into system roles and permissions. If either side works alone, access models drift from business reality and SoD controls become too loose or too noisy to trust.

How shared ownership should work between business and IT

SoD and user access governance work best as a shared operating model, not a single-team task. Business owners define what work is legitimate, where duties must be separated, and what risk is acceptable. IT then implements those decisions in roles, entitlements, and technical controls so the model is executable in systems without losing the business intent.

That split matters because access is not just a technical permission set. It is a business decision translated into system enforcement, and the translation step is where drift usually starts if ownership is vague, informal, or left to whichever team happens to be closest to the ticket queue.

Effective governance also depends on a clear decision boundary. Business should own policy intent, exception approval, and risk acceptance for conflicting duties. IT should own the mechanics of role design, provisioning, and control enforcement, while audit or risk functions verify that the resulting access model still reflects the approved separation rules.

Why dual ownership fails when accountability is not explicit

Problems usually appear when both teams assume the other side is responsible for the hard part. Business may describe access in process language but never maintain the entitlement logic. IT may build a clean role structure that satisfies system constraints but no longer matches how work is actually performed. Either failure produces access that is technically assigned but operationally wrong.

That misalignment creates two common outcomes: roles become too broad because they are built for convenience, or SoD rules become too noisy because they are applied without enough context about real work patterns and compensating controls. In both cases, the governance signal becomes less trustworthy, which makes approvals slower and exceptions harder to defend.

Shared ownership works only when accountability is explicit at each step of the lifecycle, from role definition to access review to exception handling. The business cannot delegate the meaning of access, and IT cannot inherit responsibility for deciding what the business should permit. Each side needs a named decision role and a traceable approval path.

What a sustainable governance model needs to preserve

The model should preserve three things at once: business realism, technical enforceability, and reviewability. Business realism means the access model reflects how the organisation actually separates duties. Technical enforceability means the rules can be implemented consistently across applications and platforms. Reviewability means auditors and control owners can see why an entitlement exists and who accepted the associated risk.

That is why access governance should be treated as a living control, not a one-time design exercise. Role catalogues, entitlement mappings, and SoD rules need periodic recalibration when processes change, systems are consolidated, or job functions shift. If those updates do not happen, the access model gradually starts representing the old organisation rather than the current one.

Practical governance also benefits from a narrow set of authoritative sources. When business definitions, role libraries, and approval records live in different places, teams debate whose version is correct instead of managing actual risk. A single operating model with clear ownership reduces that ambiguity and makes reviews easier to evidence.

Risk and Threat Considerations

When SoD and access governance are split informally, the main risk is control dilution. Excessive access, weak exception discipline, and role drift can create conditions where a single user can perform incompatible actions without detection, or where reviewers stop trusting the alerts because too many are false positives.

Failure mechanism: Business-defined duties and IT-enforced permissions diverge over time, so the access model no longer reflects actual process boundaries. That divergence can hide privilege creep, make compensating controls harder to sustain, and leave segregation exceptions unchallenged.

Impact: Organisations can end up with unauthorised combinations of access, slower approvals, more remediation work, and weaker audit evidence. In more mature environments, the issue becomes strategic because the governance process looks active while the underlying control is steadily losing precision.

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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-2 — Account Management	Access governance depends on controlled account and entitlement lifecycle ownership.
	AC-5 — Separation of Duties	The question is fundamentally about who owns SoD decisions and enforcement.
	AC-6 — Least Privilege	Role design must keep permissions bounded to the minimum necessary for work.
Recommendation — Define account ownership and review responsibilities for business and IT roles. Assign SoD responsibility to process owners and enforce it in system design. Restrict entitlements to the minimum access required for each approved role.
ISO/IEC 27001:2022	A.5.15 — Access control	Access control policy needs clear governance ownership across business and IT.
	A.5.18 — Access rights	The topic concerns assignment, review, and revocation of user access rights.
Recommendation — Document access control ownership, approval, and review responsibilities. Review and revoke access rights using accountable ownership and periodic checks.

Practitioner Guidance

What to prioritise: Assign one accountable owner for business SoD rules and one accountable owner for technical implementation, then require a named approver for any exception. The key is not who writes the rule, but who can change it and who signs off when the rule cannot be enforced cleanly.

What to verify: Check that every SoD rule has a traceable business rationale, a mapped system role or entitlement, and a documented review cadence. If a rule cannot be explained in process terms and reproduced in system terms, it is not yet governance, only intent.

Practitioner takeaway: Shared ownership is healthy only when accountability is unambiguous, because SoD breaks first at the translation layer between business meaning and system enforcement.