SOC 2 Compliance: Type I and Type II Explained

For a SaaS company selling to US enterprises, the security review often comes down to one request: "Can you share your SOC 2 Type II report?" This guide explains what a SOC 2 report is (and is not), how the Trust Services Criteria work, the difference between Type I and Type II, and a practical path to a first clean report.

What is SOC 2?

SOC 2 is one of the System and Organization Controls (SOC) reports defined by the American Institute of Certified Public Accountants (AICPA). It is designed for service organisations, such as SaaS providers, cloud hosts, data processors and managed service providers, whose customers need assurance about how customer data and systems are protected.

Full form and definition

SOC stands for System and Organization Controls (the term "Service Organization Controls" was used earlier). A SOC 2 report is an examination performed under AICPA attestation standards (the SSAE framework, AT-C section 205) using the Trust Services Criteria (TSC) as the benchmark. The report contains the auditor's opinion, management's assertion, a description of the system, and, for Type II, the controls tested and the results.

SOC 1, SOC 2 and SOC 3

The SOC report family

Report	Focus	Audience
SOC 1	Controls relevant to customers' internal control over financial reporting (for SOX)	Customers' finance teams and auditors
SOC 2	Security, availability, processing integrity, confidentiality, privacy	Customers, prospects and partners under NDA
SOC 3	Same criteria as SOC 2 but a short public summary without test details	Anyone; often published on websites

History and background of SOC 2

Before 2011, service organisations commonly used SAS 70 reports, which were designed for financial reporting controls but were widely misused as general security assurance. In 2011 the AICPA replaced SAS 70 with the SOC framework: SOC 1 for financial reporting and SOC 2 and SOC 3 for broader trust topics. The criteria have since been updated; the current 2017 Trust Services Criteria are aligned with the COSO 2013 internal control framework, and the AICPA published revised points of focus in 2022 to reflect new risks and technologies.

Why was SOC 2 introduced?

Companies were outsourcing critical systems to cloud and service providers and needed a consistent, independent way to evaluate them without sending their own auditors to every vendor. SOC 2 gives a standard report format that one auditor produces and many customers can rely on.

Main objectives and purpose

• Give customers independent assurance that a service provider's controls are designed and (for Type II) operating effectively.
• Reduce the burden of individual security questionnaires and audits.
• Describe clearly the system boundaries and the controls customers must operate themselves (complementary user entity controls).

Who needs SOC 2?

No law requires SOC 2. Companies get it because customers ask, typically in procurement or vendor risk reviews. It is most relevant for:

• B2B SaaS companies handling customer data, especially selling to mid-market and enterprise buyers in the US.
• Cloud infrastructure, data platform and analytics providers.
• Managed service providers, managed security providers and IT outsourcing firms.
• Fintech, HR tech, health tech and martech vendors that process sensitive personal or business data.
• Offshore development and support companies (including in India) serving US clients who require vendor SOC 2 reports.

Which industries does it apply to?

Any industry. The criteria are generic, and the scope is defined by the services you provide. It is most entrenched in technology, financial services and healthcare supply chains.

Geographical applicability

SOC 2 is a US framework: only licensed CPA firms can issue SOC 2 reports. It is used worldwide by companies selling to US customers. Companies outside the US often hire US-licensed CPA firms, or international firms with US CPA practices. Outside the US, the equivalent assurance standard is ISAE 3000, and many international buyers prefer ISO 27001.

Key requirements: the Trust Services Criteria

The Trust Services Criteria are organised into five categories. Security is required in every SOC 2; the others are optional and chosen based on your commitments to customers.

The five Trust Services Criteria categories

Category	Required?	What it addresses
Security (Common Criteria CC1 to CC9)	Always	Protection of information and systems against unauthorised access, disclosure and damage
Availability (A1)	Optional	Systems available for operation and use as committed (capacity, backups, recovery)
Processing integrity (PI1)	Optional	Processing is complete, valid, accurate, timely and authorised
Confidentiality (C1)	Optional	Information designated confidential is protected and disposed of as committed
Privacy (P1 to P8)	Optional	Personal information is collected, used, retained, disclosed and disposed of in line with commitments

The Common Criteria explained

• CC1 Control environment: integrity and ethical values, board or management oversight, organisational structure, competence, accountability. Evidence: code of conduct, org chart, background checks, performance reviews.
• CC2 Communication and information: internal and external communication of security responsibilities and system changes. Evidence: policies, security training, customer-facing documentation.
• CC3 Risk assessment: objectives, risk identification including fraud risk, and assessment of significant changes. Evidence: annual risk assessment.
• CC4 Monitoring activities: ongoing and separate evaluations, deficiency communication. Evidence: internal audits, control monitoring, penetration test follow-up.
• CC5 Control activities: selection and deployment of controls and policies.
• CC6 Logical and physical access: user provisioning and removal, MFA, access reviews, encryption, network security, protection against malware, physical access to facilities. Usually the largest area.
• CC7 System operations: vulnerability management, monitoring for anomalies, incident detection, response and recovery.
• CC8 Change management: authorised, tested and approved changes to infrastructure and software.
• CC9 Risk mitigation: business disruption risk, and vendor and business partner risk management.

