What is SOC2 – The Complete Guide

What Is SOC 2? #

Where Did SOC 2 Come From? #

SOC 2 evolved from the older SAS 70 (Statement on Auditing Standards No. 70), which was used for decades to evaluate service organizations’ internal controls. In 2011, the AICPA replaced SAS 70 with the SOC framework, introducing three report types:

• SOC 1 — Evaluates controls relevant to financial reporting (used by organizations whose services affect their clients’ financial statements).
• SOC 2 — Evaluates controls relevant to security, availability, processing integrity, confidentiality, and privacy (used by technology and service organizations handling customer data).
• SOC 3 — A public-facing summary version of the SOC 2 report.

SOC 2 rapidly became the dominant assurance framework for SaaS companies, cloud service providers, managed service providers, and any organization that processes, stores, or transmits customer data.

Who Needs SOC 2? #

SOC 2 is relevant to any organization that provides services involving customer data. Common examples include:

What Are the SOC 2 Requirements? An Overview of the Trust Services Criteria #

How the Trust Services Criteria Are Structured #

The SOC 2 framework is built on the Trust Services Criteria (TSC), published by the AICPA. The TSC define the control objectives that organizations must address, organized into five categories.

The criteria themselves are principles-based, not prescriptive. They describe what must be achieved but leave how to achieve it up to each organization. This flexibility is both a strength (the framework adapts to any environment) and a challenge (interpreting abstract criteria into concrete controls requires experience).

CC1 — Control Environment #

The organization demonstrates a commitment to integrity and ethical values, exercises oversight responsibility, establishes structure and authority, demonstrates commitment to competence, and enforces accountability.

What this means in practice:

• Code of conduct or ethics policy
• Board or management oversight of security
• Organizational chart with clear security responsibilities
• Job descriptions including security duties
• Background checks for relevant roles
• Performance evaluations incorporating security responsibilities

CC2 — Communication and Information #

The organization uses relevant, quality information to support the functioning of internal controls and communicates internally about security responsibilities, policies, and changes — and communicates externally about commitments, system changes, and security matters.

What this means in practice:

• Security policies communicated to all employees
• Security awareness training program
• Communication channels for reporting security concerns
• External-facing security commitments (e.g., in terms of service)
• Notification process for system changes affecting customers

CC3 — Risk Assessment #

The organization identifies and assesses risks to the achievement of its objectives, including risks related to fraud, and identifies and assesses changes that could significantly impact the system of internal controls.

What this means in practice:

• Documented risk assessment process
• Risk register with identified threats, vulnerabilities, likelihood, and impact
• Fraud risk consideration
• Process for assessing impact of significant changes (new systems, acquisitions, organizational changes)
• Periodic risk reassessment

CC4 — Monitoring Activities #

The organization selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning, and communicates deficiencies to responsible parties.

What this means in practice:

• Continuous monitoring of security controls (log review, alerting, dashboards)
• Periodic security assessments or penetration tests
• Process for evaluating and remediating identified deficiencies
• Reporting of control weaknesses to management

CC5 — Control Activities #

The organization selects and develops control activities that contribute to the mitigation of risks to acceptable levels, deploys them through policies and procedures, and uses relevant technology to support control objectives.

What this means in practice:

• Documented policies and procedures for each control area
• Technical controls implemented and configured according to policy
• Logical segregation of duties where appropriate
• Automated controls preferred over manual controls where feasible

CC6 — Logical and Physical Access Controls #

The organization restricts logical and physical access to protected assets, manages credentials and authentication, authorizes access based on business need, and protects against threats from external sources.

What this means in practice:

• Identity and access management (IAM) system
• Role-based access control (RBAC)
• Multi-factor authentication (MFA) for all users or privileged users
• User provisioning and deprovisioning procedures
• Periodic access reviews (typically quarterly)
• Physical access controls for facilities housing in-scope systems
• Network security controls (firewalls, segmentation, intrusion detection)
• Encryption of data in transit and at rest

