How to Get SOC 2 Certified

What SOC 2 actually is

Enterprise deals stall on the SOC 2 question more often than most SaaS founders expect. Not because they do not have one, but because they have a Type I, and the enterprise buyer wants a Type II. Or because they have a Type II with a scope that excludes the product environment the prospect cares about. Or because the report covers Security only and the buyer’s security questionnaire asks about Availability. Understanding SOC 2 before you are in a deal conversation prevents the last-minute scramble to explain to a prospect why your twelve-month-old report does not cover what they are asking about.

SOC 2 (System and Organization Controls 2) is an attestation report issued by a CPA firm after examining your organization’s controls against defined criteria. It is not a certification (no certificate is awarded, no ongoing license is required) and it is not a pass/fail judgment. The auditor examines your controls, tests them, and issues an opinion: either unqualified (controls are suitably designed or operating effectively) or qualified if exceptions were found.

The purpose of SOC 2 is customer assurance. When a prospect asks for your SOC 2 report during a vendor security assessment, they are asking for independently verified evidence that your organization takes data protection seriously. For SaaS companies and cloud service providers, SOC 2 has become the de facto compliance standard — it is the credential most enterprise buyers expect before approving a vendor.

Type I vs Type II — and why the difference matters

The foundational decision when pursuing SOC 2 is Type I or Type II. These answer different questions and take different amounts of time.

Type I validates that your controls are designed correctly but tells the customer nothing about whether you actually run them day-to-day. Type II demonstrates sustained operational discipline — the auditor samples evidence from across the entire observation period and concludes that controls did what they were supposed to.

Most organizations pursuing SOC 2 for the first time start with a roadmap that looks like: establish controls, get a Type I report early (to share with prospects while the observation period runs), then move to Type II within 6 to 12 months.

Selecting which trust service criteria to include

Security is mandatory in every SOC 2 report. The other four criteria are optional and selected based on customer requirements and what your service actually does.

Security (Common Criteria) — mandatory. Covers governance, risk assessment, access controls, monitoring, incident response, change management, and vendor management.

Availability — most SaaS companies include this. Evaluates whether your service is available and reliable as you have promised (backup, disaster recovery, uptime monitoring).

Processing Integrity — include if data accuracy is central to your service (financial calculations, analytics engines, payment processing). Skip if your core service is not data processing.

Confidentiality — include if you handle regulated data (healthcare, financial, trade secrets) or if confidentiality is a major selling point.

Privacy — include if you process personal information as a primary function (employee data for HR tech, customer PII for consumer services). Skip if you only collect standard business contact information.

The practical answer for most companies: include Security and Availability, then add Confidentiality or Privacy based on customer requirements and business context. The more criteria you include, the more controls you must implement and the higher the audit cost.

Phase 1: Scoping and readiness assessment

Scoping defines what the auditor will examine: which systems, which business processes, which trust service criteria. Scoping matters because it determines the evidence workload and the audit cost. Too narrow and you exclude critical systems that customers will ask about. Too broad and you inflate cost without proportional benefit.

Define the system boundaries. What systems process, store, or transmit customer data? For a typical SaaS company: production infrastructure, CI/CD pipelines, identity providers, monitoring systems, corporate IT systems (email, file storage), and the HR systems that manage access provisioning and offboarding.

Document the in-scope services and data types. What does the service do? What customer data does it handle? What regulatory or contractual constraints apply?

Identify subservice organizations. Does AWS, Azure, or Google Cloud process data on your behalf? Does a payment processor, data warehouse, or email provider play a role? The auditor will need to address these through either the inclusive method (examining the subservice organization’s controls within scope) or the carve-out method (documenting that you have verified the subservice organization’s SOC 2 report independently).

Conduct a readiness assessment. A readiness assessment (optional but strongly recommended for first-time audits) evaluates current controls against the SOC 2 criteria you have selected. The assessment identifies gaps that can be remediated before the observation period starts. Gaps found during the audit itself become exceptions in your report — expensive ones, because exceptions undermine the whole purpose of having a clean report. A readiness assessment costs $5,000 to $15,000 and prevents far more expensive rework later.

Phase 2: Remediation and control implementation

Based on the readiness assessment, prioritize gaps by impact and effort. The common gaps are access controls (access reviews not running, onboarding/offboarding not automated), change management (changes deployed without approval, no separation of duties), monitoring (no centralized logging, alerts not being investigated), and risk assessment (no formal process, no risk register).

Implement or formalize access controls. Multi-factor authentication on all production systems and cloud consoles. Quarterly access reviews with documented evidence of approval and remediation. Automated onboarding (access provisioned by role on hire date) and immediate offboarding (access revoked within 24 hours of termination, verified through HR system integration).

