Last reviewed 8 August 2026 by Tom McNamara. This page is reviewed quarterly; the next review is due November 2026. Market facts are date-stamped “as of 06-08-2026”.
SOC 2 does not have a fixed requirements list. It has criteria: the AICPA Trust Services Criteria, defined in TSP Section 100 (2017, with revised points of focus issued in 2022). Security is the only mandatory category, examined through nine Common Criteria, CC1 to CC9; Availability, Processing Integrity, Confidentiality and Privacy are optional categories you scope in when customer commitments call for them. You design the controls; a licensed CPA firm then attests whether they are suitably designed (Type 1) and operating effectively over time (Type 2).
If you came here looking for the SOC 2 checklist to download and complete, that document does not exist. What exists is a criteria model, and once you understand it, “requirements” makes sense again.
The SOC 2 requirements model at a glance
Every SOC 2 report is built from the same five categories, but only Security is mandatory. The other four are scoped in or out based on what you have committed to customers.
| Category | Criteria reference | Status | What it asks, in one line |
|---|---|---|---|
| Availability | A1.1 to A1.3 | Optional | The system is available for operation and use as committed |
| Processing Integrity | PI1.1 to PI1.5 | Optional | System processing is complete, valid, accurate, timely and authorised |
| Confidentiality | C1.1 to C1.2 | Optional | Information designated as confidential is protected, including secure disposal |
| Privacy | P1 to P8 | Optional | Personal information is collected, used, retained, disclosed and disposed of in line with your commitments |
Why listen to us
Atoro is an Irish AI governance and cyber compliance consultancy for software companies, and the first consultancy in Europe certified against ISO 42001. We prepare software companies for SOC 2 Type 1 and Type 2 reports at a fixed price agreed after scoping, and this criteria map is the one we work through with clients.
SOC 2 has criteria, not requirements
SOC 2 is an attestation, not a certification. A licensed CPA firm examines your controls against the Trust Services Criteria under AICPA attestation standards and issues a report. Nobody certifies you, and no regulator approves the result.
This is where SOC 2 stops behaving like ISO 27001. There is no Annex A with a numbered control set to adopt. The AICPA publishes the criteria and points of focus, and you design controls that meet them for your system, your architecture and your commitments. Schellman, an audit firm that performs SOC 2 examinations, puts it bluntly: when it comes to choosing categories and controls, “there is no checklist or even guidance on how to choose.”
Two consequences follow. First, two companies can both hold SOC 2 reports with different controls, because the criteria are the constant and the controls are risk-based and auditor-judged. Second, “compliant with SOC 2” is the wrong mental model. You are not complying with a rulebook; you are evidencing that your controls meet criteria an auditor can test.
For what the examination itself involves, our existing post on what a SOC 2 audit is covers it; this guide stays on criteria and evidence.
The full list, mapped: the Common Criteria (Security)
Security is implemented through nine Common Criteria, CC1 to CC9, which together contain 33 individual criteria. CC1 to CC5 map to the COSO internal control framework; CC6 to CC9 cover access, operations, change management and risk mitigation.
This is the closest thing SOC 2 has to a requirements list, in full:
| Series | Name | Criteria | What it covers |
|---|---|---|---|
| CC2 | Communication and Information | CC2.1 to CC2.3 | How security objectives and responsibilities are communicated internally and externally |
| CC3 | Risk Assessment | CC3.1 to CC3.4 | How you specify objectives, identify and analyse risk, and assess fraud risk and change |
| CC4 | Monitoring Activities | CC4.1 to CC4.2 | Ongoing and separate evaluations of controls, and how deficiencies are communicated and corrected |
| CC5 | Control Activities | CC5.1 to CC5.3 | Selecting and deploying control activities, including general controls over technology |
| CC6 | Logical and Physical Access Controls | CC6.1 to CC6.8 | Identification, authentication, authorisation, credentials, provisioning and deprovisioning, physical access, and protection against external threats |
| CC7 | System Operations | CC7.1 to CC7.5 | Vulnerability and incident detection, monitoring, incident response and recovery |
| CC8 | Change Management | CC8.1 | Authorising, designing, testing, approving and implementing changes |
| CC9 | Risk Mitigation | CC9.1 to CC9.2 | Identifying and mitigating risks from business disruption and vendor relationships |
CC1 to CC5: the organisational layer
CC1 to CC5 test whether security is governed, communicated, risk-assessed, monitored and deliberately controlled. They are management controls, and the evidence is documents and records, not tooling.
Evidence that typically satisfies this layer includes a maintained risk register, documented communication of security policies and records of recurring control monitoring, and it is reusable: CC1 to CC5 evidence supports every optional category you add later, so getting Security right first keeps scope expansion cheaper.
CC6 to CC9: the technical layer
CC6 is where most first-time audits collect exceptions, because it is the most evidence-dense series: authentication, access lifecycle and system boundary protection.
Controls auditors test most often under CC6, and the evidence behind them:
- Multi-factor authentication on every account, endpoint and admin console, typically enforced through an identity provider. Evidence: IdP configuration exports and coverage reports.
- Documented, periodic access reviews confirming each person’s access still matches their role. Evidence: dated review records with sign-off.
- Timely deprovisioning when someone leaves, ideally automated so accounts are disabled the same day. Evidence: leaver tickets matched against access exports.
CC7 covers operations and incidents, CC8 is a single criterion covering the change lifecycle, and CC9 covers risk mitigation including vendor risk.
The optional categories and when to scope them
You scope an optional category in when a customer commitment or buyer requirement calls for it, not because a template includes it. Schellman’s rule: your in-scope categories should be predicated entirely on your service commitments and system requirements.
Availability (A1.1 to A1.3)
Scope Availability in when you sell an uptime commitment and customers want audited proof you can recover. A1.3 requires tested recovery procedures, so a written disaster recovery plan with no exercise evidence draws an exception.
The criteria cover capacity monitoring (A1.1), environmental and backup protections (A1.2) and recovery testing (A1.3). Evidence: dated recovery test results showing whether you met your stated Recovery Time Objective and Recovery Point Objective, with failures and corrective actions recorded. Stated targets alone are not enough.
Processing Integrity (PI1.1 to PI1.5)
Scope Processing Integrity in when processing accuracy is the product: payments, billing, trading or data processing where customers rely on complete, valid, accurate, timely and authorised processing. It is evidence-heavy because auditors trace transactions end to end.
Evidence: end-to-end reconciliation that balances inputs against outputs, tamper-evident records, and recurring testing of material transaction types. A database log on its own does not demonstrate processing integrity. Note the distinction auditors draw: processing integrity is about whether your system does what you say it should, not whether the input data itself was accurate.
Confidentiality (C1.1 to C1.2)
Confidentiality protects information your business designates as confidential, such as trade secrets or contract terms. C1.1 requires you to identify and protect it; C1.2 requires secure disposal, with evidence the disposal actually ran.
Evidence for C1.2: automated lifecycle deletion rules with audit logs recording each deletion, immutable retention controls, and deletion attestations where contracts request them. A deletion policy without execution records is a common exception.
Privacy (P1 to P8)
Privacy applies only when you handle personal information, and covers its full lifecycle: notice, choice and consent, collection, use and retention, access, disclosure, quality, and monitoring and enforcement.
Handling personal data does not force Privacy into scope. Many software companies meet customer privacy needs through Security and Confidentiality controls plus a standalone privacy programme, adding the Privacy category only when a specific buyer requires it. Even commitments you have made do not oblige you to include the matching category in the report.
How an auditor judges whether you meet the criteria
A Type 1 report examines whether your controls are suitably designed at a point in time. A Type 2 report examines whether they operated effectively over a period, usually six to twelve months. Enterprise buyers nearly always ask for Type 2.
Each criterion carries points of focus, which are the characteristics an auditor considers when judging whether your controls meet it. The 2022 revision updated those points of focus, not the criteria themselves. This is why cookie-cutter evidence fails: the auditor tests your controls against the criteria, not your artefacts against a template, a worry first-timers raise directly in auditor Q&As.
The SOC 2 risk assessment is CC3, not a separate deliverable
When people search for a “SOC 2 risk assessment”, they are usually looking for CC3, the risk assessment series inside the Common Criteria. It is not a standalone document you buy; it is the work of identifying and analysing the risks your controls exist to mitigate.
Your risk assessment is what connects the criteria to your control design. It lets you defend scope decisions to an auditor: which risks are relevant, which optional categories your commitments trigger, and which threats you mitigate under CC9. A maintained risk register is both CC3 evidence and the backbone of the whole engagement.
Common failure points
The recurring exceptions cluster in predictable places: access lifecycle gaps under CC6, untested recovery plans under A1.3, and policies without execution records.
- Missing MFA coverage on some service, endpoint or admin account.
- Terminated personnel who retain access. Reconcile an access export against current personnel before the observation period starts.
- Shared or generic credentials.
- A disaster recovery plan that has never been exercised, which fails A1.3.
- Disposal and deletion policies with no evidence the process ran, which fails C1.2.
- For Processing Integrity, treating a database log as sufficient evidence when auditors expect reconciliation.
Requirements people assume exist, but do not
Several widely repeated “SOC 2 requirements” simply do not exist. The criteria model, not a fixed catalogue, is the real structure.
- “Send me the official SOC 2 controls list.” There is no official controls list. The AICPA publishes criteria and points of focus; you design the controls. Even audit firms state there is no checklist or guidance on how to choose.
- “We need to get SOC 2 certified.” SOC 2 is an attestation report issued by a licensed CPA firm, not a certificate.
- “We must include all five categories.” Security is the only mandatory category. You are not required to add a category even when you have commitments it would cover, particularly in a first examination.
- “The criteria tell us which tools to buy.” They do not. Controls are risk-based and auditor-judged; the same criterion can be met with different tooling.
- “A compliance platform can issue our SOC 2.” Platforms collect and organise evidence. Only a CPA firm can perform the examination and issue the report.
- “SOC 2 prescribes a fixed timeline.” The criteria set no timeline. In practice, readiness typically takes three to six months and the Type 2 observation period six to twelve, but those are market norms, not requirements.
The step-by-step readiness sequence is a different question from the criteria model, and our companion SOC 2 compliance checklist guide owns it. What the work costs is covered separately in SOC 2 certification cost.
FAQs
1. Is there an official SOC 2 controls list I can download?
No. The AICPA publishes the Trust Services Criteria and points of focus, not a controls catalogue. You design controls that satisfy the criteria for your system, and the auditor judges whether they are suitably designed and operating. Schellman, an audit firm, states plainly that there is no checklist or even guidance on how to choose.
2. What are the SOC 2 Trust Services Criteria?
They are the five categories an auditor measures your controls against: Security, Availability, Processing Integrity, Confidentiality and Privacy, defined in AICPA TSP Section 100. Security is mandatory and contains the nine Common Criteria, CC1 to CC9. The other four are optional categories you scope in based on your customer commitments.
3. Is SOC 2 a certification?
No, it is an attestation. A licensed CPA firm examines your controls under AICPA attestation standards and issues a report expressing an opinion. There is no certificate and no accreditation body behind it.
4. Do we need all five Trust Services Criteria in our report?
No. Security is the only category every report must include. Add Availability if you sell uptime commitments, Processing Integrity if processing accuracy is the product, Confidentiality if contracts designate information as confidential, and Privacy if a buyer specifically requires it for personal data. You are not obliged to include a category even when you have made commitments it would cover.
5. What is the biggest misstep when scoping a SOC 2?
Scoping by template instead of by commitment. Every category you add increases the controls you maintain, the evidence you collect and the auditor hours you pay for, so adding one no customer asks for raises cost without winning deals. The fix is unglamorous: read your contracts and ask your target buyers which categories they require.
6. What is a SOC 2 risk assessment?
It is the CC3 series of the Common Criteria: specifying objectives, identifying and analysing risks to those objectives, and considering fraud and change. It is not a separate product or document you purchase. Your risk register is the evidence, and it is what justifies your control design and scope decisions to the auditor.
7. How long does it take to meet SOC 2 requirements?
Market norms, not mandated timelines: readiness typically takes three to six months, the Type 2 observation period runs another six to twelve months, and fieldwork plus reporting takes about four to six weeks after that. A Type 1 report skips the observation period because it tests design at a single date.
8. Can a compliance platform get us SOC 2 compliant on its own?
No. Platforms are evidence infrastructure: they collect logs, monitor controls and organise artefacts. The report itself can only come from a licensed CPA firm performing an attestation examination. You still need the controls, the scope decisions and the auditor.
Next step
If you are unsure which categories your commitments trigger, scoping is the right place to get help: it sets everything downstream, from controls and evidence to timeline and audit fees. Atoro’s SOC 2 implementation service prepares software companies for Type 1 and Type 2 at a fixed price agreed after scoping, and our TrustOps service keeps the evidence running between reports. The scoping conversation comes first, and it starts from your contracts, not a template.
Sources
Primary sources:
- AICPA, “2017 Trust Services Criteria (With Revised Points of Focus: 2022)”, TSP Section 100. https://us.aicpa.org/content/dam/aicpa/interestareas/frc/assuranceadvisoryservices/downloadabledocuments/trust-services-criteria.pdf (abstract page fetched and confirmed, 2026-08-06)
- AICPA, “System and Organization Controls: SOC Suite of Services”. https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services (fetched 2026-08-06)
Secondary sources (provider named, date checked):
- Schellman (audit firm), “The 5 SOC 2 Trust Services Categories Explained”, published 27 Aug 2025, updated 11 Feb 2026. https://www.schellman.com/blog/soc-examinations/soc-2-trust-services-criteria-with-tsc (fetched 2026-08-06)
- SOC2Auditors.org (auditor directory), “SOC 2 Trust Services Criteria: The 5 Categories and When to Scope Them”. https://soc2auditors.org/insights/soc-2-trust-services-criteria/ (fetched 2026-08-06)
- SOC2Auditors.org, “SOC 2 Controls List”. https://soc2auditors.org/insights/soc-2-controls-list/ (per R8 research, checked 06-08-2026)
- Ciphrix, citing Journal of Accountancy: “SOC 2 isn’t a certification.” https://ciphrix.com/blog/soc-2/trust-services-criteria–soc-2 (per R8 research, checked 06-08-2026)
Language sources only (never cited as fact):
- Reddit r/cybersecurity auditor AMA questions, captured verbatim via Thoropass (thread URLs unverified; used for FAQ phrasing only).