SOC 2 evidence collection: what auditors accept

What SOC 2 evidence collection requires and why screenshots rarely pass

When a customer or contract asks for a SOC 2 report, the team has to prove that its controls operated, and the auditor needs evidence that is complete, dated and traceable to the system that produced it. Screenshots and verbal confirmations seldom meet that bar on their own, because a picture cannot show what was queried, when, for which population, or whether anything was left out. The organization owns its controls and its evidence. An implementation partner such as DeployOpen can configure systems, logging and collection routines so that evidence is generated as a by-product of normal operation, but only an independent CPA firm examines that evidence and issues the report.

Start by listing each control in your control matrix and asking what the auditor would sample for it. For access reviews, that is usually a system-generated export of users and roles with its query parameters and timestamp, plus the reviewer's sign-off and the removal tickets. For change management, it is the pull request, the approval record and the pipeline run that deployed it. Pipeline artifacts such as a scan report saved by the CI system are stronger than a dashboard screenshot because the file carries its own metadata. Confirm with your CPA firm which population and sample sizes it will use before you decide how each report is exported, since a list that cannot be reproduced for the same date range will be questioned.

The difference between a Type 1 and a Type 2 report changes what the evidence has to cover. A Type 1 examines the design of controls as of a single date, so evidence is a snapshot. A Type 2 covers operating effectiveness over a period, so every control must leave records throughout that window, and the auditor will test samples from across it. Ask whether your ticketing, identity and deployment tools retain history for the full period. If they overwrite configuration or purge closed tickets, you need an export routine that runs on a schedule and stores results in a location the team controls, or the gaps will appear only when the auditor asks for March.

Which evidence types survive auditor testing

This table compares the evidence types a SOC 2 auditor may accept, from system-generated reports to interview notes. Read each row for what the evidence proves, how the auditor checks it is complete and dated, and when it can only support other evidence. The main takeaway is that the strongest items show the system's own state and history, while screenshots and inquiry rarely carry a control alone.

Evidence type	What it proves	How an auditor checks completeness and dating	Acceptable use
System-generated reports	The configured state of a system or a list of accounts, settings or results at the time it was run	Confirm the report came from the system, check the query or parameters, and compare totals to a second source such as the identity directory	Primary evidence for access lists, configuration and population testing when the report is reproducible
Exported tickets	That a request, approval, removal or exception was raised, decided and closed by named people on recorded dates	Check ticket timestamps, approver identity, workflow history and that closure matches the underlying change in the system	Primary evidence for approvals and joiner or leaver events when the workflow history is preserved
Pipeline artifacts	That a change passed defined build, test, scan and approval steps before deployment, tied to a specific commit	Match the commit, pipeline run, approval record and deployment event, and confirm the artifact is retained unaltered	Primary evidence for change management and secure development when the pipeline enforces the steps
Policy engine reports	Pass, fail, warn or skip results for each resource against a defined rule, from admission events or periodic scans	Confirm the policy version, the scan scope and that results cover all matching resources, not only those that failed	Strong support for configuration controls, and primary evidence when the rule set and scope are documented
Screenshots	A moment in time as displayed to one person, with no record of the query, the user or the full population	Hard to verify completeness or dating, since the auditor cannot re-run the view or see what was filtered out	Supporting only, typically to illustrate a setting already evidenced by a system report or export
Interview notes and inquiry	Management's or staff's description of how a control works, which the auditor records as an understanding	Cannot be checked for completeness on its own, so auditors corroborate it with inspection of records	Supporting only; a control described in an interview still needs inspectable records to be tested
Signed documents and attestations	That a person accepted a policy, reviewed an item or acknowledged a responsibility on a date	Check signer identity, version signed, date and that the document matches the approved policy in force	Supporting evidence for awareness, review and acceptance controls, not proof that the control operated

What automation platforms can and cannot do for SOC 2 evidence

Compliance automation platforms and self-hosted pipeline tools can collect records at scale and show control owners where work is outstanding. They cannot decide whether a control was designed well or operated, and the auditor still needs the underlying records to test it.

