Case Study 1: Meridian Maps Its Obligations and Prepares for the QSA

"The audit isn't the test. The audit is the moment you find out whether you studied. We're going to study." — Elena Vasquez, GRC Analyst, Meridian Regional Bank (constructed)

Executive Summary

Meridian Regional Bank's annual PCI-DSS assessment is ninety days out, and for the first time the bank wants to be ready rather than merely compliant on the day. CISO Dana Okafor has asked GRC analyst Elena Vasquez to do three things that, taken together, transform Meridian's compliance posture from a yearly fire drill into a maintained capability: build a compliance mapping that crosswalks Meridian's controls across all of its obligations so one piece of evidence does many jobs; draw a defensible scope boundary for the Cardholder Data Environment and prove what is outside it; and run a gap assessment so the bank finds its own shortfalls before the Qualified Security Assessor does. Junior analyst Theo Brandt shadows the work, learning that the GRC seat is not paperwork but a particular kind of engineering — the engineering of provable claims. Along the way the team confronts the chapter's hard lesson directly: a control can satisfy every framework and still fail a real attacker, and the bank's job is to be ready for both the auditor and the adversary. All figures, systems, and findings are constructed for teaching (Tier 3).

Skills applied: sorting obligations (voluntary vs. mandatory); control crosswalking across PCI-DSS, GLBA, NIST CSF, and SOC 2; PCI-DSS scope definition and reduction; evidence and artifact selection (designed vs. operated); gap assessment and routing gaps into the risk register; distinguishing compliance from security.

Background

Meridian is regulated by nearly everyone. As a mid-size U.S. regional bank with roughly 1,800 employees, 120 branches, and 2.5 million customers, it issues and processes payment cards (PCI-DSS, by contract with the card brands), protects customer financial information (the GLBA Safeguards Rule, by U.S. law), runs financial-reporting systems under SOX controls, is examined under FFIEC guidance by federal regulators, and is bound by state breach-notification laws across three states. It is not ISO/IEC 27001 certified, but it uses the NIST CSF to organize its program, and it produces a SOC 2 report for the fintech partners that connect to its APIs. That is at least six distinct audiences, each wanting proof, on its own schedule, against its own list.

Before this year, Meridian's compliance work was what Elena privately called "the binder shuffle." Each obligation was handled as a separate project: when the PCI assessment came, the team scrambled to assemble PCI evidence; when a fintech partner asked for the SOC 2, a different scramble began; the GLBA examination triggered a third. The same controls — MFA, encryption, logging, access reviews — were documented three or four times, in three or four formats, with no shared source of truth. Worse, gaps surfaced during audits, as findings, which is the most expensive and embarrassing moment to discover them.

Dana's mandate is to fix the pattern, not just survive this year's PCI assessment. "I don't want us to pass," she tells Elena and Theo. "Passing is the floor. I want us to know exactly where we stand against every obligation we have, all the time, and I want the auditor to find nothing we didn't already find ourselves. And I want you to tell me, honestly, where we're compliant but not actually safe — because those are the places that will hurt us."

The Engagement

Phase 1 — Mapping the obligations

Elena starts where the chapter says to start: not with controls, but with sorting the landscape. She and Theo lay out every obligation Meridian carries and classify each by who compels it and what passing produces, because — as Elena puts it — "you can't manage six obligations until you understand that they're not six of the same thing."

🔗 Connection: Theo notices something the sorting makes obvious. The voluntary obligations (NIST CSF, and arguably SOC 2, which is market-driven) are where Meridian chooses its altitude, while the mandatory ones (PCI-DSS, GLBA, SOX, FFIEC) are floors the bank cannot opt out of. Dana uses the voluntary CSF to set the program's target maturity above the mandatory floors — exactly the §28.6 stance of using compliance as the floor and risk as the engine for going higher. The sorting isn't bureaucracy; it tells the team which obligations are negotiable in scope and which are not.

The team's first real insight is how much these obligations overlap. Nearly every one of them requires, in some form: access control with strong authentication, encryption of sensitive data in transit and at rest, logging and monitoring of access to sensitive systems, change management, vulnerability management, and incident response. They say it differently and organize it differently, but the underlying controls are largely the same set. This overlap is the opportunity. If Meridian builds each control once, documents it once, and generates its evidence once, then a crosswalk can file that single artifact against every obligation that needs it. The binder shuffle exists only because nobody built the crosswalk.

