How Auditors Perform a SOC 2 Examination

1. Where SOC 2 Fits in the Attestation World

SOC 2 examinations are attestation engagements performed by independent CPA firms.

As of today (December 2025), the key U.S. standards are:

• AT-C Section 105 – Concepts Common to All Attestation Engagements (AICPA)
• AT-C Section 205 – Examination Engagements
• AT-C Section 320 – Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy

(This is the SOC 2–specific section.)

Historically, SOC 2 engagements were performed under SSAE 16 and then SSAE 18. Those have been codified into the AT-C sections above. In practice, people still say things like “under SSAE 18”, but the technically correct reference is now the AT-C standards.

Big picture:

• The service organization designs and operates the controls.
• The independent service auditor (CPA firm) evaluates those controls and issues a SOC 2 report.
• The report provides assurance to customers and other stakeholders about how well the system’s controls address the Trust Services Criteria (TSC) (e.g., Security, Availability).

2. The Independent Service Auditor’s Role and Independence

In a SOC 2 examination, the auditor is called the independent service auditor.

Core responsibilities

Under AT-C 105/205/320, the auditor must:

1. Plan and perform the engagement to obtain reasonable assurance about whether:

• Management’s description of the system is fairly presented.
• The controls are suitably designed (Type 1 and Type 2).
• The controls operated effectively over the period (Type 2 only).

1. Gather sufficient appropriate evidence using methods like:

• Inquiry
• Observation
• Inspection of documents
• Reperformance

1. Evaluate exceptions (control failures or deviations) and decide how they affect:

• The description of the system
• The control conclusions
• The SOC 2 opinion (unmodified, qualified, adverse, or disclaimer)

Independence requirements

The auditor must comply with AICPA independence rules and, for many firms, IESBA Code of Ethics as well. Independence has two sides:

• Independence in fact: The firm must be objectively unbiased (no financial interest, no management role in the client, etc.).
• Independence in appearance: A reasonable third party would also view the firm as unbiased.

What auditors cannot do in a SOC 2 engagement:

• Design or implement the client’s controls and then audit their own work.
• Make management decisions (e.g., choose which controls to implement).
• Act as part of the client’s internal audit or compliance staff.

What they can do:

• Provide general guidance (e.g., share frameworks, common practices).
• Perform readiness assessments as a separate, non-attest service (with safeguards) and then perform the SOC 2, as long as management remains responsible for decisions.

3. Independence Thought Exercise

Imagine you are a staff auditor at a CPA firm performing a SOC 2 Type 2 examination for a cloud-based HR platform.

For each scenario, decide whether independence is threatened (Y/N). Just think through it; no need to write an answer.

1. Your firm helped the client document their existing controls last year, but management decided what to implement and operates the controls.
2. Your firm designed the access control process, configured the IAM tool, and then performed the SOC 2.
3. You personally own a small amount of stock in the client.
4. Your firm provided a general SOC 2 readiness workshop to multiple companies, including this client, using generic examples.

Now reflect:

• Which scenarios clearly break independence and why?
• Which might be acceptable with safeguards (e.g., different teams, clear documentation that management made decisions)?

Try to connect your reasoning back to independence in fact vs. appearance.

4. From Scoping to Audit Plan: How Auditors Organize the Work

This module builds on earlier ones where you learned how the system and Trust Services Categories are scoped.

Once scope is set, the auditor develops an audit plan. Key planning steps include:

1. Understanding the system

• Review management’s system description (services, boundaries, infrastructure, data flows).
• Identify key processes (e.g., user provisioning, change management, incident response).

1. Understanding controls and risks

• Map controls to the Trust Services Criteria (TSC) (e.g., CC6.1 for logical access).
• Identify risks that could cause the criteria not to be met (e.g., unauthorized access, data loss).

1. Determining materiality and testing strategy

• Decide what would be significant to report users (e.g., failure to restrict production access).
• Decide which controls to test, how often, and what evidence is needed.

1. Choosing the period and type of report

• Type 1: A point-in-time report (e.g., "as of June 30, 2025").
• Type 2: A period (usually 6–12 months, e.g., "January 1–September 30, 2025").

In practice, most mature SaaS providers pursue Type 2 because customers want evidence that controls operated effectively over time, not just that they were designed well on a single date.

5. How Auditors Collect Evidence: The Four Main Methods

AT-C 205 and 320 require auditors to obtain sufficient appropriate evidence. In SOC 2, that usually means combining four methods:

1. Inquiry

• What it is: Asking questions of personnel.
• Examples:
• Interviewing the Security Engineer about how vulnerability scans are run.
• Asking the HR manager how offboarding is handled.
• Limitation: Inquiry alone is not enough; it must be supported by other evidence.

2. Observation

• What it is: Watching a process being performed.
• Examples:
• Observing an engineer submitting a change ticket in the change-management tool.
• Watching an admin approve a new user request in the IAM system.

3. Inspection

• What it is: Reviewing documents, records, or configurations.
• Examples:
• Inspecting access control logs to see who approved access.
• Reviewing policy documents, incident tickets, backup logs, or config screenshots.
• Digital inspection is common in SOC 2 (screenshots, exported logs, configuration files).

4. Reperformance

• What it is: The auditor independently re-does a control procedure.
• Examples:
• Re-running a report that management uses to review privileged access.
• Attempting to log in with a disabled account to confirm access is blocked.

In real SOC 2 engagements, auditors often:

• Combine inquiry + inspection (e.g., interview + ticket evidence).
• Use observation + reperformance for technical controls (e.g., MFA enforcement, firewall rules).

6. Concrete Testing Examples (Security & Availability)

Here are two realistic examples of how auditors test SOC 2 controls.

Example 1: User Access Reviews (Security)

Control (from prior module):

> Management performs a quarterly review of all users with access to the production environment and removes unnecessary access.

How the auditor tests it:

1. Inquiry – Ask the system owner how the review is done.
2. Inspection – Obtain:

• The access review checklist or SOP.
• Evidence for each quarter in the period (e.g., Q1–Q3 2025):
• Exported user lists
• Marked-up spreadsheets showing review
• Tickets where access was removed

1. Reperformance – For a sample of users, independently:

• Compare their role to job responsibilities.
• Confirm that users flagged as terminated actually had access removed.

What the auditor concludes:

• Did reviews occur each quarter?
• Were exceptions (e.g., terminated users still active) identified and remediated?
• Are any deviations significant enough to impact the SOC 2 opinion?

---

Example 2: Backup and Restore Testing (Availability)

Control:

> The company performs daily backups of critical databases and tests restoration at least annually.

How the auditor tests it:

1. Inspection – Review:

• Backup job configurations.
• Backup logs for a sample of days across the period.

1. Observation/Reperformance – Observe (or reperform) a test restore of a backup:

• Confirm the restore completes successfully.
• Validate that restored data is consistent and complete.

1. Inspection – Review documentation of the annual disaster recovery (DR) test.

What the auditor concludes:

• Are backups actually running as scheduled?
• Has the company proven it can restore from backups?
• Any failed backups or untested restores may be logged as exceptions.

7. Sampling, Exceptions, and Deviations

Auditors rarely test every single instance of a control. Instead, they use sampling.

Sampling basics

• Population: All instances of a control during the period.

Example: If offboarding is a control, the population might be all employees terminated from Jan 1–Sep 30, 2025.

• Sample: A subset the auditor tests in detail.
• Selection methods:
• Random sampling (e.g., random number generator).
• Systematic sampling (e.g., every 10th item).
• Risk-based or judgmental sampling (e.g., focusing on high-risk users like admins).

The sample size depends on:

• Length of the period
• Frequency of the control (daily, weekly, quarterly)
• Risk/importance of the control

Exceptions vs. Deviations

• Exception / Deviation: When a tested item does not operate as described.
• Example: One user in the sample did not have MFA enabled, even though the control requires MFA for all users.

Auditors then ask:

• Is the exception isolated or systemic?
• Does it indicate a design problem (control doesn’t work in concept) or an operating problem (control not followed consistently)?
• Is the rate of deviation (e.g., 1 out of 25 samples) acceptable given the risk?

How exceptions affect the report

• If exceptions are minor and infrequent, the auditor may still conclude that controls were operating effectively, but describe the exceptions in the testing results.
• If exceptions are frequent or severe, they may lead to:
• A qualified opinion ("controls were effective except for...").
• In rare, serious cases, an adverse opinion (controls not effective) or disclaimer (insufficient evidence).

8. Quick Check: Evidence and Exceptions

Answer this question to check your understanding of evidence types and exceptions.

9. Putting It Together: Forming the SOC 2 Opinion

After testing, the auditor synthesizes all evidence to form the SOC 2 opinion.

Key questions the auditor answers

1. System description fairness

Is management’s description of the system fairly presented?

• Are services, boundaries, and components described accurately?
• Are relevant subservice organizations (e.g., cloud providers) disclosed?

1. Suitability of design

Are the controls suitably designed to meet the selected Trust Services Criteria as of the specified date (Type 1) or over the period (Type 2)?

1. Operating effectiveness (Type 2 only)

Did the controls operate effectively throughout the examination period?

Types of opinions (for SOC 2)

• Unmodified (clean) opinion:

Controls are suitably designed (and, for Type 2, operated effectively) in all material respects.

• Qualified opinion:

Controls are generally effective except for certain specific matters.

• Adverse opinion:

Controls are not suitably designed or not operating effectively.

• Disclaimer of opinion:

The auditor could not obtain sufficient appropriate evidence (e.g., major data gaps).

In the SOC 2 report, you typically see:

• The auditor’s opinion letter (high-level conclusion).
• Management’s system description.
• The controls and related tests (often in a detailed matrix).
• Any exceptions noted in testing and the auditor’s conclusion about their impact.

10. Scenario Exercise: How Would You Conclude?

Imagine you are on the audit team for a SOC 2 Type 2 engagement covering January 1–September 30, 2025.

You tested three important controls:

1. Quarterly access reviews for production systems

• Evidence: Reviews performed in Q1 and Q3, but Q2 review was missed.

1. Daily backups of production databases

• Evidence: Backups ran successfully on >99% of days. A few backups failed but were re-run the next day successfully.

1. Change management approvals

• Evidence: In a sample of 40 changes, 2 had no documented approval but appeared low-risk bug fixes.

Think through these questions (no need to write answers):

• Which control issues are most likely to be considered significant?
• Could the auditor still issue an unmodified opinion? If yes, what might they disclose in the testing results?
• Under what circumstances might the pattern of exceptions lead to a qualified opinion?

Try to reason from the auditor’s perspective: How do frequency, severity, and risk level shape your conclusion?

11. Review Key Terms

Flip these cards (mentally) to review key concepts from this module.