Field Notes: Articles & Insights

MTC Skopos came out of consulting work, not a pitch deck. This introduces Field Notes, a six-part series of observations on how organisations actually evaluate and buy SoD tooling: data residency, desktop software in a SaaS market, the two kinds of buyer, why GRC owners keep shopping, SOC 2 requests for offline software, and the small-vendor question.

In most SoD tool evaluations, the deciding question is not the ruleset. It is where the SAP authorization data goes. Field Notes article 1 covers why these extracts raise the question more sharply than most software, the five questions buyers actually asked, how MTC Skopos answers them, and the honest costs of running entirely on the customer's hardware.

Field Notes article 2. The decision to ship MTC Skopos as a signed portable executable came from the consultant's laptop problem: locked-down client machines where nothing can be installed and the fallback is two days of VLOOKUPs that produce a wrong analysis. What portable-and-signed solves in practice, where the market agreed, and where SaaS honestly wins.

Field Notes article 3. Compliance-driven buyers need a defensible SoD report once, to close an audit finding, and then the need is gone. Efficiency-driven buyers produce that report repeatedly and it hurts. Both look identical during a trial. Three first-call questions that separate them, the trial-extension mistake we made for six months, and advice for buyers on the other side.

Field Notes article 4. Large enterprises with fully deployed SAP GRC Access Control kept asking for demos, and they were not confused. ARA detects risks perfectly well; what is missing is everything after the report lands: remediation decisions, fast exploratory simulation, and output a business owner will read. The Excel file every security architect maintains is the market.

Field Notes article 5. Procurement asks an offline desktop tool for a SOC 2 report. The request is not unreasonable: certificates are a proxy for working processes, and a compromised build pipeline is a real risk. But the scope does not fit software whose boundary never contains customer data. What we offer instead: verifiable code signing, packet-capture-testable data flow, Ed25519-signed logs, an SBOM embedded in the binary, and the five questions security teams should ask in place of the certificate.

Field Notes article 6, closing the series. Every small vendor gets the disappearance question, and the honest answer splits it into four risks: operational continuity, data access, licensing, and maintenance. Three structurally favour local software; one genuinely does not, and the mitigations for it are contractual and verifiable. Meanwhile the same question is never asked of large vendors, whose products disappear by portfolio decision all the time.