As the Director of Service Delivery for a mid-sized manufacturing company based in the US, my scope of responsibility encompasses traditional Service Transition, Service Operations and Access Management. Like many companies utilizing a broad ERP solution such as SAP, our approach to user access control tended towards convenience and reactionary response, growing organically rather than through a disciplined process aided by an advanced access control tool. After several years in this mode, we realized that we needed a more disciplined and sustainable solution, finally landing on SAP’s GRC tool.
We began implementing SAP’s R3 ERP solution in 2009, rolling out major functional components such as Human Resources, Sales and Distribution, Material Management, Demand Planning, Finance, Cost Accounting, Plant Maintenance, and several others. Our goal was to homogenize primarily on the SAP platform and capitalize on its robust suite of functionality. Having previously implemented SAP, I was put in a leadership role on the Application side of the house with additional responsibilities that extended into programming (ABAP) and system administration (Basis).Access Management for SAP was on the Infrastructure side of our IT department, and I was only minimally aware of their activities.
With the rollout of each component, we developed or enhanced individual user access rather than developing common User Roles, or more over, Business Roles. While this approach was labor intensive, it ensured that we did not hinder the business from executing their duties which resonated well with our 24/7 production facilities. Approval for individual access requests was handled via email to IT management and a limited number of business area owners. Further, we maintained robust audit reports that served as a mitigation buffer for specific areas that had inherent risk. Frankly, lacking an access control tool to allow effective monitoring and analytics, this methodology felt like our most viable option.
In 2018 we re-evaluated our processes regarding user access provisioning and recognized that it was not the most effective, efficient or sustainable method to handle this important task. We knew that we also needed an automated, auditable and workflow-controlled method to grant one-time access needs, such as those requested for emergencies and initial go-lives. We kicked off a project to evaluate available tools that satisfied our needs and worked well with the SAP platform, eventually landing on the SAP GRC Access Control solution.
Initially, we engaged a consulting firm specializing in SAP GRC to help us implement the components, which we limited to Access Risk Analysis, Access Request Management, Business Role Management, SOD (Separation of Duties) Management, and Emergency Access Management. Our first phase focused on Access Risk Analysis with an approach that veered away from the pre-configured solution inherent in GRC in favor of a highly customized model. The project began in earnest but lost momentum over time as resources changed and priorities shifted. Since we had not experienced an authority breach within our user base, there was little urgency for implementation.
Over time it became all too apparent that our decision to customize SAP GRC to closely model our company’s business structure was not the most efficient option. Our progress was slow, upgrades were made much more difficult, and any consulting specialists we brought in were rendered ineffective due to the unique configuration of our solution.
Our second shortcoming was failing to engage the Business Process Owners in a significant way. From a RACI standpoint they were “informed” rather than “accountable,” and when the inevitable audit came around there was little support or ownership. At this point, we were roughly two years into the project and had only addressed Human Resources and part of our Finance group.
This is about the time I came into the picture. Reassigned from the Application side of our IT department to Infrastructure, part of my new remit was the Access Management function, staffed by the SAP Security Team, tasked with the aforementioned SAP GRC Project. After a few months of familiarizing myself with the project’s history and status, the difficult decision was made to essentially start over and refresh our SAP GRC instance with the latest version and return to a standard configuration.
Along with this system reset, we created a business-owned GRC Governance Committee to oversee our activities and generate buy-in from the Business Process Owners, effectively handing over ownership of the SAP GRC Project. Our plan of attack had us addressing SOD (Separation of Duty) violations within each User Role, and we were able to eliminate virtually all SOD-based risks in those roles. In conjunction with this activity, we enabled the SAP GRC Firefighter process, which is an Emergency Access Management function with built-in workflow for approval, logging and auditing that enabled us to move risk-related activities outside of the User Roles.
Subsequent to the User Role redesign, we are now developing Business Roles that will allow us to abandon our current process of “mirroring” users when granting access which has historically overprovisioned the recipient. Our approach is to analyze actual activity in production and capture the most common and frequently executed activities in the role. The rest will be considered for individual user assignment or Firefighter delegation. Once complete, we will revisit the remaining risks and look for Remediation opportunities or Mitigation options.
Though it has been a long and circuitous road, we have learned a great deal and developed the internal expertise to enable us to capitalize on the functionality that SAP has provided in their GRC tool. With the culmination of this project, we will have significantly reduced our access risk profile while empowering our SAP Security team to provision access with a more simple and supportable process that undoubtedly will score well with our auditors.
