TL;DR: Segregation of duties examples across accounting, payroll, IT, healthcare, and ERP systems show that fraud and error usually appear when one person can both create and approve the same action, according to SecurEnds. The practical lesson is that clear role splits and continuous conflict checks matter more than policy language alone.
NHIMG editorial — based on content published by SecurEnds: segregation of duties examples across accounting, IT, and industry
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
Questions worth separating out
Q: How should teams implement segregation of duties in finance and ERP systems?
A: Start by mapping the full transaction path, then split creation, approval, posting, and reconciliation across different roles.
Q: What breaks when one person can create and approve the same transaction?
A: The control breaks because the same identity can introduce errors, hide fraud, and clear its own work.
Q: How do you know if segregation of duties is actually working?
A: It is working when entitlement reviews show no single role can complete a critical process end to end, and when exceptions are rare, documented, and time-bound.
Practitioner guidance
- Build a real entitlements-based SoD matrix List the actual permissions behind each role in finance, HR, and IT, then flag any identity that can both create and approve the same business event.
- Separate access administration from oversight Ensure the identity that provisions users, vendors, or payroll records cannot also reconcile logs, approve payments, or certify its own work.
- Automate conflict detection across core systems Use continuous checks to detect risky overlaps in ERP, IAM, and admin workflows so conflicts are surfaced when entitlements change, not only at audit time.
What's in the full article
SecurEnds' full guide covers the operational detail this post intentionally leaves for the source:
- Concrete examples of SoD controls across accounting, IT, healthcare, banking, and manufacturing workflows
- A simple segregation of duties matrix that maps who enters, approves, and audits each process step
- Automated conflict detection and audit-ready reporting details for teams moving beyond spreadsheet checks
- Practical examples of how to handle SoD violations in smaller teams where complete role separation is difficult
👉 Read SecurEnds' guide to segregation of duties examples across finance, IT, and HR →
Segregation of duties examples: where do control gaps appear first?
Explore further
Segregation of duties is a governance model, not just a compliance checkbox. The article shows the classic pattern clearly: one person creates, another approves, and a third reconciles. That same split is the structural logic behind NHI governance as well, because service accounts and API keys become risky when creation, use, and review collapse into one control owner. Practitioners should treat SoD as a lifecycle design pattern, not a reporting exercise.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
A question worth separating out:
Q: Who is accountable when segregation of duties fails in an audit?
A: Accountability usually sits with the process owner, the control owner, and the managers who approved the conflicting access. Auditors expect named ownership, evidence of review, and a documented remediation path. If no one owns the split between creation and approval, the organisation does not really have segregation of duties, only a policy statement.
👉 Read our full editorial: Segregation of duties examples show where control gaps start