SOC 2 Evidence Collection: What Auditors Actually Look For

Evidence collection is where SOC 2 compliance gets real. Your policies describe what you commit to doing. Your controls are the mechanisms that enforce those commitments. Evidence is the proof that those controls actually operated — consistently, across your entire observation period.

For a SOC 2 Type I report, evidence proves that controls are properly designed at a point in time. For a Type II report, the bar is higher: evidence must demonstrate that controls operated effectively over a sustained period — typically 6 to 12 months. Every month in that window matters. A single gap in evidence can result in a qualified opinion or an exception in your report that enterprise customers will scrutinize.

SaaS companies that treat evidence collection as a last-minute scramble before audit season end up with incomplete records, panicked teams, and delayed reports. Companies that build evidence collection into their daily operations find that the audit itself becomes a straightforward exercise. This guide covers exactly what evidence auditors request, organized by control area, and how to build a collection system that makes SOC 2 sustainable.

Types of SOC 2 Evidence

Before diving into specific control areas, understand the categories of evidence that auditors work with. Different controls require different types of proof.

Screenshots. Point-in-time captures of system configurations, security settings, and dashboard views. Screenshots are useful for demonstrating that a setting is enabled (MFA enforcement, encryption configuration, firewall rules) but they only prove the state at the moment of capture. For Type II audits, you may need screenshots from multiple points during the observation period.

In practice: Always include the browser URL bar, a timestamp, and enough context to identify the system. A screenshot of an MFA configuration page is useful. A cropped screenshot of a toggle switch with no system identification is not.

Logs. System-generated records of events: access logs, change logs, audit trails, authentication logs. Logs are the strongest form of evidence because they’re generated automatically and are difficult to fabricate. Auditors prefer logs over manual records because they represent what actually happened, not what someone remembers happening.

In practice: Ensure log retention covers your full observation period plus a buffer. If your observation period is January through December and your logs rotate after 90 days, you’ll lose evidence from the first nine months.

Tickets. Issue tracking records from systems like Jira, Linear, or ServiceNow. Tickets provide evidence of change management (code changes going through approval workflows), incident handling (response timelines and resolution), and access management (provisioning and deprovisioning requests).

In practice: Tickets are only useful if they contain the right metadata: timestamps, assignees, approval records, status transitions, and linked artifacts. A ticket that says “Deploy update” with no review or approval record doesn’t demonstrate change management.

Reports. Formal outputs from security tools and processes: vulnerability scan results, penetration test reports, access review summaries, risk assessment documents. Reports typically demonstrate periodic control activities.

In practice: Reports should be dated, attributed to the person or tool that generated them, and show clear findings and remediation actions. A vulnerability scan report that lists 47 critical findings with no evidence of remediation work is worse than no report at all — it proves you identified risks and did nothing about them.

Documents. Signed policies, training records, meeting minutes, management assertions. Documents demonstrate governance activities that may not produce system-generated evidence.

In practice: Documents need dates, signatures or approvals, and version information. Meeting minutes should include attendees, topics discussed, and decisions made — not just “security review meeting” with no content.

Configurations. Infrastructure-as-Code templates, CI/CD pipeline configurations, firewall rules, network ACLs. For SaaS companies managing infrastructure through code, these configurations are powerful evidence because they’re version-controlled and auditable.

In practice: Point auditors to your IaC repository with specific commit hashes. A Terraform configuration enforcing encryption on all S3 buckets, checked into Git with review history, is cleaner evidence than a screenshot of the AWS console.

Attestations. Signed acknowledgments, management assertions, and formal declarations. These are used where automated evidence isn’t available — for example, employee policy acknowledgments or management’s assertion about the completeness of the system description.

In practice: Attestations must be signed and dated. Digital signatures (DocuSign, internal acknowledgment systems) are acceptable and preferred over physical signatures because they include tamper-evident timestamps.

Evidence by Control Area

SOC 2 auditors organize their evidence requests around the Common Criteria categories. Here’s what they expect for each major area, with specific examples relevant to SaaS companies.

Access Controls (CC6)

Access control is the most evidence-intensive area of a SOC 2 audit. Auditors test the full lifecycle of user access — provisioning, ongoing management, and deprovisioning — and they’ll sample extensively.

