Who Are You? And Should You Be Here?
The Segregation of Duties and the Common Misconception Surrounding Identity Management
It’s not the name of the role, it’s what the role can do!
Who does what? At the root, this is what segregation of duties (SoD) and identity management is all about. The roles assigned to the users in your business applications (ERP, HCM, CRM) determine what they can do within those applications. Unfortunately, many managers and system administrators assign roles to users based simply on the names of the roles without considering the actions those roles can actually perform within the application.
This can be a mistake.
The name assigned to a role does not necessarily accurately reflect the security objects that can be accessed within the role. A role with a name like “Accounts Payable Clerk – Read Only” would imply that any user assigned that role can only read (but not edit) Accounts Payable activity and nothing else. The reality is that the name given to a role does not have to match the privileges assigned to that role. In this example, there is nothing to say that the role named “Accounts Payable Clerk – Read Only” can’t also modify the General Ledger or create a new vendor. Only by looking at the security objects that can be modified within each role (create a vendor, edit GL) can managers properly analyze potential access violations and SoD conflicts within their business applications.
Another identity management issue faced by managers and administrators is the idea of cross-application SoD conflicts. The concept of Separation of Duties is that no one user should be able to perform both sides of a transaction without some oversight. But if a user can create a vendor in the CRM application and also pay that vendor from the ERP application, this represents an SoD conflict.
Actions Risk Managers Can Be Taking Right Now
If it hasn’t been done already, the most effective place to begin for identity management is perform a full risk assessment. Have the managers and administrators work with the risk management team to identify the high-risk activities in each department. Determine the actions each role can perform at a granular level and then identify which users should be assigned those roles.
Addressing the areas of highest risk first (large transactions, SoD violations, access and modification of critical data) will go a long way to help secure your organization from internal fraud in the short term. These teams can continue to refine the process, offering better security over time. However, it is best to introduce security measures from the top down incrementally rather than waiting to fix every security issue all at once.
Changes Needed in Your Risk Manager’s Identity Management Processes
Many employees, if asked, would say that the system integrator or the IT department is responsible for setting up and administering the security for all the business application and integrations. The fact is nobody knows the access and risk factors in a role better than the managers or process owners responsible for assigning those roles to their staff. These individuals should work closely with the system integrators, the IT department, and the internal auditors to establish the type of access assigned to each employee along with the monitoring and mitigating controls that will ensure a secure user environment.
Find out more about designing and implementing access control solutions across multiple systems. Download a free copy of Fastpath’s Managing Risk & Discovering Value with Fastpath During an ERP Implementation or Upgrade.
Contact ArcherPoint to discuss your identity management concerns and needs.