BC Permission Sets — Building a Defensible SoD Framework Without a Native Engine

BC has no native SoD engine. No conflict matrix rules, no automated blocking, no runtime validation. The entire governance burden falls on explicit permission set design and administrative discipline.

Unlike enterprise ERP systems that feature automated compliance engines, Microsoft Dynamics 365 Business Central contains no native Segregation of Duties (SoD) enforcement engine. When auditors evaluate a Business Central environment for SOX, FDA, or ITGC compliance, they do not look for automated blockages — they test whether the underlying permission structures prevent a single user from possessing end-to-end control over critical financial cycles. Failing to implement compensating controls is treated as a severe control deficiency.

How BC Permission Sets Work — Objects, Types, and RIMDE

Business Central relies on object-based security. Permission sets act as containers defining exactly what database objects a user can interact with and what operations they can perform. BC controls access across five primary object types: tables, pages, reports, codeunits, and queries. Table data security is the most critical — database records carry direct financial value.

Within these objects, permissions are governed by the RIMDE framework:

Read

View records

Insert

Create records

Modify

Edit records

Delete

Remove records

Execute

Run objects

Permissions can be Direct or Indirect. An indirect permission means a user cannot access a table directly through the UI, but can read or modify data through a controlled posting routine or codeunit workflow. BC Cloud users receive baseline permission sets tied to their M365 license type first, upon which administrators layer additional custom or system permission sets.

The Three Permission Set Categories

System Permission Sets: Maintained by Microsoft. Include baseline roles like D365 BASIC or D365 BUS. FULL ACCESS. Locked — cannot be modified by administrators.
Extension Permission Sets: Deployed via AppSource or custom per-tenant extensions written in AL code. Also immutable within the UI.
User-Defined Permission Sets: The only category fully editable by administrators. Effective SoD governance relies entirely on disciplined user-defined sets built on the principle of least privilege.

How to Design SoD Governance Using Permission Sets

Because BC lacks native SoD rule validation, building a defensible framework requires a methodical approach. Start by establishing a risk matrix mapping every business process — Procure-to-Pay, Order-to-Cash, General Ledger posting — into distinct functional duties.

Eliminate monolithic baseline roles. Granting D365 BUS. FULL ACCESS breaks segregation immediately. Instead, decompose job functions into granular, task-specific user-defined permission sets. Separate the duty of creating vendor master records from the duty of approving payment journals.

Because permission sets in BC are additive when assigned concurrently, administrators must audit the combined effect of all assigned sets — not individual assignments in isolation. A user with three permission sets holds the cumulative permissions of all three.

The Most Dangerous Permission Set Combinations

⚠️ The most dangerous configuration: assigning the SUPER permission set. Combining SUPER with any other set grants full unrestricted access to all database objects, bypassing all security boundaries.

Vendor Creation + Payment Processing

Insert/Modify rights on the Vendor table alongside Execute and Modify rights on Bank Payment Export or General Journals — enabling ghost-vendor creation and direct disbursement manipulation. Equivalent to VendVendorMasterMaintain + VendPaymApprove in F&O.

Customer Master + Credit Limit Override

Customer edit rights combined with unconstrained sales document posting permissions — enabling fictitious revenue generation and accounts receivable manipulation.

Item Journal Posting + Inventory Valuation Setup

Inventory adjustment posting alongside direct ledger setup modification — masking physical inventory shrinkage from financial statements.

How to Audit Current Permission Set Assignments

1Open the Users List

Use the Tell Me search (Alt+Q or magnifying glass icon) → type Users → select the Users link. Or navigate directly using /?page=9800 appended to your BC environment URL. Select an individual user card to inspect their assigned permission sets.

2Review Permission Set Contents

Use Tell Me search (Alt+Q) → type Permission Sets → open the page directly. Open any user-defined permission set to view its constituent table data, page, report, and codeunit permissions at the RIMDE level.

3Export for External Analysis

Export the user list and permission set assignments to Excel via the standard Open in Excel action. Perform offline matrix cross-referencing to identify overlapping permissions and build an external SoD conflict report.

Quarterly Review — What to Check and When

Given the absence of native runtime prevention, periodic manual validation is mandatory. Every 90 days, pull a complete export of all active users, their M365 license types, and every assigned permission set. Verify three core parameters:

Confirm zero users possess the SUPER permission set outside of designated emergency break-glass accounts
Cross-reference user-defined sets to ensure no new additive combinations introduce cross-process conflicts
Validate that terminated employees have had permission sets immediately revoked

A complete BC governance review — identifying SUPER assignments, dangerous permission combinations, inactive users, and shared accounts — delivered within 48 hours from two standard exports. No system access required.