User access lists with roles. Provide current access lists for all in-scope systems showing each user’s role, permissions, and the date access was granted. Auditors will cross-reference these against your employee directory and HR records.

SaaS example: Export user lists from AWS IAM, Okta, GitHub, and your production database showing usernames, assigned roles, group memberships, and last login dates.

MFA enforcement evidence. Prove that multi-factor authentication is enforced — not just available — for all required systems. Configuration screenshots showing MFA is mandatory, plus authentication logs showing MFA challenges during login events.

SaaS example: Okta policy configuration showing MFA is required for all users accessing production systems, plus authentication event logs showing MFA factor verification for a sample of login events.

Quarterly access reviews with remediation. This is where many SaaS companies stumble. Auditors want to see four completed access reviews during a 12-month observation period, each showing the reviewer, systems reviewed, discrepancies found, and remediation taken. If a review found an account that should have been removed, the auditor wants to see the removal ticket and confirmation.

SaaS example: A quarterly report showing that all AWS IAM users were reviewed by the engineering lead, two accounts belonging to former contractors were identified, Jira tickets were created for removal, and the accounts were disabled within 48 hours with confirmation screenshots.

Onboarding and offboarding tickets. Provide tickets showing that access provisioning follows your documented procedure and that terminated employees are deprovisioned within the timeframe your policy specifies.

SaaS example: A Jira ticket showing a new engineer’s access request, manager approval, account creation in Okta with the specified role, and completion timestamp — all within your policy’s SLA. A corresponding offboarding ticket for a departed employee showing access revocation across all systems within 24 hours of termination.

Privileged access logs. Provide audit logs for privileged accounts — root access, database admin accounts, infrastructure admin roles. Auditors want to see who used privileged access, when, and for what purpose.

Change Management (CC8)

Change management evidence proves that your development and deployment processes follow your documented procedures. For SaaS companies shipping code frequently, this area should produce abundant automated evidence.

Pull request history with code reviews. Auditors will sample pull requests from across the observation period and verify that code reviews occurred before merge. They’ll check for reviewer approvals, review comments, and that the reviewer is someone other than the author.

SaaS example: GitHub pull request logs showing that every merged PR to the main branch had at least one approving review from a team member who is not the author, with review comments and a timestamp of approval before merge.

Deployment logs. Provide records of production deployments showing what was deployed, when, by whom, and through what mechanism. Auditors want to see that deployments went through your CI/CD pipeline, not through manual SSH access to production servers.

SaaS example: CI/CD pipeline execution logs from GitHub Actions or CircleCI showing the deployment trigger (merged PR), automated test results, build steps, and successful deployment to production with timestamps.

Change approval workflows. For changes that require explicit approval beyond code review — infrastructure changes, database migrations, configuration modifications — provide the approval records.

Rollback procedures tested. Evidence that you’ve tested your ability to roll back a failed deployment. This could be a documented test, an actual rollback event with an incident ticket, or a runbook with execution records.

Emergency change documentation. If emergency changes occurred during the observation period (hotfixes deployed without standard review), provide the emergency change tickets showing justification, the change itself, and retrospective review and approval within your policy’s timeframe.

System Operations (CC7)

System operations evidence covers monitoring, incident management, vulnerability management, and operational health. This area tests whether you’re actively watching your systems and responding to issues.

Monitoring dashboards and alert configurations. Show that monitoring is configured for critical systems and that alerts are routed to the right people. Configuration exports from tools like Datadog, PagerDuty, or CloudWatch demonstrating alert thresholds, notification channels, and escalation policies.

Incident tickets with response timelines. For every incident during the observation period, provide the ticket showing detection time, response initiation, containment actions, resolution, and post-mortem completion. Timestamps matter — auditors will measure your response against the SLAs defined in your incident response policy.

SaaS example: A PagerDuty incident record showing alert fired at 02:15 UTC, acknowledged by the on-call engineer at 02:18 UTC, a linked Jira incident ticket with containment steps documented by 02:45 UTC, resolution at 03:30 UTC, and a post-mortem document completed three business days later with root cause analysis and preventive actions.

Vulnerability scan results and remediation tickets. Provide scan results from your vulnerability scanning tools (Snyk, Qualys, Nessus, AWS Inspector) at regular intervals across the observation period, plus tickets showing that identified vulnerabilities were remediated within your policy’s SLA.

