What to ask an on-chain assurance vendor

An assurance result is only as good as the diligence behind the vendor that produced it. When a supervised institution relies on a third-party verdict about its on-chain systems, it inherits the vendor's strengths and the vendor's weaknesses alike. A result produced under weak methodology, unclear scope or undocumented data handling becomes the institution's own exposure the moment it enters the control file. Vendor assessment is therefore not procurement hygiene. It is the control that decides whether the assurance result can be relied on at all.

Ask about scope first

The first questions establish what was actually tested. What exactly does the analysis cover, artifact by artifact: which contracts, which bytecode versions, which dependency set. Against which standard is the result mapped, and which controls does that standard include. And what is explicitly out of scope: network configuration, settlement governance, key management, novel business logic. A vendor that cannot draw its own boundary sharply is itself a risk, because an unstated boundary is always read wider than it is.

Ask about reproducibility

The second set of questions establishes whether the result is evidence or opinion. Can our own team re-derive the verdict from pinned inputs, inside our own environment, and arrive at the same rule-based outcome. Are the engine versions and ruleset versions recorded on the result itself, so the run can be reconstructed later without asking the vendor. A result that a client cannot independently reproduce is a claim, and claims carry little weight at examination.

Ask about the data boundary

The third set concerns where the work happens. Where does our contract code sit during analysis, and where does any model inference run. What leaves our environment, in what form, and under what handling terms. For pre-deployment code the answer should be unambiguous: source and bytecode stay inside the client boundary, and only hashes, verdicts and version identifiers cross it. A vendor that cannot state its data boundary in one sentence has not finished designing its service.

Ask about accountability

The fourth set establishes who answers for the result. Which named person is accountable for the accuracy of a given verdict. What is the escalation path when a client disputes a finding. What is the correction path when the vendor itself discovers that a result was wrong, and how quickly is the client told. Accountability that resolves to a distribution list is a warning sign; the operating model should name people, in writing, at every tier.

Ask for the security evidence

The final set covers the vendor's own controls. What attestations exist, SOC 2 and ISO 27001 among them, and in what status: examined and issued, or in progress. Can the vendor provide the underlying control documentation for the client's own third-party file, rather than a summary brochure. An assurance vendor is itself a third party on the critical path, and it should be able to satisfy the same assessment it helps its clients pass.

The pattern across all five sets of questions is the same. A vendor whose answers are specific, bounded and reproducible can be relied on. A vendor whose answers are a label cannot. Client Focus designs SCG360 to answer these questions directly: scope stated on the certificate, verdicts reproducible from pinned inputs, source and bytecode retained inside the client boundary, named operators accountable for evidence accuracy, and security status disclosed through the trust and compliance page rather than asserted in marketing.