They already own SAP GRC Access Control. They are still shopping.

Article 4 of Field Notes, a series on what we learned selling an offline SAP access-risk tool.

The first time a very large enterprise with a fully deployed SAP GRC Access Control landscape asked for a demo, I assumed someone had made a mistake. They have ARA. They have the ruleset. They have mitigating controls, workflow, risk owners, the whole thing, paid for and running.

They had not made a mistake. It happened again, then again, and by the fourth time I had a reasonably clear picture of what these organisations are actually missing. It is not risk detection. ARA detects risks perfectly well. It is everything that has to happen after the report lands.

I have spent most of my career on the implementation side of GRC Access Control, so I want to be careful here. This is not a case against the product. It is an observation about where the tool stops and where the work continues.

What ARA gives you and where it ends

Run a risk analysis in ARA and you get a list. User X has risk F001. Role Y contains a conflict between create vendor and post payment. The list is accurate, it is traceable to a maintained ruleset, and it will hold up in an audit.

Now the security architect has to answer a different question: what do I change, and what breaks if I do?

That question needs things ARA was not designed to give quickly:

• Which specific authorization objects and field values in which role generate the conflict, not just the function pair
• What happens to the risk if I remove that one object from that one role, before I touch PFCG
• Which of the seventy roles containing this conflict are actually used, and by whom
• Whether the same conflict is being solved five different ways by five different regional teams
• What the risk position looks like after a proposed role redesign, in a form I can show to a business owner

Some of this is technically possible in the standard product. Simulation exists. In practice, the architects I work with do it in Excel, because the round trip through the system is slow, because they want to try twenty variations in an hour, and because the output has to go to a business role owner who will not read an ARA screenshot.

That Excel file is the market. Every one of these enterprise conversations started with somebody describing their spreadsheet.

The three patterns I saw repeatedly

Remediation is manual and undocumented. The analysis is systematic and the fix is not. Decisions about which object to strip out of which role live in someone's head or in a mail thread. Six months later nobody can explain why that role has that restriction. This is an audit problem waiting to happen, and internal audit functions are increasingly the ones raising it.

Simulation is too slow to be exploratory. Role redesign is iterative. You try something, look at the residual risk, try something else. If each iteration costs twenty minutes, you do not iterate. You pick the first option that works and defend it later.

The output does not travel. A risk report that a security specialist can read is not a risk report a finance process owner can approve. Somebody rebuilds it in Excel or PowerPoint every single time. This is unglamorous and it consumes an enormous amount of skilled time.

The replacement conversations are different

Separately from the GRC customers, several organisations came to us wanting to move off a commercial third-party SoD product they were already licensing. The drivers there were not the same. They were, in rough order of frequency: annual cost, the depth of analysis at object and field level, and control over the ruleset.

Ruleset control deserves a mention. Several teams told me they could not fully see or modify the logic behind the risks they were being reported. If a control owner challenges a finding and the security team cannot show exactly which authorization object combination triggered it, the finding gets disputed and the process loses credibility. Transparency of the rule logic turned out to matter as much as the size of the rule library.

What this means if you own GRC and are wondering whether to look

A few honest signals that a complementary tool is worth evaluating:

• Your architects maintain a personal Excel workbook for role analysis. Ask them. They will show you.
• You cannot answer "what is the residual risk after this change" without a full analysis cycle.
• Remediation decisions from the last redesign are not documented anywhere an auditor could follow.
• You run analysis for entities that are not connected to your GRC landscape, such as recent acquisitions or a hosted subsidiary.

And a few signals that you do not need one:

• Your pain is access request workflow, provisioning, or firefighter. That is ARM and EAM, not analysis, and no analysis tool will help.
• You need continuous monitoring with alerting across a connected landscape. That is what a connected platform does well.
• Your risks are detected fine and your remediation backlog is small.

The uncomfortable truth for both vendors and consultants is that the SoD market has been sold as a detection problem for fifteen years, and detection was solved a long time ago. Most organisations I meet know exactly what their conflicts are. They have known for years. What they cannot do is fix them at a reasonable cost, prove afterwards what they fixed, and explain it to the business in a language it accepts.

That is where the time goes. That is where the money should go.

If you are in that position, we wrote a practical guide to running a specialist access risk analysis tool alongside a GRC platform: Planning SAP GRC or Pathlock? Start with MTC Skopos.

Next in this series: what happened when procurement asked an offline desktop tool for a SOC 2 report.