Why Your Auditor Says “Show Me, Don’t Tell Me”: Evidence in SOC 2 Explained

Why proof matters more than promises during a SOC 2 audit and how to prepare the right evidence every time.

One of the biggest surprises companies face during their first SOC 2 audit is this: auditors don’t want explanations they want evidence.

You can tell an auditor, “We review access quarterly.” You can even explain how the process works. But unless you show proof screenshots, logs, tickets, approvals, or reports the control is considered not operating effectively.

Why “Show Me, Don’t Tell Me” Matters in SOC 2

SOC 2 is built on trust and verification. The goal is to prove that your security controls work in real life not just on paper.
Your auditor needs to confirm that each control:

• Exists and is clearly defined
• Operates consistently over time
• Worked across the entire audit period

Words alone cannot prove that. Evidence can.
This is why SOC 2 audits focus heavily on sampling auditors pull real examples from real dates to show that controls were not ignored or skipped.

A Fictional Example: “We Definitely Did That… Didn’t We?”

This example is fictional but inspired by common SOC 2 failures.

BrightGate Cloud, a 35-person SaaS company, proudly told their auditor:

The auditor replied:

Suddenly, things fell apart:

• Offboarding tickets were missing.
• IT had no screenshots of disabled accounts.
• HR had no logs that matched the dates.
• One former engineer still had access to a dev system.

The team did remove access most of the time but without documented proof, none of it counted.

This is the difference between intention and verification.

The Types of Evidence SOC 2 Auditors Expect

Different controls need different types of evidence. Here is a simple breakdown to keep things clear and practical.

1. Screenshots (Most Common)

Screenshots prove the current state of a system at a point in time.
Useful for showing:

• MFA enforcement in your identity provider
• Logging or SIEM configuration
• Password and session policies
• Firewall rules or security groups
• Disabled user accounts after offboarding

Tip: Make sure timestamps, usernames, and system names are visible wherever possible.

2. System Logs

Logs prove that activity actually happened not just that a setting exists.
Examples include:

• Authentication and access logs
• Deployment logs and CI/CD history
• Alert and incident logs
• Change history for critical systems

Logs help auditors pull samples and verify that activities were performed on real dates.

3. Tickets or Workflow Records

Tickets show who requested, who approved, and when it was done.
Tickets are key evidence for:

• Onboarding and offboarding
• Change management and releases
• Risk acceptance decisions
• Vendor onboarding and reviews

If something important happened, there should be a ticket or workflow record.

4. Policies and Procedures

Policies show intent. Procedures show how work is done.
But policies alone cannot prove compliance. They must match the evidence.
For example, if your policy says “We perform quarterly access reviews,” your auditor will ask for:

• The review document or export
• The reviewer’s name and role
• The date of the review
• Any findings and remediation actions

5. Sampling Evidence

Sampling is one of the most misunderstood parts of SOC 2.
Typically, an auditor will:

• Pick a random month, user, or ticket.
• Ask for evidence tied to that specific sample.
• Mark an exception if the evidence is missing.

Common sample types include:

• A set of onboarding or offboarding records
• Several change tickets for major releases
• Access reviews for key systems
• Training completion lists for selected dates

This is where companies panic because evidence is often stored inconsistently across tools.

A Simple Table: Good vs. Bad Evidence

The pattern is simple: statements fail, proof passes.

Why SOC 2 Evidence Feels Hard for Many Teams

Most organizations do the work. The problem is that they don’t capture the work.
Common challenges include:

• Evidence spread across many tools and folders
• Teams forgetting to take screenshots or save reports
• Tickets not created for every change or access request
• No clear ownership for each control
• People assuming “someone else documented it”

SOC 2 doesn’t fail because companies never perform controls. It fails because companies don’t document those controls in a repeatable way.

How to Make SOC 2 Evidence Easy (Not Stressful)

You can reduce audit chaos with a few structured habits.

1. Assign Ownership for Every Control

Every SOC 2 control should have a single named owner not a committee and not “the security team.”

• One owner per control.
• Clear responsibilities.
• Defined expectations per month or quarter.

This removes confusion and makes follow-up easier.

2. Create a Monthly or Quarterly Evidence Checklist

Instead of gathering everything at the end of the year, build a rhythm:

• Collect screenshots monthly.
• Save logs in a central location.
• Document changes as they happen.
• Update access reviews on a fixed schedule.

This makes the audit feel like a review, not a rescue mission.

3. Automate What You Can

Automation helps maintain consistency across the audit period.

Tools can:

• Pull and store logs on a schedule
• Track access changes automatically
• Alert when controls are missed
• Generate reports that map directly to SOC 2 controls

The more your evidence is automated, the less you rely on memory.

4. Use a Central Evidence Repository

Store everything in one place, such as:

• SharePoint or Google Drive
• Confluence or Notion
• A dedicated SOC 2 or compliance platform

Organize evidence by:

• Control ID or area (e.g., access control, change management)
• Audit period and date
• Type of evidence (logs, screenshots, tickets)

Auditors love organized evidence and your internal team will too.

A Fictional Timeline: What “Good Evidence” Looks Like

Here’s a simple fictional timeline that illustrates what “audit-ready” looks like across a year.

• January: Access review performed, screenshot saved, sign-off recorded.
• March: New vendor added, security review completed, approval stored.
• May: Offboarding ticket created, account disabled, timestamp logged.
• August: Incident response test completed, outcomes documented.

When an auditor arrives, the team doesn’t scramble they simply share the evidence repository.

Stay Connected With Canadian Cyber

Follow Canadian Cyber for SOC 2 insights, vCISO guidance, and practical security tips: