> ## Content Index
> Fetch the complete content index at: https://www.sajeedmullaji.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# D365 F&O Security Governance Phase 2 — SoD Conflict Analysis
- URL: https://www.sajeedmullaji.com/d365-fo-sod-conflict-analysis-phase-2/
- Published: 2026-09-08T06:21:47.000Z
- Updated: 2026-09-08T07:25:20.000Z
- Description: One user with the wrong role combination can create a fictitious vendor and approve a payment to it with zero oversight. Discover how to find and fix this risk using only native D365 tools.
- Author: Sajeed Mullaji
- Tags: D365 FO, Security Architecture, ITGC Audit, The D365 Governance Roadmap, SoD

[D365 F&O Segregation of Duties (SoD) Mitigation LogD365 SoD Mitigation Log — conflicts, justifications, and compensating controls for audit evidence.D365 F&O Segregation of Duties (SoD) Mitigation Log.xlsx18 KBdownload-circle](https://www.sajeedmullaji.com/content/files/2026/09/D365-F-O-Segregation-of-Duties--SoD--Mitigation-Log-1.xlsx "Download")

[Sample SoD Justification LetterMEMORANDUM DATE: TO: Governance, Risk & Compliance (GRC) Committee / Internal Audit FROM: (\[Manager Title\]) SUBJECT: Segregation of Duties (SoD) Conflict Justification & Exception Request COMPANY / ENTITY: \[Company Name\] LOCATION: 1\. USER & ACCESS PROFILE Field Detail User Full N…![](https://storage.ghost.io/c/86/1f/861f43cb-a69d-4876-ae5d-bd42db276850/content/images/icon/docs-favicon-2026-v2-5bf77346-8711-40d0-a55d-9a9529a4b24e.ico)Google Docs![](https://storage.ghost.io/c/86/1f/861f43cb-a69d-4876-ae5d-bd42db276850/content/images/thumbnail/AHkbwyLTanbnCwKl8xKRoBZ8z1txrOOzW-4uZN3Lh8U2YIDXSo1hw7sqDna7YmsgdI8VGBBCN4cBCFZSO_3Sovkz_86UfXqOojTlE2aPbYxhvApmjQRS0_o-w1200-h630-p-7ca7a80e-3e28-48bc-9e4b-8cfcc461e10c)](https://docs.google.com/document/d/1NXnzoMuNWeGlgLYdd-MBHp%5Fm2bAUB3xVxiveAZShvTs/edit?usp=sharing&ref=sajeedmullaji.com)

Professional SoD justification letter template — three auditor approved scenarios with sign off block included.

A single fraudulent vendor payment that goes undetected typically ranges from fifty thousand to two hundred thousand dollars before someone notices.

It does not take a team of external hackers to execute this theft. It only takes one internal employee with the wrong combination of security roles in Microsoft Dynamics 365 Finance & Operations.

In Phase 1 of our governance engagement for Sajeed Mullaji Consulting, we extracted the security baseline. We found a user named Frank sitting in our active user list with highly elevated access.

We knew Frank had power. But raw data without context is useless to a CFO.

Today, in Phase 2 — D365 F&O SoD conflict analysis — we are going to apply algorithmic pressure to Frank's access. We are going to prove exactly why your internal auditors are about to flag him as a material weakness.

Here is the exact, step-by-step D365 Segregation of Duties execution roadmap.

### Step 1: The Baseline Check (Are You Flying Blind?)

Never assume a client environment has active security monitoring. Before we build new traps, we must check if the previous IT team left any active governance behind.

Navigate to **System administration → Security → Segregation of duties → Segregation of duties rules**.

Look at the grid. A blank ruleset means zero automated governance. The system is completely blind to toxic access combinations. If this grid is empty, your D365 environment is actively hiding financial risk from your executive team.

![](https://storage.ghost.io/c/86/1f/861f43cb-a69d-4876-ae5d-bd42db276850/content/images/2026/09/Screenshot-2026-09-08-113737.png)

Blank SoD ruleset — zero automated governance — system is blind to toxic access.

### Step 2: Engineering the Conflict Rule

We need to mathematically prove that a user can commit vendor fraud. To do this, we build a targeted Segregation of Duties rule.

On the Segregation of duties rules screen, click **New**.

We will name this rule: **Vendor Creation and Payment Approval**.

D365 Segregation of Duties rules are evaluated at the Duty level, not the Role level. For the **First duty**, select *Maintain vendor master*. This grants the systemic ability to create a vendor and alter bank routing details.

For the **Second duty**, select *Maintain vendor payments*. This grants the ability to generate and post a payment journal.

Set the **Severity** to **High**.

It is important to note that Microsoft provides a standard SoD rule set that can be imported as a starting point. However, standard rules do not know your unique business. Custom rules must always be added for specific, localized business processes.

![](https://storage.ghost.io/c/86/1f/861f43cb-a69d-4876-ae5d-bd42db276850/content/images/2026/09/Screenshot-2026-09-08-113545.png)

Vendor Creation and Payment Approval rule — Maintain vendor master vs Maintain vendor payments — Severity High.

### Step 3: Running the Detection Engine

We have built the trap. Now we unleash it against the entire active user base.

Navigate to **System administration → Security → Segregation of duties → Verify compliance of user-role assignments**.

Click **OK**. This action runs a batch job that checks every single user assignment against every active SoD rule in the system.

In a massive enterprise environment, this batch job runs in the background. In smaller environments, it processes rapidly. Do not skip this step; D365 does not evaluate SoD conflicts in real-time on the front end without this engine running.

### Step 4: Exposing the Unresolved Conflicts

The batch job has finished. It is time to review the damage.

Navigate to **System administration → Security → Segregation of duties → Segregation of duties conflicts**.

The screen populates. In our Sajeed Mullaji Consulting engagement, Frank is immediately flagged. But he is not alone. April and Sara are also showing as conflicted.

One single rule just exposed three users simultaneously. This is exactly what happens in real enterprise environments. The problem is almost never just one person; it is a systemic failure of role design.

![](https://storage.ghost.io/c/86/1f/861f43cb-a69d-4876-ae5d-bd42db276850/content/images/2026/09/Screenshot-2026-09-08-113129.png)

Three users flagged simultaneously — one rule exposed systemic role design failure across the environment.

### Step 5: Translating IT Risk to Business Impact

When presenting this screen to a CFO or IT Audit Director, you must translate technical roles into dollar amounts. Talk about the D365 vendor fraud risk.

Frank holds the Accounts Payable Manager role, which contains *Maintain vendor master*. He also holds the Accounts Payable Payments Clerk role, which contains *Maintain vendor payments*.

Because of this specific overlap, Frank can silently create a fictitious vendor. He can add his own personal bank details. He can raise an invoice against that vendor, and he can approve the payment himself with zero secondary oversight.

![](https://storage.ghost.io/c/86/1f/861f43cb-a69d-4876-ae5d-bd42db276850/content/images/2026/09/Screenshot-2026-09-08-112619.png)

Frank holds both conflicting roles — system confirmed vendor creation and payment approval in one user account.

### Cross Question: "Won't our workflow approvals stop him?"

This is the first question every CFO asks. The brutal truth is no. Workflow approvals are not a substitute for SoD controls.

Workflows only protect you if they are perfectly configured and cannot be overridden. If Frank’s roles contain underlying systemic privileges that bypass the user interface, the workflow is useless. Systemic access always overrides business process.

### Cross Question: "Why didn't the SoD engine catch this earlier?"

D365 F&O native SoD engines have a massive architectural blind spot. They evaluate risk strictly at the Duty level.

If a previous internal IT administrator customized a role by bypassing the Duty layer and injecting a raw Privilege directly into the role, the SoD engine goes completely blind. The user still has the toxic access, but the automated tool will never report it.

### Step 6: Native Remediation Options

We have found the D365 ITGC audit SoD failure. Now we must fix it natively within the system. Select Frank's record on the conflicts screen.

You have two native buttons available.

**Option A — Deny assignment:** If you click this, the system instantly strips the conflicting role from Frank. The vulnerability is permanently blocked. However, Frank might no longer be able to perform his daily job.

**Option B — Allow assignment:** If you click this, the system leaves the access in place but forces you to document a compensating control with formal justification.

Auditors accept "Allow assignment" ONLY if the justification is highly specific, time-limited, and includes an independent control. Vague justifications trigger immediate material weakness findings.

![](https://storage.ghost.io/c/86/1f/861f43cb-a69d-4876-ae5d-bd42db276850/content/images/2026/09/Screenshot-2026-09-08-111943.png)

Two native remediation options — Deny assignment blocks permanently — Allow assignment documents a compensating control.

### Step 7: Structuring the Perfect Justification

When you click Allow, you are accepting financial risk. Here is how you document it to survive an audit.

**Accepted Justification 1 (Small team constraint):** There is only one qualified AP resource in the regional office. A monthly management review of all vendor master changes is in place and performed by the Controller.

**Accepted Justification 2 (Temporary coverage):** The primary payment approver is on medical leave. Systemic access is granted for 30 days only, with a weekly D365 vendor fraud risk review executed by the CFO.

**Accepted Justification 3 (System limitation):** The D365 workflow is not yet configured for this new legal entity. A manual approval email chain is documented and attached to every payment journal before posting.

**Rejected Justification (Do not use):** "Business requirement." Full stop. No detail. No compensating control. This will fail your audit immediately.

### Step 8: Delivering the Audit Evidence

Auditors do not accept screenshots. They require cryptographic proof of your D365 SoD mitigation log.

From the conflicts grid, click the *Open in Microsoft Office* icon and export the grid to Excel. This flat file becomes your official audit evidence.

What do external Big Four auditors look for in this file? They look for every single conflict identified. They check the resolution chosen. They scrutinize the justification text, they verify exactly who approved it, and they check the timestamp.

If IT Security approved a financial risk, the auditor will fail the control. Only business process owners can accept financial risk.

![](https://storage.ghost.io/c/86/1f/861f43cb-a69d-4876-ae5d-bd42db276850/content/images/2026/09/Screenshot-2026-09-08-114711.png)

Frank confirmed with vendor creation and payment approval conflict — Resolution None means unmitigated risk on the balance sheet.

### The Bridge to Phase 3: Role Engineering

Every environment has unique conflicts, but the pattern of unmanaged risk is universal.

Clicking 'Allow assignment' and logging a D365 compensating control is a necessary band-aid to survive an immediate audit. But it requires constant human effort and manual review to maintain.

The permanent, structural fix is to stop relying on out-of-the-box Microsoft roles that overlap in the first place.

What comes next is Phase 3 — Role Engineering. We are going to rip open the Accounts Payable Manager role and surgically extract the toxic duties so Frank can do his job without ever triggering a conflict again.

### Elevate Your Governance Standard

Do not build these documents from scratch. You need defensible assets that Big Four auditors immediately recognize and accept.

The complete, professional D365 SoD Mitigation Log Excel template and the formal Sample SoD Justification Letter are available for immediate download.

Visit **sajeedmullaji.com** to secure your environment, pass your next ITGC audit, and transition your D365 security from reactive chaos to proactive governance.

### Executive Q&A: Advanced D365 F&O Security Governance  

**Q1: We use a third-party ISV solution for vendor payments. Will the native D365 F&O Segregation of Duties engine still detect a conflict if Frank uses the ISV module to pay the vendor?**

**Answer:** It depends entirely on how the ISV engineered their security architecture. If the ISV correctly mapped their custom payment process to standard D365 Duties, the native SoD engine will catch it.

However, if the ISV created custom Duties, or worse, assigned raw Privileges directly to their custom roles, your native SoD rule looking for *Maintain vendor payments* will completely miss the conflict. You must map the ISV's specific custom Duties and build a brand-new SoD rule incorporating them to guarantee coverage.

**Q2: Our CFO just signed an SoD Justification Letter accepting the risk for an AP Clerk. Can we leave that mitigation active indefinitely since the business officially accepted the risk?**

**Answer:** No. External auditors view unexpiring risk acceptance as a severe control failure. A D365 compensating control relies on human intervention (like a manual review), and human controls degrade over time.

Big Four auditors expect high-severity SoD mitigations to be reviewed and re-certified every 90 to 180 days. Furthermore, a justification is supposed to be a temporary bridge while IT engineers a permanent systemic fix (role splitting). Indefinite mitigations signal to an auditor that your IT department lacks the technical capability to properly engineer security roles.

**Q3: We ran the Verify Compliance batch job, but the unresolved conflicts grid is empty. Our internal audit team insists we have toxic overlaps. Why is the system returning zero conflicts?**

**Answer:** You are likely suffering from System Administrator sprawl. The native D365 F&O Segregation of Duties engine is hardcoded to ignore any user who holds the System Administrator role.

If your IT team over-provisioned SysAdmin access to power users, or if business users were granted SysAdmin to bypass go-live issues, the SoD engine will skip them entirely during the batch run. Your environment is highly toxic, but the reporting tool is artificially blinded by the highest level of access. You must strip SysAdmin rights before your SoD reporting can be trusted.