SOC 2 Evidence Repository: What Belongs in Git?

A SOC 2 evidence repository should tell a reviewer what happened, where the source data lives, which fixed artifact was preserved, who checked it, and what date or period it covers. It should not become a copy of every live system. Before your first evidence period, separate reviewable program records from restricted evidence and source data that should stay where it was created.

For the full program layout around those evidence records, see the SOC 2 repository structure guide.

TL;DR

• Keep live identity, cloud, source control, monitoring, workforce, and vendor data in their authoritative systems.
• Keep structured evidence records and review notes in the GRC workspace.
• Store a fixed artifact in Git only when repository access, retention, deletion, size, and backup rules fit the file.
• Never retain credentials, private keys, tokens, recovery codes, or session material as evidence.
• Use a restricted evidence store for high-risk personal data, incident material, and records that may need erasure, after removing secrets.
• Record a safe external reference when the artifact must remain outside Git.
• Preserve source, scope, query, dates, collector, verifier, and coverage for every retained artifact.
• Review the final delivery set with the CPA firm instead of giving it the entire internal repository.

What is a SOC 2 evidence repository?

A SOC 2 evidence repository is the controlled system, or set of connected systems, used to organize evidence for management and the CPA firm. The repository needs more than folders of screenshots. It needs enough context to connect each artifact to the control activity, source, date or period, person, review, and audit request it supports.

The AICPA describes SOC 2 as an examination of controls relevant to security, availability, processing integrity, confidentiality, or privacy in a service organization’s system. Its SOC 2 guide is written for CPAs who perform and report on the examination. Management’s evidence repository supports that work. It does not set the CPA firm’s procedures or replace the firm’s judgment.

That division matters for storage design. Your internal repository should help management operate and review the program. The delivery channel should contain the evidence the CPA firm requests for the engagement. They do not have to be the same system.

Use four evidence layers

Most startups need four layers rather than one shared evidence folder:

Layer	What belongs there	Example
Authoritative source	Live data and native history	Identity directory, deployment system, ticketing system, cloud console
Program record	Control activity, owner, dates, result, source, review, and exceptions	Access review record linked to its source export
Fixed artifact or reference	The exact export, report, screenshot, signed file, or approved external locator	CSV export in Git or a restricted-store reference
Audit delivery	The scoped records and files requested for one examination	Approved packet sent through the CPA firm’s secure channel

The source system operates the control and holds its native data. The program record explains the activity and management’s review. The fixed artifact preserves the version used for that review, or points to an approved immutable copy outside the repository. The delivery layer limits what leaves the company for fieldwork.

Do not treat a sync or copied folder as a new source of truth. Record which system is authoritative and why the retained artifact represents the right scope and period.

Decide where each evidence class belongs

Use the same placement test for every evidence class:

1. Is this a live record or a fixed representation?
2. Could it contain credentials, session material, private keys, tokens, or recovery codes?
3. Does it contain customer, workforce, incident, vulnerability, legal, or other sensitive data?
4. Could law, contract, privacy policy, or a data-subject request require deletion?
5. Is every person with repository access allowed to see it?
6. Does approved encryption protect the remote, network path, local clones, CI workspaces, mirrors, and backups, with keys managed outside the evidence?
7. Can the company apply its retention and disposal rules to every clone, backup, mirror, and delivery copy?
8. Is the file size and format suitable for the repository and review tools?
9. Can another person verify its source, scope, query, time, and completeness?

If the evidence fails the secrets, access, encryption, deletion, or copy-control tests, keep it outside Git. If it passes, a fixed artifact may live beside its structured evidence record in a dedicated private repository.

Storage decision matrix

Evidence	Default location	Keep in the program record
Current user directory	Identity system	Source Component, retrieval method, scope, query, collection date
Quarterly user export	Git or restricted store, based on classification	Fixed path or external reference, item count, coverage, collector, verifier
Pull request and deployment history	Source control and deployment systems	Population method, period, reconciliation result, exceptions
Policy approval	GRC operating record and exact approved revision	Approver, approval date, revision, activation facts
Incident investigation files	Restricted incident system	Safe incident reference, classification, dates, owner, review result
Penetration test report	Restricted store unless repository access fits	Provider, scope, report date, classification, approved reference
Backup job history	Backup platform	Export method, covered systems, period, failures, review
Plaintext secret or token	Nowhere as evidence	Record that the configuration was checked without copying the secret

This table is a starting point. Management still chooses the actual system, classification, retention rule, access group, and disposal method for each record class.

When Git is a good evidence repository

Git works well for evidence that benefits from exact revisions and diff review:

• structured records with stable IDs and explicit business dates;
• Markdown policies, procedures, minutes, and review notes;
• small fixed exports or reports approved for repository storage;
• links among controls, source systems, operating work, evidence, and audit requests;
• changes that a reviewer should approve before they become part of the program record.

Git stores the commit time, author and committer metadata, and exact diff. That metadata supports review, but it does not prove a person’s identity by itself. Use authenticated repository access and signed commits or an equivalent verification method when attribution matters. These Git facts also do not replace domain dates. An access review completed on September 18 still needs that completion date even if someone commits the record on September 19.

