SOC 2

What is SOC 2

SOC 2 (System and Organization Controls 2) is an independent examination of the controls a service organization uses to protect the systems and data behind its service. A licensed CPA firm evaluates those controls against the AICPA’s Trust Services Criteria and issues a report containing its professional opinion.

SOC 2 exists because customers cannot audit every vendor themselves. One examination, performed by an independent auditor and shared under confidentiality, answers the security questions that would otherwise arrive as hundreds of individual questionnaires. That is why the request usually shows up during enterprise sales or a customer’s vendor risk review.

The criteria in use today are the 2017 Trust Services Criteria, revised in 2022 with updated points of focus. The criteria themselves have been stable since 2017.

SOC 2 is not a certification, and there is no pass or fail issued by the AICPA. The output is a report with an auditor’s opinion, and the report speaks for itself. Marketing badges saying “SOC 2 certified” are shorthand at best. What a customer actually wants is the report.

Who SOC 2 applies to

No law requires SOC 2. It applies to your organization the moment enough customers or prospects make it a condition of doing business, which in practice covers:

• software-as-a-service and cloud providers holding customer data;
• data centers, managed service providers, and IT outsourcers;
• back-office processors such as payroll, billing, and claims services; and
• any vendor whose failure could affect a customer’s own security, availability, or data.

The common pattern is that the request arrives from a single large prospect, often mid-negotiation. Deal size, not company size, drives the timing. A ten-person startup selling to a bank may need a SOC 2 report before a five-hundred-person company selling to small businesses does.

If your customers ask for “a SOC report” without specifying, note that SOC 1 covers controls relevant to a customer’s financial reporting, while SOC 2 covers security and related operational criteria. Many organizations are asked for one, the other, or both.

Who manages and enforces SOC 2

The AICPA (American Institute of Certified Public Accountants) publishes the Trust Services Criteria, the description criteria, and the attestation standards that govern how examinations are performed. It does not review individual reports, accredit organizations as compliant, or maintain a registry of SOC 2 holders.

The examination itself may only be performed by a licensed CPA firm that is independent of the organization it examines. CPA firms are subject to state licensing and the AICPA peer review program, which is where professional accountability lives. Security specialists who are not CPAs often participate in the work, but the firm signing the opinion must be a CPA firm.

Enforcement is commercial. Customers write SOC 2 obligations into contracts, procurement teams gate purchases on a current report, and a qualified opinion or missing report costs deals rather than fines. That also means your customers define what is acceptable: which categories, which report type, and how recent the report must be.

What is in scope

A SOC 2 examination covers a defined system: the infrastructure, software, people, procedures, and data that deliver the service being examined. You draw that boundary with your auditor, and the report describes it so readers know exactly what was and was not covered.

Scope has two dimensions:

• The system boundary. Which service or services, which environments, which locations, and which supporting processes are inside the description. A company with several products may scope one product’s platform, not the whole business.
• The Trust Services Categories. Security is required in effectively every SOC 2 report. Availability, processing integrity, confidentiality, and privacy are added when they match commitments you make to customers.

Vendors you rely on, called subservice organizations, complicate scope. A cloud-hosted service typically uses the carve-out method: the report notes reliance on, say, a cloud provider’s physical security controls and excludes them from testing, expecting readers to consult that provider’s own SOC report. The report also lists complementary user entity controls, things your customers must do themselves for the system to be secure, such as managing their own user accounts.

A practical scope exercise: list the commitments in your customer contracts and security pages, then trace which systems, teams, and vendors those commitments depend on. That trace is roughly your system description.

What SOC 2 requires

The Trust Services Criteria are organized into five categories:

1. Security, also called the common criteria, covering governance, risk assessment, access controls, change management, system operations, and monitoring. This category anchors every report.
2. Availability: keeping the system operational and recoverable as committed.
3. Processing integrity: complete, accurate, timely, and authorized processing.
4. Confidentiality: protecting information designated as confidential through its lifecycle.
5. Privacy: collecting, using, retaining, and disposing of personal information in line with your commitments.

Unlike PCI DSS, SOC 2 does not hand you a control checklist. The criteria state outcomes, and each is supported by points of focus that suggest what auditors consider. You design controls that fit your environment and demonstrate they meet the criteria. Two companies can hold clean SOC 2 reports with substantially different control sets. The risk assessment criteria (CC3) expect a documented, periodic assessment behind those choices; the free risk assessment tool on this site is one way to produce it.

That flexibility is the standard’s strength and its trap. It accommodates any architecture, but it also means “we have SOC 2” says less than people assume. The substance is in which categories were covered, how the system was scoped, and what the auditor found. Readers who evaluate vendor reports learn to check those three things first.

How compliance is validated

Validation is the examination itself, and the first decision is which report type you need:

• A Type 1 report evaluates whether controls are suitably designed and implemented at a single point in time.
• A Type 2 report also tests whether controls operated effectively over a review period, commonly three to twelve months. Most customers ultimately want Type 2; many organizations do a Type 1 first while their controls accumulate history. The trade-off is time against weight: a Type 1 can be issued as soon as controls are designed and in place, while a Type 2 needs the review period to elapse first, and carries more weight with customers because it shows the controls actually ran.

See SOC 2 Type 1 versus Type 2 for how to confirm which one a customer will accept and how the review period sets the calendar.