Connecting to source systems

Most platforms use API connectors to read identity providers, cloud accounts, code repositories and ticketing systems. Pulled data is only as complete as the connector's scope, so confirm which fields, projects and accounts each connector reads and whether it captures historical state or only the current snapshot. Ask the vendor in writing which systems are covered and which need manual upload.

Dashboards and control status

A dashboard can show which controls are passing, overdue or missing an uploaded file. That view helps control owners act between audits. A green status reflects a rule the tool evaluates, not proof that a person reviewed the change or removal, so check what the status is actually measuring before treating it as assurance.

Tracking control owners and reminders

Platforms assign owners, due dates and recurring tasks for activities such as access reviews and policy acknowledgments. This keeps the calendar honest. Ownership does not show the task was done well, so keep the signed review, the list of reviewers and the removals made as records the auditor can sample.

Automated pipeline and scanner output

Self-hosted pipelines can keep scanner results as build artifacts. GitLab SAST, for example, runs open-source analyzers on each commit and saves the findings as a JSON report job artifact. Confirm that retention settings keep artifacts for the whole examination period, because an artifact that expired before fieldwork cannot be sampled.

Cluster policy reports

Kyverno writes PolicyReport and ClusterPolicyReport resources that record pass, fail, warn, skip or error results from admission events and periodic background scans. These reflect current cluster state, so they show what the cluster looks like at the time of reading. Export and retain them on a schedule if the auditor needs a record from earlier in the period.

What tools cannot replace

Tools cannot substitute for auditor judgment or for sufficient, appropriate evidence. The AICPA chair of the SOC 2 Working Group said tools help examiners pull evidence into a real-time dashboard provided quality is maintained, and the Journal of Accountancy warned that an overly automated report may lean on inquiry rather than thorough procedures. Plan for the auditor to inspect the source records directly.

How to set up evidence collection before fieldwork starts

This sequence turns the control matrix into a set of named sources, formats and locations that the team can pull on demand, so fieldwork requests are answered from tested exports rather than reconstructed screenshots. The output is an evidence plan the auditor can review before the examination period begins.

Map each control to a source system
Start from the control matrix and, for every control, record the system where the control operates and where its evidence originates, such as the identity provider, the code host, the ticketing tool, the cloud audit log or the HR system. Name one accountable owner per control and one backup. Confirm with your auditor which control descriptions they will test and whether any control depends on a subservice organization whose evidence you must request from its vendor. Output: a control-to-source map reviewed by each owner, with gaps marked where no system of record exists yet.
Decide the evidence format for each control
For each control, choose the form the evidence will take: a system-generated report, an exported log, a ticket with approvals, a pipeline artifact, or a documented review with a dated record. Rank system-generated and timestamped sources above screenshots, and use screenshots only where no export exists and say so in the plan. Ask the auditor which formats they accept for each control and whether they want the population listing used for sampling. Output: an evidence register listing the format and the sample population for each control.
Configure exports with timestamps and identifiers
Set up each recurring export so it carries the system name, the date range, the generation time, the user or service account that produced it, and a stable identifier for each record. Test that a filtered report still shows the full population, since an auditor may question an export that omits records. Where a tool writes results continuously, such as a policy engine recording pass or fail results from admission events and background scans, confirm the retention setting covers the full examination period. Output: a documented export configuration per control and a sample file for each.
Define retention location and auditor access
Decide where evidence is stored, who can read it and who can change it, and how the auditor will receive it. Use a repository with write-once or change-logged behavior where possible, and separate the folder the auditor reads from the working area where owners prepare files. Confirm with the auditor how they will access evidence and whether any tool they propose to use needs a contract or access arrangement with the organization. Output: a written evidence storage standard with access roles and a named custodian.
Run a dry-run sample pull
Pick a few controls from different criteria areas and pull evidence for a sample period as if the auditor had asked for it. Check that each file shows what the control says it shows, that the population is complete, and that a sample can be traced from the population listing to the underlying record. Note any control whose evidence is only a person's recollection, since that is inquiry and will need a stronger source. Output: a dry-run log recording each pull, its result and the fix it needed.
Review gaps with control owners
Walk through the dry-run log with each control owner and agree on what changes before fieldwork: new exports, corrected formats, missing approvals or controls that did not operate. Record each gap, its owner and the date it was closed, and check that a fix does not rewrite history for a period that has already passed. Confirm with the auditor any control whose evidence has changed since the plan was drafted. Output: a signed-off gap register and an updated evidence plan that the control owners have accepted.

