At a glance
A message saying “SoD violation” does not help a requester understand what to change. A useful policy explains which responsibilities conflict, why the combination matters and how an authorised exception is handled.
- Describe the business conflict in plain language.
- Evaluate the person’s combined effective access.
- Keep exceptions specific, owned and time-limited.
Name the conflicting capabilities
In a fictional distributor, the same person may be able to change supplier bank details and release payments. The concern is the combination of actions, not the fact that the person works in finance. The process owner must establish whether the relevant scope and other controls make the combination unacceptable.
Map the business capabilities to the actual application permissions. Check restrictions such as organisational unit or transaction scope. A rule based only on broad job titles may block legitimate work while missing a more precise conflict.
NIST SP 800-53 AC-5 addresses separation of duties. It provides a basis for considering incompatible responsibilities, while the organisation must identify the relevant duties and access authorisations. NIST SP 800-53 Rev. 5: Access Control family.
Explain the decision at request time
Tell the requester which existing capability conflicts with the proposed one. Offer an appropriate route, such as requesting a narrower permission or asking the owner to review an obsolete assignment. Avoid exposing unrelated sensitive details in the explanation.
IGAX’s website describes request-time policy validation and conflict-resolution capabilities. The policy team still needs to supply understandable rule definitions and an approved operating process. A clear explanation makes the control easier to follow and reduces avoidable support conversations.
Consider effective access, not one request alone
A conflict can arise through two roles, a role plus a direct entitlement or memberships inherited through a group. Review those paths when validating the policy. If the integration cannot see part of the application’s access model, record that coverage limit.
| Case | Owner decision |
|---|---|
| Old permission no longer needed | Remove it and verify the resulting state. |
| Requested permission is too broad | Select a narrower permission if available. |
| Temporary cover is necessary | Assess an explicit exception and compensating review. |
| Rule does not reflect the process | Review the rule rather than bypass it informally. |
Keep an exception from becoming the baseline
An exception should identify the affected person, permissions, business reason, duration and accountable approver. Describe any independent check in terms of the work performed and evidence retained. “Manager approved” alone does not explain how the remaining exposure is handled.
At the end of the exception, confirm the required access change. If the need continues, reconsider it rather than renewing it silently. Review recurring exceptions to determine whether staffing, role design or the control itself needs attention.
References
Primary guidance used for the specific points cited above. The examples, templates and recommended working practices are AIdentX editorial guidance.
Sources reviewed September 2026.
Published by AIdentX Editorial. Illustrative scenarios are fictional and do not represent customer results.