Formalize change management. All changes to production require approval before deployment. Code changes require peer review (enforced through branch protection rules). Infrastructure changes go through the same process as application changes (infrastructure-as-code with pull request review). Emergency changes have post-change review requirements. Every change is documented with who requested, who approved, what changed, and when it was deployed.

Implement centralized monitoring and logging. All security-relevant events (authentication attempts, privilege escalation, configuration changes, incidents) are logged to a central system. Logs are retained for at least the length of your observation period plus 90 days. Alerts are configured for high-priority events and investigated within defined SLAs.

Conduct a formal security risk assessment. Document your methodology, identify risks to customer data, score them consistently, and create a risk register with treatment plans. Link the risk register to your selected SOC 2 controls — the controls in your SOC 2 compliance checklist should exist because you identified risks that require mitigation.

Build supporting policies. Information Security Policy (overarching), Acceptable Use, Access Control, Change Management, Incident Response, Data Classification, Vendor Management, Business Continuity, Risk Assessment, and Encryption policies. If you do not have these, draft them. If you have them, review them against the readiness assessment findings and update them to match your actual processes.

Phase 3: Observation period and evidence collection

For Type II, the observation period is when the auditor will test whether your controls actually work. The observation period is typically 6 to 12 months for a first report. During this period, every control must operate as documented. This is not theoretical — if your policy says you conduct quarterly access reviews, you must actually conduct them quarterly, with documented evidence that the review happened and that any findings were remediated.

Common failure point: Organizations document a control (e.g., “access is reviewed quarterly”) but do not operationalize it before the observation period begins. Then they miss a review during the period because they were heads-down on a product launch. One missed quarterly review during the observation period is one exception in your auditor report. The remediation should have happened before the period started.

Operator note: The controls most often found to have lapsed during a Type II observation period are not the technically complex ones. They are the procedural ones with no system enforcement — quarterly access reviews, vendor security assessments, and security awareness training completion. These fail because they are calendar-driven, not workflow-driven. The fix is not reminder emails. It is attaching the control to an existing recurring process with an owner who cannot mark it complete without submitting documentation. If the access review is not tied to a ticket that must be closed, it will not happen consistently over twelve months.

Set up operational discipline. Calendar reminders with specific owners for every recurring control. For access reviews: assign a data owner, a deadline (first Friday of Q1/Q2/Q3/Q4), and automatic escalation if not completed. For change management: enforce branch protection rules at the CI/CD layer — no manual override. For monitoring: route alerts to a ticketing system and establish investigation SLAs.

Collect evidence continuously. Do not wait until the auditor asks for evidence to start collecting it. A GRC platform automates this by continuously pulling evidence from your identity provider (access reviews, MFA status), cloud providers (configurations, logs), ticketing systems (incidents, changes), and HR systems (onboarding/offboarding dates). Without automation, teams often scramble to reconstruct evidence at the end of the observation period, producing incomplete records that the auditor flags as exceptions.

Phase 4: Selecting an auditor and formal engagement

Not all CPA firms are equal in SOC 2 experience. Factors that matter:

Operator note: The auditor selection decision that organizations most consistently underestimate is the difference between a firm that issues 50 SOC 2 reports per year and one that issues 500. The smaller firm is often less expensive and the engagement manager is highly attentive. The problem shows up when the fieldwork begins and the auditor spends three weeks asking for evidence that an experienced firm would know how to locate in three hours. The time burden shifts to your internal team. Choose on volume and architecture familiarity, not price.

SOC 2 volume. Firms that issue hundreds of SOC 2 reports per year have refined processes and encounter fewer surprises. Boutique CPA firms that issue a handful of SOC 2 reports per year are often less efficient and may miss nuances in your specific architecture.

Industry experience. An auditor familiar with SaaS cloud infrastructure will be more efficient than one whose practice is primarily financial services SOX audits. When interviewing auditors, ask about their experience with companies similar to yours in size and architecture.

Report credibility. Big Four firms (Deloitte, PwC, EY, KPMG) carry the most prestige with enterprise customers, but cost more. Mid-tier firms (like CliftonLarsonAllen, CohnReznick) offer strong credentials at lower cost. Smaller local CPA firms may not have the SOC 2 experience or the reputation that sophisticated customers expect.

Communication and responsiveness. The auditor will work with your team throughout the observation period and during fieldwork. Responsiveness, clear communication, and willingness to explain findings matter for the quality of the final report and the internal experience.

Engagement structure. If you conducted a readiness assessment with an external advisor or the CPA firm itself, confirm that separate teams handle readiness and audit (independence is important for audit quality and customer credibility). Some firms offer a combined readiness + audit engagement; others keep them separate.

The auditor engagement typically follows this sequence:

1. Readiness assessment (if not already done): 2–4 weeks
2. Gap remediation: 4–12 weeks depending on your starting maturity
3. Type I audit (optional, or concurrent with Type II): 4–8 weeks
4. Type II observation period: 3–12 months (6 months typical for first reports)
5. Type II audit fieldwork: 4–8 weeks after the observation period closes
6. Report issuance: 2–4 weeks after fieldwork completes

Phase 5: The observation period in motion

Once the observation period officially begins, every day of it counts as audit evidence. The auditor will later sample from this period to verify that controls operated as designed.

During the observation period: Do not pause to catch up on controls you have neglected. Do not implement significant policy changes that will disrupt the running controls. The goal is to demonstrate 6 to 12 continuous months of operational discipline, not perfection. Small exceptions (one access review completed one week late with documented justification) are survivable. Large exceptions (entire quarter of access reviews skipped) are not.

After the observation period ends: The auditor begins fieldwork. They sample evidence from throughout the period, interview team members about how controls operate, observe live systems, and test that controls worked as described. Fieldwork typically takes 3 to 6 weeks depending on scope and complexity.

Common findings during fieldwork: The most frequent exception is access control gaps (access reviews missed, offboarding delayed, unnecessary admin access not cleaned up). Second is change management (changes deployed without documented approval, emergency changes without post-change review). Third is monitoring (alerts not investigated, incidents not documented). These are preventable by implementing the operational discipline described in Phase 2.

Phase 6: Report review and issuance

The auditor will share a draft report and request your review before final issuance. Review it carefully:

• Do the control descriptions match how controls actually operate? If the report describes a control incorrectly, ask the auditor for a corrected description in the final report.
• Are there any exceptions noted? Understand why they occurred and whether they reflect true gaps or procedural misunderstandings. You cannot change the auditor’s findings, but you can provide context.
• Are the management assertions (signed statements that controls operate as described) accurate?

Once the final report is issued, it is yours to share with customers and prospects. A clean Type II report is your credential that controls are designed correctly and operating effectively.

Timeline expectations by company size and maturity

Mature companies (existing policies, access controls, centralized logging, risk assessment on file)

• Type I: 8–12 weeks total
• Type II: 6–10 months total (fast observation period, minimal rework)

Growth-stage companies (some policies and controls, moderate gaps)

• Type I: 12–16 weeks total
• Type II: 10–14 months total (longer observation period, significant control tightening)

Early-stage or startup (limited formal controls, building from scratch)

• Type I: 14–18 weeks total
• Type II: 14–18 months total (extended observation period to demonstrate new controls are sustained)

The timeline is not just about the audit itself — it is about establishing and running controls long enough to have evidence that they work.

Common failure points and how to avoid them

Scoping too narrow. Include the systems that process customer data, even if it means higher cost. An auditor report that omits critical systems raises questions from sophisticated customers.

Skipping readiness assessment. The most expensive mistakes are deficiencies found during the audit rather than before. A readiness assessment identifies and allows you to fix gaps before the observation period starts.

Starting the observation period before controls are operational. This is the number one source of exceptions. Implement controls completely, run them for 2–4 weeks, catch and fix any operational issues, then notify the auditor that the observation period should begin.

Treating monitoring alerts as optional. The auditor will ask for evidence that your security alerts were investigated. If alerts exist but nobody was looking at them, you have a control failure. Assign ownership, define SLAs, and route to a ticketing system.

Not tracking access offboarding. Terminated employees with lingering access is an automatic exception. Integrate your HR system with your identity provider so access is revoked on termination date, then verify monthly that no access remains.

Letting policy fall out of sync with practice. The auditor will test whether your actual processes match your documented policies. If your policy says quarterly access reviews but you are doing them monthly, update the policy. If you are doing them quarterly, make sure you actually do them every quarter.

After you get your report

SOC 2 reports do not automatically renew. A Type II report typically covers a 12-month observation period. To maintain continuous coverage (which enterprise customers and investors expect), start the next audit cycle before the current report expires — the new observation period begins immediately after the previous one ends. Most companies operate on an annual audit cycle with 12-month overlaps in observation periods.

Maintaining compliance year-over-year requires continuous operational discipline: quarterly access reviews, change management on every deployment, centralized monitoring that catches anomalies, and a risk register that gets reviewed and updated as your business and threat landscape evolve. Organizations that embed these practices into daily workflows (code review before merge, MFA on every login, access provisioned through HR integration) sustain compliance with less friction than those that treat SOC 2 as a periodic compliance project.

For organizations pursuing both SOC 2 and ISO 27001, the two frameworks share approximately 70 to 80 percent of control overlap. Both require formal risk assessment, documented policies, access controls, change management, monitoring, and vendor management. A unified approach to control implementation and evidence collection reduces the incremental effort of pursuing both.

Nick’s book, Cyber War…and Peace, covers the operational frameworks — including audit readiness, management-system discipline, and board-level governance — that keep compliance sustainable across years, not just across one audit cycle.