Notifications
Clear all
Topic starter
08/06/2026 4:14 pm
TL;DR: A segregation of duties matrix maps roles to critical tasks so organisations can spot conflicting access before fraud, mistakes, or audit findings emerge, according to SecurEnds. The control only works when it stays current and is backed by compensating reviews, because static policy language does not reveal real-world overlap.
NHIMG editorial — based on content published by SecurEnds: a guide to segregation of duties matrices and internal control mapping
Questions worth separating out
Q: How should security teams build a segregation of duties matrix that reflects real access?
A: Start with live identity data, not a policy document.
Q: Why do segregation of duties conflicts still happen in mature IAM programmes?
A: They persist because operational convenience often overrides control design.
Q: What breaks when service accounts are excluded from SoD reviews?
A: You miss the non-human identities that often execute the most sensitive workflows.
Practitioner guidance
- Map sensitive processes to live entitlements Rebuild the matrix from current identity data, then compare it to the business process map for payments, vendor setup, payroll, code release, and privileged admin actions.
- Separate initiation, approval, and release paths Require different identities for each stage wherever the process can move money, change records, or deploy production changes.
- Include service accounts in every SoD review Do not limit the matrix to employee roles.
What's in the full article
SecurEnds' full article covers the operational detail this post intentionally leaves for the source:
- Spreadsheet and ERP-based matrix examples for finance, HR, and IT workflows
- Template-style breakdown of common conflict pairings such as vendor setup and payment release
- Implementation considerations for identity governance platforms that automate conflict detection
- Practical maintenance guidance for keeping the matrix current as roles and systems change
👉 Read SecurEnds' guide to building and maintaining a segregation of duties matrix →
Segregation of duties matrices: where do access conflicts still hide?
Explore further
08/06/2026 5:46 pm
SoD matrices are control evidence, not documentation exercises. A matrix only has value when it reflects actual entitlements, not policy intent. If the rows and columns do not match live access, the organisation is proving a story rather than controlling a risk. Practitioners should treat the matrix as an access assurance object that must be reconciled to the identity store and business process owners.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which shows how quickly governance gaps become persistent exposure.
A question worth separating out:
Q: Who should own SoD exceptions when full separation is not practical?
A: The business process owner should own the exception, with IAM or GRC providing the control record and review discipline. If ownership sits only in security, the exception becomes a report item instead of a managed business risk. Clear ownership is what makes the control defensible.
👉 Read our full editorial: Segregation of duties matrices expose hidden access conflicts
