qodiqa
SpecificationRun a simulation
AICPA SOC 2 (identification only)

Frameworks · Standards and guidance

qodiqa and SOC 2

qodiqa checks each AI request before the call and keeps tamper-evident, offline-verifiable evidence. This page shows where that evidence supports SOC 2, and where it does not.

  • Standard
  • AICPA
  • Criteria 2017, points of focus 2022.
  • Verified 2026-11-01
Read the official textBack to all frameworks

Overview

What it is

AICPA SOC 2 (identification only)
Issuer
AICPA
Type
Standard
Status
Trust Services Criteria (2017), with revised points of focus (2022)
Official text
www.aicpa-cima.com

SOC 2, AICPA 2017 Trust Services Criteria. A SOC 2 report is an independent auditor’s opinion on a service organisation’s controls against the AICPA Trust Services Criteria: security, availability, processing integrity, confidentiality and privacy. It is an attestation by a licensed CPA firm, not a certification.

Who it applies to. Service organisations that hold or process customer data and need to give customers assurance about their controls.

Where it meets qodiqa

The parts of SOC 2 where the evidence matters.

Record-keeping and logging

A tamper-evident record of the gateway’s decisions that an auditor can sample.

Robustness and security

Access control and checks before the call for the security category.

Accountability

Signed receipts give an auditor evidence that is checkable offline.

Traceability

Each decision is tied to a request id and hash an auditor can sample.

Risk management

Metrics and alerts support ongoing monitoring of the system.

Human oversight

Revocation and a kill switch support access removal and incident response.

Mapping

What qodiqa provides, and what stays with you.

Requirement or controlWhat qodiqa providesWhat stays with you
Theme Security (common criteria): protection against unauthorised access, logical access controls and system monitoring.Per-actor keys, role-based operator access, checks before the call, a tamper-evident record and metrics with alert rules.The control environment, risk assessment and monitoring of your own systems.
Theme Availability: the system is available for operation as committed.Health and readiness endpoints, backup, restore and disaster-recovery runbooks for the gateway.Your availability commitments. The supported production deployment is one gateway instance, with no clustering or automatic failover.
Theme Processing integrity: processing is complete, valid, accurate, timely and authorised.Authorisation before the call, request binding and a signed receipt for each decision. Binding means the request that was authorised is the request that ran.Accuracy of the model’s output, and completeness of processing in your application.
Theme Confidentiality: information designated as confidential is protected.Encrypted keys at rest and tenant isolation enforced by the application.Classifying and protecting confidential information in the rest of your systems.
Theme Privacy: personal information is handled in line with commitments.A data-subject-request framework, lawful-basis and consent records and retention settings.Your privacy notices, commitments and the processes behind them.

The criteria document sits behind an AICPA account, so this page names categories and does not quote criteria numbers. Check each category against the AICPA text.

The specification’s Regulatory Alignment Matrix does not cover SOC 2. This page maps the gateway documentation only.

How it fits

What SOC 2 asks, and what qodiqa produces.

  1. Security (Common criteria) is supported by Per-actor keys and checks (Before the call).
  2. Processing integrity (Category) is supported by Request binding and receipts (Authorised request = request that ran).
  3. Evidence for the audit (Attestation) is supported by Tamper-evident record (Sampleable by an auditor).

Evidence

Evidence you can hand to an auditor.

Five artifacts, each checkable on its own

  • Consent artifact Signed with Ed25519, bound to one request, single use.
  • INTENT entry The audit entry written before the provider call.
  • Receipt A signed decision record that checks offline.
  • Audit export Hash-chained entries with a Merkle inclusion proof.
  • Anchor proof A signed checkpoint pinned outside the gateway.
Verify offline, from a clone of qodiqa-verify
node bin/verify.bundle.external.js \
  --keys examples/front-half/keys.json \
  --transparency-keys examples/front-half/transparency-keys.json \
  examples/front-half/bundle-with-proof.json

The example files ship with the repository and are signed with throwaway keys. The command exits 0 and prints "valid": true. For your own evidence, take keys and anchors from a source other than the gateway that wrote it.

Scope and limits

Scope and limits

Technical evidence, not a compliance outcome

qodiqa produces verifiable technical evidence that supports parts of SOC 2. It is not a compliance certification, it is not legal advice, and no regulator or standards body has endorsed it. Whether your use meets SOC 2 is a decision for you and your advisers.

What qodiqa does not address:

  • The audit itself: an independent CPA firm issues a SOC 2 report, not qodiqa.
  • Organisation-wide controls such as HR, change management and vendor management.
  • Criteria numbering, which sits behind an AICPA account and is not quoted.
  • Only requests that pass through the gateway are checked, and a receipt proves a decision was recorded, not that it was correct.

Sources

Sources

Article, clause and control references were read in the official texts listed first. The remaining links are qodiqa’s own documents. Checked on 2026-11-01; rules change, so read the current text.

Next steps

See the evidence for yourself.

Read the spec sectionRun a simulationQuickstart