SOC 2 evidence request list: what auditors ask for

What goes on a SOC 2 evidence request list and who answers it

A SOC 2 evidence request list asks for populations, samples and system-generated evidence for each control in scope. The organization owns its controls and answers every request, while the independent CPA firm chooses the samples it wants to test and issues the report. The list is only as useful as the system description and control matrix behind it, so a request that does not map to a named control, system and owner usually comes back with questions. A Type 1 list is mostly about design: policies, architecture diagrams, configuration baselines and proof that each control existed on the as-of date. A Type 2 list is heavier because the auditor needs complete populations for the whole observation period, such as every joiner, leaver and access grant, every production change and every security alert, then samples drawn from them. Each in-scope category adds its own requests. Availability brings backup and recovery test records, confidentiality brings disposal records, and processing integrity brings input, processing and output checks. Privacy adds notice and retention evidence. Confirm the scope with your CPA firm before building the list, because the requests follow from it.

Ask the firm for the request list in writing before fieldwork, and assign an owner to every line. Identity and access owners usually provide directory exports and access review sign-offs. Engineering owners provide change tickets, pull request approvals and deployment logs. Operations owners provide monitoring configurations, alert records and incident tickets. Leadership owns the risk assessment and board or management review minutes. The key test for each request is whether the evidence came from a system rather than a person describing it. A system-generated report with a timestamp and a query that the auditor can rerun is far stronger than a screenshot, and inquiry on its own is not sufficient. Confirm with the firm which report formats and export methods it accepts, and whether any tool it uses needs to be engaged by you rather than by the firm.

Populations and samples for access, change and monitoring controls

For CC6.2, the auditor needs to see how access credentials are created, reviewed and removed. Because the test depends on the period, the auditor usually asks for a complete population first, such as every account created, every access review completed and every account disabled during the observation window. The auditor then draws items from that population and traces each one back to its authorization and to the system record that shows the change. Inquiry alone will not satisfy the test, so the owner should prepare a system-generated export for each population instead of a summary.

New account population: A complete export from the identity provider or directory that lists every account created in the period, with creation date and creator.
Authorization for each sampled account: The approved access request or ticket showing who approved the role and when.
Removal population: Every termination, role change and disablement in the period, cross-checked against HR leaver records so the auditor can confirm timeliness.
Periodic access review evidence: Dated reviews with reviewer identity, the user list reviewed and the decisions recorded, including any removals that followed.
Invalid credential checks: Output showing dormant accounts, expired credentials and service accounts, with the action taken on each.

Before the request arrives, confirm with the system owner that the exports can be re-run with the same filters and that the auditor can see the underlying records, not only a dashboard summary.

System-generated reports versus screenshots

Auditors do not only ask whether a control exists. They ask whether the evidence can be trusted, and that depends on where it came from, how it was pulled and whether it covers the full period. The cards below set out the evidence types a SOC 2 team usually relies on and the checks that make each one hold up in fieldwork.

System-generated exports with parameters

A system-generated export is a report the platform produces directly, such as a user access list from the identity provider. Auditors look for the date the report was run, the filters applied and the person who ran it. Ask whether the export can be regenerated with the same parameters so the auditor can confirm the population is complete and accurate. Without that, the report is only a snapshot the auditor cannot test.

Completeness of the population

Before an auditor samples from a list, they usually need to know the list is complete. A user access report missing terminated accounts or a change log that omits emergency deployments undermines every sample drawn from it. Check the query or filter logic against the source system, and document how the population was reconciled, for example against headcount from HR records or deployment counts from the pipeline.

Ticket system records

Tickets show approval, assignment and closure for access requests, change requests and incidents. Their value lies in the timestamps and approver fields, which show who authorized an action and when it happened relative to the change. Confirm that approvals were recorded before the change was deployed, not added after the fact. Tickets that contain only a closing comment rarely satisfy a reviewer testing authorization.

Logs with defined retention

Audit logs from cloud accounts, identity providers and build systems show activity over the period, which is what a Type 2 test needs. Auditors check that logs are enabled, protected from alteration and retained long enough to cover the observation window. Confirm the retention setting in the log platform and whether it covers the full review period, because a log that expired in month three cannot prove month three.

