SOC 2 Evidence Collection: A Source-to-Review Workflow

SOC 2 evidence collection should turn control work into records that another person can trace back to the source. Saving a file is one step. A usable process also records which control the item supports, where it came from, what date or period it covers, who collected it, what management concluded, and who checked the result.

TL;DR

• Start with the scoped controls, not a generic evidence folder.
• Catalog each authoritative source and test its export before relying on an evidence period.
• Keep the operating record separate from the source artifact when they answer different questions.
• Match collection timing to scheduled, event-driven, and point-in-time controls.
• Preserve complete Type 2 populations before the CPA firm selects samples.
• Review source, scope, dates, sensitive data, and exceptions before delivery.

What is SOC 2 evidence collection?

SOC 2 evidence collection is the work of preserving records and artifacts that support management’s description of its system and controls. It is part of an assertion-based examination performed by an independent CPA firm.

The AICPA describes SOC 2 as an examination of controls at a service organization relevant to security, availability, processing integrity, confidentiality, or privacy in its SOC suite of services. Its Trust Services Criteria provide the criteria used to evaluate those controls. This means the evidence plan depends on the company’s scoped system, selected criteria, risks, commitments, and implemented controls.

Evidence collection is different from an audit request list. Collection happens as the company operates controls. A request list tracks what the CPA firm asks management to send during fieldwork. It is also different from a delivery packet, which packages approved records and artifacts at a fixed Git revision.

Build the collection map from controls

Start with each implemented control and ask what record would show that it operated as written. Avoid beginning with a long list of standard screenshots. The same artifact may be useful for one control and irrelevant to another because the system, scope, date, or review is different.

For each control, record:

1. Record what happens, who performs it, and whether the activity is continuous, scheduled, or triggered by an event.
2. Name the systems, people, vendors, data, locations, or changes in scope.
3. Define where management records the decision, result, exceptions, and follow-up.
4. Identify the authoritative system that operated the control or produced the source data.
5. Define the export, report, ticket, signed record, capture, or other fixed artifact that supports the activity.
6. Save the report name, filters, query, account, environment, timezone, and person with source access.
7. Define who reviews the artifact, what they check, and how they record exceptions.
8. State where the item belongs, how long it must be kept, and whether it contains sensitive data.

This map belongs in the control and source-system design before a candidate Type 2 period starts. The SOC 2 compliance checklist for startups places that work between control implementation and dated operation because a team cannot collect a report that its source system does not retain or export.

Catalog the source before collecting files

An evidence source is the system that can answer the control question. An identity provider may supply users, roles, grants, and removals. A deployment system may supply releases and production timestamps. A training system may supply assignments and completions.

For each source, name:

• the bounded system and controls it supports;
• the types of evidence it can produce;
• the people who can access the report;
• the exact retrieval steps and filters;
• the available timestamps and timezone;
• the retention window and known gaps;
• the approved destination and data classification.

Test the retrieval steps before the period begins. Confirm that the export has stable identifiers, the required dates, the correct environment, and enough history. If two source systems cover different parts of the same activity, record both boundaries instead of merging them under an unclear label.

filegrc models each authoritative source as a Component. The Control links to the Components that can produce evidence, and the Component’s Markdown keeps the retrieval instructions. filegrc evidence-map --json reports missing source roles, access owners, and instructions so an engineer or agent can fix the map before collecting artifacts.

filegrc does not sign in to those systems or fetch their data. Identity, cloud, endpoint, monitoring, backup, source-control, and workforce tools remain the systems that operate controls and produce source facts.

Separate the result from the artifact

Many control activities need two connected records:

Record	What it answers	Example
Operating record	What did management do, decide, find, and approve?	An access review with scope, reviewer decisions, exceptions, remediation, and approval
Source artifact	What fixed data or output supported that work?	The user and role export examined during the review

The distinction matters because a user export does not say who reviewed it or what they decided. An access review record without the reviewed source cannot show which accounts and roles were in scope.

The same pattern applies to change approvals and deployment output, vulnerability reviews and scan reports, vendor decisions and third-party reports, or restoration tests and backup-system output.

FileGRC records dated work inside the repository as normal operating records. It uses an Evidence Artifact for a retained export, report, screenshot, signed record, fixed file, or approved external reference. Connect both to the same control and audit when both are needed.

Record enough context for someone else to review it

A filename such as users-final.csv cannot explain its source or scope. Record the context when you collect the artifact, while the collector still knows how it was produced.

At minimum, keep:

• a stable title and evidence kind;
• source description and authoritative source Component;
• collection date and collector;
• related controls and systems, plus operating records and an audit when applicable;
• as-of date or covered period;
• report, query, filters, environment, timezone, and generation time when relevant;
• fixed file path, approved external reference, or repository revision;
• data classification and handling limits;
• verifier and verification date when the item is marked verified.

