Dynamics 365 (D365) is a cloud-based ERP software solution that can be used by management for real-time visibility into performance, automated workflows, and customisable reporting and analytics features to help streamline processes and make informed decisions. Often it's chosen due to an existing investment in Microsoft systems, a need for integration with other Microsoft tools, or a desire to upgrade legacy finance systems and take advantage of cloud infrastructure.
While reviewing D365 implementations from a risk or internal audit perspective, however, we identified some common challenges related to access and segregation of duties controls. These included issues with role design, segregation of duties (SoD) conflicts, and under-utilisation of system functionality and tools for maintaining controls. We also observed recurring issues across organisations, mainly stemming from the complexity of the system design, insufficient knowledge and awareness about system functionality, and limited time spent in the project phase to define and implement control requirements.
The Microsoft standard roles aren't free of conflicts and are built to allow access to a wide variety of functionality, which then needs to be reduced based on your organisation's needs.
The structure of the role design is quite complex, with many layers that can be used to make access granular – presenting a challenge to reviewers, with comprehensive manual reviews being extremely time-intensive. Security objects in D365 designate what users can do in the system. These are grouped to form privileges, which may be grouped to form duties, and ultimately these are all nested under roles, which are assigned to users.
Where the assignment of multiple roles to users is not controlled, governed by a security matrix, or risk-assessed and approved by an appropriate individual with sufficient competence and authority, there's a risk of introducing segregation of duties violations. These may lead to bypassing of internal controls and the risk of fraud.
The D365 role design needs to be assessed against your organisational hierarchy, the principles of least privilege, and business need. Access and authorisation controls within bespoke modules, such as project and property management, should also be reviewed.
Organisations that follow good practice have spent time upfront in the project design phase to review standard roles and customise these to be as narrow as possible, thus eliminating segregation of duties conflicts from the roles.
Microsoft's standard duties and privileges may also cause segregation of duties concerns in custom roles due to inheritance relationships. We recommend that roles are customised to be as free of conflicts as possible, and other methods to mitigate conflicts applied as compensating controls where conflicts can't be removed from the role design.
There's a built in SoD tool as part of D365, but it doesn't have a default ruleset and doesn't review access permissions at a granular enough level. For instance, a permission could be flagged as generating a conflict when that access is 'read only' and can't be used to process any transactions. It's therefore important to extract granular data including security objects and report on segregation of duties conflicts in your D365 instance, and to tailor a library of segregation of duties rulesets based on existing process maps and business processes carried out in the system.
Another layer of security additional to the role design – which contains ‘allow’ permissions – is the ability to deny permissions. These were used in instances where knowledge about the role design hadn't been effectively handed over from implementation to system administrators due to a lack of documentation. This leads to additional complexity when trying to review what conflicts need to be addressed because SoD tools can only analyse the ‘allow’ permissions in the role design.
Given the complexity of the role design and the potentially millions of conflicts which can be generated from inappropriate access assignments, automated tools and specialists who can interpret their results is recommended to reduce the D365 SoD risk. In the selection of such a tool, you need to consider essential capabilities such as granularity, ability to tailor rulesets and ability to visualise the results in a user-friendly manner.
One area of good practice – which mitigated around 95% of SoD conflicts found in role assignments in one particular case – is the introduction of workflows across key finance cycles. The workflows contained logic within them to allow approvals only based on the delegation of authority matrix, expected monetary limits, and to prevent the same person from raising and approving transactions. Even in cases where users had permissions to raise and approve transactions, we observed that workflows would override this and enforce segregation of duties.
While compensating controls, such as automated workflows, may provide good mitigation for a role design that introduces conflicts to the system, removing conflicting access from users will help reduce your reliance on such mitigations. Users may have become reliant on their current permissions over the course of time, however. Instantly revoking access could result in operational issues so you need to perform an assessment of this risk and test changes to the role design before implementation.
In cases where mitigations are introduced for SoD conflicts, it's important to scrutinise the users who can change the underlying configurations for the mitigating controls. The default logs in D365 often don't give sufficient details for these reviews of privileged activity, in which case enhanced logging should be explored for key activities and data modifications.
Segregation of duties conflicts are common in organisations using D365 due to the complexity of its role design and inherent conflicts present in its default roles. From our experience of reviewing organisations’ D365 instances and their segregation of duties controls, there are common challenges to address around designing roles that are free of conflicts, inadequate tooling to manage access, and overly broad privileged access. The likely root cause is insufficient consideration and planning of system roles prior to implementation and an over-reliance on default roles, which have broad functionality.
Examples of good practice we found include removing conflicting permissions from roles before the system goes live, implementing security matrices to drive user access assignments, implementing automated tools to support the maintenance of conflict-free environments and facilitate user access reviews, and applying workflows to mitigate conflicts.
People are a key enabler for the adoption of these good practices. All three lines of defence need to upskill their teams around system segregation of duties risks and controls, and call on subject matter experts to provide in-depth and tailored insight for the chosen ERP solutions.
For more insight and guidance, contact Cristiana Mirosanu.
