"Send us your SOC 2 report." But we never receive your data.

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

This one I find genuinely interesting, and I want to argue both sides properly, because the easy version of this article is a small vendor explaining why certifications do not apply to him. That version is self-serving and procurement teams can smell it.

Here is the situation. A prospect's third-party risk process sends the standard questionnaire. It asks for an ISO/IEC 27001 certificate or a SOC 2 Type II report. The software in question is a signed binary that runs on the customer's own machine and analyses data that stays there. It reads either a file the customer exported themselves, in which case no network is involved at all, or it connects over RFC to the customer's own SAP system, inside the customer's own network. Their authorization data is not transmitted to us in either case. The one connection that does reach us is a licence check, and it carries entitlement metadata and a machine fingerprint, no business data. We have no production environment that holds customer data. There is no tenant. There is no data centre holding their extract, because we never receive their extract.

So what exactly would the report cover?

Why the question is not unreasonable

I spent years on the audit side, at PwC and Deloitte, before moving into SAP security consulting. I have written the requests I now receive. The logic behind them is sound.

A SOC 2 or an ISO 27001 certificate is not really a statement about where data sits. It is a proxy for something harder to observe: does this organisation have working processes? Does it manage change, control access to its own source code, respond to incidents, screen its people, and review its suppliers? Those questions apply to a desktop software vendor exactly as much as to a SaaS provider, because a compromised build pipeline delivers malicious software to the customer's most privileged systems regardless of where the data lives.

That is a real risk and it is arguably worse for offline software, not better. If a hosted vendor is breached, the blast radius is their environment. If a desktop vendor's signing process is compromised, the blast radius is every customer machine that installs the update. SolarWinds is the reference case and it has changed how procurement thinks, correctly.

So when a security team asks for assurance, they are not confused. They are asking a good question with the only vocabulary their process gave them.

Why the standard answer does not fit

The mismatch is in scope, not in principle.

A SOC 2 Type II describes controls over a defined service commitment, over a period, for a system boundary. The system boundary is where the auditor looks. For a hosted service the boundary contains the customer's data, so the report tells you something directly relevant: your data was in that boundary and these controls operated on it.

For software that runs on your hardware, your data is never inside our boundary. It is inside yours. A report on our internal environment would be a report about a company that develops software, not about a system that processes your information. The trust service criteria for confidentiality and privacy would apply to almost nothing in the customer relationship.

ISO 27001 has the same shape of problem. The statement of applicability would cover our own information assets. It would be a genuine certificate and it would tell you very little about the risk you were actually worried about.

What we offer instead, and how the conversation goes

Rather than argue about the certificate, I found it more productive to answer the underlying questions directly and specifically. The list we now provide covers:

Supply chain and code integrity. The executable is code-signed with a DigiCert Authenticode certificate and a SHA-256 checksum is published per release, so the customer confirms publisher and integrity themselves through the Windows signature dialog or Get-AuthenticodeSignature. That is a stronger control than any attestation from us, because they perform it rather than reading an auditor's opinion of us.

Verifiable data flow. Instead of asserting no data leaves the machine, we invite the customer to prove it. Run the tool with a packet capture or on an isolated machine. This is the single most persuasive thing in the whole package, because it converts a trust question into a test the customer runs themselves.

Cryptographic integrity of the evidence itself. Analysis logs are signed with Ed25519, and the customer can configure their own signing key alongside ours, adding non-repudiation on top of the software attestation. This is the control an auditor should actually care about, because it answers a question a SOC 2 report does not: can you prove the ruleset and the data were not altered between extraction and analysis, and can you prove it without taking the vendor's word for it. Auditors verify the signature independently, outside the application, on Linux, macOS, or Windows. With the customer's own key, non-repudiation runs to them rather than to us.

AI data handling, described precisely. The assistant is optional and the product is fully functional without it, including air-gapped. When enabled, it uses the customer's own API key with the provider they already contract with, so no new sub-processor enters the assessment. Identifying fields, user IDs, role names, system names, and HR attributes, are replaced with placeholders locally before any request is built, the mapping never leaves the machine, and a preview shows the exact payload before it is sent. The feature can also be disabled outright. This is the part of the questionnaire where a written answer beats a certificate, because the reviewer can ask for a sample payload and check it against the claim in ten minutes.

A dependency inventory they can verify rather than trust. Releases are built with cargo auditable, which embeds the full dependency list inside the signed binary, so the SBOM inherits its integrity from the code signature instead of arriving as a separate file whose provenance is its own problem. The customer can then run cargo audit against the binary they received and produce their own result against the RustSec advisory database. This is the answer I am most comfortable giving, because it does not ask them to believe anything. They generate the evidence.

A documented architecture and data-flow statement. Every outbound connection inventoried, with what each one carries, for their security and data protection teams to review. The standing version of this lives on our security page.

Business continuity, honestly framed. If the vendor disappears, the installed software continues to function on the customer's hardware and their data was never held by us. This is a materially better continuity position than a hosted service can offer, and it is worth stating plainly.

Regulatory posture. For European buyers, the Cyber Resilience Act is becoming the more relevant framework for software products anyway, and NIS2 obligations flow down to suppliers in scope. Engaging with those seriously carries more weight with an informed security team than a certificate that was scoped around the wrong boundary.

Where this still fails

I want to be straight about the outcome, because it is not a clean win.

Some procurement processes cannot accept an argument, only an artefact. The requirement is a field in a system and a written explanation does not populate the field. In those cases the technical and security stakeholders were often persuaded and procurement still could not proceed. That is not irrationality, it is process design, and it is a real barrier for any small vendor selling into a large enterprise.

The pattern that worked, when it worked, was to get the explanation in front of the security function early, before procurement opened the file, and to have the security function write the exception rather than asking procurement to make one. If you wait until the questionnaire arrives, you are arguing with a form.

I also do not think the answer is permanent. A vendor of any size eventually certifies something, if only to stop having this conversation. My reservation is about doing it for signalling reasons while telling customers the certificate proves something it does not. If we do it, I would rather scope it around the thing that actually carries risk, which is the build and release pipeline.

For security teams reading this

If you receive a request to approve a tool that runs entirely on your own hardware, the questions I would ask, in place of the certificate, are these:

1. Can you verify the code signature and the publisher independently?
2. Can you confirm the absence of network egress in your own environment, before deployment?
3. What is the vendor's update mechanism, and can you control when and whether updates are applied?
4. What happens to your operations if the vendor ceases to exist?
5. How are third-party dependencies in the build managed and disclosed?

Those five answers tell you more about your actual exposure than a certificate scoped around an office in another country.

Next in this series: the vendor risk argument for buying from a small company, which is not the argument you expect.