The question that decides SAP SoD tool evaluations: where does my data go?

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

I used to think the deciding question in an SoD tool evaluation was the ruleset. How many risks, how many transactions, how well maintained, does it cover S/4HANA and Fiori and IAG.

It is not. In most of the evaluations I have run over the past two years, the question that actually decided the outcome was asked by someone who was not in the room for the demo. It came back through the sponsor, usually a week later, usually in one line:

Where does our SAP authorization data go?

Everything before that question is a feature comparison. Everything after it is either a short conversation or a very long one.

Why this question has teeth for SAP specifically

Plenty of software handles sensitive data and nobody blinks. What makes SAP authorization extracts different is what they contain and who they describe.

An SoD analysis needs AGR_USERS, AGR_1251, AGR_1252 with its org value assignments, AGR_DEFINE, AGR_AGRS, and USR02, plus the UST* tables when profiles are in scope. Put together, that is a full map of who can do what in the system that runs the company's money. It includes the names of every user, their SAP ID, their roles, their org level restrictions, and frequently their department. In many extracts you also get last logon dates and lock status, which is personal data about employees under GDPR and its Swiss equivalent.

So the security team is being asked to send, to an external party, a document that describes precisely how to commit fraud in their ERP and which named individuals are already positioned to do it. Reasonable people hesitate.

They hesitate more when the vendor is small. A large software company sending that extract to a hyperscaler region is a known quantity with an insurance policy behind it. A small vendor is not, and the security team knows it.

What people actually asked us

I kept notes, because the pattern was consistent enough to be useful. The questions came in roughly this order:

1. Does the tool upload anything?
2. Does it call home for licensing, telemetry, updates, crash reports?
3. If we import a CSV export instead of connecting over RFC, does it still work with no network at all?
4. Can we inspect the network traffic ourselves during the trial?
5. If we use the AI features, where do the prompts go?

Question four is the one I would flag to any vendor reading this. Two prospects ran the trial with a packet capture open. One told me afterwards that they had done the same to three other tools and that two of them had been dropped at that point. I do not know which two, and I did not ask.

Question five became important faster than I expected. Once a tool has any AI assistance in it, the data residency conversation restarts from zero, because now the security team is thinking about a third party model provider they never agreed to.

Our answer has three parts, and all three came out of these conversations rather than out of a product plan.

The first is that the feature is optional and the product is complete without it. Not degraded, not a trial tier. Analysis, simulation, remediation, and reporting all work with AI switched off, which means a security team that says no is not choosing a lesser version of the tool. Several did say no initially and enabled it months later once they had tested it themselves.

The second is that the customer supplies their own API key for their own provider. Anthropic, OpenAI, Azure OpenAI, or a self-hosted gateway, whichever they already have a contract and a data processing agreement with. Requests go from their machine to their provider under their terms and their retention settings. We are not in the path, we do not broker the traffic, and there is no MTC endpoint involved. This matters more than it sounds in a procurement review, because the AI provider is then not a new sub-processor to assess. It is one they already approved.

The third is anonymisation, and it applies to the fields that carry the identity: user IDs, role names, system names, HR attributes. These are replaced locally with placeholders before the request is built, and mapped back on the machine when the response returns. The model reasons about the structure of the risk, which is what it is good at, and never receives the names. Anonymisation is configurable, so a team with a stricter policy can extend it, and a team using a self-hosted model can reasonably decide they do not need it at all because nothing is leaving their infrastructure.

There is also a preview of the exact payload before a request goes out. I did not expect this to carry commercial weight and it turned out to be the most effective single item in a security review, because it converts a vendor claim into something the reviewer verifies with their own eyes in about a minute.

The public sector and defence-adjacent case

For public organisations, an inter-governmental body, and organisations with classified or export-controlled environments, this stopped being a preference and became a hard gate. If the tool needs an outbound connection, the evaluation ends. Not after a procurement debate. It ends in the first technical call.

I want to be careful not to overclaim here, because it cuts the other way too. Some of these organisations then asked for certifications that an offline tool cannot meaningfully hold, and that conversation was harder. I come back to it in article five of this series.

The trade-offs we accepted

Running entirely on the customer's hardware is not free. Here is what it costs, honestly:

No usage telemetry. I have no idea which features people use. I find out when someone tells me, or when they do not renew. For a product team this is genuinely painful.

No silent updates. Every customer runs the version they downloaded. Support conversations start with "which build are you on" and sometimes the answer is one from eight months ago.

No hosted demo environment that reflects their data. Every demo runs on synthetic data or on their own extract during a trial, which lengthens the sales cycle.

Performance is bounded by their laptop. We spend engineering effort on making analysis fast on a mid-range corporate machine that we would otherwise spend on features. Rust helps. It does not make the constraint disappear.

I would make the same choice again, but I want to be clear that it is a choice with a bill attached, not a free win.

What I would tell a buyer

If you are evaluating any access-risk tool, ask the five questions above in writing and keep the answers. Ours are documented on our security page. Then verify the first two yourself during the trial with a packet capture. It takes twenty minutes and it will tell you more about the vendor than the reference calls will.

And if the answer is that data goes to a hosted environment, that is not automatically wrong. Hosted tools have real advantages, particularly for continuous monitoring across a landscape. Just make sure the DPA, the sub-processor list, and the deletion commitments are as specific as the demo was.

The failure mode I saw most often was not a company choosing the wrong architecture. It was a company choosing an architecture without noticing that they had chosen.

Next in this series: why we built a desktop tool in a SaaS market, and the client-laptop problem that decided it.