What does a SOC 2 auditor actually look for?

A SOC 2 auditor evaluates whether your controls are suitably designed (Type 1) and operating effectively (Type 2) against the applicable Trust Services Criteria. In practice this means reviewing policy documents, testing technical controls (such as MFA enforcement, encryption configuration, access logs), interviewing key personnel, reviewing change management records, and inspecting evidence of ongoing monitoring activities. Auditors test a sample of evidence from across the observation period for Type 2 engagements.

What is a SOC 2 readiness assessment?

A SOC 2 readiness assessment is a pre-audit evaluation — usually conducted by the organisation itself or with outside help — that identifies which controls are in place, which are partially implemented, and which are missing. A readiness assessment produces a gap list that the team works through before engaging a formal auditor. Running a readiness assessment first prevents wasting audit fees on an engagement before controls are actually ready.

What are the most common SOC 2 audit failures?

The most common SOC 2 audit findings include: missing or unsigned policy documents, inconsistent MFA enforcement (some users without MFA), inadequate access review cadence (annual reviews missing), unencrypted data stores, undocumented change management procedures, missing security training records, and vendor risk assessments that are outdated or incomplete. Most of these are process and documentation failures rather than technical ones.

How do I collect evidence for a SOC 2 audit?

Evidence for a SOC 2 audit typically includes: screenshots or API exports of security configurations (MFA settings, encryption settings, firewall rules), access logs and access review records, policy documents with employee acknowledgement timestamps, change management records, incident response records, vendor assessment questionnaires and responses, and training completion records. Compliance automation tools like zGovern collect much of this evidence automatically by integrating directly with your infrastructure, eliminating the manual screenshot-and-upload workflow.

How long does a SOC 2 audit take?

A SOC 2 Type 1 audit — from the start of the formal engagement to report issuance — typically takes 6–10 weeks. A SOC 2 Type 2 audit requires a minimum 6-month observation period before fieldwork begins, so the total time from engagement start to report issuance is 8–16 months. The readiness phase before the formal engagement adds 2–4 months for most organisations.

SOC 2 Blog · March 2026

SOC 2 Audit: A Step-by-Step Guide to Your First Audit (2026)

By the zGovern Team · 12-minute read · March 16, 2026

Your first SOC 2 audit is intimidating for good reason: it is an independent examination of your entire security control environment, conducted by a licensed CPA firm with the authority to issue a qualified (i.e., negative) opinion that customers will see. Getting it wrong — or arriving unprepared — is expensive, time-consuming, and can damage sales relationships if the report is delayed or contains exceptions.

The good news is that SOC 2 audits are entirely predictable. Auditors follow a defined methodology, test the same types of controls, and ask for largely the same evidence from engagement to engagement. Once you understand the process, you can prepare precisely and efficiently — especially if you are using a compliance automation platform like zGovern to maintain a continuous, audit-ready evidence library throughout the year.

This guide walks through every stage of the SOC 2 audit process, from initial gap assessment through report issuance, with specific guidance on what to prepare at each step.

Key Takeaways

A SOC 2 audit has two distinct phases: a readiness phase (before the formal engagement) and the audit itself. Investing in readiness prevents expensive surprises during fieldwork.
Auditors test both design and operating effectiveness — policies alone are never sufficient evidence. You need logs, records, and configuration exports to prove controls are working.
The most common audit failures are documentation gaps and inconsistent enforcement of controls like MFA, access reviews, and change management — not technical vulnerabilities.
Continuous evidence collection via a platform like zGovern transforms the Type 2 observation period from a frantic sprint into a background process.
Selecting the right auditor matters: experience with technology companies and familiarity with cloud-native architectures significantly affects both cost and efficiency.

What SOC 2 Auditors Actually Look For

Understanding the auditor's perspective is the most important foundation for audit preparation. A SOC 2 auditor is not looking for a perfect security posture — they are looking for evidence that your controls are real, documented, consistently applied, and proportionate to the risks your organisation faces.

Auditors evaluate controls through three lenses:

