Segregation of Duties Mitigation Options for Dynamics GP

Posted by Mark Polino

risk mitigation logo.jpgIdeally, a well-designed security setup should be all that’s needed to properly segregate duties in any ERP system, but the real world never works that way. Regardless of which ERP system is being used, perfect separations of duties (SOD) can be expensive, impractical, and inefficient. Typically, companies should make a concerted effort to apply segregation of duties based on the organization’s identified risks and then apply mitigating controls when security setup alone is insufficient.

 

Dynamics GP provides several features that can be used to deliver mitigating controls. Here is an overview of the most commonly used features for mitigations.

 

  • Workflow 2.0 – Dynamics GP’s Workflow 2.0 feature provide approval workflow functionality for transactions and master record setup. This a great way to add workflow based approvals as compensating control.
  • Posting Approval – Prior to Workflow 2.0, posting approval was the only built-in option for approvals. This feature continues to work, but it uses a shared password so care should be taken with password management. Posting approval applied to the GL can also be cumbersome, because all posting to the GL, even from subledgers, will stop for approval.
  • System Password – The system password functions as an additional control for sensitive areas. Users who are granted access via security still need the System Password to access certain windows in GP. There is a single System Password shared among users. Consequently, this control functions more like a double check that security access was appropriately granted.
  • Functional Passwords – Like Posting Approval, GP provides functional passwords throughout the system for activities like overriding credit holds, exceeding maximum write-offs, and many other functions. Functional passwords are shared, there is one password per function, so care should be taken in managing these passwords.
  • Field Level Security – Field Level Security lets an administrator design additional security for specific windows including locking fields and password protecting specific fields. Because field level controls are designed separately from GP security, auditors will typically want to do additional testing on these controls. Field Level Security passwords are shared passwords as well.
  • Numbering – GP provides audit numbering to assist with tracing transactions through the subledgers as well as an option for gapless numbering of GL transactions if required.

This list is a subset of common control elements. For real control of segregation of duties in Dynamics GP, the best option is Fastpath Assure. Assure’s built in list of SOD conflicts is tuned for Dynamics GP and can identify hundreds of potential conflicts out of the box. This is incredibly useful in fine tuning security and identifying mitigation options.

 

When discussing mitigating controls, Dynamics GP’s Activity Tracking feature is commonly mentioned. Activity Tracking can be useful for tracking logins and logouts, but it’s not particularly helpful beyond that. Activity Tracking only identifies that a record was changed, with no indication of the actual information that was changed. Knowing that someone changed something on vendor record isn’t a control mechanism.

 

For true Audit Trail tracking in Dynamics GP, Fastpath Audit Trail is the right solution. Audit Trail provides SQL level tracking of changes in GP including the original value and changed value for tracked field. Audit Trail records are commonly used as mitigation options for post transaction review.

 

Dynamics GP has a great built in security model, and it includes some nice mitigation options for those times when security just can’t get the job done by itself. Often, it takes creativity to build a robust security fabric.

 

The mitigations options discussed here are covered in detail in the upcoming book ‘Microsoft Dynamics GP Security and Audit Field Manual’ due early fall 2017.