SOC 2 & ISO 27001 - Trust Services Criteria, Type I vs Type II, ISMS, Annex A, Statement of Applicability & Which to Choose
SOC 2 (an AICPA attestation against the Trust Services Criteria, Type I vs Type II, observation windows, CUECs and bridge letters) vs ISO/IEC 27001:2022 (a certifiable ISMS with clauses 4 to 10, 93 Annex A controls, the Statement of Applicability and a surveillance cycle). Covers which to choose by market and how engineers produce evidence, with a runnable Type II sampling simulation and SoA builder.
- 1Gist
- 2Maps
- 3Q&A
- 4Sandbox
Voice readout needs Web Speech Synthesis in this browser.
Question ladder
L1
Which Trust Services category is always in a SOC 2?
Answer
Security, the Common Criteria CC1 to CC9. Availability, Confidentiality, Processing Integrity and Privacy are optional.
L2
What is a CUEC?
Answer
A complementary user entity control: something the customer must do for your controls to work, such as managing its own users' MFA.
L3
Carve-out vs inclusive method?
Answer
Carve-out excludes a subservice organization's controls and points to its own report; inclusive tests them inside yours. Carve-out is the norm for clouds.
L4
Who signs a bridge letter?
Answer
Your management, not the auditor. It gives no independent assurance, so buyers accept it only for a few months.
L5
What is the Statement of Applicability?
Answer
A list of every Annex A control: included or not, why, whether it is implemented, and the justification for any exclusion.
L6
How long is an ISO 27001 certificate valid?
Answer
Three years, with annual surveillance audits and a recertification audit in year three.
L7
Why test the full population yourself?
Answer
Auditor sampling can miss real failures. In the simulation a sample of 25 changes missed two emergency changes that a full check found.
Failure modes
Missing evidence turns into exceptions
A control that ran but left no system record fails sampling, and the exception appears in the report buyers read.
Type II with immature controls
Going straight to a Type II window before controls settle produces a first report full of exceptions.
Coverage gap between reports
When the next audit slips, the bridge letter stretches for months and buyers stall renewals.
Misconceptions
A SOC 2 report is a certificate.
It is a CPA firm's opinion on your controls. ISO 27001 is the certificate.
Type I is enough for enterprise buyers.
It shows controls were designed as of one date, never that they operated. Most enterprise buyers want Type II.
An ISO logo covers the product we are buying.
Only if the certificate's scope includes it. Read the scope statement, not only the logo.
Interviewer traps
Writing policies that promise more than engineering does.
Auditors test against the policy. A two-reviewer promise with one-reviewer practice becomes an exception.
Ignoring the vendor's CUECs in your own review.
The vendor's report may assume you do things you do not, which leaves a gap neither side tests.
Design scenario
Same prompt for every reader.
Requirements
First deals need something within three months; both frameworks should share one control set.
Failure assumptions
- Emergency hotfixes sometimes skip review.
- Quarterly access reviews were missed once.
- Offboarding is a manual checklist.
Constraints
- Fully remote company with no offices.
- Infrastructure runs on one hyperscaler, carved out of scope.
Prompt
A 40-person B2B SaaS is losing US enterprise deals for lack of a SOC 2 report, and a German customer is asking for ISO 27001. Plan the first 12 months of audits and evidence.
API
Which systems export evidence automatically (IdP, CI, ticketing), and which still need manual records?
Data
What populations will the auditor request for the observation window, and how do you test them in full first?
Architecture
How do you sequence Type I, Type II and ISO Stage 1 and Stage 2, and justify Annex A exclusions such as physical controls?
Overview
Engineering guidance, not legal advice. Whether a law applies to your company, and what a contract obliges you to do, is a question for counsel and your auditors. Facts were checked against official sources on 2026-10-08.
SOC 2 and ISO/IEC 27001 are the two voluntary frameworks B2B companies use to prove their security to customers. SOC 2 is an attestation: a licensed CPA firm examines your controls against the AICPA Trust Services Criteria and writes an opinion report, either Type I (are controls designed well as of a date) or Type II (did they operate effectively over a period). ISO 27001 is a certification: an accredited body audits your information security management system (ISMS), a risk-driven management loop, plus a Statement of Applicability covering the 93 Annex A controls of the 2022 edition. This page explains how each audit actually works, what evidence engineers produce, how subservice organizations and bridge letters work, and when to pick one, the other, or both.
Not re-taught here (see Elsewhere in the library): CI/CD and supply-chain controls, RBAC design, secrets and key rotation, DR drills and backups. These are the systems auditors sample; this page is about how they are examined.
SOC 2: what is examined
The examination evaluates controls at a service organization relevant to five categories in the 2017 Trust Services Criteria (with revised points of focus, 2022):
| Category | Required? | What it covers | Typical engineering evidence |
|---|---|---|---|
| Security (the Common Criteria, CC1 to CC9) | Always | Control environment, communication, risk assessment, monitoring, control activities, logical and physical access (CC6), system operations (CC7), change management (CC8), risk mitigation including vendors (CC9) | IdP and MFA config, access reviews, deploy approvals, vulnerability scans, alerting and incident tickets, vendor reviews |
| Availability (A1) | Optional | Capacity, backup, recovery to meet commitments | Capacity monitoring, backup jobs, restore tests, DR exercises |
| Confidentiality (C1) | Optional | Data designated confidential is protected and disposed of | Classification, encryption, deletion at contract end |
| Processing Integrity (PI1) | Optional | Processing is complete, valid, accurate, timely | Input validation, reconciliation jobs, error queues |
| Privacy (P1 to P8) | Optional | Personal information collected, used, retained, disclosed per commitments | Notices, consent, DSAR handling, retention |
Pick optional categories by what customers rely on. A payments processor adds Processing Integrity; an infrastructure SaaS adds Availability; a data platform adds Confidentiality. Adding Privacy is less common because GDPR and CCPA programs usually cover it separately.
Type I vs Type II
| Type I | Type II | |
|---|---|---|
| Question | Are controls suitably designed and implemented as of a date? | Did they operate effectively throughout a period? |
| Period | A single date | Observation window, commonly 3 to 12 months; first reports are often shorter, then annual |
| Testing | Inquiry, inspection of design, walkthroughs | Plus sampling of the full population of control occurrences across the window |
| Who wants it | First-time vendors, to unblock deals quickly | Most enterprise buyers; renewed every year |
What is in the report
Management's assertion, the auditor's opinion (unqualified, qualified, adverse or disclaimer), the system description prepared against the AICPA description criteria (DC 200), and for Type II the tests of controls and results, including every exception and management's response. Two sections engineers should read carefully:
- Complementary user entity controls (CUECs): things the customer must do for the controls to work, such as "customers manage their own users' MFA". Buyers map these to their own controls.
- Subservice organizations: vendors you rely on, such as your cloud provider. With the carve-out method, their controls are excluded and listed as complementary subservice organization controls (CSOCs); customers read the subservice organization's own SOC report. With the inclusive method, the auditor tests the subservice organization's controls inside your report, which needs its cooperation and its own written assertion. Carve-out is the norm for hyperscalers.
A SOC 2 report is restricted-use (customers and prospects under NDA). A SOC 3 is a short general-use version for a website. A SOC 1 is different: it covers controls relevant to customers' financial reporting, which SOX auditors use.
Bridge letters
A Type II period ends; the next report arrives months later. In between, customers ask for a bridge (gap) letter: a statement signed by your management, not the auditor, that no material changes or control failures occurred since the period ended. It provides no independent assurance, so buyers accept it only for a few months.
Selling to US enterprise buyers: SOC 2 Type II or ISO 27001 first?
Prefer
SOC 2 Type II, with a Type I to unblock early deals
A CPA firm's report on controls operating over an observation window.
- US enterprise security teams read the detailed test results.
- A Type I can arrive before the first observation window ends.
- Most evidence carries over to ISO 27001 later.
Alternative
ISO 27001 first
A certificate for a risk-driven management system with a Statement of Applicability.
- Strong in Europe, Asia and public-sector procurement.
- US buyers often still ask for a SOC 2 report.
- Shows less detail about how well each control works.
From readiness to report or certificate
Diagram 1 condensed.
- 1
Define scope and run a gap assessment
Scope decides what the auditor tests; the gap assessment finds missing controls before the auditor does. - 2
Write policies and implement controls
Policies set the expectations; controls such as MFA, change review and access reviews must actually operate. - 3
Type I or Stage 1
A point-in-time design check before you spend a whole observation window. - 4
Observation window and sampling
Controls run for 3 to 12 months while the auditor samples tickets, reviews and logs. - 5
Report or certificate, then renew
Exceptions need remediation; the report or certificate goes to customers and is renewed every year.
ISO 27001: what is certified
ISO/IEC 27001:2022 certifies a management system, not a list of controls. Clauses 4 to 10 require you to define scope and context, get leadership commitment, assess and treat information security risks (6.1.2 and 6.1.3), set objectives, run operations, measure performance with internal audits and management reviews, and improve continually. Annex A lists 93 reference controls in four themes:
| Theme | Count | Examples |
|---|---|---|
| Organizational (5.x) | 37 | 5.15 access control, 5.19 supplier relationships, 5.23 cloud services, 5.24 incident management planning, 5.34 privacy and PII |
| People (6.x) | 8 | 6.3 awareness and training, 6.7 remote working |
| Physical (7.x) | 14 | 7.1 perimeters, 7.4 physical security monitoring |
| Technological (8.x) | 34 | 8.9 configuration management, 8.10 information deletion, 8.12 data leakage prevention, 8.15 logging, 8.16 monitoring, 8.24 cryptography, 8.28 secure coding |
The 2022 revision added 11 new controls, including threat intelligence, cloud services security, ICT readiness for business continuity, configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering and secure coding. The transition period for 2013-edition certificates ended on 2025-10-31, so every valid certificate is now against the 2022 edition (with its 2024 climate-action amendment to clauses 4.1 and 4.2).
The Statement of Applicability (SoA) lists every Annex A control: whether it is included, why (which risk it treats or which obligation requires it), whether it is implemented, and the justification for any exclusion. It is the bridge between your risk register and the certificate.
Certification cycle: Stage 1 (documentation and readiness), Stage 2 (implementation audit), certificate valid for 3 years with annual surveillance audits and a recertification audit in year 3. Nonconformities are major or minor; majors must be closed before certification.
How each audit actually runs
Diagram 1: from readiness to report or certificate, with the failure path.
Decisions
- 1
Step 1: define scope
- nextStep 2: gap assessment
- 2
Step 2: gap assessment
- nextStep 3: write policies
- 3
Step 3: write policies
- nextStep 4: implement controls
- 4
Step 4: implement controls
- nextStep 5: Type I or Stage 1
- 5
Step 5: Type I or Stage 1
- nextStep 6: observation window
- 6
Step 6: observation window
- nextStep 7: auditor samples evidence
- 7
Step 7: auditor samples evidence
- nextStep 8: exceptions found?
- ?
Step 8: exceptions found?
- nextStep 9: report or certificate
- nextFailure: exception or nonconformity
- 9
Step 9: report or certificate
- nextStep 10: renew yearly
- 10
Step 10: renew yearly
- 11
Failure: exception or nonconformity
- nextRoot cause and corrective action
- 12
Root cause and corrective action
- nextStep 6: observation window
Lesson map
SOC 2 & ISO 27001 - Trust Services Criteria, Type I vs Type II, ISMS, Annex A, Statement of Applicability & Which to Choose
SOC 2 (an AICPA attestation against the Trust Services Criteria, Type I vs Type II, observation windows, CUECs and bridge letters) vs ISO/IEC 27001:2022 (a certifiable ISMS with clauses 4 to 10, 93 Annex A controls, the Statement of Applicability and a surveillance cycle). Covers which to choose by market and how engineers produce evidence, with a runnable Type II sampling simulation and SoA builder.
Architecture. Architecture
Select a node to see why it exists, or an edge to see the protocol, direction, effect, and consequence.
Mermaid export
flowchart TB s1["Step 1: define scope"] s2["Step 2: gap assessment"] s3["Step 3: write policies"] s4["Step 4: implement controls"] s5["Step 5: Type I or Stage 1"] s6["Step 6: observation window"] s7["Step 7: auditor samples evidence"] s8["Step 8: exceptions found?"] s9["Step 9: report or certificate"] s10["Step 10: renew yearly"] f1["Failure: exception or nonconformity"] f2["Root cause and corrective action"] s1 -->|continues| s2 s2 -->|continues| s3 s3 -->|continues| s4 s4 -->|continues| s5 s5 -->|continues| s6 s6 -->|continues| s7 s7 -->|continues| s8 s8 -->|continues| s9 s9 -->|continues| s10 s8 -->|continues| f1 f1 -->|continues| f2 f2 -->|continues| s6
For SOC 2, step 6 is the Type II period and step 7 is population-and-sample testing. For ISO 27001, step 5 is Stage 1, steps 6 and 7 are the Stage 2 audit and later surveillance audits, and the failure path is a nonconformity with a corrective action plan.
Runnable: a Type II window in miniature
Concept first: the auditor asks for the population (every production change, every termination, every quarterly review in the window), samples it by control frequency, and reports exceptions. Sampling can miss real failures, which is why mature teams test the full population themselves.
"""SOC 2 Type II in miniature: an observation window, populations, samples, exceptions.
Concept first:
* Type I asks "is the control designed well, as of one date?"
* Type II asks "did it operate effectively for the whole period?" (often 3-12 months).
* The auditor pulls a POPULATION (every change, every new hire, every quarterly
review in the window), tests a SAMPLE, and reports EXCEPTIONS.
* One exception rarely sinks a report; it shows up in the tests-of-controls
section with management's response. Systemic failures can qualify the opinion.
Sample sizes below are typical rules of thumb by control frequency; each CPA
firm sets its own methodology.
"""
import random
from datetime import date, timedelta
random.seed(7)
WINDOW = (date(2026, 1, 1), date(2026, 6, 30)) # 6-month Type II period
TYPICAL_SAMPLE = {"annual": 1, "quarterly": 2, "monthly": 2, "weekly": 5,
"daily": 25, "per_event": 25}
def days(a: date, b: date) -> int:
return (b - a).days + 1
# population 1: production changes (per-event control: peer review + approval before deploy)
changes = []
for i in range(420):
d = WINDOW[0] + timedelta(days=random.randrange(days(*WINDOW)))
approved = not (i in (57, 311)) # two emergency changes skipped approval
changes.append({"id": f"CHG-{i:04d}", "date": d, "approved_before_deploy": approved})
# population 2: quarterly access reviews (two quarters fall inside the window)
reviews = [{"quarter": "2026Q1", "completed": date(2026, 4, 9)},
{"quarter": "2026Q2", "completed": None}] # Q2 review not done by period end
# population 3: terminations (access must be removed within 1 business day per policy)
terms = [{"user": f"u{i}", "left": WINDOW[0] + timedelta(days=15 * i),
"revoked_after_days": 0 if i != 6 else 5} for i in range(1, 12)]
def test(name: str, population: list, freq: str, passes) -> list:
n = min(TYPICAL_SAMPLE[freq], len(population))
# auditors often force-include known high-risk items; here we sample randomly
sample = random.sample(population, n)
exceptions = [x for x in sample if not passes(x)]
print(f"{name:28} population={len(population):4} sample={n:3} exceptions={len(exceptions)}")
return exceptions
print(f"window {WINDOW[0]} .. {WINDOW[1]} ({days(*WINDOW)} days)")
test("change approval (CC8.1)", changes, "per_event", lambda c: c["approved_before_deploy"])
test("access review (CC6.2/6.3)", reviews, "quarterly", lambda r: r["completed"] is not None)
test("termination revoke (CC6.2)", terms, "per_event", lambda t: t["revoked_after_days"] <= 1)
# full-population view: what continuous monitoring would have told you on day 1
missed = [c["id"] for c in changes if not c["approved_before_deploy"]]
print("full-population check of changes ->", missed, "(fix the pipeline gate, don't hope sampling misses it)")
# bridge letter: covers the gap between report period end and today, signed by management
report_end, today = WINDOW[1], date(2026, 10, 8)
print(f"bridge letter needed for {(today - report_end).days} days ({report_end + timedelta(days=1)} .. {today}); "
"it is a management assertion, not auditor assurance")Output:
window 2026-01-01 .. 2026-06-30 (181 days)
change approval (CC8.1) population= 420 sample= 25 exceptions=0
access review (CC6.2/6.3) population= 2 sample= 2 exceptions=1
termination revoke (CC6.2) population= 11 sample= 11 exceptions=1
full-population check of changes -> ['CHG-0057', 'CHG-0311'] (fix the pipeline gate, don't hope sampling misses it)
bridge letter needed for 100 days (2026-07-01 .. 2026-10-08); it is a management assertion, not auditor assuranceWhat it shows: the random sample of 25 changes missed both emergency changes that skipped approval, but a full-population check finds them instantly. A missing Q2 access review and one late termination are classic SOC 2 exceptions. And the 100 days since period end are covered only by a management-signed bridge letter.
Runnable: Statement of Applicability builder
// ISO/IEC 27001:2022 Statement of Applicability (SoA) builder - a small slice.
// Concept: ISO 27001 is risk-driven. You assess risks (clause 6.1.2), choose
// treatments (6.1.3), then compare your chosen controls against ALL 93 Annex A
// controls. The SoA lists every Annex A control with: included or excluded,
// justification, and implementation status. An exclusion with no justification,
// or a risk treated by a control you never implemented, is a classic audit finding.
type Theme = "Organizational" | "People" | "Physical" | "Technological";
interface Control { id: string; name: string; theme: Theme }
interface Risk { id: string; desc: string; treatedBy: string[] }
interface Row { id: string; name: string; included: boolean; why: string; status: string }
const annexSlice: Control[] = [
{ id: "5.7", name: "Threat intelligence", theme: "Organizational" },
{ id: "5.15", name: "Access control", theme: "Organizational" },
{ id: "5.19", name: "Information security in supplier relationships", theme: "Organizational" },
{ id: "5.23", name: "Information security for use of cloud services", theme: "Organizational" },
{ id: "5.24", name: "Information security incident management planning and preparation", theme: "Organizational" },
{ id: "5.34", name: "Privacy and protection of PII", theme: "Organizational" },
{ id: "6.3", name: "Information security awareness, education and training", theme: "People" },
{ id: "7.1", name: "Physical security perimeters", theme: "Physical" },
{ id: "7.4", name: "Physical security monitoring", theme: "Physical" },
{ id: "8.10", name: "Information deletion", theme: "Technological" },
{ id: "8.12", name: "Data leakage prevention", theme: "Technological" },
{ id: "8.15", name: "Logging", theme: "Technological" },
{ id: "8.24", name: "Use of cryptography", theme: "Technological" },
{ id: "8.28", name: "Secure coding", theme: "Technological" },
];
const risks: Risk[] = [
{ id: "R1", desc: "Stolen admin credentials expose customer data", treatedBy: ["5.15", "8.15"] },
{ id: "R2", desc: "Cloud bucket misconfiguration leaks backups", treatedBy: ["5.23", "8.24", "8.12"] },
{ id: "R3", desc: "Customer data kept past contract end", treatedBy: ["8.10", "5.34"] },
{ id: "R4", desc: "Injection bug in API", treatedBy: ["8.28"] },
{ id: "R5", desc: "Vendor breach (log SaaS) exposes PII", treatedBy: ["5.19", "5.24"] },
];
// what engineering has actually shipped, and explicit exclusions with reasons
const implemented = new Set(["5.15", "8.15", "5.23", "8.24", "8.28", "5.19", "5.24", "6.3", "5.34"]);
const exclusions: Record<string, string> = {
"7.1": "fully remote company; no offices or own data centers - inherited from cloud provider (see its ISO certificate / SOC 2)",
"7.4": "", // forgot to justify -> finding
};
function buildSoA(): Row[] {
const needed = new Set(risks.flatMap((r) => r.treatedBy));
return annexSlice.map((c) => {
if (c.id in exclusions) return { id: c.id, name: c.name, included: false, why: exclusions[c.id] || "(missing)", status: "n/a" };
const fromRisk = needed.has(c.id);
const why = fromRisk ? `treats ${risks.filter((r) => r.treatedBy.includes(c.id)).map((r) => r.id).join("+")}` : "baseline good practice";
return { id: c.id, name: c.name, included: true, why, status: implemented.has(c.id) ? "implemented" : "PLANNED" };
});
}
const soa = buildSoA();
for (const r of soa) console.log(`${r.id.padEnd(5)} ${(r.included ? "IN " : "OUT")} ${r.status.padEnd(11)} ${r.name.slice(0, 44).padEnd(44)} ${r.why.slice(0, 60)}`);
const findings = [
...soa.filter((r) => !r.included && r.why === "(missing)").map((r) => `${r.id}: exclusion without justification`),
...soa.filter((r) => r.included && r.status === "PLANNED" && r.why.startsWith("treats")).map((r) => `${r.id}: risk treatment relies on a control not yet implemented (${r.why})`),
];
console.log("\naudit findings:", findings.length ? "\n - " + findings.join("\n - ") : "none");
const byTheme = annexSlice.reduce<Record<string, number>>((m, c) => ((m[c.theme] = (m[c.theme] ?? 0) + 1), m), {});
console.log("slice by theme:", JSON.stringify(byTheme), "| full Annex A 2022: 37 org, 8 people, 14 physical, 34 tech = 93");Output:
5.7 IN PLANNED Threat intelligence baseline good practice
5.15 IN implemented Access control treats R1
5.19 IN implemented Information security in supplier relationshi treats R5
5.23 IN implemented Information security for use of cloud servic treats R2
5.24 IN implemented Information security incident management pla treats R5
5.34 IN implemented Privacy and protection of PII treats R3
6.3 IN implemented Information security awareness, education an baseline good practice
7.1 OUT n/a Physical security perimeters fully remote company; no offices or own data centers - inher
7.4 OUT n/a Physical security monitoring (missing)
8.10 IN PLANNED Information deletion treats R3
8.12 IN PLANNED Data leakage prevention treats R2
8.15 IN implemented Logging treats R1
8.24 IN implemented Use of cryptography treats R2
8.28 IN implemented Secure coding treats R4
audit findings:
- 7.4: exclusion without justification
- 8.10: risk treatment relies on a control not yet implemented (treats R3)
- 8.12: risk treatment relies on a control not yet implemented (treats R2)
slice by theme: {"Organizational":6,"People":1,"Physical":2,"Technological":5} | full Annex A 2022: 37 org, 8 people, 14 physical, 34 tech = 93Expected5.7 IN PLANNED Threat intelligence baseline good practice 5.15 IN implemented Access control treats R1 5.19 IN implemented Information security in supplier relationshi treats R5 5.23 IN implemented Information security for use of cloud servic treats R2 5.24 IN implemented Information security incident management pla treats R5 5.34 IN implemented Privacy and protection of PII treats R3 6.3 IN implemented Information security awareness, education an baseline good practice 7.1 OUT n/a Physical security perimeters fully remote company; no offices or own data centers - inher 7.4 OUT n/a Physical security monitoring (missing) 8.10 IN PLANNED Information deletion treats R3 8.12 IN PLANNED Data leakage prevention treats R2 8.15 IN implemented Logging treats R1 8.24 IN implemented Use of cryptography treats R2 8.28 IN implemented Secure coding treats R4 audit findings: - 7.4: exclusion without justification - 8.10: risk treatment relies on a control not yet implemented (treats R3) - 8.12: risk treatment relies on a control not yet implemented (treats R2) slice by theme: {"Organizational":6,"People":1,"Physical":2,"Technological":5} | full Annex A 2022: 37 org, 8 people, 14 physical, 34 tech = 93
Press Run. Snippets must be self-contained — no network, files, or native modules.
The findings are exactly what an ISO auditor raises: an exclusion with no justification, and risks whose treatment plan depends on controls not yet implemented. The fix is not a better spreadsheet; it is shipping deletion and DLP, or changing the risk treatment.
SOC 2 vs ISO 27001
| Dimension | SOC 2 | ISO/IEC 27001 |
|---|---|---|
| Nature | Attestation report (CPA opinion) | Certificate (accredited certification body) |
| Basis | AICPA Trust Services Criteria | ISMS requirements (clauses 4 to 10) plus Annex A |
| Output | Long report with system description and test results | Short certificate plus scope statement; the SoA stays internal unless shared |
| What it proves | Specific controls operated over a period (Type II) | A management system that identifies and treats risk, maintained over 3 years |
| Strength | Detail buyers' security teams can read; test results visible | Global recognition; simple procurement checkbox |
| Weakness | US-centric; restricted use; scope can be narrow | Less visibility into how well controls work; certificate scope can be narrow too |
| Typical buyers | US enterprise | Europe, Asia, global procurement, government |
When to pick which. Selling to US mid-market and enterprise: SOC 2 Type II first, usually a Type I to unblock the first deals. Selling globally or to European buyers and public sector: ISO 27001. Many companies end up with both from one control set; most evidence overlaps, so the second framework costs far less than the first. Health-sector buyers may also ask for HITRUST; federal buyers need FedRAMP. Neither SOC 2 nor ISO replaces HIPAA, PCI DSS or GDPR obligations.
Check the scope, not only the logo. A certificate covering "the corporate IT department" or a SOC 2 covering one product says nothing about the service you are buying. Engineers reviewing vendors should read the scope statement, the system description, CUECs, carve-outs and exceptions.
Decision chart: SOC 2, ISO 27001, or both?
Decisions
- 1
Q1
- nextQ2: need it in weeks?
- nextISO 27001 certification
- nextOne control set, SOC 2 plus ISO
- ?
Q2: need it in weeks?
- nextSOC 2 Type I now
- nextSOC 2 Type II, 3 to 6 month window
- 3
ISO 27001 certification
- 4
One control set, SOC 2 plus ISO
- 5
SOC 2 Type I now
- nextSOC 2 Type II, 3 to 6 month window
- 6
SOC 2 Type II, 3 to 6 month window
- nextQ3: buyers rely on uptime or data accuracy?
- ?
Q3: buyers rely on uptime or data accuracy?
- nextAdd Availability criteria
- nextAdd Processing Integrity
- nextSecurity criteria only
- 8
Add Availability criteria
- 9
Add Processing Integrity
- 10
Security criteria only
What engineers actually produce as evidence
- Access: IdP exports showing MFA enforced, joiner-mover-leaver tickets with timestamps, quarterly access review records with sign-off, break-glass usage logs.
- Change management: pull requests with review and approval before merge, CI checks, deployment logs tied to tickets, emergency change process with after-the-fact review.
- Operations: alert definitions, incident tickets and postmortems, vulnerability scan results and remediation SLAs, backup job history and restore test records.
- Vendors: inventory of subprocessors, their SOC reports reviewed yearly, contracts with security terms.
Evidence that is produced by the system (pipeline logs, IdP exports, policy-gate results) is far stronger and cheaper than screenshots. See the compliance-engineering-classification-audit-logs-retention-evidence page for continuous evidence.
What happens if you choose otherwise
- Go straight to Type II with immature controls: the first report lists many exceptions, which buyers read.
- Rely on Type I for years: buyers learn your controls were designed, never that they operated.
- Scope ISO to a tiny unit to pass faster: the certificate is real but useless in sales once buyers read the scope.
- Choose the inclusive method for your cloud provider: you need its cooperation and assertion; carve-out is standard and simpler.
Pitfalls
- Policies that promise more than engineering does ("all changes are reviewed by two engineers").
- Manual controls with no system record; if it is not logged, it did not happen in an auditor's eyes.
- Forgetting CUECs in your own vendor reviews; your vendor's report may assume you do things you do not.
- Letting bridge letters stretch for months because the next audit slipped.
How the code was checked
- The Type II sampling simulation ran under Python 3.13 and the Statement of Applicability builder under
tsc --strictand Node 20. Their output blocks are the real captured output. - The populations, risks and control decisions are example data for a small remote company.
Interview Q&A
What is SOC 2 in one sentence?
Answer
An attestation report in which a licensed CPA firm gives an opinion on whether a service organization's controls meet the AICPA Trust Services Criteria, for design at a date (Type I) or operating effectiveness over a period (Type II).
Type I vs Type II?
Answer
Type I tests design as of a single date. Type II tests that controls operated effectively across an observation window, usually 3 to 12 months, by sampling populations of control occurrences. Buyers generally require Type II.
Which Trust Services Criteria are mandatory?
Answer
Only Security, the Common Criteria CC1 to CC9. Availability, Confidentiality, Processing Integrity and Privacy are added when customers rely on them.
Carve-out vs inclusive method for subservice organizations?
Answer
Carve-out excludes the subservice organization's controls and lists the controls you expect it to have; customers read its own report. Inclusive tests its controls within your report and requires its cooperation and assertion. Hyperscalers are almost always carved out.
What is a bridge letter and how much should a buyer trust it?
Answer
A management-signed statement covering the time between the end of the last report period and today, saying nothing material changed. It is not auditor assurance, so it is acceptable only for a short gap.
What are CUECs and why do engineers care?
Answer
Complementary user entity controls are things the customer must do for the vendor's controls to work, such as managing their own users or securing API keys. Engineers integrating a vendor must actually implement them.
What is an ISMS and how is ISO 27001 different from a control checklist?
Answer
An ISMS is a management loop: scope, leadership, risk assessment and treatment, operation, internal audit, management review and improvement. ISO 27001 certifies that loop; Annex A controls are chosen through risk treatment and recorded in the SoA rather than applied blindly.
What is a Statement of Applicability?
Answer
The document listing all 93 Annex A controls with inclusion or exclusion, justification and implementation status. It links risk treatment to controls and is a core audit artifact.
How many Annex A controls are in ISO 27001:2022 and how are they grouped?
Answer
93, in four themes: 37 organizational, 8 people, 14 physical, 34 technological. The 2022 edition added 11 new controls such as configuration management, information deletion, data masking, data leakage prevention and secure coding.
A startup asks whether to do SOC 2 or ISO 27001 first. What do you ask?
Answer
Where its buyers are and what blocks deals. US enterprise security reviews: SOC 2 (Type I quickly, then Type II). Global or European procurement: ISO 27001. Both eventually, from one control set, because the evidence overlaps heavily.
Why might an auditor's sample miss a control failure, and what do you do about it?
Answer
Samples cover a small fraction of the population, so rare failures like emergency changes can slip through. Test the full population yourself with automated checks and fix the process (for example a pipeline gate), so the control cannot fail silently.
Check yourself
List the populations an auditor would request from your team for a six-month window (changes, terminations, access reviews, incidents). For each one, write the query or export that would produce the full population today, and run it.
Elsewhere in the library
These pages stay as they are. This lesson only points at them: CI/CD Pipelines — Stages, Artifacts, Caching & Supply Chain, Supply Chain Security — Signing, SBOMs & OIDC Federation, RBAC — Roles, Permissions & Role Explosion, Secrets & KMS — Envelope Encryption, Rotation & Blast Radius, Backups That Actually Restore - Snapshots, PITR, Immutable Copies & Restore Drills, Region Failover in Practice - Runbooks, DNS/GLB Cutover, Failback & Game Days, Observability Triad — Metrics, Logs & Distributed Tracing.
Go Deeper
- AICPA & CIMA: SOC 2 - SOC for Service Organizations: Trust Services Criteria
- AICPA & CIMA: 2017 Trust Services Criteria (with revised points of focus, 2022)
- AICPA & CIMA: SOC 2 Description Criteria (DC 200, 2022 guidance)
- ISO: ISO/IEC 27001:2022
- ISO: ISO/IEC 27002:2022 (control guidance)
- ISO: ISO/IEC 27001 explained
- NIST Cybersecurity Framework (for mapping)