Field Notes: Articles & Insights

MTC Skopos was built to do consulting work at clients who had no access-risk tooling, by a security consultant and a software architect, and it grew to cover the analyses we were rebuilding in Python, SQL and Alteryx on every engagement: did-do, remediation, the authorization matrix, the role bill of materials. Then it started selling, to global firms, Big Four, boutiques, public bodies and S&P 500 companies. This introduces Field Notes, a six-part series on how those organisations actually evaluate and buy SoD tooling.

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, how a decade of default-to-SaaS removed the choice from buyers, the five questions buyers actually asked, 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, so the analysis is either a spreadsheet that stops at transaction level or a SQL, Python or Alteryx build that is correct once and thrown away at the end of the engagement. What portable-and-signed solves, why the product is still sold as a subscription when there is nothing hosted, 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 what happens after the yes, when the file moves to a procurement function that never saw the product.

Field Notes article 4. Large enterprises with fully deployed SAP GRC Access Control kept asking for demos, and so did organisations already running a specialist analyzer such as CSI tools. They were not confused. Detection works; 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. Software mostly disappears by sunset, acquisition and forced migration rather than by bankruptcy, which is a risk vendor size does not remove. What MTC Skopos commits to: if the company stops, the version you paid for keeps running, with no licence server in the way.