The control framework nobody owns
Meridian Pay is a 5,200-employee payments firm running AWS (240 accounts under Control Tower), Azure for Microsoft 365, and GCP for analytics. A state banking regulator requires an annual control mapping to a recognized framework. Today four teams maintain separate spreadsheets totaling about 1,100 controls, most copied from a 2016 on-premises matrix; 38% are marked "N/A - cloud," and exceptions are approved in email threads with no expiry and no named owner. The CISO proposes replacing the matrix with CSA CCM v4 plus CIS Benchmarks per platform, a single exception register capped at 30 days with a named risk owner, and quarterly attestation by control owners. The head of the cards business unit objects: her migration is 11 weeks from a contractual deadline and she cannot "absorb a new control bureaucracy." The cloud platform team says it already produces the real evidence in AWS Config and Azure Policy and does not want it mediated by a GRC tool that will lag reality by weeks.
1. Diagnose the governance failure at Meridian Pay. What decision rights and accountability structures must exist before any framework is selected?
Read the worked answer
There are three distinct failures, and only the third is about frameworks.
1. No accountable owner. Four spreadsheets means four de facto standards and nobody accountable for the union. Any framework chosen inherits the same fragmentation. The first fix is a single named owner for the cloud control baseline (typically the CISO with delegated authority to the cloud governance board) and a documented decision right: who may add, waive, or retire a control.
2. The framework was never risk-derived. Controls copied from an on-premises matrix do not map to cloud constructs, so owners mark them N/A - 38% N/A is not a cloud problem, it is evidence the matrix measures the wrong things. Controls should trace to a risk register and to the regulator's requirement, not to a historical artifact.
3. Exceptions are unbounded. Email approvals with no expiry and no owner mean residual risk is accepted by nobody. That is the single most auditable governance defect.
So the sequence is: assign accountability and decision rights, define a risk-derived baseline with traceability to the regulator's framework, then formalize time-boxed exception handling with named risk acceptors. Choosing CCM v4 before fixing ownership simply produces a better-formatted version of the current problem.
2. Evaluate the CISO's proposal. Which elements genuinely reduce risk, and which introduce new failure modes?
Read the worked answer
Sound elements. CSA CCM v4 is purpose-built for cloud and maps to ISO 27001/27017 and NIST 800-53, which preserves regulator traceability. A single exception register with expiry and named owners closes the real governance hole. Quarterly attestation with a named owner creates accountability that spreadsheets never had.
Weak or risky elements.
- CIS Benchmarks are configuration baselines, not a control framework. They answer "how do we configure this resource," not "what control objective does this satisfy." Presenting them as half the framework conflates technical hardening with governance and will leave process controls (vendor review, change approval, access recertification) uncovered.
- Dual frameworks create double work unless there is one canonical control set with a mapping layer. The CCM should be the control language; CIS results should be evidence for specific CCM controls.
- A flat 30-day cap invites rubber-stamping once exception volume rises. Tier the register: pre-approved low-risk patterns auto-renew with compensating controls, while high-risk exceptions require CISO sign-off and a remediation date.
- The platform team's objection is legitimate. Manual attestation of controls that are already continuously measured is theatre. Make Config, Azure Policy and Security Hub the system of record for technical controls and reserve human attestation for process controls. If the GRC tool cannot ingest machine evidence, it should not be the source of truth for those controls.
Net: keep CCM v4, the register, and attestation; drop CIS-as-framework and fix the tooling boundary before rollout.
3. The cards business unit head asks to be exempted from the new process until her migration completes. How should security leadership respond, and what measurable outcomes define success at six months?
Read the worked answer
Exempting the unit is the wrong trade, but so is a blanket rollout. The correct move is to decouple controls with zero marginal cost to the business unit from those that require human effort.
Response. Immediately apply the fully automated controls - Control Tower guardrails, Config rules, CIS-aligned baseline via landing-zone templates - because they impose no new work on her teams. Onboarding to the paved landing zone is the compliance path; a business unit that migrates through the standard account factory gets baseline controls by default rather than by exception. Defer only the manual process controls (control self-attestation, access recertification cycles) until two weeks after cutover, with a written date. Explicitly refuse the request for a general exemption, because the 11-week migration is exactly when a misconfigured account is most likely.
Six-month success measures.
- Percentage of in-scope controls with machine-generated evidence (target ≥70%), not the number of policies written.
- Count of open exceptions and count expired without closure (target: zero expired).
- Median exception approval cycle time (a long cycle signals the process is being routed around).
- Attestation completeness by control owner, by quarter.
- Percentage of controls traceable to the regulator's framework (target 100%).
Success is exceptions trending down and evidence trending automated. If exception volume rises and evidence stays manual, the governance change failed regardless of how many controls the matrix now lists.