SOC 2 Evidence Request List: What to Pull by Source (2026)

A SOC 2 evidence request list is easiest to work through source by source, not control by control. Nine systems typically hold most of the evidence: the identity provider (provisioning, MFA, access reviews), the cloud console (encryption, logging, IAM), Git and CI/CD (change management), the HR system (training, onboarding and offboarding), endpoint management (device encryption, patch status), ticketing (incidents, changes, vulnerability remediation), the SIEM (monitoring and alerting), a vulnerability scanner (scan and remediation history), and a vendor or GRC inventory (subservice organizations, vendor SOC 2 reports on file). One clean pull from any of these typically answers several separate requests at once. Each section below lists, for that system, the evidence to pull and the SOC 2 criteria each item answers, with links to the controls library. A final section covers the documents and records that live outside the nine systems.

An auditor’s SOC 2 request list is usually written control by control: one block of requests for access provisioning, another for change management, another for incident response. That is the right lens for understanding what the Trust Services Criteria require, and our SOC 2 audit checklist covers that ground control by control.

The systems that answer those requests are not organized that way. Each one holds evidence for many controls at once, and a team rarely works from a spreadsheet sorted by criterion number. They log into Okta, then AWS, then GitHub, then whatever the HR platform is called this year, and pull what each system will give them.

This guide follows the systems: nine that commonly hold SOC 2 evidence, plus a final section for the documents and records that live outside them. A clean, complete pull from the right system can clear several line items on the request list at once, because that system is the record of more than one control.

To work from the controls side instead, filter the same controls to your stack and download them as Excel, PDF or CSV.

Why Organize Evidence by Source Instead of by Control?

The map below shows where that overlap falls.

The Coverage Map: One Pull, Several Answers

Read it by row. Each row is one system: “Primary evidence for” lists the control areas it is typically the main evidence source for, and “Supporting evidence for” lists areas where it contributes supporting or cross-referenced evidence. A control area missing from a row just means that system usually isn’t where an auditor would look for that particular control.

Evidence source	Primary evidence for	Supporting evidence for
Identity provider	Access control	Monitoring
Cloud console	Monitoring, Data protection	Access control, Vulnerability management, Vendor risk
Git and CI/CD	Change management	Access control, Vulnerability management
HR system (HRIS)	Training	Access control
Endpoint management (MDM)	Data protection	Vulnerability management
Ticketing / ITSM	Change management, Monitoring, Vulnerability management	None
SIEM / monitoring	Monitoring	Access control, Vulnerability management
Vulnerability scanner	Vulnerability management	Monitoring
Vendor / GRC inventory	Vendor risk	None

1. Identity Provider (Okta, Azure AD/Entra ID, Google Workspace)

Your identity provider is the backbone of access control evidence. Pull the full population of provisioning, role change, and termination events for the observation period, not just a handful of examples. From that population the auditor selects a sample (our guide to SOC 2 sample size covers how that number gets set) and traces each one back to an approval.

The same export usually carries the termination test too: the timestamp an account was disabled, compared against the timestamp HR recorded as the employee’s last day. A long gap between the two is a common finding, worth checking before the auditor does.

MFA enforcement is a separate, smaller pull: a screenshot or configuration export showing MFA is required, not just available, for every user. Advisory-mode MFA, where a user can decline the prompt, usually won’t satisfy the control, even when adoption looks high.

If access reviews run through the identity provider, or a platform synced to it, the review records (reviewer, date, systems covered, sign-off) usually live here too. One clean export from this system usually answers provisioning, termination, MFA, and most of the access review requirement.

Beyond the provisioning and termination populations, the rows below cover MFA enforcement, SSO coverage, and checks that every account belongs to one named person.

2. Cloud Console (AWS, GCP, Azure)

The cloud console is the second major evidence hub, because a cloud account is simultaneously your infrastructure inventory, your encryption configuration, and one of your primary log sources.

Pull a current resource inventory (every storage bucket, database, and compute or network resource in scope) alongside encryption-at-rest configuration for each one. Resources provisioned mid-period are worth checking separately: an unencrypted bucket or database spun up during the period is a common finding, surfaced by comparing your inventory against a live cloud export.

IAM policies and role assignments answer part of the access picture too, though they’re usually secondary to the identity provider unless cloud access is managed independently. Logging configuration (CloudTrail or the GCP/Azure equivalent), along with network and firewall rules, covers monitoring evidence directly.

One more item belongs in this pull even though it doesn’t come from your own console: the cloud provider’s own SOC 2 report, which typically satisfies physical data center access for a company running on rented infrastructure and belongs in the vendor file alongside your subservice organization disclosure. Our guide to the Google Cloud SOC 2 report shows what to check when you read one.

The rows below add backup configuration and AI model provider settings to the console items covered above.

3. Git and CI/CD (GitHub, GitLab, Jenkins, CircleCI, GitHub Actions)

