Everything you need to define, implement, and maintain an SoD policy, including the procedure steps and review cadence that keep it enforceable.
Plenty of organizations have an SoD policy sitting in a shared drive. Far fewer have a procedure that turns it into something enforced day to day, or a maintenance rhythm that keeps it accurate as roles change.
This guide covers all three: what belongs in the policy, how to build the procedure behind it, and how to keep the whole thing current instead of letting it go stale six months after the audit that prompted it. For the underlying SoD concept this policy is built to enforce, see our Segregation of Duties guide.
Policy vs. procedure: what each one actually covers
A policy is the documented rule: what conflicts are prohibited, who owns SoD overall, how exceptions get approved, and how often the program gets reviewed. It's the authority document, the thing you point to when someone asks why a particular access request got denied.
A procedure is the operational how: the specific, repeatable steps for identifying a violation, assessing it, deciding on remediation, documenting the decision, and confirming the fix held. Where the policy says "conflicting access must be remediated within 30 days," the procedure says exactly who gets notified, what form the remediation takes, and who signs off that it's actually resolved.
A policy without a procedure tends to sit unused, because nobody actually knows the steps to follow when a violation surfaces. A procedure without a policy has no authority behind it: when someone pushes back on a required access change, there's no documented rule to point to that justifies the decision. Effective SoD programs need both, written to reference each other directly.
Writing the policy
Define scope first. Name the specific processes covered: financial transactions, IT administrative access, procurement, HR and payroll, whichever apply. A policy that claims to cover "all systems" without specifics tends to be enforced nowhere in particular. IT scope deserves particular care, since the conflicts look structurally different from finance ones; see our IT Segregation of Duties guide for the specific role pairings worth naming explicitly.
State the core rule plainly. "No individual may hold entitlements that allow them to both initiate and approve the same transaction or process" is a clear, testable statement. Vague language like "appropriate separation should be maintained" gives auditors and employees nothing concrete to check against.
Assign ownership. Someone needs to be named as accountable for the SoD program overall, typically a controller, CISO, or compliance lead depending on the organization, along with owners for specific process areas (finance, IT, HR). Without named ownership, policy maintenance becomes everyone's job and therefore nobody's.
Define the exception process. Legitimate business exceptions happen, especially on smaller teams that can't fully separate every duty. The policy should state who can approve an exception, what documentation is required (a specific reason, not a generic justification), and critically, a maximum duration after which the exception expires and gets re-evaluated rather than becoming permanent by default.
Set the review cadence. State explicitly how often the policy itself, not just individual violations, gets reviewed. Quarterly is common for high-risk processes; annually is typically the floor for lower-risk ones.
For the underlying conflict logic a policy like this actually tests against, see our Segregation of Duties matrix template, and for the full range of what conflicts look like across different departments, see Segregation of Duties policy examples.
Building the procedure: from detection to resolution
A working SoD procedure generally moves through six steps, regardless of whether detection happens manually or through automated tooling.
1. Identify the conflict. A violation surfaces, either through a scheduled access review, an automated detection tool flagging a match, or an ad hoc discovery during an audit or investigation.
2. Assess the risk. Not every conflict carries equal weight. Reference the risk rating already assigned in your conflict matrix (High, Medium, Low) to determine urgency. A High-risk finance conflict warrants same-week attention; a Low-risk conflict with an existing compensating control may not.
3. Determine the remediation path. Two options generally exist: revoke one side of the conflicting access entirely, or apply a documented compensating control if full separation isn't immediately possible. The procedure should specify who makes this call, typically the process owner named in the policy, not the person who discovered the violation.
4. Execute the remediation. Whoever is responsible for the affected system removes the access, adjusts the role, or implements the agreed compensating control. Where possible, this step should have a defined turnaround time (30 days is a common benchmark for lower-risk findings, immediate for high-risk ones).
5. Document the decision. Record what was found, what was decided, who approved it, and when it was executed. This is the evidence an auditor will ask for later, and its absence is often a bigger audit problem than the original conflict.
6. Verify and re-check. Confirm the remediation actually took effect, ideally at the next scheduled review or detection run, rather than assuming a change request that was submitted was also completed correctly.
Setting up the technical conditions behind the policy
Turning policy language into something a system can actually enforce requires translating each conflict rule into specific access conditions. In practice, this means defining the exact entitlements, roles, permissions, or group memberships, that make up each side of a conflict, and configuring what should happen automatically when both sides are detected on the same identity.
This is also where resolution instructions matter. A well-built procedure specifies, in advance, which side of a conflict gets revoked by default when a violation is found, rather than leaving that decision to be worked out fresh every time. For genuinely high-stakes conflicts, routing the decision to a human reviewer instead of a default automatic resolution is usually the safer configuration, since context sometimes changes which side should be removed.
Maintaining the policy over time
Most SoD programs don't fail at the writing stage. They fail because nobody keeps the policy current once the initial rollout is done. A handful of practices keep it alive.
Review the conflict matrix on a fixed schedule, not just reactively. Waiting for an audit finding to prompt a review means the matrix has already been stale for however long it takes to trigger one, and stale matrices are exactly how the accumulated risk described in our Segregation of Duties risks guide actually forms. Quarterly reviews for high-risk areas catch drift before it compounds.
Assign real ownership, not shared responsibility. A policy owned by "the finance and IT teams together" tends to have nobody actually driving updates. Name one accountable person per process area.
Build remediation into a defined cadence, not an ad hoc queue. Violations that sit unresolved for months because nobody prioritized them defeat the purpose of detecting them in the first place. A defined SLA (same-week for High risk, 30 days for Medium, next quarterly review for Low) keeps the backlog from growing indefinitely.
Use the data the program generates. Recurring violations in the same role or department usually indicate a structural problem, a job description that inherently creates conflicting access, rather than a series of unrelated incidents. Reviewing violation patterns periodically surfaces this in a way that looking at individual cases doesn't.
Train the people who actually request and approve access. Most violations don't originate from malicious intent. They originate from a manager approving an access request without realizing it creates a conflict with something the employee already holds. Basic training for anyone with approval authority reduces this meaningfully.
Re-evaluate the policy whenever the underlying business changes. A new application, a reorganization, a new compliance framework the company now needs to meet, all of these should trigger an off-cycle policy review rather than waiting for the next scheduled one.
A worked example: policy to procedure in practice
It helps to see the full arc in one example. Say the policy states: "No individual may both create a purchase requisition and approve the resulting purchase order." The matrix identifies this as a High-risk conflict.
A quarterly access review, or an automated scan if one exists, finds that a procurement coordinator, recently expanded into a broader role during a team restructuring, now holds both permissions. Following the procedure, the finding gets logged with a risk rating of High, which per the defined SLA requires resolution within the same week.
The process owner, in this case the procurement lead named in the policy, reviews two options: fully revoke the approval right, or apply a documented compensating control if the coordinator's expanded role genuinely requires both for a transitional period.
In this case, the decision is to revoke the approval right and route purchase order approval to the procurement lead directly going forward. This gets documented: what was found, the decision made, who approved it, and the date it was executed. At the next quarterly review, the same conflict is checked again to confirm the fix held and no other role change has reintroduced it.
Nothing about this example requires exotic tooling. It requires a policy specific enough to test against, a matrix that already rated the conflict's severity, and a procedure that didn't leave any of the six steps ambiguous. That combination, more than any particular piece of software, is what actually makes an SoD program hold up under audit scrutiny.
Common pitfalls in SoD policy and procedure
Writing the policy once and never revisiting it. A policy drafted during audit prep and never touched again describes an organization that no longer exists eighteen months later.
Exceptions with no expiration. A temporary access grant approved during a leave of absence or project crunch, with no built-in expiration date, is one of the most common ways SoD violations quietly become permanent.
No connection between the policy and the actual conflict matrix. A policy that states principles without referencing a specific, testable matrix of conflicts is difficult to enforce consistently, since two different reviewers might interpret the same situation differently.
Treating documentation as optional. Skipping the "document the decision" step in the procedure might save time in the moment, but it's almost always the first thing an auditor asks for. Its absence turns a minor finding into a bigger one about process integrity.
This documentation is what makes the procedure function as the corrective-control layer within a broader internal controls program; see Separation of Duties and internal controls for how detection, remediation, and documentation fit into that larger framework.
Where automation fits into the procedure
Everything described above, detection, risk assessment, remediation, documentation, verification, can be done manually. It typically is, at small scale. The manual version tends to break down for the same reason manual SoD detection breaks down generally: access changes continuously, and a human-run procedure can only check it periodically.
Automated SoD platforms fold several of these procedure steps into the detection mechanism itself. A policy defined once can trigger a scheduled scan, automatically log any violation found, route it to the designated owner for a decision, execute the agreed remediation through a configured action, and preserve a complete record of the decision, all without someone manually walking through each of the six steps by hand.
Zluri, an identity security platform, addresses this through its IGA product's Segregation of Duties capability. Policies run on a defined schedule, violations route to an assignee or trigger automatic remediation depending on configuration, and every policy version is preserved as a full configuration snapshot with a mandatory publish note.
If you're evaluating tools that can support this level of procedural automation, our guide to SoD software covers the buying criteria and compares the leading platforms.
Want to see how automated detection and remediation can run your SoD procedure for you? Book a demo with Zluri.
Frequently Asked Questions
What's the difference between an SoD policy and an SoD procedure? The policy is the documented rule, what conflicts are prohibited, who owns the program, and how exceptions work. The procedure is the operational process for identifying, assessing, remediating, and documenting a violation once it's found. Both are needed; neither substitutes for the other.
How often should an SoD policy be reviewed? Quarterly is common for high-risk processes; annually is typically the floor for lower-risk ones. Outside that schedule, any major role restructuring, new application rollout, or newly discovered violation type should trigger an off-cycle review.
Who should own an organization's SoD policy? Overall ownership typically sits with a controller, CISO, or compliance lead, with individual process owners named for specific areas like finance, IT, and HR. Shared ownership without a single accountable person tends to result in the policy going unmaintained.
What should an SoD exception process require? A documented, specific reason (not a generic justification), approval from a named role, and a maximum duration after which the exception automatically expires and gets re-evaluated rather than becoming permanent by default.
How long should remediation take once an SoD violation is found? This depends on the conflict's risk rating. High-risk violations typically warrant same-week resolution; medium-risk findings are often given around 30 days; lower-risk findings may be addressed at the next scheduled review, provided a compensating control is already in place in the meantime.
Can SoD policy and procedure be fully automated? Detection, notification, and even remediation execution can be automated through dedicated SoD software, which significantly reduces the manual burden. Some decisions, particularly high-stakes ones where context matters, are often still best routed to a human reviewer rather than resolved automatically by default.
.svg)
