Two years of watching companies decide how to handle SAP access risk

Introduction to a six-part series.

I should get the awkward part out of the way first. MTC is not an old company and it did not start as a software venture.

I registered it in Geneva in March 2024 to run my SAP Security and GRC consulting practice. MTC Skopos, the segregation of duties analysis tool we build, came out of that consulting work. There was no thesis about an underserved market and nothing that would have looked good in a pitch deck.

The tool exists because the engagements needed it

The situation repeated itself often enough to become predictable. A client asks for an access risk assessment and has nothing to run it with. Sometimes they never bought a tool. Sometimes they own a platform that covers the main production landscape but not the entity I have been asked to look at, typically a recent acquisition or a subsidiary on its own system. Sometimes they own the platform, it covers the system, and I cannot get an account on it inside a six-week engagement.

The result is the same in all three cases. You are standing in front of a system with a few thousand users, asked for an opinion on access risk, with no way to see who can actually do what.

Working in the dark was not an option. You cannot assess access risk by reading role names and asking people what they think their roles contain, and I was not willing to produce a transaction code cross-reference and let a client believe it was an analysis. So we built something that would run on whatever laptop the client had handed me.

I should be clear about who the we is, because it matters for everything that follows. I am a security consultant, not a software engineer. I can write an analysis in SQL or Python and did for years, but a query written against one client's extract is not a product. MTC Skopos is engineered by a software architect whose priorities are performance and code quality rather than feature count, which is why it is written in Rust, why a 10,000 user system is analysed in under two minutes on a standard laptop, and why it behaves the same at the tenth client as at the first. My half is the domain: what has to be checked, how a risk is defined, what a remediation proposal must contain to survive a business owner and then an auditor. Neither half would have produced this alone, and I have watched enough consultant-built tools stall at the point where they meet a real system to know which half people underestimate.

What actually made it a product

Risk detection was never the hard part of those engagements. The hard part was everything I did around it, in Python, SQL and Alteryx workflows, from scratch, at every single client:

• The did-do analysis, comparing what people can do against what they actually did, using change documents and execution data rather than assumption
• The remediation work, which assignment to remove first, what breaks if you remove it, and a record of why the decision was made
• The authorization matrix that business owners actually sign
• The role bill of materials, what a role is genuinely made of once you resolve derived roles and expand composites

None of that lives in a standard risk analysis tool, so it gets rebuilt by hand on every engagement by whoever is on the project. That is where the time went, and folding those analyses into the same tool as the detection was the real driver. The SoD engine was the easy half.

Then people asked to buy it

At some point clients and colleagues who had seen it working asked whether they could have their own copy. We started running demos, and it sold.

What surprised me was who bought it. Global consulting firms and a Big Four member firm, but also two-person boutique consultancies, public sector organisations, and S&P 500 companies with GRC landscapes far larger than anything I had implemented. I had expected the tool to fit one profile. It fits several, and those buyers behave nothing like each other once the demo is over. The Big Four firm and the boutique consultancy want the same software for opposite reasons and buy it through processes that have nothing in common.

That range is why I think these notes are worth publishing. It is not that MTC is interesting. It is that almost everything written about this market is written by people selling into it at scale, and it describes the market as it is supposed to work. The evaluations I sat through did not work that way, and the gap between the two is where the useful information is.

The usual advice for a company at this stage is to write about the market and never about yourself. I am going to half ignore it. What follows is a set of observations about how organisations evaluate and buy SoD tooling, drawn from evaluations I personally ran, with our own decisions included only where they are the evidence.

What the series covers

Six articles. They are all published, so read them in order or jump to the one that matches the decision you are currently sitting in.

Where does my data go. The question that decided more evaluations than any feature comparison. Why SAP authorization extracts raise it more sharply than most software does, what a decade of default-to-SaaS has done to the answer, and the five questions I would put to any vendor in writing.

Why we built a desktop tool in 2024. Every piece of advice said build a service. The reason we did not comes down to what happens when a consultant is handed a locked-down client laptop. Also the question that follows immediately afterwards: if it is not SaaS, why is it a subscription?

Two kinds of buyer. Some organisations need an SoD report once, to close an audit finding. Others need it forty times a year. They behave identically during a trial and completely differently afterwards. Plus what happens when the evaluation ends and procurement begins, which is where most of the calendar actually goes.

They already own SAP GRC and they are still shopping. Large enterprises with fully deployed Access Control landscapes kept asking for demos, and so did organisations already running a specialist analyzer. They had a remediation problem, not a detection problem.

Send us your SOC 2 report. What happens when a third-party risk process designed for hosted services meets software that runs on the customer's own hardware and never receives their data. I argue both sides of this one, including the side that says procurement is right.

What if you disappear. The small vendor objection, answered structurally rather than emotionally, including what we commit to so that a customer who has paid keeps a working tool whatever happens to us.

What it is not

There are no client names in any of this. Where a detail could identify an organisation I have removed or generalised it, and in a few places that has cost the article some specificity. I would rather lose the specificity.

There is also no product pitch. Article four is the one that comes closest to describing why our tool exists, and I have tried to write it as an account of what enterprise security teams told me they were missing rather than as a feature list. If it reads otherwise, that is a failure on my part and I would rather hear about it.

Why I am writing it now rather than in five years

Partly because the observations are fresh and I still have my notes. Mostly because the version written in five years would be tidier and less true. By then I would have a narrative, and narratives are built backwards from outcomes. The founder telling you what he saw coming is usually telling you what he can now see, arranged in the right order.

Right now I can still remember which evaluations I misread and why. That seems more useful to someone currently sitting on either side of one of these decisions.

The series starts with the data question.

Mathieu Meylan runs Meylan Technologies & Consulting in Geneva, an SAP Security and GRC consulting practice, and builds MTC Skopos. He holds CISA and CISSP and has worked in IT audit and SAP security consulting since 2015.