Pipeline artifacts, system reports and tickets in practice

Pipeline artifacts are the outputs a CI/CD job saves when it runs. GitLab SAST, which runs open-source analyzers in the pipeline, saves the vulnerabilities it detects as a downloadable JSON report job artifact on each commit, in every tier. That file shows what the scanner found at the time it ran, which is useful evidence for the vulnerability management and secure development criteria. It does not show what the team did with the findings. The artifact is a starting point, and the auditor will expect the surrounding workflow to be visible.

Retention of the artifact: Confirm how long the job artifacts are kept and whether older reports are deleted before the observation period ends. Export or archive the reports that fall inside the period.
Triage record: Show how each finding was assessed, whether it was fixed, accepted with a documented reason, or marked as a false positive, and who made that decision.
Review before merge: Show that a person reviewed high-severity findings before a change was merged, for example through merge request approvals linked to the pipeline run.
Commit linkage: Tie each report to the commit, branch and pipeline ID so a sampled change can be traced from code to scan to approval.
Pipeline configuration history: Keep the pipeline definition under version control so the auditor can see when scanning was added or changed.

Before relying on this source, confirm with the auditor which export formats they accept and whether a JSON file alone satisfies the sample.

Contract terms that can limit the auditor's access to evidence

A platform contract can decide whether the service auditor can test a control at all. If a tool provider sits between the auditor and the evidence, the terms governing that access matter as much as the control itself. AICPA ethics staff have said that contract terms requiring the service auditor to pay a tool provider to reach evidence needed for the examination may raise questions about whether the auditor obtains sufficient, appropriate evidence. Your organization is not a party to the auditor's fee arrangements, but it is the party that signs the platform contract, so the check belongs on your side of the table before you sign.

Review the terms that govern the people and systems that will pull evidence. Confirm whether the auditor can receive a read-only account on the identity provider, the ticketing system, the cloud control plane and the CI/CD platform without a separate license or fee, and who grants and revokes that access. For self-hosted tools such as GitLab or Kyverno, check that the export path works without a vendor-hosted dashboard: the GitLab job artifact and the Kyverno PolicyReport resources should be retrievable from your own environment. Ask about export rights, including whether raw data can be downloaded in a usable format, how long evidence stays in the platform, and whether historical snapshots survive a subscription change.

Put your questions to the auditor in writing before fieldwork begins. Ask whether any term in the platform or tool contract, including fees for auditor access, data retention limits, restrictions on exporting raw records, or a requirement to route requests through the vendor, affects the procedures they plan to perform. Keep the answer in the engagement file. Journal of Accountancy reporting from 2026 also warned that heavy reliance on third-party SOC platforms can crowd out professional judgment, so a written answer from the auditor is the record that the evidence route was agreed. The AICPA's Ethics Staff Insights on SOC tool providers is the natural next read on how these arrangements are viewed.

Evidence mistakes that delay the audit or weaken the report

Most evidence problems in a SOC 2 examination are not missing controls but records the auditor cannot date, trace or rely on. The cards below cover the mistakes that slow fieldwork most often, and each one comes with a check you can run before the auditor asks.

Evidence that cannot be dated or traced

An auditor needs to see when a record was produced and which system, user or ticket it belongs to. A PDF with no timestamp, a spreadsheet with no source query, or a log excerpt with no host name forces the auditor to ask follow-up questions or reject the item. Before sending anything, confirm each artifact carries a generation date, the system it came from, and a stable identifier such as a ticket number or pipeline run ID.

Screenshots taken after the fact

