SOC 2 Compliance Guide: Criteria, Types, Process, and Audit Readiness

A customer security questionnaire lands in your inbox. One line asks whether you hold a current SOC 2 report. Sales freezes the deal until someone can answer with more than a shrug. You open a half-written wiki page. Three system lists disagree. The real exposure is walking into scope talks without a defensible inventory of what you run and who can reach it, with the auditor as only one part of that risk.

Most teams search for SOC 2 compliance for that reason. They are not ready to buy a platform. They need structure to brief leadership, set scope, and stay credible with an auditor or a buyer’s security team.

What SOC 2 is and the five Trust Services Criteria

SOC 2 is a System and Organization Controls report for service organizations. Licensed Certified Public Accountants (CPAs) examine controls against the Trust Services Criteria from the American Institute of Certified Public Accountants, the AICPA. The criteria live in TSP Section 100, the 2017 Trust Services Criteria with revised points of focus published in 2022. That 2022 revision is the AICPA’s most recent update to the framework, and auditors continue to refine how they apply those points of focus to identity types, devices, and cloud boundaries.

Security is required in every SOC 2 examination. Organizations may also include availability, processing integrity, confidentiality, and privacy. Those categories must match customer commitments and system description language.

Category	What it addresses in plain terms
Security	Protect systems against unauthorized access and misuse
Availability	Systems are available for operation and use as committed
Processing integrity	System processing is complete, valid, accurate, timely, and authorized
Confidentiality	Information designated as confidential is protected as committed
Privacy	Personal information is collected, used, retained, disclosed, and disposed of in line with commitments

Security is evaluated through the Common Criteria (CC1 through CC9). The series cover control environment, communication, risk assessment, monitoring, and control activities. They also cover logical and physical access, system operations, change management, and risk mitigation. Other categories add criteria when they are in scope.

SOC 2 is principles-based. Each organization designs its own controls to fit its risk profile, and the AICPA’s criteria provide the standard those controls get tested against. Type II also tests operating effectiveness over time.

Type I vs Type II: why the distinction drives the calendar

Type I reports on the suitability of control design at a point in time. Type II reports on design and operating effectiveness over a defined period. That period is often about three to twelve months. Buyers usually prefer Type II. It shows controls operated, not only that they existed on one date.

Type I still needs clear scope, policies, and implemented controls. Type II also needs period evidence. Access reviews must run on schedule. Change tickets must tie to production. Monitoring alerts must be triaged. Assets must enter and leave with a trail. Treating Type II like a longer Type I often surfaces gaps after the window has already started.

First-time teams often under-budget the Type II calendar. Policy work can finish in weeks. Clean samples across joiner-mover-leaver events, production changes, and inventory churn need a planned monitoring period. A last-minute folder dump rarely holds.

Who needs SOC 2 and why demand keeps rising

SOC 2 is common for SaaS and other B2B service organizations that host, process, or access customer data. Managed service providers face the same questionnaires. So do platforms inside customer workflows.

Demand is rarely a single regulator mandate. Enterprise procurement uses the report as a portable trust signal. A clean Type II shortens vendor reviews. A missing or thin report extends diligence or blocks production access. Founders feel it when a late-stage deal stalls on security paperwork.

IT managers and security or compliance officers usually own the evidence path. Founders often own the commercial deadline. Both need the same plain map: what the report is, what Type II adds, and which operational records auditors will sample.

If you already map payment data under a separate card-data program, treat SOC 2 as a parallel, complementary service-control signal running alongside it. Shared themes include access and change, though buyer questions and scope still differ. For payment-card control mapping on its own track, see this PCI DSS compliance guide.

The SOC 2 certification process end to end

People say “SOC 2 certification” in everyday language. Formally, a CPA issues an examination report under AICPA standards. The practical path still follows a repeatable sequence.

Define services, boundaries, and Trust Services Categories. Document what the system does and where it runs. Name key subprocessors and categories you will claim. Weak boundary language drives later evidence fights.

Readiness and gap analysis. Map controls to criteria. Rank gaps by exception risk and effort before fieldwork.

Remediate. Close policy and technical gaps. Assign owners. Set evidence rhythms before a Type II window starts.

Engage the auditor and set the period. Confirm independence, experience, and sampling approach.

Fieldwork. Auditors sample users, changes, incidents, assets, and tickets. For Type II, they test operating effectiveness.

Report and exceptions. Remediate findings. Brief customers carefully. Plan the next period so evidence does not reset.

The process fails most often when slides replace systems of record. If a control cannot produce dated artifacts, it will not survive sampling. Scope definition is also where asset inventory enters the story. Proving control over a system starts with listing it in scope.

SOC 2 certification requirements auditors actually sample

SOC 2 certification requirements are not identical for every company. Auditors still cluster sampling around a few operational themes once Security is in scope.

Logical access. Cover joiner-mover-leaver workflows and privileged access. Use multi-factor authentication (MFA) where risk demands it. Run access reviews that match the org chart. CC6 covers logical and physical access, including boundary protections and role-appropriate access. CC6.1-style boundary work assumes you can name systems and entry points in scope before you prove who may use them.

Change management. Approve changes. Honor claimed segregation of duties. Tie tickets to production. CC8 addresses change in the Common Criteria.

Monitoring and incident response. Detect anomalies and configuration issues. Evaluate events. Respond and recover. CC7 covers system operations. That includes detecting configuration changes and new vulnerabilities, often discussed as CC7.1. Monitoring claims fail when tool coverage diverges from the system description.

Asset and system inventory. Access, monitoring, and change samples start from in-scope systems. Missing hosts break population frames. So do admin consoles and still-reachable decommissioned servers. Type II also samples life cycle evidence: when an asset was provisioned, patched, and retired. Dependency context from service mapping helps show which systems sit on critical paths when you freeze scope populations.

Encryption and data protection. Confirm data is encrypted at rest and in transit, including on personal devices where policy allows their use for work. Auditors sample key management practices alongside the encryption claim itself.

Application security. Confirm defenses sit in front of production applications against common web attacks, including SQL (Structured Query Language) injection, cross-site scripting (XSS), and cross-site request forgery (CSRF). A web application firewall (WAF) is one control auditors commonly look for here.

Physical and environmental security. Confirm access to data centers, backup media storage, and other sensitive facilities is restricted to authorized personnel and logged.

Workforce security training. Confirm the security awareness program covers phishing recognition, social engineering, and incident reporting, with training records available to sample.

Vendors and subservice organizations. Carve-outs, inclusive methods, and complementary user entity controls must match the system description.

Type II needs operating evidence spread across the full period rather than a single screenshot week. Lagging access reviews create exceptions. So do after-the-fact change tickets and partial monitoring coverage. A coherent system description and management assertion still matter, and technical controls only protect the systems that made it onto the list in the first place.

Availability, confidentiality, and privacy controls in practice

Security draws most of the attention in a SOC 2 engagement because it applies to every audit. The other three categories most commonly added, availability, confidentiality, and privacy, each carry their own concrete evidence expectations once they enter scope.

Availability. Document the minimum service level or uptime commitment made to customers. Confirm failover and disaster recovery procedures exist and get tested on a defined cadence. Capacity planning and performance monitoring for production systems round out the evidence auditors sample here.

Confidentiality. Classify data by sensitivity level and document which categories carry confidentiality commitments in customer contracts. Limit access to confidential data on a need-to-know basis, and confirm secure disposal procedures apply once the retention period for that data ends.

Privacy. Maintain a documented privacy notice describing what data gets collected, how it gets used, and with whom it gets shared. Confirm a process exists for individuals to access, correct, or request deletion of their data, and keep a complete record of disclosures made to third parties. Breach notification procedures should specify clear timelines for notifying both affected individuals and relevant regulators.

Audit readiness and common challenges that create findings

Audit readiness means complete, dated, reconcilable evidence exists on request, captured as it happens rather than assembled afterward from chat threads. Teams that wait for the first auditor request list often fail on process even when intent was solid throughout. This section covers audit readiness and the failure points that show up again and again in Type II samples.

Incomplete or stale asset inventories. Shadow cloud accounts leave holes in access and monitoring populations. So do abandoned test stacks that still hold credentials, and devices never enrolled.

Access reviews that lag org reality. Contractors and former employees left in identity groups after role changes is a classic CC6 operating failure.

Decommissioned systems still showing as active. Billing may stop while DNS, VPN profiles, or agent records remain. Auditors treat “we thought it was gone” as a gap when the system still appears in logs or network paths.

No durable change evidence trail. Emergency changes without follow-up documentation break Type II samples even when the change was reasonable.

Monitoring that does not match scope. Logging only the primary app tier while claiming full environment coverage fails CC7-style expectations. Secondary databases or admin planes outside the tool create the gap.

Evidence ownership confusion. Security owns the narrative. IT owns inventory, identity, and ticketing data. Without a single owner for each control’s artifact source, packages arrive late and inconsistent.