Points of focus

Each criterion has points of focus, which describe characteristics auditors consider. They are not mandatory checklists; you design controls that achieve the criteria in your environment, and the auditor judges whether they do.

SOC 2 Type I vs Type II

Type I vs Type II

	Type I	Type II
What is tested	Suitability of control design at a specific date	Design and operating effectiveness over a period
Period	A single date	Usually 3 to 12 months (6 or 12 is most common)
Evidence	Policies, configurations and walkthroughs	Samples across the period: tickets, access reviews, logs, change records
Customer value	Useful as a first step or for early-stage vendors	What most enterprise buyers require

A common path is a Type I as soon as controls are designed, followed by a Type II covering the next 3 to 6 months, then annual Type II reports with back-to-back periods so there are no gaps in coverage.

How to implement SOC 2: step by step

1. Confirm the need and scope. Which customers ask for it, which products and environments are in scope, and which TSC categories match your commitments (most SaaS companies start with Security, often adding Availability and Confidentiality).
2. Write the system description: services, infrastructure, software, people, procedures and data, plus subservice organisations (for example AWS, Azure, Google Cloud) and whether they are carved out.
3. Run a readiness assessment against the criteria to identify gaps.
4. Design controls and policies. Map each criterion to specific controls: who does what, how often, and what evidence it produces.
5. Remediate gaps: SSO and MFA, endpoint management, centralised logging, vulnerability scanning, background checks, vendor reviews, documented change management.
6. Select a CPA firm. Look for SaaS experience and agree on the period and timing.
7. Type I audit (optional but common).
8. Operate controls through the observation period, collecting evidence continuously.
9. Type II fieldwork: the auditor samples evidence across the period and tests controls.
10. Receive the report, review exceptions, plan remediation and share the report under NDA.

Documentation and policies required

The AICPA does not publish a mandatory document list; auditors expect documentation that supports your controls. Typical SaaS policy sets include:

• Information security policy and acceptable use policy
• Access control policy (provisioning, MFA, reviews, privileged access)
• Change management and secure software development policy
• Risk assessment methodology and annual risk assessment
• Vendor (third-party) management policy and vendor reviews
• Incident response plan and incident records
• Business continuity and disaster recovery plan, with test results
• Data classification, retention and disposal policy
• Encryption and key management standard
• HR security: background checks, onboarding, offboarding, training records
• Logging and monitoring standard and vulnerability management procedure
• Privacy notice and procedures if Privacy criteria are in scope

Audit and assessment requirements

Only a licensed CPA firm can perform a SOC 2 examination and issue the report. The auditor must be independent of you; firms that design your controls should not also audit them. The report includes:

1. The independent service auditor's report (the opinion: unqualified, qualified, adverse or disclaimer).
2. Management's assertion.
3. The system description.
4. For Type II, the description of tests of controls and results, including any exceptions.
5. Optional other information provided by management.

Is there a SOC 2 certification process?

No. SOC 2 is an attestation, not a certification. Avoid describing yourself as "SOC 2 certified"; say "we have a SOC 2 Type II report covering the period from ... to ...". Reports are point-in-time or period-based, so customers usually ask for one that covers the last 12 months, plus a bridge letter for any gap between the report's end and today.

Estimated implementation timeline

• Readiness and remediation: 2 to 4 months for a startup with modern cloud tooling; longer if foundational controls are missing.
• Type I: fieldwork in a few weeks after readiness; report typically within 2 to 6 weeks.
• Type II: observation period of 3 to 12 months, then fieldwork and report.

Realistically, a company starting from scratch should plan 6 to 12 months to its first Type II report.

Cost considerations

Costs depend on the scope, number of TSC categories, size of the environment and the auditor. Main components:

• Audit fees for Type I and Type II (Type II is higher because of sampling across a period).
• Readiness and advisory if you use a consultant.
• Compliance automation platforms that connect to your cloud, identity and HR tools to collect evidence.
• Security tooling (MDM, EDR, logging, vulnerability scanning, penetration testing).
• Internal time from engineering and operations.

Small SaaS companies often report first-year totals in the tens of thousands of US dollars when audit, tooling and testing are combined; larger scopes cost more. Compare several CPA firms and ask exactly what is included.

Benefits of SOC 2

• Shorter enterprise sales cycles and fewer bespoke security questionnaires.
• Stronger security operations: access reviews, change control and monitoring become routine.
• A clear description of shared responsibilities with customers and subservice providers.
• Board and investor confidence, and better cyber insurance conversations.

Risks and consequences of not having SOC 2

There are no legal penalties for lacking a SOC 2 report. The consequences are commercial: blocked or delayed deals, more intrusive customer audits, and contractual breaches if you promised a report. A report with significant exceptions or a qualified opinion can also raise concerns that need explaining.

Common implementation mistakes

• Choosing too many TSC categories in the first year.
• Describing controls that do not happen (for example quarterly access reviews that were never scheduled).
• Gaps between report periods that leave customers without coverage.
• Ignoring complementary user entity controls and subservice organisation controls in the system description.
• Not keeping evidence through the whole period, such as missing offboarding tickets for leavers.
• Calling it a certification in marketing material.

