SOC 2 Type II explained: what it proves, who needs it, and what it really costs

What SOC 2 actually is, and what it is not

SOC 2 is an attestation report produced by a licensed accountant about the controls at a service organisation. The acronym stands for System and Organization Controls, and the "2" marks the report that looks at security and operational controls rather than financial reporting. It is American in origin. It is defined, governed and maintained by the American Institute of Certified Public Accountants (the AICPA), which describes System and Organization Controls as "a suite of service offerings CPAs may provide" and says it "promulgates the professional standards for SOC engagements".¹

The single most important thing to understand, before any of the detail, is this: SOC 2 is not a certificate. There is no badge, no pass or fail stamp, no government licence. A SOC 2 report is an independent accountant's opinion, written up in a long document, about whether an organisation's controls were suitably designed and, in the Type II case, whether they actually operated as described over a period of time.¹² The report is a restricted use document, meant for the service organisation, its customers and those customers' own auditors, not for the open web.¹

That distinction matters for honesty, and honesty is the whole point of how I work. I build software to the engineering standard a SOC 2 report describes. I prepare a business so that an audit can succeed. I cannot issue the report, and neither can any other developer. Only a licensed CPA firm that you commission and pay can do that. Anyone who tells you they will "give you SOC 2" is either being loose with language or selling you something that does not exist.

Who issues a SOC 2 report, and why it cannot be me

A SOC 2 examination is performed under the AICPA's attestation standards, set out in Statement on Standards for Attestation Engagements No. 18 (SSAE No. 18). The common requirements live in section 105 of those standards, and the rules for an examination engagement, which is what a SOC 2 is, live in section 205.² Those standards can be applied only by a CPA, and the AICPA states plainly that where auditors are unlicensed it will act against its members and assist regulators.¹

So the roles split cleanly, and I keep them separate on purpose:

The CPA firm is independent. It tests your controls and signs the opinion. It has to be independent of you, which is exactly why it cannot also be the firm that built your systems.
I am the builder and the preparer. I design and write the software so the controls exist, work and leave evidence. I run the gap analysis, help you choose scope, stand up the logging and the access model, and get you to the point where an auditor has something real to test.

If I also claimed to audit the result, the independence that gives a SOC 2 report its value would be gone. Keeping the two apart is not a limitation. It is the reason the report means anything.

The five trust services criteria

A SOC 2 report is written against the Trust Services Criteria, a set of control criteria established by the AICPA's Assurance Services Executive Committee. The current version is the 2017 Trust Services Criteria with revised points of focus from 2022, codified as TSP section 100, and it covers five categories: Security, Availability, Processing Integrity, Confidentiality and Privacy.³

You do not have to report on all five. Security is the only one that is always included, which is why it is known as the common criteria. The other four are chosen according to the promises you make to your customers and the nature of what you run.³

Category	What it covers	When you include it
Security (common criteria)	Protection of systems and data against unauthorised access, always required in every SOC 2 report.	Always.
Availability	Whether the system is available for operation and use as committed, which maps to uptime promises.	When you sell an availability commitment or a service level agreement.
Processing integrity	Whether processing is complete, valid, accurate, timely and authorised.	When you process transactions or calculations on a customer's behalf, such as payments or billing.
Confidentiality	Whether information designated as confidential is protected as committed.	When you hold customer business data under confidentiality terms.
Privacy	Whether personal information is collected, used, retained and disposed of in line with your notice.	When you handle personal data and make privacy commitments about it.

Most software businesses start with Security alone, or with Security plus Availability and Confidentiality. Adding Privacy is a bigger undertaking, and it does not replace your data protection obligations under law, which I come to below.

Type I and Type II, and why buyers want Type II

Every SOC 2 comes in one of two forms, and the difference is the single thing a buyer cares about most.

A Type I report describes whether your controls were suitably designed at one specific point in time. It is a snapshot. It says the right controls were in place on the date the auditor looked.²⁴

A Type II report goes much further. It tests whether those controls actually operated effectively over a period, the observation window, which typically runs from three to twelve months.⁴ The auditor does not just confirm that a control exists. The auditor samples evidence across the whole window to confirm it kept working: that access really was removed when people left, that changes really did go through review every time, that backups really were taken and tested month after month.

