SOC 2 Type 2 Quarterly Evidence Checklist: What to Collect and When

A SOC 2 Type 2 report evaluates your controls over a period of time—usually 6 to 12 months—rather than at a single point in time. This distinction creates a specific burden: you must prove that your controls were operating effectively continuously. If you fail to collect evidence for a specific quarter, you cannot retroactively generate it. The control fails, and your report lists an exception.

While automated compliance platforms monitor infrastructure configurations continuously, they often miss the "process" evidence that auditors require on a quarterly cadence. This includes screenshots of user access reviews, evidence of vulnerability remediation, and documentation of quarterly policy meetings.

This guide details exactly what evidence you need to collect every quarter to ensure your SOC 2 Type 2 audit remains clean.

What Evidence Must Be Collected Quarterly for SOC 2?

Quarterly evidence generally falls into three buckets: Access Control, Vulnerability Management, and Operational Reviews. Unlike daily automated checks (like "is disk encryption on?"), these are procedural controls that require human action and specific documentation artifacts.

1. User Access Reviews (CC6.1, CC6.2)

The most common source of SOC 2 exceptions is the User Access Review (UAR). Auditors expect you to review access to critical systems—production databases, cloud infrastructure (AWS/GCP/Azure), and identity providers (Okta/Google Workspace)—at least quarterly.

What to collect:

• The Population List: A timestamped export or screenshot of all active users and their roles before the review starts.
• The Review Action: Evidence that a manager or owner reviewed the list. This could be a Jira ticket, a sign-off sheet, or a screenshot of a review tool.
• The Remediation: If access was revoked, you need "before and after" screenshots showing the user was actually removed.

2. Vulnerability Scans and Penetration Testing (CC7.1)

While penetration testing is typically annual, vulnerability scanning should happen at least quarterly.

What to collect:

• Scan Configuration: Screenshots showing the scope of the scan (ensuring it covers all production assets).
• Scan Results: The summary report showing identified vulnerabilities (High, Medium, Low).
• Remediation Evidence: If High/Critical vulnerabilities were found, auditors need proof they were fixed within your SLA (usually 30 days). This often requires a Jira ticket linked to a GitHub PR, followed by a "clean" re-scan screenshot.

3. Security Awareness Training (CC2.2)

Training is often done upon hire and annually, but auditors will ask for a quarterly population sample to ensure new hires during that quarter completed training on time.

What to collect:

• Training Logs: A CSV export or screenshot from your LMS (Learning Management System) showing completion dates for all employees active during that quarter.

Quarterly Evidence Checklist

Use this checklist to ensure you have the necessary artifacts before your audit window closes.

Control Area	SOC 2 Criteria	Task	Evidence Artifact
Access Control	CC6.1, CC6.2	Review user access to production environments	• User list export (timestamped) • Sign-off from system owners • Tickets for revoked access
Access Control	CC6.1	Review privileged access (admin rights)	• Screenshot of admin group members • Confirmation that admin count is appropriate
Vulnerability Mgmt	CC7.1	Run internal/external vulnerability scans	• Scan report summary (PDF) • Jira tickets for remediation • Re-scan screenshot confirming fix
Change Mgmt	CC8.1	Sample Change Advisory Board (CAB) meetings (if applicable)	• Meeting minutes or notes • List of attendees • Decisions made on major changes
Risk Mgmt	CC3.1	Review and update risk register	• Updated Risk Register (spreadsheet/tool) • Meeting notes discussing new risks
Physical Security	CC6.4	Review physical access logs (if you have an office)	• Visitor log export • Badge access review screenshot
Incident Response	CC7.3	Test incident response plan (often annual, but table-top can be quarterly)	• Table-top exercise report • Post-mortem for any actual incidents

How Do Auditors Sample Quarterly Evidence?

Understanding how auditors ask for this data helps you prepare it correctly. Auditors use population sampling.

When your audit begins, the auditor will ask for a "population list" of all occurrences of a control during the audit period.

Example: Change Management (CC8.1)

1. Request: "Provide a list of all 400 changes deployed to production between Jan 1 and Dec 31."
2. Selection: The auditor selects 25 random changes (samples).
3. Evidence: For those 25 specific changes, you must provide the Jira ticket, the pull request, the approval screenshot, and the CI/CD deployment log.

The Trap: If you didn't capture the approval screenshots or PR comments at the time, and your tools (like Slack or Jira) have retention limits or deleted the logs, you cannot produce the evidence. The control fails.

For quarterly controls like Access Reviews, the population is smaller (4 reviews per year). Auditors will typically ask to see all 4 quarters. If you missed Q2, you have a 25% failure rate for that control, which usually results in a qualified opinion (a "bad" report).

Where Traditional SOC 2 Automation Stops

GRC platforms like Drata, Vanta, and Secureframe are excellent at collecting configuration evidence via API. They can instantly tell you if MFA is enabled on your email accounts.

However, they often struggle with evidence that requires contextual screenshots or manual workflows.

• Custom Internal Tools: If you manage user access to an internal admin panel that doesn't have an API, GRC tools can't see it. You must manually take screenshots of the user list every quarter.
• Complex Access Reviews: Automated tools often dump a raw list of users. They don't capture the decision process—the conversation where a manager said, "Keep Bob, remove Alice." That context is often lost in Slack threads or emails unless explicitly captured.
• Proprietary Workflows: If your change management involves a design review in Figma followed by a Slack approval, the API-based GRC tool won't link those disparate pieces of evidence together.

This is where teams often scramble. They rely on the "100% automated" dashboard green light, only to realize during the audit that the auditor rejects the automated evidence because it lacks the necessary detail or context.

Automating the Manual Quarterly Grind

Since you cannot rely solely on APIs for every control, you need a strategy for the "last mile" of evidence collection.

1. Calendar Invites are Not Enough: Don't just put "Run Access Review" on a calendar. Create a ticket in Jira/Linear that blocks the quarter closing.
2. Screenshot Everything: For non-integrated systems, take timestamped screenshots of the user settings page. Ensure the URL bar and system clock are visible.
3. Use Workflow Recorders: Tools that record your screen as you click through a review process can generate a PDF audit trail automatically. This is faster than pasting screenshots into Word documents and provides higher assurance to auditors that the screenshots are authentic.
4. Centralize Storage: Do not leave evidence in email or Slack. Upload every quarterly artifact to a dedicated folder in Google Drive/SharePoint or directly into your GRC tool's "Evidence Library" immediately.

Learn More About SOC 2 Compliance Automation

For a complete guide to handling the artifacts auditors request, see our guide on automating SOC 2 evidence collection, including how to handle the application-level controls that APIs miss. You may also find these relevant:

• Do You Actually Need a vCISO for SOC 2? - Why AI is replacing the $10k/month consultant
• The Bootstrapped Founder's Guide to SOC 2 - How to get SOC 2 done without a massive budget

For more on this topic, see SOC 2 Evidence by Application Type: SaaS Panels, Internal Tools, and Production Environments.

For more on this topic, see SOC 2 Evidence Preparation Checklist: How to Automate Screenshots Before an Audit.