- 5 Posts
- 164 Views
Hi - I'm throwing out a question to the PeopleSoft Financials community about the best practice or their method of faciliating a business review of PeopleSoft permission lists and roles. We have not established a timetable for how often this review is done, but right now, I'm trying to determine if there is a better way to review the access rather than walking through a role page by page in a production-like environment using a user profile that contains only the role being reviewed. It is a tedious process, and I have considered providing queries that show access and control levels on each page - but it can be very cryptic.
Does anybody have a process that works well for them? Is anybody having their business teams perform this review?
We dump the security tables into a tool called Governance Minder that we use for security reviews by the business for other software reviews. We made sure we input a good long description on the role in order to facilitate this review. The business managers are then responsible for reviewing and approving each person that reports to them on a quarterly basis that they have the appropriate roles. Additionally I review quarterly a subset of the roles to ensure there are no segregation of duty issues and the roles are appropriately assigned as I am the official system owner of all PeopleSoft modules. I also review on a quarterly basis any changes to roles/permission lists. I do all of my reviews through queries.
At my old company, we had to review the roles and permission lists with our audit and financial compliance group yearly. We were a business functional group. My AP expert kept an excel spreadsheet of the AP roles, what permissions they had (update, read, no access). We then married that excel sheet with a report from our IT security team which told us who (by userid), had those roles. We then had a macro created which attached the HR data to obtain the person’s manager and then had each manager reapprove their persons access. It was involved but over time we automated as much as we could by using both business functional people and IT people.
I write a query of the People and roles, making sure the Role Descriptions adequaetly describe the access that the Role has. Next do a pivot table of the data showing the People in the the rows and the Roles in the Columns. It needs to be filtered by the area or department, so you have to determine a way to include that information in the data. One way to do this is to name all of your Roles by module like XX_AP, XX_GL, XX_PO where XX is your company identifier and the next two Characters are the module. this way you can create a separate pivot table for GL, AP, Purchasing, etc.
Application security…one of my favorite topics!
Quarterly reviews tend to be a typical standard for a business review. That is what I've followed for every ERP application and has held up to auditor scrutiny thus far. The trick is to keep it a manageable size so that the business review is timely, balancing the burden on management while still being an effective control. One of the best practices is to establish access standards by job code and use dynamic assignment to provision those roles by job code. Dynamic assignment strengthens the control environment and lets auditors perform more testing of the preventative, system controls rather than the manual detective control of a periodic review. In fact, when we perform quarterly reviews, we do not require management to review the dynamically assigned roles because they are provisioned according to defined business rules rather than subjective ad-hoc requests.
Another practice to help manage the burden of management review is to make the first quarterly review of the year a full certification, in other words managers review all static assigned roles for all users under their management. Each subsequent quarter the only user roles reviewed are new assignments since the previous quarter. In other words, only the changes since the annual full certification are reviewed in quarters 2-4. There are certain roles that should be flagged as "sensitive" requiring specialized reviews. These are roles used for system administration/configuration. These are always reviewed every quarter by key IT or business managers. Additionally, we have logging enabled on security tables so that we can automatically detect whether a user has modified their own access which could potentially be a violation of a key segregation of duties control over the entire process of provisioning access.
Annette makes a great point about GRC applications. They can be very helpful in terms of reviewing for segregation of duties. Once certain roles, permissions, pages, etc. are defined as conflicting combinations, the user role assignments can be objectively compared to the rule set rather than subjectively reviewed by a manager. I've also used GRC application as a library to document what is an effective mitigating control for potential access conflicts as well as a repository for retaining evidence of performing these mitigating controls for detected conflicts.