This is why serious buyers ask for Type II. A snapshot is easy to stage for a day. A report covering six or twelve months of operation is evidence of a discipline you actually live by. A Type I has its place as a stepping stone, a way to show design is sound while you accumulate the operating history for a Type II, but if an enterprise customer has asked for Type II, a Type I will not satisfy them, and presenting one as though it did damages trust.

Who needs SOC 2, and who is spending money they do not need to

SOC 2 earns its cost in a specific situation: you are a cloud or SaaS business, and you sell, or want to sell, to larger companies or to American customers who ask for it during procurement. In that world a SOC 2 Type II report is often the ticket that gets you through security review at all. Without it, the deal stalls in the buyer's risk team.

Just as important is knowing when you do not need it. A shop selling its own goods to consumers does not need SOC 2. A small business with no enterprise customers and no American buyers does not need SOC 2. If nobody in your sales pipeline is asking for it, buying it is spending real money to answer a question nobody is posing. I would rather tell you that plainly than sell you an audit you cannot use.

There is also a geography point. SOC 2 is the North American expectation. In Europe, the internationally recognised certificate for information security is usually ISO/IEC 27001, the international standard for an information security management system, against which an organisation is certified by an accredited certification body.⁵ Unlike a SOC 2 report, ISO 27001 is a certification with a certificate and a defined three year cycle. If your customers are European, ISO 27001 may be the thing they actually expect, or you may be asked for both. I cover how these fit together in my overview of the quality tiers for business critical software, and a full ISO 27001 piece is coming.

What a SOC 2 report is worth

A SOC 2 Type II report does three concrete things. It unblocks enterprise and American sales that would otherwise stall in procurement. It shortens the security questionnaires you would otherwise answer one painful cell at a time, because much of what a buyer asks is answered by the report itself. And it is genuine evidence of operational discipline, independently tested, which is worth something internally as well as externally.

It is just as important to be clear about what it is not. A SOC 2 report is not a security guarantee. It says your controls were designed suitably and operated as described against the criteria you chose over the period observed. It does not promise you will never be breached. And it is not proof of legal compliance. The General Data Protection Regulation, for example, is a separate legal regime with its own duties, including breach notification under Article 33, and a SOC 2 report does not discharge them.⁶ A good report is strong evidence that you take security seriously. It is not a substitute for the law, and not a shield against every incident.

How the audit works, step by step

The path to a Type II report runs in a fairly fixed order, and most of my work happens before the auditor ever starts.

Readiness assessment. You, usually with a preparer like me, run a gap analysis against the criteria in scope. Every control is marked present, partial or missing, and the missing ones become a work list. This is where the real engineering happens.
Remediation. You build and fix: the access model, the change process, the logging, the backups, the vendor reviews, the written policies. Nothing after this point can rescue a control that does not exist.
Scope and auditor selection. You decide which trust services categories to include, pick your observation window, and commission a licensed CPA firm. You pay the firm directly, and separately from any build cost.
The observation window. For a Type II the clock now runs, typically three to twelve months, during which your controls simply have to keep working while evidence accumulates.⁴
Evidence collection and fieldwork. The auditor requests samples from across the window and tests them, often remotely, against each control.
The report and its opinion. The auditor writes up the description, the controls, the tests and the results, and signs an opinion. An unqualified (clean) opinion means the controls were suitably designed and operated effectively. A qualified opinion flags specific exceptions. An adverse opinion means the controls cannot be relied on. A disclaimer means the auditor could not form an opinion at all.²⁴

The opinion is the part buyers read first. An unqualified Type II is the outcome you are working towards, and it is earned in steps one and two, long before the auditor arrives.

What you have to build first, where I fit

A SOC 2 report describes controls, but controls are not paperwork. They are engineering you can show. For a Ruby on Rails SaaS platform or a Solidus shop, the work is mostly ordinary good practice done properly and made auditable.