Configuration baselines in version control

Infrastructure as code and configuration files stored in version control show the approved state of systems and when it changed. Commit history, pull request approvals and tagged releases give an auditor a reviewable trail for change management and hardening. Ask whether the repository branch protection rules were enforced during the period, since a direct push to the main branch would bypass the approval evidence the commit history seems to show.

Screenshots taken for the audit

A screenshot captured for the audit shows one configuration at one moment. It does not show that the setting stayed in place across the period or that no one changed it in between. Auditors may accept screenshots as supporting material, but they seldom accept them as the primary evidence for operating effectiveness. Prefer a system-generated export or log entry, and use a screenshot only to show how a setting appears in the console, labeled with its date and the person who captured it.

Why inquiry alone does not satisfy the auditor

Asking a control owner how a control works is one procedure among several, and it is the weakest of them on its own. A SOC 2 examination relies on inquiry alongside observation, inspection and reperformance, and the auditor uses those procedures together to test whether a control exists and operated. When a control owner says "we do access reviews quarterly," the auditor treats that sentence as the start of the test, not the evidence. The signed review records are what the auditor needs: the population of in-scope accounts, the reviewer's name and date, the decision made on each account, and the follow-up on any removal. Before fieldwork, have each control owner confirm that every answer they will give can be matched to a dated record the auditor can inspect.

The Journal of Accountancy warned in February 2026 that a rushed or overly automated SOC 2 report may lean too heavily on inquiry rather than thorough procedures. That warning matters most for organizations that adopt a compliance platform or evidence tool late in the period and assume the dashboard closes the gap. A dashboard shows that a test was configured, not that a reviewer performed it or that the population was complete. Test the tooling yourself before the auditor does: pull a sample of items from the platform, trace each one back to the source system, and confirm that the platform's population matches the system of record. Ask the auditor early which evidence they will take directly from your systems and which they will accept as management-prepared.

Evidence access is also a sufficiency question. AICPA ethics staff said in April 2026 that contract terms requiring the service auditor to pay a tool provider to access evidence needed for the examination may raise questions about obtaining sufficient, appropriate evidence. Confirm with your audit firm whether any tool or platform it uses will be paid for by the auditor, and whether that arrangement affects what the auditor can see. Keep your own arrangements transparent: the organization should own its evidence exports, and the auditor should be able to request the same reports directly from the source system without a paywall or license step in between.

Who should own each request

Who answers access requests on a SOC 2 evidence list?

The IT or security lead owns access requests, including user listings, privileged account reviews, MFA settings and access review sign-offs. A named backup, usually a senior engineer with administrative rights in the same systems, should be able to pull the same reports when the owner is away. Turnaround should be agreed internally as a type, such as same-day for system-generated exports and scheduled for periodic access reviews, rather than as a fixed promise. Ask the auditor which populations they will draw from so the owner exports complete lists with timestamps, not partial screenshots.

Who owns change management evidence requests?

The engineering lead owns change requests, because the population sits in the ticketing system, source control and the deployment pipeline. The request usually asks for a complete list of changes in the period, then samples of individual changes showing the request, review, testing, approval and deployment. A backup should be a second engineering manager who can export the same pipeline and ticket data. Confirm with the auditor whether emergency changes are tested as a separate population, since those records often sit outside the normal workflow.

Who provides HR joiner and leaver records?

HR owns joiner and leaver records, such as signed policy acknowledgements, background check status, onboarding and offboarding tickets, and termination dates. The security or IT lead should confirm that account deprovisioning matches each leaver's date, because the auditor will compare the two. The backup is usually an HR operations colleague with access to the HRIS. Ask HR to export records with dates intact rather than summarizing them, and agree a turnaround type with the auditor before fieldwork so the population is frozen at a known point.

Who owns risk assessment and vendor requests?

The compliance lead owns risk and vendor requests, including the risk register, risk assessment minutes, vendor inventory, and the review of third-party SOC reports or security questionnaires. The compliance lead should keep the vendor list current because it feeds CC9.2 testing. A backup from the security team can supply technical context for vendors that hold production data. Ask the auditor how often they expect risk reviews and vendor reviews to occur, and make sure the dates in the evidence match the period under examination.

