SOC 2: trust services criteria, audits, and automation

What SOC 2 is

SOC 2 is an attestation, not a certification. A licensed CPA firm examines a service organization's controls against the AICPA's Trust Services Criteria and issues an independent opinion, called a System and Organization Controls report, describing what it found. There is no governing body that stamps an organization as SOC 2 compliant the way a certification program would; buyers evaluate the report itself, including any exceptions it lists, rather than a badge.

The Trust Services Criteria organize the examination into a set of common criteria covering the control environment, communication, risk assessment, monitoring activities, control activities, logical and physical access, system operations, and change management. Every SOC 2 report is built on this security baseline. Four additional criteria, availability, confidentiality, processing integrity, and privacy, are added only when they reflect a commitment the organization has actually made to its customers, such as an uptime service level agreement pulling in availability or a payments feature pulling in processing integrity.

A SOC 2 engagement produces one of two report types. A Type 1 report is an opinion on whether controls are designed appropriately as of a single date. A Type 2 report goes further, testing whether those same controls actually operated effectively across an observation period, typically three to twelve months. Enterprise buyers almost always ask for Type 2, since a Type 1 report only proves a control exists on paper, not that it worked over time.

Who needs SOC 2

Unlike a legal mandate such as the HIPAA Security Rule, SOC 2 is market driven. Nothing in federal or state law requires it; enterprise procurement does. It shows up as a line item in a vendor security questionnaire long before it becomes a strategic decision.

• SaaS and cloud service vendors whose contracts or security reviews from enterprise customers require a current SOC 2 report before a deal can close.
• Managed service providers, payroll processors, and other service organizations, the term SOC 2 itself uses, that host or process a customer's data on that customer's behalf.
• Companies preparing to sell into regulated verticals such as healthcare or finance, where a SOC 2 report functions as a baseline credibility signal before a vertical-specific framework even enters the conversation.
• Vendors pursuing a federal opportunity who already carry SOC 2 and want to understand what it does and does not carry over toward a FedRAMP authorization.

The trigger is rarely proactive. It usually arrives as a checkbox in a security questionnaire from the first enterprise customer large enough to require independent assurance before signing a contract.

SOC 2 requirements, by trust services criteria

Each Trust Services Criterion sets expectations rather than a fixed checklist, leaving the organization to design controls appropriate to its own environment and have the auditor test whether those controls actually work.

A report scoped to security alone is often called a SOC 2 Security report, and it is the minimum bar most enterprise buyers expect. Adding criteria the organization has not actually committed to expands audit scope and cost without giving a buyer anything new to evaluate, so scoping the right set of criteria is one of the earliest and most consequential decisions in the process.

The SOC 2 audit process, step by step

A SOC 2 Type 2 report is built around an extended observation period, not a single audit day, which shapes every step around it differently than a point-in-time review would.

1. Scoping and readiness assessment: Define which systems, Trust Services Criteria, and subservice organizations are in scope, and identify gaps against the criteria, commonly three to six weeks with an experienced advisor.
2. Gap remediation: Close identified control gaps, access reviews, logging, multi-factor authentication, vendor management, before the observation period starts; typically four to twelve weeks depending on gap severity.
3. Optional Type 1 report: Some organizations issue a Type 1 opinion first to give buyers something immediately, covering only design as of a point in time, usually completed within a few weeks of fieldwork.
4. Evidence period: Controls operate and evidence accumulates continuously; three months is the practical minimum most buyers accept for a first report, six months is a common target, and twelve months becomes standard on renewal.
5. Auditor fieldwork: The CPA firm tests a sample of evidence generated across the observation window against each in-scope criterion, commonly four to eight weeks.
6. Report drafting and management response: The CPA firm drafts the report, including any exceptions found, and the organization can add a management response describing planned remediation.
7. Report issuance: The finished SOC 2 Type 2 report is issued under restricted distribution, typically shared with customers and prospects under a non-disclosure agreement rather than published publicly.
8. Renewal: The cycle repeats roughly every twelve months to keep the report current for ongoing sales cycles and vendor reviews.

How long does SOC 2 take and what does it cost?

Ranges below assume a typical SaaS vendor scoping the security criterion plus one or two additional criteria; costs move with system complexity, prior audit history, and how many Trust Services Criteria are in scope.

A first-time Type 2 report commonly takes nine to fourteen months end to end, covering readiness, remediation, the observation period, fieldwork, and report drafting. Once a program is mature, the annual renewal cycle is largely the twelve-month observation period plus four to eight weeks of fieldwork, run back to back rather than starting over each year.

