What SOC 2 Compliance Is
SOC 2 compliance means an independent CPA firm has examined your controls against the AICPA Trust Services Criteria and issued a report on them. Security is mandatory in every SOC 2 report. Availability, Processing Integrity, Confidentiality and Privacy are optional, and included only if you scope them in.
Three clarifications that save a lot of confusion later:
It is a report, not a certificate. There is no accreditation body and nothing to display. What you send a customer is a document, usually under NDA.
"SOC II" is a misspelling. The reports are SOC 1, SOC 2 and SOC 3, in Arabic numerals. The Roman numeral creeps in from Type I and Type II, which is a different axis entirely.
You cannot be audited by whoever prepared you. Independence is a requirement of the attestation standard, so readiness and the audit always come from two separate organizations. Any provider offering to take you "end to end through certification" is describing something that is not a SOC 2 report.
Who Needs SOC 2
Formally: any service organization holding or processing customer data where that customer needs assurance about the controls around it.
Practically: SOC 2 is procurement-driven. Almost nobody starts one because they read about it. They start because an enterprise deal is contingent on producing a report, and the security questionnaire arrived with a deadline attached.
There are three moments that trigger it: the first enterprise deal that reaches legal review, a vendor security questionnaire you cannot answer, and a renewal where the customer has since built a vendor-risk function. If none of those has happened yet, you are early — and being early is the cheapest time to start, because you can open the observation window before anyone is waiting on the report.
That matters for how you scope. If the trigger is one customer, ask which criteria they require before scoping in all five — every optional criterion is more controls, more evidence and a longer audit.
| If you are… | Typical trigger | Usual scope |
|---|---|---|
| B2B SaaS selling upmarket | An enterprise security review | Security, sometimes Availability |
| Data processor or analytics vendor | Customer contract clause | Security, Confidentiality |
| Payments or billing platform | Customer's auditors | Often SOC 1 as well — see SOC 1 |
| Healthcare-adjacent SaaS | A BAA plus a security review | Security, Confidentiality, often HIPAA alongside |
The Five Trust Services Criteria, and What Each Requires
This is the requirements question, answered by criterion. For each one in scope you need a documented policy, the control operating in practice, and evidence it operated — across the full window if you are doing a Type 2.
| Criterion | Mandatory | What it requires of you |
|---|---|---|
| Security (CC1–CC9) | Yes | Governance, risk assessment, access control, MFA, change management, logging, incident response, vendor management, continuity |
| Availability | No | Capacity monitoring, tested backups, a recovery plan with RTO and RPO |
| Processing Integrity | No | Input validation, error handling, output reconciliation |
| Confidentiality | No | Data classification, retention periods, evidenced secure disposal |
| Privacy | No | Privacy notice, consent capture, data subject request handling |
The nine Common Criteria carry most of the weight. CC6 alone — logical and physical access — is where the majority of findings originate, and multi-factor authentication on production is the single most commonly failed control in the entire framework.
Which optional criteria to actually scope in
Most guides explain all five and leave you to decide. Decide with this instead — the question is what you contractually owe, not what sounds thorough.
| Criterion | Scope it in when | Leave it out when |
|---|---|---|
| Security | Always — it is mandatory | Never |
| Availability | You sell an uptime SLA, or a customer contract names one | Delivery is batch or asynchronous and no SLA exists |
| Confidentiality | Your contracts define "confidential information" and commit you to protecting it | You handle only data that is already public |
| Processing Integrity | You compute something the customer relies on — money, payroll, billing | You store and return data without transforming it |
| Privacy | You act as a controller of personal information in your own right | You touch personal data only as a processor under a DPA |
Adding a criterion later is cheap. Removing one is not. Widening scope mid-window generally means the new criterion needs its own observation period, so your next report covers the new criterion for a shorter window than the rest. Narrowing scope is worse: a customer who received the earlier report can see what you dropped, and procurement teams do compare year over year. Scope once, deliberately.
For the control-by-control task list, work through the SOC 2 compliance checklist.
The 33 Common Criteria, Mapped to the Config That Satisfies Them
The Security category breaks into 33 common criteria, numbered CC1.1 through CC9.2. For a company running on cloud infrastructure, a large share of them are satisfied by configuration rather than by a policy document — and that is the part almost no SOC 2 guide will show you, because most are published by platforms whose product exists to keep it hidden.
Here is where the work actually lives:
| Family | Covers | Mostly satisfied by |
|---|---|---|
| CC1 · CC2 | Governance, communication | Documents and records — org chart, code of conduct, board minutes |
| CC3 · CC4 · CC5 | Risk assessment, monitoring, control activities | Process — a risk register with named owners and review dates |
| CC6 | Logical and physical access | Configuration — IAM, MFA, network boundaries, encryption |
| CC7 | System operations, monitoring | Configuration — logging, alerting, vulnerability management |
| CC8 | Change management | Configuration — branch protection, CI gates, deploy approvals |
| CC9 | Risk mitigation, vendors | Documents — vendor register, subservice organization reports |
Four worked examples, each with the criterion, the question the auditor will actually ask, and the configuration that answers it.
CC6.1 — Logical access
The auditor asks: how do you enforce multi-factor authentication for everyone with console access? A policy saying "MFA is required" is not an answer. This is:
# Deny every action unless the session is MFA-authenticated.
# The not_actions list is what lets a user without MFA still
# enrol a device — omit it and you lock out your own workforce.
data "aws_iam_policy_document" "require_mfa" {
statement {
sid = "DenyUnlessMfaPresent"
effect = "Deny"
not_actions = [
"iam:ChangePassword",
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:ListMFADevices",
"iam:ResyncMFADevice",
"sts:GetSessionToken",
]
resources = ["*"]
condition {
test = "BoolIfExists"
variable = "aws:MultiFactorAuthPresent"
values = ["false"]
}
}
}CC6.6 — Boundary protection
The auditor asks: show me that management interfaces are not reachable from the open internet. The finding they are looking for is a security group with 0.0.0.0/0 on port 22 or 3389.
resource "aws_security_group" "app" {
name = "app-tier"
vpc_id = aws_vpc.main.id
ingress {
description = "HTTPS from the load balancer only"
from_port = 443
to_port = 443
protocol = "tcp"
security_groups = [aws_security_group.alb.id]
}
# No SSH ingress rule at all. Administrative access goes through
# SSM Session Manager, which is logged — and a logged access path
# is evidence, where a bastion host is one more thing to prove.
}CC7.2 — Monitoring for anomalies
The auditor asks: how do you know your audit logs have not been altered? One line answers it, and it is the line most teams have left at its default:
resource "aws_cloudtrail" "audit" {
name = "org-audit-trail"
s3_bucket_name = aws_s3_bucket.trail.id
is_multi_region_trail = true
include_global_service_events = true
# Writes a signed digest so tampering is detectable. Defaults to
# false. This is the line the auditor is looking for.
enable_log_file_validation = true
}CC8.1 — Change management
The auditor asks: prove that no code reached production without review. They will then sample deploys and trace each one back to an approval.
resource "github_branch_protection" "main" {
repository_id = github_repository.app.node_id
pattern = "main"
required_pull_request_reviews {
required_approving_review_count = 1
dismiss_stale_reviews = true
}
required_status_checks {
strict = true
contexts = ["ci/test", "ci/sast"]
}
# Without this, administrators bypass the rule — and the control
# has a hole exactly where the auditor will sample.
enforce_admins = true
}The caveat that matters more than the config
Configuration proves a control exists. It does not prove the control operated for the whole window. A Type 2 tests the period, not the present state, so the auditor will ask when each of these settings took effect — and your commit history will tell them. Configuration merged three weeks before fieldwork, covering a six-month window, produces an exception no matter how correct it is.
That is the whole argument for a readiness assessment before the window opens rather than after. The cheapest SOC 2 is the one where the controls were already running when the clock started.
Type 1 vs Type 2
| Type 1 | Type 2 | |
|---|---|---|
| Question answered | Are the controls suitably designed? | Did they operate, over time? |
| Period covered | A single date | 3–12 month observation window |
| Time to report | 2–3 months | 6–12 months for a first one |
| What procurement wants | Accepted as an interim | This one |
Under deal pressure, issuing a Type 1 first and following with a Type 2 covering the subsequent window is a legitimate sequence — provided you tell the customer which one they are receiving. It is not a shortcut and it should not be presented as one.
What the Auditor Actually Asks You For
Roughly two weeks into fieldwork, the CPA firm sends a PBC list — "Prepared By Client." It is the request list for every piece of evidence they need, and it is the truest picture of what a SOC 2 involves. Most published guides never show one, because most are written by companies that sit outside the engagement.
A representative list, grouped by criterion:
| Criteria | What they request |
|---|---|
| CC1 · CC2 | Org chart at window start and end, signed code of conduct for a sample of staff, security committee minutes, evidence the security policy was communicated |
| CC3 · CC4 | Risk register with owners and assessment dates, sign-off on the annual risk assessment, internal control monitoring records |
| CC6 | Complete user listing for every in-scope system, joiner/mover/leaver records with effective dates, quarterly access review artefacts, MFA configuration export, encryption settings |
| CC7 | Logging and alerting configuration, sample alerts with response records, vulnerability scan results and remediation dates, incident tickets — including the ones that turned out to be nothing |
| CC8 | Full population of production changes for the window, sampled pull requests with approvals, deployment logs, evidence of testing before release |
| CC9 | Vendor register, current SOC 2 reports for every subservice organization, vendor risk assessments, business continuity test results |
Populations come before samples — and this is where teams lose weeks
The auditor does not test everything. They ask you for a population — every access change in the window, every production deploy — and then pick a sample from it. If the population is wrong, everything built on it is wrong, and you will be asked for it again.
The common failure is a population that does not reconcile to the system of record: a deploy list exported from CI that is missing hotfixes shipped by hand, or a user listing that omits service accounts. Auditors check the reconciliation before they sample. Build the population from the authoritative source the first time.
Why evidence gets rejected
Rejections are rarely about the control being wrong. They are about the artefact failing to prove what it claims:
A screenshot with no date. If the system clock is cropped out, it evidences nothing about when the setting was in place. Capture the full window including the date.
An access review with no reviewer. A spreadsheet of users is not a review. The evidence is who looked, when, what they changed, and the record of that decision.
A ticket closed before it was approved. Timestamps are compared. A change approved after deployment is an exception even when the change itself was fine.
Evidence dated outside the window. A quarterly review run three times in the final month does not cover the first three quarters, and cannot be made to.
A subservice organization with no report. If a vendor in scope cannot produce a current SOC 2, that gap becomes yours, and the fix is procurement, not engineering. Find this at readiness, not at fieldwork.
The Path to a Report
1. Scope. Which criteria, which systems, which entity. Decided by what your customer asked for, not by what sounds impressive.
2. Readiness assessment. Where you stand against every control in scope, with a costed remediation plan. See SOC 2 readiness.
3. Remediation. Closing the gaps. Usually engineering capacity, not policy writing, and usually the longest controllable stage.
4. Observation window (Type 2 only). Your controls run and you collect evidence. Three months is the common first window.
5. Fieldwork. The CPA firm samples, interviews and re-performs. Two to six weeks — see what actually happens in a SOC 2 audit.
6. Report. Issued two to four weeks after fieldwork closes.
| Stage | Typical duration | What it produces | Who does it |
|---|---|---|---|
| Scope | 1–2 weeks | Criteria and system boundary, agreed in writing | You, with an advisor |
| Readiness assessment | 2–4 weeks | Findings register and a costed remediation plan | Avantcert |
| Remediation | 1–3 months | Controls actually running | Your engineers, with us |
| Observation window | 3–12 months | The evidence trail | You, continuously |
| Fieldwork | 2–6 weeks | Tested samples, exceptions raised | The CPA firm |
| Report | 2–4 weeks | The signed opinion | The CPA firm |
Two organizations appear in that table, and they cannot be the same one. Independence is a requirement of the AICPA attestation standards: the firm that designs or remediates your controls is not permitted to issue an opinion on them. We do readiness and remediation; a licensed CPA firm does the audit. A provider offering to take you "end to end through SOC 2 certification" is either describing a referral or describing something that is not a SOC 2 report — and compliance platforms blur this line routinely by bundling an audit-firm introduction into an "audit-ready" claim. Ask any provider which of the two roles they occupy, and expect one answer.
Cost and Timeline
Two invoices from two organizations. Avantcert readiness ranges, already discounted 30–50% below typical market rates:
| Tier | Employees | Avantcert readiness | CPA audit fee | Max duration |
|---|---|---|---|---|
| Startup | 5–50 | from $7,000 | Separate | 90 days |
| Mid-Market | 51–200 | around $16,000 | Separate | 90 days |
| Large Enterprise | 201–500 | up to $25,000 | Separate | 90 days |
There is a third cost, and no one invoices you for it: your own engineering hours. Remediation is usually engineering capacity rather than policy writing, and the observation window then adds a recurring evidence load — access reviews, change records, alert triage — that lands on the same people. For a first Type 2 at mid-market scope, budget somewhere between a quarter and a half of one engineer's time across the window. Teams that miss this are the ones whose window slips, and the slip costs more than either invoice.
Considering ISO 27001 instead or as well? It generally costs less at comparable scope — from $4,000 — and its certificate lasts three years where a SOC 2 report repeats annually. See ISO 27001 vs SOC 2 and ISO 27001 certification cost. Full SOC 2 detail in the cost breakdown.
Get a Scoped SOC 2 Quote
Tell us which criteria your customer asked for and your headcount. Scoped estimate and a roadmap within 24 hours.
Our form could not load. Email your scope and headcount and you'll get the same estimate within 24 hours.
Email your requirements Open the full quote formWhere Companies Go Wrong
In order of what they cost. The expensive mistakes all cluster around the observation window, because it is the one stage you cannot redo without spending it again.
1. Opening the window before the controls are running. The most expensive error available. Evidence starts accruing against controls that are still half-built, the auditor finds exceptions across the early months, and the only real fix is a second window. Everything in the configuration section should be merged and running before the clock starts.
2. Treating evidence as a quarter-end task. A Type 2 samples across the whole period. A quarterly access review performed only in the final quarter produces an exception for the earlier ones, and no amount of tidying afterwards changes that.
3. Scoping in all five criteria. More criteria is not a stronger report, it is a longer and more expensive one. Scope what the customer asked for and no more.
4. No named owner for a control. Controls without a person attached are the ones that silently stop running in month four. The auditor will ask who performs each one; if the answer is a team name, that is usually where the gap is.
5. Discovering a subservice vendor has no report of its own. A critical vendor without a current SOC 2 becomes your gap, and resolving it means changing vendor or carving them out of scope — neither of which is quick. Check the vendor register at readiness.
6. Treating a green dashboard as readiness. Compliance automation shows current state; the auditor examines the period. See passing SOC 2 when you already run a platform.
7. Writing a generic system description. Section III is where procurement checks the report covers the product they are buying. A clean opinion on the wrong scope answers nobody's question.
Everything We Have on SOC 2
Get started: SOC 2 readiness · the compliance checklist · certification services
The audit: what actually happens · Type 2 in detail
Cost and planning: certification cost · SOC 2 for small business · cost calculator
Choosing a partner: SOC 2 compliance companies · already running a platform? · Vanta alternative
Related frameworks: ISO 27001 vs SOC 2 · PCI DSS vs SOC 2 · SOC 1 · the full SOC 2 guide
SOC 2 Compliance FAQs
What is SOC 2 compliance?
SOC 2 compliance means an independent CPA firm has examined your controls against the AICPA Trust Services Criteria and issued a report on them. Security is mandatory in every report; Availability, Processing Integrity, Confidentiality and Privacy are included only if you scope them in. It results in a report, not a certificate.
What are the SOC 2 requirements?
For every criterion in scope you need three things: a documented policy, the control actually operating, and evidence that it operated. For a Type 2 that evidence has to cover the entire observation window, not just the date the auditor asked. The Security criterion alone spans nine Common Criteria, CC1 through CC9.
Is SOC 2 a certification?
No. SOC 2 produces an attestation report from a CPA firm under AICPA standards, not a certificate from an accreditation body. Buyers say "SOC 2 certified" as shorthand, but what you send a customer is a report, and there is nothing to hang on a wall.
Who needs SOC 2 compliance?
Any service organization holding or processing customer data where that customer needs assurance about the controls around it. In practice it is driven by procurement: a B2B SaaS company usually starts SOC 2 because a specific enterprise deal is contingent on producing a report.
How long does SOC 2 compliance take?
A Type 1 takes roughly two to three months end to end. A first Type 2 realistically takes six to twelve months, because readiness and remediation run one to three months, the observation window adds three to twelve, and fieldwork plus the report add another month or two after that.
How much does SOC 2 compliance cost?
Avantcert readiness engagements run from $7,000 for a 5–50 employee company, around $16,000 at 51–200, and up to $25,000 at 201–500 or complex scope. The CPA firm's audit fee is separate and paid directly to them, because the firm that prepares you cannot also audit you.
What is the difference between SOC 2 and SOC II?
Nothing. "SOC II" is a common misspelling of SOC 2, produced by confusing the report number with the Type 1 and Type 2 designations. There is a SOC 1, a SOC 2 and a SOC 3, each written with an Arabic numeral.
Can we use our Terraform as SOC 2 evidence?
Yes, for the controls that are genuinely implemented in infrastructure. Configuration proves a control exists and how it is enforced, which addresses design. It does not by itself prove the control operated for the whole observation window, so a Type 2 also needs the change history showing when that configuration took effect. Configuration merged after the window opened will raise an exception no matter how correct it is.
What is a PBC list in a SOC 2 audit?
PBC stands for "Prepared By Client." It is the evidence request list the CPA firm sends at the start of fieldwork, covering populations, samples, configuration exports and records for every criterion in scope. It usually arrives around two weeks in, and it is the point at which most teams discover which evidence they never collected.
Can the consultant who prepared us also perform the SOC 2 audit?
No. Independence is required under the AICPA attestation standards, so the firm that designs or remediates your controls cannot issue an opinion on them. Readiness and the audit always come from two separate organizations. Any provider offering to take you end to end through SOC 2 is describing a referral, or describing something that is not a SOC 2 report.
Do I need SOC 2 or ISO 27001?
SOC 2 is the North American norm and is usually triggered by a specific customer request. ISO 27001 is the international certification, more often required in Europe, the Middle East and Asia. ISO 27001 is also generally cheaper at comparable scope, starting around $4,000 against $7,000, and its certificate lasts three years where a SOC 2 report is repeated annually.
Official reference: AICPA, SOC 2.
Start with where you actually stand
A readiness assessment tells you the gap, the cost to close it, and the realistic date.