SOC 2 Requirements Explained: Controls, Criteria & Step-by-Step Implementation Guide

Most organizations seeking to meet SOC 2 requirements already know the framework exists. The challenge is understanding how the controls translate into daily operational work, and how long the entire process takes when engineering bandwidth is already committed to product.

This guide breaks down the Trust Services Criteria, the controls auditors evaluate, the evidence they expect, and a phase-by-phase implementation path for mid-market and enterprise security teams.

What SOC 2 Actually Requires 

SOC 2, or System and Organization Controls 2, is an auditing framework developed by the American Institute of Certified Public Accountants (AICPA). It evaluates how well a service organization protects customer data by testing internal controls against defined criteria.

Here is what makes SOC 2 different from frameworks like PCI DSS or HIPAA: 

SOC 2 does not provide a checklist of technical controls to implement. Instead, it defines five Trust Services Criteria and leaves it to each organization to design controls that meet those criteria within their specific environment. 

The effectiveness of those controls is then validated through an independent audit by a licensed CPA firm. For a deeper look at how SOC 2 differs from ISO 27001, see our ISO 27001 vs SOC 2 comparison.

This flexibility is the source of both SOC 2’s adaptability and most organizations’ confusion. There is no single correct set of controls. Two companies with the same number of employees could have very different SOC 2 control sets depending on their infrastructure, data flows, and which criteria their customers require.

SOC 2 mandates three things clearly:

• Controls must address the relevant criteria
• Controls must be documented
• Controls must operate effectively. 

The auditor’s job is to verify those three things.

The 5 Trust Services Criteria Explained

The Trust Services Criteria form the foundation of every SOC 2 audit. Security is mandatory. The remaining four are selected based on what your services deliver and what your customers expect.

Security (Common Criteria)

Security is the baseline. It applies to every SOC 2 audit regardless of scope. It covers the security of data against unauthorized access, including both logical and physical controls. 

This is where access management, incident response, encryption, monitoring, change management, and vendor oversight all sit. 

The Security criterion spans nine Common Criteria categories, CC1 through CC9.

Availability

Availability focuses on whether systems are operational and accessible as committed. Organizations offering uptime SLAs, customer-facing platforms, or infrastructure that others typically depend on include this criterion. Controls here address redundancy, disaster recovery, failover mechanisms, and capacity planning.

Processing Integrity

Processing Integrity applies when your organization processes data on behalf of customers. It confirms that data is processed accurately, completely, and on time. Controls include quality assurance checks, transaction logging, error detection, and change management for processing workflows.

Confidentiality

Confidentiality protects information designated as confidential, such as trade secrets, intellectual property, or contractual data. Controls include encryption at rest and in transit, access reviews, data classification policies, and secure data disposal procedures.

Privacy

Privacy addresses how personal information is collected, used, retained, disclosed, and disposed of against stated commitments. Organizations handling consumer PII in industries like healthcare, fintech, or B2C SaaS, often include this criterion.

Common Criteria (CC1 through CC9): what auditors test

The operational details of every SOC 2 audit fall within 9 Common Criteria categories that make up the Security criterion. These are the areas auditors examine in every SOC 2 engagement, regardless of which additional criteria are in scope.

SOC 2 Type I vs. Type II: Which One You Actually Need

SOC 2 produces two types of reports, and the distinction matters because it determines how much operational history you need before the audit can begin.

Type I is a point-in-time assessment. The auditor evaluates whether your controls are suitably designed as of a specific date. It confirms that the right controls exist and are configured correctly. This is faster to obtain and works as a first step when building a compliance foundation.

Type II is a period-based assessment. The auditor evaluates whether controls are designed well and whether they operated effectively over a defined period — typically three to 12 months. Auditors test samples of evidence from multiple points in that period to confirm controls ran consistently throughout.

Most enterprise buyers, procurement teams, and regulated industries expect a Type II report. Type I can be useful as an interim signal, but it rarely satisfies long-term customer requirements.

Here is a consideration that many organizations overlook. Starting with Type I as a standalone milestone can feel productive, but it often adds time to the overall process rather than saving it. 

