Organizations at risk
Every organization has to deal with the risk that staff might be able to undertake fraudulent actions whilst at work. This can be actions like direct theft, paying out fake invoices, paying out actual invoices to “wrong” bank accounts. But as mankind is creative there are lots of other cases known where employees took advantage of there employers in an illegal way. In order to assess these risks and to decrease these risks financial auditors check work processes and to what extent they contain risks at fraudulent actions and advice companies how to improve their work processes in this area. As work processes are nowadays often supported by (ERP) software the audit performed usually extends to the way work processes are configured in this software. As Dynamics AX is also used to support work processes often configuration of Dynamics AX is checked by and commented on by financial auditors.
Financial auditor at work
As financial auditors not only check the financial well being of an organization but also check the administrative organization and the way an organization has guarded itself to prevent fraudulent actions of its staff and to what extent risks are present in the way work processes are configured in Dynamics AX. Given this, financial auditors will check the configuration of security roles of Dynamics AX in an organization and will pose questions in what way this configuration helps to prevent fraudulent actions of staff. Usually employees of Financial or Accounting department(s) will receive these questions. Segregation of Duties is in common part of the answer to such questions.
Often also an authorization matrix is present in an organization. This will of course also periodically be audited by the financial auditor. The financial auditor will have a look at the way security roles are set up and to what extent they are covered by the authorization matrix and to what extent they are in line. This also helps them to get an idea if a Segregation of Duties is in place at an organization.
Apart from security roles usually at organizations there are also mandates in place. Usually they are used in workflows in order to establish who has to approve a purchase order or a received invoice. The financial auditor will for this reason also have a look at the way workflows are setup in order to determine if mandates are properly used.
Financial auditors, especially working at larger accounting firms, often have a keen eye for users with Administrative access rights. These access rights are not only handed out to actual users, like system administrators and application managers but also to service accounts. This will lead to questions like why has helpdesk employee X an administrative like account in AX, why has interface Y an administrative like account in AX. As it turns out in these cases is it not always necessary to grant these administrative rights. So in order to avoid to answer these ackward questions, it is better to create roles that exactly grant what is necessary to perform tasks at hand.
Security roles and Segregation of Duties
The above questions posed by Financial Auditors can usually be answered by showing an overview of roles assigned to users. With some effort these data can be retrieved from Dynamics AX.
When must be demonstrated in Dynamics AX how a Segregation of Duties is achieved it gets more troublesome. Not only are employees of Financial or Accounting departement(s) in common not the people that have setup the security roles in Dynamics AX but also it is difficult to exactly demonstrate in what way the setup of security roles helps to minimize the risk on fraudulent actions. Just showing the content of a role on a form is insufficient and doesn’t prove that the setup was exactly the same during the fiscal year that is audited. Even additional logging on various tables like vendor bank accounts is just additional evidence, but not conclusive evidence.
When a Segregation of Duties has to be demonstrated to a Financial Auditor one has to bear in mind that in general there are two approaches to setup security in Dynamics AX:
- Grant more than sufficient access rights to roles to perform their activities (overgranting)
- Usually there are a limited amount of roles containing lots of duties or sub-roles
- Users have often just one role
- Specific privileges are not often used
- Users don’t ask or just in few cases for more access rights after start of configuration; when this happens this is often resolved by granting a role containing even more access rights
- Grant just enough access rights to perform their activities (undergranting)
- Usually there are various roles containing some duties and privileges
- Users have often multiple roles
- Specific privileges are regularly used
- Users ask frequently for more access rights after start of configuration, this is often resolved by adding one or a few privilege(s) to a role or create a new role with limited access rights and add this new role as a sub-role.
Both approaches have their pro’s and con’s. In case of overgranting business processes won’t stop, but there is a risk that the scale of the access rights of the available roles is too large in order to speak of roles that support Segregation of Duties. There are cases known that warehouse workers were allowed to post packing slips, change addresses and could create sales invoices as well. This is very usefull to speed up a business process, but is of course quite tricky from a Segregation of Duties point of view.
In case of undergranting there is a risk that if a business process is not completely tested, especially when only the happy flow is tested, a business process can’t be completed. As more roles are necessary to complete a business process this means that more cooperation between Dynamics AX users is necessary, unless users get several roles assigned (that can lead to the same effect as overgranting). Undergranting leading to problems with completing business processes can easily arise when workflows are used. At a customer where security roles with limited access rights where used workflows stopped due to insufficient access rights, so some vendors couldn’t get paid in a normal way because invoices couldn’t be processed in case of a mismatch between invoice and purchase order (for the handling of mismatches a separate sub workflow was used) or due to missing date necessary to assing a workflow step properly (in the past when a lot of access rights were granted such data could easily be corrected, but in the new situation that was not possible anymore).
As one might understand already from a Segregation of Duty point of view undergranting is the approach that helps best to be in control, but it also implies that business processes must be tested more thoroughly, especially the way exceptions or data errors are handled. This is even more important when workflows are used.
In real live it can also occurr that an organization starts with one approach (overgranting) and switches to another approach (undergranting). This can lead to all kinds of complaints of users that they can’t do their work anymore. When the switch is made from undergranting to overgranting usually there are no complaints of users, but controllers and financial auditors are usually not very fond of such a switch as they increase the risk that fraudulent actions can be undertaken. So in general such a switch is quite uncommon.
Another consideration is that standard AX roles are not (all) created to support an organization where Segregation of Duties is vital. A lot of standard roles contain access rights to both Inbound and Outbound activities. Usually this is something that financial auditors disapprove of, so a proper setup of security roles involved leads in a lot of cases to the creation of new roles where inbound and outbound duties are split or even to splitting duties that contain too many access rights. In various cases it might even be necessary to create additional duties and privileges in order to achieve a proper Segregation of Duties.
Segregation of Duties in AX
In order to ensure that the setup of security in AX is compliant with Segregation of Duties as the organization it intents, adviced or not by the financial auditor, it is possible to actually configure a Segregation of Duties in AX. In the module System administration (system administration – setup – security – segregation of duties) is a form present where the Segregation of Duties can be setup. In this form the Segregation of Duties rules can be defined.
Access to this to functionality is controlled by the privilege SysSecSegregationOfDutiesMaintain which is part of the standard Security Administrator role. So according to Microsoft the setup of the Segregation of Duties should be performed by an AX Security Administrator. But given his or her IT background the setup of these Segregation of Duty rules can’t be done by by a AX Security Administrator alone. Usually input from the Financial Department is necessary as this department is usually responsible for internal control and auditing, so Segregation of Duties is their cup of tea. So what often can be noticed is that Segregation of Duties is setup and maintained as a result of close cooperation of Financial and IT department. This is even more true as the setup of security roles is an activity where the AOT and security development tool of Dynamics AX are used, these are usually the play ground of the IT department, but they lack usually the business insight necessary to establish a proper Segregation of Duties.
As mentioned the term used is Segregation of Duties. This means exactly what it says only a Segregation of Duties can be configured in Dynamics AX. Where-as in Dynamics AX in the end access to entry points (menu-items) is controlled by privileges it is not possible to configure a Segregation of Duty rule based on privileges, this can only de done on duty level. The standard roles present in Dynamics AX are setup in order to ensure that business processes of organizations are supported, however these roles are not always (or one could say quite often) not compliant with requirements that a proper Segregation of Duties demands. In these cases an additional Duty has to be created (it can be useful to name these SoD_XXXXX, so it is clear that these duties are specifically created for Segregation of Duties purposes).