SAP GRC

GRC helps organisations control access and comply with regulations: Access Control analyses and prevents segregation-of-duties conflicts, manages access requests and role design, and controls emergency (firefighter) access; other components manage risk, process controls and audit.

Worth being clear about scope, because the name is broad. GRC as a product family is not one system: it is several capabilities sharing a platform, and a client saying they have GRC usually means Access Control. Establishing which capabilities are actually licensed and implemented is the first question on any engagement.

• Access Control: SoD analysis, access request, role management, firefighter.
• Process Control: internal controls monitoring.
• Risk Management.
• Audit Management.

GRC is several products and when somebody says GRC they usually mean Access Control, so it is worth knowing its four parts by what they do.

Access Risk Analysis is the core. A ruleset defines conflicting combinations, such as creating a vendor and paying one, and the tool evaluates every user and every role against it. The output is a list of violations with names, which is what an auditor asks for and what a spreadsheet cannot produce across hundreds of roles.

Access Request Management replaces the email-and-ticket route to getting access. A request is raised, risk analysis runs on the proposed access before approval, and the approver sees the conflicts they would be creating. That preventive check is the single most valuable thing here.

Business Role Management governs the role lifecycle: designing, changing and certifying roles, with the risk analysis built in.

Emergency Access Management, usually called firefighter, grants elevated access temporarily, logs everything done with it, and routes that log to somebody to review. It is what allows nobody to hold permanent excess privilege.

The pattern across all four: turn a periodic clean-up exercise into a control that operates at the moment access is granted.

Every capability above depends on a ruleset, and building or adopting one is where GRC projects consume their time.

A ruleset defines functions, groups of transactions and authorisation objects that represent a business capability such as maintaining a vendor. It then defines risks as conflicting pairs of functions, with a severity.

SAP ships a standard ruleset, and it is generic. It contains risks that do not apply to a given business and misses ones that do, particularly where custom transactions exist. A custom transaction doing something sensitive is invisible to a ruleset that has never heard of it.

So the work is: adopt the standard, remove what does not apply, add the custom transactions to the right functions, and get the business to agree that each remaining risk is genuinely a risk. That last step needs process owners rather than security people, and it is where the schedule goes.

The output nobody expects is that the first full run produces thousands of violations, most of which have existed for years. Deciding what to remediate, what to mitigate with a compensating control and what to accept is a programme rather than a task.

GRC integrates with the SAP systems whose access it governs (and increasingly beyond SAP), automating the SoD and access controls that would otherwise be manual. It is essential for audit and compliance (e.g. SOX) and a strong security-adjacent specialisation.

Technically it sits alongside the systems it governs, connected by RFC, reading their users, roles and authorisations. That means it can analyse several systems at once, which is the point in a landscape with more than one. It also means the connections and the data extraction are part of the implementation, and a system not connected is a system not analysed. See MDG for the equivalent governance idea applied to master data.

Learn GRC through its core processes, its master data and configuration, and its integration with the rest of the SAP landscape. Hands-on practice cements it.

Access Control dominates GRC conversations and the suite carries other capabilities worth being able to name.

Process Control manages internal controls: documenting them, scheduling their performance, collecting evidence and tracking failures. Where a business is subject to financial controls regulation, this is what turns a spreadsheet of controls into something with owners, dates and an audit trail. It also supports automated control testing, where the system checks a condition rather than a person confirming they looked.

Risk Management maintains a risk register: identifying risks, assessing likelihood and impact, recording responses and monitoring indicators. It is the enterprise risk discipline rather than an IT one, and it is usually owned outside IT.

Audit Management plans and runs internal audits, tracking findings to closure.

Trade and customs capabilities sit under the same umbrella in some landscapes, covering sanctioned party screening and export controls.

The pattern is the same as Access Control: take something a business does in documents and give it structure, ownership and evidence. And the same caution applies, which is that the tool records the control and does not perform it.

• Which capability first. Access risk analysis, because it tells you the size of the problem before you commit to fixing it. Request management next, because it stops new violations while remediation runs.
• Standard ruleset or custom. Start from standard and adapt. Building one from nothing is months, and the standard one carries the risks auditors expect to see.
• Remediate or mitigate. Fixing roles is the real answer and it is slow. Compensating controls are legitimate where the conflict cannot be removed and are a filing exercise when applied wholesale.
• Who owns the risks. Process owners in the business, not security, because a risk nobody in the business has agreed to is a finding nobody will act on.

Emergency access is the capability people meet first because it changes daily life, and the mechanism is worth understanding.

A firefighter ID is an account holding the elevated access. An owner decides who may use it and a controller reviews what was done. A user requests it, uses it for a bounded period, and every action taken is logged.

Two models exist. In the ID-based model the user logs in as the firefighter ID, so the audit trail sits against that ID and against the request that assigned it. In the role-based model the elevated role is temporarily added to the user's own account, so the log is against them directly.

The value is entirely in the review. A controller receiving the log and confirming the actions were appropriate is the control; a log generated and never opened is a record of what somebody did with unlimited access, filed.

The failure mode to watch for is firefighter access becoming routine. When a role is so restrictive that people use emergency access weekly, the role is wrong and the emergency mechanism has quietly become the normal one.

• Learning features, not the end-to-end process.
• Ignoring integration with finance and neighbouring areas.
• Skipping master data/configuration the process depends on.

• Implementing the tool before agreeing the ruleset. It then reports risks nobody has accepted as risks, and the output is ignored.
• Mitigating everything rather than remediating. A compensating control on hundreds of conflicts is a filing exercise; fixing the roles is the actual answer.
• Firefighter logs never reviewed. See HCM, IBP and MM for modules whose access is typically in scope.

• Buying GRC to satisfy an audit finding. The tool records and analyses; the finding is closed by changing the roles, and a tool with nobody remediating produces better documentation of the same problem.
• Connecting only production. Access granted in a development system with a copy of production data is access to that data.

Running a risk analysis is straightforward, and building a ruleset the business agrees with and remediating what it finds is the part you do in the course.

The sequence that works: analyse first so the size of the problem is known, then stop new violations with request management, then remediate the existing ones. Starting with remediation means fixing while more arrive.