What is the difference between a potential SoD violation and an actual SoD violation?

A potential SoD violation exists when a user has the permissions to perform both sides of a sensitive transaction, but has not yet done so. An actual SoD violation exists when the user has executed both sides. The first is a control warning. The second is evidence of active policy breach and should trigger immediate remediation and review.

Why the distinction matters in access governance

A potential sod violation is a condition in the access model, not yet a completed control failure. It means the person could complete conflicting steps in a sensitive process, so the issue sits in provisioning, role design, or entitlement review. An actual SoD violation is the point where those conflicting actions have been executed, which changes the problem from risk exposure to confirmed breach.

That distinction matters because the response is different. Potential violations call for preventive control action, such as fixing entitlements, tightening approval paths, or redesigning duties. Actual violations require incident handling, evidence preservation, and review of whether the control failed because of bad design, bad exception handling, or delayed detection.

The difference is also about auditability. A potential violation can be identified from permissions and workflow design alone. An actual violation usually requires transaction evidence, logs, or approval records showing that the conflicting duties were exercised. A useful reference point for control design and audit evidence is NIST SP 800-53 Rev 5 Security and Privacy Controls, especially access control, audit, and configuration management expectations.

How the two conditions show up in practice

In practice, potential SoD violations often surface in role mining, access recertification, joiner-mover-leaver review, or workflow analysis. The user may hold both an initiating role and an approving role, or a requestor and approver combination, even though no improper transaction has occurred yet. That is a warning that the system allows a breach path.

Actual SoD violations are easier to explain but harder to tolerate. They typically appear when logs, approvals, or transaction history show that the same person performed both sides of a sensitive action, or used a conflicting access path to do so. At that point, the control has failed in execution, not just in design.

For teams working with recurring access review cycles, the practical distinction is that potential violations can often be resolved before impact, while actual violations need retrospective validation of scope. If the user exercised both sides through the same account, the breach is direct. If the actions were spread across accounts or systems, investigators still need to determine whether the same underlying authority was used.

When SoD is being evaluated alongside privileged or delegated access, the same logic applies to machine and service identities that can execute sensitive workflows. Ultimate Guide to NHIs, What are Non-Human Identities is useful background where automation, service accounts, or API keys are part of the transaction path.

Risk and Threat Considerations

Potential SoD violations create exposure because they leave a path open for fraud, unauthorized change, or concealed misuse even if nothing has happened yet. Actual SoD violations are more serious because they show the conflicting authority was already exercised, which can indicate policy breach, control failure, or in some cases deliberate abuse.

Failure mechanism: The control fails first at the entitlement layer when one user can reach both sides of a sensitive transaction, then at the detection layer if the organisation only reviews permissions and never checks executed transactions. In higher-volume environments, that gap can persist until audit or reconciliation catches it.

Impact: A potential violation increases the likelihood of future misuse, while an actual violation can require transaction reversal, disciplinary review, fraud analysis, and broader access reassessment. If the action touched financial, approval, or master-data workflows, the scope can extend well beyond the individual account.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC — Access Control	SoD is an access-control issue because conflicting duties arise from what an identity can do.
Recommendation — Review and constrain access paths so no single user can both initiate and approve sensitive transactions.
CIS Controls v8	5 — Account Management	SoD violations usually originate in excessive or conflicting entitlements on user accounts.
Recommendation — Continuously validate account permissions and remove conflicting access before it becomes executable.
NIST SP 800-53 Rev 5	AC-5 — Separation of Duties	This control directly governs conflicting responsibilities that create potential or actual SoD violations.
	AU — Audit and Accountability	Actual SoD violations require evidence from logs, approvals, and transaction records.
Recommendation — Apply AC-5 to prevent one person from holding incompatible duties in the same sensitive process. Retain transaction and approval evidence so executed SoD breaches can be detected and investigated.
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	When automation or service accounts can perform both sides of a workflow, SoD risk extends to non-human access.
Recommendation — Rotate and scope machine credentials so automation cannot execute conflicting transaction steps.

Practitioner Guidance

What to verify: Treat the permission set and the executed transaction as separate evidence. If the issue is only potential, confirm whether the user can reach both sides through one role, a combination of roles, or an exception that has outlived its approval window.

Decision rule: If both sides exist only in access, fix the entitlement model first. If both sides were actually used, escalate as a confirmed control breach and review whether the same weakness exists anywhere else in the process.

What practitioners underestimate: Potential SoD violations are not harmless just because they are unexercised. They often represent the exact conditions needed for the next actual violation, so they should be prioritized based on transaction sensitivity, privilege breadth, and how quickly the access could be abused.

Practitioner takeaway: The operational distinction is simple, but the response is not: potential SoD is a preventable exposure, actual SoD is a confirmed control failure, and the second always deserves immediate containment plus root-cause review.