If enterprise customers are the goal, plan for Type II from the beginning. Use Type I as a checkpoint along that path, not a destination.

Timeline comparison:

• Type I: Typically 1.5 to 3.5 months (preparation plus audit)
• Type II: Typically 5.5 to 17.5 months (preparation, observation period, plus audit)

The observation period for Type II cannot be shortened. This is the single largest timeline variable, and it is the reason starting early matters. By the time a customer asks for your SOC 2 report, a nine-month timeline is often a deal-killer.

SOC 2 Controls: What You Are Actually Implementing

Each organization maps its own controls to the Trust Services Criteria based on systems, risk profile, and scope. 

For a step-by-step readiness breakdown, see our SOC 2 compliance checklist.

A mid-market company pursuing SOC 2 for the first time typically implements between 60 and 200 controls, depending on the number of Trust Services Criteria in scope and the complexity of the environment. 

Controls generally fall into three categories

1. Technical controls: Includes configurations and tools that enforce security policies automatically. These include MFA enforcement, encryption at rest and in transit, centralized logging and SIEM configuration, firewall rules and network segmentation, endpoint detection and response, and automated vulnerability scanning.
2. Operational controls: These are the processes your team runs on a recurring basis. It includes quarterly user access reviews, monthly vulnerability scan reviews and patch cycles, incident response exercises, backup testing, disaster recovery drills, and vendor risk assessments for third parties with access to customer data.
3. Administrative controls: These form the governance layer. It includes formal security policies reviewed by leadership, security awareness training with documented completion, background checks at onboarding, an annually updated risk assessment, and a change management policy with defined approval workflows.

The controls most organizations get wrong

Implementing controls is rarely the bottleneck. Proving they ran consistently over six to 12 months is the problem.

• • Quarterly access reviews: A company may conduct a thorough review in month one, document it, and then skip months four through six because other priorities took precedence. When the auditor samples evidence from across the observation period, that gap creates a finding.
  • Incident response plans: Many organizations write a plan and store it in a shared drive. If the auditor asks for evidence of a tabletop exercise and finds none, or asks for post-incident review notes and receives a blank stare, that plan does not count as an operating control.

• Vendor, change and training controls: Vendor risk management fails when new providers are onboarded without security assessments. Change management creates gaps when deployments bypass approval workflows. Training completion logs without timestamps are invisible to auditors.

The pattern across all of these is the same. The audit does not test what you built but whether you operated it. A control that ran for three months and then stopped is worse than a control that ran imperfectly but consistently. Auditors value continuity over perfection.

Step-by-Step SOC 2 Implementation Guide

The path to SOC 2 is a phased program that builds on itself. Problems created early compound at audit time.

Phase 1: Define scope

Decide which systems, data flows, and infrastructure components will be in scope. Select the Trust Services Criteria your audit will cover. Start with Security, and add Availability, Confidentiality, Processing Integrity, or Privacy only if your customers or contracts require them. Scoping too broadly is one of the most expensive mistakes organizations make. Focus on the systems that store, process, or transmit customer data.

Phase 2: Readiness assessment and gap analysis

Evaluate your current environment against the selected Trust Services Criteria. Identify which controls already exist, which need to be built, and which need documentation. This is where most organizations first realize the gap between doing something informally and proving it to an auditor.

Phase 3: Remediation

Close the gaps identified in the readiness assessment. This may involve deploying new security tools, configuring existing tools to produce audit-ready evidence, writing or updating security policies, and assigning control owners across teams. The hidden cost of remediation is internal labor. Budget for this time explicitly.

Phase 4: Policy documentation

Write or update formal policies that describe how each control operates, who owns it, how it is monitored, and how exceptions are handled. 

SOC 2 typically requires 15 to 25 formal policies, including information security, access control, incident response, change management, risk assessment, data classification, business continuity, vendor management, and acceptable use.

Phase 5: Set up evidence collection

Build the infrastructure to capture and store evidence throughout the observation period. If evidence collection is not in place before the observation period starts, six months of data cannot be reconstructed retroactively. Set this up before the clock starts.

Phase 6: Select and engage an auditor

