Chapter 61 — Compliance and assurance without theater

In one sentence

Compliance frameworks (SOC 2, ISO 27001, PCI-DSS, HIPAA) are a lagging, point-in-time snapshot of a subset of your controls, so the right way to satisfy them is to build the actual program from Parts 1-9 first and map its real artifacts onto each framework's control language as evidence — not to build a separate, parallel "compliance" effort aimed only at passing the audit.

Where we are

Everything in this guide — threat models (Part 1 Ch 4), access reviews (Part 7 Ch 49), vulnerability management (Ch 59), detection coverage (Part 8) — happens to be exactly what auditors ask for. This chapter is how to make that mapping deliberate instead of accidental, and how to recognise "compliance theater" for what it is.

How it works

The major frameworks, and what each actually is:

   SOC 2      an AUDIT (not a certification) against the AICPA's Trust
     Services Criteria: Security (mandatory), and optionally
     Availability, Confidentiality, Processing Integrity, Privacy.
     TYPE I: are controls DESIGNED appropriately, at a point in time.
     TYPE II: were controls OPERATING EFFECTIVELY over a period (typically
       6-12 months) -- the version customers actually want to see, because
       it demonstrates sustained practice, not just a good policy
       document.
     Extremely common as a B2B SaaS sales requirement -- often the FIRST
     framework a growing company pursues, driven by customer procurement
     requirements rather than direct regulation.

   ISO/IEC 27001   an actual CERTIFICATION (via an accredited certification
     body) of an ISMS (Information Security Management System) -- not
     just a set of controls, but a MANAGEMENT SYSTEM following a
     Plan-Do-Check-Act continuous-improvement cycle. Annex A lists the
     specific control set; the certification body audits BOTH the
     controls and the management-system process around them (risk
     assessment, management review, internal audit, corrective action).
     ISO/IEC 27701 extends it specifically for PRIVACY (Part 7's domain),
     recognisable to anyone who's built that Part's data-protection
     program.

   NIST CYBERSECURITY FRAMEWORK (CSF)   not a certification -- a
     voluntary, widely-adopted STRUCTURE for organising and
     self-assessing a security program around six functions (CSF 2.0):
     GOVERN, Identify, Protect, Detect, Respond, Recover. Extremely useful
     as a COMMUNICATION TOOL (Ch 62) even for organisations pursuing
     SOC 2/ISO 27001 as their formal compliance target, because its
     function names map intuitively onto conversations with
     non-technical stakeholders.

   PCI-DSS (recap, G1 Ch 43)   mandatory if you handle payment card data;
     SAQ (Self-Assessment Questionnaire) type or a full QSA-led assessment
     depending on transaction volume and how you handle cards (Part 7
     Ch 43's tokenization discussion directly determines which SAQ tier
     applies).

   HIPAA (US health data)   the Security Rule (administrative, physical,
     and technical safeguards -- this guide's Parts 2-8 cover the
     technical safeguards in depth), the Privacy Rule, and the Breach
     Notification Rule, plus Business Associate Agreements with any
     vendor/processor touching Protected Health Information -- directly
     analogous to Part 7 Ch 47's Data Processing Agreements, applied to a
     specific US regulatory context.

   FEDRAMP (US federal cloud)   a heavy, formal authorisation process for
     cloud services selling to US federal agencies -- StateRAMP mirrors
     it for US state/local government. Substantially more demanding than
     SOC 2/ISO 27001 in documentation and continuous-monitoring
     requirements; only pursue if your actual customer base requires it.

"Compliance != security" — the theater to recognise and avoid:

   An audit SAMPLES evidence over a defined period; it does not pentest
   your systems, does not verify every control operated correctly on
   every day of the audit period, and does not catch a control that
   looks correct on paper but is trivially bypassed in practice. A
   security program that optimises for PASSING THE AUDIT rather than
   REDUCING ACTUAL RISK can, and does, pass audits while carrying real,
   substantial gaps -- this is "compliance theater": doing the minimum
   documented activity required to satisfy a control's LANGUAGE without
   addressing the risk the control was meant to manage.
   THE TELL: if a control's evidence is generated ONLY because the audit
   is approaching (a frantic pre-audit access review that hasn't happened
   since the last audit, a policy document nobody has actually followed
   day-to-day), it's theater. If the SAME evidence is a natural byproduct
   of a control that runs continuously ANYWAY (Part 7 Ch 49's quarterly
   recertification, Part 8's live-validated detection coverage), it's
   real.

The right way round: build the program, then map the evidence:

   Rather than reading a compliance framework's control list and building
   NEW, PARALLEL processes to satisfy each line item, map this guide's
   ALREADY-BUILT artifacts onto the framework's language:

     SOC 2 / ISO 27001 "logical access control" / "access review"
       controls          <-  Part 7 Ch 49's JIT access + quarterly
                             recertification (ALREADY produces exactly
                             the evidence an auditor wants: who has
                             access, when it was last reviewed, what was
                             revoked).
     "vulnerability management" controls
                          <-  Ch 59's prioritised backlog, SLA tracking,
                             and risk-acceptance records.
     "incident response" controls
                          <-  Ch 55/G1 Ch 51's IR lifecycle, PLUS the
                             actual tabletop/drill records (G1 Ch 51's
                             practice exercise) as evidence the plan is
                             tested, not just written.
     "security monitoring" / "logging" controls
                          <-  Part 8's telemetry architecture and
                             detection coverage heat map -- an auditor
                             asking "how do you detect security events"
                             gets a genuinely substantive, evidenced
                             answer instead of "we have a SIEM."
     "secure development" controls
                          <-  Ch 58's SDLC gates, with CI pipeline logs
                             as automatic, continuously-generated
                             evidence.
     "data protection" / "privacy" controls (ISO 27701 specifically)
                          <-  the entirety of Part 7.
     "risk assessment" controls
                          <-  Part 1 Ch 4's threat-modeling artifacts,
                             kept live in the repo.

   Built this way, GENUINE security practice generates compliance
   evidence AS A BYPRODUCT, continuously, rather than requiring a
   separate, disconnected "compliance team" effort that scrambles before
   each audit cycle to manufacture evidence for controls nobody actually
   operates day to day.

Continuous compliance tooling and harmonised control mapping:

   Tools like Vanta, Drata, and Secureframe connect directly to your
   cloud accounts, IdP, ticketing system, and CI/CD platform to pull
   evidence CONTINUOUSLY (an access list snapshot, an open-vulnerability
   report, an MFA-enforcement setting) rather than requiring a manual
   evidence-gathering scramble before each audit -- but they still
   REQUIRE the underlying controls to genuinely exist and operate; they
   automate EVIDENCE COLLECTION, not the actual security work.

   Because MANY frameworks ask for essentially the same underlying
   control (a quarterly access review satisfies language in SOC 2, ISO
   27001, and PCI-DSS simultaneously, worded slightly differently in
   each), a HARMONISED CONTROL MAPPING -- build the control ONCE, map its
   evidence to every framework's specific wording -- avoids duplicating
   effort per-framework. Reference mappings exist to start from: the
   Cloud Security Alliance's Cloud Controls Matrix (CCM) and the Secure
   Controls Framework (SCF) both publish free, cross-framework control
   mappings specifically for this purpose.

Worked example

Passing a SOC 2 Type II audit as a byproduct, not a scramble.

   SecureShop pursues SOC 2 Type II (a customer procurement requirement,
   the common driver). Rather than starting from the AICPA's Trust
   Services Criteria and building new processes for each line item, the
   security lead maps EXISTING artifacts:

     CC6.1 (logical access controls)    -> Part 7 Ch 49's JIT + quarterly
       recertification records -- already six months of continuous
       evidence by the time the audit period starts, because the process
       has been running since Part 7's hands-on build, not started for
       the audit.
     CC7.2 (security monitoring)         -> Part 8's detection coverage
       heat map + the live-validation dates on each rule -- an auditor
       reviewing this sees genuinely operating monitoring, not a SIEM
       license purchase.
     CC7.3 (incident response)           -> the tabletop exercise records
       (G1 Ch 51) plus the real (or simulated) incident write-up from
       Ch 55's worked example -- evidence the IR plan has actually been
       exercised, not just documented.
     CC8.1 (change management)           -> Part 3's CI/CD pipeline gates
       and required-review branch protection settings -- automatically
       and continuously evidenced by the pipeline's own audit log.

   RESULT: when the auditor requests evidence, most of it already EXISTS,
   dated across the full audit period, because it's a natural output of
   controls that were built to actually work (this guide's Parts 1-8),
   not manufactured retroactively. The audit takes weeks of evidence
   COLLATION, not months of scrambling to invent processes that don't
   normally run. The one gap the audit DOES surface -- a documented
   vendor-security-review process for new SaaS tools (Part 7 Ch 47's
   sub-processor tracking existed for DATA PROCESSING but hadn't been
   formalised as a general vendor-onboarding gate) -- becomes a genuine,
   useful finding that improves the actual program, which is what a good
   audit should produce even when it "passes."

Practice (60 min)

Pick one compliance framework relevant to your context (SOC 2 is a reasonable default even if hypothetical). Pull its control list (SOC 2's Trust Services Criteria are publicly summarised in many places) and map at least 8 of its controls to specific artifacts you've already built in this guide's earlier Parts.
For each mapping, honestly assess: is this "real" (a continuously-operating control that would produce evidence at any random point in time) or "theater" (something you'd have to hastily construct only because an audit is coming)?
Identify one genuine gap this exercise surfaces — a control the framework expects that you haven't actually built yet — and add it to your Ch 59-style backlog with an owner and a target date.
Research the CSA Cloud Controls Matrix or the Secure Controls Framework; find one control that maps to three or more frameworks simultaneously and note how building it once would satisfy all three.
If you have access to a continuous-compliance tool (or its public documentation), review what it actually automates (evidence pulling) versus what it still requires you to build yourself (the underlying control).

Common mistakes

Building a separate "compliance program" parallel to the real security program. Doubles the work and produces controls that exist only for the audit rather than genuinely operating.
Treating "we passed the audit" as equivalent to "we are secure." An audit samples evidence over a defined scope and period; it is not a pentest and does not verify every control on every day.
Frantic pre-audit evidence generation. The clearest sign of theater — real controls produce evidence continuously, not on a scramble timed to the audit calendar.
Chasing every framework's control list independently instead of using a harmonised mapping. Wastes effort rebuilding essentially the same control (e.g. access review) multiple times under different names.
Continuous-compliance tooling mistaken for the security program itself. It automates evidence collection; the underlying control still has to genuinely exist and operate.
Pursuing a heavier framework (FedRAMP) than your actual customer base requires. A substantial, ongoing cost that should be driven by real business need, not aspiration.

Check yourself

What's the difference between SOC 2 Type I and Type II, and why do customers generally prefer Type II?
What does ISO 27001 certify that SOC 2 doesn't (hint: it's about the system, not just the controls)?
What is "compliance theater" and what's the practical tell that distinguishes it from a genuinely operating control?
Describe the "build the program, then map the evidence" approach and why it's more efficient than building compliance processes framework-by- framework.
What do continuous-compliance tools (Vanta, Drata, etc.) actually automate, and what do they not replace?
Give an example of one control that satisfies multiple frameworks simultaneously, and name a resource for finding such mappings.