A screenshot captured the week before fieldwork shows the current state, not the state during the examination period. Auditors test operating effectiveness across the whole period, so a single image taken on demand rarely proves a control operated on the sampled dates. Prefer system-generated exports or logs that the system produced at the time of each event, and keep screenshots only as supporting context.

Exports that omit the period under test

A user list pulled on the first day of fieldwork does not show who had access in month three. Reports that default to the last 30 days, or that cover only the current quarter, leave gaps the auditor must fill with inquiry. Check the date range, time zone and filter settings on every export, and label the file with the exact start and end dates it covers.

Gaps in ticket approvals

Access grants, production changes and exceptions often rely on approvals that happen in chat or in a meeting. When the ticket shows the request but not the approver, or the approval comes after the work was done, the auditor cannot test the control as designed. Require approval inside the ticketing system before the change or grant is executed, and review a sample of closed tickets for missing or late approvals each month.

Controls with no named owner

When a control such as quarterly access review or vulnerability triage has no accountable person, evidence tends to be produced by whoever remembers, and gaps appear between cycles. Auditors ask who performs the control, who reviews the output and who follows up on exceptions. Record each owner and reviewer in the control matrix, and confirm that the evidence shows the named person acting, not just a shared mailbox.

Dashboards accepted without checking their source

A compliance platform showing a green status does not prove the control works unless you know which system feeds it, what rule it tests, and how often it refreshes. The AICPA has cautioned that firms leaning too heavily on third-party SOC platforms without applying professional judgment create weak reports. Ask the vendor or your team to explain how each dashboard result is produced, and sample the underlying records yourself.

Why interviews and explanations cannot replace records

Inquiry, meaning questions put to staff, is one procedure among several, and it is the weakest one when used alone. An auditor will ask an engineer how production access is granted, how a failed backup is handled or who reviews firewall rule changes. Those answers help the auditor understand the control, but they do not show that the control operated. In February 2026, the Journal of Accountancy warned that a rushed or overly automated SOC 2 may lean too heavily on inquiry rather than thorough procedures. For the organization, the practical risk is an examination that stalls or ends with exceptions because the team could describe a control but could not produce the record behind it.

A Type 2 report makes this more demanding. Its opinion covers operating effectiveness over an observation period, and the service auditor's report includes the tests performed and their results. That means a quarterly access review in month two, a change approval for a release in month seven and a leaver ticket from month eleven must all exist and be retrievable at fieldwork. Records created in the final weeks before the audit cannot stand in for the months before it. Ask your system owners which evidence is generated automatically (for example, git merge approvals, identity provider audit logs or ticket histories) and which depends on someone remembering to save a file, because the second category is where gaps appear.

Prepare records so the auditor can test without relying on what staff say. Name a source system for each control, confirm the report or export includes the date range, user and outcome, and keep a dated copy in a location the audit team can reach. Then confirm the details with your CPA firm before fieldwork: the sample sizes it will select, the population it will draw from, the period it expects to cover and whether it will accept system-generated exports directly. These parameters differ between firms and engagements, so the answers belong in writing, not in assumptions made during the examination.

Questions buyers ask about SOC 2 evidence

Are screenshots acceptable evidence for a SOC 2 audit?

Screenshots can be accepted in some cases, but the auditor decides what is sufficient, and a screenshot is rarely the best record. An auditor usually needs to see that a control operated during the period, and a screenshot taken on the day of testing shows only one moment. System-generated reports, exported tickets and pipeline artifacts carry timestamps and show the full population, which makes sampling possible. The Journal of Accountancy has warned that a rushed report may lean too heavily on inquiry rather than thorough procedures, so a folder of screenshots can weaken the examination. Ask your auditor which artifacts they will accept for each control before you build the process.

Can a compliance platform produce all of our SOC 2 evidence on its own?

