Compliance

Continuous-evidence pack vs SOC 2 posture: why the offline verifier changes the audit conversation

Most AI Control Planes ship a SOC 2 Type II logo and call it done. Visionality ships a continuously-generated, signed evidence pack across SOC 2 + ISO 27001 + ISO 42001 + NIST AI RMF that the auditor verifies offline with a standalone CLI. Here's the difference.

By Chris Therriault6 min read

There is a meaningful gap between "we hold a SOC 2 Type II report" and "we produce a continuous-evidence pack across four compliance frameworks that an auditor can verify offline." The first is what most AI Control Plane products ship. The second is what Visionality ships. This article walks through the difference, why it matters at the procurement stage, and how to evaluate any vendor's compliance posture in five minutes.

What a SOC 2 Type II posture is

A vendor claims SOC 2 Type II posture by:

  1. Engaging a CPA-certified auditor (Sensiba, A-LIGN, Schellman, etc.)
  2. Designing controls aligned to the Trust Service Criteria (CC1–CC9)
  3. Operating those controls over a window (typically 6–9 months)
  4. Receiving a Type II report attesting that the controls were designed and operated effectively over the window

This is a serious investment. Most vendors who hold a SOC 2 Type II report did real work for it. It is also a point-in-time artifact. The report covers a specific window. Customers buying a year later, three years later, have to trust that the controls have not drifted — and that the vendor's renewal-window snapshot is current.

What a continuous-evidence pack is

Visionality's continuous-evidence pack is generated every time you ask for it. It is not a point-in-time snapshot. Twelve evidence collectors read the live database state — role grants, audit-table census, recently issued tokens, recent binding rejections, applied migrations — and produce a structured JSON bundle:

{
  "schema_version": 2,
  "generated_at": "2026-06-26T15:23:01.234Z",
  "org_id": "org_arctrade",
  "frameworks": ["SOC2", "ISO27001", "ISO42001", "NIST_AI_RMF"],
  "evidence": [
    { "framework": "SOC2", "control": "CC6.1", "title": "Role grants", "status": "pass", "detail": {...} },
    { "framework": "SOC2", "control": "CC6.6", "title": "PKCE consent audit", "status": "pass", "detail": {...} },
    { "framework": "SOC2", "control": "CC6.7", "title": "Binding-status posture", "status": "pass", "detail": {...} },
    { "framework": "SOC2", "control": "CC7.2", "title": "Audit census", "status": "pass", "detail": {...} },
    { "framework": "SOC2", "control": "CC7.3", "title": "MCP invocation log", "status": "pass", "detail": {...} },
    { "framework": "SOC2", "control": "CC8.1", "title": "Migration ledger", "status": "pass", "detail": {...} },
    { "framework": "ISO27001", "control": "A.8.15", "title": "Logging", "status": "pass", "detail": {...} },
    { "framework": "ISO27001", "control": "A.8.34", "title": "Protection during audit testing", "status": "pass", "detail": {...} },
    { "framework": "ISO27001", "control": "A.5.34", "title": "Privacy", "status": "pass", "detail": {...} },
    { "framework": "ISO42001", "control": "A.6.2", "title": "AI risk management", "status": "pass", "detail": {...} },
    { "framework": "ISO42001", "control": "A.6.2.5", "title": "AI system impact assessment", "status": "pass", "detail": {...} },
    { "framework": "NIST_AI_RMF", "control": "GOVERN-1.5", "title": "Audit log policy", "status": "pass", "detail": {...} },
    { "framework": "NIST_AI_RMF", "control": "MAP-3.4", "title": "AI risk landscape", "status": "pass", "detail": {...} },
    { "framework": "NIST_AI_RMF", "control": "MEASURE-2.7", "title": "Drift monitoring", "status": "pass", "detail": {...} },
    { "framework": "NIST_AI_RMF", "control": "MANAGE-4.3", "title": "Incident response", "status": "pass", "detail": {...} }
  ],
  "fingerprint": "<sha256-hex>"
}

The bundle is signed with SHA-256 over its canonical JSON form. The fingerprint is the integrity check; if any byte changes after generation, the fingerprint stops matching.

What vis-verify does

The auditor downloads the pack and runs the open-source standalone Node CLI:

$ vis-verify pack.json
✓ MATCH
  file:         pack.json
  generated_at: 2026-06-26T15:23:01.234Z
  org_id:       org_arctrade
  schema:       v2
  evidence:     15 items (SOC2, ISO27001, ISO42001, NIST_AI_RMF)
  claimed:      ab12cd34...
  computed:     ab12cd34...

The verifier re-derives the canonical JSON form locally, computes the SHA-256 over it, and compares to the claimed fingerprint in constant time. Exit code 0 = match. Exit code 1 = mismatch (file was tampered with after generation, or schema version drifted; check schema_version). The verifier does not make a network call. The verifier does not contact Visionality. The auditor does not have to trust our dashboard. They trust the spec.

