SOC 2: Type 1 vs Type 2, Criteria and Audit

SOC 2 is a report, not a certificate. An independent CPA firm examines the controls a service organisation uses to run its service and gives an opinion on them against the AICPA's Trust Services Criteria. Customers then read the report to decide whether they can trust you with their data. For SaaS companies selling to US enterprises, a current SOC 2 Type II report is often the single most requested security document.

This guide explains what the Trust Services Criteria require, the difference between Type I and Type II reports, what an auditor actually tests, how to scope and prepare, and where SOC 2 overlaps with ISO/IEC 27001 and other frameworks. It is written for the people who have to make the controls work: founders, engineering leads and the person who has just been told "sales needs a SOC 2 report by next quarter".

What is SOC 2?

SOC stands for System and Organization Controls. The AICPA defines a family of SOC reports, and SOC 2 is the one about a service organisation's controls relevant to security, availability, processing integrity, confidentiality or privacy. Those five areas are the Trust Services Categories, and the detailed requirements under them are the Trust Services Criteria (TSC).

A SOC 2 engagement is an attestation engagement performed under the AICPA's Statements on Standards for Attestation Engagements (the AT-C sections, principally AT-C 105 and AT-C 205). Only a licensed CPA firm can issue the report. The output has four main parts:

The independent service auditor's report, containing the opinion.
Management's assertion, in which your management states that the description is fairly presented and the controls are suitably designed (and, for Type II, operated effectively).
The system description, written by you against the AICPA's description criteria (DC 200): services, infrastructure, software, people, data, processes, commitments, system requirements, and the boundaries of the system.
The criteria, controls and, for Type II, the tests performed and their results, including any exceptions found.

SOC 2 reports are restricted-use: they are meant for customers, prospects and their auditors who understand the system, and are normally shared under a non-disclosure agreement. A SOC 3 report covers the same criteria in a short general-use form you can publish on your website, without the detailed tests.

History and why SOC 2 was introduced

Before SOC reports, service organisations in the US commonly provided SAS 70 reports, which were designed for controls relevant to a customer's financial statements but were widely used for general security assurance, a purpose they were never built for. When the auditing standard was replaced by SSAE 16 in 2011, the AICPA introduced the SOC framework: SOC 1 for controls over financial reporting, and SOC 2 for controls relevant to security and related areas. The attestation standards were later recodified (SSAE 18), and the criteria were updated as the 2017 Trust Services Criteria, aligned with the 2013 COSO Internal Control framework. The AICPA published revised points of focus for the criteria in 2022, without changing the criteria themselves.

The purpose is efficiency and trust. Instead of every customer auditing every vendor, one independent examination produces a report that many customers can rely on.

Who needs SOC 2?

No law requires a SOC 2 report. It is driven by customers. You are likely to be asked for one if you are:

A SaaS or cloud company that stores or processes business customers' data.
A managed IT, hosting, security or data processing provider.
A fintech, HR-tech, health-tech or payroll platform whose customers have their own regulatory duties.
A software development or outsourcing firm with ongoing access to client environments.

Industry does not decide applicability; the customer relationship does. A company selling to US enterprises will meet SOC 2 in procurement regardless of where it is based, and many Indian and European SaaS companies get SOC 2 reports for that reason.

Geography

SOC 2 is an AICPA product and the examination must be performed by a CPA firm licensed to do so, but the service organisation can be anywhere. Outside the US, ISAE 3000 reports under the International Auditing and Assurance Standards Board are sometimes used for similar purposes, and some audit firms issue combined reports.

The Trust Services Criteria explained

Security is always in scope. It is covered by the common criteria (CC1 to CC9), which also apply to every other category you add. The other four categories are optional and chosen by you based on your commitments to customers.

Category	Included	What it addresses
Security	Always	Protection of information and systems against unauthorised access, disclosure and damage
Availability	Optional	Systems are available for operation and use as committed (capacity, backup, recovery)
Processing integrity	Optional	Processing is complete, valid, accurate, timely and authorised
Confidentiality	Optional	Information designated as confidential is protected as committed
Privacy	Optional	Personal information is collected, used, retained, disclosed and disposed of as committed