Engage a licensed CPA firm with SOC 2 expertise. Auditor fees vary significantly. Specialist CPA firms typically charge $10,000 to $25,000 for a Type II audit. Regional and mid-tier firms range from $20,000 to $50,000. 

Big Four firms run $40,000 to $150,000 or more, typically only warranted when a specific enterprise or government customer requires it. 

For most mid-market SaaS and technology companies, a specialist or regional firm produces a report that enterprise buyers accept.

Network Intelligence provides SOC audit services that guide organizations through each phase, from auditor selection to final report.

Phase 7: Observation period (Type II only)

The observation period is the defined window during which auditors monitor whether your controls operate effectively. 

The minimum is 3 months. During this period, your team must operate controls consistently, collect evidence at the cadence defined in your policies, and address issues as they arise. Do not start the observation period before controls are actually ready.

Phase 8: Audit fieldwork and report

The auditor reviews evidence, conducts interviews, tests controls, and produces the final SOC 2 report. Fieldwork typically takes two to five weeks. 

Unresolved issues appear as exceptions in the report, and significant exceptions can result in a qualified opinion, which enterprise buyers treat as a red flag.

Phase 9: Post-audit operations

The SOC 2 report is valid for 12 months. Renewal audits pick up where the previous period ended. There should be no gap in the control operation between audit periods. This is where most organizations struggle, and we address this in the next section.

How Long Does SOC 2 Implementation Take?

For Type I, expect 1.5 to 3.5 months from start to report, assuming controls are already partially in place. For organizations starting from scratch, add one to three months for remediation.

For Type II, the total timeline is typically 5.5 to 17.5 months. This includes preparation (one to six months), the observation period (three to 12 months), and audit fieldwork and report delivery (one to two months). The single largest variable is the observation period, and it cannot be compressed.

How Much Does SOC 2 Compliance Cost?

Costs vary widely based on company size, security maturity, scope, and auditor selection. 

Below is a realistic range for mid-market organizations pursuing their first SOC 2.

The most consistently underestimated cost is internal labor. SOC 2 preparation consumes 400 to 600 hours of senior team time across engineering, IT, security, and compliance. That time has an opportunity cost that often exceeds the auditor’s invoice. Annual renewal costs are generally lower, ranging from $20,000 to $60,000, because controls are already in place.

When to Bring in a Managed Compliance Partner

Some organizations have the internal capacity to manage SOC 2 end-to-end. Many do not, and pretending otherwise usually costs more than getting help.

Signs that a managed compliance partner would reduce risk and cost include: 

• No dedicated CISO or compliance function
• A security team that is already at capacity with detection and response
• A first SOC 2 audit with no prior compliance program in place
• Customers asking for real-time compliance status rather than an annual report, and the need to align SOC 2 with ISO 27001, HIPAA, or PCI DSS simultaneously.

Network Intelligence approaches SOC 2 as an operational outcome rather than a point-in-time certification. 

With 23 years of cybersecurity experience and a team of more than 620 certified professionals, Network Intelligence provides SOC 2 compliance as part of a broader governance, risk, and compliance practice.

The platform behind this is Transilience AI. It applies multi-agent intelligence to continuously monitor environments against SOC 2 requirements. 

Evidence collection is automated across identity, infrastructure, and data layers. Control drifts are identified in real time and prioritized for remediation. The result is a live compliance posture that ensures continuous readiness.

In practice, this approach has delivered measurable outcomes. Network Intelligence helped Aucctus achieve SOC 2 certification as an industry first, with zero human touch compliance certification completed two months ahead of schedule.

If your organization also operates on AWS or Azure, you can check out the linked guides to automating SOC 2 compliance.

Conclusion

SOC 2 requirements are not complex once you understand the structure. Understand the Five Trust Services Criteria, build customizable controls mapped to those criteria and make sure evidence that proves controls operated consistently over time.

The implementation gap is also very important as the idea is to maintain a program that continuously collects evidence, catches drift early, and survives the 12-month gap between audits.

If you are planning for SOC 2 and want to understand exactly where your current environment stands and how to automate evidence collection, our team can run a readiness assessment and map the path forward. 

Reach out to Network Intelligence’s compliance advisory team to get started.