Who signs off policy and board items?

Management owns policy and board items, meaning the approvals, signatures and minutes that show leadership reviewed the information security policy, risk decisions and control oversight. The compliance lead usually coordinates these records, but the approver must be a named member of management or the board. The backup should be an executive assistant or company secretary who can locate minutes and signed versions. Ask the auditor which policies must show approval dates within the period, since a policy approved after the period may create an exception.

Can one person own the whole evidence list?

One person can coordinate the whole list, but should not own every item. A single coordinator, often the compliance lead, can track requests, due dates, status and questions from the auditor. Technical and business records still need the functional owners listed above, because only those people can export the source data and explain it. Name a backup coordinator as well. For a small team, one person may hold several roles, but the auditor will still expect each evidence item to trace to a named individual who can answer follow-up questions.

Should DeployOpen own evidence requests for us?

DeployOpen can prepare systems, controls and evidence for the examination, and can document how each request is produced, but the organization owns its controls and the evidence it gives the auditor. Where an engagement covers evidence preparation, the written scope should name which requests DeployOpen prepares, which your staff confirm, and who holds each backup role. An independent CPA firm issues the report. Ask any implementation partner to show the export steps and to hand over the procedures so that your team can answer auditor follow-ups after the engagement ends.

How to prepare the list before fieldwork starts

This sequence turns a generic evidence request list into one the team can answer on time, with each request tied to a criterion, a named source, an owner and a population the auditor can sample from. The output is a set of working artifacts that the team can hand to the CPA firm before fieldwork begins.

Confirm the in-scope criteria and system description
Start by fixing which Trust Services Categories are in scope and which common criteria apply, then confirm the system description that describes the boundary, components and services. Compliance lead and the system owner do this together, because every evidence request has to point back to a criterion and to a component inside that boundary. Close the step when the scope statement, the criteria list and the draft system description agree with each other and the CPA firm has confirmed the scope in writing.
Map each control to its evidence source and owner
For every control in the control matrix, record the system or record that proves it operated, such as an identity provider export, a ticketing system, a deployment pipeline log or an HR system entry. Assign one named owner per source, who can produce it and explain it during fieldwork. The output is an owner matrix that lists control, criterion, evidence source, owner and backup owner, so no request lands with someone who cannot answer it.
Build a populations register for each control
For controls that are tested on samples, the auditor needs a complete population to draw from, not a list the team chose. For each control, document the population definition, the system that generates it, the date range and the expected count, such as all user accounts, all production changes or all terminated employees in the period. The output is a populations register that a reviewer can check against the source system, and any gaps are logged before the auditor finds them.
Test that each system report is complete and repeatable
Any report pulled from a system must be shown to be complete and accurate before it is given to an auditor. Run each report with the parameters the auditor will expect, compare its totals against an independent count from the source, and confirm the same parameters return the same results when run again. Record the query, filters, run date and the person who ran it. The output is a tested report log that shows the team knows what each system-generated report includes and excludes.
Archive evidence with dates and provenance
Store each piece of evidence in a repository with a consistent naming convention, the control ID, the period covered, the date it was generated and the name of the person who produced it. Keep screenshots only where no system report exists, and note why. Access to the repository should be restricted so that the record cannot be edited after collection. The check is that anyone on the team can find the evidence for a given control and date without asking the owner, and that nothing in the archive was altered after it was taken.
Run a mock request against a sample
Before the auditor arrives, pick a sample from a population in the register, ask the owner to produce the evidence as if the auditor had asked for it, and time how long it takes to answer. Check whether the evidence proves the control operated, not just that the control exists, and whether the owner can explain the exception handling if an item is missing. The output is a mock request log with the outcome for each sample, and each gap is assigned to an owner for correction before fieldwork.

Readiness checks before the first request arrives

Most evidence delays come from gaps the organization could have closed before fieldwork began. The six checks below test whether each request can be answered quickly, completely and in a form the auditor can trust. Together they show whether evidence is owned, exportable, retained, protected and traceable.

Every control has a named owner