SaaS example: Monthly Snyk scan reports showing identified vulnerabilities in dependencies, with linked Jira tickets for critical and high findings showing remediation (dependency updates, patches) completed within 7 and 30 days respectively.

Penetration test reports. At least one penetration test during the observation period, conducted by a qualified third party. The report should include methodology, findings, severity ratings, and your remediation plan with evidence of completion for critical and high findings.

Patch management records. Evidence that operating systems, frameworks, and dependencies are kept up to date. Automated patching configurations, patch deployment logs, and records showing time-to-patch for critical security updates.

Risk Assessment (CC3)

Risk assessment evidence demonstrates that your organization systematically identifies, evaluates, and treats risk. This area connects to your risk assessment policy and feeds into multiple other control areas.

Formal risk assessment document. A completed risk assessment dated within the observation period, following your documented methodology. It should include the risk identification process, likelihood and impact ratings, risk scores, and treatment decisions.

Risk register with treatment plans. A living document showing identified risks, their current status, assigned owners, and treatment actions. Auditors want to see that risks aren’t just identified — they’re actively managed with clear ownership and timelines.

Risk review meeting minutes. Evidence that risk is discussed at a governance level — management meetings, board updates, or dedicated risk review sessions. Minutes should include attendees, risks discussed, decisions made, and action items assigned.

Vendor risk assessments. Risk assessments for your critical and high-risk vendors, demonstrating that third-party risk is integrated into your overall risk management program. For details, see our Vendor Management guide.

Communication (CC2)

Communication evidence proves that security expectations are established and communicated to all relevant parties — employees, management, customers, and vendors.

Security awareness training completion records. Provide records showing that all employees completed security awareness training within your policy’s timeframe. Records should include the employee name, training topic, completion date, and pass/fail status if applicable.

SaaS example: Training platform export showing all active employees completed annual security awareness training, with completion dates falling within the observation period and before each employee’s policy-mandated deadline.

Policy acknowledgment signatures. Records of employees acknowledging receipt and understanding of key policies. At minimum, the Information Security Policy and Acceptable Use Policy should have acknowledgments from every employee, collected during onboarding and after significant policy updates.

Board or management security reporting. Evidence that security posture is communicated to leadership — board meeting minutes with security agenda items, quarterly security reports to management, or executive dashboard reviews.

External security commitments. Your public-facing security page, SLAs with security provisions, and any external security certifications or attestations that you communicate to customers.

Building an Evidence Collection System

Collecting evidence manually is unsustainable. SaaS companies that rely on spreadsheets and quarterly evidence-gathering sprints burn out their compliance teams and produce incomplete records. Here’s how to build a system that works.

Automate where possible. Every tool in your stack has an API. GitHub’s API provides pull request and code review data. AWS CloudTrail provides access and change logs. Okta provides authentication and provisioning events. Jira provides ticket history. Build integrations — or use a compliance platform — that pulls evidence automatically on a scheduled basis.

SaaS example: A nightly job that exports the previous day’s production deployment logs from GitHub Actions, access events from Okta, and alert events from PagerDuty into your evidence repository with standardized naming and metadata.

Establish collection cadence. Not all evidence needs daily collection. Define the appropriate frequency for each evidence type:

• Daily: Access logs, deployment logs, monitoring events
• Weekly: Vulnerability scan results, ticket status updates
• Monthly: Training completion records, policy acknowledgment updates
• Quarterly: Access reviews, vendor reviews, risk register updates
• Annually: Penetration test reports, full risk assessments, policy reviews

Centralize evidence storage. All evidence should live in one system with consistent organization. Use a folder structure or tagging system organized by Common Criteria category and control. Every piece of evidence should be linked to the specific control it supports. Consider connecting your evidence program to your continuous monitoring workflows so that gaps are detected in real time.

Assign evidence owners. Each control area needs an identified owner responsible for ensuring evidence is collected on schedule. Engineering leads own change management evidence. The security team owns access control evidence. HR owns training records. Distributed ownership prevents evidence collection from becoming one person’s burden.

Name consistently. Adopt a naming convention that includes the evidence type, control area, date range, and system. Example: access-review_aws-iam_2026-Q1.pdf. When your auditor receives 200 evidence files, consistent naming saves hours of sorting.

Common Evidence Mistakes

