Chapter 28 — Key Takeaways

The re-grounding card for compliance frameworks. Scannable and dense — this is what you reread before a cert exam or an audit. The governing idea, never forget it: compliance is the floor, not the ceiling.

The one-sentence core

Compliance is conforming to rules (law, contract, or adopted standard) and being able to demonstrate it; it is necessary but not sufficient for security — a floor you stand on to build higher, never a ceiling you stop at.

Definitions (first-defined in this chapter)

Term One-line definition
Compliance Conforming to rules — law, contract, or adopted standard — and being able to demonstrate conformance to an authority that can check.
NIST CSF A voluntary, self-assessed framework organizing security outcomes into Functions (Govern, Identify, Protect, Detect, Respond, Recover).
ISO/IEC 27001 An international standard for an Information Security Management System (ISMS); you can be formally certified against it.
SOC 2 An AICPA attestation: a CPA's report on controls against Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, Privacy).
PCI-DSS A contractual standard (card brands) protecting cardholder data within the CDE; prescriptive; validated by SAQ or a QSA.
HIPAA U.S. law; its Security Rule mandates administrative/physical/technical safeguards for electronic PHI; "addressable" ≠ optional.
GDPR EU law on processing the personal data of people in the EU; rights + privacy + "appropriate" security + ~72-hour breach notice.
Control mapping / crosswalk Identifying which controls correspond across frameworks, so one control + one artifact satisfies many obligations.
Audit A formal, independent examination of whether controls meet a defined requirement set; yields findings, an opinion, or a cert decision.
Evidence The records demonstrating a control exists and operates.
Artifact A single concrete piece of evidence (config export, log sample, signed access review, ticket, screenshot).
Scope The defined boundary of people/processes/systems/data to which an obligation applies.
Attestation An independent professional's report and opinion on their examination (e.g., SOC 2) — reader judges for themselves.
Certification A pass/fail credential from an accredited body (e.g., ISO/IEC 27001) — you are certified or not.
Gap assessment A self-run comparison of current controls vs. a framework's requirements, producing shortfalls to fix before a formal audit.

Framework comparison table (memorize this)

Framework Voluntary / Mandatory Kind Who compels it Trigger What "passing" produces Protects
NIST CSF Voluntary Framework You (choice) Adoption Self-assessed maturity rating (Organizes any program)
ISO/IEC 27001 Voluntary Framework/standard You (choice) Adoption Certificate (accredited body) The ISMS / managed program
SOC 2 Voluntary (market-driven) Attestation std. Customers Customer demand CPA's report (Type II = operated over time) Trust criteria for service orgs
PCI-DSS Mandatory (contract) Standard Card brands Handling card data ROC + AOC (QSA) or SAQ Cardholder data (in the CDE)
HIPAA Mandatory (law) Regulation U.S. (HHS OCR) Handling U.S. PHI Lawful handling / avoid penalties Electronic PHI
GDPR Mandatory (law) Regulation EU DPAs EU personal data Lawful processing / avoid fines Personal data of EU subjects

Sector laws to recognize (not detailed as frameworks): GLBA (U.S. financial privacy), SOX (U.S. financial-reporting integrity), FFIEC (U.S. bank exams), state breach-notification laws.

Certification vs. attestation (a common exam trap)

Certification Attestation
Example ISO/IEC 27001 SOC 2
Issued by Accredited certification body CPA firm
Result Pass/fail credential (a certificate) A report describing tests, exceptions, and opinion
Reader's role Sees "certified" Reads the report and judges for themselves
Can it note exceptions and still be useful? No (it's a gate) Yes (it's a documented opinion)

SOC 2 Type I vs. Type II

Type I Type II
Assesses Control design at a point in time Control operating effectiveness over a period (≈6–12 mo)
Proves Controls are suitably designed now Controls actually ran consistently
Enterprises demand Rarely sufficient Usually required
Theme tie-in Existence Effectiveness over time (design without operation proves little)

The crosswalk (the efficiency engine)

  • What it buys: one control + one artifact → satisfies a requirement area in many frameworks. Generate trustworthy evidence once.
  • The expensive asset is the operated-over-time evidence, not the control. The crosswalk is its index.
  • Read the differences between cells — PCI cares about MFA into the CDE; HIPAA's version is addressable; GLBA frames it as protecting customer info. Differences reveal seams.
  • Published crosswalks (e.g., NIST informative references) = starting point, not gospel. They map frameworks; only you can verify your implementation satisfies both.
  • The trap: a fully "✓" crosswalk can describe an insecure control (e.g., phishable MFA). Maps existence, not effectiveness.
Example crosswalk row — one control, six obligations, one artifact:
CONTROL: Phishing-resistant MFA (remote + admin)
EVIDENCE: Conditional Access export + 30-day sign-in log (MFA enforced, no bypass)
  NIST CSF → Protect: Access Control     ISO 27001 → Access control
  SOC 2    → Security (logical access)   PCI-DSS   → strong auth into CDE
  HIPAA    → technical safeguards (addr.) GLBA     → access controls on cust. info

Surviving an audit (the workflow)

1. DEFINE SCOPE   → draw the boundary; PROVE what's out (net diagram + data-flow
                    map + segmentation test). Pull "connected-to/can-affect" IN.
