Microsoft D365 Security Design Implementation Considerations

Implementation timeline

• Pre-ERP implementation: Designing, building and testing a custom security model takes several months, varying based on the number of modules utilised. Most of this time will be spent conducting workshops with the business to determine access requirements and then the role build itself. Since these roles will be built to be risk compliant, we will also need to factor in time to configure a segregation of duties ruleset and control library. Organisations already on the path to implementation will want to weigh this timeline against the need to go-live as quickly as possible.
• Post-ERP implementation: Implementing security after an ERP implementation allows for more buy-in time from the business, IT, and compliance. There is less pressure to make decisions based on the ERP implementation timeline and greater focus on taking the proper measures to come to a reasonable solution.

User knowledge base

• Pre-ERP implementation: While all security designs are iterative, there may be additional iterations when implementing security during an ERP implementation as the SMEs are learning the platform functionality, business processes are still in design phases and configuration is still being completed. While this may appear as a disadvantage, the security role design may help SMEs better understand the system and provide transparency among the responsibilities of other workstreams.
• Post-ERP implementation: On the other hand, designing custom security after implementation will be more streamlined as the business processes and configurations are defined, resulting in quicker decision making and testing during the project.

Business optics

Potentially one of the most important considerations is the impact on the business. The look and the feel of the application and the user experience is different depending on which approach is taken. This could result in additional change management and training efforts to help the end user understand how to use the application leveraging the custom security model.

• Pre-ERP implementation: When aligning role design to ERP implementation, the business will operate compliantly immediately from go-live. Although there may be some growing pains incorporating security into the implementation, there is less burden on IT for maintenance as the business has a deeper understanding of the system and will be empowered to make decisions.
• Post-ERP implementation: Designing security post-implementation may have larger impacts on the business as the business has become comfortable with their access and navigation. The business may have to adjust their processes due to potential access changes as roles become segregation of duties risk compliant. However, implementing a custom security model after an ERP implementation may give more time for the business to grasp the concepts and be engaged in the role design without distraction from other implementation activities.

Testing

• Pre-ERP implementation: During an ERP implementation, we recommend incorporating security during the user acceptance testing phase. One of the main obstacles we see is that testers may not know exactly what to look for or do not fully understand the way the system should function as this may be one of their first experiences working in the system. Additionally, it may be difficult for testing teams to identify what issues are related to security and which are related to configuration, integrations or custom code. It is important to create synergy among the testing team to ensure bugs are properly identified and troubleshooted in a timely manner.
• Post-ERP implementation: If a business designs security after implementation, testers are easily able to navigate test scripts and identify bugs. Also, business processes are already defined, which removes the guesswork in the testing process.

Licensing impacts

• Pre-ERP implementation: While cost can be a deterring factor in deciding when to implement a custom security model, it is important to weigh it against the cost of utilising standard out-of-box security. The out-of-box roles tend to overprovision security – creating segregation of duties risks and higher licensing costs. Customising the security model to only the access required will make the environment more secure and can save hundreds of thousands in licensing fees. Learn more about the Microsoft D365 licensing model here.
• Post-ERP implementation: Implementing security post implementation might result in more licensing fees during the initial go-live. Depending on the size of the user base, this can add up quickly and offset any savings realised during the implementation. Although putting security on the back burner may help the overall ERP implementation cost and timeline, it may create increased costs for compliance to closely monitor and report against user’s out-of-box access.
  It is important to align with the implementation partner and team to understand which choice is right for each business. In either case, a custom security model is the best way to ensure the system is properly secured from segregation of duties risks.

Final considerations

Organisations looking for the segregation of duty risk and user licensing minimisation of custom security, but which do not have the necessary resources for a full design timeline as described in this post, may want to consider the D365FO Template Role offering from Protiviti. These template roles offer a great starting point in the custom security design journey and offer easy customisation to fit business needs.

To learn more about our Microsoft consulting solutions or a free solution demo, contact us.