Compliance challenges for IT companies

• Engineers with production access: auditors look for least privilege, approvals and logging of privileged actions.
• Fast deployments: change management must show peer review and testing without slowing delivery; pull-request rules and CI checks help.
• Vendors everywhere: every SaaS tool that touches customer data needs a vendor review.
• Offshore teams: background checks and device controls must work across countries and contractors.

Best practices and recommendations

• Start with Security only, plus Availability or Confidentiality if your contracts promise them.
• Automate evidence collection from identity, cloud, code and HR systems.
• Use one control framework mapped to SOC 2, ISO 27001 and relevant laws.
• Run a pre-audit "mock" test of key samples before fieldwork.
• Plan report periods back to back and offer bridge letters.
• Publish a SOC 3 or trust page for prospects who only need a summary.

Tools and technologies that help

• Compliance automation platforms with SOC 2 templates and integrations.
• Identity provider with SSO, MFA and automated provisioning (SCIM).
• MDM and endpoint detection for company devices.
• Cloud security posture management and infrastructure-as-code scanning.
• Centralised logging and alerting, and vulnerability and dependency scanning.
• Ticketing systems that record approvals for access and change.
• Security awareness training platforms or an LMS that tracks completion for every employee.

Relationship with other compliance frameworks

SOC 2 compared with related frameworks

Framework	How it relates to SOC 2
ISO 27001	Certifiable management system; large control overlap. ISO 27001 proves a working ISMS; SOC 2 Type II proves specific controls operated over a period. Many companies do both.
HIPAA	A SOC 2 (sometimes with HIPAA criteria mapped in a "SOC 2+") helps business associates evidence safeguards, but HIPAA compliance is a legal determination.
PCI DSS	SOC 2 does not replace PCI DSS validation for card data.
NIST CSF	CSF can structure the programme; SOC 2 provides independent assurance on it.
FedRAMP	Federal authorization with far more controls; SOC 2 is not accepted in its place.
ISO 27701	Certifiable privacy management; SOC 2 Privacy criteria are an alternative for US buyers.

Real-world implementation examples

These are illustrative composites, not specific companies.

Seed-stage B2B SaaS

A 25-person startup losing deals to security reviews scoped Security only, used its cloud provider as a carved-out subservice organisation, rolled out SSO and MDM, and automated evidence through a compliance platform. It obtained a Type I after three months and a Type II covering a three-month period soon after, then moved to annual 12-month periods.

Indian managed services provider with US clients

A 150-person MSP added Availability and Confidentiality because client contracts committed to uptime and confidentiality. The hardest controls were background checks for contractors and evidence of timely offboarding across client tools; it solved them with a central joiner-mover-leaver workflow linked to HR.

Frequently asked questions

Is SOC 2 a certification?

No. It is an attestation report with an auditor's opinion. There is no SOC 2 certificate.

Is SOC 2 mandatory?

No law requires it. Customers often require it contractually.

What is the difference between SOC 2 Type I and Type II?

Type I tests whether controls are suitably designed at a point in time. Type II also tests whether they operated effectively over a period, typically 3 to 12 months.

Which Trust Services Criteria are mandatory?

Only Security (the Common Criteria). Availability, processing integrity, confidentiality and privacy are optional.

How long is a SOC 2 report valid?

Reports do not expire formally, but customers usually expect one covering a period that ended within the last 12 months, plus a bridge letter.

Who can issue a SOC 2 report?

Only a licensed CPA firm that is independent of the service organisation.

Can a company outside the US get SOC 2?

Yes. Many Indian, European and other companies obtain SOC 2 reports from CPA firms that serve international clients.

How long does SOC 2 take?

Typically 6 to 12 months from start to the first Type II report, depending on readiness and the observation period.

What is a bridge letter?

A letter from management (not the auditor) stating there have been no material changes to controls between the end of the last report period and a later date.

What is a carve-out?

Excluding a subservice organisation's controls (such as your cloud provider) from your report and referring customers to that provider's own SOC report.

What is a SOC 3 report?

A short, public version of a SOC 2 report without test details, suitable for publishing on a website.

Can we share our SOC 2 report publicly?

SOC 2 reports are restricted-use and usually shared under NDA. Use a SOC 3 for public distribution.

What happens if the auditor finds exceptions?

Exceptions are described in the report. A few exceptions with good responses usually still result in an unqualified opinion; pervasive failures can lead to a qualified opinion.

Conclusion and next steps

SOC 2 is the common currency of SaaS security in the US market. The key is to promise only what you do, design controls that fit your engineering workflow, and collect evidence continuously so the Type II period is a formality.

1. Confirm which customers need SOC 2 and which criteria match your commitments.
2. Run a readiness assessment and fix foundational gaps (identity, devices, logging, change control).
3. Choose a CPA firm and agree Type I and Type II timing.
4. Automate evidence and plan back-to-back report periods.

How we keep this guide up to date

We review this guide every six months and whenever the AICPA updates the Trust Services Criteria, points of focus or SOC guidance. Each review checks criteria names, report types and linked AICPA resources.