Building a SOC 2 Evidence Repository With Version Control

Most SOC 2 evidence repositories fail for the same reason, and it's a design failure, not a diligence failure. People treat evidence collection like paperwork, something you sort out before the audit, though it is really a process issue. The folder layout, how version control is managed, and how the pipeline is wired determine if a request for an auditor's sample gets handled in under five minutes or causes a two-week search across Slack threads and somebody's Google Drive.

What the Trust Services Criteria actually demand in terms of stored artifacts

Changed in 2017 and given new details during 2022, the AICPA's Trust Services Criteria list 33 Common rules for Security (CC1 through CC9), with add-on requirements covering Availability, Processing Integrity, Confidentiality, and Privacy based on what a firm scopes. Many SaaS teams still scope only Security, but the move is shifting: CBIZ’s 2024 SOC Benchmark Study saw confidentiality across SOC 2 audits at 64.4%, rising from 34% during 2023. Clients expect more scope than before, and firms that treat single-domain as their forever plan will face pressure at renewal.

Evidence tied to these standards takes a few forms. System-generated logs include app access logs, AWS CloudTrail, or its Azure and GCP equivalents, plus EDR scan records or antivirus files. Configuration details include exported firewall configurations, password policy setup, KMS encryption setup, and backup plans. Artifacts include change management tickets in Jira or Linear that show approval workflows, onboarding plus offboarding checklists, security notes, as well as incident post-mortems.

Mapped across a folder structure, this divides into buckets: evidence from HR (screening checks, returned handbooks, job offers), evidence on access (request tickets, termination tickets, quarterly access reviews), DevOps evidence (code review in pull requests, vulnerability scans and deploy logs), plus evidence from management (threat assessments, reviews of vendors, meeting notes).

Most groups mess this up, since nothing matters if metadata is missing. One screenshot lacking a timestamp, the system name, or any hint of who captured it proves neither when that control operated nor which person was accountable, so the auditor may treat it as nearly worthless. The screenshot becomes evidence when it includes a timestamp, the system name, plus who captured it. Making this change is free, yet it changes everything.

One emerging consideration for teams with AI systems: auditors may review CC9.2 (mitigation) for risk management practices related to model performance and third-party dependencies. Risk reviews should address third-party dependencies, including any AI or LLM tools used in operations.

Designing the repository folder structure around CC families

Centralize right away; treat it as anything but optional. When Evidence gets scattered through private disks, message attachments plus one-off Slack posts, gaps open that no one can fix, since half a year out, no person remembers the version that wrapped things up or who held access. The bare minimum is a centralized repository offering access control, versioning, plus an audit trail, not something to aspire toward.

Organize into CC groups, letting any auditor, a compliance staffer, or a tech manager handling a sample request get what they came for alone. One folder called /CC6_Access/ or /CC8_Change_Management/ shows right away the criteria it covers, while subfolders in each (screenshots, logs, plus tickets, exports) stop evidence blurring together.

Naming counts for more than you'd think it would. An auditor can't link a file called Report1.xlsx to any control or period. A file named HRIS_access_review_Q1_2025.xlsx handles that tracing on its own. Always follow one order: control, name, date, then what it covers. With log exports, name the file with its date range: siem_logs_2025-01-01_to_2025-01-07, stored in logs/weekly. That single practice cuts a whole set from auditor follow-up asks.

We should call out Timestamp integrity separately. When system clocks stay out of sync with a solid standard, disputes arise over when evidence got captured, and fixing them later is extremely hard. Add the date to each filename and within the file too, when possible.

Infrastructure separation isn't only some nice-to-have. Compliance evidence ought to live in one segregated GCP space or the AWS zone tagged Security and Audit, separate from your live systems. Keeping things separate cuts the damage radius: once live credentials are compromised, an attacker can't reach and start deleting those logs meant to expose any intrusion.

And each control needs one person responsible for it, who knows why it’s there and can respond to results. No group mailbox. Not "the compliance team." One person, whose name you can point to.

How version control transforms a folder of files into an auditable chain of custody

Load your configuration and policy materials into Git or a similar version-controlled system, and its commit history serves as the audit trail with no added effort from you. Git logs who touched each file and when, so no one has to reconstruct the history.

The commit log settles the key things an auditor checks. This proves the control existed on that date. It shows who approved a change and when. It also proves no unauthorized modification slipped in between dates, the very thing a Type II sample exists to test.

GitHub adds the controls that keep your trail solid during scrutiny. Every merge requires a reviewer to sign off. With CODEOWNERS, specific reviewers get tied to critical files, so nobody holding access can alter a rules page or control setup on their own. Stopping these pushes matters too: commit history can be rewritten and the proof of an unauthorized change erased, and letting that happen undoes the rest here.

Which tier you're on matters more than people think, and plenty of groups take a quick fix here that costs them later. An auditor expects enforced controls that the free tier won't provide. For compliance, GitHub's Team tier is where you realistically start, and higher tiers offer additional controls for audit readiness. A real evidence setup outgrows its free tier quickly, often sooner than people think. Splunk suggests groups without a complete Git-based pipeline begin with a version-controlled folder using something like Notion or Confluence, maybe Google Drive, treating that stopgap as a temporary fix rather than a permanent home.

Immutability serves as the trust marker above everything else. Customers running true diligence want logs nobody changes later, plus role-based access for evidence and a complete audit trail without gaps. They treat the way a vendor locks those records as the stand-in for its broader management commitment. Some GRC platforms create immutable audit logs to maintain evidence integrity throughout the audit period.

For exceptions, if a change skips the usual approval steps, like a rushed hotfix, record that retroactive sign-off inside the ticket rather than some Slack chat no one saves. Version history proves a change occurred. That ticket proves it was checked. No ticket means you only prove part of the case.

