SOC 2 compliance: a technical readiness guide

SOC 2 is an attestation report produced by an independent CPA firm that describes how your company protects customer data against a defined set of criteria. It is not a certification, and it is not a license. It is an auditor's opinion on whether your controls were suitably designed and, for a Type II report, whether they operated effectively over a period of time. For a technical leader, the practical meaning is simpler. SOC 2 readiness is the work of building, documenting, and proving that your security controls actually run the way you claim they do. This guide explains what the report covers, how the audit works step by step, what you receive at the end, and where teams waste months before they get there.

We wrote this for engineering leaders and executives at regulated mid-market and enterprise companies who are being asked for a SOC 2 report by a customer, a prospect, or a board. The fastest way to fail SOC 2 is to treat it as a paperwork exercise that the security team handles in isolation. The fastest way to pass it cleanly is to fix the underlying controls first, then document what you already do. We help clients do the second version through our governance, risk, and compliance work, and most of what follows reflects how we scope and run those engagements.

What SOC 2 actually is, and what it is not

SOC 2 is built on the Trust Services Criteria published by the AICPA. There are five criteria, and Security is the only one that is mandatory. The other four are optional, and you include them based on what your customers care about and what your product does. The report itself is a document an auditor writes after examining your environment. It is meant to be shared under NDA with your customers and their auditors, not posted publicly. People often confuse SOC 2 with ISO 27001, which is a certification against a management system standard. The two overlap heavily in controls but differ in form, audience, and renewal cadence. We cover that distinction in detail in our SOC 2 vs ISO 27001 comparison.

• The Security criterion, also called the Common Criteria, is required in every SOC 2 report and covers access control, change management, risk assessment, monitoring, and incident response.
• Availability covers whether your systems meet agreed uptime and performance commitments, and it matters most for infrastructure and platform companies with service level agreements.
• Processing Integrity covers whether systems process data completely, accurately, and on time, and it matters for payments, billing, and data pipeline products.
• Confidentiality covers how you protect information designated as confidential, including encryption, retention limits, and disposal, and it overlaps with contractual data handling promises.
• Privacy covers how you collect, use, retain, and dispose of personal information in line with your stated privacy notice, and it is the least commonly included criterion.
• A SOC 2 report is an attestation, not a pass or fail badge, so the value lives in the auditor's narrative and the list of exceptions, not in the existence of the document alone.

Type I versus Type II, and why the difference matters

SOC 2 comes in two report types, and confusing them costs deals. A Type I report describes your controls as designed at a single point in time. The auditor looks at your environment on one date and gives an opinion on whether the controls are suitably designed to meet the criteria. A Type II report goes further. The auditor tests whether those controls operated effectively across a review period, usually three to twelve months. Type II is the report most enterprise buyers actually want, because design without operation proves nothing. A control that exists on paper but never ran is worse than no control, because it creates false confidence.

Many companies start with a Type I to show momentum, then move to a Type II covering the following period. That sequence is reasonable when you need something in hand quickly. It is wasteful when you already operate mature controls, because you pay for two audits to get to the report you needed anyway. We usually advise teams with reasonable engineering hygiene to skip straight to a short Type II window. The right answer depends on your sales pressure and your current control maturity, and that is a scoping conversation worth having before you sign anything.

A control that exists on paper but never runs is worse than no control, because it manufactures confidence you have not earned.

How the audit works, step by step

The audit is the last phase, not the first. Most of the effort happens before an auditor touches your environment. The sequence below is the path we walk clients through, and skipping steps is the single most common reason readiness drags past a year.

• Scope the report by deciding which Trust Services Criteria apply, which systems and services are in scope, and which legal entity the report covers, because scope creep later forces rework of every downstream artifact.
• Run a readiness assessment or gap analysis that maps your current controls against the criteria and produces a concrete list of what is missing, weak, or undocumented.
• Remediate the gaps by building or fixing the actual controls, which means changing how access is granted, how code ships, how logs are kept, and how incidents are handled, not just writing policies about them.
• Select an auditor, a licensed CPA firm, and agree on the review period, the report type, and the timeline, since the auditor cannot also build your controls without impairing independence.
• Operate the controls across the observation window for a Type II report, generating the evidence the auditor will sample, which is why you cannot fake a Type II in a week.
• Sit the audit, during which the auditor requests evidence, interviews control owners, tests samples, and documents any exceptions before issuing the report.
• Receive and review the report, address any exceptions in your management response, and plan the next year's renewal because SOC 2 is an annual cycle, not a one-time event.

The controls that carry the most weight

Auditors spend most of their time on a predictable set of control areas. If these are strong, the rest of the audit goes quickly. If they are weak, the auditor finds problems everywhere downstream. Identity and access control is the largest single area. The auditor wants to see that access is granted on a least privilege basis, reviewed on a schedule, and revoked promptly when people leave. Stale access from departed employees is one of the most common exceptions we see, and it is entirely preventable. Change management is the second pillar. The auditor wants evidence that code changes are reviewed, tested, and approved before they reach production, with a clear separation between who writes code and who deploys it.

