Skip to main content
Identity Authority
Category: Governance & Compliance

Segregation of Duties Report

Also known as: SoD Report, Separation of Duties Report, SoD Violation Report, SoD Conflict Report
Simply put

A Segregation of Duties Report is a document that shows where individuals hold combinations of responsibilities or access that they should not have at the same time. It supports the underlying principle that no single person should be able to both carry out and hide errors or fraud. Organizations use these reports to spot and address risky access before it can be misused.

Formal definition

A Segregation of Duties (SoD) Report is an IGA artifact that identifies principals whose assigned entitlements, roles, or effective permissions violate defined SoD rules, policy constraints preventing any one individual from holding conflicting combinations of duties (for example, both initiating and approving a transaction). It is typically produced as part of access reviews, certification campaigns, or governance analytics, and enforces the control objective that no employee or group should be positioned to both perpetrate and conceal errors or fraud. As a governance and administration concern, an SoD Report is distinct from runtime access enforcement; it reports on conflicting access states discovered through analysis of entitlement data rather than making real-time PDP/PEP authorization decisions. The specific conflict rules, granularity (role-level versus fine-grained entitlement-level), and remediation workflow depend on the vendor platform and deployment configuration.

Why it matters

Segregation of duties rests on a foundational control objective: no single employee or group should be in a position both to perpetrate and to conceal errors or fraud. An SoD Report operationalizes that principle by surfacing where individuals have accumulated conflicting access, such as the ability to both initiate and approve a transaction, so that governance teams can act before the combination is misused. As a risk-mitigation tool, the report distributes accountability across the identity lifecycle by making toxic combinations of entitlements visible rather than leaving them latent in the access data.

These conflicts frequently arise not through deliberate misconfiguration but through the ordinary accumulation of access over time: role changes, temporary assignments that are never revoked, and inherited permissions can gradually place a single principal on both sides of a control. Because SoD violations often emerge from this drift, periodic reporting during access reviews and certification campaigns is typically the mechanism by which they are caught. Without it, an organization may satisfy each individual access grant while still failing the overarching control objective.

It is important to keep the report's scope clear. An SoD Report describes conflicting access states discovered through analysis of entitlement data; it does not, by itself, prevent a conflicting action at runtime. That distinction matters for compliance and audit conversations, where the report serves as evidence that conflicts are detected and remediated, while real-time enforcement of a given transaction is handled by separate authorization controls.

Who it's relevant to

Identity Governance Leads
Governance leads own the SoD rule set and the review cadence that produces these reports. They define which duty combinations constitute a conflict, decide the granularity of analysis (role-level versus fine-grained entitlement-level), and design the remediation and exception workflows that follow a flagged violation. The report is a primary instrument for demonstrating that conflicting access is being identified and addressed over time.
Compliance Officers and Auditors
For compliance and audit stakeholders, the SoD Report is evidence that the control objective, preventing any one individual from both perpetrating and concealing errors or fraud, is being monitored. It supports certification campaigns and access reviews, but they should understand that it documents detected conflicts in access states rather than enforcing controls at transaction time.
IAM Engineers and IGA Administrators
Engineers and administrators configure the platform that ingests entitlement data, evaluates it against SoD rules, and produces the report. They manage rule definitions, tune granularity, and integrate the output with remediation workflows. Because behavior varies by vendor and configuration, they are responsible for validating that the reporting logic reflects the intended policy constraints.
Security Architects
Architects position the SoD Report within the broader access governance program and must keep its scope distinct from runtime enforcement. They ensure that governance-time detection of conflicting access complements, rather than substitutes for, the authorization controls that govern individual transactions.

Inside SoD Report

SoD Rule Set (Toxic Combinations)
The catalog of conflicting entitlement, role, or permission pairs that should not be held by the same identity, expressed as policy rules the report evaluates against. In most deployments these rules are defined by risk and compliance owners rather than derived automatically.
Violations and Conflicts
The core output: identities that hold two or more entitlements that together breach an SoD rule. Depending on configuration, the report may distinguish potential (assigned access) from actual (exercised access) conflicts.
Affected Identities and Accounts
The users, service accounts, or other principals implicated in each violation, typically resolved back to their directory identity and the underlying accounts or roles that produced the conflict.
Risk Rating and Prioritization
A severity or risk score attached to each conflict so remediation can be prioritized. Ratings are usually assigned per rule by governance owners and vary by organization.
Mitigating Controls and Exceptions
Documented compensating controls or approved exceptions that acknowledge a conflict without immediate removal, along with their owners and review dates where the platform supports them.
Remediation and Certification Status
The state of each violation within the governance workflow, such as open, remediated, accepted, or pending review, linking the report to access review and certification processes.