CPA firm audit fees commonly run twenty thousand to sixty thousand dollars for a Type 2 report scoped to security alone, and often fifty thousand to one hundred thousand dollars or more as additional criteria and system complexity are added. A standalone Type 1 report typically costs less, often ten thousand to twenty-five thousand dollars. Readiness advisory, when an organization does not build the program in-house, commonly adds fifteen thousand to fifty thousand dollars, and third-party penetration testing, frequently requested by enterprise buyers alongside the report, typically runs ten thousand to thirty thousand dollars a year.

ACTA is licensed per environment, and every engagement starts with a conversation. The deterministic evidence generation described later on this page targets the readiness and evidence-collection cost above, not the CPA firm's independent examination fee, which ACTA does not and cannot replace.

Common failure points

The organizations that struggle with SOC 2 tend to hit a small, recurring set of problems, most of them evidence problems rather than control-design problems.

• Evidence collected manually and inconsistently across the observation period, so by fieldwork the auditor finds gaps in the months the team forgot to capture screenshots or exports.
• Scope drawn to include systems or subservice organizations that were never part of the actual customer-facing service, inflating both cost and audit time.
• Access reviews performed once at the start of the period and never repeated, which a Type 2 examination flags immediately since it tests operating effectiveness, not intent.
• Subservice organizations, cloud providers, payment processors, treated as automatically covered by the vendor's own report, when their controls need to be separately accounted for through complementary user entity controls or their own SOC 2 report.
• Policies that describe what the security team wishes were true rather than what the engineering team actually does day to day, the single most common source of exceptions in a finished report.

How ACTA automates SOC 2

ACTA's cybersecurity policy pack library includes SOC 2 alongside NIST CSF, ISO/IEC 27001, CIS Controls, and the rest of the cybersecurity set, and like every pack, it ships with every license: a vendor does not buy a separate tier to add SOC 2 to a program that already covers a federal or healthcare framework. The pack is editable YAML, so control narratives can reflect a specific environment rather than a generic template.

ACTA runs on goRapide, BMD's deterministic causal engine, with no large language models, no agents, and nothing probabilistic anywhere in the compliance path. Assessing the same environment twice, whether for an internal check midway through the observation period or a renewal a year later, produces identical evidence and identical findings both times, with an inspectable causal chain behind each one, a property that matters directly for a Type 2 examination testing consistency of operation over months, not a single snapshot.

From a live environment, ACTA generates control narratives and an evidence binder mapped to whichever Trust Services Criteria are in scope, built continuously across the observation window rather than reconstructed by hand when the auditor asks for a sample. ACTA does not replace the CPA firm's independent opinion; it narrows what the firm has to chase down before it can form one.

Because the SOC 2 pack ships with every license alongside the federal and healthcare pack families, a vendor selling the same product into a commercial enterprise, a federal agency, and a hospital system can run SOC 2, NIST SP 800-53, and the HIPAA Security Rule out of one deployment instead of three separate tools. Continuous monitoring tracks credential health, evidence freshness, and drift from previously passing controls between cycles, refreshing a stale posture to current in two clicks.

SOC 2 and adjacent frameworks

SOC 2 overlaps heavily with ISO/IEC 27001 in access control and risk management, though the two work differently in mechanism: SOC 2 is an attestation against Trust Services Criteria, while ISO 27001 is a certification against a management-system standard. Some organizations pursue both in parallel and reuse a meaningful share of the same evidence across each engagement, even though neither report substitutes for the other.

Is SOC 2 enough for federal work?

No. A SOC 2 report overlaps with FedRAMP and NIST SP 800-53 in areas like access control and monitoring, which gives a mature vendor a genuine head start on evidence. But there is no formal reciprocity between the two. As the FedRAMP authorization process explains in detail, federal work still requires its own System Security Plan, its own continuous monitoring package, and in most cases an independent third-party assessment that a SOC 2 report alone does not satisfy.

Health-tech vendors selling to both commercial and healthcare buyers frequently need SOC 2 alongside the HIPAA Security Rule as well. The two address different obligations, contractual assurance for one, a federal legal requirement for the other, so neither substitutes for the other, even though the underlying technical safeguards overlap. A supplier weighing SOC 2 against a defense-sector requirement instead should look at CMMC Level 2, which draws on a different control set entirely. See the rest of the compliance framework library for how SOC 2 fits the wider picture.