A #GRC tool is just part of the solution
A discussion I had this morning with one of our IT senior managers served as a good wake-up call to me. We were talking about our organization’s strategic direction for SAP security, and the manager expressed a great deal of confidence that our deployment of SAP GRC 10.x was going to meet our organization’s compliance needs. I was glad to hear it, since our GRC Access Control 10.0 migration project is my primary focus this year; however, I also took the opportunity to mention that, as excited as I am about our migration project, any toolset is not the “end all and be all” of compliance. Deploying a new toolset is just the start; reviewing the security and compliance processes and governance model is equally important to ensure that the organization will get the full value from the GRC toolset implementation. If you, too, are deploying, or migrating to SAP GRC 10.x, here are some things to consider.
For starters, if Access Risk Analysis is in scope, the GRC toolset is only as good as its Segregation of Duties (SOD) ruleset. Has yours been maintained when SAP has released updates and when custom transactions are implemented? Any organization can be “clean” on SOD violations if the ruleset and risks matrix have not been maintained regularly on a timely basis. In addition, if you only have rules for your ECC system, it might be time to consider implementing rules for other connected systems as well.
Do you have a process and organization in place to review all custom transactions for SOD or sensitive access risks before SAP roles are updated? Does anyone sign off on the risks of new custom transactions before they are added to end user roles? Do you have a strong governance model for security role designs, or is it pretty much anything goes? Is there a designated person or committee with the authority to veto the addition of sensitive Basis transactions and authorizations into end user roles? The latest GRC toolset without a strong governance model may not be fulfilling the promise of its investment to the organization.
When was the last time your security role design was reviewed for alignment with the organization? Whether your roles are task-based, job role based, or a combination of the two, if they are not well aligned with the way the SAP users work, your end users may continue to struggle to identify the “right” roles, even with the improved access request user interface, and many more user access requests are likely to be processed, which is expensive both from a user downtime perspective and an administrative processing perspective. Business processes often change when new functionality is deployed; a review of the role designs and the risks should be part of that effort as well. Keeping your security role design aligned with the business processes is not something the GRC toolset will do for you, but it is an important part of the compliance picture to ensure that users have the right access to do their jobs. Getting HR engaged in the process can pay off in the long run with more quickly provisioned users, and who doesn’t want faster and better onboarding of new hires? Improve this process and you get to be the hero in your organization.
Getting the latest technology in GRC tools without a well-aligned supporting organization model and processes is a lot like a luxury sports car without a skilled driver and good roads to enable the car to run to its potential. Consider how your security processes and governance model can be updated to enable your SAP GRC 10.x toolset to deliver the best value to your organization.