CC6 is typically the most control-dense category and where the largest volume of evidence is generated.

CC7 — System Operations #

The organization detects and monitors anomalies, evaluates security events, and responds to identified security incidents.

What this means in practice:

• Security information and event management (SIEM) or centralized logging
• Alerting and escalation procedures for security events
• Vulnerability scanning (infrastructure and application)
• Incident response plan with defined roles, procedures, and communication protocols
• Post-incident review and lessons learned process

CC8 — Change Management #

The organization authorizes, designs, develops, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures.

What this means in practice:

• Change management policy and procedure
• Change request, approval, and documentation workflow (typically via ticketing system)
• Separation of development, staging, and production environments
• Code review requirements before production deployment
• Rollback procedures
• Emergency change procedures with retrospective approval

CC9 — Risk Mitigation #

The organization identifies, selects, and develops risk mitigation activities, including activities related to vendor and business partner management.

What this means in practice:

• Vendor risk assessment program
• Third-party security review process (reviewing vendor SOC 2 reports, ISO 27001 certificates, or security questionnaires)
• Contractual security requirements for vendors
• Business continuity and disaster recovery planning
• Cyber insurance (as a risk transfer mechanism)

Criterion 2: Availability (Optional) #

Purpose: The system is available for operation and use as committed or agreed.

Additional control points include:

• Capacity planning and management
• Disaster recovery planning and testing
• Backup management and restoration testing
• Uptime monitoring and SLA tracking
• Incident management specific to availability events

When to include: When your service includes uptime commitments (SLAs), when customers depend on your system’s availability for their operations, or when customers specifically request it.

Criterion 3: Processing Integrity (Optional) #

Purpose: System processing is complete, valid, accurate, timely, and authorized.

Additional control points include:

• Input validation and completeness checks
• Processing accuracy verification
• Output reconciliation
• Error detection and correction procedures
• Processing monitoring and alerting

When to include: When your service performs data processing, calculations, or transformations on behalf of customers — such as financial calculations, data analytics, automated decision-making, or transaction processing.

Criterion 4: Confidentiality (Optional) #

Purpose: Information designated as confidential is protected as committed or agreed.

Additional control points include:

• Data classification scheme
• Access restriction based on classification level
• Confidentiality requirements in employment agreements and vendor contracts
• Secure disposal of confidential information
• Encryption specific to confidential data categories

When to include: When your service handles information that customers designate as confidential (trade secrets, pre-release data, proprietary information, financial records) — beyond what the base Security criterion covers.

Criterion 5: Privacy (Optional) #

Purpose: Personal information is collected, used, retained, disclosed, and disposed of in conformity with the organization’s privacy notice and criteria set forth in the AICPA’s generally accepted privacy principles.

Additional control points include:

• Privacy notice and consent management
• Collection limitation (collecting only what is necessary)
• Use limitation (using data only for stated purposes)
• Access and correction rights for data subjects
• Disclosure limitations and third-party sharing controls
• Data quality and accuracy controls
• Retention management and secure deletion
• Privacy incident response

When to include: When your service collects or processes personal information (PII) and you need to demonstrate compliance with privacy commitments aligned to GDPR, CCPA/CPRA, PIPEDA, or similar privacy regulations.

What Are the Differences Between SOC 2 Type 1, Type 2, and Type 3? #

This is one of the most important distinctions in the SOC framework — and one of the most frequently misunderstood. Each report type serves a different purpose, provides a different level of assurance, and involves a different audit scope.

What Is a SOC 2 Type 1 Report? #

Definition: A SOC 2 Type 1 report evaluates whether an organization’s controls are suitably designed to meet the applicable Trust Services Criteria at a specific point in time.

Key characteristics:

What Type 1 proves: Your organization has designed controls that, if operated as intended, would satisfy the Trust Services Criteria.

What Type 1 does not prove: That those controls have been operating consistently over time. A Type 1 report says “this lock was installed correctly.” It does not say “this lock has been locked every night for the past six months.”

When Type 1 is appropriate:

