How to Implement Data Security Best Practices in Dynamics 365 F&SCM

Table of contents
The cost of a data breach can be very high. The global average cost of a data breach in 2024 for an organization as reported by IBM, was a record-breaking 4.9 million USD.
The enterprise system houses crucial and sensitive financial data. In addition to compliance with frameworks like GDPR, SOX, CCPA, and other regulations, organizations need to account for cybersecurity.
Therefore, organizations must familiarize themselves with the security landscape of their key systems to ensure compliance and protect their data from fraud, theft, and data breaches.
One concern highlighted in the ERP 2024 report by Panorama Consulting is that organizations moving from legacy systems to cloud-based ERP systems was data security. Although Microsoft offers security role management and a range of security layers that can be configured for Microsoft Dynamics 365 Finance & Supply Chain Management, setting up and maintaining security processes is the organization’s responsibility.
To ensure you get Dynamics 365 data security right the first time, we share a structured approach to managing security within D365 F&SCM. Using our robust tried and tested security best practices offered in this blog, you can ensure your D365 F&SCM security implementation is airtight.
At STAEDEAN, we have helped several customers with our no-code embedded Data Management solutions for Dynamics 365. To know more about our Data Security and Compliance Solution, browse our product page.
Understanding Dynamics 365 F&SCM Security Architecture
Microsoft offers layers of security and also leverages Azure’s security capabilities for D365 F&SCM. Below we share an overview of the D365 F&SCM security model. The D365 F&SCM security architecture comprises of several layers:
Authentication
The initial layer uses Microsoft Entra (earlier known as Azure Active Directory), as the primary identity authenticator.
Authorization
Under this layer, you can configure security roles, duties, privileges, and permissions in D365 F&SCM. This can be a little complicated and lead to security threats if not properly configured.
Roles: Roles act as an initial authenticator and share access to either all legal entities or specific legal entities in D365 F&SCM. A user can be assigned to an existing security role in Dynamics out of the hundred standard roles. The system administrator can also create a new role by duplicating and modifying existing roles or customizing completely new roles. Standard roles have a set of duties associated with a job function, for example, “branch manager”.
Duties: There are 1000+ duties. Duties are made up of privileges and represent parts of a process associated with the role assigned, for example, “maintain vehicles”.
Privileges: Privileges are task-focused and based on the role. Privileges share permissions to access levels with associated entry points, for example, “edit vehicles menu item”. There are 8000+ privileges.
Permission: At the bottom-most level of the hierarchy is a group of base objects. There are 30,000+ permissions. This is again associated with the job function and shares required permission to data such as “read vehicle table”.
Above is an example of setup of a role for a sales manager
Data security policies
Segregation of duties
In Dynamics 365, there is a segregation of duties also referred to as SoD. Segregation of duties helps you enforce internal control policies, detect security threats, and also reduce the threat of fraud.
SoD rules
Based on your compliance requirements, you can setup SoD rules. While defining rules for segregation of duties, you need to evaluate Microsoft’s existing role definitions and role assignments. You need to map duties to roles and the existing business processes. Is there a combination of dutyies that a specific role user should not perform? Then there should be a SoD rule setup to detect such conflicts.
Extensible data security policies
With Extensible Data Security (XDS) policies, using customizations, you can restrict table-level access to records based on security policies.
Although the Dynamics 365 security model is robust, it can be overwhelming and requires an understanding of D365 F&SCM security architecture, and a familiarity with the security roles, duties, privileges, and permissions. Next, lets understand how to navigate Dynamics 365 security to ensure minimum risk to your organization’s data.
Encryption and Decryption
At-rest and in-transit data protection: Dynamics 365 environment databases use SQL TDE (Transparent Data Encryption, compliant with FIPS 140-2) to encrypt and decrypt the data and for database logging. This provides data encryption at rest. Microsoft also offers in-transit data protection using security protocols.
Essential Security Implementation Steps for Dynamics 365 F&SCM
Security role management and auditing is the responsibility of your organization, and you cannot expect your ERP implementation partner to take this on. Implementing data security in Dynamics 365 Finance and Supply Chain Management (F&SCM) requires a structured approach to ensure data integrity and compliance. A well-defined Dynamics 365 data security strategy helps organizations safeguard sensitive information and comply with regulatory requirements.
To build a comprehensive security framework, the following implementation steps are essential
Step 1: Conducting a security assessment
-
Assemble a team: Put together a security and compliance team that comprises IT personnel, Security Architects, Data and Compliance Officers, Head of Business Units, Internal Auditors, QA & Testing Teams, and ERP Consultants.
-
Understand compliance needs: Analyze the regulatory compliance landscape (GDPR, CCPA, HIPAA, etc.) and the regulations your organization must comply with.
-
Study Dynamics 365 standard roles: Understand the default Dynamics 365 roles and the data access for each role down to the entry point level.
-
Review Dynamics 365 documentation: Study Microsoft’s policies and procedures for encryption, data handling, data residency, and disaster recovery.
-
Run a security assessment: Map security roles to compliance requirements. This will help you identify standard roles that could introduce compliance risk.
Step 2: Configuring Role-Based Access Control (RBAC)
-
Assign roles: First, as part of role-based security, assign system admin roles so that you can begin assigning security roles to the rest of the organization. Next, look at the standard roles and begin assigning access to users. The standard allows you to duplicate and customize a new role or create new roles. If you need to lock, disable, or merge existing roles, you cannot do that using native Microsoft functionalities. STAEDEAN’s Data Security and Compliance solution can help you simplify this without a line of code.
-
Create a role hierarchy: Using a role hierarchy, you can define parent and child roles. A parent role has access to the duties, privileges, and conditions assigned to its child roles. This can simplify processes and allows you to have a backup in times of absence. For example, an HR Manager can perform all the tasks and will have access to all the data that an HR Assistant has.
-
Dive deeper: Every role has a set of privileges, duties, and permissions that a user gets access to pre-defined in Microsoft. Duties, privileges, and permissions need to be checked in alignment with your security and compliance requirements and modified.
Step 3: Implementing Data Security Policies
Although organizations do not prioritize implementing data security policies in the first phase of an ERP implementation, we highly recommend it!
-
Set up segregation of duties: Related duties can be assigned to separate roles, allowing you to segregate duties to comply with your regulatory requirements. For example, you might not want the same person/role to set a bank account and manage vendor payments. Using STAEDEAN’s Data Compliance solution, you can handle segregation of duties, privileges and entry points which ensures people have access to exactly the data they need for their job functions.
-
Resolve conflicts: Once you segregate duties, the standard roles that violate rules, the conflict is logged. The administrator needs to identify and resolve conflicts.
-
Implement conditional access: You can restrict regional and global data using Microsoft Entra Conditional. By using Conditional Access policies, you can limit access controls. This functionality when applied, analyzes signals such as user, device, and location to enforce organizational security access policies. You can also enforce legal entity security boundaries.
-
Extensible Data Security (XDS) policies: XDS allows you to use customizations to restrict access to table records based on security policies. The query in the security policy applies a filter and records that do not meet the filter’s conditions will be restricted and the rest accessible. A word of caution regarding XDS policy queries – when not designed and tested adequately impact performance negatively.
-
Set up data loss prevention (DLP): Apply data loss prevention policies to make changes or request exceptions.
Step 4: Setting Up Field-Level Security
-
Field-level security: Dynamics 365 Finance does not offer field-level security but you can look at either customizing this for sensitive data protection or implementing STAEDEAN’s Master Data Management solution embedded in D365 F&SCM for field-level security.
-
Secure sensitive fields: Financial data, personally identifiable information, and other such information that ensures compliance can be restricted from view/edits using field-level security.
Step 5: Configuring Database Security
-
Database security: Configure database logging for limited tables or fields that store sensitive data. It is best to review your database logs periodically to see if they are still relevant for your business as they use resources, space, and can impact performance.
-
Data encryption implementation: Microsoft offers several encryption capabilities for volume encryption, file encryption, and mailbox encryption by default. Finance and operations apps use server-side encryption with service-managed keys. You need to ensure you have set up authorized users to access encryption keys for when the data needs to be decrypted. For additional compliance requirements, Microsoft offers additional solutions built on Azure.
Step 6: Establishing Audit and Monitoring Protocols
-
Set up security auditing in Microsoft Dynamics 365: System administrators can configure a user log to keep an audit of users who have signed in and out of the app.
-
Detailed audit trail implementation: If you are looking for an extensive audit trail, you will either need to customize or explore ISV solutions such as STAEDEAN’s Data Security and Compliance Solution. Using our solution, you can configure a detailed audit trail tracking 54+ events without affecting the performance of Dynamics 365.
-
Setup alert mechanisms and incident response: You can get an alert for a (possible) security-related incident from different sources. An important element is a robust solution that monitors all the security risks that can prevent an incident. But if there is an incident, you need to be able to go through the security auditing to identify where the problem originated and from there solve the problem.
Step 7: Training, Testing, Validation, and Deployment
-
Training and communications: Prior to security testing, ensure team members have received necessary training on security controls, protocols, and best practices. Ensure communication about important dates has been shared in advance with team members.
-
User Acceptance Testing: Ensure you have set up security and auditing processes prior to UAT testing. This helps you validate role assignment and gives you an idea of any SoD conflicts that will need to be managed. Outline security testing methodologies. The UAT helps the functional testing overall as you know what the user can expect when you go live and there are lesser surprises or chances of issues after implementation.
-
Validate security and auditing processes: While running security assessments, you can simulate threats, test readiness, and identify gaps for improvement.
-
Go live: Post testing, it is time to go live with your security roles and procedures. Ensure you have reporting setup to monitor and make improvements even post go-live.
Best Practices for Dynamics 365 F&SCM Data Security
Before you begin planning your ERP implementation project, plan your data governance and security processes keeping in mind scalability. Use our recommended D365 security best practices to plan your project.
-
Database logging: Since it can impact performance, it is best to limit log entries and select specific fields with just sensitive data for database logging and not whole tables. Keep a timeline for logged data, so that it can be deleted post an audit.
-
Group privileges to a duty: Instead of assigning privileges directly to roles, assign duties to role. This makes it easier to maintain.
-
Plan early: Start your security role management earlier in the Dynamics 365 implementation process so that you get enough time for testing.
-
Customize security: Security models will need to be tweaked based on legal entities or regionally, so plan for a tailored security approach.
-
Organization/User/Team owned entities: Select an approach based on your business requirements in the planning stage. If you are using a multi-phased approach, we recommend using user/team owned entities. This is because segmentation is difficult using organization owned entities. Once you create an entity, ownership is not flexible and cannot be changed.
-
Map security roles to business processes: Design security roles based on business processes and not for each user. Or else it will be difficult to maintain and not scalable. Incorporate segregation of duties for security roles.
-
AI Agents: Understand security and access for AI agents within Dynamics 365. Hiding fields might not be enough to restrict access, explore all the ways data can be accessed while planning for security and compliance.
-
Data exports: Understand and plan for a way to record the security context for data exports.
-
Map changes: Have a defined process to keep a tab of changes in the organization structure. Ensure to map this with your security model regularly in Dynamics 365.
-
Post go-live security and compliance: Plan processes to maintain the security and compliance post go-live. Document and setup a process to add future users, roles, and ensure compliance with required regulations.
Follow our D365 security best practices when you design your security and compliance processes and build on established data governance. Use a continuous improvement approach to improve and one-up your data protection strategies based on new laws, Microsoft rollouts, and changes in business.
Conclusion: Strengthen your Dynamics 365 security and auditing
Implementing robust data security in Dynamics 365 Finance & Supply Chain Management starts with understanding and leveraging the full capabilities of the available D365 security framework. From defining security roles correctly to the entry point level to managing user access through Azure Active Directory (Microsoft Entra), each step plays a critical role in protecting sensitive financial and operational data. You can strengthen up your auditing processes using add-on solutions such as STAEDEAN’s Data Security and Compliance solution.
However, implementation is only part of the equation. Ongoing security management including regular audits, role reviews, and compliance monitoring, is essential to adapting to new technologies, threats, and organizational changes. A proactive approach ensures that your security model scales with your business and is mapped with regulatory and industry mandates.
Maintaining data security and compliance is a continuous process. Investing in add-on security and compliance tools, staying updated with the latest security trends, and periodic assessments will safeguard your Dynamics 365 data from internal and external threats.
For more information on STAEDEAN’s Data Security and Compliance solution, access our guided demo from the link below.