SAP® GRC Access Control Implementation at a Leading Client in the Audiovisual Sector

In this case study, we will discuss the implementation of the SAP® GRC Access Control tool, marking the ninth SAP® GRC Access Control implementation carried out by Inprosec across all its clients. This implementation completed the client’s use of all SAP® GRC tools, with a project duration of 14 months, starting in November 2021 and concluding in December 2022.

The client in question is a leading group in the European audiovisual sector, unique in content integration, production, and audiovisual distribution. It provides the creativity and technical solutions needed to design, produce, and distribute any audiovisual or multi-channel project.

The challenge

Although we started with a slight advantage, as the client’s organization already used the main GRC modules (PC – Process Controls, RM – Risk Management, and AM – Audit Management), the project had its difficulties, which could be divided into several sections:

• User Interface for GRC Access: Although it was mentioned at the beginning of this section that the client was already using SAP® GRC, it was through the NWBC (Netweaver Business Client) user interface. One of the project’s objectives was to stop using this somewhat outdated interface and start using the Fiori Portal, thus improving the user experience and enabling GRC use on different devices.
• Emergency Access Management: The concept of emergency users had not been used before, making the definition of this type of access complex. Nevertheless, a simple strategy was chosen, generating access aligned with the most significant business and IT access risks for the organization.
• Access Risk Management: Although there was no proprietary access matrix, the client already used SAP®’s standard risk matrix for reengineering their role model, so we weren’t starting from scratch. The complexity came more from the valuation and identification of key access risks and the analysis of the large number of custom Z transactions (> 1.6K) and custom business UI5 applications.
• User Provisioning Processes: The greatest difficulty was adapting the user management process, where, in addition to the technological change, functional changes had to be made. The management process was entirely manual, managed by 2 service levels, with numerous stages, and supported by a ticketing tool (JIRA) and the use of email to obtain the necessary approvals.

In addition to the aforementioned, the project had to adapt to changes not initially anticipated, the most important of which are listed below:

• Migration of the SAP® GRC system (On-Premise –> Cloud (RISE)): As part of the organization’s strategy, at the beginning of the project, the decision was made to migrate the GRC system to a cloud environment. This strategic change delayed the availability of the new SAP® GRC system by 5 months.
• Key Changes in Organizational Structure: At the beginning of the project, we worked closely with the Security Area, which was the main authority with which the process designs were defined and validated. This department underwent changes, requiring the review and updating of the already approved user management flow designs.
• Integration of SAP® GRC Access Controls with Identity Manager (One Identity – OI): One of the project’s objectives was the integration between One Identity and GRC Access Controls. This strategic objective required adapting the designs of the user approval flows and the GRC form, extending the acceptance process. Finally, this integration had to be separated from the GRC AC implementation project into a parallel project, but the design requirements were maintained; GRC AC could only go into production if it remained adaptable to integration with OI.

Having understood all the challenges presented, the next section will outline how they were addressed and the milestones achieved in each phase.

Inprosec solution

The project proposed by Inprosec sought a phased solution, with a plan aligned with the previously described difficulties.

The duration of each of the phases described below was estimated at 2.5 months, with a total duration of 6 months, but it had to be extended to 14 months to adapt to the problems encountered during execution.

Phase 1 – Implementation of GRC EAM (Emergency Access Management):

• Definition – IT and business emergency access based on roles following best practices. IT roles were generated based on a best practices model, which the client could then reuse for the proper management of the minimum privilege when assigning IT access.
• Responsibles – Specific log approvers and reviewers were defined by process: IT, Finance, HR, and BW.
• Approval Flows (x3):
  1. Creation/modification of access
  2. Access approval
  3. Log review

Phase 2 – Implementation of GRC ARA (Access Risk Analysis):

• Business Matrix – Definition starting from the standard recommended by SAP®, including relevant risks derived from the analysis of the 1,600 existing Z transactions in the ECC system
  • UI5 applications were analyzed, but ultimately could not be included due to their high degree of customization.