• You need compliance evidence urgently to unblock a deal and cannot wait for a full Type 2 observation period.
• You are establishing your initial control environment and want a formal validation of your design before committing to a full observation period.
• Your customers or prospects will accept a Type 1 report as an interim measure with a commitment to achieve Type 2.

Limitations: Sophisticated enterprise buyers, financial institutions, and regulated industries typically do not accept Type 1 as a long-term substitute for Type 2. It is a stepping stone, not a destination.

What Is a SOC 2 Type 2 Report? #

Definition: A SOC 2 Type 2 report evaluates whether an organization’s controls are suitably designed AND operating effectively over a defined observation period.

Key characteristics:

What Type 2 proves: Your organization has designed controls that meet the Trust Services Criteria, and those controls have been operating consistently and effectively over a sustained period. This is a significantly higher bar than Type 1.

How the auditor tests operating effectiveness:

The auditor selects samples across the observation period to verify controls operated. Sampling methods vary by control type:

Exceptions and qualified opinions:

If the auditor finds evidence of a control not operating during part of the observation period, this is reported as an exception. Exceptions do not automatically disqualify the report, but they are disclosed to readers. Significant or pervasive exceptions can result in a qualified opinion or an adverse opinion — both of which severely undermine the report’s value and customer confidence.

The annual cycle:

Once you achieve Type 2, you must renew annually. Each subsequent report covers a new observation period, typically running consecutively (e.g., January–December 2026, then January–December 2027). Gaps between reporting periods raise questions from customers.

What Is a SOC 3 Report? #

Definition: A SOC 3 report provides the same audit scope and rigor as a SOC 2 Type 2 report but presents only the auditor’s opinion — without the detailed system description, specific control descriptions, test procedures, or test results.

Key characteristics:

How SOC 3 relates to SOC 2:

SOC 3 is not a separate audit. It is an alternate reporting format produced from the same engagement as a SOC 2 Type 2 audit. Organizations typically request both reports simultaneously: the SOC 2 Type 2 for sharing under NDA with specific customers, and the SOC 3 for general public distribution.

When SOC 3 is valuable:

• You want to publicly demonstrate your compliance posture without exposing sensitive control details.
• Your marketing team wants to reference SOC 2 compliance on your website with an associated report that prospects can download without an NDA.
• You serve a large customer base where individual NDA-based SOC 2 distribution is impractical.

Limitations: SOC 3 provides assurance that the auditor’s opinion is positive, but it gives the reader no insight into what was tested or how. Security-conscious enterprise buyers will still require the full SOC 2 Type 2 report for their vendor due diligence.

Side-by-Side Comparison: Type 1 vs. Type 2 vs. Type 3 (SOC 3) #

The Typical Progression #

Most organizations follow this path:

Year 1 (Months 1–4): Prepare controls → SOC 2 Type 1 report
Year 1 (Months 4–14): Operate controls → SOC 2 Type 2 report (first observation period)
Year 2+: Annual SOC 2 Type 2 renewal (12-month observation periods)
+ SOC 3 for public distribution (optional, recommended)

Some organizations skip Type 1 entirely and go directly to Type 2 — particularly if they have an existing security program and can sustain control operation for 6+ months without an interim report.

What Is the SOC 2 Process from Start to Finish? #

The SOC 2 process involves multiple phases, each building on the previous one. Below is the end-to-end journey — from the decision to pursue SOC 2 through report delivery and annual renewal.

Phase 1 Strategic Decision and Scoping #

Objective: Determine what is in scope, which Trust Services Criteria to include, and which report type to pursue first.

Key activities:

• Identify the business driver. Why does your organization need SOC 2? Customer demand? Competitive differentiation? Regulatory alignment? The answer shapes scope and urgency.
• Define the system in scope. SOC 2 evaluates a “system” — a combination of infrastructure, software, people, procedures, and data. Define which products, services, supporting infrastructure, and business processes are included.
• Select Trust Services Criteria. Security is mandatory. Decide which additional criteria (Availability, Processing Integrity, Confidentiality, Privacy) to include based on your service and customer expectations.
• Choose report type. Type 1 for immediate assurance, Type 2 for full enterprise credibility, or both in sequence.
• Set timeline and budget. Establish a realistic project timeline and allocate resources.