These mistakes cause audit delays, findings, and in some cases, qualified opinions. Avoid them.

Gaps in the observation period. If your observation period is January through December and you have access review evidence for Q1, Q2, and Q4 but not Q3, that’s a gap. Auditors can’t assume the control operated during periods with no evidence. For continuous controls (like monitoring), a multi-week gap in log collection could result in a qualified opinion covering that period.

Screenshots without timestamps or context. A screenshot of a configuration screen means nothing without the system name, URL, date of capture, and the person who captured it. Develop a template or checklist for screenshot evidence that includes all necessary metadata.

Evidence that contradicts your policies. Your policy says access reviews happen quarterly with remediation within 14 business days. Your evidence shows a quarterly review where a flagged account wasn’t removed for 45 days. This is a control failure — you’ve provided evidence against yourself. Before submitting evidence, verify it demonstrates compliance with your own policies.

Collecting evidence at audit time instead of continuously. If you try to gather a year’s worth of evidence in the two weeks before your audit, you’ll discover that logs were rotated, screenshots weren’t taken, and nobody remembers the details of an incident from eight months ago. Continuous collection prevents this entirely.

Not preserving evidence from terminated employee accounts. When an employee leaves, their accounts are deprovisioned — correctly. But if that employee was an evidence owner or conducted access reviews, their records might be lost. Ensure that evidence generated by individuals is stored in shared systems, not personal accounts.

Over-collecting without organization. Dumping hundreds of files into a shared drive without naming conventions, control mapping, or date attribution creates work for auditors and your team. More evidence is not better evidence. Organized, relevant, well-labeled evidence is what auditors need.

Working with Your Auditor on Evidence

The auditor relationship directly affects how smoothly evidence collection goes. Invest time upfront to align on expectations. For a detailed overview of the full audit lifecycle, see our Audit Process guide.

Request the evidence request list early. Most audit firms provide a Prepared by Client (PBC) list — a detailed inventory of every evidence item they’ll need, organized by control area. Get this list as early as possible, ideally before your observation period starts, so you can configure your collection processes accordingly.

Agree on evidence format and naming conventions. Ask your auditor how they prefer to receive evidence. Some firms use portals with specific upload structures. Others accept organized folder shares. Agree on file formats — some auditors prefer PDFs for documents and CSVs for data exports. Aligning upfront prevents rework.

Use a shared portal or secure folder structure. Avoid emailing evidence files back and forth. Use a dedicated evidence-sharing mechanism — your auditor’s portal, a shared secure drive, or your compliance platform’s auditor access feature. Organize files to match the PBC list structure so auditors can find what they need without asking.

Respond promptly to follow-up questions. Auditors will have follow-up questions. A deployment log that doesn’t show the reviewer’s name. An access review with an unclear remediation status. Respond within 24 to 48 hours. Delayed responses extend the audit timeline and signal disorganization.

Don’t volunteer evidence that hurts you. This isn’t about hiding problems — it’s about not creating unnecessary confusion. If your auditor asks for access review evidence and you provide 15 supplementary documents that include an outdated access review template alongside the current one, you’ve created a question. Provide exactly what’s requested, organized and contextualized.

How GRCTrail Helps

GRCTrail transforms evidence collection from a manual scramble into an automated, continuous process that keeps your SaaS team audit-ready year-round.

• Automated evidence collection from your existing tools — GitHub, AWS, Okta, Jira, and more — pulling control evidence on a scheduled basis without manual intervention
• Evidence linked to specific controls and criteria so every collected artifact maps directly to the Common Criteria category and control it supports, eliminating the “which evidence goes where” question
• Auditor-ready evidence packages that organize your evidence into the format auditors expect, with consistent naming, metadata, and control mapping that can be shared directly with your audit firm
• Gap detection for missing evidence periods that alerts you when expected evidence hasn’t been collected — before your auditor discovers the gap months later during fieldwork
• Continuous collection with scheduled automation that replaces quarterly evidence-gathering sprints with a steady, automated collection process that runs throughout your observation period

Get started with GRCTrail →

Related Guides

• What Is SOC 2? A Practical Guide for SaaS Companies
• SOC 2 Policies and Procedures: What You Need to Document
• SOC 2 Vendor Management: Third-Party Risk Requirements
• SOC 2 Continuous Monitoring Guide