• IT Matrix – The internal risk matrix of Inprosec was used as a basis, aligning it with the latest report from the client’s external auditors.
• Risk Levels – Aligned with the internal risk management policy (Marginal, Mild, Moderate, Severe, Very severe, and Critical)
• Risk Responsibles – By process: IT, Finance, HR, and BW.
• Approval Flows (x2):
  1. Creation/modification of risks
  2. Creation/modification of roles/functions

Phase 3 – Implementation of GRC ARM (Access Request Management):

• Process Definition – Considering the current situation and the possibility of integration with One Identity and the use of SSO (Single Sign-On).
• User Database – SAP® HR (HCM), an active module within the SAP ECC system.
• Unique Identifier – Throughout the project, the automatic and controlled creation of the SAP® User ID (infotype 0105) was requested as a unique identifier for users in the SAP® systems, this was a significant improvement in identity management resulting from the implementation project.
• Job Positions – The use of job positions was enabled (using the “Function” field to link it with composite roles) to facilitate provisioning.
• Custom Fields – Certain custom fields were configured to facilitate integration with JIRA (ticketing tool) and One Identity: ticket number, licenses, additional companies, and reference user.
• Approval Flows (x5):
  1. Creation
  2. Modification
  3. Locking and Unlocking
  4. Deletion

Accompanying the previously mentioned phases, roles that provided access to the various Fiori applications on the Portal were designed and validated, generating the following main roles:

• Firefighter ID
• EAM Requester
• Owner and Reviewer
• GRC Requester
• Management Administrator
• EAM Reports Viewer
• ARA Reports Viewer
• Risk Analysis Executor
• BRM Reports Viewer
• ARM Reports Viewer

This segregation allowed the client to assign roles based on each user’s position within the GRC AC process management.

Finally, as documentary support for the project, the following 3 types of documents were generated:

• Process document: It described the design of the processes for each module, the flow diagrams with their main activities, and the associated RACI matrix. Additionally, at the request of the Internal Control area, control points were included within each process to become part of the internal control matrix with the objective of periodically validating that the defined processes were being executed as had been defined.
• Technical design: It contained the technical details of the implementation to make the client and its GRC technical team independent in maintenance after deployment and the completion of the PGLS period.
• Training and usage manuals: It described the main functions of the roles defined within each process, with simulated examples (cases) to facilitate the understanding of the tool and knowledge transfer if necessary.

Throughout this process, the significant support received from the Internal Control, IT, and SAP® GRC departments was key and identified as a positive lesson learned, being crucial their involvement in the design, UAT testing, production rollout of each module, and change management to handle the end-user’s expectations and resistance to changes resulting from the project.

Results

The implementation of GRC Access Controls brought numerous benefits to the client’s organization, summarized below by relating them to each module:

EAM – Emergency User Management

• • Enabled monitoring of the use of critical accesses (IT/Business) in production environments, thereby reducing the risk levels of this type of access in production environments.
  • Remediation of audit deficiencies (e.g., debug access in IT users).
  • Improved visibility of business process issues during emergency access log reviews.

ARA – Access Risk Management

• • Increased visibility of the status of access risks in SAP® systems to prioritize risk reduction plans.
  • Enabled preventive and real-time monitoring of the risk level before creating accounts in SAP®, involving process owners (integration with approval flows).
  • Enabled risk simulations for access changes to support the client’s role model redesign projects.
  • Introduced control over access risks in existing Z transactions.

ARM – User Provisioning Flows

• • Simplification and centralization of user management process activities: fewer involved groups, reduction of errors, and a unified tool.
  • Automation of user access management processes, reducing request processing times.
  • Increased control in access assignment by involving access and risk approvers within the approval flow.
  • Improved traceability of user changes, moving from maintaining evidence in various places (email and ticket management tool) to everything being available in the SAP® GRC AC audit log.

In conclusion, it’s important to highlight that the main objective was always to improve the client’s user and access management processes, maximizing the use of SAP® GRC AC’s standard functionalities, thus avoiding customized processes that would make tool maintenance and future change management difficult.