Version control and the pipeline that deploys from it are the system of record for change management, and one of the cleanest evidence sources on the list, because most of what an auditor wants is already generated as a byproduct of normal engineering work.

Pull branch protection configuration showing peer review is required before a merge to production, plus a sample of pull requests from the observation period with visible approvals. Add pipeline logs showing automated tests passed before deployment, and a deployment log tying each release to a commit hash and a timestamp.

This source also carries a good share of segregation-of-duties evidence: branch protection rules that block a single developer from approving and merging their own change answer that question directly, more convincingly than a policy document alone. See our change management controls guide for the complete change trail end to end.

A common gap sits around the tool, not in it: an emergency hotfix pushed straight to production with no ticket and no retroactive review. A genuine break-glass path should be documented as its own controlled exception, not an unexplained gap in an otherwise clean population.

Beyond branch protection and pull request approvals, the rows below include secret-scanning and dependency-scanning results from the pipeline.

4. HR System / HRIS

The HR platform, whatever runs payroll, onboarding, and people records, is the primary source for personnel security and training evidence, and it’s the cross-reference partner for the identity provider’s termination test.

Pull onboarding records showing when each new hire started, alongside training completion records showing when required security training finished, typically within the window your policy sets after the start date (30 days is a common choice). Add background check completion records where policy requires them, and annual policy acknowledgment records showing every employee has signed off.

Offboarding records are the other half: the date HR recorded as an employee’s last day, lined up against the timestamp the identity provider shows access was revoked. A gap between the two is a common access control exception, even though the root cause usually sits in the handoff between HR and IT rather than either system alone.

Contractors are easy to miss. An HR platform tracks employees by default, so part-time or project-based contractors may fall outside training and policy tracking. If a contractor can touch production or customer data, they belong in these records too.

The org chart and performance review records also come from this system and appear in the rows below.

5. Endpoint Management (MDM: Jamf, Intune)

Endpoint management tools answer a narrower but still distinct question: whether the laptops and phones your employees use are hardened the way policy says.

Pull an enrollment report showing every company-managed device is enrolled, alongside a compliance report showing disk encryption (FileVault or BitLocker), screen lock, and automatic updates are enforced, not merely recommended. Patch compliance data, showing how current each device is against your defined SLA, is the other half.

This source’s main overlap is with vulnerability management: a device out of compliance on patching is functionally the same finding whether it surfaces through the MDM compliance report or a vulnerability scan. Keeping both sources in sync avoids submitting evidence that quietly contradicts itself.

Lost or stolen device handling is a separate, small pull: a documented process for remote lock, wipe, and recovery. Have it ready, since auditors may ask for it.

The rows below include the asset inventory, since the enrollment report has to reconcile with it.

6. Ticketing / ITSM (Jira, ServiceNow, PagerDuty)

Ticketing is the clearest case for organizing by source. A well-run ticketing system is simultaneously the system of record for change management, incident response, and vulnerability remediation tracking, so one clean export can answer three sections of the request list at once.

For change management, pull the population of change tickets tied to production deployments, each linked to its pull request and deployment record (see the Git and CI/CD section for the other half). For vulnerability management, pull remediation tickets for critical and high findings, each with a creation date, an owner, and a resolution date the auditor can compare against your remediation SLA. For incident response, pull the incident log itself: every entry with a severity, detection date, response actions, and resolution date.

A common gap across all three is work that was handled but never recorded in the ticketing system. An engineer fixes a critical vulnerability the same day it’s found and never opens a ticket. An incident gets resolved in a chat thread with no follow-up record. An auditor cannot tell undocumented work from work that never happened.

Ticket exports reach beyond change and incidents: the rows below also cover access requests, risk reviews, and control deficiencies.

7. SIEM / Monitoring (Datadog, Splunk, cloud-native like GuardDuty)

The SIEM, or whatever aggregates logs and generates alerts, is the primary evidence source for monitoring. The question is whether it caught things during the observation period, not just whether it exists.

Pull the alert configuration showing rules exist for security-relevant events (failed login thresholds, privilege escalation, unusual access patterns), then a sample of alerts that actually fired during the period with evidence each was acknowledged and resolved. Add the log retention configuration, confirmed against the full observation period, since a retention window that doesn’t reach the start of the audit period is a finding regardless of how good the alerting is.

A common gap is missing coverage: a new cloud account or service that was never connected to the SIEM. It’s the monitoring equivalent of the encryption gap in the cloud console section: something new got provisioned faster than the checklist caught up.

The rows below also cover admin activity logs and malware alert logs, not only security alerts.

8. Vulnerability Scanner (Tenable, Qualys, Wiz, or equivalent)

A dedicated vulnerability scanner is the primary source for the vulnerability management requirement, and it overlaps directly with the endpoint-hardening evidence covered above.

Pull scan reports across the full observation period, not just the most recent one, showing scans ran on a consistent cadence with dated, scoped results. The trace from a specific finding to its remediation matters most: the corresponding ticket (see the ticketing section above), the date it was opened, the date the fix shipped, and a follow-up scan confirming it cleared.