The AICPA’s FAQ on SOC 2 software tools says management is expected to evaluate the accuracy and completeness of information produced or maintained by a tool. Keeping the source and collection facts with the item helps management perform and explain that work. The CPA firm still decides whether the evidence is sufficient and appropriate for its procedures.

Example Evidence Artifact

This shortened example records a fixed access export. The source Component holds the reusable retrieval instructions, while this record binds one actual artifact to its collection and review facts.

{
  "id": "evidence-quarterly-access-export-2026-q2",
  "type": "evidence",
  "title": "Quarterly Access Export, 2026 Q2",
  "status": "verified",
  "artifactKind": "system-export",
  "sourceKind": "file",
  "sourceDescription": "User and role export for the production tenant",
  "collectedOn": "2026-07-02",
  "systemIds": ["system-production-service"],
  "controlIds": ["control-quarterly-access-review"],
  "sourceResourceIds": ["access-review-2026-q2"],
  "coverage": {
    "kind": "range",
    "startsOn": "2026-04-01",
    "endsOn": "2026-06-30"
  },
  "collectorIds": ["person-access-administrator"],
  "verifierIds": ["person-security-reviewer"],
  "verifiedOn": "2026-07-03",
  "componentIds": ["component-identity-provider"],
  "filePaths": [
    "evidence/evidence-quarterly-access-export-2026-q2/users-and-roles.csv"
  ],
  "classificationId": "classification-internal"
}

Use fictional values in examples and test workspaces. Do not put credentials, session data, customer data, or personal data that may need later erasure into Git.

Match collection timing to the control

Collection frequency should follow the control, not a universal calendar.

Event-driven work

Collect the record when the event occurs. Access grants, terminations, production changes, incidents, vendor onboarding, and exceptions lose context when reconstructed months later. Link the request, approval, execution, result, and supporting source output while their identifiers and timestamps are available.

Recurring work

Schedule evidence for activities such as quarterly access reviews, annual risk assessments, policy reviews, training, vulnerability scans, and restoration tests. Each occurrence should have a deadline, owner, covered scope, result, evidence, reviewer, and any follow-up. The SOC 2 recurring compliance tasks guide shows how to turn policy cadence into due work without copying generic checklists into every record.

Point-in-time configuration

Capture configuration at the date that matters, with the account, environment, setting, and collection time visible or recorded. If a screenshot omits those facts, add collection notes or an export. A current capture cannot prove what a setting was six months earlier unless the source keeps history that supports the claim.

Continuous sources

Logs and automated exports may run continuously, but management still needs to define which output supports the control, confirm coverage, review failures, and retain the relevant result. Automation can reduce repeated retrieval work. It does not supply management’s scope or conclusion.

Handle Type 1 and Type 2 coverage differently

A Type 1 examination addresses control design and implementation as of a specified date. Collection should support the scoped system, control design, and implementation at that date.

A Type 2 examination also covers operating effectiveness over a specified period. Evidence must follow the control’s actual cadence and events across that period. One end-of-period capture cannot stand in for each quarterly review, access removal, production change, or exception that occurred earlier.

For controls the CPA firm may sample, management should preserve the complete population before sample selection. Keep one source and repeatable query per population when possible. Record the exact period, query or report parameters, generation time, timezone, count, fixed export, and management’s completeness and accuracy checks. A zero count needs the same source and boundary facts.

Management prepares and reconciles the population. The CPA firm chooses its samples and testing approach.

Review each item before audit delivery

Use a separate reviewer for evidence marked verified when the company has an available person with the needed knowledge and authority. The reviewer should check the artifact against the control and collection map, not only confirm that a file opens.

Ask:

1. Does the item come from the recorded authoritative source?
2. Does it cover the right company, tenant, environment, systems, and people?
3. Does the date or period match the control occurrence and audit?
4. Are the query, filters, timezone, and exclusions recorded?
5. Can the artifact be tied to the operating record and its result?
6. Are exceptions and corrective work visible rather than edited out?
7. Does the artifact exclude secrets and data that the approved recipient does not need?
8. Is the fixed file or approved reference available under the retention plan?

Mark gaps as gaps. Recollect an incorrect export when the source still permits it, explain a known limitation, and create corrective work when a control did not operate as designed. Do not alter source evidence to make the result look clean.

Keep collection, fieldwork, and delivery connected

A clean handoff follows one chain:

policy requirement
  -> implemented control
  -> authoritative source
  -> operating record and source artifact
  -> management review
  -> Type 2 population when applicable
  -> CPA request and approved response
  -> fixed delivery packet

That chain makes a missing link visible. A policy with no implemented control is a design gap. A control with no source cannot support repeatable collection. An artifact with no operating result cannot explain what management concluded. A few clean samples without a complete population cannot establish the source set.

filegrc keeps these relationships in plain JSON and Markdown and uses Git for file history. It can calculate readiness, find broken references, schedule work, and prepare an indexed packet with checksums at a committed revision. It does not operate controls, fetch external evidence, choose audit samples, or replace the CPA firm’s judgment.