Common questions

Answers to the questions practitioners most commonly ask about SoD Report.

Is a Segregation of Duties report the same thing as an access certification or access review?
No. Although both are IGA governance activities, they answer different questions. An access review or certification asks whether a given identity should still hold the access it currently has, typically by having a reviewer attest to each entitlement. A Segregation of Duties (SoD) report asks whether the combination of entitlements an identity holds creates a toxic pairing that violates a defined SoD policy, for example, the ability to both create a vendor and approve payments to it. An SoD report evaluates conflicts across entitlements against a ruleset; a certification confirms appropriateness of individual grants. They are often run together, but they are distinct controls.
Does producing a Segregation of Duties report actually prevent conflicting access from being granted?
Not by itself. An SoD report is a detective control that surfaces existing conflicts after the fact; it does not enforce anything at the moment access is requested. Preventive SoD enforcement, blocking a request that would create a conflict, is a separate capability, typically implemented in the provisioning or access-request workflow. In most deployments the report identifies violations that then require remediation, mitigation, or documented exception approval. Treating the report as a preventive control conflates detection with enforcement.
What inputs does an SoD report typically require to run?
Depending on the platform, an SoD report generally requires a defined set of SoD rules (the conflicting entitlement or function pairs), the current entitlement data for the in-scope identities, and often a mapping layer that translates fine-grained application permissions into the business functions the rules are written against. The quality of results depends heavily on how completely entitlements are aggregated and how accurately the rule set reflects real business conflicts. Gaps in either area produce false positives or missed conflicts.
How should exceptions to SoD conflicts be handled in the report?
In most IGA deployments, conflicts that cannot be resolved by removing access are handled through documented exceptions with compensating or mitigating controls, for example, additional monitoring or a secondary approval on the conflicting transaction. The report typically distinguishes unmitigated violations from those with an approved, time-bound exception. Well-governed processes require periodic re-review of exceptions so they do not become permanent, and the report should make the exception status and its expiry visible to auditors.
Should SoD rules be defined at the role level or the entitlement level?
This depends on the access model and the granularity of your data. Rules defined at a coarse role level are simpler to maintain but can miss conflicts introduced by direct entitlement grants or by permissions nested inside roles. Rules at the fine-grained entitlement or business-function level catch more conflicts but require accurate mapping and more maintenance. Many organizations combine both, evaluating conflicts across roles, direct assignments, and nested permissions so the report reflects effective access rather than only nominal role membership.
How can false positives in an SoD report be reduced?
False positives typically stem from imprecise rules, stale entitlement data, or mappings that treat unrelated permissions as conflicting. Reducing them generally involves refining rule definitions against actual business processes, ensuring entitlement aggregation is current, and accounting for context such as whether both sides of a conflict are actually exercisable by the identity. Some platforms allow scoping rules by application, environment, or organizational unit, which can lower noise, though the specifics vary by product and configuration.

Common misconceptions

An SoD report enforces access controls in real time and blocks conflicting access.
An SoD report is a governance (IGA) artifact that detects and surfaces conflicting entitlement assignments, typically after the fact. Runtime enforcement of what a principal may do is handled separately by authorization components (for example a PDP/PEP), not by the report itself.
A clean SoD report means the environment is free of segregation-of-duties risk.
The report only evaluates the rules that have been defined. Gaps in the rule set, unmodeled entitlements, or conflicts arising outside the analyzed systems can leave real risk undetected, so a clean result is bounded by the completeness of the configured rules and scope.
Every conflict listed must be removed to be compliant.
In most deployments some conflicts are knowingly retained under documented mitigating or compensating controls and formal exception approvals. Resolution can mean remediation or a governed acceptance, depending on organizational policy.

Best practices

Define and maintain the SoD rule set with business, risk, and compliance owners, and review it periodically so toxic combinations reflect current processes and systems.
Distinguish potential conflicts (based on assigned access) from actual conflicts (based on exercised access) in the report so remediation effort is directed appropriately.
Assign a risk rating to each rule and use it to prioritize remediation rather than treating all conflicts equally.
Require documented mitigating controls, an owner, and a review date for any accepted exception instead of leaving conflicts open indefinitely.
Integrate the report with access review and certification workflows so violations feed a tracked remediation or acceptance decision.
Validate report scope and completeness, confirming that all in-scope systems, entitlements, and account types are captured, since undetected gaps limit the report's assurance.
Promotional banner for the Penetration Report Template Kit