Case studies / Control framework
Simulated case study: fictional company (Northstar Financial Technologies), synthetic data, no real audit or client.
2. Unified control framework and audit-readiness assessment
32 unified controls (27 consolidated from existing controls, 5 proposed to cover missing areas), 158 requirement mappings, 54 gaps and a roadmap of 54 items.
Why it matters to the business
The business context. A payments company is asked for assurance in several languages at once: a voluntary cybersecurity framework (NIST CSF 2.0), an information security standard (ISO/IEC 27001), the card industry's data security standard (PCI DSS) for the part of the business that touches card data, and the trust-services categories behind a SOC 2 report. Each one is usually answered by a different person with a different spreadsheet, and each asks for evidence about the same things.
What is at stake. Duplicated effort is the visible cost: here, 32 controls carry 158 mappings to framework requirements, about 4.9 for every control, supported by 40 evidence items, so collecting one piece of evidence once can serve several answers. The hidden cost is inconsistency. PCI DSS requirement 8.2.5 says access for terminated users is revoked immediately, while Northstar's own policy allows 2 business days. If no one reconciles them, the company can meet its policy, fail the stricter requirement, and not know it. Pulling the audit results in shows where intent and practice diverge: of the 54 gaps found, 11 are controls that were tested and did not operate effectively.
Who relies on the work. The Chief Risk Officer needs to know which gaps matter first. The IT Security Manager and the control owners need one list of what is expected of them. Assessors, customers and partners may each ask for assurance against a different framework, and the answer should not change depending on who asks.
What the business needs from this work.
- One control set mapped once to many requirements, with the evidence that proves each control and the test result behind it.
- Honesty about how sure each mapping is, and about requirements that look alike but are not equivalent.
- A sequenced plan (10 actions in the first 30 days, 16 by day 60, 28 by day 90) rather than a list of 54 gaps with no order.
What this shows about how I work. It translates regulatory language into testable controls without overclaiming, rates its own confidence, prioritises, and says plainly which standards could only be partly verified. That is the judgement a GRC analyst or compliance team needs, beyond simply filling in a mapping table.
Scope and assumptions
- Payment-card requirements apply only to the fictional segmented payments environment (SYS-02 and its AWS segment), not the whole company. No compliance with any framework is claimed.
- Requirements are paraphrased, never copied, and each cites a source in the register.
Approach
I consolidated Northstar's 33 controls into 32 unified controls, added 5 where no existing control covered an area, and mapped each to requirements with a relationship (equivalent, partial overlap, related, or not equivalent), a confidence level and a rationale. The mapping is author judgement and is labelled as an unreviewed draft. Controls inherit operating status from the Project 1 test results, so the library shows what actually failed, not only what is documented.
An important non-equivalence is kept visible rather than merged: PCI DSS 8.2.5 requires access for terminated users to be revoked immediately, while the Northstar policy allows 2 business days.
What is automated, and what is not
Automation here means scripts that run the same way every time on synthetic data. It is not a live connection to any real system. The table separates what a script does from what still needs judgement.
| What is automated | How | Where in the repository | What a person still does |
|---|---|---|---|
| The control library and gap list | 32 controls, 158 mappings and 54 gaps are generated from the audit results and the framework requirements | scripts/build_p2.py, p2_config.py | Judging whether two requirements really mean the same thing |
| Gap priority and the 30/60/90-day roadmap | Each gap is scored from the inherent risk behind it, its type, the severity of any related finding and PCI relevance, then placed in a 30, 60 or 90-day phase by score thresholds and dependencies | scripts/build_p2.py | Agreeing the order with the control owners |
| Operating status of each control | Inherited automatically from the Project 1 test result, so the library cannot drift from the audit | scripts/build_p2.py | Explaining the difference between a documented and an operating control |
| Verified standards extracts | NIST CSF 2.0 and NIST AI RMF subcategories were extracted from the NIST PDFs by script | scripts/extract_csf_core.py, extract_airmf_core.py | Reading standards that cannot be machine-extracted (ISO, SOC 2) and rating confidence |
| The interactive crosswalk | Filters and sorting run in the browser over the generated table | src/site/static/site.js | Reviewing the mapping rationale |
Re-run it. bash scripts/build_all.sh rebuilds everything from the synthetic data in 22 steps and runs 92 automated tests. The single script is named in each row.
Results
54 gaps were identified (50 actionable after excluding 4 marked not applicable). The roadmap sequences them: 10 items by day 30, 16 by day 60 and 28 by day 90. Use the interactive crosswalk to filter the 158 mappings by framework, relationship and confidence.
| Gap type | Gaps |
|---|---|
| Missing evidence | 18 |
| Operating failure | 11 |
| Mapping uncertainty | 9 |
| Design weakness | 7 |
| Missing control | 5 |
| Not applicable | 4 |
Unified control library
| UC-ACC-01 | Access | Access request, approval and role-change adjustment | Existing (consolidated) | Not operating effectively |
|---|---|---|---|---|
| UC-ACC-02 | Access | Timely removal of leaver access | Existing (consolidated) | Not operating effectively |
| UC-ACC-03 | Access | Periodic user access review | Existing (consolidated) | Not operating effectively |
| UC-ACC-04 | Access | Privileged access management | Existing (consolidated) | Not operating effectively |
| UC-ACC-05 | Access | Service account ownership | Existing (consolidated) | Not operating effectively |
| UC-ACC-06 | Access | Dormant account removal | Existing (consolidated) | Operating effectively with exceptions (within tolerance) |
| UC-ACC-07 | Access | Multi-factor authentication | Existing (consolidated) | Not operating effectively |
| UC-CHG-01 | Change management | Change authorisation and testing | Existing (consolidated) | Not operating effectively |
| UC-CHG-02 | Change management | Developer and deployer segregation | Existing (consolidated) | Not operating effectively |
| UC-CHG-03 | Change management | Emergency change control | Existing (consolidated) | Not operating effectively |
| UC-VUL-01 | Vulnerability management | Vulnerability scanning and remediation | Existing (consolidated) | Not tested |
| UC-VUL-02 | Vulnerability management | Independent penetration testing | Existing (consolidated) | Not tested |
| UC-LOG-01 | Logging and monitoring | Log capture, retention and integrity | Existing (consolidated) | Not tested |
| UC-LOG-02 | Logging and monitoring | Alert review and escalation | Existing (consolidated) | Not operating effectively |
| UC-INC-01 | Incident response | Incident response plan and exercise | Existing (consolidated) | Not tested |
| UC-INC-02 | Incident response | Incident notification decisions | Existing (consolidated) | Not tested |
| UC-BCR-01 | Backup and recovery | Backup operation and failure handling | Existing (consolidated) | Operating effectively with exceptions (within tolerance) |
| UC-BCR-02 | Backup and recovery | Restoration testing | Existing (consolidated) | Not operating effectively |
| UC-BCR-03 | Backup and recovery | Disaster recovery testing | Existing (consolidated) | Not tested |
| UC-SUP-01 | Supplier risk | Vendor due diligence before onboarding | Existing (consolidated) | Not tested |
| UC-SUP-02 | Supplier risk | Vendor reassessment and issue tracking | Existing (consolidated) | Not tested |
| UC-PRV-01 | Privacy | Privacy impact assessment | Existing (consolidated) | Not tested |
| UC-PRV-02 | Privacy | Retention and deletion | Existing (consolidated) | Not tested |
| UC-SDL-01 | Secure development | Code review and security scanning | Existing (consolidated) | Not tested |
| UC-AIG-01 | AI governance | AI use case intake and risk assessment | Existing (consolidated) | Not tested |
| UC-AIG-02 | AI governance | Human review of AI output to customers | Existing (consolidated) | Not tested |
| UC-AIG-03 | AI governance | AI quality and incident monitoring | Existing (consolidated) | Not tested |
| UC-GOV-01 | Governance | Information security policy governance | Proposed (missing from Northstar library) | Not applicable (control absent) |
| UC-GOV-02 | Governance | Asset, data inventory and classification | Proposed (missing from Northstar library) | Not applicable (control absent) |
| UC-GOV-03 | Governance | Security awareness training | Proposed (missing from Northstar library) | Not applicable (control absent) |
| UC-CFG-01 | Configuration | Secure configuration baselines | Proposed (missing from Northstar library) | Not applicable (control absent) |
| UC-GOV-04 | Governance | Payment-card scope confirmation | Proposed (missing from Northstar library) | Not applicable (control absent) |
No rows match the current filters.
What management should do
Fix the controls that failed in testing first (access, change and backup evidence), then close the missing-evidence gaps, then adopt the five proposed controls. The roadmap lists owner, acceptance criteria and closing evidence for every item; effort estimates are planning-only.
Uncertainty and limitations
- Verification levels differ by standard. NIST CSF 2.0 subcategories and PCI DSS requirement text were read from primary PDFs (PCI from v4.0, not v4.0.1). ISO/IEC 27001 Annex A titles come from a secondary source because the publisher's site could not be read, so confidence is capped at Medium. SOC 2 criteria sit behind an account wall and are mapped at category level only, with no criteria identifiers.
- Mappings are one practitioner's judgement with no independent review.
Downloads
Every file below is generated by this repository's scripts and listed in the download index.
- Audit-readiness gap assessmentPDF · 16 KB
- 30-60-90 day roadmapPDF · 23 KB
- Unified control library workbookXLSX · 49 KB
- Framework crosswalk (CSV)CSV · 59 KB
- Requirements traceability (CSV)CSV · 55 KB
- Evidence catalogue (CSV)CSV · 20 KB
- NIST CSF 2.0 subcategories, verified extract (CSV)CSV · 13 KB
Sources
- S001: The NIST Cybersecurity Framework (CSF) 2.0 (NIST CSWP 29) (NIST), verified
- S016: PCI DSS v4.0 SAQ D for Merchants and Attestation of Compliance (April 2022) (PCI Security Standards Council), verified (v4.0 text)
- S017: ISO 27001:2022 Annex A Explained and Simplified (control list) (ISMS.online), partially verified (secondary; internally consistent counts)
See the full source register.