Key decisions:

nank.ai advantage: We conduct a structured scoping workshop that maps your services, infrastructure, data flows, and customer expectations to determine optimal scope and criteria selection — preventing the common mistake of scoping too broadly or too narrowly.

Phase 2 Gap Assessment #

Objective: Understand where your current controls stand relative to SOC 2 requirements.

Key activities:

• Evaluate current controls against each applicable Trust Services Criteria point.
• Categorize each control point as met, partially met, or not met.
• Identify remediation actions required for each gap.
• Prioritize remediation based on risk, effort, and audit impact.
• Produce a gap assessment report with a prioritized remediation roadmap.

What a gap assessment typically reveals:

nank.ai advantage: Our automated gap assessment evaluates your environment against all applicable TSC requirements and generates a prioritized roadmap on day one — replacing weeks of manual assessment with a structured, immediate output.

Phase 3 Remediation and Control Implementation #

Objective: Close identified gaps by designing and deploying controls.

Key activities:

• Develop policies and procedures. Draft, review, and approve all required documentation. Ensure policies describe what the organization actually does — not what it aspires to do.
• Implement technical controls. Configure IAM, MFA, encryption, logging, monitoring, vulnerability scanning, backup, network security, endpoint protection, and change management tooling.
• Implement organizational controls. Establish incident response procedures, vendor assessment processes, risk assessment workflows, and business continuity plans.
• Implement people controls. Roll out security awareness training, update HR processes (onboarding, offboarding, background checks), and communicate security responsibilities.
• Conduct the risk assessment. Document methodology, identify and score risks, determine treatment options.
• Write the system description. Draft the narrative that describes the system, its boundaries, components, and controls — this is included in the SOC 2 report itself.

Critical principle: Implement for reality, not for paper. Every policy statement must have a corresponding operational control and a mechanism for producing evidence. If your incident response plan describes a process you have never tested, it will not survive audit scrutiny.

nank.ai advantage: Our CaaS platform includes 40+ pre-built policy templates, guided implementation workflows for each TSC category, and integration with your technology stack to configure and validate technical controls — accelerating remediation from months to weeks.

Phase 4 Evidence Collection and Observation Period (Type 2) #

Objective: Operate controls consistently and collect evidence over the observation period.

Key activities:

• Operate all controls daily according to documented policies and procedures.
• Collect evidence continuously. Automated evidence (system logs, configuration exports, scan reports) should flow into a centralized repository. Manual evidence (access review records, meeting minutes, training records) must be documented and stored as it occurs.
• Monitor for gaps. Review evidence completeness monthly. A gap discovered in month two can be corrected; a gap discovered during the audit cannot.
• Execute periodic controls on schedule. Quarterly access reviews, monthly log reviews, annual risk reassessments, periodic vulnerability scans, tabletop incident response exercises, disaster recovery tests — all must occur on the schedule your policies define.
• Maintain change documentation. Every production change should have a corresponding ticket with approval, testing evidence, and deployment record.
• Handle incidents according to procedure. Any security incident during the observation period should be handled according to the incident response plan and fully documented. Well-handled incidents are not audit failures — undocumented or poorly handled incidents are.

Observation period length:

nank.ai advantage: Our platform automates evidence collection from 40+ integrated tools, monitors for evidence gaps in real time, and sends alerts when periodic controls are coming due. This transforms evidence management from a manual, error-prone process into an automated, continuously monitored operation.

Phase 5 Readiness Assessment #

Objective: Verify the organization is ready for the formal audit.

Key activities:

• Conduct a pre-audit review of all documentation, controls, and evidence — simulating the auditor’s examination.
• Verify that every TSC requirement has a corresponding control, supporting documentation, and operational evidence covering the observation period.
• Test the evidence retrieval process — can you locate any piece of evidence within minutes?
• Identify and resolve remaining gaps, inconsistencies, or weak points.
• Brief key personnel on the audit process: what to expect during auditor interviews, how to respond to questions, and how to present evidence.
• Review the system description for accuracy, completeness, and consistency with actual operations.

Why this phase matters: A readiness assessment is the difference between a smooth audit and a stressful one. Organizations that skip this step frequently discover gaps during the audit itself — when it is too late to remediate without creating an exception in the report.

nank.ai advantage: Our readiness assessment service simulates the full audit experience, conducted by practitioners with SOC 2 audit background. We identify every potential finding and help resolve it before the CPA firm arrives.

Phase 6 CPA Firm Selection and Engagement #

Objective: Select a qualified audit firm and establish the engagement.

Key activities:

• Evaluate CPA firms based on SOC 2 experience, industry expertise, team quality, timeline availability, and fee structure.
• Request proposals from 2–3 firms and compare scope, approach, timeline, and pricing.
• Negotiate the engagement letter, including scope, fees, timeline, responsibilities, and deliverables.
• Establish the communication and coordination process for the audit — primary contacts, evidence request procedures, interview scheduling.

Selection considerations:

nank.ai advantage: We maintain relationships with vetted CPA firms across multiple industries and help clients select the right firm, negotiate terms, and coordinate the engagement — ensuring the right fit and a smooth audit experience.

Phase 7 The Formal Audit #

Objective: The CPA firm examines your controls and issues the SOC 2 report.

How the audit unfolds:

Information Request #

The auditor issues an information request list (IRL) — a comprehensive list of documentation and evidence they need to review. This typically includes:

• All policies and procedures in scope
• System description narrative
• Risk assessment documentation
• Organization charts and role descriptions
• Technical architecture diagrams
• Evidence of control operation (logs, review records, scan reports, tickets, training records)
• Vendor management records
• Incident response records
• Management and governance meeting minutes
• HR onboarding/offboarding documentation

Evidence Review and Testing #

The auditor reviews submitted evidence, tests controls through sampling, and verifies that documentation matches operational reality.

For Type 1: The auditor evaluates whether controls are suitably designed as of the report date.

For Type 2: The auditor selects samples across the observation period and tests whether controls operated effectively throughout. Sampling size depends on control frequency:

Interviews #

The auditor conducts interviews with personnel responsible for controls — typically including:

• Security/compliance leadership
• IT/infrastructure personnel
• Engineering/development leads
• HR representatives
• Executive management

Interviewees should be able to explain their control responsibilities and describe how controls operate in practice. Rehearsal is not necessary, but awareness of relevant policies and procedures is essential.

Findings and Draft Report #

The auditor communicates findings — including any exceptions — and prepares a draft report for management review. Management has an opportunity to provide responses to any exceptions noted.

Final Report #

The CPA firm issues the final SOC 2 report. The report includes:

• Section I: Independent auditor’s report (the opinion)
• Section II: Management’s assertion
• Section III: System description
• Section IV: Description of controls, tests of controls, and results (Type 2 includes tests of operating effectiveness)
• Section V (if applicable): Other information provided by management

Phase 8 Report Distribution and Ongoing Compliance #

Objective: Put the report to work and prepare for next year.

Key activities:

• Distribute the report to customers, prospects, and partners under NDA (for SOC 2). Post the SOC 3 report publicly if obtained.
• Update your sales process to proactively share the report during security due diligence.
• Address any exceptions identified in the report — develop corrective actions to prevent recurrence in the next audit period.
• Continue operating controls — the next observation period begins immediately. There should be no gap between reporting periods.
• Maintain evidence collection continuously throughout the year.
• Conduct periodic internal reviews (quarterly recommended) to verify control operation and evidence completeness.
• Plan the next audit cycle — engage the CPA firm for the next year’s Type 2 engagement well in advance.

