How should security teams implement segregation of duties across multiple business applications?

Start by mapping the business actions that must never sit in the same identity across ERP, finance, HR, CRM, and workflow systems. Then translate those actions into conflict rules that are checked whenever access changes, not only during audit season. The goal is to catch toxic combinations before they become operationally usable.

Why This Matters for Security Teams

segregation of duties is often framed as a policy exercise, but in practice it is an identity design problem. When the same account can create a vendor in ERP, approve a payment in finance, and update beneficiary details in HR, the control has already failed even if audit reports look clean. Current guidance suggests that SoD must be enforced at entitlement time, not discovered after a transaction has been completed.

This matters more in multi-application environments because business processes are fragmented across systems that do not share a native conflict model. Security teams need to translate process-level separation into identity-level guardrails that span applications, roles, and automation paths. The NIST Cybersecurity Framework 2.0 is useful here because it treats access governance as an ongoing risk management activity, not a one-time recertification event. NHIMG’s Ultimate Guide to NHIs shows why this is hard in real environments: NHIs often outnumber human identities by 25x to 50x, which means conflict risk scales faster than manual review can keep up.

In practice, many security teams encounter SoD failures only after an exception path, integration account, or emergency access grant has already been used to complete a disallowed business action.

How It Works in Practice

Effective SoD across ERP, finance, HR, CRM, and workflow systems starts with a shared conflict matrix. That matrix should identify the business actions that must remain separate, then map those actions to entitlements, roles, service accounts, and privileged workflows in each application. The key is not to rely on role names alone, because role labels rarely mean the same thing across systems.

Security teams usually get better results when they evaluate conflict rules at three points: provisioning, access change, and privileged elevation. Provisioning checks prevent a toxic combination from being granted in the first place. Change checks catch when an otherwise safe identity accumulates conflicting access over time. Elevation checks matter because temporary admin paths can bypass normal approval workflows if they are not explicitly covered.

• Define conflicts in business terms first, such as create supplier plus approve payment.
• Map each conflict to application entitlements, not just job titles or org charts.
• Check the rule set whenever access is requested, modified, or elevated.
• Use workflow approvals to enforce compensating controls only when true separation is impossible.
• Log the reasoning for each allow or deny decision so audit evidence is produced continuously.

Best practice is evolving toward policy-as-code, where SoD logic is evaluated in near real time rather than during quarterly reviews. That approach aligns with NIST Cybersecurity Framework 2.0 and with the NHI lifecycle discipline described in Ultimate Guide to NHIs. It also reduces dependence on manual spreadsheets, which are usually out of date the moment a business role changes.

These controls tend to break down when organisations keep application-specific roles siloed from central identity governance because conflicts cannot be detected consistently across systems.

Common Variations and Edge Cases

Tighter segregation often increases operational overhead, requiring organisations to balance fraud prevention against workflow friction. That tradeoff becomes visible in high-volume environments such as shared service centres, month-end finance operations, and emergency support desks, where rigid separation can slow legitimate work.

There is no universal standard for how much compensating control is enough, especially when one business unit owns the process while another owns the system. In those cases, current guidance suggests using time-bound approvals, dual control, or independent post-action review, but the design should be risk-based rather than purely procedural.

Edge cases also appear when service accounts and integration identities perform business actions on behalf of users. Those identities can inherit conflicting capabilities indirectly, which means SoD must include non-human identities, not just employee accounts. NHIMG’s research shows why this matters operationally: only 20% of organisations have formal processes for offboarding and revoking API keys, so stale access can preserve a conflict long after a person has changed roles.

Security teams should treat exception management as a controlled risk decision, not a permanent workaround. If a business process truly requires overlapping privileges, the exception should be documented, expiry-bound, and revisited on a scheduled basis.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• How should security teams manage cloud identities across multiple applications?
• How should security teams govern access across SAP and business applications?
• How should security teams implement continuous transaction monitoring across business systems?