Access control and least privilege come first: multi factor authentication on the admin area, the production servers, the deployment pipeline and the cloud console, with role based access so people can reach only what their job needs, and a clean process for removing access the day someone leaves. Change management means every change to production goes through review and leaves a record, which is where a release register and security testing on every release do real work. I wrote separately about evidencing compliance with release registers and security testing per release, and that method is exactly what a Type II auditor samples.

Logging and monitoring have to be centralised, with alerts that a real person receives, because an auditor will ask who saw what and when. Encryption means transport security on every connection and encrypted data at rest and in backups. Vendor management means a documented review of the suppliers your service leans on, their security posture and their incident terms, which connects to the vendor risk due diligence I describe in the data protection context. Incident response means a written procedure, not good intentions. Backups and recovery mean a tested restore, with the time it takes and the data you could lose written down, not just a backup job that has never been read back.

This is the engineering I build from the start, so that preparing for an audit is a matter of collecting evidence rather than rebuilding the system. Every platform I deliver also gets a penetration testing pass with the Kali Linux toolkit before it faces the internet, using tools such as Nmap, Burp Suite and OWASP ZAP, with findings documented by severity and fix. That record is precisely the kind of evidence a readiness assessment wants.

What it really costs, and how long it takes

Costs and timelines vary a great deal with your size and how mature your controls already are, so treat these as planning ranges, not quotes. The figures below come from current industry practitioners and are in US dollars, since the audit itself is an American engagement you pay for in dollars.

On cost, one widely used compliance platform puts the auditor's fee for a Type II examination at roughly $12,000 to$ 20,000 for a small to midsize company, and $30,000 to$ 100,000 or more for a large organisation, with a Type II typically costing 30% to 50% more than a Type I. Readiness work adds to that: a gap assessment in the region of $5,000 to$ 25,000, plus control implementation that can run to $30,000 or more. All in, including tooling and your own team's time, a first year total is put at around$ 25,000 for a small startup rising to over $200,000 for a large enterprise.⁷

On timeline, the AICPA sets no formal minimum observation period, but three months is the practical floor, with six months a common choice for a first Type II and twelve months typical once a programme matures. Readiness and remediation before the window usually take one to three months, fieldwork runs a few weeks, and the report itself takes a few more. A realistic end to end timeline for a first Type II is six to twelve months.⁸

The split to keep in mind is the one I keep coming back to. The readiness and the engineering are work I can do with you. The auditor's fee is a separate cost you pay the CPA firm directly. I never present the audit fee as part of my own price, because it is not mine to charge, and conflating the two is exactly the sort of thing that erodes trust.

SOC 2, ISO 27001, a penetration test and GDPR, picking the right thing

These four get confused constantly, and buying the wrong one is a common and expensive mistake. They answer different questions.

Instrument	What it is	What it answers	Who gives it to you
SOC 2 Type II	An attestation report under AICPA standards	Did my chosen controls operate effectively over a period, for a specific customer to read	A licensed CPA firm you commission
ISO/IEC 27001	An international management system certification	Do I run a recognised information security management system, certified on a three year cycle	An accredited certification body
Penetration test	A technical security assessment	Can a tester break into this system right now	A security tester, such as me as part of a build
GDPR	A legal regime	Do I meet the law's duties for personal data	Nobody issues it, the law simply applies

A penetration test is a point in time technical check, not a certification, and it is part of what I deliver on every build. SOC 2 and ISO 27001 are the two attestation and certification routes, chosen mostly by geography and by what your buyers ask for. GDPR is law that applies whether or not you hold any of the others.⁵⁶ The honest advice is simple: do the thing your actual customers are actually asking for, and no more, until the next customer asks for the next thing.

A worked example, a Leeds SaaS company asked for SOC 2 Type II

Dalesync is an invented company in Leeds with 30 staff and a turnover of about £4 million. It sells a scheduling platform used in the browser, at dalesync.example, and it has just reached the procurement stage of its largest deal yet: a contract with a big American retailer that would roughly double its revenue. The retailer's security team asks for a SOC 2 Type II report before it will sign. Dalesync has never done one.