Design adequacy: Is the control designed in a way that would actually address the risk it is meant to mitigate? A policy that says "MFA is required for all users" is designed adequately. A policy that says "MFA is encouraged" is not.
Implementation: Was the control actually put in place? An MFA policy with no enforcement configuration in your identity provider is designed but not implemented.
Operating effectiveness: Did the control operate consistently throughout the observation period? An MFA policy that was enforced for 8 months but then disabled for a month due to a migration, without compensating controls, may generate a finding.

Evidence auditors typically request includes: policy documents with version history and employee acknowledgement records, technical configuration exports (IAM policies, security group rules, S3 bucket settings, encryption configurations), access logs and access review records, change management records, incident response logs, vendor assessment questionnaires, security training completion records, and background check or onboarding records for personnel with privileged access.

Readiness Assessment vs Formal Audit

A critical distinction that many teams miss: the readiness assessment and the formal audit are separate activities. A readiness assessment is conducted before the formal engagement — either internally or with help from a consultant or your auditor in a pre-engagement phase — to identify gaps that need to be closed before the auditor begins testing.

Skipping the readiness assessment and going straight to a formal audit engagement is a common and expensive mistake. Every finding the auditor discovers during fieldwork costs real money in additional audit hours and creates a finding in the report. A readiness assessment surfaces those issues first, when they can be fixed quietly.

A well-executed readiness assessment produces:

A gap analysis listing controls that are missing, partially implemented, or not evidenced
A prioritised remediation plan with owners and target completion dates
A confirmed evidence collection process so the observation period starts cleanly
A scoping decision: which Trust Services Criteria are in scope and why
An estimated audit-ready date so you can schedule the formal engagement with confidence

zGovern's readiness report feature provides exactly this output: a per-framework view of control completion, identified gaps, and a projected audit-ready date based on current velocity — giving compliance managers a live readiness dashboard rather than a periodic spreadsheet.

The SOC 2 Audit Process: Step by Step

Gap Assessment (Weeks 1–4)

Map all applicable Trust Services Criteria to your existing controls. Identify which controls are implemented and evidenced, which are partially implemented, and which are missing entirely. Document your system description — the scope of your SOC 2 engagement including the systems, infrastructure, and data in scope.

Connect zGovern to your infrastructure for automated gap detection
Review all existing policies and confirm they are current, approved, and distributed
Identify personnel responsible for each control area

Remediation (Weeks 4–16)

Address the gaps identified in the assessment. Remediation typically involves a mix of technical work (configuring controls), process work (establishing procedures and assigning owners), and documentation work (writing or updating policies).

Enforce MFA across all users and privileged accounts
Enable encryption at rest and in transit for all customer data stores
Implement a formal access review cadence (quarterly recommended)
Write or update: Information Security Policy, Incident Response Plan, Change Management Policy, Acceptable Use Policy, Vendor Management Policy, Business Continuity Plan
Establish security training program and track completions
Implement logging and alerting for security events

Begin Evidence Collection and Observation Period (Month 3+)

For Type 2, the observation period must be at least 6 months. Start it as soon as controls are in place. Use zGovern's continuous monitoring to collect evidence automatically: access logs, configuration snapshots, monitoring check results, incident records, and vendor assessment records all accumulate in the evidence library.

Configure zGovern integrations to your cloud providers, identity providers, and HR systems
Schedule and complete quarterly access reviews within the platform
Log all incidents and their resolutions in the risk register
Track vendor assessments and review status

Auditor Selection and Engagement (Month 4–6)

Select a CPA firm with experience auditing technology companies. Request references from companies of similar size and stack. Negotiate scope carefully — every criterion and system in scope adds cost. Define the audit period dates, report delivery timeline, and fee structure before signing the engagement letter.

Prioritise auditors familiar with AWS, GCP, Azure, and common SaaS tooling
Ask about their familiarity with SOC 2 automation platforms like zGovern
Clarify what evidence format they prefer and how they want it delivered

Audit Fieldwork (3–6 Weeks)

The auditor conducts their formal testing. They will send a PBC (Prepared by Client) list — a request for evidence. Using zGovern's one-click audit bundle export, you can deliver a structured package of evidence covering controls, risks, evidence items, and policies in seconds rather than days. Expect walkthrough calls with key personnel and requests for configuration screenshots or log exports.

