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. 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 later and came out of the consulting work rather than out of a plan. There was no thesis about an underserved market and nothing that would look good in a pitch deck. I kept running into the same problem on engagements, built something for my own use, and other people asked for it.

I mention this because the alternative framing, where a founder identifies an opportunity and executes on it, would be a nicer story and a false one. The product is built alongside client work, slowly, which shapes almost everything in this series. It is why we can sell to the customers the tool actually fits and decline the ones it does not.

The usual advice for a company at this stage is to write about the market and never about yourself. I am going to ignore that advice, but not by writing a founder story. What follows is a set of observations about how organisations actually evaluate and buy SoD tooling, drawn from the evaluations I have personally sat through.

The reason I think they are worth publishing has nothing to do with MTC. 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 watched did not work that way, and the gap between the two is where the useful information is.

What the series covers

Six articles. They are all published, so you can read them in order or jump to the one that matches the decision you are 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, 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 is unglamorous and comes down to what happens when a consultant is handed a locked-down client laptop and cannot install anything on it.

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. I learned to tell them apart late, and this article is mostly about the cost of learning it late.

They already own SAP GRC and they are still shopping. Large enterprises with fully deployed Access Control landscapes kept asking for demos. They were not confused. They had a remediation problem, not a detection problem, and I think that distinction describes the state of this market better than anything else I could write.

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 the parts of it I cannot answer.

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 cases that has cost the article some specificity. I would rather lose the specificity.

There is also no product pitch. Article three 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 list of features we happen to have. 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 of this article 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.