Use a dedicated private repository, least-privilege access, protected review rules, encrypted transport, encrypted local devices and backups, keys managed outside the repository, and a tested restore process. Review repository membership and connected automation because each clone, CI job, backup, and integration can create another copy of the evidence.

What should stay out of Git

Do not commit:

• plaintext passwords, API keys, private keys, tokens, session data, or recovery codes;
• live customer or workforce datasets copied only for convenience;
• personal data that may need correction or erasure;
• unrestricted incident, legal, vulnerability, or investigation material;
• evidence that exceeds the repository’s approved access, retention, or disposal rules;
• files whose license or contract does not allow repository storage.

A private repository does not make every file appropriate for Git. Git is designed to preserve and distribute history, which can conflict with later deletion.

The official Git documentation for .gitignore states that ignore rules do not affect files already tracked. GitHub’s sensitive-data removal guide warns that removal requires coordinated history rewriting and that copies may remain in clones, forks, pull requests, caches, or other references.

If a secret enters Git, rotate or revoke it first. Then follow the hosting provider’s removal process and check every managed copy. Do not add a .gitignore rule and assume the earlier commit disappeared.

Record context even when the file stays elsewhere

An external reference should remain useful after the person who collected the evidence leaves. Record:

• the authoritative system or Component;
• a safe locator that does not expose a credential or expiring secret;
• the artifact kind and description;
• the collection date and source generation time;
• the covered date or period;
• report filters, query parameters, timezone, and item count when relevant;
• the collector and verifier;
• the linked controls, operating records, and audit;
• classification, retention class, expiry, and withdrawal facts;
• completeness and accuracy checks.

Avoid a bare URL to a live dashboard. It may show different data later, expire, or depend on access the reviewer does not have. Preserve a fixed approved copy when policy permits, or use a controlled immutable location and record how to retrieve the exact version.

Set retention before the evidence period

Do not wait for fieldwork to decide how long evidence stays. Build a retention schedule by information type and storage system. Each rule should name:

• the covered evidence class and scope;
• the event that starts the retention clock;
• the approved period;
• any legal hold or exception process;
• the disposal action;
• the owner and approver;
• how disposal is verified across the main store, clones, backups, and delivery copies.

There is no sound universal period for every SOC 2 artifact. The answer depends on law, contract, privacy duties, company policy, business need, the report cycle, and the CPA firm’s planned work. Keep unknown values as management decisions rather than copying a number from a template.

Test retrieval and disposal. A retention rule that cannot find every copy is not yet an operating process.

Build a reviewable repository structure

In a file-based workspace, keep the evidence record and any approved attachment together:

data/
├── controls/
│   └── control-quarterly-access-review.json
├── access-reviews/
│   └── access-review-2026-q3.json
└── evidence/
    └── evidence-access-review-2026-q3/
        ├── evidence.json
        └── access-review-export.csv

The structured evidence record should link the export to its source Component, control, operating record, collector, verifier, classification, and period. The CSV should be a fixed approved copy, not the only record that the review happened.

If the CSV contains material that should not enter Git, keep the same evidence.json record but use an approved external reference instead of a file path.

Test the repository before relying on it

Run one real evidence workflow before the planned period:

1. Choose a recurring control such as an access review.
2. Identify its authoritative source and full population.
3. Export the population using a recorded query and timezone.
4. Classify the artifact and run the storage decision test.
5. Store the fixed file or approved external reference.
6. Record source, scope, period, count, collector, and review.
7. Have a second person retrieve and verify the exact artifact.
8. Prefer sanitized test data for recovery tests that do not need real evidence.
9. When a full-data restore is required, authorize it and use an isolated nonproduction location with equivalent encryption and access controls, no writes to authoritative systems, and access logging where policy requires.
10. Verify the restore, then dispose of the test copy under the approved process.
11. Produce a delivery copy without exposing unrelated records.
12. Test disposition on nonproduction evidence.

This test finds missing access, unclear ownership, expiring links, incomplete exports, and retention conflicts before they affect a real period.

How FileGRC manages evidence storage

FileGRC is a Git-native GRC workspace for SOC 2 work. JSON holds structured records, Markdown holds long-form work, and Git supplies the change history.

FileGRC Evidence Artifacts can represent a retained export, report, screenshot, signed record, fixed file, rendered page, authored record, or approved external reference. An Evidence Artifact can record its source Component, linked controls and operating records, collection and verification facts, classification, coverage, file paths, or external reference.

Use the CLI to inspect the current model and evidence coverage:

npx filegrc guide evidence --json
npx filegrc evidence-map --json
npx filegrc list evidence --workflow --json
npm run validate

File attachments live under data/evidence/<evidence-id>/. CLI commands can change workspace files, but they do not create Git commits, so review the exact diff and stage only approved paths.

FileGRC does not log in to external systems or collect evidence automatically. It does not decide whether an artifact is sufficient for the examination. Starter records are proposals. Your team chooses what to collect, where to store it, how long to retain it, and what to send, while the independent CPA firm performs the examination and evaluates the evidence.

Design the repository before the first real collection. That keeps a convenient evidence folder from becoming an uncontrolled archive.