The report contains the auditor’s opinion, management’s written assertion, the system description, and, for Type 2, every control tested with the tests and results. Exceptions found during testing appear in the report even when the overall opinion is unqualified (clean). A qualified opinion signals the auditor found problems material to one or more criteria.

SOC 2 reports are restricted-use documents shared with customers and prospects under confidentiality, usually through a portal or a non-disclosure agreement. A SOC 3 report is the general-use summary version some organizations publish openly.

A report covers a fixed period and goes stale. Customers commonly expect a report no older than twelve months, with a bridge letter covering the gap between the report’s end date and today.

Two engagement distinctions worth understanding before you buy anything: a readiness assessment is not the audit (it finds gaps before the auditor does and produces no report a customer will accept), and the consultant who builds your controls should not be the assessor who opines on them (auditor independence rules forbid it, and customers who read reports notice).

The SOC 2 process

A first SOC 2 cycle usually looks like this:

1. Confirm what customers actually need. Report type, categories, and deadline, taken from the contract or the customer’s security team rather than assumed.
2. Scope the system. Define the service, environments, teams, and subservice organizations the description will cover.
3. Run a readiness assessment. Compare current controls against the criteria and list the gaps.
4. Remediate and document. Build missing controls, write the policies behind them, and start generating evidence. Evidence collection tooling, if you use it, earns its keep here.
5. Operate through the review period. For Type 2, controls must run and leave evidence for the full period. A control turned on the week before fieldwork does not have a period to test.
6. Fieldwork and report. The CPA firm tests, resolves questions, and issues the report.
7. Repeat annually. Most organizations move straight into the next review period so coverage stays continuous.

Who decides, and what to ask them

There is no regulator here. The customer or prospect asking for the report decides what counts, and the person who decides is rarely the one who passed along the request. Sales contacts and account managers relay the ask; the customer’s security, procurement, or vendor risk team sets the actual bar. Ask to be connected to that team, and keep the answers:

• Which report type they need, Type 1 or Type 2, and whether a Type 1 now with a Type 2 to follow will satisfy them for this contract.
• Which Trust Services Categories they expect beyond Security.
• How recent the report must be, and whether they accept a bridge letter to cover the gap.
• Whether they will accept something else in the meantime: a completed security questionnaire, a recent penetration test report, or an ISO 27001 certificate.
• Whether the request is a contractual condition, a procurement gate, or a preference. The answer tells you whether the deal waits for the report.
• How they want to receive the report (under NDA, through a portal) and who on their side reviews it.

Different customers answer differently. Collect the answers from the two or three that matter most and scope to the strictest; a report that satisfies your most demanding customer usually satisfies the rest.

The calendar is dominated by remediation and the review period, not by the audit itself. A first Type 1 commonly lands two to four months after readiness starts; a first Type 2 adds the review period on top, so six to twelve months to a report in hand is realistic for most organizations.

Cost, time, and internal effort

The cost range on this page covers examination fees only, for the most common audited path: a Type 2 examination at a typical organization. That definition keeps standards comparable across this site, and it is the number you can check against an auditor’s proposal.

The examination type sets the baseline. A Type 1 commonly runs $7,000 to $40,000 and a typical Type 2 runs $20,000 to $75,000, with organization size, scope, and the audit firm’s tier moving the fee within those ranges. Industry directory data puts the specialist-firm Type 2 median near $33,000; Big Four fees for large enterprises reach six figures and sit above the page’s range.

Everything around the examination is extra, and frequently adds up to more than the audit fee: readiness assessments, remediation work, compliance automation platforms, penetration testing, and staff time.

The page’s cost and effort ranges are directional, not a quote. The strongest predictors:

• Type 1 versus Type 2, and the review period length;
• how many categories beyond Security you include;
• the size and complexity of the system description;
• how much readiness work uncovers; and
• whether evidence collection is automated or manual.

A detailed breakdown with current market figures is in How much does SOC 2 cost?

Maintaining compliance

A SOC 2 report expires in practice, so the program becomes an annual rhythm: operate controls, collect evidence continuously, and re-examine each year with back-to-back review periods.

Between reports, expect to:

• issue bridge letters when a customer’s diligence lands between report dates;
• run the recurring controls your report describes, such as access reviews, vulnerability management, vendor reviews, and incident response exercises;
• keep the system description current as architecture, vendors, and teams change; and
• fold new products or environments into scope deliberately rather than discovering them during fieldwork.

Scope drift is the quiet failure mode. A new subprocessor, an acquired product, or a customer commitment added by the sales team can put your description out of date. Give someone standing ownership of the description and the evidence calendar.

How to get started

If a customer just asked for your SOC 2 report and you do not have one, start here:

1. Get the requirement in writing. Which report type, which categories, and by when. A Type 1 now with a Type 2 to follow satisfies many customers if you ask.
2. Draft the system boundary. One page: the service, environments, key vendors, and teams that would appear in the description.
3. Inventory existing controls and policies. Map what you already do against the five categories before assuming you are starting from zero.
4. Decide your tooling and help. Compliance automation, a readiness consultant, both, or neither. Keep the consultant separate from the assessor.
5. Engage a CPA firm early. Fieldwork calendars fill up, and the firm’s view on scope and review period will shape your plan. Confirm the firm is a licensed CPA firm subject to peer review.

The AICPA SOC suite overview describes the report family, and the Trust Services Criteria document is the actual criteria text.

The first goal is not a perfect control environment. It is knowing which report your customer needs, what system it will describe, and how far your current controls are from the criteria. With those three facts, the rest is a plannable project.