Build readiness as a habit. Freeze a scope inventory early. Refresh it on a known cadence. Store evidence in systems auditors can trust. Manual, spreadsheet-based tracking breaks down across a multi-month Type II window.

Download the SOC 2 audit readiness checklist to close these gaps before your auditor finds them.

How asset visibility supports SOC 2

Two Common Criteria areas depend on knowing what exists before you can prove control over it. Logical access work under CC6 assumes you can identify systems and access points in scope. System operations work under CC7 assumes you can detect relevant configuration and vulnerability conditions across those systems. Auditors routinely request asset inventory evidence when they build populations for both.

A configuration management database (CMDB) is the system of record many teams use for that inventory. It holds what assets exist, configuration state, and ownership. It also holds service dependencies once service definitions are supplied and maps are maintained. That record supports define-scope and identify in-scope systems steps in the certification process.

IT asset management (ITAM) adds life cycle evidence Type II auditors sample: provisioned, patched, and decommissioned on a schedule, not only a point-in-time list. That provision-to-retire trail is often the gap teams need to close before fieldwork.

IT discovery keeps the inventory current through scheduled, high-frequency discovery cycles. That cadence targets the most common finding pattern: an inventory that no longer matches production. Scan coverage and last-seen timestamps are what auditors will test against your system description.

Virima combines discovery-sourced inventory, CMDB structure, service dependency maps, and ITAM life cycle fields. Teams can show what ran, what changed, and what left scope during the examination period. Pair that operational truth with your identity provider, ticketing, and security monitoring evidence. Inventory works alongside access reviews and incident drills, making those controls testable against a complete population.

When you need a governed view of what exists, how it connects, and what changed before the next questionnaire or fieldwork window, start with Trusted Runtime Truth.

From questionnaire panic to sample-ready evidence

SOC 2 is a CPA examination report against AICPA Trust Services Criteria. Security is in scope for every engagement. Other categories are optional when commitments require them. Type I freezes design at a moment. Type II proves operation across a period. Clear scope, honest gaps, and sample-ready evidence win. Requirements cluster on access, change, monitoring, incidents, encryption, application security, physical security, training, and inventory integrity.

Use a control-oriented checklist or template for fieldwork prep. Keep inventory and life cycle trails current so the next period does not restart from zero. Keep payment-card programs on their own track when cardholder data is in play. Keep this SOC 2 path focused on service organization trust.

Ready to pressure-test inventory and dependency evidence before the next audit window? Request a demo and see how discovery-sourced CMDB and ITAM data support SOC 2 populations.

Frequently Asked Questions

Is SOC 2 a certification or a report?

In everyday speech people say certification. Under AICPA practice, a licensed CPA issues a SOC 2 examination report on management’s controls against the Trust Services Criteria, and that report is the actual deliverable.

Do all companies need all five Trust Services Categories?

Security is the only category required in every engagement. Availability, processing integrity, confidentiality, and privacy get added when they match the system description and customer commitments. Over-scoping categories without evidence creates avoidable exceptions.

What is the difference between SOC 1, SOC 2, and SOC 3?

SOC stands for System and Organization Controls, and the AICPA publishes three main report types under that family. SOC 1 covers controls relevant to a service organization’s impact on customers’ financial reporting. SOC 2 covers the five Trust Services Criteria described above. SOC 3 covers the same criteria as SOC 2 in a shorter, general-use format suitable for public distribution.

Is SOC 2 compliance mandatory?

SOC 2 compliance is voluntary rather than legally mandated. Enterprise customers and procurement teams often require a current report before signing a contract or granting production access, which makes it a practical requirement for most B2B SaaS and service providers even without a regulatory mandate behind it.

How long does a Type II examination period usually run?

Many organizations use a period of roughly three to twelve months, set with the auditor based on risk, customer expectations, and control maturity. Shorter periods can still work when evidence quality is strong, but buyers often prefer longer operating histories.

How much does a SOC 2 audit cost?

Cost varies with report type, organization size, system complexity, and how mature existing controls already are. A Type I examination typically costs less and moves faster than a Type II, since Type II adds a multi-month observation period plus the evidence collection that period demands.

Why do auditors care so much about asset inventory for SOC 2?

Access and monitoring tests need complete populations. If in-scope systems are missing from inventory, samples represent only part of the environment described in the report. Stale inventory is a frequent root cause of both CC6 and CC7-related findings.

How does Virima relate to SOC 2 compliance work?

Virima supports the inventory, configuration, ownership, dependency, and life cycle evidence auditors use when testing whether you know what is in scope and whether it stayed current during the period. It complements identity, ticketing, and security monitoring evidence that CPA examiners already rely on.