Monitoring and incident response form the third pillar, and this is where many teams have the widest gap between what they claim and what they do. Claiming you monitor for threats means little if no one reviews the alerts. We see this pattern often, and it is the reason we wrote why SOC 2 is not the same as security. A clean report describes controls that exist; it does not prove an attacker cannot get in. That gap is exactly what services like managed detection and response and offensive security testing are built to close. The audit confirms your process; a penetration test confirms your defenses.

What you actually receive at the end

The deliverable is the SOC 2 report itself, a document that usually runs forty to a hundred pages. Understanding its structure helps you read your own report critically and answer customer questions about it. The report is not a single verdict. It is a structured set of sections, and the parts buyers scrutinize most are the auditor's opinion and the list of exceptions.

• Section one is the auditor's opinion, a short statement of whether the controls were suitably designed and, for Type II, operated effectively, expressed as unqualified, qualified, adverse, or a disclaimer.
• Section two is management's assertion, where your leadership formally states that the description is accurate and the controls met the criteria, which is why executives have real accountability here.
• Section three is the system description, a detailed narrative of your infrastructure, software, people, processes, and data flows that the controls protect.
• Section four is the controls and test results, the longest part, listing each control, the auditor's test procedure, and the result including any exceptions noted.
• An unqualified opinion with no or few minor exceptions is the outcome you want, while a qualified opinion signals that one or more controls failed and prospects will ask about it.
• Complementary user entity controls appear near the end and list the things your customers must do on their side for your controls to work, which matters if you are the one reading a vendor's report.

SOC 2 versus the other reports and frameworks

SOC 2 sits in a family of reports, and choosing the wrong one wastes money. SOC 1 covers controls relevant to financial reporting, so it matters for payroll processors and companies that touch their customers' financial statements. SOC 2 covers security and operational controls, which is what most software and infrastructure buyers want. We break this down in our SOC 1 vs SOC 2 guide. SOC 3 is a stripped down, public facing version of SOC 2 you can post on a website, but it carries little weight in a serious vendor review.

Against international frameworks, the choice is often regional. North American buyers tend to ask for SOC 2. European buyers more often ask for ISO 27001, which maps to 93 Annex A controls across four themes in the 2022 revision. If you sell into regulated EU sectors, you may also face NIS2 or, in financial services, DORA, which has been in force since January 2025. Those are legal obligations rather than voluntary attestations, and a SOC 2 report can supply useful evidence toward them without satisfying them on its own. If both audiences matter to you, build one control set that serves several frameworks rather than running parallel programs.

How long it takes and what it costs

Honest timelines depend on your starting point. A company with mature engineering practices, single sign on, code review, infrastructure as code, and centralized logging, can reach a Type I in roughly two to three months and complete a Type II observation window in another three to six. A company starting from scratch, with shared admin accounts and ad hoc deployments, should plan for six to twelve months before the auditor arrives. The audit fee paid to the CPA firm is only one line in the budget, and it is usually not the largest one.

• The auditor's fee is a fixed external cost, and it scales with scope, the number of Trust Services Criteria, and the report type rather than with your headcount.
• Compliance automation tooling reduces evidence collection effort and recurs annually, and it pays off only if you actually remediate the gaps it surfaces rather than admiring the dashboard.
• Internal engineering time is the real cost, because remediating access control, change management, and logging pulls senior people away from product work for weeks.
• Readiness and remediation support from a firm like ours front loads the work so the audit itself is uneventful, which is usually cheaper than failing an audit and re running it.
• Renewal is annual, so the program is an ongoing operating cost rather than a one time capital expense, and budgeting it as recurring prevents an unpleasant surprise in year two.

Common mistakes and red flags

We have seen the same failures repeat across very different companies. The most damaging one is buying automation tooling and assuming the tool is the program. A dashboard that shows green does not mean your controls work; it means the integrations are connected. Another frequent error is writing policies that describe an aspirational company rather than the real one. Auditors test against what your policies claim, so an ambitious policy you do not follow creates exceptions you would not have had with a modest policy you do follow. Scope is the third trap. Teams include systems and criteria they do not need, which multiplies evidence collection for no commercial benefit.

• Treating SOC 2 as a security guarantee rather than a process attestation, which leaves real attack paths open behind a clean report, a gap covered in pentest versus scan.
• Letting an auditor or their affiliate also build your controls, which raises independence questions and can undermine the report's credibility.
• Writing policies that overstate what you do, since every gap between the policy and the practice becomes a testable exception.
• Leaving access provisioning and deprovisioning manual, which produces stale accounts that are the single most common Type II exception we encounter.
• Starting evidence collection on the last day of the observation window, when the auditor needs samples spread across the entire period to test operating effectiveness.
• Ignoring external attack surface management, so unknown internet facing assets sit outside your documented scope and your monitoring entirely.

SOC 2 readiness is mostly engineering work wearing a compliance label. Fix the controls, document what you do, then let the auditor confirm it. That is the order that produces a clean report without a year of thrash. Our GRC team runs readiness assessments, closes the gaps, and prepares the evidence so the audit itself is uneventful, and we connect it to the offensive testing and detection work that turns a clean report into actual security. If you are facing a customer deadline or a board request, book a scoping call and we will map your starting point to a realistic timeline.