Wiring CI/CD pipelines into the evidence layer so change approvals are automatic artifacts

The failure that happens most often here is unintentional. Friction is why. Someone approves the pull request on GitHub, yet no one screenshots that approval. When a Jira ticket closes, nobody keeps it tied or linked to the deploy. The control ran as it was meant to, yet nothing exists to document it, so no auditor can accept a control that leaves no record.

Pipelines handle this by automatically generating that artifact during the build, not as an extra job anyone might forget. Integrations pulling from GitLab, Jira, or GitHub grab code review rule checks, test coverage numbers, plus security scan outputs on their own, before code ships. Each deployment makes its own immutable log, so nobody has to go get it. Approved pull requests plus CI/CD logs give every deployed change a record filed as traceable under /CC8_Change_Management/, logged ahead of the audit period's opening.

Several key checks should be enforced before any merge completes to ensure compliance. These may include review sign-offs, security scans, test coverage, and linked tickets with completed approval workflows. Once you nail those checks, your evidence shows up automatically.

Your pipeline configuration file counts as evidence, a point people miss all the time. A stored CI/CD config under version control proves an approval step was genuinely in place, not merely that one deploy got through.

Retention is what catches people by surprise most. Some Microsoft 365 environments may retain audit logs for limited periods, while a SOC 2 Type II observation period typically covers 12 months. If logs don't get routed into a long-retention store ahead of that 90-day window closing, early audit period evidence simply isn't around when the auditor asks. You can't go back and do it later.

Setting a cadence that keeps evidence current between audits, not just before them

Evidence that turned stale is almost as useless as evidence that wasn't there. Once an auditor asks about ownership of a quarterly access review, it becomes a finding if the reviewer quit 3 months ago without anyone taking over.

Here's roughly what a solid cadence looks like. Weekly, store SIEM log exports plus vulnerability scan findings in logs/weekly, putting each date range inside the name. Quarterly covers access reviews, checks of vendor documentation, plus controls review, planned early rather than getting squeezed right before any audit. Event-triggered or continuous: offboarding and onboarding checklists, change management tickets, incident post-mortems, each captured as things occur rather than pieced by hand long after the fact.

Like the folder structure, every control needs a single identified reviewer who can step in when something's gone, rather than an unnamed team or rotating group.

Vendor documentation remains an active dependency, rather than a one-time upload you file away. A significant share of 2024 breaches (35.5%) originated from third parties, according to Konfirmity. That's exactly why vendor SOC 2 reports, signed BAAs, and security questionnaire responses inside the repository need to reflect current status, not last year's renewal cycle.

Handled right, readiness is like this: if the auditor asks to see a sample from 28 in the observation period, that evidence is already kept in a repository, with a title, timestamped and linked to the control. Nothing reconstructed. No scramble.

Automation platforms that handle evidence collection at scale

Collecting by hand scales badly, and the pattern is predictable: with evidence disconnected, each audit cycle forces you into rebuilding documentation almost from nothing. Firms that messed up compliance in 2024 saw $2.8 million disappear on fines, post-breach cleanup, downtime, and people walking away. Automation platforms were built to solve that problem, and the stronger ones tackle multiple frameworks in one pass rather than running distinct collection efforts covering SOC 2, ISO 27001, HIPAA, then GDPR, plus PCI DSS.

Vanta connects to over 400 apps spanning cloud infrastructure, HR, code, plus security platforms, doing 1,400 or more automated hourly checks within 35+ frameworks. Its Agent reviews evidence, spots gaps, links controls, and writes policy suggestions, with every item such as audit asks, ownership of controls, and auditor access kept in one workspace. Vanta landed at No. 63 on the 2025 Forbes Cloud 100, its third consecutive appearance, and joined the 2025-2026 Fortune Cyber 60.

Scrut Automation pulls evidence by itself through 75-plus integrations, says it drops compliance work by 80%, and gets an organization ready for audit in fewer than six weeks.

Scytale connects to over 150 tools and covers over 80 frameworks, using automated checks for evidence review, plus user access reviews alongside vendor management. Because it maps controls between frameworks, evidence gathered a single time can be reused for SOC 2, ISO 27001, HIPAA, and GDPR, while Scytale adds staff who guide users past gaps ahead of a third-party audit.

Thoropass automates evidence collection, simplifies stakeholder updates during an audit, and makes compliance work continuously, not through bursts, to remove surprise fees and limit scope creep near the audit cycle.

AI makers and providers face one more layer of work before 2026. You have to keep immutable logging, something like Object Lock from S3, for learning sets, runs of fine-tuning, plus model builds, putting drift or fairness checks into the pipeline right alongside standard security scans. For firms with EU customers, the EU Act's general-purpose AI requirements, in force since August 2025, push that standard even higher.

For teams handling compliance for many customers, the same idea scales smaller: a single workspace, per-client control granularity, evidence exporting cleanly for each customer alone, not as an undifferentiated dump.

The operational posture that makes audit readiness continuous rather than cyclical

Most groups get ready for their audit. Going after that is a mistake: building a repository meant to handle one sample request during March isn't like running a system that creates evidence even when no one's watching, and calling them interchangeable throws your team into another frantic scramble across scattered notes plus makeshift tools every cycle. From the repository shown here, an auditor who asks gets a week-28 sample in moments. A person pulls the file. No rebuilding, no reverse-engineering from Slack, and nobody's chasing a device from an employee who departed months ago.

Being ready for an audit has zero to do with how a team performs just before an auditor arrives. What matters is if the evidence-generating system operated continuously, in silence, behind the scenes, regardless of observation.