2. MAP REQS       → crosswalk: which of OUR controls covers each requirement?
3. GAP ASSESS     → per requirement: Exists? Artifact proves it? Shows it
                    OPERATED (not just designed)? Each "no" = a GAP.
4. REMEDIATE/FILE → fix gaps (you own them) OR file the artifact.
5. EXTERNAL AUDIT → auditor samples; surprises are few; disclose open items + plan.

Gap vs. finding (the whole strategy): a gap = you found it first (a to-do you own); a finding = the auditor found it (on your record). Convert findings into gaps by getting there first.

Evidence rules: show, don't tell (reach for the artifact, not the explanation); operated beats designed; collect evidence continuously, not at audit time; never fabricate/backdate (unethical, often illegal, and auditors catch it).

Audit-day habits: answer the question asked and stop · show the artifact · disclose real gaps with a remediation plan · never invent precise requirement numbers you're unsure of (name the area).

Scope (the highest-leverage concept)

  • Everything in scope needs evidence; everything out of scope must be provably out.
  • PCI-DSS scope = the CDE = systems that store/process/transmit cardholder data + anything connected to or able to affect them.
  • Scope reduction (segmentation + don't store data you don't need) is a security control, not just a cost saving — it removes the attacker's bridge into the crown jewels.
  • The attacker reads your scope diagram for seams: systems scoped out but still connected. Hunt for those.

Why compliance ≠ security (§28.6 — the five structural limits)

Limit What it means What the attacker does
Frameworks lag the threat Standards codify yesterday's consensus Uses today's technique vs. yesterday's requirement
Checks existence, not effectiveness Audit confirms a control is present Defeats the present-but-weak control (phishable MFA)
Scope is a boundary Out-of-scope = least watched Aims at the systems scoped out
Point-in-time validation drifts Validated at a moment; security is continuous Exploits the lapse between assessment day and any other day
Map is not the territory A clean report represents security Breaches the real system the report only represented

The productive stance: use compliance as the floor and your risk process (Ch.27) as the engine that decides how far above it to build. Compliance answers "what must we do?"; risk answers "what should we do?"; the distance between them is real security.

Common pitfalls (don't do these)

  • Treating ISO 27001 and SOC 2 as interchangeable checkboxes (different instruments; often hold both, reuse evidence).
  • Declaring a system "out of scope" on paper while it stays connected (cut the connection instead).
  • Building controls a month before the window and letting them lapse (the "compliant breach").
  • Accepting a vendor's clean SOC 2 at face value (read scope, criteria, window, exceptions, exclusions).
  • Fabricating/backdating evidence (auditors are trained to catch it; it destroys credibility on everything).
  • Citing exact requirement numbers you're unsure of (name the area; cite numbers only when confident).
  • Mistaking a fully "✓" crosswalk for a secure system.

Framework mapping (this chapter → standards)

  • NIST CSF 2.0: the whole chapter is a tour of Govern/Identify/Protect/Detect/Respond/Recover as an organizing lens.
  • ISO/IEC 27001 / 27002: ISMS (the management system) + the control catalog you select from.
  • PCI-DSS v4.0: CDE scope, scope reduction, prescriptive control areas, QSA/SAQ validation.
  • HIPAA Security Rule: administrative/physical/technical safeguards; required vs. addressable.
  • GDPR: lawful basis, data-subject rights, data minimization, "appropriate measures," ~72-hour breach notice.

Certification exam pointers

  • [Sec+] Match the regulation to its data type: PCI-DSS↔card data, HIPAA↔health data (PHI), GDPR↔EU personal data. Know voluntary vs. mandatory.
  • [Sec+] "Compliance ≠ security" / "compliance is a floor" is a recurring framing — expect a question.
  • [CISSP] Certification (27001) vs. attestation (SOC 2); SOC 2 Type I vs. Type II; ISMS as a managed process.
  • [CISSP] Scope, evidence, gap assessment, and the audit lifecycle; "addressable" in HIPAA.
  • Both: crosswalking / control mapping as the efficiency mechanism across overlapping frameworks.

Project additions (Meridian + bluekit)

  • Program increment: Meridian's compliance mapping — a master crosswalk (controls × obligations: PCI-DSS, GLBA, NIST CSF, SOC 2), a PCI-DSS scope statement (CDE definition + data-flow + segmentation evidence), and a gap assessment whose gaps route into the Chapter 27 risk register.
  • bluekit increment: extended compliance.py with crosswalk(framework_a, framework_b) — returns every control mapped to both frameworks, with each one's requirement area, so one artifact files against both columns. Models the crosswalk as {control_id: {framework: requirement_area}}. (Proves controls are mapped, never that they are good — the risk process decides how much higher to build.)

The thirty-second recap

Sort obligations (voluntary vs. mandatory; framework/standard/regulation). Know the six: NIST CSF (self-assessed outcomes), ISO 27001 (certifiable ISMS), SOC 2 (CPA attestation; Type II), PCI-DSS (card data in the CDE; scope reduction), HIPAA (PHI safeguards; addressable ≠ optional), GDPR (EU personal data; ~72h notice). Crosswalk controls so one artifact does many jobs — but a "✓" proves existence, not effectiveness. Survive audits with scope (provably in/out), evidence/artifacts (operated > designed), and a self-run gap assessment (turn findings into gaps first). And above all: compliance is the floor, not the ceiling — use it for budget and baseline, then build higher with your risk process to defeat the real adversary.