Phase 2 — Building the crosswalk

Elena builds Meridian's master crosswalk: a table whose rows are the bank's implemented controls and whose columns are its obligations, with each cell naming the requirement area the control satisfies and a pointer to the artifact that proves it. She deliberately describes requirement areas rather than inventing exact requirement numbers for every framework — "I cite a specific requirement number only when I'm certain of it," she tells Theo; "otherwise I name the area and let the QSA confirm the exact reference. Confident-sounding wrong numbers are how you lose an auditor's trust." Here is a representative slice:

MERIDIAN CONTROL CROSSWALK (slice)  —  rows = controls, cols = obligations
Legend: ✓ = satisfies requirement area;  artifact in [brackets]

Control                         NIST CSF        ISO-equiv*  SOC2    PCI-DSS        GLBA
─────────────────────────────   ────────        ─────────   ────    ───────        ────
Phishing-resistant MFA          Protect:        Access      Security MFA into     Access
(remote + admin access)         Access Control  control     (logical) the CDE     controls
  [Conditional Access export + 30-day sign-in log sample, MFA enforced, no bypass]   ✓ all

Encrypt cardholder data         Protect:        Crypto/     Conf-    Encrypt CHD   Protect
in transit (strong TLS)         Data Security   transmission identy  in transit    cust. info
  [TLS config scan report + cert inventory + endpoint list]                          ✓ all

Centralized logging of          Detect:         Logging &   Security Log access   Monitor
access to the CDE               Anomalies/Events monitoring (logical) to CHD       access
  [SIEM ingestion proof + 90-day retention config + sample CDE access events]        ✓ all

Quarterly access review         Protect:        Access      Security Restrict     Access
/ recertification               Access Control  review      (logical) access (NTK)* controls
  [4 quarters of signed review records: reviewer, date, decisions]                   ✓ all

Vulnerability scanning          Identify:       Tech vuln   Security Regular      Risk
+ risk-based patch SLAs         Risk Assessment management  (avail)  testing       assessment
  [Scan reports + patch tickets showing SLA met over 12 months]                      ✓ all

*ISO-equiv shown for reference (Meridian is not 27001-certified). NTK = need-to-know.

Figure CS28.1 — A slice of Meridian's master crosswalk. The expensive asset is not the control but the artifact in brackets; the crosswalk lets one artifact satisfy a requirement area in every column. Build the row once, maintain it, and an audit becomes a lookup.

The payoff is immediate and concrete. When the QSA asks for evidence of MFA into the CDE, Elena reaches for the same Conditional Access export and sign-in-log sample she would hand a SOC 2 examiner or a GLBA examiner. When the partner's SOC 2 review asks about logging, she pulls the same SIEM evidence the QSA wants for PCI. One control, one artifact, many audiences. Theo, watching, finally understands why GRC people talk about "evidence" the way engineers talk about "infrastructure" — it is the thing you build once and reuse, and the crosswalk is its index.

But Elena makes Theo write down the caveat in his own notebook, because it is the most important thing in the whole engagement: a fully populated crosswalk can describe an insecure bank. Every cell in the MFA row can read "✓" while the MFA is a phishable push notification an attacker defeats with fatigue. The crosswalk proves the control exists across all six obligations; it says nothing about whether the control would survive contact with a real adversary. "We map for the auditor," Elena says, "and we build for the attacker. When those two disagree, the attacker is right, and we fix the control — not the crosswalk."

🛡️ Defender's Lens: Elena does something subtle in the crosswalk that pays off against attackers, not just auditors. For each control she notes not just that it satisfies a framework but how the cells differ. PCI-DSS cares specifically about MFA into the CDE; GLBA frames the same control as protecting customer information broadly. That difference is a clue: PCI's narrower framing means the bank could satisfy PCI with MFA only on CDE-adjacent systems and still leave non-CDE customer-data systems weakly authenticated — fully PCI-compliant, GLBA-exposed. Reading the differences between cells is how a crosswalk surfaces the seams an attacker would target. The mapping is a security tool, not just an audit tool, when you read it that way.

Phase 3 — Drawing the scope

The single most consequential artifact in the entire PCI-DSS assessment is the scope diagram, because everything in the CDE must meet the standard's demanding requirements, and everything claimed to be outside it must be provably, defensibly outside. Elena and Sam Whitfield (the security engineer) sit down to draw it, and the conversation is where most of the real work happens.

