Appendix E: Compliance Crosswalk

Meridian Regional Bank answers to PCI-DSS, the GLBA Safeguards Rule, SOX, FFIEC examination, state breach-notification laws, a slice of GDPR, and produces a SOC 2 report for its fintech partners. If its GRC analyst treated each of these as a separate universe — separate controls, separate evidence, separate audits — she would spend her entire year producing the same artifacts six times over and still have gaps. The way out is the crosswalk: a table that maps one well-designed control to the many obligations it satisfies, so a single control and a single piece of evidence answer to several regimes at once. This appendix is that crosswalk, built across the major regulatory and compliance regimes the book covers, mapped against the control domains a defender actually implements.

The regimes covered here are PCI-DSS v4.0, the HIPAA Security Rule, GDPR, the SOC 2 Trust Services Criteria, the GLBA Safeguards Rule, and NIST CSF (included as the voluntary organizing framework that ties the others together). For each, this appendix gives scope and applicability — who it binds and what triggers it — because scope is half the battle in compliance, and a control that satisfies one regime may be entirely out of scope for another.

Two principles govern everything that follows, both from Chapter 28. First and most important: compliance is the floor, not the ceiling. Every regime here defines a minimum — a bar someone else set, on a schedule someone else chose, against a list someone else wrote. Passing proves controls exist and are documented, not that they defeat the attacker you actually face. Real security lives in the gap between the two. Second: the data opts you in. For the mandatory regimes you do not choose the obligation; the moment you handle a particular kind of data or activity, the obligation attaches.

A note on numbers, per the book's citation policy (_style-bible.md §7): this appendix describes requirements by area, not by fabricated article or requirement numbers. Where a specific number is well known and stable, it is named; where it is not, the area is described. Always pull a precise citation from the live published standard before relying on it. The regimes are Tier 1 sources; Meridian and its scenarios are Tier 3 constructed illustrations.

E.1 The regimes at a glance

Before the control-domain tables, fix what each regime is, who it binds, and what produces a "pass." Chapter 28 develops this in depth; here it is the reference card.

Three of these are mandatory (PCI-DSS by contract, HIPAA and GLBA by law, GDPR by law) and bind you the moment the triggering data or activity appears. Two are voluntary (SOC 2 and NIST CSF), adopted to signal trust or organize a program — though a SOC 2 report can be market-mandatory, the literal price of selling to large enterprises. The scope triggers are the load-bearing column: PCI-DSS protects one thing (cardholder data) and only within the CDE; HIPAA covers ePHI; GDPR covers EU personal data broadly; GLBA covers customer financial information. A breach of data outside a regime's scope is not that regime's failure — it was never in play.

E.2 Which regimes require X — by control domain

These are the crosswalk's core tables. Each takes one control domain a defender implements and shows how each regime treats it. "Required" means the regime explicitly demands a control in this area; "Required (risk-based)" means the regime demands it but lets you calibrate the implementation to assessed risk (HIPAA's "addressable," GDPR's "appropriate," GLBA's "appropriate to size and complexity"); "In scope as selected" means SOC 2 covers it if you scoped the relevant Trust Services Criterion in. Read the prose under each table for the nuance the matrix cannot hold.

Access control and authentication

Access control is the most universally required domain — every regime demands it, which is exactly why MFA on remote and administrative access is the canonical crosswalk control (one policy export plus a sign-in-log sample satisfies every column). The differences are in framing and rigor: PCI-DSS is the most prescriptive (it names MFA explicitly and scopes it to the CDE and to all administrative access), GLBA's modernized Safeguards Rule also calls for MFA, while HIPAA and GDPR demand access control but let you calibrate the specifics to risk.

Encryption and protection of data at rest and in transit

Encryption is required across the board, but the regimes care about it the way Chapter 4 and 5 do — the algorithm is the easy part; key management is where you win or lose. "We encrypted it" satisfies no auditor who then asks with what algorithm, where is the key, who can decrypt? PCI-DSS is the most demanding on cryptographic key management (it mandates HSM-grade protection for certain payment keys and documented key-management procedures). HIPAA's "addressable" encryption is widely misunderstood as optional — it is not; it means implement or justify, and proper encryption additionally provides a breach-notification safe harbor, which is a strong practical incentive. For card data specifically, tokenization (Chapter 5) is often the better lever than encryption: it removes the sensitive data from most of the environment, shrinking PCI-DSS scope.

Logging, monitoring, and audit trails

Every regime requires logging, but a defender must hold the Chapter 28 distinction in mind: "compliant" logging and "useful" logging are not the same set. A regime may require that you log access to a data type and retain it; whether those logs actually let you detect the attacker is a separate question the audit usually cannot ask. PCI-DSS v4.0 notably strengthened the expectation toward automated log review and toward logs that support actual detection, narrowing (but not closing) the gap between the floor and real security.

Incident response and breach notification

This is the domain where the notification clocks differ sharply, and a defender must know them cold because they drive the IR runbook's tempo:

The 72-hour GDPR clock is the one security teams feel most directly, and it is why a rehearsed IR plan (Chapter 24) matters: the decision of who notifies whom, in what order, under what statutory deadline, cannot be improvised at 2 a.m. during a breach.

Vendor / third-party risk management

Vendor risk is required by every regime, each with its own instrument: PCI-DSS's written agreements and responsibility matrix, HIPAA's BAA, GDPR's data-processing agreement, GLBA's service-provider oversight, CSF's C-SCRM. The unifying lesson (Chapter 29): your risk includes your vendors' risk, and the contract is how you flow your floor across an organizational boundary you do not control. A vendor's SOC 2 report is the evidence you read to extend that floor — which is why SOC 2 sits on both sides of this domain (you produce one for your customers and consume your vendors').