A common exception is a vulnerability that shows up in three consecutive months of reports with no ticket and no documented risk acceptance. If a finding genuinely can’t be remediated on schedule, a formal, signed risk acceptance is the difference between a documented decision and a finding that looks ignored.

The rows below include penetration test reports alongside scanner output.

9. Vendor / GRC Inventory

The vendor or GRC inventory, whether it’s a dedicated register, a spreadsheet, or a module inside a compliance platform, is the primary source for third-party risk management. Unlike the other sources, it is a document that has to stay current on its own, not a system export.

Pull the vendor inventory with a risk tier assigned to each vendor, then current SOC 2 reports on file for every critical-tier vendor, meaning any vendor with direct access to production or customer data. “Current” needs care: a report covering a period that ended well over a year ago reads as a gap in assurance, even for an otherwise reputable vendor.

This is also where subservice organizations get documented: the vendors your own SOC 2 report will describe as either carved out of scope or included within it, a distinction detailed in our guide to carve-out versus inclusive reporting. The mirror image, the controls your own customers are expected to run on their end, is covered in our guide to complementary user entity controls.

A common gap in this source is a vendor onboarded mid-period without a security review, typically because a contract got signed before security was looped in. Keeping the inventory as a gate in vendor onboarding, not a document updated after the fact, is what keeps it current.

The rows below cover vendor reviews and offboarding, plus the control monitoring records a compliance platform keeps.

10. Documents, Records and the Application

Not every request comes from one of the nine systems. Policies, board and management records, the risk register, training and policy acknowledgment records, customer and vendor contracts, customer communications, privacy records, physical security records, exercise and test records, and the application’s own data stores sit in shared drives, document tools, and the product itself. Auditors ask for them because the criteria on governance, risk, privacy, and customer commitments test two things: whether a decision was made, approved, and communicated, and whether the product behaves as described. A system export cannot show either. Dates and approvals matter most here, since a policy with no approval date or a risk register with no review date tends to read as a document nobody maintained.

Policy repository

Board and management records

Exercise and test records

Risk register

Training platform

Physical security records

Application and data stores

Customer and vendor contracts

Customer communications

Privacy records

Putting It Together Before Fieldwork Starts

These nine sources overlap, and the overlaps are where cross-checks happen. A termination event only fully resolves when the HR timestamp and the identity provider’s revocation timestamp agree; a vulnerability finding only resolves when the scanner, the ticket, and the endpoint report all tell the same story. An evidence folder organized by source, with a note on which requests each export answers, tends to surface these cross-references before the auditor does. The same exports also back the answers you give in customer security questionnaires; our vendor security questionnaire guide covers that workflow. The SOC 2 compliance checklist places the evidence-repository step and the monthly evidence close during a Type 2 window in the full audit sequence, while this page lists what to pull from each system.

For the deeper, per-control version of this list, our SOC 2 compliance checklist covers the ten control areas with the evidence each one produces and the fieldwork steps, and our SOC 2 documentation guide covers the written policies and procedures that sit alongside the system exports covered here.

FAQ

A SOC 2 evidence request list is the set of specific artifacts an auditor asks a company to produce during fieldwork: population exports, configuration screenshots, tickets, and sign-off records proving a control operated as described. Auditors usually write it control by control; the same evidence can also be organized by the system it comes from.

Do we need to prepare separate evidence for every control, or can one export cover several?

One export very often covers several. A population export from an identity provider typically answers the provisioning test, the termination test, the MFA test, and most of the access review requirement at once, since all four draw on the same system of record.

Do we need all nine evidence sources if my company is small?

Usually, in some form. For a SOC 2 audit the tooling can be lightweight, such as a shared inbox standing in for a dedicated ITSM tool. Whatever tool is used needs to produce a dated, attributable record, not a chat message.

What is the fastest way to organize evidence before fieldwork starts?

Build a folder or index by source system rather than by control, pull the full population, not a handful of examples, for the observation period from each one, and note next to each export which specific requests it answers. When the request list arrives, many items map directly to an export already staged. Compliance platforms can pull several of these exports automatically; compare SOC 2 compliance software if you are choosing one.

What happens if one evidence source can’t produce clean evidence for the full observation period?

That gap typically becomes an audit exception rather than something to paper over during fieldwork. If a system was only recently connected to logging or brought under a formal review cadence, flag the gap before fieldwork starts and discuss it with the auditor directly.

How is organizing evidence by source different from a general SOC 2 evidence collection guide?

A control-by-control guide covers what each control needs to show. This guide organizes the same evidence by the system it comes from, and each item lists the SOC 2 criteria it answers.

---

Once your evidence is staged, the next decision is which firm reviews it. SOC2Auditors compares verified SOC 2 audit firms on pricing, timelines, and the frameworks they cover. Visit SOC2Auditors to compare firms and request quotes.