Most SOC 2 evidence guides are organized the way auditors write their request lists: by control area. That’s the right lens for understanding what the Trust Services Criteria actually require, and our SOC 2 audit checklist and evidence collection guide cover that ground well, control by control.

It’s not how most IT and engineering teams actually work through a request list, though. Nobody opens 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 whatever each system will give them.

This guide follows that grain instead: nine systems that show up in almost every SOC 2 environment, and for each one, what to export and which auditor requests it typically answers. A clean, complete pull from the right system routinely clears three or four line items on the request list at once, because that system is the record of more than one control.

Quick Answer: A SOC 2 evidence request list is easiest to work through source by source, not control by control. Nine systems answer most of it: 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.

Why Organize Evidence by Source Instead of by Control?

A SOC 2 evidence request list reads like it was written control by control, because it was. But almost every system in a typical stack is the system of record for more than one control, so organizing preparation by source instead means fewer separate trips into the same tool for the same evidence, and it matches how technical teams already think about their own stack.

The map below shows where that overlap actually falls.

The Coverage Map: One Pull, Several Answers

Read it by row. Each row is one system; a filled mark means that system is typically the primary evidence source for that control area, and an open mark means it contributes supporting or cross-referenced evidence. A blank cell just means that system usually isn’t where an auditor would look for that particular control.

Nine evidence sources mapped against seven SOC 2 control areas Coverage matrix showing which control areas each evidence source typically answers. Identity provider is the primary source for access control, with supporting evidence for monitoring. Cloud console is primary for monitoring and data protection, with supporting evidence for access, vulnerability management, and vendor risk. Git and CI/CD is primary for change management, with supporting evidence for access and vulnerability management. The HR system is primary for training, with supporting evidence for access. Endpoint management is primary for data protection, with supporting evidence for vulnerability management. Ticketing and ITSM is primary for change management, monitoring, and vulnerability management all at once. SIEM and monitoring tools are primary for monitoring, with supporting evidence for access and vulnerability management. A vulnerability scanner is primary for vulnerability management, with supporting evidence for monitoring. A vendor or GRC inventory is primary for vendor risk. Access Change Monitor Vuln Vendor Training Data Identity provider Cloud console Git & CI/CD HR system / HRIS Endpoint mgmt (MDM) Ticketing / ITSM SIEM / monitoring Vulnerability scanner Vendor / GRC inventory Primary evidence source Supporting evidence Blank cells are not typically the evidence source for that control area.
Pulling ticketing or the cloud console well answers three control areas at once.Coverage reflects common practice for a typical SaaS environment, not a fixed rule. Column order follows this guide's Access control, Change management, Monitoring, Vulnerability management, Vendor risk, Training, and Data protection sections.

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 actually 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 gap of more than a day or 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, doesn’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 routinely answers provisioning, termination, MFA, and most of the access review requirement.

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 one of the most common findings, 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.

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.

The most common gap here isn’t in the tool, it’s around 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.

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 expected within 30 days of the start date. 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 of the story: 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 one of the most frequently cited access control exceptions, even though the root cause usually sits in the handoff between HR and IT rather than either system alone.

Contractors are the recurring blind spot. Most HR platforms are built around employees, and part-time or project-based contractors quietly fall outside training and policy tracking. If a contractor can touch production or customer data, they belong in these records too.

5. Endpoint Management (MDM: Jamf, Intune)

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

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 worth pulling as a separate, small item: a documented process for remote lock, wipe, and recovery. It’s a small ask, but current audits ask for it specifically enough to have ready.

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

If any single source earns the reframing this guide is built around, it’s ticketing. 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.

The recurring failure mode across all three is the same: something got handled, but not 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. Undocumented work and work that never happened look identical. If it isn’t in the ticket, it isn’t evidence.

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, tested less on whether it exists than on whether it actually caught things during the observation period.

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.

The gap that shows up most often here isn’t a missing rule, it’s 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.

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. What actually decides this control is the trace from a specific finding to its remediation: 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.

The most common exception here isn’t a missed scan, it’s 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.

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’s less a system export and more a document that has to stay current on its own.

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” is the word that trips people up: 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.

The most 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.

Putting It Together Before Fieldwork Starts

None of these nine sources exist in isolation, and the overlaps are the point. 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.

For the deeper, per-control version of this list, our SOC 2 audit checklist walks all ten AICPA control domains in the order an auditor tests them, and our SOC 2 documentation guide covers the written policies and procedures that sit alongside the system exports covered here.

FAQ

What is a SOC 2 evidence request list?

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 typically organize it by control area; 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?

Most companies in scope for a SOC 2 audit run some version of all nine, even if the tooling is lightweight, a shared inbox standing in for a dedicated ITSM tool, for example. The systems matter less than the discipline: 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, most items map directly to an export already staged.

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 general evidence guide organizes by evidence type or control area. This guide organizes by the system that evidence actually comes from, closer to how most IT and engineering teams spend the days before fieldwork.

Your evidence is only as strong as the systems it comes from and the discipline of pulling a full population, not a convenient sample. Once your evidence is staged, the next decision is which firm actually reviews it. SOC2Auditors compares verified SOC 2 audit firms on pricing, timelines, and the frameworks they cover, so you can select an auditor with the same rigor you brought to organizing your evidence. Visit SOC2Auditors to compare firms and request quotes.