Security awareness and training

Awareness is required everywhere because, as Theme 3 holds, the human is both the weakest link and the strongest asset. Every regime mandates training; none of them, by mandating it, guarantees a workforce that actually resists a deepfake-enabled fraud call (Chapter 35). Annual click-through training satisfies the checkbox; a measured, recurring program that drives down phishing click-rates is the security the checkbox only gestures at.

Risk assessment and governance

Risk assessment is the domain that ties compliance back to real security, because it is the engine that decides how far above the floor to build (Chapter 27). Every regime requires it; the better ones (GLBA's modernized rule, PCI-DSS v4.0's targeted risk analyses, HIPAA's foundational risk analysis) make it the basis for which controls you implement and how often. A risk assessment done honestly is where a defender converts a compliance program from a binder into a defense.

E.3 The master matrix

For the reader who wants the whole picture on one screen, here is the consolidated view. Cells use: R = required; R = required but risk-based/calibrated (HIPAA addressable, GDPR/GLBA "appropriate"); S = in scope if the relevant Trust Services Criterion is selected; O* = required as an outcome (CSF). Confirm specifics against the live standard before citing.

The shape of the matrix tells the story: the control domains are almost universally required; the differences are in scope, framing, and rigor, not in whether the control is needed. This is precisely why crosswalking works — implement the control once, generate the evidence once, and file it against many columns — and precisely why you must still read each cell, because the same control is scoped to cardholder data under PCI-DSS, to ePHI under HIPAA, to EU personal data under GDPR, and to "customer information" under GLBA. A control can be in scope for one and entirely out of scope for another, depending on which data it touches.

E.4 Scope and applicability — read this before you map

The single most consequential — and most misunderstood — fact in compliance is that each regime's requirements apply only within that regime's scope, and the scopes are different.

• PCI-DSS applies only to the Cardholder Data Environment: systems that store, process, or transmit cardholder data, plus systems connected to or able to affect them. The highest-leverage move in PCI-DSS is scope reduction — shrinking the CDE through segmentation and by not storing card data you do not need — which is both a cost saving and a security control, because every system removed from the CDE is one that cannot become the attacker's bridge into it. A company can be fully PCI-DSS compliant and suffer a devastating breach of PII or health data that lived entirely outside the CDE.
• HIPAA applies to ePHI held by covered entities and business associates. Data that is not PHI, or an organization that is neither a covered entity nor a business associate, is outside it.
• GDPR applies to the personal data of people in the EU, regardless of where the processing organization sits (extraterritorial reach). A U.S. company with EU customers is bound.
• GLBA applies to customer financial information held by financial institutions.
• SOC 2 applies to exactly the controls and Trust Services Criteria you put in scope, over a defined window — assurance about a bounded set of controls operating in the past, not a guarantee against everything.
• NIST CSF has whatever scope you give it; it is a voluntary organizing framework.

Worked scope example (Tier 3, constructed). An attacker steals Meridian's customer-support database — names, emails, support transcripts, but no card numbers. Did PCI-DSS "fail"? No — it was never in play, because the support database sat outside the CDE. Meridian was genuinely PCI-DSS compliant and still suffered a serious breach, which is now a GLBA matter and a state-breach-law (and possibly GDPR, for any EU customers) matter rather than a PCI-DSS one. This is the floor-vs-ceiling principle in its purest form: compliance with a regime protects only what that regime scopes in, and attackers aim at the seams between scopes.

E.5 Compliance is the floor, not the ceiling

This appendix is a crosswalk, and a crosswalk is a powerful tool — it collapses six audits into one maintained table and lets a single piece of evidence do many jobs. But the crosswalk's danger is the same as its power: a fully populated, all-green crosswalk can still describe an insecure organization. Every cell can read "required — satisfied" while:

• the MFA is a phishable push notification an attacker defeats with fatigue (Chapter 16);
• the "encryption at rest" has its master key sitting on the same server, readable by the same account that reads the data (Chapter 5);
• the required logs are collected and retained but no rule fires on the technique the attacker actually uses (Chapter 22);
• the data the attacker takes lived outside every regime's scope, and so was never required to be protected at all.

The structural reasons compliance falls short of security are worth keeping in view as you use these tables: frameworks lag the threat (written over years, while attackers iterate in weeks); compliance checks existence, not effectiveness (the audit confirms the control is present, not that it stops your adversary); scope is a boundary, and attackers love boundaries (the data outside an obligation's scope is least watched); point-in-time validation drifts (the gap between assessment day and any other day is where controls lapse); and the map is not the territory (a clean report is a representation of security that can be accurate and still describe something inadequate).

The mature stance is neither "compliance is theater" nor "compliance is enough." It is this: use compliance as the floor and your risk process as the engine that decides how far above it to build. Compliance answers what must we do?; risk management answers what should we do?; and the distance between those two answers is the whole of real security. Build the control to defeat the attacker, operate it continuously, collect its evidence as a byproduct, map that evidence across every regime in this appendix — and let passing the audits be the consequence of being secure rather than its substitute.

🔗 Connection: Appendix A maps the control frameworks (NIST CSF 2.0, SP 800-53, CIS Controls v8, ISO 27001/27002) that organize how you build controls; this appendix maps the regulatory and compliance regimes those controls must satisfy. Chapter 28 teaches the live skills — crosswalking, scoping the CDE, gathering evidence, running a gap assessment on yourself before the auditor arrives — and Chapter 29 extends the vendor-risk row across the supply chain. Together they turn these reference tables into a compliance program that scales instead of one that drowns.