What are the best practices for keeping segregation of duties effective as organisations grow?

Why Segregation of Duties Gets Harder as Organisations Grow

segregation of duties stays effective only when it is treated as a living control, not a one-time policy. As organisations expand, responsibilities split across more teams, more systems, and more exceptions, which increases the chance that one person, role, or automation path can initiate and approve the same high-risk action. That is why SoD usually fails first at the edges: acquisitions, new business units, fast-moving projects, and access exceptions.

The practical risk is not just fraud prevention in the narrow sense. Weak SoD can also hide errors, make investigations slower, and leave audit evidence too inconsistent to prove who approved what. Current guidance suggests the control must scale with process complexity, not only with headcount. In practice, many organisations discover SoD drift only after workflow shortcuts, emergency access, or system integration changes have already created overlapping authority.

For teams looking to anchor SoD in a broader control environment, the NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful control baseline, while the Ultimate Guide to NHIs is especially relevant where machine access, service accounts, and automation begin to absorb duties once reserved for people.

How Segregation of Duties Works in Practice

Effective SoD starts by defining which combinations of request, approval, execution, and review must never sit with the same person or role. That sounds simple, but at scale the real work is translating those rules into identity governance, workflow design, and system-enforced checks. The strongest programmes map duties to business processes first, then apply access constraints, approval routing, and periodic certification so that the control survives reorganisation and tooling changes.

Automation matters because manual SoD reviews do not scale well, especially when organisations add subsidiaries, cloud platforms, or delegated administration. But automation only helps if the rule set is precise. If the rules are too broad, teams create false positives and route around the control. If they are too loose, they create a paper control that looks complete but does not actually stop conflicting access. Best practice is to review role design and transaction paths together, because a clean role model can still fail when a workflow engine, API token, or privileged support process bypasses the intended approval chain.

In environments with strong identity governance, SoD is usually enforced through a combination of role design, approval workflow, exception handling, and monitoring. Where non-human identities are part of the process, the same logic must apply to service accounts and automation credentials. NHIs often concentrate privilege and are harder to review than human users, which is why good SoD programmes track both who can act and what systems can act on behalf of the business. That is also where a control reference such as NIST SP 800-53 becomes useful, because it ties SoD thinking to account management, access enforcement, and auditability rather than leaving it as a policy statement alone.

These controls tend to break down when organisations treat exceptions as temporary but never recertify them, because exception sprawl silently turns a segregated process into a shared-access process.

Where SoD Usually Erodes and What to Watch For

Tighter SoD often increases approval friction, so organisations have to balance control strength against operational speed. That tradeoff becomes visible when teams start asking for emergency access, shared admin roles, or “temporary” overrides to keep delivery moving. Those shortcuts are not automatically wrong, but they should be rare, logged, time-bound, and subject to retrospective review. Guidance is evolving here: there is no universal standard for how many exceptions are acceptable, but there is broad agreement that exception volume and duration are leading indicators of control decay.

The most common failure points are expansion, not obvious misconduct. Mergers introduce duplicate entitlements. New cloud services create separate permission models. Outsourcing and third-party operations shift duties outside the original control boundary. At the same time, automation can hide whether a system is performing separation correctly unless teams retain evidence of rule enforcement, approval traces, and periodic recertification outcomes.

Two practical signs deserve attention. First, if the same role can create, approve, and release a change or payment, SoD is already functionally weak even if the policy says otherwise. Second, if automation credentials are exempt from review, the organisation may have preserved human SoD on paper while losing it in machine-operated workflows. That is why growth-stage SoD programmes should measure exception age, role overlap, and review completion, not just policy coverage.

Risk and Threat Considerations

SoD failures create both fraud risk and control-bypass risk. As organisations grow, the main exposure is that overlapping authority becomes normalised through exceptions, delegated admin rights, and automation paths that are not subject to the same review as human access. That increases the chance that an error, abuse case, or compromised account can move from request to approval to execution without an effective second check.

Failure mechanism: the control weakens when process ownership, approval authority, and execution rights converge inside one role or one workflow path. Attackers and insiders do not need to defeat the policy directly if they can exploit standing privilege, shared service credentials, or an exception process that was never revoked or recertified.

Impact: the organisation loses independent oversight over sensitive actions, which can lead to unauthorised transactions, concealed changes, poor auditability, and delayed incident detection. In larger environments, that can also undermine trust in the entire control framework because reviewers can no longer rely on the approval trail.

Practitioner Guidance

What to prioritise: Focus first on the few processes where SoD failure would create the highest loss, such as payments, production changes, privileged access, and entitlement administration. Those are the workflows where role overlap and weak exception handling become material fastest.

What to verify: Confirm that every exception has an owner, an expiry date, and a review record. If an exception cannot be proved current, treat it as a control gap rather than a paperwork issue.

What practitioners underestimate: Non-human identities often become the easiest way to bypass SoD intent because they are created for speed and then left outside normal review cycles. As the environment scales, that blind spot can matter more than human role overlap.

Practitioner takeaway: The best SoD programmes do not try to prevent every overlap everywhere; they preserve independent approval only where the business impact of combined authority is actually unacceptable.

Related resources from NHI Mgmt Group

• What breaks when organisations allow broad internal access to sensitive information without segregation of duties?
• How should organisations implement segregation of duties without slowing down core business workflows?
• How should security teams make NHI best practices usable across the business?
• How should financial institutions implement segregation of duties across critical financial processes?