Each control in the matrix needs one accountable person who can answer for it, not a team mailbox. The owner decides which system produces the evidence, who pulls it, and who answers the auditor's follow-up questions. Ask whether each owner can explain the control without consulting a vendor or a consultant. A control with no owner usually produces inquiry-only answers, which auditors treat as weak support.

Populations export from source

A population is the full set of items a control applies to, such as every account provisioned in the period or every production change. Auditors draw samples from populations, so the organization must be able to export the complete list directly from the identity provider, ticketing system or deployment pipeline. Test the export once before fieldwork and confirm that its count matches the source system. A sample drawn from a partial list cannot support a conclusion about the whole period.

Retention covers the Type 2 period

A Type 2 report tests controls over an observation period, so evidence from the start of that period must still exist when the auditor samples it. Check retention settings on logs, tickets, chat approvals and access review records before the period opens. Logs that roll off after a short default window will create gaps the auditor cannot fill. Confirm the retention periods with your own policy and the auditor's engagement terms.

Access to evidence is controlled

The evidence store is itself a security-sensitive system. Restrict who can edit or delete audit logs, approval records and exported reports, and record who accessed them. Auditors will ask whether the population could have been altered after export, so keep system-generated reports in a read-only location with an audit trail. Access to the evidence folder should follow the same least-privilege rules as production.

Sampled items trace end to end

When an auditor selects one change or one access grant, the organization should be able to follow that single item through every step of the control. For a change, that means the request, the approval, the test result, the deployment record and the post-deployment check. Walk through two or three items yourself before fieldwork to find broken links, such as an approval given in chat with no ticket reference. Missing links are the most common reason a sample becomes an exception.

Exceptions are logged and explained

Exceptions happen in every real control environment, such as a late access review or a change deployed before approval. The risk is not the exception itself but an exception the team hides or explains only after the auditor finds it. Keep an exception log with the date, the affected item, the root cause, the corrective action and the owner. Auditors and peer reviewers look for this record as evidence that monitoring works.

What do SOC 2 evidence requests cost in effort and who does the work

How much effort do SOC 2 evidence requests take?

The effort depends on how many controls are in scope, how many systems hold the evidence, and whether the evidence already exists in a retrievable form. No researched figure for hours or weeks is available for this page, so ask for it in writing. A useful quote breaks effort down by criterion area (access, change, monitoring, vendor management) and by population, and states how many samples the team should expect the auditor to draw. The biggest variable is the Type 2 observation period, because evidence must be produced for every sampled event across that period, not for a single date.

Can our own team handle SOC 2 evidence requests alone?

Often yes, if the team has someone who understands the systems and can keep records current. The work is continuous rather than a one-off, so the question is whether engineers, IT and HR have time to pull populations, export system reports and answer follow-up requests within the auditor's timelines. Organizations usually keep ownership of their controls and decide who answers each request. An outside partner can help set up the collection process, but the organization still owns the controls and the auditor still decides what it tests.

What does an implementation partner prepare and what does the auditor test?

An implementation partner prepares systems and evidence: it configures logging, access records and change workflows, sets up repeatable exports and organizes the evidence folders so that each request can be answered from a known source. The auditor does something different. It selects samples, performs inquiry, observation, inspection and reperformance, and forms its own opinion. DeployOpen prepares systems, controls and evidence for assessments but does not issue reports or attestations. Scope and deliverables for any preparation work are agreed in writing before work starts.

Do automated evidence tools remove the work of SOC 2 requests?

No. Automated tools reduce the manual collection of some evidence, such as pulling user lists or configuration state, but they do not decide whether a control operated. The AICPA's SOC 2 Working Group chair has said such tools can help examiners connect to client systems and pull evidence into a dashboard, provided quality is maintained. The Journal of Accountancy has also warned that a rushed or overly automated report may lean too heavily on inquiry. Ask the auditor which evidence it will accept from a tool, and confirm that the tool's outputs are complete and can be traced to the source system.

Should we pay an evidence tool provider that the auditor needs?

Check this before signing. AICPA ethics staff have said that contract terms requiring the service auditor to pay a tool provider to access evidence needed for the examination may raise questions about whether the auditor obtained sufficient, appropriate evidence. The organization should expect the auditor to explain how it will access evidence, and should avoid arrangements where the auditor's access depends on a fee the organization is asked to route through the tool. Put the evidence access arrangement in writing before fieldwork begins.

