SOC 2 Type II Audit Preparation for Cloud Companies: 90-Day Checklist 2026

SOC 2 Type II Is an Operating Effectiveness Test, Not a Design Assessment

Before preparing for a SOC 2 Type II audit, you need to understand exactly what the auditor is assessing. Most cloud companies go through months of documentation work only to discover that the auditor does not care about your policy PDFs. They care about evidence that controls actually ran, consistently, over the entire observation period.

SOC 2 is a framework created by the American Institute of CPAs (AICPA). It assesses service organizations, companies that hold or process data on behalf of customers, against the Trust Services Criteria. The framework has two report types with fundamentally different scopes.

---

SOC 2 Type I vs Type II

The practical implication: Type I is a design blueprint review. Type II is a building inspection after a year of operation. Customers with enterprise procurement processes almost universally require Type II. Type I is acceptable as a bridge while you accumulate the observation period, but it will not satisfy Fortune 500 security questionnaires. When to pursue each: Get Type I if you are pre-series-A, need to close a specific deal quickly, and have not yet run a full control cycle. Get Type II if you are selling to enterprises, handling regulated data (healthcare, financial services, government), or renewing an existing SOC 2 relationship with a customer.

---

The 5 Trust Services Criteria

SOC 2 audits are structured around five Trust Services Criteria (TSC). Security (CC1-CC9) is mandatory for every SOC 2 audit. The remaining four are in scope only if you include them in your audit scope, which most cloud companies do for Availability and Confidentiality.

What "operating effectiveness" actually means

Operating effectiveness is the auditor's term for: did the control run every time it was supposed to, over the entire observation period, without exception?

A control that was designed correctly but executed only 80 percent of the time is an exception finding. A single month where quarterly access reviews were not performed is an exception finding. An incident response test that was planned but cancelled is an exception finding.

The evidence auditors collect to assess operating effectiveness includes:

• Log exports covering the full observation period: Not a screenshot from today. An export from the start date to the end date of the audit window.
• Dated access review records: Spreadsheets or tool exports showing who approved what, and when, for every review cycle during the period.
• Change management tickets: Every production change with evidence of testing, approval, and rollback plan, for the entire year.
• Incident records: All P1/P2 incidents during the period with timestamps showing detection, containment, and resolution times.
• Penetration test report: Dated within the observation period, with remediation evidence for all critical and high findings.

If your control ran 11 out of 12 months, you have an exception. Build systems that make compliance automatic and continuous, not periodic and manual.

---

The 90-Day Preparation Timeline

Ninety days is the minimum viable preparation window for a cloud company that has never completed a SOC 2 Type II audit. Organizations with partial controls in place can compress some phases. Organizations starting from zero need every week.

Week 1-2 in detail: The gap analysis is the most critical output of the readiness phase. Map every control in the AICPA's Trust Services Criteria to your current state: designed and operating, designed but not operating, not designed. Controls in the third category are the ones that will generate exceptions if the audit observation period has already started. Begin the observation period only after you are confident that controls in scope are actually running. Week 3-6 in detail: Control narratives are often underestimated. An auditor does not read your policy and assume the technical control exists. They need a narrative that says: "Our access control policy requires that all privileged access is governed by Entra ID PIM with just-in-time activation. The technical implementation is PIM configured in our tenant ID xxxxxxxxx, with activation requiring manager approval and a business justification. Evidence of all PIM activations is captured in the Entra ID audit log and exported monthly to our compliance evidence repository." Write a narrative like this for every single control.

---

Azure-Specific Evidence Collection

Azure-native controls generate rich evidence logs. The challenge is knowing exactly which export to pull and ensuring retention covers the full observation period. Entra ID sign-in logs (90-day export): Navigate to Entra ID, then Monitoring, then Sign-in logs. Export to CSV or route to a Log Analytics workspace. The portal UI only shows 30 days. For a full 12-month export, you need either Log Analytics with a workspace retention policy of at least 12 months, or a Microsoft Entra ID P1/P2 license with log archival to a storage account. Command: az monitor log-analytics query --workspace --analytics-query "SigninLogs | where TimeGenerated > ago(365d)" --output json Azure Policy compliance dashboard export: In the Azure Portal, go to Policy, then Compliance. Select your compliance initiative (e.g., CIS Azure Foundations Benchmark or your custom initiative). Click Export and download as JSON or CSV. This produces a point-in-time compliance report. For historical compliance evidence, you need Azure Policy compliance state change history, which is available via the REST API or Azure Resource Graph: az graph query -q "policyStates | where timestamp > ago(365d) | summarize count() by complianceState, policyDefinitionName" Defender for Cloud Secure Score history: The Secure Score does not show historical trends in the portal by default. Export Secure Score data to a Log Analytics workspace using the continuous export feature under Defender for Cloud settings. Once configured, query: SecureScoreControlsSnapshot | where TimeGenerated > ago(365d) | project TimeGenerated, ControlName, HealthyResourceCount, UnhealthyResourceCount Key Vault audit logs for all secret and key access: Enable diagnostic settings on every Key Vault in scope to route AuditEvent logs to Log Analytics. Query: AzureDiagnostics | where ResourceType == "VAULTS" and OperationName in ("SecretGet", "KeySign", "SecretSet") | project TimeGenerated, CallerIPAddress, identity_claim_oid_g, OperationName, ResultType Azure Monitor alert history: Export all alert rule firings for the observation period from Azure Monitor. In the portal, go to Monitor, then Alerts, then Alert rules. Use the Azure Monitor REST API to pull historical alert instances: az monitor metrics alert list --resource-group combined with the alert history endpoint. PIM activation history: In Entra ID, navigate to Privileged Identity Management, then My audit history, or use the audit log query: AuditLogs | where Category == "RoleManagement" and ActivityDisplayName contains "eligible" | project TimeGenerated, InitiatedBy, TargetResources, Result

