Take every measure from stable definition and manual baseline to automated, decision-relevant evidence.
16metric roadmaps
5maturity stages
6implementation facets
Choose an outcome
Each roadmap covers mechanics, data contract, stages, readiness, anti-gaming controls and asks.
ODM-01 · Implementation roadmap
Design-Stage Defect Capture
Staged plan for a federated organisation: one definition and a minimal data contract per PMO - not a single defect repository. Report the ODM value AND its coverage at every stage. Companion tabs: ODM Register, ODM Contributing Indicators (CI-03/05/07), ODM Data Lineage.
Security design defects identified at or before the Design gate ÷ all security design defects found in the period, including escapes discovered in build, test, penetration testing or production.
Type / target
KPI · % · Green ≥80, Amber ≥65 (illustrative pending PLA negotiation with CIO / Portfolio Board)
Linear delivery: the design stage gate. Agile: end of inception / design spike. Both defined in the version-controlled metric specification.
Reporting rule
Always publish two numbers: the ODM value AND coverage (% of Tier-1 projects whose data meets the contract). Coverage is the honesty device and the PMO improvement lever.
2. The data contract (six fields per defect - any tracker qualifies)
#
Field
Notes
1
Project / portfolio ID
Maps the record to a PMO and the Tier-1 scope list
2
Date and lifecycle phase found
Phase at detection, not at fix
3
Security flag (Y/N)
Set at triage
4
Design-attributable flag (Y/N)
“Should this have been caught at design?” - governed by the written triage rule with QA sampling
5
Severity
Local scale mapped to the common 4-point scale
6
Source
Design review / SAST / test / pen test / incident RCA
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence label
0 - Define
4–6 weeks
Publish metric specification (data contract, severity mapping per tool, Design-gate definitions, triage rule). Select one pilot portfolio. Name metric owner (SSA lead) and PMO counterpart.
Specification signed by pilot PMO; Tier-1 scope list agreed
-
1 - Manual baseline
Q1–Q2
Design review findings logged in one simple register. Quarterly manual sweep of pilot trackers for security defects; SSA triages design-attributability. Publish first cut with coverage.
Two quarterly cuts published; triage rule stable
Directional - trends only, no targets
2 - Standardise at source
Q2–Q4
Each PMO adds security + design-attributable flags and phase field to its own tracker workflow (field mapping, not migration). Design review becomes a Tier-1 gate requirement. Escapes tagged at pen-test triage and incident RCA. Onboarding checklist makes new projects contract-compliant by default.
Teams protect their number by disputing design-attributability
Written triage rule with worked examples; 10% quarterly QA sample outside the delivery line; disputes settled by design authority and folded into the rule
Org change breaks ownership
Metric orphaned in restructures
Anchor to gates and artefacts, not org units; PMOs sign the data contract, never a tool choice
Thin early denominator
Ratio meaningless in first quarters
Report the inverse story - escape count trend + review coverage - until the ratio stabilises
6. Asks of each PMO
#
Ask
1
Sign the data contract for Tier-1 projects (not a tooling commitment)
2
Nominate a data counterpart for the quarterly cut
3
Add the two flags and phase field to the local tracker workflow during Stage 2
4
Adopt the security design review as a Tier-1 gate requirement
5
Include ODM-readiness (L2) in project onboarding from Stage 2 onward
ODM-02 · Implementation roadmap
Security Rework Cost
KRI · % of delivery spend · Green ≤2, Amber ≤4 (illustrative pending PLA negotiation) · Owner: Enterprise Security Architecture lead · Consumer: CFO / Portfolio Board · Cadence: Quarterly, reported with coverage. Organising principle: Do not wait for perfect financials. Effort-days recorded at the change board are a credible proxy until finance cost codes can isolate security rework. The flag discipline matters more than the currency.
Effort/cost of post-build change attributable to security design decisions, as a percentage of total delivery spend on in-scope (Tier-1) initiatives.
Why it matters
This is the money slide of the framework: the invisible tax of late security redesign made visible. It funds the case for early engagement (ODM-15) and design-stage capture (ODM-01), and typically reveals 3–6% of delivery spend on first measurement.
Numerator
Post-build changes flagged security-driven (control retrofit, redesign after review/pen test/incident, compliance rework), costed in £ or effort-days
Denominator
Total delivery spend (or effort) on in-scope initiatives in the period
What counts
Rework caused by security decisions that could reasonably have been made at design - not new scope, not threat-landscape change
Reporting rule
Publish the ODM value AND coverage (% of Tier-1 change volume passing through boards applying the flag)
2. The data contract (per change record)
#
Field
Notes
1
Change record ID
From each PMO’s change/delivery tooling
2
Project / portfolio ID
Maps to PMO and Tier-1 scope
3
Security-driven flag (Y/N)
Set at CAB/change triage against the written definition
Connects rework to its cause (feeds ODM-01, ODM-11)
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence
0 - Define
4–6 weeks
Publish the security-rework definition with worked examples (what counts, what does not). Agree effort-days as the interim unit with finance. Pick one pilot portfolio.
Definition signed by pilot CAB chair and finance
-
1 - Manual baseline
Q1–Q2
CAB applies the flag; PMs record effort on flagged changes. Quarterly manual roll-up against delivery effort.
Two quarterly cuts; flag applied consistently at pilot CAB
Directional
2 - Standardise at source
Q2–Q4
Flag and trigger fields added to each PMO’s change tooling. Finance maps cost codes where feasible; effort-days retained elsewhere. Onboard remaining portfolios.
≥70% of Tier-1 change volume flagged at source
Indicative
3 - Federate & automate
Year 2 H1
Automated quarterly extract from change tooling and finance. Convert effort to £ where codes allow. Negotiate the PLA target.
No change-level flagging; rework invisible inside project budgets
-
L1
CAB applies security-driven flag using the written definition
Pilot by end of Stage 1
L2
Effort recorded on flagged changes; trigger classified
All Tier-1 by end of Stage 2
L3
Finance cost codes or consistent effort-to-cost conversion in place
During Stage 3
L4
Automated extract; rework linked to causal defect/exception records
With Stage 3 tooling
5. Quality and anti-gaming controls
Risk
Effect
Control
Rework hidden as enhancement
Numerator undercounted
CAB challenge question in the template; QA sample of unflagged changes each quarter
Reporter punishment
Teams stop flagging if the number is used against them
Attribute rework to the design stage, never the reporting team - say so publicly and mean it
Effort estimates gamed low
Value understated
Standard effort bands rather than free-text estimates; sample against timesheets where they exist
Scope-change conflation
New requirements counted as rework
Definition excludes genuine scope change; disputed cases settled by design authority and folded into the examples
6. Asks of PMOs and Finance
#
Ask
1
Add the security-driven flag and trigger field to change templates
2
Chairs apply the definition at CAB and challenge unflagged candidates
3
Record effort-days on flagged changes (bands, not precision theatre)
4
Finance counterpart to map cost codes during Stage 2–3
5
Nominate a data counterpart for the quarterly cut
ODM-03 · Implementation roadmap
Pattern Adoption & Conformance
KCI · % · Green ≥85, Amber ≥70 (illustrative pending PLA negotiation) · Owner: Operational Security Architecture lead · Consumer: Domain / Platform Owners · Cadence: Monthly, reported with scan coverage. Organising principle: Machine-checkable baselines before broad scanning. A pattern that exists only as a diagram cannot be conformance-tested; start by expressing your top patterns as testable configuration baselines.
Percentage of new deployments conformant with the approved reference pattern that specifies them, with configuration drift detected within 30 days.
Why it matters
The estate either converges on approved architecture or it silently forks. This is also the reality-check twin of ODM-10: paper coverage claims are audited against what is actually running.
Numerator
Deployments matching their specifying pattern baseline at scan
Denominator
All new deployments that a published pattern specifies
Drift clock
Days from non-conformant change to detection; 30-day threshold
Reporting rule
Publish the ODM value AND scan coverage (% of pattern-specified estate actually scanned) - unscanned is not conformant
2. The data contract (per deployment)
#
Field
Notes
1
Deployment / CI identifier
CMDB configuration item or platform deployment ID
2
Specifying pattern + version
From the architecture repository; version-controlled
3
Scan result (conformant Y/N)
From configuration compliance tooling or IaC policy checks
4
Deviation detail
Failing rules, with severity
5
Drift detection date
First scan detecting divergence from baseline
6
Remediation status
Open / accepted (with expiry) / closed
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence
0 - Define
4–6 weeks
Select top 3 patterns by deployment volume. Express each as a version-controlled, machine-checkable baseline (IaC policy / CIS-style checks).
Three baselines published as code
-
1 - Manual baseline
Q1–Q2
Manual conformance sampling of recent deployments against the three baselines. Map CIs to patterns in the CMDB.
Two monthly cuts on sampled estate; CI-to-pattern mapping started
Directional
2 - Standardise at source
Q2–Q4
Onboard scanning tooling per platform; extend baselines to remaining priority patterns; pattern release process updated to ship a baseline with every pattern.
Scan coverage ≥70% of pattern-specified estate
Indicative
3 - Federate & automate
Year 2 H1
Automated monthly cut with drift alerting; accepted deviations carry owners and expiry (feeds ODM-11).
Coverage ≥95%; drift MTTD under 30 days
PLA-grade
4 - Institutionalise
Ongoing
No pattern published without a baseline; conformance in platform teams’ service reviews.
Baseline-with-pattern rule enforced at design authority
Sustained
4. Readiness ladder - Platform teams and the Architecture Repository owner
Level
Criteria
Target
L0
Patterns exist as documents only; no conformance checking
-
L1
Top patterns have machine-checkable baselines; manual sampling running
End of Stage 1
L2
Platform onboarded to scanning; CI-to-pattern mapping maintained
End of Stage 2
L3
Drift alerting live; deviations managed with owners and expiry
During Stage 3
L4
Automated monthly reporting; baseline ships with every pattern release
With Stage 3–4
5. Quality and anti-gaming controls
Risk
Effect
Control
Blind-spot conformance
Unscanned estate flatters the number
Report scan coverage alongside; treat unscanned as non-conformant in the headline
Stale baselines
Teams fail against outdated rules and lose faith
Baselines version-controlled with the pattern; grace period on pattern updates
Pattern forking
Teams copy-adapt patterns and claim conformance to their fork
Conformance is to the published version only; forks surface as deviations for design authority decision
Gaming by exclusion
Deployments argued out of pattern scope
Scope decided by the repository mapping, not the delivery team
6. Asks of Platform teams and the Architecture Repository owner
#
Ask
1
Onboard platform estates to configuration/IaC scanning
2
Maintain CI-to-pattern mapping in the CMDB
3
Ship a machine-checkable baseline with every pattern release
4
Manage deviations with owner and expiry, not silent acceptance
ODM-04 · Implementation roadmap
Requirements Traceability Integrity
KCI · % of Tier-1 changes · Green ≥95, Amber ≥85 (illustrative pending PLA negotiation) · Owner: Security Solutions Architecture lead · Consumer: Change / Programme Boards · Cadence: Quarterly, reported with coverage. Organising principle: The chain is the deliverable. Tooling can be federated across PMOs if every Tier-1 project maintains requirement→control→evidence links in whatever tool it uses - the trace is snapshotted at the go-live gate.
Percentage of Tier-1 changes whose security requirements trace to implemented and verified controls at go-live (requirement → control → verification evidence).
Why it matters
The audit-surviving answer to “was what we required actually built?”. It also protects delivery: traceable requirements are testable requirements, and disputes about scope get settled by the record.
Numerator
Tier-1 changes with a complete trace chain at go-live
Publish the ODM value AND coverage (% of Tier-1 changes assessed at gate)
2. The data contract (per security requirement)
#
Field
Notes
1
Requirement ID + source
Catalogue-derived or bespoke; bespoke requires design authority note
2
Project / change ID
Maps to Tier-1 scope
3
Linked control / design element
The thing that satisfies the requirement
4
Verification evidence link
Test result, scan output or review record
5
Status at go-live
Verified / waived (with risk acceptance) / open
6
Gate snapshot date
Trace assessed and frozen at the go-live gate
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence
0 - Define
4–6 weeks
Publish the chain definition and minimal linkage convention per tool (Jira/ADO field mapping). Agree the gate snapshot rule.
Convention signed by pilot PMO and test lead
-
1 - Manual baseline
Q1–Q2
Manual traceability audit at go-live gates on pilot Tier-1 projects; broken links logged and classified.
Two quarterly cuts; broken-link taxonomy stable
Directional
2 - Standardise at source
Q2–Q4
Linkage fields configured in each PMO’s tooling; evidence attachment made mandatory in test workflow; requirements catalogue adoption pushed to reduce bespoke sprawl.
≥70% Tier-1 coverage at gate
Indicative
3 - Federate & automate
Year 2 H1
Automated broken-link reports per project; gate report generated from tooling. Negotiate PLA target.
≥90% coverage; gate report automated
PLA-grade
4 - Institutionalise
Ongoing
Trace report is a standing go-live gate artefact; catalogue requirements version-managed.
Gate rule enforced without exception process abuse
Sustained
4. Readiness ladder - PMOs, Test/QA and Requirements-tooling owners
Level
Criteria
Target
L0
Requirements in documents; no linkage to controls or evidence
-
L1
Security requirements itemised in tracker with IDs
Pilot by end of Stage 1
L2
Requirement→control linkage maintained; evidence attached at test
Evidence link mandatory for “verified”; QA sample links quarterly
Bespoke requirement sprawl
Untestable one-off requirements bypass the catalogue
Bespoke requires design authority note; sprawl reported per project
Trace decay after go-live
Chain rots and misleads later assurance
Snapshot at gate is the record of account; in-life changes handled by ODM-03/10
Tool migration breaks links
Coverage collapses during PMO tooling changes
Contract is tool-agnostic; migration plans must include link preservation
6. Asks of PMOs, Test/QA and Requirements-tooling owners
#
Ask
1
Adopt the linkage convention in local tooling
2
Make evidence attachment mandatory at test completion
3
Produce the trace report at every Tier-1 go-live gate
4
Route bespoke requirements through the design authority
ODM-05 · Implementation roadmap
Third-Party Assurance Coverage
KRI · % · Green 100 critical suppliers, Amber ≥90 (illustrative pending PLA negotiation) · Owner: Enterprise Security Architecture lead · Consumer: CPO / Supplier Board · Cadence: Quarterly; expiry alerts monthly. Organising principle: The tier list is the metric’s foundation and its most political artefact. Settle tiering criteria and ownership before arguing about assessment methods - a perfect assessment of the wrong supplier list measures nothing.
Percentage of critical suppliers holding current security assurance within agreed thresholds (assessment age, score, remediation status); high-tier suppliers reported alongside.
Why it matters
Supply chain is where other people’s immaturity becomes your incident. This metric turns “we assess our suppliers” from an assertion into a coverage statement with named gaps.
Numerator
Critical suppliers with in-date, in-threshold assurance
Denominator
All suppliers on the critical tier list
Currency
Assessment age within cadence for tier; remediation actions within SLA
Reporting rule
Critical and high tiers reported separately - never blended into one flattering number
2. The data contract (per supplier)
#
Field
Notes
1
Supplier ID
From the contract register - the authoritative population
2
Tier
Critical / high / standard, per agreed criteria
3
Last assessment date + method
Evidence-based for critical; questionnaire acceptable below
4
Outcome / score
Against the agreed scheme
5
Remediation status
Open actions with due dates
6
Contract references
Renewal date; security schedule version
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence
0 - Define
4–6 weeks
Agree tiering criteria (data access, service criticality, connectivity) and name the tier-list owner. Baseline the critical list from the contract register.
Tier list baselined and owned
-
1 - Manual baseline
Q1–Q2
Reconcile existing assessments against the critical list; publish first coverage cut with gaps named.
Two quarterly cuts; gap list actioned
Directional
2 - Standardise at source
Q2–Q4
Assessment cadence per tier agreed; expiry alerting from the register; evidence-based method for critical tier; assurance clauses into renewal templates.
New critical suppliers invisible; departed ones flatter coverage
Population from the contract register, not memory; annual tier review plus trigger on M&A/new contracts
Questionnaire theatre
Currency without assurance
Evidence-based method mandatory for critical tier; sample-audit questionnaire answers below it
Blended reporting
High-tier gaps hidden inside a healthy critical number
Tiers reported separately by contract
Assessment backlog dumping
Coverage spikes from bulk low-quality reviews before reporting
Method and reviewer recorded per assessment; QA sample quarterly
6. Asks of Procurement and Supplier Management
#
Ask
1
Own and maintain the tier list from the contract register
2
Operate expiry alerting and assessment scheduling
3
Adopt evidence-based assessment for the critical tier
4
Make assurance status a renewal gate from Stage 2
5
Notify tier-list owner on M&A and major contract changes
ODM-06 · Implementation roadmap
Procurement Security Cycle Time
KPI · working days (median) · Green ≤10, Amber ≤15 (illustrative pending PLA negotiation) · Owner: Security Solutions Architecture lead · Consumer: CPO / Procurement · Cadence: Quarterly, segmented by category. Organising principle: Define the start and stop events with procurement, not for them. Most cycle-time disputes are definition disputes; a shared clock ends them.
Median working days from procurement engagement to issue of security requirements for RFP/contract.
Why it matters
This is the metric that buys goodwill: security volunteering to be measured on its own responsiveness. It protects procurement velocity as an explicit business value and disarms the “security slows everything” narrative with data.
Clock start
Procurement initiation record naming a security-relevant category (not when security happens to hear about it)
Clock stop
Security requirements issued to the procurement (versioned document or workflow state)
Median, segmented
Reported by category/complexity - framework call-offs and bespoke builds are different populations
Reporting rule
Publish the ODM value AND coverage (% of security-relevant procurements with both timestamps)
Days waiting vs days in active security work (optional but diagnostic)
6
Outcome
Requirements issued / not required / escalated
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence
0 - Define
3–4 weeks
Agree start/stop events and security-relevant categories with procurement. Publish the requirement pattern library for common categories.
Shared clock definition signed
-
1 - Manual baseline
Q1
SSA team logs engagements and issue dates in a simple register; first median published by category.
One quarterly cut with segmentation
Directional
2 - Standardise at source
Q2–Q3
Timestamps captured in procurement workflow tooling; requirement patterns cover top categories so routine cases are near-instant.
≥70% of security-relevant procurements timestamped at source
Indicative
3 - Federate & automate
Q4–Year 2
Automated quarterly cut from workflow; queue-vs-work split reported; PLA target negotiated both ways (security commits to cycle time, procurement commits to early notification).
≥90% coverage; two-sided PLA agreed
PLA-grade
4 - Institutionalise
Ongoing
Cycle time in mutual SLAs; stuck-case escalation route operating.
Escalations rare and resolved in-quarter
Sustained
4. Readiness ladder - Procurement and the SSA team (jointly)
Level
Criteria
Target
L0
Security engaged by email, late, untracked
-
L1
Engagements logged with dates in a register
End of Stage 1
L2
Workflow timestamps at source; categories applied
End of Stage 2
L3
Pattern library covers top categories; queue/work split visible
During Stage 3
L4
Automated reporting; two-sided SLA operating
With Stage 3–4
5. Quality and anti-gaming controls
Risk
Effect
Control
Late engagement gaming
Clock started late makes security look fast while procurements still stall
Clock starts at procurement initiation, not security awareness - that is the point of the shared definition
Mix shift
Median moves because case mix changed, not performance
Always segment by category; never report one blended median
Email-shadow procurement
Cases bypass the workflow and the metric
Coverage reported; unlogged cases surfaced at the joint review
Speed over substance
Fast issuance of boilerplate requirements
Pair with ODM-04/05 quality signals; pattern library keeps speed and substance compatible
6. Asks of Procurement and the SSA team (jointly)
#
Ask
1
Adopt the shared clock definition and categories
2
Capture both timestamps in workflow tooling
3
Notify security at procurement initiation for relevant categories
4
Joint quarterly review of stuck cases and the segmented median
ODM-07 · Implementation roadmap
Regulatory Trace Completeness
KRI · % of obligations · Green ≥95, Amber ≥85 (illustrative pending PLA negotiation) · Owner: Enterprise Security Architecture lead · Consumer: CISO / Risk Committee · Cadence: Quarterly; regime-by-regime rollout. Organising principle: One regime at a time. A complete, defensible trace for the ISO 27001 SoA beats a shallow gesture at every regulation; each completed regime becomes the template for the next.
Percentage of in-scope regulatory obligations (UK GDPR, NIS, ISO/IEC 27001 SoA) with a demonstrable obligation → control → architecture evidence chain.
Why it matters
Audit-readiness becomes a state rather than a quarterly panic. The same chain answers regulators, certification auditors and insurers - built once, cited many times.
Numerator
Obligations with complete obligation→control→architecture-evidence chains
Denominator
All obligations in the in-scope regimes (declared scope)
Regime scope declared and version-controlled; changes need risk committee sign-off
6. Asks of GRC function and the Architecture Repository owner
#
Ask
1
Name a single owner per regime register
2
Fund the regime-1 mapping sprint
3
Adopt the repository linkage convention
4
Route regulatory change through the register update process
5
Prioritise GRC-repository integration in Year 2
ODM-08 · Implementation roadmap
Design-Attributable Audit Findings
KRI · count per year · Green ≤2 (none critical), Amber ≤4 (illustrative pending PLA negotiation) · Owner: Enterprise Security Architecture lead · Consumer: CISO / Audit Committee · Cadence: Per audit; reported annually with 3-year rolling context. Organising principle: This is a partnership metric - the data belongs to audit. Approach it as a joint classification exercise with the audit function, or it will die of contested attribution.
Count of internal and external audit findings in the period whose root cause is an architecture or design defect.
Why it matters
The lagging, independent proof of the whole framework: if design quality is genuinely improving, it eventually shows up as clean audits. Because the evidence comes from audit rather than from security, it is unusually hard to dismiss.
Numerator
Findings root-caused to architecture/design defects (joint classification)
Population
All internal/external audit findings in the period
Small-number handling
Annual count reported with 3-year rolling trend - single-year swings are noise
Reporting rule
Classification jointly signed by audit and ESA; disputes recorded, not buried
2. The data contract (per audit finding)
#
Field
Notes
1
Finding ID + audit reference
From the audit findings register
2
Severity
Audit’s own scale, mapped once
3
Root-cause class
Agreed taxonomy: design / configuration / process / people / vendor
4
Design-attributable flag
Joint audit + ESA sign-off
5
Linked remediation
Tracks closure and connects to ODM-11 where accepted as debt
6
Classification date + classifiers
Accountability for the judgement
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence
0 - Define
4–6 weeks
Agree the root-cause taxonomy and joint classification protocol with the audit function. Settle access to the findings register.
Taxonomy and protocol signed by audit leadership
-
1 - Retrospective baseline
Q1–Q2
Jointly classify the last 24 months of findings; publish the baseline with rolling context.
Baseline classified; disputes documented
Directional
2 - Standardise at source
Q2–Q4
Classification step embedded in finding-closure workflow; new findings classified within 30 days of issue.
All new findings classified in-cycle
Indicative
3 - Trend & negotiate
Year 2
Two audit cycles of consistent classification; PLA target negotiated with audit committee awareness.
Stable classification across cycles
PLA-grade
4 - Institutionalise
Ongoing
Audit planning consumes the trend (risk-based audit scoping); design authority reviews every design-attributable finding.
Findings feed pattern/standard updates
Sustained
4. Readiness ladder - Internal Audit and the ESA function (jointly)
Consistent classification across audit cycles; disputes rare
During Stage 3
L4
Trend informs audit planning and design authority action
With Stage 4
5. Quality and anti-gaming controls
Risk
Effect
Control
Contested attribution
Every finding argued out of “design” - count collapses to zero credibility
Joint sign-off protocol; disputes recorded with both positions; annual calibration session
Small-n noise
One bad audit year read as systemic failure
3-year rolling reporting; narrative on each finding, not just the count
Perverse dispute incentive
Teams fight findings to protect the metric
The metric measures the design system, not teams - findings drive pattern fixes, not blame
Independence sensitivities
Audit resists co-owning a security metric
Frame as root-cause enrichment of their data; audit retains final classification authority
6. Asks of Internal Audit and the ESA function (jointly)
#
Ask
1
Agree the root-cause taxonomy and joint protocol
2
Grant register access for classification
3
Add the classification step to finding closure
4
Join an annual calibration session with the design authority
ODM-09 · Implementation roadmap
Standards Currency
KCI · % · Green ≥90, Amber ≥75 (illustrative pending PLA negotiation) · Owner: Operational Security Architecture lead · Consumer: Design Authority · Cadence: Monthly report; quarterly review. Organising principle: Currency fails from capacity, not intent. The roadmap is mostly about making review workload visible and planned - the reporting is trivial once owners and dates exist.
Percentage of technical security standards reviewed and reissued within their defined review cycle (12 or 24 months by class).
Why it matters
Stale standards are worse than no standards: teams conform to obsolete guidance with full confidence. Currency is the cheapest health signal for the whole standards estate.
Numerator
Standards with a completed review inside their cycle
A review must produce either changes or a recorded “reviewed, no change required” rationale - re-dating alone does not count
2. The data contract (per standard)
#
Field
Notes
1
Standard ID + title
From the standards register
2
Class
12- or 24-month cycle, assigned by design authority
3
Owner
Named individual, not a team
4
Last review date + outcome
Changed / no-change-with-rationale
5
Next review due
Derived; drives expiry flags
6
Status
Current / due / overdue / retired
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence
0 - Define
3–4 weeks
Inventory all standards; assign owners and review classes; retire the dead ones honestly.
Register complete with owners and classes
-
1 - Manual baseline
Q1
Publish first currency cut; overdue standards triaged into a review backlog.
Baseline published; backlog sized
Directional
2 - Standardise at source
Q1–Q3
Review-date and outcome fields mandatory; expiry flags automated; review workload scheduled into team plans.
Overdue backlog cleared or explicitly rescheduled
Indicative
3 - Automate & negotiate
Q4
Monthly automated report; PLA target set with design authority.
Two clean monthly cycles
PLA-grade
4 - Institutionalise
Ongoing
Currency in the design authority dashboard; class assignments reviewed annually.
Sustained ≥ target with stable capacity
Sustained
4. Readiness ladder - Design Authority and standard owners
Level
Criteria
Target
L0
Standards undated, unowned, of unknown vintage
-
L1
Register complete; owners and classes assigned
End of Stage 0
L2
Review outcomes recorded; expiry flagging live
End of Stage 2
L3
Review capacity planned; backlog managed
During Stage 2–3
L4
Automated monthly reporting to design authority
With Stage 3
5. Quality and anti-gaming controls
Risk
Effect
Control
Re-date rubber-stamping
Currency without review
Outcome field mandatory; “no change” requires rationale; QA sample reviews
Orphaned standards
Org change leaves standards ownerless and silently overdue
Ownership by role with named holder; orphan report monthly
Class inflation
Everything argued into the 24-month class
Class assignment owned by design authority, reviewed annually
Retirement avoidance
Dead standards padding the denominator
Explicit retirement path; register hygiene in the annual review
6. Asks of Design Authority and standard owners
#
Ask
1
Name an owner for every standard
2
Approve class assignments and hold them
3
Plan review capacity in team schedules
4
Retire dead standards rather than ignoring them
ODM-10 · Implementation roadmap
Control-Objective Coverage
KRI · % of Tier-1 objectives · Green ≥95, Amber ≥85 (illustrative pending PLA negotiation) · Owner: Enterprise Security Architecture lead · Consumer: Domain Owners / Risk Committee · Cadence: Quarterly, reported with modelling coverage. Organising principle: Model two domains deeply before touting breadth. The SRM chain (domain → control objective → control → mechanism) must exist in the repository for a domain before its coverage means anything; two credible domains beat ten hollow ones.
Percentage of Tier-1 domain control objectives realised by at least one implemented, operating control, with residual gaps formally risk-accepted by the domain owner.
Why it matters
The flagship coverage claim: “critical domains are demonstrably protected end-to-end”. It is also the framework’s most demanding metric - it cannot exist until control objectives are modelled per domain.
Numerator
Tier-1 control objectives realised by ≥1 implemented AND operating control (assurance-evidenced)
Denominator
All control objectives across modelled Tier-1 domains
Gap handling
Unrealised objectives require a domain-owner risk acceptance with expiry - silence is a red flag, not a gap
Reporting rule
Publish the ODM value AND modelling coverage (% of Tier-1 domains with objectives modelled); pair with ODM-03 so paper claims meet the running estate
2. The data contract (per control objective)
#
Field
Notes
1
Domain + objective ID
From the architecture repository (SRM conceptual layer)
2
Realising control(s)
Logical controls mapped to the objective
3
Implementation status
Deployed mechanisms/CIs from CMDB
4
Operating evidence
Control assurance/testing result within cycle
5
Gap risk-acceptance record
Owner, rationale, expiry
6
Last assessed date
Chain re-validated per cycle
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence
0 - Define
6–8 weeks
Select two pilot Tier-1 domains with engaged owners. Model 8–15 control objectives per domain in the repository.
Two domains modelled; owners signed up
-
1 - Manual baseline
Q1–Q2
Map objectives→controls→CIs; classify each objective (realised / partial / gap); domain owners risk-accept or fund gaps.
Pilot coverage published; every gap owned
Directional
2 - Standardise at source
Q2–Q4
Add assurance linkage (operating evidence, not just deployed). Extend modelling to next 3–4 Tier-1 domains using the pilot template.
Modelling coverage ≥50% of Tier-1 domains
Indicative
3 - Federate & automate
Year 2
Repository–CMDB–assurance joins automated; quarterly cut generated; PLA negotiated with domain owners and risk committee.
Modelling coverage ≥90%; automated reporting
PLA-grade
4 - Institutionalise
Ongoing
New domains modelled at policy creation; coverage standing item at risk committee.
No Tier-1 domain unmodelled >2 quarters
Sustained
4. Readiness ladder - Domain Owners and the ESA/repository function
Level
Criteria
Target
L0
Domain has no modelled control objectives
-
L1
Objectives modelled (8–15) with an engaged owner
Pilot domains by Stage 0–1
L2
Controls mapped to objectives; gaps classified and risk-accepted
End of Stage 1–2
L3
Operating evidence linked (assurance results in cycle)
During Stage 2–3
L4
Automated chain validation; drift from ODM-03 reconciled
With Stage 3
5. Quality and anti-gaming controls
Risk
Effect
Control
Paper coverage
Chains complete in the repository, absent in production
Mandatory pairing with ODM-03 configuration scans; “operating” requires assurance evidence
Granularity wars
500 micro-objectives or 3 vague ones make the % meaningless
8–15 objectives per domain, calibrated by design authority across domains
Owner disengagement
Gaps unowned; acceptance theatre
Risk acceptance is the owner’s act, with expiry; unaccepted gaps escalate to risk committee by default
Modelling stall
Two pilot domains forever
Modelling coverage reported beside the ODM - the unmodelled estate stays visible
6. Asks of Domain Owners and the ESA/repository function
#
Ask
1
Sponsor modelling for your domain and own the gaps
2
Risk-accept or fund every unrealised objective - with expiry
3
Provide assurance results for operating evidence
4
Fund repository modelling capacity through Stage 2
ODM-11 · Implementation roadmap
Security Debt Exposure
KRI · weighted index · Green ≤100 and falling, Amber ≤130 (illustrative pending PLA negotiation) · Owner: Enterprise Security Architecture lead · Consumer: Risk Committee · Cadence: Monthly register hygiene; quarterly index. Organising principle: Hygiene before index. An index computed over a register full of ownerless, expiry-less items is theatre; the first quarter’s work is making every item carry an owner, a severity and an expiry.
Weighted index (severity × age) of open security technical-debt items and design exceptions on critical domains; no exception older than 12 months without owner re-authorisation.
Why it matters
Risk debt is what accumulates in the gap between “accepted for now” and “forgotten forever”. The index makes the accumulation visible, owned and priced - and the 12-month rule forces the forgetting to stop.
Index
Σ (severity weight × age factor) across open items on critical domains, normalised to baseline = 100
Population
Design exceptions + technical debt items from all sources (CAB, design reviews, assessments, ODM-03 deviations)
The 12-month rule
Any exception older than 12 months without re-authorisation is escalated automatically
Reporting rule
Index reported with the top-5 items narrated - a number without its stories misleads
2. The data contract (per debt item / exception)
#
Field
Notes
1
Item ID + type
Exception / debt; source recorded
2
Domain + affected assets
Maps to critical domains for weighting
3
Severity
Common 4-point scale
4
Raised date
Drives the age factor
5
Owner + expiry
Mandatory; no item without both
6
Remediation path + re-authorisation history
Evidence that acceptance is a decision, not a default
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence
0 - Define
4–6 weeks
Agree the register schema and weights with the risk committee (then freeze weights for 12 months). Identify all exception sources.
Schema agreed; weights frozen; sources listed
-
1 - Hygiene sprint
Q1
Consolidate items into the schema (register can stay federated); assign owners, severities, expiries to every item. Kill duplicates.
100% of items carry owner/severity/expiry
Directional
2 - Baseline & routine
Q2–Q3
Baseline the index at 100. Monthly orphan report; CAB and design review feeds create items at source; ODM-03 deviations flow in.
Two quarterly index cuts; orphan count ~zero
Indicative
3 - Automate & negotiate
Q4–Year 2
Automated index computation; expiry-driven re-authorisation workflow; PLA target (trajectory, not point) negotiated.
Re-authorisation workflow live; index trend credible
PLA-grade
4 - Institutionalise
Ongoing
Debt burn-down tranches priced in planning; index trajectory reviewed quarterly at risk committee.
Burn-down funded against trajectory
Sustained
4. Readiness ladder - Risk function and exception-source owners (CAB, design authority)
Level
Criteria
Target
L0
Exceptions scattered, verbal, or expired-in-place
-
L1
All items in schema with owner, severity, expiry
End of Stage 1
L2
New items created at source (CAB, reviews, scans)
End of Stage 2
L3
Expiry-driven re-authorisation operating
During Stage 3
L4
Automated index; burn-down tranches in planning
With Stage 3–4
5. Quality and anti-gaming controls
Risk
Effect
Control
Weight-fiddling
Index “improves” by re-weighting, not remediating
Weights frozen for 12 months; changes need risk committee sign-off and restated history
Bulk closures
Items closed without remediation evidence before reporting
Closure requires evidence or formal risk-acceptance renewal; closures QA-sampled
Shadow exceptions
Verbal acceptances at CAB never reach the register
CAB workflow creates the item automatically; minutes audited quarterly
Index without narrative
A falling number hides one monstrous item
Top-5 items narrated in every report; single-item concentration flagged
6. Asks of Risk function and exception-source owners (CAB, design authority)
#
Ask
1
Sign off the schema and weights, then hold them
2
Resource the hygiene sprint
3
Create items at source in CAB and review workflows
4
Operate the 12-month re-authorisation rule without exception
ODM-12 · Implementation roadmap
Roadmap Delivery
KPI · % of milestones · Green ≥80, Amber ≥65 (illustrative pending PLA negotiation) · Owner: Security Solutions Architecture lead · Consumer: CISO / Investment Board · Cadence: Quarterly. Organising principle: The baseline is the metric. Without change control on plan dates, the target is met by quietly moving it; the entire delivery effort here is baseline discipline, which the portfolio office already knows how to run.
Percentage of security capability roadmap milestones delivered within one quarter of the baselined plan.
Why it matters
Investment credibility. The board funded a roadmap; this is the metric that says whether funding turns into capability - and it is the first metric a sceptical CFO will check against reality.
Numerator
Milestones delivered within +1 quarter of baselined date
Denominator
Milestones due in the period per the baseline
Baseline rule
Plan dates change only via approved re-baseline; history preserved
Reporting rule
Variance reasons classified (security-controllable vs external dependency) - the metric should drive the right conversation
4. Readiness ladder - Portfolio Office and the security capability owners
Level
Criteria
Target
L0
Roadmap is a slide; dates move freely
-
L1
Baselined milestones with DoD
End of Stage 0
L2
Tracked in portfolio tooling; re-baseline governed
End of Stage 2
L3
Variance taxonomy applied consistently
During Stage 2–3
L4
Automated reporting into investment governance
With Stage 3
5. Quality and anti-gaming controls
Risk
Effect
Control
Baseline drift
Target met by moving dates
Re-baseline requires approval; original dates preserved and reported
Milestone inflation
“Phase 1 delivered” by renaming half the scope
Definition of done fixed at baseline; delivery verified against it
External-dependency fog
Slippage blamed outward without evidence
Variance taxonomy separates controllable from external; chronic external causes escalated as their own issue
Sandbagging
Trivially safe dates guarantee green
Investment board reviews baseline ambition, not just delivery %
6. Asks of Portfolio Office and the security capability owners
#
Ask
1
Run re-baseline governance and preserve history
2
Track milestones with DoD in portfolio tooling
3
Classify variance honestly by the taxonomy
4
Review ambition and delivery together at the investment board
ODM-13 · Implementation roadmap
Architectural Lessons Closed
KPI · % of P1/P2 incidents · Green 100 within 90 days, Amber ≥80 (illustrative pending PLA negotiation) · Owner: Security Solutions Architecture lead · Consumer: CISO / Resilience Board · Cadence: Quarterly; cumulative view for small numbers. Organising principle: The lesson must land as a published artefact change, not a lessons-learned document. Documents are where lessons go to be forgotten; patterns and standards are where they change the next design.
Percentage of P1/P2 security incidents whose architectural lessons produce a published pattern or standard change within 90 days of incident closure.
Why it matters
Incidents are the most expensive design reviews you will ever run - this metric makes sure you collect the findings. It is the difference between an organisation that has ten years of experience and one that has one year of experience ten times.
Numerator
P1/P2 incidents with a published pattern/standard change within 90 days of closure
Denominator
P1/P2 security incidents closed in the period (including “reviewed, no architectural lesson” with rationale)
The clock
Starts at incident closure; stops at publication of the artefact change
Reporting rule
Small quarterly numbers reported cumulatively over rolling 12 months; adoption of changes checked via ODM-03
2. The data contract (per P1/P2 incident)
#
Field
Notes
1
Incident ID + priority
From incident management tooling
2
Closure date
Clock start
3
Architectural RCA (Y/N + date)
RCA template carries a mandatory architecture section
4
Lesson classification
Pattern change / standard change / no architectural lesson (with rationale)
5
Artefact change reference + publish date
Repository change record - the evidence
6
Adoption check
Downstream conformance via ODM-03 where applicable
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence
0 - Define
3–4 weeks
Add the architecture section to the P1/P2 RCA template; agree the closure-gate rule with incident management.
Template updated; gate rule agreed
-
1 - Manual baseline
Q1–Q2
Track incidents on a simple sheet; SSA reviews each P1/P2 RCA; first cumulative cut published.
All P1/P2 RCAs reviewed; first cut out
Directional
2 - Standardise at source
Q2–Q4
Pattern/standard change referencing convention; incident closure blocked until the architecture section is complete; 90-day tracking automated from the sheet.
No P1/P2 closes without architectural review
Indicative
3 - Automate & negotiate
Year 2
Join incident records to repository change records; automated quarterly cut; PLA negotiated with resilience board.
Operational scapegoats, no architectural lesson found
RCA template forces the architecture question; SSA reviews every P1/P2 RCA
Slow-closure gaming
Incidents held open to defer the 90-day clock
Incident closure SLAs owned by incident management; both clocks reported
Published ≠ adopted
Pattern changed, estate unchanged
Adoption checked via ODM-03 conformance for affected patterns
Lesson inflation
Trivial edits claimed as lessons to hit 100%
Design authority validates the change is substantive; “no lesson, here’s why” is an acceptable and honest outcome
6. Asks of Incident Management / SOC and the Design Authority
#
Ask
1
Adopt the RCA architecture section and closure gate
2
Reference repository changes from incident records
3
Hold the joint quarterly lessons review
4
Accept “no architectural lesson” only with recorded rationale
ODM-14 · Implementation roadmap
Resilience Design Verification
KCI · % of critical services · Green ≥95, Amber ≥85 (illustrative pending PLA negotiation) · Owner: Operational Security Architecture lead · Consumer: Service Owners / Resilience Board · Cadence: Quarterly; rolling 12-month window. Organising principle: The criticality list is the battleground; settle its ownership first. Every service argued off the list is a blind spot with a lobbyist - the list belongs to the resilience board, not to service teams.
Percentage of critical services whose recovery architecture has been exercised within 12 months and met agreed RTO/RPO - including compromise-recovery variants.
Why it matters
Backups that have never restored and failovers that have never failed over are hopes, not capabilities. This metric converts recovery from an assertion in a document to a demonstrated, dated result.
Numerator
Critical services exercised within 12 months meeting agreed RTO/RPO
Denominator
All services on the resilience board’s criticality list
Exercise validity
Result recorded against RTO/RPO targets; exercise type recorded (desktop / partial / full / compromise-recovery)
Reporting rule
Exercise depth mix reported alongside the % - twelve desktop walkthroughs are not a recovery capability
2. The data contract (per critical service)
#
Field
Notes
1
Service ID + criticality tier
From the owned criticality list
2
RTO / RPO targets
Agreed with the service owner; versioned
3
Last exercise date + type
Desktop / partial / full / compromise-recovery
4
Result vs RTO/RPO
Measured, not asserted
5
Findings + actions
With owners and due dates
6
Next exercise due
Drives the calendar
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence
0 - Define
4–6 weeks
Resilience board confirms ownership of the criticality list and the exercise-validity rules; result-recording template published.
List owned; rules and template agreed
-
1 - Baseline & triage
Q1–Q2
Reconcile exercise history against the list (expect a large unexercised backlog); publish the honest baseline; build the exercise calendar.
Baseline published; calendar covers the backlog
Directional
2 - Standardise
Q2–Q4
Exercises run to calendar with results in the template; depth rotated (desktop → partial → full); findings tracked to closure.
On-calendar exercise rate ≥80%
Indicative
3 - Extend & negotiate
Year 2
Compromise-recovery variants added for top-tier services; automated reporting from the exercise register; PLA negotiated.
Top tier has compromise-recovery evidence
PLA-grade
4 - Institutionalise
Ongoing
Exercise cadence funded in service budgets; list reviewed annually and on major change.
Cadence survives budget cycles
Sustained
4. Readiness ladder - Resilience Board and Service Owners
Level
Criteria
Target
L0
No owned criticality list; exercises ad hoc
-
L1
List owned; exercise history baselined
End of Stage 0–1
L2
Calendar operating; results recorded vs RTO/RPO
End of Stage 2
L3
Depth rotation including full failover for top tier
Template requires measured times; unmeasured exercises do not count
Scope shrink
The easy component exercised, the service claimed
Exercise scope defined per service in the validity rules
Criticality-list politics
Services lobby off the list to escape the calendar
List owned by resilience board; removals need board sign-off with rationale
Exercise fatigue
Full failovers everywhere burn teams and budgets
Depth rotation by tier - full for top tier, partial/desktop below, all measured
6. Asks of Resilience Board and Service Owners
#
Ask
1
Own the criticality list and its changes
2
Fund the exercise cadence in service budgets
3
Record results against RTO/RPO in the template
4
Accept compromise-recovery exercising for top-tier services
ODM-15 · Implementation roadmap
Early Engagement Rate
KPI · % of Tier-1 initiatives · Green ≥90, Amber ≥75 (illustrative pending PLA negotiation) · Owner: Security Solutions Architecture lead · Consumer: CIO / Delivery Leadership · Cadence: Quarterly, reported with coverage. Organising principle: Measure the relationship, not just the compliance. An engagement rate enforced as a gate but resented in practice will be gamed; pair the rate with security’s own responsiveness (review turnaround, CI-03) so both sides are visibly held to the bargain.
Percentage of in-scope (Tier-1) initiatives with security architecture engagement completed before build commences.
Why it matters
The framework’s best leading indicator: when early engagement falls, design defects and rework follow within two quarters. It is also the cultural metric - it measures whether teams come to security by default or under duress.
Numerator
Tier-1 initiatives with a qualifying engagement before the build-start event
Denominator
All Tier-1 initiatives passing build-start in the period
Qualifying engagement
Defined minimum (scoping session + risk view), not a calendar invite
Reporting rule
Publish the ODM value AND the tier-classification coverage; report security’s review turnaround beside it
2. The data contract (per initiative)
#
Field
Notes
1
Initiative ID + tier
Tier assigned by criteria owned outside delivery
2
Build-start event date
Defined per methodology (first sprint of build / development gate)
3
Engagement date + type
Scoping / threat review / design session
4
Engagement outcome
Proceed / conditions / escalate
5
Engaging architect
Capacity and coverage planning
6
Source
Pipeline gate telemetry or engagement log
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence
0 - Define
3–4 weeks
Agree Tier-1 criteria and their owner; define the build-start event per methodology and the qualifying-engagement minimum.
Criteria and definitions signed
-
1 - Manual baseline
Q1
Engagement log maintained by the SSA team; first quarterly cut against the initiative register.
One cut published with coverage
Directional
2 - Standardise at source
Q2–Q3
Pipeline/gate tooling captures engagement status; tier classification applied at intake; engagement becomes a gate precondition for Tier-1.
≥80% of Tier-1 flowing through instrumented gates
Indicative
3 - Automate & negotiate
Q4–Year 2
Automated quarterly cut from gate telemetry; PLA negotiated with delivery leadership - two-sided with security’s turnaround commitment.
Two-sided PLA agreed
PLA-grade
4 - Institutionalise
Ongoing
Engagement default in delivery playbooks; repeat-engagement (teams returning voluntarily) tracked as the culture signal.
Voluntary early engagement rising
Sustained
4. Readiness ladder - PMOs and Delivery-pipeline owners
Level
Criteria
Target
L0
Security discovers initiatives at go-live
-
L1
Initiative register visible; engagements logged
End of Stage 1
L2
Tier applied at intake; gates instrumented
End of Stage 2
L3
Engagement precondition enforced with an exception path
Two-sided PLA: security is measured on turnaround in the same report
Capacity failure
Engagement demand exceeds architect supply and the gate becomes the bottleneck
Engagement volume forecast from pipeline; capacity escalated before the gate jams
6. Asks of PMOs and Delivery-pipeline owners
#
Ask
1
Adopt tier classification at intake
2
Instrument gates to capture engagement status
3
Enforce the precondition with a sane exception path
4
Hold security to its turnaround commitment in the same review
ODM-16 · Implementation roadmap
Capability Uplift
KPI · composite trend · growth year-on-year (targets set after baseline) · Owner: Enterprise Security Architecture lead · Consumer: CIO / HR (capability) · Cadence: Annual, with in-year indicators. Organising principle: Accreditation must mean something and self-service must stay safe. The design authority owns the accreditation bar; self-served designs are sample-checked for conformance (via ODM-03) so speed never silently trades against quality.
Number of accredited secure-design practitioners in delivery teams, and the percentage of routine designs completed via self-served patterns without security architect escalation.
Why it matters
The scale-out metric: security architecture cannot review its way to a secure estate. Capability uplift measures whether routine secure design is becoming something delivery teams do, freeing scarce architects for the hard problems.
Component 1
Accredited practitioners by team (register, with currency)
Component 2
% of routine (pattern-eligible) designs self-served without escalation
Routine definition
Design classes declared pattern-eligible by the design authority
Reporting rule
Trend-based; self-served share reported WITH its conformance sample result
2. The data contract (per practitioner / design event)
#
Field
Notes
1
Practitioner record
Person, team, accreditation level, date, expiry
2
Accreditation evidence
Assessment against design-authority criteria
3
Design event
Project, design class, pattern used
4
Self-served flag
Completed without architect escalation
5
Escalation reason
Where escalated: complexity / gap / confidence
6
Conformance sample result
From the ODM-03 scan or design spot-check
3. Staged roadmap
Stage
Timeframe
Activity
Exit criteria
Confidence
0 - Define
4–6 weeks
Design authority sets accreditation criteria and the pattern-eligible design classes; register schema agreed with L&D.
Criteria and classes published
-
1 - Baseline
Q1–Q2
Count existing practitioners against criteria (expect a small, honest number); baseline self-served share from project records - manual is fine.
Baseline published
Directional
2 - Build
Q2–Year 2
Training pathway live with L&D; pattern library made genuinely self-serveable (guidance, examples, checklists); telemetry started even if manual (pattern pull requests, register lookups).
First cohort accredited; self-serve pathway used
Indicative
3 - Measure & negotiate
Year 2
Trend across two cycles; conformance sampling of self-served designs routine; growth targets agreed with CIO/HR.
Two-cycle trend; conformance holding
PLA-grade
4 - Institutionalise
Ongoing
Accreditation in role profiles for senior engineers; self-serve default for routine classes; architects redeployed to Tier-1 complexity.
Architect time measurably shifted to complex work
Sustained
4. Readiness ladder - L&D / HR and the Design Authority
Level
Criteria
Target
L0
No accreditation; all designs routed through architects
-
L1
Criteria published; baseline counted honestly
End of Stage 1
L2
Training pathway live; first cohort through
During Stage 2
L3
Self-serve operating for eligible classes with sampling
Stage 2–3
L4
Telemetry-based trend; accreditation in role profiles
With Stage 3–4
5. Quality and anti-gaming controls
Risk
Effect
Control
Accreditation inflation
Bar lowered to show growth
Criteria owned by design authority; pass rates and assessor calibration reviewed
Unsafe self-service
Speed bought with silent quality loss
Conformance sampling of self-served designs; share reported with its sample result
Telemetry fantasy
Pattern-usage data assumed where none exists
Manual proxies for year one (PRs, register lookups, project records) - honestly labelled
Attrition masking
Gross accreditations up, net capability flat
Report net practitioners by team; concentration risk flagged
6. Asks of L&D / HR and the Design Authority
#
Ask
1
Co-own the training pathway and accreditation register
2
Hold the accreditation bar at design-authority criteria
3
Declare and maintain the pattern-eligible design classes
4
Fund pattern self-serve usability (examples, checklists) - it is cheaper than architects