The common criteria (CC1 to CC9)

The first five series follow the five components of the COSO internal control framework; the last four are specific to security.

CC1 Control environment: integrity and ethical values, board oversight, structure, competence, accountability.
CC2 Communication and information: quality information, internal communication of responsibilities, external communication with customers.
CC3 Risk assessment: objectives, identification and analysis of risks including fraud risk, assessment of changes.
CC4 Monitoring activities: ongoing and separate evaluations, communication of deficiencies.
CC5 Control activities: selecting and deploying controls, technology controls, policies and procedures.
CC6 Logical and physical access controls: access provisioning and removal, authentication, least privilege, encryption, protection against malicious software, physical access.
CC7 System operations: detection of vulnerabilities and anomalies, monitoring, incident response and recovery.
CC8 Change management: authorised, designed, tested, approved and documented changes to infrastructure, data and software.
CC9 Risk mitigation: business disruption risk and vendor and business partner risk.

The criteria say what must be achieved, not how. Each criterion comes with "points of focus" that describe characteristics an auditor will consider. You design your own controls to meet them. That is why two SOC 2 reports can look very different: the controls are yours.

Choosing the categories

Add a category only when you make commitments in that area. If your contracts include uptime commitments, availability makes sense. If customers rely on your calculations (billing, payroll), processing integrity may. If you process personal data and make privacy commitments, consider privacy, but note that the privacy criteria are detailed and that a SOC 2 report does not show compliance with a privacy law such as the GDPR or CCPA.

SOC 2 Type I vs Type II

	Type I	Type II
Question answered	Are the controls suitably designed at a specific date?	Were the controls suitably designed and did they operate effectively throughout a period?
Testing	Design and implementation	Design, implementation and operating effectiveness, with sampling over the period
Typical use	A first report, to show progress	What most customers ultimately expect

The AICPA does not set a minimum review period for Type II. Many organisations start with a shorter first period and then move to an annual cycle so that reports are continuous. Customers usually want the period to end recently; when there is a gap between the end of the period and the date they review it, service organisations often provide a bridge letter, which is a statement by management (not by the auditor) that nothing material has changed.

What auditors test, in practice

Auditors test controls by inquiry, observation, inspection of documents and records, and re-performance. For a software company, testing usually lands on these areas:

Access: onboarding approvals, timely removal on termination, multi-factor authentication, periodic access reviews, privileged access to production and databases.
Change management: every production change traceable to a ticket or pull request, peer review, testing, approval, and separation between who writes and who deploys where that is your design.
Operations: monitoring and alerting, vulnerability scanning and remediation timelines, penetration testing, logging and log review.
Incident response: a written plan, records of incidents, and tests or tabletop exercises.
Backups and recovery: backup configuration and evidence of restore tests, particularly if availability is in scope.
Vendor management: a list of subservice organisations and evidence that you review their SOC reports or equivalent.
HR and governance: background checks where your policy requires them, security awareness training, signed policies, a risk assessment, board or management oversight.

Subservice organisations and complementary controls

Most SaaS companies run on a cloud provider. The report must say how that provider is handled: the carve-out method (the provider's controls are excluded and you rely on its own reports, the common choice) or the inclusive method (the provider's controls are included and tested, which requires its cooperation). The report also lists complementary subservice organisation controls that you assume the provider runs, and complementary user entity controls, which your customers must run for the controls to work, such as managing their own users' access to your product. Customers read the latter list closely.

How to get SOC 2 ready, step by step

