How does the D365 F&O security model work?
D365 F&O uses a role-based security model built on a hierarchy of roles, duties and privileges. Roles are assigned to users; each role contains duties (logical groupings of related tasks); each duty contains privileges (the actual permissions to access specific objects and operations). This hierarchy means you can build a clean, auditable security model — but only if you design it properly from the start. The common mistake is assigning too many roles per user, which undermines segregation of duties and makes the model unmaintainable.
How do we implement segregation of duties in D365 Finance?
D365 Finance has a built-in segregation of duties (SoD) framework that lets you define rules preventing users from holding conflicting privilege combinations — for example, someone who can create a vendor cannot also approve payment runs. The system enforces these rules at user assignment and flags violations. The key design task is mapping your SoD rules to the actual D365 privilege structure, which requires someone who understands both the financial control requirements and the technical security model. Do not leave this to the end of the project.
What audit trail capabilities does D365 F&O provide?
D365 F&O provides database logging for changes to specific fields and tables, the ability to track who posted transactions, and an audit trail for security role changes. For regulated industries you can also configure change-based alerts and use the Audit workbench. However, the default logging configuration is not comprehensive — it has to be switched on for the fields and entities that matter. Work with your auditors during the design phase to identify exactly what they will want to see, and build the logging configuration to match.
How do we manage environment access and data protection for D365 F&O?
Production should have the smallest possible set of privileged users. Use Microsoft Entra ID (formerly Azure AD) groups to manage access at scale, not individual assignments. Sensitive data — personal details, bank account numbers, salary information — should use the D365 field-level security feature to restrict visibility to roles that genuinely need it. For GDPR compliance, D365 includes a Person search report to identify where individual data is stored. Establish a process for regular access reviews: standing privileged access in ERP systems is a recurring audit finding.
What should we configure before handing D365 F&O over to auditors?
Before your first audit post go-live, make sure you can evidence: that SoD rules are configured and enforced, that database logging covers financially significant fields, that privileged access is limited and reviewed, that period close and posting controls are configured, and that your IT general controls documentation reflects the actual D365 setup. Auditors testing a new ERP will probe the access controls first. If you cannot answer their questions about who can do what and how that is prevented from conflicting, expect a finding.