SOC 2 Control Testing: Auditor Procedures and Expectations

The conference room was silent except for the sound of my client's pen tapping nervously against the table. It was day three of their first SOC 2 Type II audit, and the lead auditor had just asked to see evidence of their quarterly access reviews for the past twelve months.

The CTO's face went pale. "We do access reviews," he stammered. "Every quarter. Like clockwork."

"Great," the auditor smiled. "Can I see the documentation?"

That's when I watched a $2 million deal start to crumble. They had done the reviews—I'd seen them happen. But they hadn't documented them properly. No signatures. No dates. No evidence of follow-up on findings.

In the auditor's eyes, if it wasn't documented, it never happened.

After fifteen years of sitting through hundreds of SOC 2 audits—on both sides of the table—I've learned one fundamental truth: understanding what auditors look for and how they test controls is the difference between a smooth audit and a nightmare that costs you customers, revenue, and sleep.

What Auditors Are Really Looking For (And It's Not What You Think)

Here's something that might shock you: most auditors aren't trying to fail you. I know that sounds crazy when you're sitting across from someone asking for your 47th piece of evidence, but it's true.

What they're actually looking for is simple: consistent, documented proof that your controls operated effectively throughout the entire audit period.

Let me break that down because every word matters:

• Consistent: Not just once, but repeatedly and reliably

• Documented: Written evidence that can be verified

• Proof: Actual evidence, not just your word

• Controls operated effectively: They didn't just exist—they worked

• Throughout the entire audit period: For Type II, that's 3-12 months, not just the last week

I remember auditing a fintech company in 2021. Their access control system was bulletproof—multi-factor authentication, least privilege, regular reviews, the works. But they'd only been documenting it for two months before the audit.

The auditor had to write an exception. Not because the controls were bad, but because there wasn't enough evidence covering the full audit period.

"In SOC 2 audits, 'trust me' are the two most expensive words you can say. Documentation is your currency, and evidence is your proof of payment."

The Five Trust Services Criteria: What Gets Tested

Before we dive into how auditors test, you need to understand what they're testing. SOC 2 is built around five Trust Services Criteria. Not every organization needs all five, but you need to understand how each one gets tested.

In my experience, Security criteria testing consumes about 60-70% of the audit effort, even in reports that include all five criteria. Why? Because security underpins everything else.

Control Testing Methods: How Auditors Actually Work

I've watched hundreds of auditors work, and they typically use five main testing methods. Understanding these will transform how you prepare.

1. Inquiry (The Warm-Up)

This is where it starts. The auditor asks questions to understand how your control works.

What it looks like in practice: "Walk me through your process for onboarding a new employee. Who approves access? How is it granted? What documentation is created?"

What they're really doing: Building a mental model of how your control should operate, which they'll then verify through other testing methods.

Pro tip from the trenches: Never assume inquiry alone is sufficient. I've seen companies give perfect answers to questions but fail to produce evidence. Inquiry just opens the door—other methods lock in the findings.

2. Observation (Show Me, Don't Tell Me)

The auditor watches your process in action.

Real example from my experience: I was consulting for a healthcare company during their audit. The auditor asked to observe their daily vulnerability scan review process. We scheduled it for 9 AM the next day.

At 9:05 AM, the security team pulled up their scanning tool, reviewed the previous night's scan results, created tickets for new findings, and updated existing tickets. The whole process took 17 minutes.

The auditor took notes, asked clarifying questions, and marked the control as "observed operating effectively."

The catch: Observation only proves the control worked once, at that moment. It's valuable but not sufficient for Type II audits.

3. Inspection (The Paper Trail)

This is where documentation becomes critical. The auditor examines records, logs, reports, approvals, and any other evidence.

Common inspection requests:

Here's a war story that illustrates why inspection matters:

I worked with a SaaS company that had implemented excellent access controls. Every quarter, the IT director performed comprehensive access reviews, identified inappropriate access, and remediated issues.

During the audit, the auditor asked for documentation of Q2's access review. The company provided:

• A spreadsheet showing current access (created the day before the audit)

• An email saying "access review complete"

What was missing:

• The actual review from Q2 showing what access existed then

• Documentation of what exceptions were found

• Evidence of remediation

• Approval from management

Result? Exception noted for insufficient evidence.

"Auditors don't audit your intentions or your current state. They audit your documented history. If you can't prove it happened, it didn't happen."

4. Re-performance (Trust, But Verify)

The auditor independently repeats your control procedure to verify it works.

Classic re-performance example: Your control states that employees terminated on day X should have access removed within 24 hours.

The auditor will:

1. Get a list of all terminations during the audit period

2. Select a sample (typically 25 terminations)

3. For each one, verify in your systems that access was actually removed

4. Check the timestamp to confirm it was within 24 hours

5. Look for any terminated employees who still have access

I watched an auditor do this exact test at a client site in 2022. Out of 25 terminated employees tested, 23 had access removed properly. Two still had active accounts 3 and 7 days after termination.

Exception noted. Not because the control design was bad, but because it hadn't operated effectively in 100% of instances.

The company had to:

• Explain why the exceptions occurred

• Show what corrective actions were taken

• Provide evidence that the control now operates effectively

5. Recalculation (The Math Check)

For controls involving calculations or formulas, auditors verify the math.

This comes up less frequently but is critical for things like:

• Encryption strength calculations

• Uptime percentage calculations (for Availability criteria)

• Risk scoring formulas

• Data retention calculations

Example from my consulting days:

A client included Availability in their SOC 2 report and committed to 99.9% uptime. They reported 99.94% uptime for the year.

The auditor recalculated using the raw system logs:

• Total minutes in audit period: 525,600

• Total downtime minutes: 482

• Actual uptime: 99.908%

The client's calculation was correct, control passed. But I've seen auditors find discrepancies where companies rounded favorably or excluded certain outages from their calculations.

Sample Selection: Understanding the Numbers

One of the most common questions I get: "How many samples will the auditor test?"

Here's what I've observed across hundreds of audits:

Important caveat: These are guidelines. I've seen auditors adjust based on:

• Control risk (higher risk = more samples)

• Previous exceptions (prior issues = more scrutiny)

• System maturity (newer systems = more testing)

• Client size (enterprise clients often get larger samples)

The Population Problem I See All The Time

A cloud services company I worked with had documented that they performed daily backup monitoring. Sounds great, right?

During the Type II audit (covering 12 months), the auditor asked for evidence of this daily monitoring. The company provided:

• January: 31 monitoring reports ✓

• February: 28 monitoring reports ✓

• March: 29 monitoring reports ✗ (2 missing)

• April: 30 monitoring reports ✓

• May: 27 monitoring reports ✗ (4 missing)

• ...and so on

By the end, they had 47 missing daily reports out of 365. That's 87% effectiveness.

The auditor noted an exception. Why? Because the control was designed to operate daily, and 13% failure rate suggested the control wasn't operating effectively.

The lesson? When you commit to a frequency (daily, weekly, monthly), you're establishing the testing population. Every single instance matters.

The Testing Timeline: What Happens When

Understanding the audit timeline helps you prepare properly. Here's how a typical Type II audit unfolds:

Phase 1: Planning (Weeks 1-2)

What happens:

• Kickoff meeting

• Auditor reviews your system description

• Control matrix review and confirmation

• Sample requests sent

What you should be doing: I tell clients to start gathering evidence before the auditor even asks. Create a shared folder organized by control number with all your evidence pre-loaded.

Real talk: I worked with a company that had everything organized before the auditor's first sample request. The auditor told me privately: "This is the most prepared client I've seen all year. It gives me confidence in their control environment."

That confidence translated to fewer surprise requests and a smoother audit.

Phase 2: Testing (Weeks 3-6)

What happens:

• Auditors request samples

• You provide evidence

• Auditors review and ask follow-up questions

• Testing for each control area

Sample request you might receive:

Control CC6.1: Logical Access - User Access Provisioning

Common mistakes I see:

Phase 3: Exception Resolution (Weeks 7-8)

What happens: This is when auditors circle back on anything that didn't pass initial testing.

Real scenario from 2023:

I was helping a client through their audit when we hit an exception on change management testing. Out of 40 changes tested, 3 didn't have documented approval before deployment.

The auditor gave us options:

1. Provide the missing approvals if we could locate them

2. Explain why the exceptions occurred

3. Show what corrective actions we'd implemented

We found 1 of the 3 approvals buried in email. For the other 2, we:

• Documented the root cause (approval workflow bypassed during emergencies)

• Showed the policy update that now required post-deployment approval documentation for emergencies

• Provided evidence the new process was working (last 3 months of changes all had proper approvals)

The auditor still noted an exception but acknowledged the remediation in the report. The client didn't lose any deals because of it.

"Exceptions aren't automatic failures. How you respond to exceptions tells auditors—and customers—more about your security maturity than perfect controls ever could."

Phase 4: Reporting (Weeks 9-10)

What happens:

• Auditor drafts report

• You review for factual accuracy

• Final report issued

Pro tip: Read the draft report carefully. I've caught factual errors in draft reports that, if left uncorrected, would have misrepresented the client's controls.

Control Categories and Testing Deep-Dive

Let me walk you through how auditors test the most common control categories, with specific examples from my experience.

User Access Management

What auditors test:

War story:

A SaaS company I worked with had 347 employees and performed quarterly access reviews. During testing, the auditor discovered:

• Q1 review: Properly documented, 12 exceptions found and remediated ✓

• Q2 review: Completed but no documentation of exceptions found or remediation ✗

• Q3 review: Documentation showed review "in progress" but never completed ✗

• Q4 review: Properly documented, 8 exceptions found and remediated ✓

Result: Exception for inconsistent operation. The auditor noted that while the control worked in Q1 and Q4, the gaps in Q2 and Q3 showed it wasn't operating effectively throughout the period.

The fix: They implemented automated quarterly reminders and a checklist template that forced documentation of all steps. The next audit had zero exceptions in this area.

Change Management

This is where I see the most exceptions, hands down.

What makes auditors happy:

1. Clear change request: What's changing, why, who requested it

2. Risk assessment: What could go wrong?

3. Approval before implementation: Manager or change board approval

4. Testing evidence: How did you verify the change worked?

5. Rollback plan: What if something goes wrong?

6. Implementation evidence: Timestamps, deployment logs

7. Post-implementation validation: Did it actually work?

Sample size reality check:

For a company making 200+ changes during their audit period, auditors typically test 40-60 changes. That's 20-30% of your changes. If your process isn't consistently followed, they'll find it.

The exception that cost $400K:

In 2020, I consulted for a company going through their first Type II audit. They had a well-documented change management process but rarely followed it for "minor" changes.

Auditor tested 50 changes:

• 42 followed the full process ✓

• 8 had missing or incomplete approval documentation ✗

That's an 84% effectiveness rate. SOC 2 expects controls to operate effectively, which generally means 95%+ effectiveness.

The exception made it into their report. Three prospects in the middle of vendor security reviews saw the exception and asked for detailed explanations. One deal worth $400K fell through because their security team couldn't justify the risk to their CISO.

Vulnerability and Patch Management

Standard auditor expectations:

Real-world example:

I worked with a fintech company that committed to patching critical vulnerabilities within 30 days. The auditor tested 35 critical vulnerabilities identified during the audit period.

Results:

• 28 patched within 30 days ✓

• 4 patched within 45 days ✗

• 3 still unpatched at audit date ✗

The company argued that the delayed patches were due to vendor dependencies. The auditor's response: "That's a valid reason, but where's the documented risk acceptance? Where's the compensating control? Where's the management approval to exceed your policy timeframe?"

They had none of that. Exception noted.

The fix: They implemented a formal exception process:

1. Any vulnerability exceeding policy timeframe triggers exception request

2. Owner documents reason and risk assessment

3. Compensating controls identified and implemented

4. CISO approval required

5. Monthly review of all open exceptions

Next audit: Zero exceptions in this area.

Evidence Management: The Make-or-Break Factor

After watching hundreds of audits, I can tell you the #1 differentiator between smooth audits and nightmares: evidence management.

The Evidence Package Framework

Here's the system I teach every client:

Folder structure:

SOC2_Audit_2024/
├── CC1_Control_Environment/
│   ├── CC1.1_Organizational_Structure/
│   │   ├── EVIDENCE_Org_Chart_2024.pdf
│   │   ├── EVIDENCE_Board_Minutes_Security_Oversight.pdf
│   │   └── INDEX.md (describes what each file proves)
│   ├── CC1.2_Management_Philosophy/
│   └── CC1.3_Organizational_Structure/
├── CC2_Communication/
├── CC6_Logical_Access/
└── SAMPLE_TRACKING.xlsx

Evidence Quality Checklist

Before submitting any evidence, I verify:

• [ ] Date range visible and falls within audit period

• [ ] Specific users/systems/items identified

• [ ] Action and outcome clearly shown

• [ ] Timestamp or effective date visible

• [ ] Source system identifiable

• [ ] Any approvals or reviews documented

• [ ] File named descriptively (not "Screenshot 2024-11-15.png")

Good evidence naming: CC6.1_Access_Provisioning_JohnSmith_Approved_20240315.pdf

Bad evidence naming: image1.png

Common Evidence Problems I See

Preparing for Specific Testing Scenarios

Let me walk you through how to prepare for some of the trickiest testing scenarios.

Scenario 1: Incident Response Testing

What auditors want to see:

If you had incidents during the audit period, they'll test your response. If you didn't, they may do a tabletop exercise or review your procedures and training.

Testing approach:

1. List all incidents during audit period

2. Select sample (typically 5-10 if you had multiple)

3. Verify each element of your incident response process

What I tell clients:

Create an incident response folder for each incident containing:

• Initial detection/alert

• Incident ticket/record

• Investigation notes

• Containment actions

• Remediation steps

• Post-mortem/lessons learned

• Communication to affected parties (if applicable)

Real example:

A healthcare company I advised had a ransomware incident during their audit period. They had excellent documentation:

• Alert triggered at 2:47 AM

• On-call engineer paged at 2:49 AM

• Incident commander assigned at 3:15 AM

• Affected systems isolated at 3:27 AM

• Incident response team assembled (via Zoom) at 4:00 AM

• Executive notification at 6:30 AM

• Systems restored from backup at 11:45 AM

• Full post-mortem completed within 72 hours

The auditor reviewed everything and noted: "This is exactly what we want to see. The incident was handled professionally, documented thoroughly, and improvements were identified and implemented."

The incident actually strengthened their SOC 2 report because it proved their controls worked under pressure.

Scenario 2: System Availability Testing

For organizations including Availability criteria, this gets technical fast.

What auditors calculate:

Uptime % = (Total Time - Downtime) / Total Time × 100

Auditor testing process:

1. Review your availability commitment (e.g., "99.9% uptime")

2. Collect system monitoring logs for entire audit period

3. Identify all downtime incidents

4. Recalculate uptime percentage

5. Verify you met your commitment

The gotcha:

I've seen companies get tripped up by how they define "downtime." Your definition must be clear:

• Planned maintenance: Included or excluded?

• Partial outages: How counted?

• Third-party service issues: Your responsibility or theirs?

• Measurement methodology: Synthetic monitoring? Real user monitoring?

Case study:

A SaaS company committed to 99.95% uptime "excluding planned maintenance." During audit testing, the auditor found:

• Actual uptime: 99.89% (missed commitment)

• Planned maintenance windows: 4 hours per month

The problem? Their system had failed to send advance notifications for 2 of their 12 maintenance windows. The auditor ruled those as unplanned downtime, even though the work itself was planned.

Result: Availability criteria exception noted.

The lesson: Define everything explicitly, and follow your definitions religiously.

Scenario 3: Background Check Testing

This seems simple but trips up many organizations.

What auditors verify:

1. All employees and contractors with system access had background checks

2. Checks completed before access granted (or within policy timeframe)

3. Check scope matches policy (e.g., criminal, employment verification, education)

4. Results reviewed and documented

5. Appropriate action taken on adverse findings

Common issue:

A company I worked with had a policy requiring background checks "within 30 days of hire." The auditor tested 25 new hires:

• 22 had checks completed within 30 days ✓

• 3 had checks completed on days 32, 35, and 41 ✗

Even though the delays were minor and all checks came back clean, the control didn't operate according to its design.

The fix: Change the policy to "within 45 days" (more realistic) and implement automated reminders at day 20 to ensure completion.

Red Flags That Auditors Watch For

After years on both sides of audits, I know what makes auditors dig deeper:

Organizational Red Flags

• High turnover in security or IT leadership during audit period

• Major system or organizational changes without change management documentation

• Unclear roles and responsibilities

• Security policies last updated 3+ years ago

• Significant findings from previous audits not remediated

Documentation Red Flags

• Evidence created just before audit (auditors can tell)

• Inconsistent formatting or processes across samples

• Generic screenshots without identifying information

• "To be completed" or placeholder sections in policies

• Last-minute policy updates dated right before audit

Technical Red Flags

• Multiple terminated employees with active access

• Excessive administrative/privileged access

• Shared accounts or generic credentials

• No logging or monitoring for critical systems

• Outdated or unpatched systems

• Failed backup or restoration tests

Story time:

I consulted for a company during their audit where the auditor noticed all their access review documentation was created on the same day—two weeks before the audit started.

The company insisted they'd done quarterly reviews all year but "just formalized the documentation recently."

The auditor tested this by requesting the actual source data from each quarter (user lists, system exports, etc.). The company couldn't produce it. They'd deleted old exports and could only show current state.

Result: Exception for insufficient evidence, even though they'd probably done the work.

"In auditing, recency is evidence. If all your documentation is brand new, auditors assume you created it for the audit, not as part of normal operations."

How to Handle Exceptions (Because They Happen)

Let's be realistic: most first-time Type II audits have at least a few exceptions. Here's how to handle them professionally.

Types of Exceptions

The Exception Response Framework

When an exception is identified, I coach clients through this process:

1. Acknowledge and Understand

• Don't argue or get defensive

• Ask clarifying questions if you don't understand the issue

• Document the auditor's specific concern

2. Provide Context

• Explain what happened (facts only, no excuses)

• Show what you've learned

• Demonstrate you understand the risk

3. Document Remediation

• What have you already fixed?

• What process changes have you implemented?

• How are you preventing recurrence?

4. Provide Evidence

• Show the corrected process in action

• Demonstrate the control now operates effectively

• Provide recent samples proving effectiveness

Real example of excellent exception handling:

A client had an exception for incomplete change documentation (5 out of 50 changes missing approval before implementation).

Their response:

1. Root cause analysis showed approvals were happening verbally in standup meetings

2. Implemented new change approval workflow requiring documented approval in ticket system

3. Trained all engineers on new process

4. Provided evidence of 20 subsequent changes all following new process

5. Implemented automated workflow that prevents deployment without approval

The auditor noted the exception but included detailed remediation in the report. Prospects who reviewed the report actually praised the company's thorough response.

Post-Audit: Setting Up for Success Next Year

Your Type II report is valid for 12 months. Here's what I tell clients about maintaining controls:

The Continuous Monitoring Mindset

Monthly activities:

• Review sample of access provisioning/modifications/terminations

• Verify vulnerability scanning occurred and critical issues addressed

• Spot-check change management documentation

• Review incident response handling

• Test backup restoration

Quarterly activities:

• Conduct access reviews

• Review and update risk assessments

• Test disaster recovery procedures

• Update policies and procedures if needed

• Security awareness training

Annual activities:

• Full control self-assessment

• Policy review and updates

• Business continuity/disaster recovery testing

• Third-party security assessment (pen testing)

• Review of all exceptions from previous audit

Evidence Collection Cadence

Don't wait until the next audit to collect evidence. I recommend:

Weekly: Export access logs, change logs, vulnerability scan results Monthly: Document completion of monthly activities, save monitoring reports Quarterly: Save access review evidence, training completion records As-it-happens: Incident response documentation, business continuity tests

Pro tip: Set up a "SOC 2 Evidence" shared drive that automatically collects:

• System logs (automatically exported)

• Scan results (automatically saved)

• Change tickets (automatically exported)

• Training completion reports (automatically generated)

By next audit, you'll have everything organized and ready.

The Auditor Relationship: Making It Work for You

Here's something most people don't realize: your auditor can be your best consultant if you let them.

During the Audit

Do:

• Ask questions when you don't understand something

• Request clarification on evidence requirements

• Proactively communicate issues you've discovered

• Treat auditors as partners, not adversaries

Don't:

• Hide problems or provide misleading information

• Argue about sample sizes or testing approaches

• Miss deadlines for evidence submission

• Go silent when you've discovered an issue

The Pre-Audit Meeting Strategy

I always recommend clients have a pre-audit meeting with their auditor (before fieldwork starts) to discuss:

• Any significant changes since last audit

• Areas where you have concerns

• Questions about specific controls

• Timeline and logistics

Real example:

A client discovered three months before their audit that they'd missed documenting their Q3 access review. They could have tried to hide it or create documentation after the fact.

Instead, I advised them to tell their auditor immediately. We explained:

• What happened (owner was on medical leave, backup didn't follow through)

• What we found when we discovered it (no inappropriate access)

• What we'd implemented to prevent recurrence (automated reminders, documented backup owners)

• Evidence showing Q4 and Q1 reviews completed properly

The auditor appreciated the honesty. While they still had to note the exception, they worked with us to frame it appropriately and document the remediation thoroughly.

Final Thoughts: The Mindset That Makes Audits Easier

After fifteen years and hundreds of audits, here's what I know for certain:

The companies that breeze through audits don't treat controls as audit requirements. They treat them as how they operate.

When security controls are genuinely embedded in your daily operations—not something you "turn on" for audits—everything becomes easier.

I've watched organizations transform from dreading audits to barely noticing them. The difference? They stopped thinking "How do we pass the audit?" and started thinking "How do we run a secure, reliable business?"

When you reach that point, audit testing becomes validation of what you already know: your controls work, your systems are secure, and your customers' data is protected.

That's when compliance stops being a burden and starts being a competitive advantage.

"The best audit prep isn't cramming for the test. It's building a business that would pass the test any day of the year, whether an auditor was watching or not."

Your Audit Prep Checklist

Here's the checklist I give every client:

90 Days Before Audit

• [ ] Review all controls in your matrix

• [ ] Conduct self-assessment of each control

• [ ] Identify any gaps in evidence

• [ ] Begin remediation of any deficiencies

• [ ] Set up evidence collection processes

60 Days Before Audit

• [ ] Confirm audit scope and criteria with auditor

• [ ] Review and update system description

• [ ] Verify all policies are current

• [ ] Complete any outstanding remediation

• [ ] Organize existing evidence by control

30 Days Before Audit

• [ ] Conduct mock audit of high-risk controls

• [ ] Prepare evidence packages for each control

• [ ] Brief all teams on audit process and expectations

• [ ] Set up dedicated communication channel for audit

• [ ] Prepare list of questions for kickoff meeting

During Audit

• [ ] Respond to sample requests within agreed timeframe

• [ ] Track all evidence submitted

• [ ] Document any issues discovered during testing

• [ ] Maintain regular communication with audit team

• [ ] Begin remediation of any identified exceptions

After Audit

• [ ] Review draft report carefully

• [ ] Address any exceptions with detailed remediation plans

• [ ] Implement improvements identified during audit

• [ ] Set up continuous monitoring processes

• [ ] Schedule quarterly self-assessments