No. A compliance platform can connect to cloud accounts, identity providers and code repositories, then gather configuration snapshots and track tasks. It cannot decide whether a control is designed well, approve a change, perform a joiner review or prove that a person followed a procedure. Those records come from your tickets, your people and your systems. The AICPA vice president who spoke in May 2026 warned that some firms lean too heavily on third-party SOC platforms without applying the professional judgment the standards require. Confirm with the vendor exactly which evidence its connectors collect, how it is retained, and what your team must still produce by hand.

How much effort does SOC 2 evidence collection take, and what drives it?

Effort depends on how many controls you run, how many systems they touch, and how much of the evidence is produced automatically. Expect the largest load in the first observation period, when every control needs a documented owner, a repeatable source and a sample trail. The main drivers are the number of in-scope systems, whether ticketing and change approval happen in one tool, how often access reviews run, and whether the team has a single identity provider. Each of these can be reduced by automation, but automation also needs maintenance. Ask any partner or consultant for a written breakdown of the effort by control area before you agree on scope.

Can our team collect SOC 2 evidence without outside help?

Many teams can, provided someone owns the evidence process and has time to run it every week rather than only before the audit. The work is mostly organized record keeping: naming sources, setting retention, exporting reports on a schedule and checking that tickets contain approvals. What is harder is knowing which artifact satisfies which criterion and recognizing when a gap will become an exception. An implementation partner can prepare the systems, scripts and evidence folders, but the organization still owns its controls and the independent auditor issues the report. Decide early which parts of the work you will keep in house, and write down who is accountable for each.

What do we need from engineering and HR to gather evidence?

Engineering usually supplies the largest share. It needs to keep change records linked to pull requests, approvals recorded in the ticketing system, pipeline logs that show tests and scans, and access configuration that can be exported. HR supplies joiner and leaver records, training completion data and background check status, with dates that show when each step happened. Both teams should agree on system owners, export frequency and where files are stored. If your code platform is self-hosted, GitLab Community Edition runs SAST in the pipeline and saves results as a JSON job artifact, which is the sort of record auditors can sample. Confirm the artifact retention settings in your own environment.

What should we ask an auditor or partner before starting evidence work?

Ask the auditor which artifact types they accept for each control, how they sample populations, how long they expect evidence to be retained, and whether they will accept evidence from a tool that pulls data through a connector. Ask the partner what it will prepare, what it will not prepare, who owns the final control descriptions, and how it will hand over scripts and documentation. Under the AICPA's ethics guidance, contract terms that require the auditor to pay a tool provider for access to evidence may raise questions about sufficient, appropriate evidence, so review any such clause before signing. Request a written scope that lists each deliverable, and confirm that the auditor, not the partner, decides what evidence is sufficient.

How DeployOpen prepares evidence before the audit

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the system reports, tickets and pipeline artifacts an auditor samples are produced by the systems themselves. We prepare systems and evidence for the assessment; your organization owns its controls and the independent auditor issues the report.

How we scope

We agree in writing which systems, criteria and evidence sources the engagement covers before work starts.
We map each evidence source to the control it supports, and confirm with you which records your auditor expects.
We confirm who owns each evidence step, including which tasks stay with your staff and which go to us.
Engagements are fixed-scope, so deliverables and timelines are set out in the written scope and quote.

How we build

We configure platforms to write exportable reports, ticket histories and pipeline artifacts with timestamps and identifiers.
We set up scanning and policy engines so pass and fail results are recorded automatically for each resource.
We test that each evidence source returns the records a sample would need, including records from earlier periods.
We document how each report is generated, stored and protected from edits, so the auditor can repeat the pull.

How we hand over

We deliver an evidence index that links each control to its source system, query, owner and retention location.
We provide runbooks describing how staff generate recurring reports and where tickets and artifacts are kept.
We document any manual evidence, such as a signed access review, with the reviewer, date and approval record.
We walk your team through the handover so they can answer the auditor's requests without relying on us.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
We can keep evidence sources working through platform upgrades so the reporting period is not broken.
Before fieldwork, we can review the auditor's requests against the evidence index and fill any gaps you confirm.
Ask any preparation partner, including us, to confirm in writing which tasks it performs and which the auditor performs.

SOC 2 evidence collection: system reports, tickets and screenshots