Confirm what customers need. Which categories, Type I or Type II, and by when.
Define the system and its boundaries. Which product, environments, infrastructure, people and data are in scope, and which cloud providers and vendors are subservice organisations.
Choose an audit firm early. Only a licensed CPA firm can issue the report. Agree on scope, categories and timing, and ask how they handle the cloud provider.
Run a readiness assessment. Map your current controls against the criteria and points of focus and list gaps. Audit firms offer readiness assessments, but the firm that audits you must stay independent of designing your controls.
Write the policies and the risk assessment. Information security policy, access control, change management, incident response, vendor management, business continuity, data classification and retention, and an annual risk assessment.
Close the engineering gaps. Single sign-on and MFA everywhere, branch protection and mandatory review, automated deployment, logging and alerting, vulnerability scanning, backups and restore tests, device management, and offboarding that removes access within your stated time.
Draft the system description against the DC 200 description criteria.
Do a Type I, or start the Type II period. The Type II period should start only when controls are running, because every exception in the period will appear in the report.
Collect evidence continuously during the period: quarterly access reviews, change tickets, scan results, training completions, incident records.
Fieldwork and report. The auditor samples evidence, discusses exceptions, and issues the report with management's assertion.
Repeat. Plan the next period so that coverage is continuous.

Documentation you will need

The AICPA does not publish a fixed list of mandatory documents. In practice, auditors expect evidence for each control, and most SOC 2 programmes include:

System description (DC 200) and a network or data flow diagram.
Information security policy and topic policies: acceptable use, access control, change management, secure development, encryption, logging and monitoring, incident response, business continuity and disaster recovery, vendor management, data classification and retention, HR security.
Risk assessment with risks, ratings, owners and treatment, reviewed at least annually.
Organisation chart, role descriptions and evidence of oversight (management or board meeting minutes on security).
Vendor inventory with the reports or reviews of critical vendors.
Asset inventory: systems, repositories, cloud accounts and endpoints.
Records the controls produce: access requests and reviews, termination checklists, pull requests and deployment logs, scan and penetration test reports with remediation, incident tickets, backup and restore logs, training records.

Timeline and cost considerations

The timeline has three parts: readiness (closing gaps), the observation period for Type II, and the auditor's fieldwork and report writing. Readiness depends on how many controls exist already and how much is automated. The observation period is chosen with the auditor and can be extended; report issuance follows fieldwork. A company that needs a Type II report urgently sometimes obtains a Type I first to show progress while the Type II period runs.

Cost factors, without figures because they vary widely by firm, region and scope:

Number of Trust Services Categories and the size and complexity of the system.
Type I or Type II, and the length of the period.
Number of locations, products and subservice organisations.
Internal engineering and management time, usually the largest cost.
Tools: identity, device management, logging, scanning, and optionally a compliance automation platform.
Penetration testing, which many auditors expect to see though the criteria do not name it explicitly.

Benefits and the risk of not having a report

A SOC 2 report shortens vendor reviews, because it answers many questionnaire items with independently tested evidence. It forces clear ownership of controls, and the recurring cycle keeps them alive. It also helps customers with their own obligations: a customer subject to HIPAA, the GLBA Safeguards Rule or SOX must oversee its vendors, and your report is part of how it does that.

There is no legal penalty for not having SOC 2. The risk is commercial: deals that stall in procurement, security questionnaires that consume engineering time, and enterprise customers who cannot approve you at all. A report with many exceptions is also a risk, because customers read the exceptions; a qualified opinion can be harder to explain than no report.

Common mistakes and challenges for IT companies

Starting the Type II period too early. Controls that were not running on day one generate exceptions for the whole period.
Writing controls you cannot evidence. "All changes are reviewed" is tested by sampling changes. If hotfixes bypass review, say so and design a compensating control.
Over-scoping. Adding every category because it looks better. Each one adds controls and testing. Add only what customers rely on.
Forgetting complementary user entity controls. If customers must manage their own users, say so clearly; otherwise the report implies you do.
Treating the cloud provider's report as your report. Their SOC 2 covers their controls under the carve-out method, not your configuration.
Manual evidence collection. Screenshots taken the week before fieldwork are fragile. Automate evidence where systems allow it.
No owner after the report. SOC 2 is a cycle. A lapsed period leaves a gap that customers notice.

Best practices, tools and technologies

Use your identity provider as the source of truth for access, with SSO, MFA and automated de-provisioning.
Enforce change management in the tools: protected branches, required reviews, CI checks and deployments only from the pipeline.
Keep infrastructure as code so that configuration changes go through the same review.
Centralise logs with retention that matches your policy, and alert on security events.
Run dependency, container and infrastructure scanning with remediation timelines by severity.
Build audit trails into the product: who did what, when, from where, for admin and data-access actions. Customers will ask, and so will your auditor if processing integrity or privacy is in scope.
Consider a compliance automation platform to map controls to evidence, but keep the risk assessment and the system description your own work.