The founder's first instinct is to ask whether a Type I will do, because it is faster and less expensive. It will not. The retailer asked for Type II, so a Type I would be read as an attempt to dodge the question. Dalesync commits to the Type II.

I run the readiness assessment against Security, Availability and Confidentiality, the three categories that match what Dalesync promises its customers. Privacy is left out of scope for now, because Dalesync's data protection obligations are handled separately and adding Privacy would widen the audit without a buyer asking for it. The gap analysis finds the usual picture. Multi factor authentication is on the engineers' cloud console but not on the support team's admin panel. Changes to production mostly go through review, but not every time, and there is no register that proves it. Backups run nightly but nobody has restored one in a year. There is no written incident procedure at all.

The remediation takes about two months. Multi factor authentication goes on every admin path. Every production change now flows through review and lands in a release register, with security testing on each release. Centralised logging gets alerts a named person receives. A restore drill on staging takes 41 minutes and that number, with the night's backup timing, goes into the continuity plan. An incident procedure is written and rehearsed.

Dalesync then commissions a licensed CPA firm, chooses a six month observation window, and pays the firm directly. For six months the controls simply keep working while evidence accumulates. The auditor samples across the window, tests remotely, and issues an unqualified Type II report. The whole path, from the first gap analysis to the signed report, takes about eight months, in line with the six to twelve month range above.⁸ Dalesync hands the report to the retailer's security team, the procurement block clears, and the contract is signed. The report then shortens the next three enterprise security questionnaires that come in, because most of what they ask is already answered.

What Dalesync bought was not a badge. It was a tested operating discipline, independently attested, that happened to be exactly what a specific buyer required.

The honest position

SOC 2 Type II is worth having when a real buyer is asking for it, and a waste of money when nobody is. When it is worth having, the work divides cleanly. I build the compliant system and prepare you for the audit: the access model, the change management and release register, the logging, the encryption, the vendor reviews, the incident procedure and the tested recovery, all of it engineered to leave the evidence an auditor samples. Then you commission an independent, licensed CPA firm to examine it and issue the report, and you pay that firm directly. I never issue it, never certify anything, and never fold the auditor's fee into mine. That separation is not a weakness in the offer. It is what makes the report, and my word about it, worth trusting.

If you have been asked for SOC 2 Type II and are not sure whether you really need it, which criteria to scope, or whether your current systems could survive a readiness assessment, book the free workshop and I will work it out with you, and the first two weeks of the work are on me.

AICPA & CIMA, System and Organization Controls: SOC Suite of Services, aicpa-cima.com, accessed 13 November 2026, https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services ↩ ↩² ↩³ ↩⁴
Journal of Accountancy, Clarified attestation standards issued (SSAE No. 18, AT-C sections 105 common concepts and 205 examination engagements), aicpa publication, 2016, https://www.journalofaccountancy.com/news/2016/apr/clarified-attestation-standards-issued-201614113/ ↩ ↩² ↩³ ↩⁴
AICPA & CIMA, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus 2022), TSP section 100, published 30 September 2023, https://www.aicpa-cima.com/resources/article/2017-trust-services-criteria-with-revised-points-of-focus-2022 ↩ ↩²
Linford & Company LLP (licensed CPA firm), What is SOC 2? Compliance, certification and reports, guidance from an auditor, linfordco.com, accessed 13 November 2026, https://linfordco.com/blog/what-is-soc-2/ ↩ ↩² ↩³ ↩⁴
International Organization for Standardization, ISO/IEC 27001 information security management systems, iso.org, accessed 13 November 2026, https://www.iso.org/standard/27001 ↩ ↩²
European Parliament and Council, Regulation (EU) 2016/679 (General Data Protection Regulation), Article 33, EUR-Lex, https://eur-lex.europa.eu/eli/reg/2016/679/oj ↩ ↩²
Drata, SOC 2 audit cost, drata.com, accessed 13 November 2026, https://drata.com/blog/soc-2-audit-cost ↩
Scrut Automation, SOC 2 compliance timeline: how long does it really take, scrut.io, accessed 13 November 2026, https://www.scrut.io/hub/soc-2/soc-2-compliance-timeline ↩ ↩²