Meridian's network has several zones: the CDE itself (the card-processing systems and the point-of-sale infrastructure), the general corporate LAN (email, file shares, HR systems), branch networks (teller workstations, ATMs), a guest WiFi network, and a small set of administrative jump hosts. The naive scope is "the CDE is in, everything else is out." Sam pushes back immediately, because that is exactly the kind of assumption that becomes a finding — or a breach.

        MERIDIAN PCI-DSS SCOPE BOUNDARY (as drawn for the QSA)

   ┌─────────────────────── IN SCOPE (CDE) ───────────────────────┐
   │  Card-processing systems  ·  POS infrastructure  ·  the       │
   │  segment that stores/processes/transmits cardholder data      │
   └───────────────▲───────────────────────────────────────────────┘
                   │ ONLY path in/out is the jump host (logged, MFA,
                   │ default-deny firewall, no direct routes)
        ┌──────────┴──────────┐
        │  JUMP HOST (in scope │  ← "connected-to / can affect" rule
        │  because it can      │     pulls this INTO scope
        │  affect CDE security)│
        └──────────▲──────────┘
                   │
   ┌───────────────┴──────────── OUT OF SCOPE ─────────────────────┐
   │  Corporate LAN   Branch nets   Guest WiFi   HR/analytics       │
   │  — PROVABLY out: segmentation testing shows no path to the CDE │
   │    except via the jump host; data-flow map shows no CHD here.  │
   └────────────────────────────────────────────────────────────────┘

   The claim "X is out of scope" is defended by THREE artifacts:
     (1) network diagram   (2) data-flow map (no CHD outside CDE)
     (3) segmentation test results proving no reachable path

Figure CS28.2 — Meridian's PCI-DSS scope boundary. The jump host is pulled into scope by the "connected-to or can affect" rule — a deliberately conservative call. Everything claimed out of scope is defended with three artifacts, because a verbal assurance is not evidence.

Two decisions in this diagram are worth dwelling on. First, the jump host is in scope, even though no cardholder data lives on it, because it can affect the security of the CDE — it is the only door in. Sam argues for including it deliberately: "If it can reach the CDE, the attacker can use it to reach the CDE, so the auditor is right to want it hardened, and so do I." This is the conservative call, and it is the secure one. Second, the out-of-scope claim is defended with evidence, not assertion. Elena will not let "the corporate LAN is out of scope" stand on the architecture diagram alone, because an architecture diagram shows intent, not reality. The claim is backed by three artifacts: the network diagram, a data-flow map proving no cardholder data flows outside the CDE, and — most importantly — segmentation test results demonstrating that no network path reaches the CDE except through the controlled jump host.

This is also where scope reduction earns its place as a security control, not just a cost saving. Meridian discovers, during this exercise, that an old reporting server pulls transaction data nightly from the payment system over a path that technically gives it reach into the CDE. The naive move is to declare it out of scope because it holds no card numbers. The correct move — which the team takes — is to recognize that it is connected and therefore in scope, and then to reduce scope by re-architecting: the reporting server is moved behind the jump host's controls and the nightly pull is changed to a tokenized, one-way feed so that the reporting server can no longer reach into the CDE at all. Now it is legitimately out of scope, and — not coincidentally — an attacker who compromises the reporting server can no longer use it as a bridge to cardholder data. The scope reduction and the security improvement are the same action.

⚠️ Common Pitfall: The reporting server is the exact trap the chapter warned about. A team under time pressure declares a system "out of scope" because the data on it isn't regulated, ignoring that the connectivity pulls it in. This passes a careless audit and creates a breach path: it is precisely a scoped-out, connected, under-watched system — the attacker's favorite kind. The fix is never to argue the system out of scope on paper; it is to cut the connection so it is genuinely isolated, which removes both the audit obligation and the attack path at once.

Phase 4 — The gap assessment

With the crosswalk built and the scope drawn, Elena runs the move that defines the whole engagement: she audits Meridian herself, before the QSA arrives. For each in-scope requirement, she and Theo ask the three questions: Does the control exist? Can we prove it with an artifact? Does the artifact show the control actually operated, not just that it was designed? Each "no" is a gap — and a gap Elena finds now is a remediation item Meridian owns, while the same gap the QSA finds is a finding on the record.

The self-assessment surfaces four issues. Theo lays them out:

🛡️ Defender's Lens: Look at G1 and G4 through the attacker's eyes, because that is the difference between a compliance gap assessment and a security one. G1 isn't just an audit problem — that one legacy admin tool with password-only access is exactly the foothold a phished attacker would hunt for: a forgotten authentication bypass into the most sensitive environment. G4 is worse: the database is encrypted (the control the audit checks), but the backup of that database — a perfect copy of all the data — may be sitting in an unverified bucket. Attackers love backups precisely because defenders forget they are copies of the crown jewels. A naive audit might pass both controls ("MFA: yes; encryption: yes"); the gap assessment catches them because it asks does it actually protect the data against someone trying to get it?

Elena routes every gap and partial straight into the risk register Meridian built in Chapter 27 — not a separate compliance to-do list. This is a deliberate maturity choice. By making each compliance gap a risk-register row with a likelihood and impact, the gaps get prioritized alongside every other risk the bank tracks, compete for the same remediation budget on the same terms, and inherit the register's governance (owner, due date, sign-off). G4 (the unverified backup) scores high — a high-impact data-exposure risk — and jumps the queue; G2 (retention shortfall) is a lower-likelihood compliance gap that gets a scheduled fix. The risk register, not the audit calendar, now drives the work.

GAPS → RISK REGISTER (Ch.27 integration)
  G4 unverified backup encryption  L=3 I=5  score 15 CRITICAL → fix now (verify+enforce)
  G1 password-only legacy admin    L=4 I=4  score 16 CRITICAL → fix now (enforce MFA/retire)
  G2 log retention below target    L=2 I=3  score  6 MEDIUM   → scheduled remediation
  (G3 covered — filed as evidence, no register entry)

By the time the QSA arrives, G1 and G4 are remediated (MFA enforced on the legacy tool, which is then scheduled for retirement; backup-bucket encryption verified and enforced), G2 has a documented remediation plan with a date, and G3's evidence is filed. The would-be findings have become gaps Meridian found and fixed. The assessment, when it comes, is calm — the QSA samples the evidence binder, asks a handful of clarifying questions, and notes that the bank disclosed its own remediation timeline for the one open item rather than hoping it went unsampled. That disclosure, Elena knows, buys more credibility than a suspiciously perfect record ever would.

Phase 5 — From a fire drill to a standing capability

Passing this year's assessment is not the win Dana asked for. The win is that Meridian never does the binder shuffle again — that the compliance posture becomes a maintained capability rather than an annual scramble. The difference between the two is almost entirely about when evidence is collected. Meridian's old model collected evidence reactively, in the weeks before each audit, which is why gaps surfaced as findings and why the same artifact got rebuilt for each audience. The new model collects evidence continuously, as a byproduct of controls operating, so that on any given day Elena can answer "where do we stand against PCI-DSS?" without a project.

