Browse documentation
Docs/Compliance

Last reviewed 2026-06-10 - available

SOC 2 Evidence

Map Qortara governance evidence to SOC 2 Trust Services Criteria and audit workflows.

Verified against: Qortara pre-launch docs

Download PDFDownload Markdowncontent/docs/compliance/soc2.md

SOC 2 Evidence

Qortara is designed to map your AI agent governance to the SOC 2 Trust Services Criteria and to generate the evidence your auditor examines. Instead of compiling evidence by hand, you produce it from the actual runtime behavior of your agents: the allow and deny decisions, the policy versions behind them, and a tamper-evident record of the whole sequence.

> **Read this first.** Qortara does not hold SOC 2 certification or any third-party certification. Qortara does not issue a SOC 2 report and using Qortara does not make your organization compliant with SOC 2 or any other framework. What Qortara is designed to do is generate evidence that you can hand to your own auditor for the agent-governance portion of their examination. Your auditor (a CPA firm) determines whether your controls and evidence satisfy the criteria.

Availability

The export commands, compliance scans, and evidence endpoints on this page are part of Qortara Cloud Governance, the hosted control plane. That product is in pre-launch and has not been deployed, so the endpoints below describe the pre-launch design rather than a running service. The underlying governance decisions and their tamper-evident records are produced by the open-source Qortara Governance sidecar today.

Control Mapping

This table shows how Qortara governance evidence is designed to support specific SOC 2 controls. It is a mapping of evidence to criteria, not a certification.

SOC 2 ControlCriteriaWhat Qortara is designed to generate
**CC6.1**Logical and Physical Access ControlsEvidence that agents are restricted to authorized resources: a policy evaluation log showing allow and deny decisions per agent per resource pattern.
**CC6.2**System Access AuthenticationEvidence that agents are authenticated before accessing resources: auth enforcement records and agent identity verification.
**CC6.3**Termination ProceduresEvidence that deactivated agents can no longer act: agent lifecycle events showing deactivation followed by denial of subsequent access attempts.
**CC6.6**External Access ManagementEvidence that cross-organization interactions are governed: trust federation attestations and cross-org trust-score requirements in policies.
**CC7.2**System MonitoringEvidence that governance events are monitored in real time: webhook configuration showing the SIEM integration plus event delivery history.
**CC8.1**Change ManagementEvidence that policy changes are tracked and auditable: policy version history and a tamper-evident chain of every modification.

What Your Auditor Wants to See

A SOC 2 Type II audit covering an AI agent fleet typically asks for the evidence categories below. Each one shows what the auditor is checking and the pre-launch export command that is designed to produce it.

1. Policy Documentation (CC6.1, CC8.1)

**What:** your active policies and their version history.

# List all active policies
curl https://api.qortara.com/v1/policy/policies \
  -H "$AUTH_HEADER"

# Get version history for a specific policy
curl https://api.qortara.com/v1/policy/policies/pol_789ghi/versions \
  -H "$AUTH_HEADER"

**What the auditor verifies:** policies exist, are documented with descriptions, have version history showing when they were created and modified, and cover the access patterns in your agent fleet.

2. Access Decision Log (CC6.1, CC6.2)

**What:** a complete log of every policy evaluation over the audit period (typically 3 to 12 months).

curl "https://api.qortara.com/v1/portal/audit?start=2025-10-01&end=2026-04-01&limit=10000" \
  -H "$AUTH_HEADER"

**What the auditor verifies:** every agent action went through policy evaluation (no bypasses), deny decisions were enforced (the agent did not subsequently reach the resource), and the log is complete and tamper-evident.

3. Chain Integrity Proof (CC8.1)

**What:** verification that the audit trail has not been tampered with.

curl "https://api.qortara.com/v1/portal/audit/verify?offset=0&limit=50000" \
  -H "$AUTH_HEADER"
{
  "verified": 48723,
  "total": 48723,
  "valid": true,
  "first_break": null
}

**What the auditor verifies:** `valid` is `true` and `verified` equals `total`, meaning every event in the chain is intact. If `first_break` is not null, there is a tampered or missing event at that position, which is an audit finding.

4. Monitoring Configuration (CC7.2)

**What:** proof that governance events are being monitored, not just logged.

# Show webhook endpoints (SIEM integrations)
curl https://api.qortara.com/v1/portal/webhooks \
  -H "$AUTH_HEADER"

# Show delivery history (proof events are reaching the SIEM)
curl "https://api.qortara.com/v1/portal/webhooks/wh_abc123/deliveries?limit=100" \
  -H "$AUTH_HEADER"

**What the auditor verifies:** at least one webhook endpoint is configured and active, the delivery success rate is high, and the SIEM is actually processing the events (your auditor may ask for SIEM dashboard screenshots).

5. Compliance Scan History

**What:** the trend of your governance scan results over time.

curl "https://api.qortara.com/v1/compliance/reports?framework=soc2" \
  -H "$AUTH_HEADER"

**What the auditor verifies:** scans run regularly (at least monthly), results are stable or improving, and findings are remediated promptly (compare findings across consecutive scans).

Tips for a Clean SOC 2 Audit

  1. **Run governance scans at least monthly.** Weekly is better. A consistent trend is something auditors look for.
  1. **Remediate findings within 30 days.** If a scan flags a CC7.2 gap (no SIEM), configure a webhook endpoint. Auditors check that findings are addressed, not just recorded.
  1. **Keep at least three active policies.** This gives CC6.1 (logical access) real coverage and gives CC8.1 (change management) something to track. The built-in templates in the policy authoring guide are good starting points.
  1. **Configure at least one webhook endpoint.** Even pointing a webhook at a simple HTTP logger satisfies the monitoring intent of CC7.2.
  1. **Deactivate policies, do not delete them.** Auditors want the full history, including retired policies. Deactivation preserves the version chain.
  1. **Export everything about 30 days before the audit.** That gives your compliance team time to review the data and close any gaps before the auditor arrives.

What Qortara Does NOT Provide

Be honest with your auditor and with yourself about the boundary.

  • **Qortara does not provide a SOC 2 report.** It generates the evidence your auditor examines. The actual report is issued by your auditor, a CPA firm.
  • **Qortara does not cover all SOC 2 criteria.** It is designed to support the agent-governance-relevant criteria (CC6.1, CC6.2, CC6.3, CC6.6, CC7.2, CC8.1). Your overall SOC 2 posture also includes infrastructure, HR, physical security, and other areas that Qortara does not address.
  • **Qortara does not hold SOC 2 certification.** Qortara is designed to generate evidence for your audit. Qortara itself is pre-launch and has not completed its own SOC 2 examination, and nothing here should be read as a claim that it has.

Related

  • [Compliance Evidence](/docs/concepts/compliance-evidence): what an evidence record contains.
  • [Policy Authoring](/docs/guides/policy-authoring): write the policies whose decisions become evidence.
  • [Webhooks and Events](/docs/concepts/webhooks-events): stream governance decisions into a SIEM for CC7.2.