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.

The default answer changed and nobody was asked

Ten years ago this question had a boring answer in most companies. The data stayed in a system your own team ran, in a building your company paid for, and the interesting question was who had access to the server room.

That is not the default any more, in this category or in any other. Software gets sold as a service, the vendor operates it, and the buyer's data lives in a tenant alongside everybody else's. The advantages are genuine and I am not going to pretend otherwise. The part that gets less attention is that for a lot of buyers this stopped being a decision. When every product in a category is hosted, you are not choosing a hosted product. You are accepting the only shape on offer, and the security team gets handed a review whose outcome was determined before they were involved.

I have watched that happen in evaluations. The security architect raises data residency, the answer is a region selection and a sub-processor list, and the conversation ends there because the alternative does not exist in the shortlist. Nobody made a bad decision. There simply was not one to make.

We wrote separately about what that trade costs over time, in export formats, in lock-in, and in what you can do with your own data once an AI model is the thing reading it. The short version is that convenience was priced correctly and control was priced at zero, because nobody was asked to pay for it separately.

The reason MTC Skopos runs locally is not that hosting is wrong. It is that the choice had quietly disappeared, and a market with no alternative is worse for everyone in it, including the hosted vendors. A buyer who picks a hosted platform after comparing it against a local one has made a decision. A buyer who picks it because nothing else was on the list has not.

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 not noticing that an architecture had been chosen for them.

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