Segregation of Duties Reporting in Dynamics Finance & Operations: Platform Capabilities and Business Responsibilities

Segregation of Duties (SoD) is frequently treated as a security-configuration task. In Dynamics 365 Finance & Operations (D365FO), it warrants a broader designation: a business-control capability that security configuration makes possible.

D365FO can identify incompatible access, prevent new conflicts from being introduced, and retain a record of exception decisions. What it cannot do is determine which access combinations represent unacceptable risk for your specific organization. That distinction matters.

The platform provides the framework. The business must define the controls.

What D365FO Provides Out of the Box

D365FO includes a SoD framework within its role-based security model. Security roles contain duties, duties contain privileges, and privileges grant access to application entry points and data. SoD rules are defined at the duty level: The organization identifies two duties that should not be held by the same user, and D365FO evaluates roles and user-role assignments against that rule.

The standard capability includes the following functions:

Capability	What D365FO Provides
SoD rule configuration	Administrators can define incompatible duties, assign a severity level, document the associated business risk, and identify the expected mitigation.
Role-design validation	D365FO can identify when a single security role contains duties that violate an established SoD rule.
User-role assignment validation	The system can evaluate whether a user’s combined role assignments create a SoD conflict.
Assignment enforcement	When a new role assignment creates a conflict, D365FO can block the assignment unless it is explicitly allowed as an override.
Conflict inquiry and history	Administrators can review unresolved conflicts and retain visibility into approved overrides.
Role violation reporting	The Roles violating segregation of duties view identifies roles that conflict with configured SoD rules.
Security configuration migration	Customized security configuration, including SoD rules and conflict data, can be moved across environments through data-management entities.

This constitutes a strong foundation for internal controls. It helps organizations identify incompatible responsibilities, reduce opportunities for fraud or error, and provide evidence that access has been reviewed.

One important clarification: The framework is not a finished SoD program.

The Most Important Reality: Rules Are Not Prebuilt for Your Organization

D365FO delivers the SoD engine, security metadata, inquiries, reporting, and enforcement points. It does not deliver a complete, business-approved SoD ruleset that automatically fits every organization; that is by design.

A manufacturer, a professional-services firm, a retailer, and a public-sector entity may all use Accounts Payable, Procurement, General Ledger, and Cash and Bank Management differently. Their risk tolerance, staffing structures, approval hierarchies, compliance requirements, and compensating controls may also differ considerably.

D365FO allows the administrator to define conflicting duties, severity, risk description, and mitigation guidance. The business must determine whether that combination is genuinely risky, whether it is permitted under limited circumstances, and what evidence is required when an exception is approved.

A weak ruleset creates false assurance. If a risk is not configured, D365FO cannot identify it.

An overly broad ruleset creates noise. If every access combination is treated as a potential conflict, the organization may face a large volume of exceptions with very little meaningful control.

The objective is not to create the most SoD rules but to create the right ones.

How SoD Reporting Works in D365FO

A sustainable SoD process has four connected elements: design, configure, validate, and govern.

1. Design the Control Matrix

Start with business processes, not D365FO role names. The business should identify critical activities across each process and determine which activities should be performed by separate individuals.

The output should be a business-owned SoD matrix, not a technical spreadsheet listing security-role combinations without context.

Each rule should capture the following: business process, conflicting activities, business risk, rule severity, process owner, expected remediation path, permitted compensating control, exception approver, evidence requirement, and review frequency. This matrix becomes the design authority for all D365FO configuration decisions.

2. Map Business Activities to D365FO Duties

This step requires functional, security, and architecture teams to work in close collaboration.

Business activities do not always map cleanly to a single security role. A user’s effective access may derive from several assigned roles, and a role may contain multiple duties. SoD analysis must therefore consider the complete security model, not just one role in isolation.

The mapping exercise should account for several aspects, including: standard roles and duties; custom roles, duties, and privileges; security introduced through extensions; integration and service-account access; administrator access; temporary elevated access; legal entity-specific access; and security assigned directly to users or through groups.

Rather than creating highly individualized roles for each user, Microsoft recommends designing modular security roles around business processes and SoD requirements. A modular model is easier to govern, easier to test, and less likely to result in an uncontrolled role sprawl. learn.microsoft

3. Configure the Rules and Validate the Environment

SoD rules are maintained at: System administration > Security > Segregation of duties > Segregation of duties rules. For each rule, the administrator specifies the first duty, second duty, severity, risk description, and mitigation guidance. Creating an SoD rule does not automatically analyze the environment; validation must be performed separately. learn.microsoft

Two key checks should be performed:

1. Validate duties and roles to identify roles that contain incompatible duties.
   
2. Verify compliance of user-role assignments to identify users whose combined roles create a conflict.
   

User-level conflicts appear in the Segregation of duties unresolved conflicts inquiry. When a future role assignment creates a conflict, D365FO can display an error and require the administrator to either deny the assignment or explicitly allow it as an override. Approved exceptions require a documented reason and remain visible for subsequent review. learn.microsoft

4. Resolve, Document, and Monitor

A SoD conflict is not necessarily a control failure; it is an exception that requires an informed business decision. Each conflict should result in one of three outcomes:

1. Remove or redesign access when the user does not require the conflicting responsibility
   
2. Redesign the security role when a single role contains incompatible duties
   
3. Approve a documented exception when business operations, staffing limitations, or organizational design require combined access
   

An override should never be a simple technical decision made to bypass an error message. A meaningful exception record should include:

• A clear business justification
  
• The approving authority
  
• The risk being accepted
  
• The compensating control in place
  
• The owner of that compensating control
  
• The required evidence
  
• A review or expiration date

This converts an override from an undocumented security exception into a governed, business-controlled decision.

Important Limitations to Understand

The standard D365FO SoD capability is valuable, but it is not a complete governance, risk, and compliance solution.

First, D365FO evaluates only the rules that the organization has configured. It does not independently identify fraud scenarios, assess whether a business process is adequately controlled, or evaluate whether an approval workflow is operating as intended.

Second, the quality of SoD analysis depends directly on the quality of the underlying security model. Broad roles, unmanaged customizations, undocumented privileges, and excessive administrative access can all reduce the usefulness of the results.

Third, organizations should carefully test their security-assignment model. Microsoft reports that conflicts are not currently verified for users assigned roles through Active Directory Domain groups. Where group-based assignment is part of the security design, an appropriate compensating access-review process should be established and tested.

Finally, SoD should not be viewed as a substitute for other critical controls, including:

• Workflow approvals
  
• Audit trails
  
• Periodic user-access recertification
  
• Vendor and customer master-data monitoring
  
• Payment controls
  
• Privileged-access management
  
• Security change management
  
• Internal-audit review

SoD is one important control layer. It is not the entire control environment.

Conclusion

The most effective D365FO SoD implementation is not the one with the largest number of rules. It is the one where the configured rules accurately reflect the organization’s actual risks, the security model supports how people work in practice, and every exception is visible, temporary, documented, and owned.

Start with a business-controlled SoD matrix. Map that matrix to D365FO duties. Validate both role design and user assignments. Then establish disciplined exception management and a recurring access-review cadence.

D365FO provides the tools to identify and manage incompatible access. The business provides the governance, control design, and accountability that make those tools effective.

---