Elena and Theo design a small evidence-operating model around three habits. First, every control names its evidence and its owner. For each row in the crosswalk, there is a designated artifact and a person responsible for it — the access-review records have an owner who runs and signs the review each quarter; the MFA sign-in-log sample has an owner who can export it on demand. An orphaned control with no evidence owner is, Elena notes, exactly how G4 happened: nobody owned the backup-encryption verification, so nobody did it. Second, evidence is collected on the cadence the control operates, not the cadence the audit demands. Quarterly reviews produce quarterly records; daily log retention is verified on a schedule; certificate expiry is tracked continuously. The evidence binder is never "assembled" — it is always current, because each artifact lands the moment its control runs. Third, the crosswalk and the gap assessment are living documents, revisited when a new system is added (does it expand the CDE?), when a framework version changes (PCI-DSS v4.0 introduced new expectations), and when a control changes (the legacy admin tool's eventual retirement removes a gap and an artifact at once).

🔗 Connection: This is the §28.5 lesson — "collect evidence continuously rather than scrambling at audit time" — turned into an operating model, and it is also Theme 1 (security is a process, not a product) made concrete. The mature compliance posture is not a binder you build once a year; it is a process that runs all year and produces the binder as exhaust. The same shift separates a SOC 2 Type II (which proves controls operated over time) from a Type I (which proves they were designed once). Meridian is, in effect, building itself a Type II mindset across all its obligations.

Theo, at the end of the engagement, writes the sentence in his notebook that Dana has been driving at the whole time: We did not build this to pass the audit. We built it so that passing the audit is the least interesting thing it does. The crosswalk makes the obligations efficient; the scope work makes the boundary defensible; the gap assessment makes the posture honest; the evidence-operating model makes it durable. And every one of those four artifacts also made the bank genuinely harder to breach — the MFA gap that was an audit finding was also an attacker's foothold; the unverified backup that was a compliance gap was also a copy of the crown jewels. Meridian built for the auditor and the adversary at once, which is the only way the two ever reconcile.

📟 War Story: A constructed but representative contrast. A peer bank, the same size as Meridian, passed its PCI-DSS assessment the same quarter — by doing exactly what Meridian used to do. It assembled evidence in a three-week sprint, screenshotted its controls, passed cleanly, and disbanded the effort until next year. Four months later, an internal access review that should have run quarterly had not run at all (no owner, no cadence), and a contractor who left in month two still had active access in month six. There was no finding, because there was no audit that quarter — only a quiet, growing gap that an attacker, or next year's QSA, would eventually find. The two banks had identical audit results and opposite security postures. The difference was not the audit. It was whether the controls ran when no one was watching.

Discussion Questions

1. Elena describes requirement areas rather than citing exact requirement numbers for every framework unless she is certain of them. Is this caution or evasion? When does citing a precise requirement number help, and when does it risk your credibility?
2. The team pulled the jump host into PCI scope deliberately, even though it holds no card data. Argue for and against this conservative scoping decision. What would the aggressive (minimize-scope-on-paper) approach have risked?
3. Meridian routes compliance gaps into the Chapter 27 risk register rather than a separate compliance to-do list. What are the advantages of this integration? Is there any downside — e.g., could a compliance obligation get deprioritized below its true urgency because the register treats it like any other risk?
4. The crosswalk's MFA row can read "✓" across all six obligations while the MFA is phishable. If you were Dana presenting to the board, how would you communicate the difference between "we are compliant" and "we are secure" without either alarming the board or letting them believe the clean crosswalk means safety?
5. G4 — the unverified backup bucket — would likely pass a naive "is the database encrypted?" audit check. What does this reveal about the limits of audits generally, and what kind of question must a gap assessment ask that an audit often does not?
6. Scope reduction (re-architecting the reporting server) improved security and reduced audit burden in a single action. Find another control or architectural change where the compliance benefit and the security benefit point in the same direction — and one where they might conflict.

Your Turn

Take an organization you know or invent a small regulated one (a clinic, a payment startup, a SaaS vendor with EU customers). Reproduce a slice of this engagement: (1) list its obligations and sort them voluntary vs. mandatory; (2) build a crosswalk of at least four controls across at least three obligations, naming the requirement area and the artifact for each (describe areas; don't invent exact numbers); (3) draw a one-paragraph scope boundary for its most demanding obligation and name the three artifacts that would defend an "out of scope" claim; (4) run a four-item gap assessment, marking each covered/partial/gap with a justifying phrase, and route the gaps into a two-column mini risk register with illustrative likelihood × impact scores. Keep it to two pages. For each gap, write the second-question note: would fixing this for the audit also defend the organization, or only satisfy the checkbox?

Key Takeaways

• A regulated organization carries many overlapping obligations; the first move is to sort them (voluntary vs. mandatory, framework vs. standard vs. regulation) so you know which altitudes you choose and which are floors you cannot opt out of.
• A crosswalk turns overlap into efficiency: one control, one artifact, many audiences. The expensive asset is trustworthy, operated-over-time evidence, generated once and indexed by the crosswalk.
• A fully "✓" crosswalk can describe an insecure organization. Read the differences between cells to find seams; map for the auditor, build for the attacker, and fix the control (not the crosswalk) when they disagree.
• Scope is the highest-leverage artifact in a PCI-DSS assessment: everything in scope needs evidence, everything out must be provably out (network diagram + data-flow map + segmentation test). Pull "connected-to / can affect" systems in.
• Scope reduction is a security control, not just a cost saving — cutting a scoped-out system's connectivity removes both the audit obligation and the attacker's bridge in one action.
• A self-run gap assessment converts would-be findings into gaps you remediate first; route gaps into the risk register (Chapter 27) so they compete for budget on the same governed terms as every other risk.
• Audits check that controls exist; gap assessments must ask whether they protect the data against someone trying to take it — the difference between the floor and the ceiling.