Security & Data-Protection Compliance - Why Frameworks Exist, the Shared Control Set & Choosing HIPAA, SOC 2, ISO 27001, PCI DSS, GDPR or CCPA
Hub: why compliance frameworks exist (law vs contract vs market), the shared control set every framework asks for, and HIPAA vs SOC 2 vs ISO 27001 vs PCI DSS vs GDPR/CCPA (plus HITRUST, FedRAMP 20x, NIST CSF) compared by trigger, assessor, artifact and cadence. Includes a runnable control-mapping matrix and framework triage in Python and TypeScript, and an engineering-guidance, not legal-advice note.
- 1Gist
- 2Maps
- 3Q&A
- 4Sandbox
Voice readout needs Web Speech Synthesis in this browser.
Question ladder
L1
Is HIPAA a certification?
Answer
No. HHS certifies nobody. HIPAA compliance is a documented risk analysis, policies, BAAs and working controls you can show an investigator.
L2
What makes PCI DSS different from HIPAA and GDPR?
Answer
It is a contractual standard from the card brands, enforced through acquiring banks, not a law enforced by a regulator.
L3
Certification vs attestation?
Answer
ISO 27001 ends in a certificate from an accredited body. SOC 2 ends in a CPA firm's opinion report, which is not a certificate.
L4
Which control families show up in nearly every framework?
Answer
Data inventory, encryption and keys, access control, audit logging, retention and deletion, vendor management and incident response, under a risk assessment.
L5
What is a control matrix?
Answer
A list of controls, each with an ID, an owner, an automated test where possible, and every framework requirement it satisfies.
L6
Why is scope reduction the cheapest control?
Answer
Every system that never sees PHI, card data or personal data drops out of most requirements, so tokens and isolation shrink every audit at once.
L7
How do breach clocks differ?
Answer
GDPR 72 hours to the regulator, HIPAA 60 days to individuals, SEC 8-K four business days after materiality, and state laws on their own deadlines.
Failure modes
Skipped data inventory
Without knowing where regulated data lives you under-scope (PHI in a log SaaS with no BAA) or over-scope (the whole fleet in PCI scope because one service touched a PAN).
Compliance as a yearly project
Evidence is rebuilt from memory before each audit, the same exceptions repeat, and the bridge period between reports has no coverage.
Frameworks picked by fashion
A SOC 2 report does not make you HIPAA compliant and an ISO certificate does not satisfy PCI DSS, so a mandatory obligation goes unmet.
Misconceptions
We are HIPAA certified.
There is no HIPAA certification. You can show a risk analysis, policies, BAAs and controls, not a certificate.
Encryption ends the conversation.
Keys stored next to the data, or plaintext copies in caches and logs, defeat it. Frameworks also want access control, logging and retention.
Buying a compliance platform makes us compliant.
Automation collects evidence. It does not design controls, and the auditor's opinion still depends on how the controls operate.
Interviewer traps
Answering which framework is best.
Ask what data the company touches, whose data it is, where those people live and who the buyers are. Applicability comes from those facts.
Treating a policy as a control.
Auditors test the system, and investigators read the policy. A policy that describes controls engineering never built is a finding.
Design scenario
Same prompt for every reader.
Requirements
Hospitals require a BAA and a SOC 2 Type II report before signing; finance wants card payments live this quarter.
Failure assumptions
- Engineers already log full request bodies to a third-party log service.
- No data inventory exists.
- The UK launch adds personal data of UK patients.
Constraints
- Six engineers and no dedicated security team.
- The cloud provider's BAA covers only its HIPAA-eligible services.
Prompt
A telehealth startup sells a scheduling and messaging SaaS to US hospitals, takes card payments for self-pay visits and is about to launch in the UK. Decide which frameworks apply and plan the first year of compliance engineering.
API
Which endpoints and webhooks carry PHI or card data, and how do you keep both out of logs and URLs?
Data
Where do PHI, card data and UK personal data live, and how do tokens and separate stores shrink scope?
Architecture
Which controls do you build once and map to HIPAA, SOC 2, PCI DSS and UK GDPR, and in what order?
Overview
Engineering guidance, not legal advice. This cluster teaches how compliance frameworks shape system design so you can build, explain and defend the right controls. 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.
Compliance frameworks exist because customers, patients and regulators cannot inspect your systems themselves. A framework is a promise in a shared format: "we protect this kind of data with these controls, and someone independent checked." For engineers the good news is that HIPAA, SOC 2, ISO 27001, PCI DSS, GDPR and CCPA ask for mostly the same handful of controls, and they differ mainly in which data is in scope, who forces you to comply, and how you prove it. This hub gives you the landscape, the shared control set, a way to decide which frameworks apply, and the control-mapping habit that lets one piece of engineering satisfy many auditors. The five sibling pages go deep on HIPAA and PHI, SOC 2 and ISO 27001, PCI DSS, GDPR and CCPA privacy engineering, and building compliance into systems.
Not re-taught here (see Elsewhere in the library): envelope encryption and KMS key hierarchies, secrets leakage and audit trails, RBAC/ABAC and policy engines, backups and restore drills, object-storage security, OWASP web security.
Why compliance frameworks exist
Three forces created them, and each explains a different kind of framework:
- Harm to individuals that markets do not price in. A leaked diagnosis or bank account hurts the person, not only the company. Governments respond with laws: HIPAA for US health data, GDPR for anyone in the EU, CCPA/CPRA for California consumers.
- Shared infrastructure risk. One merchant's leaky checkout funds fraud against every card brand. The brands respond with a contractual standard, PCI DSS, pushed down through acquiring banks.
- Trust between companies. A buyer cannot audit 300 SaaS vendors. Vendors buy independent assurance instead: a SOC 2 report or an ISO 27001 certificate, which are voluntary until a customer contract makes them mandatory.
The engineering consequence: frameworks rarely tell you how to build. They define outcomes ("protect ePHI against reasonably anticipated threats", "render PAN unreadable wherever it is stored") and evidence expectations. Your design choices decide how expensive those outcomes are. Shrinking where sensitive data lives is almost always the cheapest control.
Law vs contract vs voluntary, and certification vs attestation vs self-assessment
| Axis | Kinds | What it means for you |
|---|---|---|
| Who forces you | Law (HIPAA, GDPR, CCPA, SOX) | Regulators investigate and fine; no certificate makes you "compliant" |
| Contract (PCI DSS via card brands; FedRAMP via federal procurement; BAAs and DPAs) | Losing compliance costs you the ability to take cards or sell to a customer | |
| Voluntary (SOC 2, ISO 27001, HITRUST) | You choose them to unblock sales; once promised in a contract they become binding | |
| How it is proven | Certification (ISO 27001, HITRUST, FedRAMP) | A certification body issues a certificate with a validity period |
| Attestation (SOC 2, SOC 1) | A licensed CPA firm issues an opinion report on your controls; it is not a certificate | |
| Self-assessment (PCI SAQ, HIPAA risk analysis, GDPR records) | You assess and sign; regulators or acquirers can challenge it later |
"HIPAA certified" and "GDPR certified" are marketing phrases. HHS does not certify anyone, and GDPR Article 42 certification schemes are optional and rare. What exists is a documented risk analysis, policies, contracts and controls you can show an investigator.
One mapped control set, or a separate program per framework?
Prefer
Build controls once and map them
Each control gets an ID, an owner, a test and every framework citation it satisfies.
- Nine controls answered 17 citations for a HIPAA plus SOC 2 company.
- The same nine answered 24 citations for SOC 2, PCI DSS and GDPR.
- Encryption, access reviews and vendor contracts served all five frameworks.
Alternative
Run each framework as its own project
A new evidence hunt and control set for every auditor.
- The same access review is exported and explained again for each audit.
- Adding a framework becomes a new program instead of a gap analysis.
- Controls drift apart, and the strictest requirement is easy to miss.
How a compliance program runs
Diagram 1 condensed: a loop, not a project.
- 1
Inventory data and pick frameworks
Find which regulated data you hold and where, then choose frameworks from that data, your users' locations and your buyers. - 2
Shrink scope and assess risk
Tokenize, isolate or delete regulated data first, then run the documented risk assessment every framework requires. - 3
Map and build controls
Map each control to every framework that cites it and build working technical controls, not only policies. - 4
Collect evidence and pass the audit
Auditors test evidence that controls operated across the period. Exceptions go to a root-cause fix and a re-test. - 5
Monitor continuously
Controls drift between audits, so continuous monitoring feeds back into the next inventory.
The landscape at a glance
| Framework | Applies to | Type | Evidence | Core engineering asks |
|---|---|---|---|---|
| HIPAA (Privacy, Security, Breach Notification Rules) | US covered entities (providers, plans, clearinghouses) and their business associates | Law | Risk analysis, policies, BAAs; OCR investigates | Protect ePHI: access control, audit controls, integrity, transmission security, minimum necessary, 60-day breach notice |
| HITECH (2009, amended 2021) | Same | Law | Same | Made business associates directly liable, created breach notification, raised penalties; 2021 amendment makes OCR consider recognized security practices |
| SOC 2 | Service organizations whose customers need assurance | Voluntary attestation | CPA report: Type I (design at a date) or Type II (operation over a period) | Controls against the Trust Services Criteria: Security plus optional Availability, Confidentiality, Processing Integrity, Privacy |
| ISO/IEC 27001:2022 | Any organization | Voluntary certification | Certificate from an accredited body, 3-year cycle | A risk-driven ISMS plus a Statement of Applicability over 93 Annex A controls |
| PCI DSS v4.0.1 | Anyone who stores, processes or transmits card data, or can affect its security | Contract (card brands) | SAQ self-assessment or QSA Report on Compliance, plus AOC | 12 requirements; scope reduction via tokenization, hosted fields, segmentation |
| GDPR / UK GDPR | Controllers and processors handling personal data of people in the EU/UK (also outside the EU when targeting them) | Law | Records of processing, DPIAs, DPAs, transfer mechanisms | Lawful basis, minimization, data subject rights, security, 72-hour breach notice, transfer rules |
| CCPA / CPRA | For-profit businesses with California consumers above thresholds (revenue over $26,625,000, or 100,000+ consumers/households, or 50%+ revenue from selling/sharing) | Law | Notices, request handling; 2026 regulations add risk assessments and cybersecurity audits | Rights to know, delete, correct, opt out of sale/sharing, limit sensitive PI; honor Global Privacy Control |
| FedRAMP | Cloud services sold to US federal agencies | Contract / procurement law | FedRAMP certification on NIST SP 800-53; 2026 Consolidated Rules with 20x Class B/C, Rev5 closing to new applicants on 2027-06-11 | Continuous monitoring, US-federal-specific controls |
| HITRUST CSF | Mostly health-sector vendors | Voluntary certification | e1, i1 (1-year) or r2 (2-year, risk-based) | Harmonized controls mapped to HIPAA, NIST, ISO and others |
| SOX ITGC (brief) | US public companies | Law (via financial audit) | External auditor tests IT general controls | Access, change management and operations controls over financial systems; vendors supply SOC 1 reports |
You will also hear about NIST CSF 2.0 (voluntary US framework, adds a Govern function), the EU's NIS2 and DORA (sector cybersecurity and financial-sector resilience), and a growing list of US state privacy laws. The control set below covers most of them too.
The shared control set
Read any two frameworks side by side and the same seven control families appear. Build them once, well, and most of each audit becomes evidence collection.
| Control family | What it is | Why every framework wants it | Deep dive |
|---|---|---|---|
| Data classification and inventory | Know what data you hold, where, and how sensitive it is | You cannot scope PCI, find PHI, answer a DSAR or set retention without it | compliance-engineering-classification-audit-logs-retention-evidence |
| Encryption and key management | Encrypt at rest and in transit; control who holds keys | Breach safe harbors (HIPAA unsecured PHI, GDPR Art. 34) and PCI's unreadable PAN depend on it | envelope-encryption-dek-kek-cmk, secrets-kms-envelope-encryption-rotation |
| Access control and least privilege | Unique identities, MFA, role/attribute-based access, periodic reviews | HIPAA minimum necessary, PCI need-to-know, SOC 2 CC6 | abac-attributes-policies-pdp-pep, authorization-for-engineers-rbac-abac-rebac-policy |
| Audit logging | Who did what to which record, tamper-evident, retained | HIPAA audit controls, PCI Requirement 10, SOC 2 CC7, ISO A.8.15 | secrets-threat-model-leakage-audit, observability-triad-metrics-logs-traces |
| Retention and deletion | Keep data only as long as a rule says, then delete verifiably; legal holds override | GDPR storage limitation and erasure, PCI minimal storage, ISO A.8.10 | backups-restore-pitr-immutable-backups, object-storage-security-iam-encryption-threats |
| Vendor management | Contracts (BAA, DPA), due diligence, subprocessor lists, their reports | You stay accountable for data you hand to vendors | |
| Incident response | Detect, contain, assess, notify on the right clock, learn | HIPAA 60 days, GDPR 72 hours, state laws, SEC 8-K four business days | disaster-recovery-multi-region-rto-rpo |
Two families sit underneath all seven: risk assessment (HIPAA risk analysis, ISO clause 6.1.2, PCI targeted risk analyses, GDPR DPIAs) and secure development (change management, code review, vulnerability management; see web-app-security-owasp-injection-xss-csrf-ssrf).
How a compliance program runs
Diagram 1: the loop a company actually runs, from scoping to continuous evidence, with the failure path.
Decisions
- 1
Step 1: inventory data
- nextStep 2: pick frameworks
- 2
Step 2: pick frameworks
- nextStep 3: shrink scope
- 3
Step 3: shrink scope
- nextStep 4: assess risk
- 4
Step 4: assess risk
- nextStep 5: map controls
- 5
Step 5: map controls
- nextStep 6: build controls
- 6
Step 6: build controls
- nextStep 7: collect evidence
- 7
Step 7: collect evidence
- nextStep 8: audit passes?
- ?
Step 8: audit passes?
- nextStep 9: monitor continuously
- nextFailure: exceptions found
- 9
Step 9: monitor continuously
- nextStep 1: inventory data
- 10
Failure: exceptions found
- nextFix root cause, re-test
- 11
Fix root cause, re-test
- nextStep 6: build controls
Lesson map
Security & Data-Protection Compliance - Why Frameworks Exist, the Shared Control Set & Choosing HIPAA, SOC 2, ISO 27001, PCI DSS, GDPR or CCPA
Hub: why compliance frameworks exist (law vs contract vs market), the shared control set every framework asks for, and HIPAA vs SOC 2 vs ISO 27001 vs PCI DSS vs GDPR/CCPA (plus HITRUST, FedRAMP 20x, NIST CSF) compared by trigger, assessor, artifact and cadence. Includes a runnable control-mapping matrix and framework triage in Python and TypeScript, and an engineering-guidance, not legal-advice note.
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: inventory data"] s2["Step 2: pick frameworks"] s3["Step 3: shrink scope"] s4["Step 4: assess risk"] s5["Step 5: map controls"] s6["Step 6: build controls"] s7["Step 7: collect evidence"] s8["Step 8: audit passes?"] s9["Step 9: monitor continuously"] f1["Failure: exceptions found"] f2["Fix root cause, re-test"] 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| s1 s8 -->|continues| f1 f1 -->|continues| f2 f2 -->|continues| s6
Read it as a cycle, not a project. Scope changes every time you add a vendor, a data store or a feature, so step 1 runs again whenever architecture changes. The failure path matters most: an auditor exception should lead to a root-cause fix in the system (a missing pipeline gate, a manual step), not a one-off cleanup that fails again next period.
Control mapping: one control, many frameworks
The single most useful engineering habit in compliance is a control matrix: each control you build gets an ID, an owner, an automated test where possible, and a list of every framework requirement it satisfies. Auditors then sample the same evidence for different criteria, and new frameworks become a gap analysis instead of a new program.
"""Control-mapping matrix: one engineering control, many framework citations.
Concept: frameworks overlap heavily. If you build each control once and tag it
with every requirement it satisfies, one piece of evidence (a log export, an
access review, a key-rotation record) answers several auditors at once.
Citations below are real section/criterion numbers, abbreviated; check the
official text before relying on them for an audit.
"""
from collections import Counter
FRAMEWORKS = ["HIPAA", "SOC2", "ISO27001", "PCI", "GDPR"]
# control id -> (description, {framework: citation})
CONTROLS = {
"ENC-1": ("Encrypt data at rest with KMS-managed keys",
{"HIPAA": "164.312(a)(2)(iv)", "SOC2": "CC6.1", "ISO27001": "A.8.24",
"PCI": "3.5.1", "GDPR": "Art.32(1)(a)"}),
"ENC-2": ("TLS 1.2+ for data in transit",
{"HIPAA": "164.312(e)(1)", "SOC2": "CC6.7", "ISO27001": "A.8.24",
"PCI": "4.2.1", "GDPR": "Art.32(1)(a)"}),
"IAM-1": ("Unique IDs + MFA for workforce access",
{"HIPAA": "164.312(a)(2)(i)", "SOC2": "CC6.1", "ISO27001": "A.8.5",
"PCI": "8.4.2"}),
"IAM-2": ("Periodic access reviews, least privilege",
{"HIPAA": "164.308(a)(4)", "SOC2": "CC6.3", "ISO27001": "A.5.18",
"PCI": "7.2.4", "GDPR": "Art.25(2)"}),
"LOG-1": ("Central audit logging of access to sensitive data",
{"HIPAA": "164.312(b)", "SOC2": "CC7.2", "ISO27001": "A.8.15",
"PCI": "10.2.1"}),
"RET-1": ("Retention schedule + verified deletion",
{"HIPAA": "164.310(d)(2)(i)", "ISO27001": "A.8.10", "PCI": "3.2.1",
"GDPR": "Art.5(1)(e)"}),
"VEN-1": ("Vendor contracts (BAA/DPA) + vendor risk review",
{"HIPAA": "164.308(b)(1)", "SOC2": "CC9.2", "ISO27001": "A.5.19",
"PCI": "12.8.2", "GDPR": "Art.28"}),
"IR-1": ("Incident response plan + breach notification runbook",
{"HIPAA": "164.308(a)(6)", "SOC2": "CC7.4", "ISO27001": "A.5.24",
"PCI": "12.10.1", "GDPR": "Art.33"}),
"RISK-1": ("Annual risk assessment",
{"HIPAA": "164.308(a)(1)(ii)(A)", "SOC2": "CC3.2", "ISO27001": "6.1.2",
"PCI": "12.3.1", "GDPR": "Art.35"}),
}
def matrix() -> None:
# print one row per control, one column per framework
print(f"{'control':8} " + " ".join(f"{f:>18}" for f in FRAMEWORKS))
for cid, (_, refs) in CONTROLS.items():
print(f"{cid:8} " + " ".join(f"{refs.get(f, '-'):>18}" for f in FRAMEWORKS))
def leverage() -> None:
# leverage = how many frameworks one control helps satisfy
ranked = sorted(CONTROLS.items(), key=lambda kv: -len(kv[1][1]))
print("\nleverage (frameworks served per control):")
for cid, (desc, refs) in ranked[:4]:
print(f" {cid:7} {len(refs)}/5 {desc}")
def coverage(in_scope: list[str]) -> None:
# for the frameworks a company actually needs, count controls per framework
c = Counter(f for _, refs in CONTROLS.values() for f in refs if f in in_scope)
total_citations = sum(c.values())
print(f"\nin scope: {in_scope}")
print(f" build {len(CONTROLS)} controls once -> {total_citations} framework citations answered")
for f in in_scope:
print(f" {f:9} {c[f]} of {len(CONTROLS)} controls map here")
if __name__ == "__main__":
matrix()
leverage()
coverage(["HIPAA", "SOC2"]) # health-tech B2B SaaS
coverage(["SOC2", "PCI", "GDPR"]) # EU-facing payments SaaSOutput:
control HIPAA SOC2 ISO27001 PCI GDPR
ENC-1 164.312(a)(2)(iv) CC6.1 A.8.24 3.5.1 Art.32(1)(a)
ENC-2 164.312(e)(1) CC6.7 A.8.24 4.2.1 Art.32(1)(a)
IAM-1 164.312(a)(2)(i) CC6.1 A.8.5 8.4.2 -
IAM-2 164.308(a)(4) CC6.3 A.5.18 7.2.4 Art.25(2)
LOG-1 164.312(b) CC7.2 A.8.15 10.2.1 -
RET-1 164.310(d)(2)(i) - A.8.10 3.2.1 Art.5(1)(e)
VEN-1 164.308(b)(1) CC9.2 A.5.19 12.8.2 Art.28
IR-1 164.308(a)(6) CC7.4 A.5.24 12.10.1 Art.33
RISK-1 164.308(a)(1)(ii)(A) CC3.2 6.1.2 12.3.1 Art.35
leverage (frameworks served per control):
ENC-1 5/5 Encrypt data at rest with KMS-managed keys
ENC-2 5/5 TLS 1.2+ for data in transit
IAM-2 5/5 Periodic access reviews, least privilege
VEN-1 5/5 Vendor contracts (BAA/DPA) + vendor risk review
in scope: ['HIPAA', 'SOC2']
build 9 controls once -> 17 framework citations answered
HIPAA 9 of 9 controls map here
SOC2 8 of 9 controls map here
in scope: ['SOC2', 'PCI', 'GDPR']
build 9 controls once -> 24 framework citations answered
SOC2 8 of 9 controls map here
PCI 9 of 9 controls map here
GDPR 7 of 9 controls map hereWhat the matrix teaches:
- Encryption, access reviews and vendor contracts serve all five frameworks. These are the first controls to make excellent and automated.
- Coverage is uneven at the edges. GDPR has no explicit "audit logging" article, but Article 32 security and Article 5 accountability make logs the practical evidence. PCI's numbers are the most prescriptive.
- The citations differ in strictness. HIPAA's encryption spec is "addressable" today (implement it or document an equivalent alternative); PCI 3.5.1 is mandatory. When frameworks disagree, build to the strictest one that applies to that data.
Which frameworks apply to you?
Applicability comes from four questions: what data do you touch, whose data is it, where are those people, and who are your buyers. The triage below encodes that logic for three typical companies.
// Which compliance frameworks apply to a business? A first-pass triage.
// Concept: some regimes are LAW (you are in scope by what data you touch and
// where your users are), some are CONTRACTUAL (card brands, enterprise customers
// demand them), some are VOLUNTARY (you pick them to win deals). The output also
// says how each is evidenced: certification, attestation or self-assessment.
// Engineering triage only - counsel decides final applicability.
type Kind = "law" | "contract" | "voluntary";
interface Profile {
name: string;
phiForCoveredEntity: boolean; // you create/receive/store PHI for a provider, plan or clearinghouse
isCoveredEntity: boolean; // you ARE a provider/plan/clearinghouse
storesOrHandlesCards: boolean; // card data touches your systems or your payment page
euUkUsers: boolean; // you offer goods/services to, or monitor, people in the EU/UK
californiaThreshold: boolean; // for-profit, CA consumers, and > $26.625M revenue or 100k consumers or 50% revenue from selling/sharing
sellsToEnterprises: boolean; // B2B buyers send security questionnaires
sellsCloudToUsFederal: boolean;
usPublicCompany: boolean;
globalCustomers: boolean; // buyers outside the US ask for ISO certificates
}
interface Hit { framework: string; kind: Kind; evidence: string; why: string }
function triage(p: Profile): Hit[] {
const out: Hit[] = [];
if (p.isCoveredEntity || p.phiForCoveredEntity)
out.push({ framework: "HIPAA + HITECH", kind: "law", evidence: "no official certificate; risk analysis, policies, BAAs",
why: p.isCoveredEntity ? "you are a covered entity" : "you are a business associate (sign BAAs)" });
if (p.storesOrHandlesCards)
out.push({ framework: "PCI DSS v4.0.1", kind: "contract", evidence: "SAQ (self-assessment) or ROC by a QSA, plus AOC",
why: "card brand rules flow down through your acquirer" });
if (p.euUkUsers)
out.push({ framework: "GDPR / UK GDPR", kind: "law", evidence: "no mandatory certificate; RoPA, DPIAs, DPAs, transfer mechanisms",
why: "you target or monitor people in the EU/UK" });
if (p.californiaThreshold)
out.push({ framework: "CCPA/CPRA", kind: "law", evidence: "no certificate; notices, request handling, risk assessments, audits",
why: "California business thresholds met" });
if (p.sellsToEnterprises)
out.push({ framework: "SOC 2 Type II", kind: "voluntary", evidence: "attestation report by a CPA firm",
why: "US enterprise buyers expect it (contractually required once signed)" });
if (p.globalCustomers)
out.push({ framework: "ISO/IEC 27001:2022", kind: "voluntary", evidence: "certificate from an accredited certification body",
why: "non-US buyers and procurement portals ask for it" });
if (p.sellsCloudToUsFederal)
out.push({ framework: "FedRAMP", kind: "contract", evidence: "FedRAMP certification (20x or Rev5) on NIST SP 800-53",
why: "agencies buy only FedRAMP-certified cloud (FedRAMP Authorization Act 2022)" });
if (p.usPublicCompany)
out.push({ framework: "SOX ITGC", kind: "law", evidence: "external auditor tests ITGCs in the financial audit",
why: "systems feeding financial statements" });
if ((p.isCoveredEntity || p.phiForCoveredEntity) && p.sellsToEnterprises)
out.push({ framework: "HITRUST (optional)", kind: "voluntary", evidence: "HITRUST e1/i1/r2 certification",
why: "some health systems ask for it instead of or on top of SOC 2" });
return out;
}
const companies: Profile[] = [
{ name: "Telehealth B2B SaaS", phiForCoveredEntity: true, isCoveredEntity: false, storesOrHandlesCards: false,
euUkUsers: false, californiaThreshold: false, sellsToEnterprises: true, sellsCloudToUsFederal: false, usPublicCompany: false, globalCustomers: false },
{ name: "EU e-commerce store", phiForCoveredEntity: false, isCoveredEntity: false, storesOrHandlesCards: true,
euUkUsers: true, californiaThreshold: false, sellsToEnterprises: false, sellsCloudToUsFederal: false, usPublicCompany: false, globalCustomers: false },
{ name: "Global dev-tools SaaS", phiForCoveredEntity: false, isCoveredEntity: false, storesOrHandlesCards: false,
euUkUsers: true, californiaThreshold: true, sellsToEnterprises: true, sellsCloudToUsFederal: true, usPublicCompany: true, globalCustomers: true },
];
for (const c of companies) {
console.log(`== ${c.name}`);
for (const h of triage(c))
console.log(` ${h.framework.padEnd(20)} ${h.kind.padEnd(9)} ${h.evidence} [${h.why}]`);
}Output:
== Telehealth B2B SaaS
HIPAA + HITECH law no official certificate; risk analysis, policies, BAAs [you are a business associate (sign BAAs)]
SOC 2 Type II voluntary attestation report by a CPA firm [US enterprise buyers expect it (contractually required once signed)]
HITRUST (optional) voluntary HITRUST e1/i1/r2 certification [some health systems ask for it instead of or on top of SOC 2]
== EU e-commerce store
PCI DSS v4.0.1 contract SAQ (self-assessment) or ROC by a QSA, plus AOC [card brand rules flow down through your acquirer]
GDPR / UK GDPR law no mandatory certificate; RoPA, DPIAs, DPAs, transfer mechanisms [you target or monitor people in the EU/UK]
== Global dev-tools SaaS
GDPR / UK GDPR law no mandatory certificate; RoPA, DPIAs, DPAs, transfer mechanisms [you target or monitor people in the EU/UK]
CCPA/CPRA law no certificate; notices, request handling, risk assessments, audits [California business thresholds met]
SOC 2 Type II voluntary attestation report by a CPA firm [US enterprise buyers expect it (contractually required once signed)]
ISO/IEC 27001:2022 voluntary certificate from an accredited certification body [non-US buyers and procurement portals ask for it]
FedRAMP contract FedRAMP certification (20x or Rev5) on NIST SP 800-53 [agencies buy only FedRAMP-certified cloud (FedRAMP Authorization Act 2022)]
SOX ITGC law external auditor tests ITGCs in the financial audit [systems feeding financial statements]Expected== Telehealth B2B SaaS HIPAA + HITECH law no official certificate; risk analysis, policies, BAAs [you are a business associate (sign BAAs)] SOC 2 Type II voluntary attestation report by a CPA firm [US enterprise buyers expect it (contractually required once signed)] HITRUST (optional) voluntary HITRUST e1/i1/r2 certification [some health systems ask for it instead of or on top of SOC 2] == EU e-commerce store PCI DSS v4.0.1 contract SAQ (self-assessment) or ROC by a QSA, plus AOC [card brand rules flow down through your acquirer] GDPR / UK GDPR law no mandatory certificate; RoPA, DPIAs, DPAs, transfer mechanisms [you target or monitor people in the EU/UK] == Global dev-tools SaaS GDPR / UK GDPR law no mandatory certificate; RoPA, DPIAs, DPAs, transfer mechanisms [you target or monitor people in the EU/UK] CCPA/CPRA law no certificate; notices, request handling, risk assessments, audits [California business thresholds met] SOC 2 Type II voluntary attestation report by a CPA firm [US enterprise buyers expect it (contractually required once signed)] ISO/IEC 27001:2022 voluntary certificate from an accredited certification body [non-US buyers and procurement portals ask for it] FedRAMP contract FedRAMP certification (20x or Rev5) on NIST SP 800-53 [agencies buy only FedRAMP-certified cloud (FedRAMP Authorization Act 2022)] SOX ITGC law external auditor tests ITGCs in the financial audit [systems feeding financial statements]
Press Run. Snippets must be self-contained — no network, files, or native modules.
Decision chart: which frameworks apply?
Decisions
- 1
Q1
- nextHIPAA: sign BAAs, run risk analysis
- nextQ2: card data on your systems or page?
- 2
HIPAA: sign BAAs, run risk analysis
- nextQ2: card data on your systems or page?
- ?
Q2: card data on your systems or page?
- nextPCI DSS: shrink scope, pick SAQ or ROC
- nextQ3: users in EU or UK?
- 4
PCI DSS: shrink scope, pick SAQ or ROC
- nextQ3: users in EU or UK?
- ?
Q3: users in EU or UK?
- nextGDPR: lawful basis, DPAs, transfers
- nextQ4: California thresholds met?
- 6
GDPR: lawful basis, DPAs, transfers
- nextQ4: California thresholds met?
- ?
Q4: California thresholds met?
- nextCCPA/CPRA: notices, opt-outs, requests
- nextQ5: selling B2B to enterprises?
- 8
CCPA/CPRA: notices, opt-outs, requests
- nextQ5: selling B2B to enterprises?
- ?
Q5: selling B2B to enterprises?
- nextSOC 2 Type II
- nextISO 27001, often plus SOC 2
- nextFedRAMP
- 10
SOC 2 Type II
- 11
ISO 27001, often plus SOC 2
- 12
FedRAMP
Comparing the approaches you will be asked about
SOC 2 vs ISO 27001. SOC 2 is a detailed report a buyer's security team reads; ISO 27001 is a certificate procurement teams can tick. SOC 2 dominates US SaaS sales; ISO 27001 dominates Europe and Asia. Many companies do both from one control set. The soc2-iso27001-trust-services-criteria-type1-type2-isms page compares them in depth.
Compliance-first vs security-first. Building only what the auditor samples produces "paper compliance": controls that pass a Type II test but would not stop an attacker. Building security first and mapping it to frameworks costs a little more documentation but survives real incidents. Every large breach in the enforcement record (Anthem, Premera, the 2026 ransomware settlements) involved a missing basic control such as an enterprise-wide risk analysis, not an exotic attack.
Centralize sensitive data vs spread it. Keeping PHI, PAN or EU personal data in a few well-guarded services (with tokens or pseudonymous IDs everywhere else) shrinks every audit. Letting it spread to logs, analytics and LLM prompts means every one of those systems inherits every requirement.
What happens if you choose otherwise
- Treat compliance as a yearly project: evidence is reconstructed from memory, exceptions repeat, and the bridge period between reports is uncovered.
- Skip the data inventory: you under-scope (PHI in a log SaaS with no BAA) or over-scope (whole fleet in PCI scope because one service touched PAN).
- Pick frameworks by fashion: a SOC 2 does not make you HIPAA compliant, and an ISO certificate does not satisfy PCI.
- Buy a compliance tool and stop there: automation collects evidence; it does not design controls or make an auditor's opinion clean.
Pitfalls
- Saying "HIPAA certified" or "GDPR certified" in sales material.
- Assuming encryption alone ends the conversation: keys stored next to data, or plaintext copies in caches and logs, defeat it.
- Forgetting vendors: your log, email, support and analytics tools often receive the most sensitive data.
- Writing policies that describe controls engineering never built; auditors test the system, and investigators read the policy.
How the code was checked
- The control-mapping matrix ran under Python 3.13 and the framework triage under
tsc --strictand Node 20. Their output blocks are the real captured output. - Framework citations in the matrix are abbreviated section and criterion numbers; check the official text before relying on them in an audit.
The cluster map
- HIPAA & PHI - Covered Entities, Business Associates, BAAs, Security Rule Safeguards, Breach Notification & De-identification: what counts as PHI, covered entities vs business associates, BAAs for cloud and AI vendors, minimum necessary, required vs addressable safeguards, the 60-day breach clock, Safe Harbor vs Expert Determination, and a runnable de-identifier and PHI-safe logger.
- SOC 2 & ISO 27001 - Trust Services Criteria, Type I vs Type II, ISMS, Annex A, Statement of Applicability & Which to Choose: the Trust Services Criteria, Type I vs Type II, CUECs, carve-outs and bridge letters, the ISO 27001 ISMS with 93 Annex A controls and the Statement of Applicability, and a runnable Type II sampling simulation.
- PCI DSS v4.0.1 - Cardholder Data, CDE Scoping, Segmentation, Tokenization, SAQ Types & Payment Page Scripts: cardholder data vs SAD, CDE scoping and segmentation, tokenization vs encryption vs hosted fields, SAQ A vs A-EP vs D, payment page script controls, and a runnable token vault and scope calculator.
- GDPR & CCPA Privacy Engineering - Lawful Bases, DSARs, Erasure in Practice, Data Transfers, DPIAs & Consent: controller vs processor, lawful bases, DSAR deadlines, erasure in backups, event logs and warehouses, crypto-shredding, EU-US transfers, DPIAs, consent and Global Privacy Control, and GDPR vs CCPA/CPRA.
- Engineering Compliance into Systems - Data Classification, Audit Logs, Retention, JIT Access, Policy-as-Code & Continuous Evidence: data classification tags, key ownership, hash-chained WORM audit logs, retention with legal hold, JIT access, policy-as-code gates, continuous evidence tools, vendor risk and the multi-clock breach runbook.
Interview Q&A
Why do compliance frameworks exist, from an engineer's point of view?
Answer
They turn "trust us" into a checkable promise. Laws protect individuals from harm the market does not price in, card brands protect shared payment infrastructure through contracts, and voluntary standards let one vendor prove its security to many buyers. For engineers they define outcomes and evidence, not implementations.
What is the difference between a law, a contractual standard and a voluntary framework? Give one example of each.
Answer
HIPAA and GDPR are laws enforced by regulators with fines. PCI DSS is contractual: card brands impose it through acquirers, and losing it costs you card acceptance. SOC 2 and ISO 27001 are voluntary, chosen to win deals, but binding once promised in a contract.
Certification vs attestation vs self-assessment?
Answer
ISO 27001 gives a certificate from an accredited body. SOC 2 is an attestation, a CPA firm's opinion report, not a certificate. PCI SAQs and HIPAA risk analyses are self-assessments you sign and must be able to defend.
Name the controls that show up in nearly every framework.
Answer
Data classification and inventory, encryption and key management, access control with least privilege and reviews, audit logging, retention and deletion, vendor management, and incident response, all driven by a risk assessment.
What is control mapping and why does it save money?
Answer
Each control gets an ID and a list of every requirement it satisfies across frameworks. One access-review export then answers SOC 2 CC6, ISO A.5.18, PCI 7.2.4 and HIPAA 164.308(a)(4), and adding a new framework becomes a gap analysis instead of a new program.
A health-tech startup sells to hospitals. Which frameworks apply?
Answer
It is a HIPAA business associate, so BAAs, a risk analysis and Security Rule safeguards are legal obligations. Hospitals will also ask for SOC 2 Type II, sometimes HITRUST. If it takes card payments or has EU users, PCI or GDPR apply too.
Does a SOC 2 report make a company HIPAA compliant?
Answer
No. SOC 2 tests controls against the Trust Services Criteria. It can include HIPAA-mapped criteria (sometimes called SOC 2+), but HIPAA compliance also needs BAAs, a HIPAA risk analysis, Privacy Rule processes and breach notification procedures.
What is the cheapest compliance control?
Answer
Scope reduction: keep sensitive data in as few systems as possible. Hosted payment fields shrink PCI scope, tokens and pseudonymous IDs keep PHI and personal data out of analytics and logs, and every system that never sees the data drops out of most requirements.
What does "paper compliance" mean, and how do you avoid it?
Answer
Controls that exist in policy or pass a sampled test but would not stop an attacker. Avoid it by designing for real threats first, automating controls and their evidence, and testing full populations rather than relying on an auditor's sample.
How do breach notification clocks differ across regimes?
Answer
GDPR: notify the supervisory authority within 72 hours of becoming aware, where feasible. HIPAA: notify individuals without unreasonable delay and within 60 calendar days of discovery, plus HHS and sometimes media. US states set their own deadlines, and SEC-registered public companies file an 8-K within four business days of deciding an incident is material.
Check yourself
Pick a product you know and write its control matrix for the five frameworks in the Python snippet. Mark which controls you already have evidence for from systems (pipeline logs, IdP exports) and which rely on screenshots or memory.
Elsewhere in the library
These pages stay as they are. This lesson only points at them: Envelope Encryption — DEK, KEK & CMK Hierarchy, Secrets & KMS — Envelope Encryption, Rotation & Blast Radius, Secrets Threat Model — Leakage Paths, Side Channels & Audit Trails, ABAC — Attributes, Policies, PDP & PEP, Backups That Actually Restore - Snapshots, PITR, Immutable Copies & Restore Drills, Security — IAM, Encryption, Public Buckets & Threat Model, Authorization — RBAC, ABAC, ReBAC & Policy Engines, Web Application Security - OWASP Top 10, Injection, XSS, CSRF & SSRF, Disaster Recovery & Multi-Region - RTO/RPO, Backups, Pilot Light to Active-Active, Observability Triad — Metrics, Logs & Distributed Tracing.
Go Deeper
- HHS: HIPAA for Professionals
- AICPA & CIMA: SOC 2 - SOC for Service Organizations: Trust Services Criteria
- ISO: ISO/IEC 27001:2022 Information security management systems
- PCI Security Standards Council: PCI DSS
- GDPR full text (gdpr-info.eu)
- California Attorney General: CCPA
- NIST Cybersecurity Framework
- NIST SP 800-53 Rev. 5 security and privacy controls (FedRAMP baseline source)