Assign a single point of contact to manage auditor communications
Respond to evidence requests within 48 hours to keep the engagement on schedule
Use zGovern's auditor workspace to share evidence directly with the audit team

Review Draft Report and Address Exceptions

Before the final report is issued, you receive a draft. Review every finding carefully. For each exception, you have the opportunity to provide management's response — either accepting the finding, explaining compensating controls, or noting remediation that has already occurred. This is also the time to verify that the system description accurately reflects your environment.

Report Issuance and Distribution

The final SOC 2 report is issued. You can now share it with customers and prospects — typically under NDA or via a secure link. Update your Trust Center and any security questionnaire responses that reference your SOC 2 status. Begin planning the next audit cycle immediately.

Most Common SOC 2 Audit Findings

Across hundreds of SOC 2 engagements, the same categories of findings appear repeatedly. None of them are surprising — they are predictable gaps that readiness assessments are designed to catch. zGovern's automated monitoring flags most of these before an auditor ever sees them.

Finding Category	Typical Issue	Frequency
MFA enforcement	Some user accounts (often service accounts or contractors) lack MFA on production systems or admin consoles	Very High
Access reviews	Periodic access reviews not conducted, not documented, or not conducted at the frequency stated in policy	Very High
Policy documentation	Policies exist but have not been approved, distributed, or acknowledged by employees within the audit period	High
Vendor risk assessments	Critical vendors lack formal security assessments or assessments are more than 12 months old	High
Change management	Code deployments to production lack documented approvals; change records are missing or incomplete	Moderate
Incident response	No documented incident response plan, or incidents not formally logged and tracked through resolution	Moderate
Security training	Security awareness training completion records are incomplete; new employees not trained within required timeframe	Moderate
Encryption gaps	Non-production data stores, logging buckets, or backup systems lack encryption at rest	Moderate
Background checks	Background checks not conducted for all employees with access to production data; records not retained	Moderate
Offboarding	Terminated employees' access not revoked within the timeframe specified in policy; offboarding checklist not documented	Moderate

How zGovern Automates Evidence Collection

The most time-consuming part of any SOC 2 audit — for both the company and the auditor — is evidence collection. In a manual process, a compliance manager spends weeks taking screenshots, exporting logs, requesting records from HR, chasing down policy signatures, and assembling it all into a folder structure that the auditor can navigate. This process is repeated for every audit cycle.

zGovern replaces this manual workflow with continuous, automated evidence collection:

Infrastructure monitoring checks: Every 6 hours, zGovern runs automated checks against your AWS, GCP, Azure, GitHub, Okta, and other integrated systems. Check results — pass or fail — are recorded with timestamps, creating a continuous log of your security configuration state throughout the observation period.
Access review records: Access reviews completed within zGovern are recorded with reviewer identity, review date, and APPROVE/REVOKE decisions per user — precisely the evidence auditors need to verify the access review control is operating.
Policy acknowledgements: When employees acknowledge policies through zGovern, acknowledgement timestamps and employee identifiers are stored — providing the distribution and sign-off evidence that auditors require.
Incident records: Every incident logged in zGovern creates a timestamped record including severity, detection time, resolution time, and response actions — meeting the evidence requirements for the incident response control.
Vendor assessments: Vendor questionnaires and their responses are stored in zGovern with assessment dates, providing the vendor risk management evidence auditors look for.
One-click audit bundle: When the auditor sends their PBC list, you export a structured ZIP from zGovern containing a controls summary, risk register, evidence checklist, and policy library — in seconds, not days.

Conclusion

The SOC 2 audit process is entirely predictable, which means it is entirely preparable. Teams that invest in a thorough readiness assessment, remediate gaps before the formal engagement begins, and maintain continuous evidence collection throughout the observation period routinely complete their first Type II audit with few or no exceptions — and finish subsequent annual audits in a fraction of the time.

The difference between a chaotic audit preparation and a smooth one is not how many people work on it — it is whether the evidence collection process is automated or manual. When zGovern is continuously monitoring your infrastructure and logging evidence in the background, your team spends audit time answering auditor questions, not hunting for screenshots.