Framework
Mapping SoD conflicts across REST endpoints
Segregation of duties fails quietly when teams keep thinking in job titles while the system thinks in HTTP verbs. A controller may never “approve payments” in the HR sense, yet the same OAuth client can call POST /payments/approve and PATCH /vendors/bank.
This note outlines the mapping method we teach in the API SoD Control Matrix course: start from endpoints, invent duty labels second, and only then draw conflict edges.
1. Inventory verbs, not screens
Export every route that can create money movement, change standing data, or alter who may do either. Ignore read-only reporting unless those exports feed an automated approval. For each route, record the resource, the verb family (create, approve, reverse, configure, export), and which principals currently hold it.
2. Collapse aliases early
Partner APIs love synonyms: release, confirm, and authorize may all mean approve. Collapse them into one duty label before you draw conflicts, or your matrix will look incomplete when an auditor picks a synonym you forgot.
3. Draw high-risk pairs
At minimum, flag principals that can both (a) change vendor payment instructions and (b) approve outbound payments; both (c) post journals and (d) close periods; both (e) deploy connector config and (f) execute the connector’s posting role. Your industry may add pairs—start with these three and prove them with access extracts.
4. Leave residual risk visible
A conflict you cannot split this quarter still belongs on the matrix with a compensating control and an owner. Hiding it to keep the spreadsheet “green” is how findings reappear in the next external review.
If you want facilitated practice on your own privilege dump, see the flagship course or the SoD framework overview.