The audit trail your SOC 2 Type II auditor already wants to see — generated as a side effect of the tested PR review.
Trust Services Criteria CC7, CC8, and CC9 turn dependency-risk and change-control into auditable controls. Bivouac records every CVE → fix → test → review state with a deterministic hash, then bundles a signed export per quarter. The auditor replays the file; same input, same root, byte for byte. Evidence for your audit, not a Bivouac certification.
TSC CC mapped to the review log
What SOC 2 asks for, and what Bivouac already records.
The controls on the left are Trust Services Criteria CC7 / CC8 / CC9. The matchings on the right are what your auditor replays when they ask for evidence — already captured per review, no end-of-quarter rebuild required. Bivouac supports your SOC 2 evidence workflow; Bivouac is itself not certified against the framework.
- CC7.1
System operations — detect / respond to vulnerabilities and upstream changes
A new CVE or upstream breaking change fires a signal within minutes. The policy pack pre-classifies the move (forward fix, downgrade, pin), and the review row carries the upstream disclosure date and the review timestamp — so the auditor can verify the signal-to-review clock on every row.
- CC7.2
Anomaly detection & response — a process for identifying and dispositioning CVEs
Each review row IS the disposition record: test outcome, policy-pack decision, approval status, and the review-wait / paged-human / declined classification. There is no separate log to reconcile — the disposition is the row.
- CC8.1
Change management — authorize, test, and document changes to the system
Patch PRs open against the actual repo and run the actual test suite; green results make them ready for human approval. The full chain — signal, policy-pack decision, test run, review state — is one signed row per CVE, not a separate paper trail to keep aligned with the code.
- CC9.1
Risk mitigation — identify, select, and develop risk-mitigation activities
Forward fix, downgrade, and pin are pre-classified per policy pack; the chosen direction is recorded on the review row BEFORE code is touched. License-sensitive and security-sensitive moves stop at a human; the approval decision is itself a row in the bundle.
- CC9.2
Vendor & supplier risk — assess and manage third-party providers and upstream components
A transitive SBOM rollup is generated per quarter from what actually shipped — vendor, version, parent edge, and support-period stamp are in the same signed root. The auditor doesn't have to ask for the SBOM separately; it ships with the change-control evidence.
- CC4.1
Continuous monitoring — ongoing evaluation of system and configuration changes
A daily triage cron opens a patch PR within minutes of a signal; the public /activity feed is the live evidence stream; the quarterly signed attestation is the bounded-period snapshot. Continuous monitoring stops being a separate program to staff.
Proof, not a promise
One signed bundle per quarter — replayable, hash-verifiable.
Pick a connected repo and a calendar quarter from /dashboard/attestand download the bundle. Every CC7 / CC8 / CC9 patch event, test outcome, merge vs human override, CVE id, and SBOM rollup is in the same JSON — and on the cover of the branded PDF. The attestation hash is deterministic, so the same data always hashes to the same root. Your auditor's replay matches yours, byte for byte. Bivouac produces the evidence; the certification is your team's, earned in your audit.
Quarter-scoped, deterministic-hashed, downloadable as JSON or PDF. The bundle is the artifact your Type II auditor replays — Trust Services Criteria coverage, decision provenance, and SBOM provenance all live in the same signed root.
Continuous monitoring — the live stream
What the agent did, just now — public, signed timestamps, no sign-in to inspect.
CC4.1 (continuous monitoring) is the cheapest control to claim and the hardest one to evidence. Bivouac publishes a live, per-row trail at /activity — every triage, test, and merge decision stamped as it happens. No login required to inspect.
From signal to SOC 2 evidence
Four steps run end to end — the same trail your Type II auditor replays.
Nothing on this list is reconstructed at the end of the quarter. Every step is a row in the signed bundle, in order, with the policy-pack decision and the SBOM provenance/per-build software-bill-of-materials attached to the last one.
- 01
Signal fires
New CVE, upstream breaking change, or package-registry advisory on a watched repo. The signal carries the upstream disclosure date and severity so the SOC 2 signal-to-fix clock on CC7.1 starts from a real timestamp, not a quarterly narrative.
- 02
Policy pack decides
Forward fix, downgrade, or pin chosen locally — license posture, peer usage, and security-sensitive surfaces reviewed BEFORE any code is touched. The chosen direction is recorded on the merge row before the PR exists, satisfying CC9.1 risk-mitigation at the source.
- 03
Test outcome recorded
Project test suite runs against the draft PR; pass/fail attaches to the review row, not just a resulting commit. The row proves the change was tested and handed to a human for approval.
- 04
Review or human escalation
Green tests produce a reviewable PR; security-sensitive surfaces and license-sensitive moves stop at a human. The approval is itself a row in the bundle (CC7.2) — the vendor, version, parent edge, and support-period stamp per review are the SBOM provenance for CC9.2.
SOC 2 buyer questions
The questions your Type II auditor and your VP Security will ask first.
Bivouac produces the evidence your team hands to the auditor — it isn't itself SOC 2 certified.
Generate, sign, ship
Generate your first SOC 2 signed attestation this quarter.
Connect a repo, review a tested patch, and the bundle hashes itself. By the time your Type II auditor opens the export, the file is already self-verifying. Bivouac produces the evidence your team hands to the auditor — it isn't itself SOC 2 certified.
Free for the first repo. No card to start.