As it relates to security practices, businesses tend to implement one of two security models. The most commonly used is a Job-Based Model. In these types of security models, roles are built based on the job a person has or a job description the company creates (i.e. AP Clerk). The other security model, one we consider best practice, is known as a Business Process-Based Model. In this model, roles are created based on the individual business processes a company performs on a daily, monthly, or quarterly basis. For instance, Accounts Payable Voucher Entry and Voucher Payment are two separate processes under the Business Process-Based Model and therefore would be two separate roles. However, under the Job-Based Model these processes would most likely fall under the same role.
Job-Based Security Models:
Job-based roles may be one of the most commonly used security models, however not necessarily the best. Under this security model, access is given to users based on their job description. However, job descriptions may not entail all processes a given user may need. See example below of just a couple issues that could (most likely) arise under this model.
John Doe is in the Accounts Payable department and has the role APCLRK (Accounts Payable Clerk) assigned to his user ID. This role has access to perform Voucher Entries, Voucher Matching, Voucher Payments and Period Processes. Jane Smith is hired to be an additional AP Clerk resource. However, Jane will only be performing the Voucher Entries and Periodic Processes.
The problem lies in that only one APCLRK role exists. If Jane is given APCLRK, she will inherit the Voucher Matching and Voucher Payment processes as well. This may result in a Segregation of Duties (SoD) violations on the audit report. In order for Jane to get the access she needs and not have SoD violations; a new role would need to be created to only grant Jane the access she needs.
This was an example for only 2 users within the same department that needed similar (but not exact) access. If you are a growing or already large company, this issue can become an unwanted trend in how you grant and differentiate access to users.
Process-Based Security Models:
Process-Based models typically handle the concerns with Job-Based roles fairly well. Under this model, roles are created by individual business processes. For instance, sticking with AP, Voucher Entry, Voucher Matching and Voucher Payment would all be separate roles in the system. The main benefit to this model is being able to assign users the access they need, without granting extra access. See example below.
John Smith is the AP Clerk for his company and has the ability to perform Voucher Entries, Voucher Matching, Voucher Payments and Periodic Processes. Due to recent growth, an additional resource is needed for the workload. Jane Doe is hired as an AP Clerk to work with John. However, Jane only needs access to perform Voucher Entries and Periodic Processes. With this hire, John will no longer perform these processes.
Under Process-Based models, this type of change request would not require additional setup in the system for access to be granted correctly. John would have the Voucher Entry and Periodic Processes roles removed from his user ID. Jane would have both of them added. No new roles need to be created, tested, approved and deployed to Production in order for this request to be completed and business to continue.
In closing, both Job-Based and Process-Based Models can be efficient and effective security models. In our experience, the time and maintenance spent on a Business Process-Based model vs a Job-Based model is significantly less. This leads to easier security management, faster resolution time of requests and typically a cleaner SoD report for auditors.
If you have any questions or would like more information on how the GSI Security Team can assist you in any way, please don’t hesitate to contact us.