nank.ai advantage: Our platform operates year-round, not just during audit season. Automated evidence collection continues between audits, real-time dashboards show compliance posture, and renewal reminders ensure you are never caught unprepared for the next engagement.

Frequently Asked Questions #

What is SOC 2 and who created it? #

SOC 2 (System and Organization Controls 2) is an attestation framework developed by the American Institute of Certified Public Accountants (AICPA). It evaluates whether a service organization’s controls are suitably designed and operating effectively to protect customer data, based on five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. SOC 2 results in an independent auditor’s report issued by a licensed CPA firm — it is an attestation, not a certification.

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

SOC 2 Type 1 evaluates whether controls are suitably designed at a specific point in time — a single date. SOC 2 Type 2 evaluates whether controls are suitably designed AND operating effectively over a defined period, typically 6 to 12 months. Type 2 is significantly more rigorous because it requires evidence of consistent control operation throughout the observation period. Most enterprise buyers require Type 2 reports.

What is a SOC 3 report and how does it differ from SOC 2? #

A SOC 3 report contains the same scope and audit procedures as a SOC 2 Type 2 report but presents only the auditor’s opinion without the detailed system description, control descriptions, or test results. SOC 3 is designed for general public distribution — it can be posted on a website or used in marketing materials. SOC 2 reports are restricted-use documents shared only under NDA. Organizations often obtain SOC 2 and SOC 3 simultaneously from the same audit engagement.

What are the five SOC 2 Trust Services Criteria? #

The five Trust Services Criteria are: Security (mandatory — protection against unauthorized access and disclosure), Availability (systems are available as committed), Processing Integrity (processing is complete, valid, accurate, timely, and authorized), Confidentiality (confidential information is protected as committed), and Privacy (personal information is managed in accordance with privacy commitments). Security is always required; the other four are selected based on the organization’s services and customer expectations.

How long does the SOC 2 process take from start to finish? #

For a first-time engagement, SOC 2 Type 1 typically takes 2 to 5 months from project start to report issuance. SOC 2 Type 2 requires an additional observation period of 6 to 12 months during which controls must operate and produce evidence. Total timeline from project start to Type 2 report is typically 8 to 16 months. Using a CaaS platform like nank.ai can compress the preparation phase significantly, though the Type 2 observation period cannot be shortened.

Is SOC 2 a certification? #

No. SOC 2 is an attestation, not a certification. The output is an independent auditor’s report issued by a licensed CPA firm expressing an opinion on whether the organization’s controls meet the Trust Services Criteria. There is no certificate, no certification body, and no formal registry. SOC 2 reports are time-bound and must be renewed annually — unlike certifications such as ISO 27001 which are valid for three years.

Source References #

[1] American Institute of Certified Public Accountants (AICPA). SOC Suite of Services Overview and Peer Review Program Data. AICPA, 2024. https://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/socforserviceorganizations

[2] Coalfire. The State of Compliance Report 2024. Coalfire, 2024. https://www.coalfire.com/research/state-of-compliance

[3] American Institute of Certified Public Accountants (AICPA). TSP Section 100: 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy. AICPA, 2017 (updated 2022). https://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/trustdataintegritytaskforce

[4] American Institute of Certified Public Accountants (AICPA). AT-C Section 205: Examination Engagements. AICPA, 2021. https://www.aicpa.org/research/standards/auditattest/ssae

[5] Schellman. SOC 2 Benchmark Report: Timelines, Costs, and Common Findings. Schellman, 2023. https://www.schellman.com/resources

[6] International Organization for Standardization (ISO). ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements. ISO, 2022. https://www.iso.org/standard/27001

Keywords: what is SOC 2, SOC 2 explained, SOC 2 requirements, SOC 2 Type 1 vs Type 2, SOC 2 Type 3, SOC 3 report, Trust Services Criteria, SOC 2 Common Criteria, SOC 2 audit process, SOC 2 compliance, SOC 2 Security criterion, SOC 2 Availability, SOC 2 Privacy, SOC 2 for SaaS, compliance as a service, nank.ai