Much of SOC 2 readiness is application work: role-based access, admin audit logs, tenant isolation, encryption of sensitive fields, data export and deletion. That is what our SaaS product development team builds.

How SOC 2 relates to other frameworks

Framework	Relationship
ISO/IEC 27001	Certification of a management system. Large control overlap. The AICPA publishes a mapping between the Trust Services Criteria and ISO/IEC 27001.
SOC 1	Controls relevant to customers' financial reporting, for their auditors. Different purpose, different criteria.
NIST CSF	Voluntary outcomes framework. The AICPA provides a mapping to it as well.
HIPAA	Some firms issue "SOC 2+" reports that add HIPAA Security Rule requirements as additional criteria.
CSA STAR	CSA STAR Attestation combines a SOC 2 engagement with the Cloud Controls Matrix.
PCI DSS	Card data security. A SOC 2 report does not satisfy PCI DSS validation.

Real-world implementation examples

Major cloud and SaaS providers make their SOC 2 reports available to customers through their trust or compliance portals, usually under NDA, and publish SOC 3 reports openly. Reading a provider's SOC 3 is a quick way to see how the system boundaries and the service commitments are described in practice.

An illustrative path for a small B2B SaaS company: a large prospect asks for SOC 2 Type II. The company selects security and availability, uses the carve-out method for its cloud provider, closes gaps in offboarding, change review and restore testing, gets a Type I report to keep the deal moving, and then completes a first Type II period. The first report shows two exceptions in access reviews that were done late; the company automates reminders and the next period is clean. The lesson is common to many first reports: exceptions are usually about consistency, not missing technology.

Next steps

Ask your customers which categories and which report type they need, and by when.
Draw the system boundary and list your subservice organisations.
Run a readiness assessment against CC1 to CC9 and any extra categories.
Fix the engineering gaps before you start the observation period.
Choose an independent CPA firm and agree the plan.

If your gaps are in the product itself, talk to us about building them in.

Frequently asked questions

Is SOC 2 a certification?

No. SOC 2 is an attestation report with an auditor's opinion. There is no SOC 2 certificate and no pass or fail mark, although an opinion can be unqualified (clean) or qualified.

Is SOC 2 mandatory?

No law requires it. Customers, particularly US enterprises, often require a current report in their contracts or procurement process.

What is the difference between SOC 2 Type 1 and Type 2?

Type I covers the design of controls at a point in time. Type II covers design and operating effectiveness over a period, with the auditor testing samples across that period. Most customers expect Type II.

How long is a SOC 2 report valid?

A report has no formal expiry, but it covers a past period. Customers generally want a report whose period ended recently, which is why organisations run SOC 2 every year.

Which Trust Services Criteria are mandatory?

Security, through the common criteria CC1 to CC9, is always included. Availability, processing integrity, confidentiality and privacy are added when they match your commitments to customers.

Who can perform a SOC 2 audit?

A licensed CPA firm that meets the AICPA's independence and professional standards. Consultants and software platforms can help you prepare but cannot issue the report.

Can a company outside the US get a SOC 2 report?

Yes. Many Indian, European and Asian SaaS companies obtain SOC 2 reports from licensed CPA firms because their customers ask for them.

What is a SOC 3 report?

A general-use summary of a SOC 2 examination without the detailed description of tests. It can be published, for example on a trust page.

No. Even with the privacy category, a SOC 2 report is not a statement of compliance with the GDPR or any other privacy law.

What is a bridge letter?

A letter from your management, not the auditor, covering the gap between the end of the last report period and the present, stating whether there have been material changes to the system or controls.

Do we need a penetration test for SOC 2?

The criteria do not name penetration testing, but they require identifying and responding to vulnerabilities, and many auditors and customers expect an independent test as part of that.

Should we do SOC 2 or ISO 27001 first?

Follow customer demand. If US buyers ask for SOC 2, start there and design controls that also map to ISO/IEC 27001, so a later certification reuses the work.