---

The 7 Most Common Gaps Auditors Find

These are not hypothetical. These are the findings that appear in most first-time SOC 2 Type II reports for cloud companies. 1. User access reviews not performed quarterly. Most companies document a quarterly access review policy but perform the review annually or only when prompted by the auditor. Auditors count the number of reviews performed during the observation period and compare it to the documented frequency. If your policy says quarterly and you have two reviews over 12 months, that is two exceptions. 2. Terminated employee accounts not disabled within 24 hours. The control typically states that terminated accounts will be disabled within one business day. Auditors pull HR termination records and cross-reference them with Entra ID account disable timestamps. A single account that took 48 hours or three days to disable is an exception finding. Automate offboarding with Entra ID lifecycle workflows or an ITSM integration. 3. MFA not enforced for all privileged accounts. Conditional Access policies that require MFA often have exceptions: break-glass accounts, service accounts, legacy authentication protocols. Auditors check the policy configuration and the sign-in logs for privileged accounts. Any sign-in from a privileged account without MFA satisfied is an exception. 4. Penetration test results older than 12 months. The SOC 2 observation period is typically 12 months. If your last pen test was 14 months ago when the audit fieldwork begins, the observation period has no penetration test. Many cloud companies treat pen testing as an annual event scheduled at a fixed date and miss the window when the audit observation period shifts. 5. Change management records lacking evidence of testing. Change management controls require that production changes are tested before deployment. Auditors request a sample of change tickets from the observation period and look for testing evidence, approval records, and rollback plans in each ticket. Changes deployed without a completed ticket, or tickets with missing approval fields, are exceptions. Every production deployment needs a traceable change record. 6. Incident response plan not tested in the observation period. Most companies have an incident response plan document. Fewer have evidence of a tabletop exercise or live test conducted during the 12-month observation period. Auditors ask for the test report, attendee list, and any action items from the most recent IR test. If no test occurred during the period, this is a gap. 7. Vendor risk assessments missing for critical subprocessors. SOC 2 requires that you assess the security posture of vendors who process or store your customer data (subprocessors). This means collecting SOC 2 reports, security questionnaires, or equivalent evidence from AWS, Stripe, Sendgrid, Salesforce, and any other critical vendor. Auditors ask for your subprocessor inventory and the most recent risk assessment for each. Missing assessments for even one critical vendor generates a finding.

---

Automated Evidence Collection Tools

Three categories of tooling exist for SOC 2 evidence collection. Choosing correctly depends on your budget, engineering capacity, and time to audit. Purpose-built compliance platforms (Vanta, Drata, Secureframe): These tools connect directly to your cloud accounts, identity providers, code repositories, and HR systems via API. They continuously collect evidence, flag control failures in real time, and generate auditor-ready evidence packages. Cost ranges from $20,000 to $50,000 per year depending on company size and in-scope systems. The return on investment is clear if your engineering team's time costs more than the tool or if you are running multiple compliance frameworks simultaneously (SOC 2 plus ISO 27001 plus HIPAA). Auditors who regularly see Vanta or Drata-generated evidence packages work more efficiently, which can reduce audit hours and total cost. Azure-native tooling (Azure Policy plus Defender for Cloud): For cloud companies running entirely or primarily on Azure, the combination of Azure Policy compliance reports, Defender for Cloud continuous assessment, Entra ID audit logs, and Log Analytics workspace queries covers the majority of Security and Availability criteria evidence at no additional licensing cost beyond Defender for Cloud plans. The limitation is manual effort: someone must know which queries to run, export the results in the right format, and organize the evidence package. For engineering-heavy teams willing to build the tooling, this approach works. For teams without a dedicated compliance engineer, the manual overhead outweighs the cost savings. When automation tools are worth the cost: Pay for Vanta or Drata if you are targeting SOC 2 plus at least one other framework (ISO 27001, HIPAA, PCI DSS), if your audit cycle repeats annually and you want to reduce the evidence collection burden each cycle, or if your sales team is losing deals to competitors who have SOC 2 and you need to close the gap in under six months. The time savings from automated evidence collection typically recover the annual platform cost within the first audit cycle.