The verifier source is in the public repository: scripts/vis-verify.mjs. It mirrors the canonical-form function from packages/compliance/src/index.ts verbatim. If anyone changes one and forgets the other, the drift-check test fails on every release.

Why this changes the audit conversation

The standard SOC 2 Type II conversation goes:

  • Buyer: "Do you have SOC 2 Type II?"
  • Vendor: "Yes. Here's the report."
  • Buyer: "Can I see how you handle audit-log integrity?"
  • Vendor: "It's in the control description. CC6.1."
  • Buyer: "Can I verify the controls are still operating?"
  • Vendor: "Not until the next audit window."

The continuous-evidence pack conversation goes:

  • Buyer: "Show me your audit-log integrity in production."
  • Vendor: "Here's the evidence pack. Run vis-verify."
  • Buyer: "When was this generated?"
  • Vendor: "Just now. You can regenerate it any time, including on a cron, and the CC6.1 row will reflect the live role grants every time."
  • Buyer: "I need a quarter of these for the audit."
  • Vendor: "Set the cron. Drop the signed packs into your S3 bucket. The auditor reads them in order. Each one is independently verifiable."

The first conversation is procurement-grade. The second conversation is audit-grade. SOC 2 Type II is the procurement gate; the continuous-evidence pack is what walks the auditor across the gate.

Where Visionality's posture maps to the four frameworks

The twelve collectors split across the four frameworks like this:

  • SOC 2 (6 controls): CC6.1 logical access, CC6.6 PKCE consent audit, CC6.7 binding-status posture, CC7.2 audit-table census, CC7.3 MCP invocation log, CC8.1 migration ledger
  • ISO/IEC 27001 (3 controls): A.8.15 logging, A.8.34 protection during audit testing, A.5.34 privacy by design
  • ISO/IEC 42001 (2 controls): A.6.2 AI risk management, A.6.2.5 AI system impact assessment
  • NIST AI RMF (4 collectors): GOVERN-1.5 audit log policy, MAP-3.4 AI risk landscape, MEASURE-2.7 drift monitoring, MANAGE-4.3 incident response

Each collector reads live database state. Each emits a structured evidence row. Each row is included in the signed pack. The CSV variant of the pack (RFC 4180 + UTF-8 BOM + OWASP CSV-injection guard) is available for auditors who prefer spreadsheets.

How to evaluate any vendor's compliance posture in five minutes

If you're evaluating Visionality or any AI Control Plane vendor, these are the five questions to ask, in this order:

  1. Do you hold a SOC 2 Type II report? (Procurement gate question. Yes/no.)
  2. Show me an evidence pack. (Operational depth question. If they hand you a PDF, that's a posture artifact. If they hand you a JSON file you can re-derive a hash for, that's a continuous-evidence pack.)
  3. Where is the verifier source? (Trust-the-spec question. If the verifier is in a closed-source product, you're trusting them. If it's open-source on GitHub, you can audit the canonical-form algorithm yourself.)
  4. What other frameworks does the pack cover? (Regulated-vertical question. SOC 2 alone is the start; ISO 42001 and NIST AI RMF are the rising bar.)
  5. Run the verifier on a pack from a year ago. (Time-integrity question. If the year-old pack still verifies, you have proof that the bundle was not tampered with in storage. That's the answer for any regulated-vertical retention requirement.)

Three of those five questions have a meaningful answer from Visionality today. The fourth (frameworks) we lead the matrix on. The fifth requires you to keep the packs around for a year, which is a customer-side action — but the integrity property is shipped.

The structural argument

A SOC 2 Type II report is a point-in-time attestation by a CPA. It is necessary for enterprise procurement. It is not sufficient for the regulated-vertical audit conversation that comes after procurement.

A continuous-evidence pack with offline verification is what the auditor was always asking for. The combination of (a) deterministic canonical form, (b) SHA-256 fingerprint, (c) open-source standalone verifier, and (d) four-framework collector coverage is uniquely Visionality in the matrix today. Truefoundry has SOC 2 + HIPAA posture. Speakeasy has SOC 2 Type II + ISO 27001 posture. Neither has a productized continuous-evidence pack with an offline verifier. None of the MCP-niche entrants (Lunar.dev, Runlayer, MintMCP) have any of it.

If your audit committee is asking the structural-integrity question — and procurement-grade buyers increasingly are — Visionality is the answer.

Book a 30-minute walkthrough and we'll generate an evidence pack against a demo dataset and walk you through vis-verify live.

Companion read: Audit at the role, not the app — why the CC6.1 collector reads role grants at the database layer instead of trusting the application.

Visionality.AI

See how Visionality handles this.

30-minute demo. Live deployment. Your questions answered directly — no slides, no pitch.

Request a Demo← Back to articles