A single chain of custody for security intent: what we believe, what we are building toward, what engineers actually consume, what the platform refuses to allow, and how we prove all of it continuously — without asking anyone to file a ticket.
Horizon
36 months, four phases
Domains
Seven
Delivery unit
The paved road
Primary KPI
Adoption, not coverage
01
The model
Seven layers, one direction of travel. The dashed loop on the right is the part most programmes leave out.
Intent — set by the CISO, ratified by the business Design — owned by security architecture Delivery — co-owned with platform engineering Feedback — the loop that keeps the model honest
02
Strategy
Security stops reviewing other people’s work and starts supplying the components they build with.
The thesis
Security scales when it is consumed, not when it is enforced. Every layer above the paved road exists to decide what goes into it; every layer below exists to make deviation visible and expensive. The organisation gets safer at the rate engineers adopt the road — so adoption, not control coverage, is the number that governs the programme.
A reference architecture with no paved road is a slide. A paved road with no guardrail is a suggestion. A guardrail with no assurance is an assumption.
↓
Intent flows down
Principles constrain the target state, which decomposes into seven domains and then into reference architectures. Nothing enters the stack that cannot be traced to a principle.
→
Capability flows across
Reference architectures are productised into paved roads. This is the only layer with users, so it gets a backlog, versions, documentation, support and a deprecation policy.
↑
Evidence flows up
Guardrails produce enforcement telemetry; assurance produces state. Together they answer one question: converging or drifting? When the answer is drift, the fix is a better road.
What changes
Security review becomes security supply. Use this module, not submit for review.
Control catalogues become architecture decisions. The reference architecture records why.
Findings become drift. Distance from an intended state, not an undifferentiated queue.
Exceptions become backlog. Each one names a paved road that is missing.
AI becomes a domain. Agents get identities and entitlements on the same terms as anyone.
What this is deliberately not
Not tool consolidation. Tools are chosen after the decision they implement is written down.
Not a maturity chase. Levels diagnose; the target state is the goal.
Not centralised build. Architecture owns the pattern; teams own the implementation.
Not a gate at the end. Guardrails run where the decision is made.
Not all at once. Two roads used everywhere beat twelve used nowhere.
03
Security principles
Few enough to remember, sharp enough to rule an option out, stable enough that changing one is a governance event.
01Identity is the control planeAccess decisions are made per request against a verified identity and device posture. Network position confers nothing.
02No standing privilegeElevated access is time-bound, justified and recorded. Permanent admin is an exception with an expiry date, never a job description.
03Every workload has a cryptographic identityServices, pipelines and agents authenticate with short-lived, attested credentials. Long-lived secrets are a defect.
04Blast radius is a design inputSegmentation, tenancy and account boundaries are chosen for containment before they are chosen for convenience.
05The secure path is the default pathIf doing the right thing is slower than doing the wrong thing, the road is at fault. Friction is our bug, not the engineer's.
06Provenance over inspectionWe trust artefacts because of how they were built — signed, attested, SBOM-bearing — not because a scanner found nothing.
07Evidence is a by-product of the systemControls emit their own proof continuously. If an auditor's question requires a human to go collect something, the control is incomplete.
08Autonomy does not create an exemptionAI systems and agents are subject to identity, entitlement, logging and change control on the same terms as any other actor.
04
Layer descriptions
What each layer is, who owns it, and the specific way each one fails.
Layer 1 · Intent · Owner: CISO
Security principles
A short, versioned set of design rules that hold regardless of technology. Their job is to settle disagreements without escalation. A good principle rules something out.
Done: Eight to twelve principles, each with a rationale, ratified by the executive and cited by name in decisions.
Fails when: Aspirational language nobody can apply, leaving every decision argued from first principles again.
Layer 2 · Intent · Owner: CISO + business
Target security state
A dated description of the end-state in outcomes, not products: what an attacker cannot do, what an engineer can do unaided, what evidence exists on demand.
Done: A per-domain statement with a horizon, a measurable definition and a named sponsor.
Fails when: Written as a product inventory. “Deploy CNAPP” is a purchase; “drift reverted within 24 hours” is a target state.
Layer 3 · Design · Owner: Security architecture
Domain architectures
Seven problem spaces with distinct engineering audiences and distinct failure modes. Each owns its strategy, its patterns and its slice of the roadmap, under shared principles.
Done: Each domain has a named architect, a current-state assessment, a target state and a paving order.
Fails when: Domains run as separate programmes with separate vocabularies, so nothing composes.
Layer 4 · Design · Owner: Security architecture
Reference architectures
The approved way to solve a recurring problem: components, interfaces, decisions, and the conditions under which the pattern stops applying. A decision record, not a diagram.
Done: Versioned, owned, review-dated, linked to a paved road and traceable to a principle.
Fails when: A beautiful artefact with no implementation path. Teams agree with it, then build something else.
The consumable form of the architecture: modules, pipeline templates, SDKs, platform services, baseline configurations. The only layer most engineers ever touch.
Done: Versioned, documented, supported, tested, with a deprecation policy and adoption telemetry.
Fails when: Published once and left to rot. An unmaintained module teaches engineers that the road is a trap.
The same decision the road implements, expressed as enforcement. Preventive where a clean alternative exists, detective where blocking would break the business.
Done: Policy-as-code in version control, tested, deployed through a pipeline, launched in warn mode with a published block date.
Fails when: Enforcement before paving. The exception queue becomes the real architecture.
Continuous verification that the estate matches intent — posture, supply chain, data, behaviour, controls — reporting distance from target rather than a queue of issues.
Done: One dashboard showing drift, adoption and exceptions per domain, refreshed without human collection.
Fails when: Measuring tool coverage instead of conformance: full agent deployment on an estate that no longer resembles the target.
The loop · Owner: Architecture review board
Evidence revises intent
The loop that makes this an operating model rather than a hierarchy. Findings feed a quarterly review that can amend an architecture, re-prioritise the backlog, or revise a principle.
Done: A standing quarterly item where each domain reports drift, adoption and exception clusters, and leaves with backlog changes.
Fails when: The strategy is refreshed by rewriting the deck, with nothing connecting what the estate does to what the document claims.
05
Domain architectures
Each domain read down the full stack, from where it must end up to the signal that proves it.
Identity
Zero Trust · IAM
Current state
Too many identities · long-lived credentials · inconsistent MFA · standing privileges · manual provisioning and deprovisioning · weak workload identity · limited access visibility. See how each is closed →
Target state
Every access decision — human, service or agent — is evaluated per request against a verified identity, device posture and entitlement. No standing production privilege; no long-lived credentials anywhere in the estate.
Reference architectures, paved roads, guardrails and assurance
Standing privileged accounts (target: zero); % workloads using federated identity; median credential lifetime; JIT elevation coverage.
Network
SASE · ZTNA · Segmentation
Current state
Flat internal networks · vpn as the access path · uncontrolled egress · firewall rules by ticket · unknown internet exposure · ot, clinical and lab estates unsegmented · third-party site-to-site tunnels. See how each is closed →
Target state
User-to-application access is brokered by identity-aware proxy with no flat corporate network behind it. East-west traffic is default-deny within a segment model that bounds any single compromise to one blast zone.
Reference architectures, paved roads, guardrails and assurance
Reference architectures
ZTNA application access; SASE egress and inspection; macro/micro segmentation model; controlled egress with allow-listed destinations; secure OT/clinical/lab enclaves.
Paved roads
Application onboarding to ZTNA in self-service; segment-aware VPC/VNet modules; egress proxy client library; standard firewall policy sets as code.
Guardrails
Deny public ingress by default; no unmanaged egress paths; mandatory network policy on every namespace; peering and route changes gated by policy-as-code.
Assurance signal
% applications behind ZTNA; count of flat/legacy segments remaining; unauthorised egress attempts; internet-exposed asset count with owner.
Cloud
Landing Zone · CNAPP
Current state
Ungoverned accounts and subscriptions · click-built infrastructure · configuration drift goes unnoticed · inconsistent logging · public exposure by default · unowned and untagged resources · inconsistent key management. See how each is closed →
Target state
Every workload runs in a governed landing zone with security baselines inherited from the account or subscription. Configuration drift is detected and reverted automatically; no environment is manually created.
Reference architectures, paved roads, guardrails and assurance
Reference architectures
Multi-account tenancy and organisational unit design; environment topology (dev/test/prod); logging and key management architecture; container platform baseline; disaster recovery pattern.
Paved roads
Account vending machine; Terraform module library for compute, storage, data and networking; hardened base images; centralised logging module; secrets management integration.
Guardrails
Service control policies and Azure Policy at the organisation root; region and service allow-lists; encryption and public-access denials; mandatory tagging; drift auto-remediation.
Assurance signal
% workloads inside a governed landing zone; module-derived infrastructure vs hand-built; drift MTTR; critical CNAPP findings by age.
AppSec
Secure SDLC · CI/CD
Current state
Every team has its own pipeline · unknown third-party components · unsigned artefacts in production · secrets in source · threat modelling done ad hoc · vulnerability backlog without an sla · no disclosure path. See how each is closed →
Target state
Every deployable artefact is produced by a hardened pipeline, signed, SBOM-bearing and provenance-attested. Vulnerability response — including customer-facing disclosure — runs to a defined SLA without heroics.
Reference architectures, paved roads, guardrails and assurance
Reference architectures
Secure build and release pipeline; software supply chain and artefact provenance; SBOM generation and distribution; threat modelling method; PSIRT and coordinated vulnerability disclosure; secrets handling.
Paved roads
Golden pipeline templates per language; pre-commit and pre-merge scanning; signing and attestation service; SBOM as a build artefact; threat model template; dependency curation service.
Guardrails
Only signed artefacts deployable to production; branch protection and required reviews; build-time secret detection blocks merge; severity thresholds break the build; no unsigned base images.
Assurance signal
% builds on golden pipelines; % releases with SBOM and attestation; mean time to remediate by severity; disclosure SLA adherence; exception count per pipeline.
Data
Data Security · DSPM
Current state
Unknown sensitive data locations · classification exists on paper only · production copies in lower environments · keys managed inconsistently · over-permissive data access · no retention or deletion · residency handled per project. See how each is closed →
Target state
Sensitive data is inventoried and classified wherever it lives, with controls — encryption, key custody, masking, retention, residency — applied from the classification rather than negotiated per project.
Reference architectures, paved roads, guardrails and assurance
Reference architectures
Classification scheme and handling matrix; key management and customer-managed key patterns; tokenisation and de-identification; data residency and cross-border transfer; retention and defensible deletion; analytics and lakehouse access model.
Paved roads
Classified storage modules with encryption pre-wired; tokenisation service; de-identification library; data access request workflow; retention policy as code.
Guardrails
Deny unencrypted or public data stores; key policy enforcement; classification tag required at creation; egress DLP on sanctioned channels; residency-constrained region policy.
Assurance signal
% sensitive stores discovered and classified; shadow data-store count; over-permissive data access findings; key rotation compliance; retention policy coverage.
SecOps
Detection Platform · SIEM/XDR
Target state
Detection is engineered, not curated: rules live in version control, are tested against known techniques, and cover a mapped and measured share of the relevant threat model. Response is automated for the top recurring incident types.
Reference architectures, paved roads, guardrails and assurance
Standard logging library with required event schema; log onboarding module; detection rule repository with CI testing; playbook templates; on-call and escalation tooling.
Guardrails
Logging cannot be disabled on production; log source coverage checked at deploy; tamper protection on audit trails; retention enforced by policy.
Assurance signal
Log source coverage vs asset inventory; detection coverage against prioritised techniques; MTTD and MTTR by severity; % incidents with automated first response.
AI
AI Gateway · Agent IAM
Current state
Shadow ai use · no inventory of models and agents · agents share human credentials · unbounded tool access · sensitive data reaching context windows · release without evaluation · agent actions not auditable. See how each is closed →
Target state
Every model call and agent action passes through a mediated path with a scoped non-human identity, enforced tool and data entitlements, and a complete evidentiary trail. Autonomy is granted per capability and revocable in seconds — the same governance any privileged human account receives.
Reference architectures, paved roads, guardrails and assurance
Reference architectures
AI gateway and model brokerage; agent identity and delegated authority; tool-use mediation and sandboxing; retrieval and context isolation for sensitive data; prompt and output filtering; model and agent inventory with lifecycle; evaluation, red-teaming and release criteria; human-in-the-loop and kill-switch design.
Paved roads
Gateway SDK with logging, redaction and rate limiting built in; agent identity issuance module; approved model catalogue; RAG reference implementation with tenant isolation; evaluation harness; agent action audit library.
Guardrails
Direct provider API calls blocked outside the gateway; agent entitlements bounded and time-limited; sensitive data classes denied at retrieval; high-impact tool calls require approval; unregistered models cannot reach production; egress-controlled inference paths.
Assurance signal
% AI traffic through the gateway; registered vs discovered models and agents; agent entitlement drift; policy blocks by category; evaluation coverage before release; audit completeness for agent-initiated actions.
06
Closing the gaps
An optional layer on the diagram. Tool names are illustrative of the category, not a shortlist — the road and the guardrail are the architecture; the product is a replaceable implementation detail.
Identity
The worked example, carried in full: identity is what every other domain depends on.
Why each condition persists, and the proof it is gone
Why each condition persists, what removes it, and the number that proves it is gone.
Condition today
Why it persists
Proof it is gone
Too many identitiesPhase 1–2
Applications were onboarded with their own local account stores; nothing ever required federation.
Distinct identity stores; % of applications federated; orphaned local accounts.
Long-lived credentialsPhase 2–3
Static keys are the only thing that works reliably in pipelines, because no broker exists.
Median credential lifetime; static keys over 90 days; secrets found in repositories.
Inconsistent MFAPhase 1–2
MFA was applied per application, and legacy protocols bypass whatever was configured.
% phishing-resistant authentications; legacy auth attempts; applications outside the baseline.
Standing privilegesPhase 2–3
Elevation is slow when it is needed, so temporary admin was granted and never revisited.
Standing privileged accounts; median elevation duration; break-glass reviews.
Manual provisioning and deprovisioningPhase 2–3
No authoritative feed from the system of record: access is granted by ticket, removed from memory.
Services use shared secrets because no attested workload identity exists to use instead.
% workloads on federated identity; shared service accounts; median token lifetime.
Limited access visibilityPhase 3–4
Entitlements live inside each system, so answering who can reach what takes days.
% entitlements in the inventory; time to answer; over-permissive findings.
The pattern to notice
Not one of these seven is solved by writing a stronger policy, and several have almost certainly had a policy written about them already. Each persists because the compliant option is harder than the non-compliant one — no broker, no elevation workflow, no attested workload identity, no inventory. That is precisely what the paved road layer exists to fix, which is why identity gets the first two roads in Phase 1 rather than the first two guardrails.
Where a condition has survived a policy, it is a supply problem. Build the road, then close the gate behind it.
Network
Everyone knows the flat segment exists. It survives because closing it breaks traffic that has no other path.
Why each condition persists, and the proof it is gone
Read the middle column as a work queue.
Condition today
Why it persists
Proof it is gone
Flat internal networksPhase 1–3
Segmentation was inherited rather than designed, and no module places a workload correctly.
Legacy segments remaining; % workloads in a defined segment; denied east-west attempts.
VPN as the access pathPhase 1–3
The VPN works for everything, so nothing pushes an application onto a better path.
% applications behind ZTNA; concurrent VPN sessions; apps still needing full network access.
Uncontrolled egressPhase 2–3
Open egress is the cloud default, and closing it breaks builds until a proxy path exists.
% workloads through the proxy; unauthorised egress attempts; destinations off the allow-list.
Firewall rules by ticketPhase 2–3
Change outruns the review queue, so rules accumulate and nobody removes them.
% rules managed as code; rule age and unused rules; time to complete a change.
Unknown internet exposurePhase 1–2
Exposure is created faster than it is inventoried, and findings arrive without an owner.
Exposed assets with an owner; exposure-to-detection time; unexpected exposures per month.
OT, clinical and lab estates unsegmentedPhase 3–4
These estates carry devices that cannot be patched, so the network was left alone.
% estates inside an enclave; brokered versus direct flows; unmanaged devices per enclave.
Third-party site-to-site tunnelsPhase 3
Each partner tunnel was built at speed and outlived the project that justified it.
Tunnels with an owner and expiry; partner sessions brokered; tunnels retired per quarter.
Cloud
The domain where the paved-road argument is easiest to win: the console was simply faster than the platform.
Why each condition persists, and the proof it is gone
Note how many resolve at account creation rather than at deployment. That is where the leverage is.
Condition today
Why it persists
Proof it is gone
Ungoverned accounts and subscriptionsPhase 1–2
Teams needed environments faster than governance could supply them.
% accounts through vending; unmanaged accounts; time to a governed environment.
Click-built infrastructurePhase 2–3
The console is the fastest route to something working, and no module fit the need.
% resources from approved modules; console writes in production; adoption per team.
Configuration drift goes unnoticedPhase 2–3
State is compared only when something breaks or an audit asks.
Drift mean time to repair; resources diverged from intent; auto-reverted versus manual.
Inconsistent loggingPhase 1–2
Logging is configured per project, at the end, on the team's own budget.
Log coverage against the inventory; accounts with gaps; attempts to disable logging.
Public exposure by defaultPhase 2–3
Provider defaults favour reachability, and the demonstration became production.
Publicly reachable resources; policy denials per week; creation-to-detection time.
Unowned and untagged resourcesPhase 1–2
Tags are a convention, and whoever created the resource has moved on.
Logging was designed for requests, not for chains of reasoning and tool calls.
% actions with a replayable trace; time to reconstruct an incident; audit gaps.
Source poster
The original identity architecture poster this section was built from — kept intact for reference.
Click the image to open it full size. Its lower half — guiding principles, the three-year journey, the enablers, the metrics and the governance panels — is redrawn in house style in sections 03, 07, 08 and 09.
07
Roadmap
Nothing is enforced before it is paved. Each phase has an exit criterion rather than a date, so slippage is visible.
Phase 1 · Months 0–6
Establish
Agree the intent, prove the mechanism
Ratify principles and target state. Stand up identity and landing-zone foundations. Ship two paved roads end-to-end to prove the model works before scaling it.
Exit criteriaPrinciples ratified; target state signed per domain; two paved roads in production use by a real team; baseline posture visible.
Phase 2 · Months 6–12
Pave
Make the secure path the fast path
Build paved roads for the highest-volume patterns. Guardrails go live in warn mode with published enforcement dates. Exception process opens and feeds the backlog.
Exit criteriaRoads cover the top five recurring patterns; all guardrails deployed in warn mode; exception queue triaged weekly with named road owners.
Phase 3 · Months 12–24
Enforce
Close the gap between intent and estate
Guardrails move from warn to block on the paved patterns. Legacy migration runs against a published deprecation calendar. Detection and data programmes reach engineered maturity.
Exit criteriaPriority guardrails blocking in production; paved-road adoption above 70%; drift MTTR inside target; exception count falling quarter over quarter.
Phase 4 · Months 24–36
Assure
Prove it continuously, to anyone who asks
Continuous controls monitoring replaces manual evidence collection. Architecture metrics reach the board pack. AI reaches parity with the mature domains rather than trailing them.
Exit criteriaMajority of audit evidence auto-collected; architecture metrics reported to the board quarterly; AI domain at the same guardrail maturity as cloud and identity.
Domain
Phase 1 — Establish
Phase 2 — Pave
Phase 3 — Enforce
Phase 4 — Assure
Identity
Federated SSO baseline; privileged account inventory; conditional access policy set
JIT elevation road; workload identity module; secretless CI broker
Direct provider calls blocked; agent entitlements bounded and expiring; retrieval isolation enforced
Full audit trail for agent actions; continuous evaluation; parity with cloud and identity guardrails
Worked example — the identity programme
The same four phases expressed as fifteen numbered workstreams, the form a delivery team can actually run.
The building blocks it runs on
Six reusable paved roads. Every workstream above consumes one of these rather than building its own.
08
Architecture metrics
Seven numbers that measure the programme, not the tools. None of them improve by buying something.
Paved-road adoption
Share of production workloads built from approved modules, templates and services rather than hand-assembled.
Target: >80% by end of Phase 3
Guardrail coverage and posture
Share of intended guardrails deployed, split by warn versus block. Warn-mode age is the leading indicator of stalled enforcement.
Target: 100% deployed, >70% blocking
Drift mean time to repair
Time from a resource diverging from its intended state to automatic or manual return.
Target: <24 hours for critical resources
Exception volume, age and expiry
Open exceptions, median age, and the share carrying a hard expiry date. Clusters name the next road to build.
Target: falling quarterly; 100% with expiry
Automated evidence share
Proportion of control evidence generated by the system rather than collected by a person ahead of an audit.
Target: >75% by end of Phase 4
Reference architecture freshness
Share of published architectures reviewed within the last twelve months and linked to a live paved road.
Target: >90% current, 100% road-linked
Time to first secure deploy
Elapsed time for a new service to reach production on the paved road, from empty repository to running workload. The single best proxy for whether security is a supplier or an obstacle — and the number engineers will quote back to you.
Target: under one day, unassisted
Baseline and target — identity
What the seven conditions look like as numbers, and where they have to land.
09
Governance and exceptions
Kept deliberately light: governance that outweighs delivery becomes the thing teams route around.
How decisions get made
Architecture review board, monthly. Approves new and revised reference architectures. Membership spans security architecture, platform engineering and a rotating product representative.
Written proposals only. A change enters as a short decision record: the problem, the options, the recommendation, the principles it engages, the paved-road implication. No proposal without a delivery path.
Paved-road backlog, fortnightly. Prioritised like any product backlog, with exception clusters and adoption telemetry as the primary demand signals.
Quarterly architecture review. Each domain reports drift, adoption and top exception clusters. This is the only forum that may amend a principle or the target state.
How exceptions work
Every exception is time-bound. No open-ended grants. Expiry forces a decision rather than deferring it indefinitely.
Risk is accepted by the business, not by security. Security documents the exposure and the compensating control; an accountable owner signs.
Exceptions are demand signals. Three requests for the same deviation stop being exceptions and become a road on the backlog.
Compensating controls are specific. “Additional monitoring” is not a compensating control unless the detection exists and has been tested.
Expiry triggers review, not auto-renewal. Renewal requires the same evidence as the original request.
Forums and success factors
Who decides, and the conditions under which any of this actually lands.
10
Assurance as evidence
The same telemetry that tells engineering it is drifting tells an auditor the control operated.
Assurance source
Engineering question it answers
Typical evidentiary use
CSPM / CNAPP
Is the cloud estate configured as designed, and where has it drifted?
Configuration management, change control, access control operating effectiveness
ASPM & supply chain
Was this artefact built the approved way, and what is inside it?
SBOM production and maintenance, secure development lifecycle, vulnerability management SLAs
DSPM
Where does sensitive data actually live, and who can reach it?
Data inventory, minimum necessary access, encryption, retention and residency
Control operating effectiveness across audit periods without sampling exercises
Architecture metrics
Is the programme converging on its target state?
Governance and management commitment; risk treatment progress reporting
The design rule that makes this work: instrument the control to emit its own proof at the moment it operates. Evidence assembled retrospectively is expensive, contested, and always thinner than the control that produced it.
11
Maturity assessment
Click a cell to cycle 0–4. The weakest layer caps the domain, so the effective score is the minimum, not the average.
0 none · 1 defined · 2 built · 3 adopted · 4 assured
Domain
Reference architecture
Paved road
Guardrail
Assurance
Effective
0 — Not started 1 — Decision written down 2 — Built and available 3 — Adopted at scale 4 — Continuously assured
