Arbela Blog
Back to Blog Index

Security Checklist – Implementing Dynamics AX

Written by Cody Bess, Functional Consultant, Arbela Technologies

With everything that you need to implement AX 2012, one of the last things in the list (and on your mind) when you manage a sprawling team of developers, process owners, domain experts, third party vendors and functional consultants is AX security. Most people still believe that you can leave security to the end of a project cycle and still have a complete and successful implementation. This dream is shattered the first time a user unwittingly changes a sensitive configuration, which could take a live environment offline to quarantine, investigate, and correct the problem. Even worse, a resentful employee can make off with trade secrets, write a check to him/herself and cover the tracks, misrepresent inventory quantities, or otherwise disrupt the flow of business. Surely, IT risk management and data governance programs in place could prevent many of these issues, but for this post, we’d like to focus on a specific source of the problem – failure to consider security as a natural and important part of your Dynamics AX implementation.

Below is a quick checklist, in the form of a short questionnaire, that should get you started on the right path to making sure that your implementation of Dynamics AX is successful, from a security standpoint.

  1. Resources
    1. Are your developers well versed in application security model in AX 2012, and are comfortable creating roles, duties, privileges, XDS policies, and controls?
    2. Have you identified process owners for security implementation?
    3. Do you have internal controls, business process restrictions, and segregation of duties in place that would mandate custom security for compliance?
    4. Has a collaborative pathway (or a team) been established between team members to communicate security requirements per business area?
    5. Are security access requirements collected in your discovery and design phases?
    6. Is your security access going to be locally or globally assigned to users?
    7. Are the project sponsors on board with the security planning?
  2. Development
    1. Are there security objects (Roles, duties, and privileges) created for access to third party modules and functions in AX?
    2. Are your developers creating duties and privileges for custom developments that they create?
    3. Are the instructions for these duties and privileges included in the functional design documents (FDDs)?
    4. Are custom duties and privileges tested for sufficiency before qualifying the customizations?
  3. User Testing
    1. Has a segment of user acceptance testing been dedicated to qualifying their user role assignments?
    2. If users request security changes during testing, are you requiring them to submit a use case to support the request?
  4. Go-Live (And Beyond)
    1. Are your implementation team members’ access to Dev, master, and test environments re-evaluated after going live?
    2. Do you have a ticketing system in place to maintain user access requests?
    3. Do you have a standard approach for assigning a core security stack to new hires based on job title, description, billet, or other standard job requirements?
    4. Do you have a standard approach for changing security role assignments for employee transfers, terminations, temps, and rehires?
    5. Are you actively monitoring user – role assignments for overarching access?
    6. Is security a part of your disaster recovery plans?
    7. Do you have a plan in place for assigning system administrators and system admin delegates?

The moral of the story is – you will have real cyber security concerns after go-live that will consume some of your attention. Do not let AX security access become one of them, and a bit of planning can prevent this. A firm “no” to any of these questions above indicate that you may have a difficult time going live and may have to abandon standard role assignments just to get the business up and running (on sys admin users or a massive stack of roles). An unconfident “maybe” or “not sure” to any of the above questions may require intervention or at the very least, a second look at the project plan.