---

What a SOC 2 Report Actually Contains

The final SOC 2 Type II report has four sections. Understanding the structure helps you review the draft report and negotiate language before it is finalized. Section 1: Management's Description of the System. This is your description of your service, the infrastructure it runs on, the data it processes, and the boundaries of the audit scope. You write this section with help from the auditor. It describes what your system does, who uses it, what data it handles, and which Trust Services Criteria are in scope. Section 2: Management's Assertion. A one-page signed statement from your leadership confirming that the description in Section 1 is accurate and that controls were suitably designed and operating effectively during the observation period. Your legal team reviews this. Section 3: Independent Service Auditor's Report. The auditor's opinion. There are three possible opinions: unqualified (clean, all controls operated effectively), qualified (one or more controls had exceptions but the overall system is acceptable), and adverse (significant failures, rarely issued for a reputable company because auditors work with clients to remediate before issuing an adverse opinion). Most companies receive a clean opinion with zero to three minor exceptions. Section 4: Description of Tests of Controls and Results. The control matrix. Every control in scope is listed with: the control objective, the control activity, the tests the auditor performed, and the results of those tests. This is the section your customers actually read. Exceptions appear here with the nature of the deviation and the auditor's assessment of impact.

---

Frequently Asked Questions

How long does SOC 2 Type II certification take?

From the start of the observation period to receiving the final report takes 12 to 18 months for most cloud companies. The observation period itself is a minimum of 6 months (some auditors accept 6 months for a first-time audit) but typically 12 months. Add 60 to 90 days for the preparation phase before the observation period begins and 60 days for auditor fieldwork and report drafting after the observation period ends. Companies that start from scratch with no controls in place should plan for 18 months total. Companies with mature security programs can often complete the cycle in 12 to 14 months.

Is SOC 2 certification required by law?

SOC 2 is not required by any law or regulation in the United States. It is a voluntary framework created by the AICPA. However, it is contractually required by many enterprise customers as a condition of doing business. Healthcare customers often require both SOC 2 and HIPAA compliance. Financial services customers may require SOC 2 alongside SOC 1 (financial controls) or PCI DSS. Government customers may require FedRAMP instead of or in addition to SOC 2. The practical reality is that for B2B SaaS companies selling to mid-market and enterprise customers, SOC 2 Type II is a de facto requirement.

What is the difference between SOC 2 and ISO 27001?

SOC 2 is an American framework governed by the AICPA and assessed by licensed CPA firms. ISO 27001 is an international standard governed by the International Organization for Standardization and assessed by accredited certification bodies. SOC 2 produces a report (not a certification) that describes your controls and the auditor's findings. ISO 27001 produces a certificate. ISO 27001 is more widely recognized outside North America, particularly in Europe and Asia. SOC 2 is dominant in North American B2B SaaS. The control overlap between the two frameworks is approximately 60 to 70 percent, which is why many companies pursue both simultaneously using automation platforms that map controls to multiple frameworks.

How much does a SOC 2 Type II audit cost?

Total cost has three components. Auditor fees range from $30,000 to $75,000 for a standard cloud company audit from a reputable regional firm. The Big Four (Deloitte, PwC, KPMG, EY) charge $75,000 to $150,000 or more. Internal preparation costs (staff time for documentation, evidence collection, and control implementation) add $50,000 to $150,000 in effective labor cost for a first-time audit. Compliance platform costs (Vanta, Drata, Secureframe) add $20,000 to $50,000 per year if you choose that route. Penetration testing adds $15,000 to $40,000 depending on scope. A realistic all-in budget for a first SOC 2 Type II audit is $100,000 to $250,000. Subsequent annual renewals cost less because the observation period preparation is shorter and controls are already running.

Can a startup get SOC 2 certified?

Yes. There is no revenue threshold, employee count requirement, or minimum infrastructure scale required to pursue SOC 2. Many seed and series-A startups pursue SOC 2 Type I or Type II to unlock enterprise sales. The practical constraints are cost (see above), engineering capacity (controls require implementation and maintenance), and leadership time (the management assertion and system description require executive involvement). For startups with fewer than 20 employees, the most efficient path is to use a compliance platform like Vanta to minimize manual evidence collection overhead, pursue Type I first to close deals in the near term, and convert to Type II once the observation period accumulates. The SOC 2 framework scales to companies of any size.