A complete, synthetic design for a mid-size regulated enterprise security program — charter, decision rights, capability maturity model, 12-quarter roadmap, staffing sequence, metrics catalog, board reporting pack, and risk-acceptance machinery.
Govern. This repository is a reference implementation of the governance layer of a security program: how authority is allocated, how capability is measured, how work is sequenced against dependencies rather than against vendor categories, how the program is staffed as it scales, and how risk is knowingly accepted and reported upward. Assess/secure/detect/respond capabilities appear here only as objects of governance — the engineering content for those lives in sibling repositories.
The reference organization is a fictional composite, referred to throughout as Northmark Industrial Health (NIH is not used as an abbreviation; the short form is the reference organization):
| Attribute | Reference organization profile |
|---|---|
| Sector | Regulated manufacturer of connected clinical devices, with an energy-sector services division |
| Size | ~6,400 employees, 9 business units, 3 manufacturing sites, 1 SaaS platform |
| Revenue band | $1.8B annual (illustrative) |
| Regulatory exposure | FDA premarket/postmarket cybersecurity, HIPAA (platform hosts PHI), SOX ITGC, GDPR (EU sales entity), NERC CIP (services division touches BES cyber systems), FedRAMP Moderate (public-sector SaaS pursuit) |
| Environments | AWS (primary), Azure (acquired BU), on-premises manufacturing OT, 2 co-located data centers |
| Security staffing at T0 | 6.0 FTE plus a fractional CISO reporting to the CIO |
| Security spend at T0 | 4.1% of IT budget (illustrative) |
Every number, finding, name, and assessment score in this repository is synthetic, constructed to make the method legible. None of it describes a real organization.
- Synthetic reference implementation. The reference organization does not exist. Maturity scores, metric values, risk records, and board slides contain illustrative example data only.
- No employer data. No content here is derived from, or describes, any employer, client, product, architecture, control inventory, finding, or incident.
- No proprietary architecture. Architecture appears only at the level of generic patterns (cloud-first SaaS, converged IT/OT plant network, multi-BU identity estate).
- Governance, not engineering. There are no detection rules, scanner configurations, IaC modules, or pipeline definitions in this repository. Where the roadmap commits to such artifacts, it names the capability and the acceptance criteria, not the implementation.
- Not a policy set. Policies and standards are named as roadmap deliverables. Their text is out of scope; this repository governs who writes them, who approves them, and how exceptions are handled.
- Not legal or audit advice. Framework interpretations are engineering judgments, not attestations.
| Standard | Version | Where it is applied |
|---|---|---|
| NIST Cybersecurity Framework | 2.0 | maturity-model/ domain structure; the six functions (Govern, Identify, Protect, Detect, Respond, Recover) anchor the 16 capability domains and the board-level scorecard |
| NIST SP 800-53 | Rev 5 | maturity-model/scoring-rubric.md control-depth anchors; risk/ risk-acceptance records cite control families (AC, CM, RA, SI, IR, CA) |
| NIST SP 800-37 (RMF) | Rev 2 | risk/exception-management.md authorization and continuous-monitoring vocabulary; system-level risk acceptance |
| NIST SP 800-30 | Rev 1 | risk/risk-register-template.md likelihood/impact scales and risk-determination method |
| ISO/IEC 27001 | 2022 | charter/program-charter.md management-system framing (Clause 5 leadership, Clause 6 planning, Clause 9 performance evaluation); Annex A control themes mapped in the maturity model |
| ISO/IEC 27005 | 2022 | Risk-treatment decision categories (modify / retain / avoid / share) in risk/ |
| ISO 14971 | 2019 | risk/ separation of patient-safety risk from enterprise information risk, and the escalation bridge between them |
| IEC 62304 | 2006+A1:2015 | Product-security domain in the maturity model (software lifecycle processes as a maturity input) |
| ISA/IEC 62443 | series (‑2‑1, ‑3‑2, ‑3‑3, ‑4‑1) | OT security domain; zone/conduit reasoning in the roadmap dependency chain; SL-T targets as maturity anchors |
| NERC CIP | CIP-002 through CIP-014 | Services-division scope in the maturity model and roadmap; evidence cadence in the metrics catalog |
| NIST AI RMF | 1.0 | AI governance domain (Govern/Map/Measure/Manage as the domain's practice groups) |
| OWASP GenAI LLM Top 10 | 2026 (published 2026-08-04) | AI governance domain target-state definition and intake review criteria |
| FDA FD&C Act §524B | effective 2023-03-29 | Product-security domain obligations, including §524B(b)(3) SBOM requirement, as roadmap-forcing constraints |
| COBIT 2019 | 2019 | Decision-rights taxonomy in charter/raci.md (accountability vs. responsibility separation) |
| SOX ITGC (PCAOB AS 2201 framing) | current | Financial-reporting IT control domain; quarterly evidence cadence in the metrics catalog |
| GDPR | Regulation (EU) 2016/679 | Privacy-engineering domain; Art. 32 measures and Art. 33 breach-clock constraint on the IR domain |
| FedRAMP | Rev 5 baselines | Roadmap Q7–Q10 authorization track and its staffing implications |
| CIS Benchmarks | current | Configuration-baseline maturity anchors for cloud and endpoint domains |
security-program-blueprint/
README.md
DECISIONS.md
LICENSE
.gitignore
charter/
program-charter.md Mission, authority, decision rights, escalation, risk-acceptance authority
raci.md RACI across security / engineering / IT / legal / compliance / executive
decision-rights-matrix.md Which body decides what, at what threshold, with what quorum
maturity-model/
README.md How to run an assessment, evidence rules, cadence
scoring-rubric.md 0–5 level definitions, per-dimension anchors, scoring algebra
capability-domains.md 16 domains: definition, current state, target state, gap narrative
assessment-current-state.csv Machine-readable synthetic assessment (T0) with per-dimension scores
generate_assessment.py Computes weighted scores from the rubric; regenerates the CSV
roadmap/
roadmap-12-quarters.md Q1–Q12 with sequencing rationale per quarter
dependency-model.md Dependency graph, critical path, and what breaks if sequence is violated
staffing-model.md Hire sequence, role charters, span of control, build-vs-buy per function
metrics/
metrics-catalog.md 55 metrics: definition, source, owner, cadence, target, failure mode
metrics-catalog.csv Same catalog, machine-readable
build_catalog.py Single source of truth; emits both catalog files
measurement-maturity.md Why most programs measure the wrong things first
reporting/
board-pack-template.md 8-section board pack template with illustrative synthetic data
audit-committee-narrative.md Worked quarterly narrative, including a bad-news quarter
risk/
risk-register-template.md Field definitions, scoring scales, lifecycle states
risk-register-example.csv Synthetic register, 18 entries
risk-acceptance-records.md 4 worked risk-acceptance records, including one denial
exception-management.md Exception process, decision tree, SLAs, and abuse controls
If you are standing up a program from near-zero:
- Read
charter/program-charter.mdand adapt the authority section first. A program without documented risk-acceptance authority will have that authority assigned to it by default during its first bad quarter, usually badly. - Run the maturity assessment in
maturity-model/before writing a roadmap. Use the evidence rules — a score without an evidence artifact is an opinion, and opinions do not survive an auditor or a budget cycle. - Do not lift the roadmap in
roadmap/roadmap-12-quarters.md. Lift the dependency model inroadmap/dependency-model.md, then re-sequence against your own assessment. The roadmap is an output of the reference organization's gaps; the dependency reasoning is portable. - Adopt at most 8 of the 55 metrics in the first two quarters.
metrics/measurement-maturity.mdexplains which 8 and why the rest will produce noise you cannot act on. - Use
risk/exception-management.mdbefore you need it. Exceptions requested during an outage get granted; exceptions requested against a documented decision tree get priced.
If you are assessing an existing program:
maturity-model/scoring-rubric.mdis usable as a standalone assessment instrument. The four scoring dimensions (Defined / Implemented / Measured / Governed) are what distinguish a program that has a tool from a program that has a capability.metrics/metrics-catalog.mdincludes a failure mode column for every metric. Ask the program owner what each metric's failure mode is. If they cannot answer, the metric is decoration.
If you are preparing for a board or audit-committee cycle:
reporting/board-pack-template.mdandreporting/audit-committee-narrative.mdmodel the hard case: reporting a missed commitment and an accepted risk without either alarming or anesthetizing the board.
Reproducing the data files
The CSV files are plain UTF-8 with a header row and are readable with any tool:
python3 -c "import csv,sys; r=list(csv.DictReader(open('maturity-model/assessment-current-state.csv'))); print(len(r),'rows'); print(r[0])"Sibling repositories in this portfolio:
compliance-control-crosswalk— the control library and multi-framework crosswalk that the compliance and audit-readiness domains of this blueprint assume as an input.product-security-program— the SaMD/product-security engineering practices governed by the product-security domain here.ai-governance-framework— the AI intake and risk-assessment machinery governed by the AI governance domain here.vulnerability-management-model— the prioritization and SLA engine behind the vulnerability metrics inmetrics/.identity-governance-reviews— the access-certification and privilege-analysis method behind the identity domain scores.ot-security-baseline— the ISA/IEC 62443 and NERC CIP engineering baseline governed by the OT domain here.