How does the evidence request list change between Type 1 and Type 2?

A Type 1 report covers the design of controls as of a single date, so requests focus on the documented system and evidence that each control exists at that point. A Type 2 report adds an opinion on operating effectiveness over a period, so the auditor selects samples across that period and asks for evidence of each sampled event, such as access approvals, change tickets and review records. The Type 2 request list is longer, recurs over the observation window, and needs evidence to be collected as the period runs, because controls that did not operate cannot be shown retrospectively.

What should we ask a consultant or partner to quote for evidence work?

Ask for a written scope that lists the criteria and controls covered, the systems and populations involved, the evidence sources and owners, and the deliverables. Ask whether the work is one-time setup, recurring support, or both, and what each covers. Confirm who answers auditor follow-up requests and how quickly. Ask how the partner will avoid overlap with the auditor's role, and whether any tool licenses are included or billed separately. DeployOpen does not publish a price list; a quote follows from the written scope.

Who should own each evidence request inside our company?

Assign each request to the person who operates the control, with a second person who can confirm the evidence is complete. Access reviews usually sit with IT or the system owner, change evidence with engineering, and joiner and leaver records with HR. Security or compliance leads should keep the master list, track due dates and check that each answer is traceable. Management remains responsible for the controls and for the representations it gives the auditor, so an owner should be named for every request before the examination starts.

Where to read the criteria behind the requests

The auditor's request list is not arbitrary. Each request traces back to a criterion in the AICPA's 2017 Trust Services Criteria, which define what your controls must address, and to the AICPA's 2018 description criteria (DC 200), which define what your system description must disclose. Before you read the request list, read the criteria it points to. Start with the common criteria CC6 (logical and physical access), CC7 (system operations) and CC8 (change management), since these generate most of the populations an auditor will ask you to pull. Then read the points of focus under each criterion. Points of focus are characteristics that can help you design and evaluate controls, not separate requirements, so you decide which ones your environment needs and document that choice.

Use the AICPA's 2017 Trust Services Criteria with revised points of focus (2022) as the working reference. For each criterion your control matrix claims to cover, note the points of focus you addressed and the ones you judged not relevant, with a reason. An auditor who asks for evidence of a credential review will look for that match. Pair the criteria with DC 200 so that the system description states the components and changes the requests will test. Confirm with your CPA firm which edition of each document it will use for your engagement, since the criteria and description guidance are the auditor's baseline.

Assign an owner to each criterion family before the first request arrives. For example, the identity lead can own CC6.2 requests covering credential creation, review and removal, and the engineering manager can own CC8.1 requests covering change tracking and emergency changes. Ask the auditor which population each request covers (for example, all accounts provisioned in the period, or all production changes) and confirm the time window in writing. Mismatched windows are one of the most common reasons evidence has to be pulled twice.

How DeployOpen prepares systems and evidence for your SOC 2

DeployOpen helps organizations prepare the systems and records that answer an auditor's evidence request list, including populations, system-generated reports and named owners for each request. The organization owns its controls and its report, and an independent CPA firm performs the examination and issues the opinion.

How we scope

Engagements are fixed-scope, with the evidence populations, systems and criteria agreed in writing before work starts.
We confirm which in-scope systems can produce access, change and monitoring populations from the start of the Type 2 period.
The written scope names the owner for each request so inquiry is backed by records the organization can produce.

How we build

We configure self-hosted open-source platforms in your own infrastructure to generate system-reported access, change and log records.
We set up recurring exports so populations and samples can be drawn from complete, dated records rather than screenshots.
We document how each evidence source is generated, stored and kept unaltered so the auditor can test its completeness.

How we hand over

You receive an evidence index mapping each request to its source system, owner, time period and retention location.
Documentation covers how each report is run, who reviews it and how exceptions are recorded and followed up.
We walk your team through the handover so the organization can answer auditor requests without relying on the implementation partner.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement.
A retainer can keep evidence collection running through the observation period and between annual examinations.
Support decisions remain with your management, and the CPA firm alone issues the report and any opinion on it.