"What if you disappear?" It is a good question. Ask it of everyone.

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

Every small vendor gets this question, and most of us answer it badly. The bad answer is a story about commitment and determination, which nobody buys, because the founder of every failed company said the same thing sincerely.

I want to make a different argument. The question is a good one. What is wrong is that it gets asked of exactly one category of vendor, and it gets asked in a form that assumes the answer is obvious for everyone else.

The question nobody asks the large vendor

In this market, right now, organisations are migrating off a commercial SoD product because it is being wound down. Not because the vendor went bankrupt. Because a viable company made a portfolio decision.

That is the normal way software disappears. It is not the dramatic way, and it happens to customers of large vendors constantly:

• The product is sunset and customers are directed to a successor with different capabilities and a new licence.
• The vendor is acquired and the roadmap for the overlapping product quietly stops.
• The product moves to a new platform and the migration is your project, on their timeline.
• Support for your version ends while you are mid-programme.
• Renewal arrives with a substantial increase and no realistic exit, because your process is built on their platform.

None of these require the vendor to cease existing. Every one of them produces the outcome the buyer was worried about, which is that the thing they depend on stops being available on terms they control.

I have never once been asked, in a competitive evaluation, what my product roadmap commitment is compared to the incumbent's sunset history. The size of the vendor is treated as answering the question. It does not answer it. It changes which failure mode applies.

Availability is not a solved problem either

The implicit comparison is against a hosted service with an uptime commitment. Those commitments are real and mostly honoured, and they are also smaller than people assume.

A 99.9% availability target permits roughly nine hours of unavailability a year, and that is before planned maintenance windows, which are typically excluded from the calculation entirely. The relevant question is not the annual percentage. It is whether the unavailable window can land on the Thursday before your quarter-end sign-off, and the answer is that it can.

Then there is the breach case. A hosted access-risk platform holds authorization data for many organisations, which makes it a considerably more attractive target than any single customer's environment. If that platform is compromised, your map of who can do what in your ERP is part of someone else's incident. You will find out when they tell you, you will manage a disclosure you did not cause, and you will have no ability to act until they act.

I am not claiming this makes hosted platforms a bad choice. They are the right choice for continuous monitoring and for workflow, as I said in article two, and their operational maturity is generally higher than a small vendor's. I am claiming that "large vendor" and "no continuity risk" are different statements, and the evaluation process usually treats them as the same one.

What is actually different about a local tool

Break the worry into four risks, because they have different answers and bundling them is what produces bad conversations.

Operational continuity. For a hosted service, vendor problems become your problems immediately and synchronously. Their outage is your outage. For software running on your own hardware, the two are decoupled. Whatever happens to us on a given Tuesday, the analysis you scheduled still runs.

Data access. This is the one where the asymmetry is largest and it is worth being blunt. If a hosted vendor ceases operating, your access to your historical analysis, your ruleset customisations, your mitigation records, and your audit evidence depends on a data return clause that almost nobody has tested. If we cease operating, none of that applies, because your outputs are files on your own storage in open formats and were never anywhere else. Your signed analysis logs remain verifiable with standard tooling and no vendor involvement, which means an auditor in 2031 can validate a 2026 analysis whether or not MTC exists.

Licensing. By default the product checks entitlement against a licence service, carrying no business data, with a grace period if the service is unreachable. A grace period suits a bad hotel network and does not suit a vendor that no longer exists. So the product also supports a fully offline licence with no server dependency, which is required for air-gapped environments anyway and removes the dependency rather than shortening it. Ask for it in the agreement rather than trusting that the capability exists.

Maintenance and support. Here the small vendor genuinely is more exposed, and I will not dress it up. If we stop, updates stop. That matters concretely for an SoD tool, because SAP keeps releasing transactions, Fiori apps, and authorization objects, and a ruleset that is not maintained drifts out of alignment with the systems it is analysing. Within a couple of years the analysis would be measurably less accurate.

Three of the four favour the local architecture, structurally rather than rhetorically. One does not. That is the honest ledger, and it is a much better ledger than the question assumes.

The maintenance risk is the real one, so treat it seriously

The mitigations are contractual and technical, and a buyer can verify all of them:

• Source code escrow with defined release conditions.
• Perpetual licence terms for the version already delivered, so an expiry cannot be used as leverage.
• An offline entitlement file, as above.
• Published, open output formats so historical results stay readable by other tools.
• A documented, editable ruleset the customer can maintain themselves if they have to.

That last one is the most underrated. If the rule logic is transparent and the customer can modify it, the maintenance risk becomes bounded rather than absolute, because an in-house team or another consultancy can keep it current. A ruleset you cannot see is a dependency regardless of how large the vendor is.

What I would actually recommend

Ask every vendor in your evaluation the same question, in the same words, and require the same specificity in the answer.

Not "will you still exist in five years", because everyone says yes and the answer carries no information. Ask: if you stop supporting this product, what precisely do I still have, and what do I have to do about it?

Then compare the answers. For some vendors it is a migration programme to a successor product. For others it is a data return clause and a ninety day window. For a tool running on your own hardware with your own signing key, it is a shorter answer.

A buyer who chooses you after that conversation is a much more durable customer than one who was talked past a concern. And a buyer who chooses someone else after that conversation has at least made the decision with the real information, which is more than the usual process produces.

This concludes the series. The earlier articles covered data residency, why we built a desktop tool rather than a service, the difference between compliance-driven and efficiency-driven buyers, why organisations that already own SAP GRC keep evaluating additional tooling, and what happens when procurement asks an offline product for a SOC 2 report.