Zero Trust Architecture Plan: [Organisation or programme name]
Plan for moving an organisation from perimeter-based security to a zero
trust architecture (ZTA): principles, logical components, deployment
approach, current state and maturity assessment, target state, roadmap by
pillar, metrics and risks. Based on NIST SP 800-207 Zero Trust
Architecture (August 2020) for tenets, logical components, deployment
approaches and migration steps; the CISA Zero Trust Maturity Model
Version 2.0 (April 2023) for pillars, cross-cutting capabilities and
maturity stages; and NIST SP 1800-35 Implementing a Zero Trust
Architecture (final, June 2025) for example builds. Replace every
[bracketed] value and every row marked Example. Worked examples use a
mid-sized company with on-premises applications, two cloud providers and a
remote workforce.
Document control
| Field | Value |
|---|
| Document ID | [ZTA-PLAN-001] |
| Programme | [Zero trust programme name] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@security-architect] |
| Executive sponsor | [@ciso] |
| Approvers / reviewers | [@cio], [@infrastructure-lead], [@identity-lead], [@app-platform-lead] |
| Last updated | YYYY-MM-DD |
| Classification | Confidential |
| Planning horizon | [YYYY to YYYY] |
| Next review | YYYY-MM-DD (at least annually and after each roadmap phase) |
| Related | [Security architecture], [Risk register], [Asset inventory], [Identity strategy] |
Approvals
| Role | Name | Decision | Date |
|---|
| Chief information security officer | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| Chief information officer | [@name] | [Decision] | YYYY-MM-DD |
| Head of infrastructure and network | [@name] | [Decision] | YYYY-MM-DD |
| Head of identity and access management | [@name] | [Decision] | YYYY-MM-DD |
| Data protection officer | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft after current state workshops |
| 0.2 | YYYY-MM-DD | [@name] | Example: Maturity scores reviewed with pillar owners; roadmap phase 1 agreed |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved by steering committee |
Contents
1. Introduction and scope
1.1 Drivers
[Example: A phishing incident last year gave an attacker VPN access and
from there flat network access to file servers and a finance application.
Half the workforce is remote, 60% of business applications run in two
public clouds, and contractors use personal devices. Cyber insurance renewal
requires phishing-resistant multi-factor authentication for all staff.]
1.2 Objectives
| ID | Objective | Measure |
|---|
| OBJ-01 | Example: Remove implicit trust based on network location | No application reachable only because a user is on the corporate network or VPN |
| OBJ-02 | Example: Phishing-resistant authentication for all workforce identities | Share of users enrolled in FIDO2 or smart card authentication |
| OBJ-03 | Example: Per-session, least-privilege access to high-value resources | High-value applications behind a policy enforcement point with device posture checks |
| OBJ-04 | Example: Limit lateral movement | East-west traffic between segments denied by default |
| OBJ-05 | Example: Visibility for every access decision | Access decisions logged centrally and correlated |
| [OBJ-nn] | [Objective] | [Measure] |
1.3 Scope and protect surfaces
List the resources to protect first. Start with a small number of high-value
resources where a breach would cause the most harm.
| ID | Resource or protect surface | Data sensitivity | Users | Hosting | Priority |
|---|
| RES-01 | Example: Finance and payroll application | Restricted | 120 staff | On premises | 1 |
| RES-02 | Example: Customer database and admin console | Restricted | 40 engineers, 300 support staff | Cloud A | 1 |
| RES-03 | Example: Source code and CI/CD | Confidential | 400 engineers, contractors | SaaS and cloud B | 2 |
| RES-04 | Example: Collaboration suite | Internal | All staff | SaaS | 2 |
| RES-05 | Example: Building management and printers (legacy devices) | Internal | Facilities | On premises | 3 |
| [RES-nn] | [Resource] | [Class] | [Users] | [Hosting] | [1 / 2 / 3] |
Out of scope for this plan: [Example: operational technology in
manufacturing sites, handled by a separate programme].
2. Zero trust tenets
NIST SP 800-207 section 2.1 sets out seven basic tenets as an ideal goal,
noting that not every tenet may be fully achievable for every strategy. The
paraphrases below are original summaries; read the publication for the full
wording.
| ID | Tenet (paraphrase of SP 800-207 section 2.1) | What it means here |
|---|
| T-1 | All data sources and computing services are treated as resources | Example: SaaS tenants, cloud workloads and APIs are inventoried and governed like on-premises servers |
| T-2 | Communication is secured whatever the network location; being on the internal network grants no trust | Example: Internal traffic to RES-01 and RES-02 is encrypted and authenticated like internet traffic |
| T-3 | Access to each resource is granted per session | Example: Authorisation to one application does not grant access to another; sessions are re-evaluated |
| T-4 | Access is decided by dynamic policy using the state of identity, application or service, and requesting asset, plus behavioural and environmental attributes | Example: Device compliance, user risk and location feed every decision for priority 1 resources |
| T-5 | The enterprise monitors and measures the integrity and security posture of all owned and associated assets | Example: Endpoint posture is continuously reported; unmanaged devices get restricted access |
| T-6 | Authentication and authorisation are dynamic and strictly enforced before access is allowed | Example: Continuous evaluation and re-authentication on risk change |
| T-7 | The enterprise collects as much information as possible about the current state of assets, network and communications and uses it to improve its security posture | Example: Access logs, flow logs and endpoint telemetry flow to analytics that tune policy |
3. Logical architecture
SP 800-207 separates a control plane, where access decisions are made, from
a data plane, where application traffic flows through enforcement points.
| Component (SP 800-207) | Role | Our implementation | Owner |
|---|
| Policy engine (PE) | Decides whether to grant, deny or revoke access to a resource, using policy and inputs | Example: Identity provider conditional access plus access proxy policy service | [@team] |
| Policy administrator (PA) | Establishes or shuts down the session path between subject and resource by instructing the PEP | Example: Access proxy control plane; issues session tokens | [@team] |
| Policy enforcement point (PEP) | Enables, monitors and terminates connections between subject and resource | Example: Identity-aware proxy for web apps; service mesh sidecars for workloads | [@team] |
| Policy decision point (PDP) | The PE and PA together | Example: As above | [@team] |
| Data sources | Inputs to the PE: diagnostics, compliance, threat intelligence, logs, data access policy, PKI, identity, SIEM | Example: EDR, MDM, IdP, CA, SIEM, data classification service | [@team] |
4. Deployment approach
4.1 Approaches (SP 800-207 section 3.1)
| Approach | Core idea | Fit here | Primary for |
|---|
| Enhanced identity governance (3.1.1) | Identity and assigned attributes of actors are the main input to access policy | Example: Strong fit: SaaS and web applications | RES-03, RES-04 |
| Micro-segmentation (3.1.2) | Place individual or groups of resources in their own segment protected by gateways or host firewalls | Example: Needed for data centre workloads and legacy servers | RES-01, RES-05 |
| Network infrastructure and software defined perimeters (3.1.3) | Use an overlay network where the PA acts as network controller and builds per-session paths | Example: Replaces the remote access VPN | RES-02 admin access |
4.2 Deployment models (SP 800-207 section 3.2)
| Model | Description (paraphrase) | Use for |
|---|
| Device agent and gateway (3.2.1) | An agent on the device and a gateway in front of the resource communicate with the PA | Example: Managed laptops to internal apps |
| Enclave-based (3.2.2) | A gateway protects a group of resources (an enclave) rather than each one | Example: Legacy finance servers that cannot host agents |
| Resource portal (3.2.3) | A portal acts as gateway for subjects without an agent | Example: Contractors on unmanaged devices, browser-only |
| Device application sandboxing (3.2.4) | Approved applications run in isolated compartments on the device | Example: Not planned in the first phases |
5. Current state assessment
5.1 Actors, assets and processes
| Step (SP 800-207 7.3) | Finding | Evidence |
|---|
| Identify actors (7.3.1) | Example: 2 400 employees, 350 contractors, 900 service accounts, 40 shared admin accounts | IdP and directory export |
| Identify assets (7.3.2) | Example: 3 100 managed laptops, unknown share of personal devices, 1 800 cloud workloads, 60 SaaS applications | MDM, CMDB, cloud inventory |
| Identify key processes and risks (7.3.3) | Example: Payroll run, customer support, software release; highest risk from support access to customer data | Business impact analysis |
5.2 Maturity stages (CISA ZTMM 2.0)
The ZTMM describes a journey from a Traditional starting point through
Initial and Advanced to Optimal, each stage needing more
automation, integration and granularity. Summarise each stage in your own
words for assessors, for example:
| Stage | Short description used in this assessment |
|---|
| Traditional | Manual, static configuration; siloed policies; perimeter-based trust |
| Initial | First automation and cross-pillar integration; some policies based on attributes |
| Advanced | Automated, centrally managed, integrated across pillars; context-based decisions where feasible |
| Optimal | Fully automated, dynamic, just-in-time policies with continuous monitoring across pillars |
5.3 Maturity scores by pillar and function
The ZTMM 2.0 has five pillars (Identity, Devices, Networks, Applications and
Workloads, Data) and three cross-cutting capabilities (Visibility and
Analytics, Automation and Orchestration, Governance). The function names
below are those of ZTMM 2.0; check the model for the criteria of each stage.
| Pillar | Function | Current stage | Evidence | Target stage |
|---|
| Identity | Authentication | Example: Initial (MFA, not phishing-resistant) | IdP policy report | Advanced |
| Identity | Identity Stores | Example: Traditional (3 directories, manual sync) | Directory inventory | Advanced |
| Identity | Risk Assessments | Example: Traditional | No user risk signals | Initial |
| Identity | Access Management | Example: Initial (standing admin rights) | Privileged account review | Advanced |
| Devices | Policy Enforcement and Compliance Monitoring | Example: Initial | MDM compliance 72% | Advanced |
| Devices | Asset and Supply Chain Risk Management | Example: Traditional | CMDB gaps | Initial |
| Devices | Resource Access | Example: Traditional (no posture in access decisions) | IdP configuration | Advanced |
| Devices | Device Threat Protection | Example: Advanced (EDR on 98% of laptops) | EDR console | Advanced |
| Networks | Network Segmentation | Example: Traditional (flat office and data centre network) | Firewall rules review | Advanced |
| Networks | Network Traffic Management | Example: Traditional | Static rules | Initial |
| Networks | Traffic Encryption | Example: Initial (internal HTTP in places) | Scan results | Advanced |
| Networks | Network Resilience | Example: Initial | Architecture review | Initial |
| Applications and Workloads | Application Access | Example: Initial (VPN then app login) | Access paths | Advanced |
| Applications and Workloads | Application Threat Protections | Example: Initial | WAF on public apps only | Advanced |
| Applications and Workloads | Accessible Applications | Example: Traditional (internal apps reachable only via VPN) | App inventory | Advanced |
| Applications and Workloads | Secure Application Development and Deployment Workflow | Example: Initial | CI/CD review | Advanced |
| Applications and Workloads | Application Security Testing | Example: Initial | SAST only | Advanced |
| Data | Data Inventory Management | Example: Traditional | No data catalogue | Initial |
| Data | Data Categorization | Example: Traditional | Policy exists, no labels | Initial |
| Data | Data Availability | Example: Initial | Backup reports | Initial |
| Data | Data Access | Example: Initial | Role-based, broad groups | Advanced |
| Data | Data Encryption | Example: Initial | At rest in cloud; gaps on premises | Advanced |
| Cross-cutting | Visibility and Analytics | Example: Initial | SIEM covers 40% of sources | Advanced |
| Cross-cutting | Automation and Orchestration | Example: Traditional | Manual provisioning | Initial |
| Cross-cutting | Governance | Example: Initial | Policies not enforced technically | Advanced |
6. Target state
| Pillar | Target state at end of horizon (Example) |
|---|
| Identity | One authoritative identity store; phishing-resistant MFA for all workforce; just-in-time privileged access; user risk signals used in access policy |
| Devices | All devices accessing priority 1 resources are managed and compliant; posture checked at every session; unmanaged devices limited to browser access through a portal |
| Networks | Data centre segmented by application; remote access VPN retired; all internal traffic to priority 1 and 2 resources encrypted |
| Applications and Workloads | All internal web applications published through the identity-aware proxy; workload-to-workload calls authenticated with workload identities in the service mesh |
| Data | Data classified and labelled for priority 1 resources; access policies use classification; encryption at rest and in transit everywhere |
| Cross-cutting | All access decisions logged to the SIEM; automated deprovisioning; zero trust policies reviewed by a policy board |
7. Roadmap by pillar
7.1 Phases
| Phase | Theme | Duration | Exit criterion |
|---|
| P1 | Example: Foundations: identity consolidation, MFA, device inventory, logging | 6 months | All workforce on one IdP with MFA; 95% device inventory coverage |
| P2 | Example: First protect surfaces: RES-01 and RES-02 behind PEPs with posture checks | 6 months | No VPN-only access to RES-01 or RES-02 |
| P3 | Example: Segmentation and workload identity | 9 months | East-west deny by default in data centre; mesh for cloud A |
| P4 | Example: Data-centric controls and automation | 9 months | Classification-based access for priority 1 data; automated provisioning |
7.2 Roadmap items
| ID | Pillar | Item | Phase | Depends on | Exit criterion | Owner |
|---|
| ZT-ID-001 | Identity | Example: Consolidate three directories into one authoritative identity store | P1 | none | Single source for workforce identities | [@identity] |
| ZT-ID-002 | Identity | Example: Phishing-resistant MFA for administrators, then all staff | P1 to P2 | ZT-ID-001 | 100% admins, 95% staff | [@identity] |
| ZT-ID-003 | Identity | Example: Just-in-time privileged access; remove 40 shared admin accounts | P2 | ZT-ID-001 | No standing domain admin rights | [@identity] |
| ZT-DEV-001 | Devices | Example: Enrol all corporate devices in MDM; inventory personal devices that access email | P1 | none | 95% coverage | [@endpoint] |
| ZT-DEV-002 | Devices | Example: Device compliance as a condition for priority 1 access | P2 | ZT-DEV-001, ZT-ID-001 | Non-compliant devices denied or limited | [@endpoint] |
| ZT-NET-001 | Networks | Example: Replace remote access VPN with identity-aware proxy for web apps | P2 | ZT-ID-002 | VPN users below 5% | [@network] |
| ZT-NET-002 | Networks | Example: Segment data centre by application, deny east-west by default | P3 | ZT-VIS-001 | Flow logs show only allowed paths | [@network] |
| ZT-APP-001 | Applications and Workloads | Example: Publish internal web applications through the PEP | P2 | ZT-NET-001 | Priority 1 and 2 apps published | [@app-platform] |
| ZT-APP-002 | Applications and Workloads | Example: Workload identities and mutual TLS in cloud A service mesh | P3 | none | All service-to-service calls authenticated | [@app-platform] |
| ZT-DATA-001 | Data | Example: Classify and label data in RES-01 and RES-02 | P3 | none | Labels on 90% of records or files in scope | [@data-governance] |
| ZT-DATA-002 | Data | Example: Classification-aware access policy and data loss prevention | P4 | ZT-DATA-001 | Policy enforced in PEP | [@data-governance] |
| ZT-VIS-001 | Visibility and Analytics | Example: Send IdP, PEP, EDR and flow logs to the SIEM | P1 | none | 90% of sources onboarded | [@soc] |
| ZT-AUT-001 | Automation and Orchestration | Example: Automated joiner, mover, leaver provisioning from HR system | P4 | ZT-ID-001 | Deprovisioning within 1 hour | [@identity] |
| ZT-GOV-001 | Governance | Example: Zero trust policy board and policy-as-code review process | P1 | none | Monthly board; policies versioned | [@ciso] |
| [ZT-XXX-nnn] | [Pillar] | [Item] | [Phase] | [Depends on] | [Exit] | [@owner] |
7.3 Migration steps
Follow the incremental steps of SP 800-207 section 7.3 for each new protect
surface: identify actors (7.3.1), assets (7.3.2) and processes and risks
(7.3.3); formulate policies (7.3.4); identify candidate solutions (7.3.5);
deploy and monitor initially, often in observe-only mode (7.3.6); then
expand (7.3.7). Record each protect surface's progress in 13.
8. Access policy and trust algorithm
8.1 Policy inputs
| Input | Source | Used for |
|---|
| Subject identity, group, role, authentication strength | IdP | All decisions |
| Device managed, compliant, patch level, EDR healthy | MDM and EDR | Priority 1 and 2 resources |
| User and sign-in risk | IdP risk engine, SIEM | Step-up or deny |
| Resource classification and owner policy | Data catalogue, application registry | Required strength per resource |
| Time, location, network | Request context | Anomaly signals, not sole basis |
| Threat intelligence | Feeds, SOC | Block known bad infrastructure |
8.2 Policy rules
| Rule ID | Resource | Condition | Decision |
|---|
| POL-001 (Example) | RES-01 Finance | Employee in finance group, phishing-resistant MFA, managed compliant device, low risk | Allow, session 8 h, re-evaluate on risk change |
| POL-002 (Example) | RES-01 Finance | Same, but unmanaged device | Deny |
| POL-003 (Example) | RES-02 Customer admin | Engineer with approved just-in-time elevation, managed device | Allow for 1 h, session recorded |
| POL-004 (Example) | RES-04 Collaboration | Contractor, MFA, unmanaged device | Allow browser-only via portal, no downloads |
| POL-005 (Example) | Any | Sign-in risk high | Deny and alert SOC |
| [POL-nnn] | [Resource] | [Condition] | [Decision] |
Policies are versioned as code, tested in report-only mode before
enforcement and reviewed by the policy board (ZT-GOV-001).
9. Reference implementations and example builds
NIST SP 1800-35 (final, June 2025) documents example zero trust
implementations built by the NIST National Cybersecurity Center of
Excellence with industry collaborators using commercially available
technology, mapped to SP 800-207 and to security standards. As published,
it describes 19 example implementations; check the current guide for the
list of builds, the technologies used and the lessons learned.
| Our roadmap item | Relevant SP 1800-35 material | What we take from it |
|---|
| ZT-ID-002, ZT-DEV-002 | Example: Builds using the enhanced identity governance approach | Integration of IdP, device posture and PEP |
| ZT-NET-001 | Example: Builds using software defined perimeter components | Replacing VPN access paths |
| ZT-NET-002 | Example: Builds using micro-segmentation | Sequencing segmentation with monitoring first |
| [Item] | [Build or volume] | [Lesson] |
10. Governance and operating model
| Element | Description |
|---|
| Steering committee | Example: CISO (chair), CIO, business unit leads; quarterly; approves phases and funding |
| Policy board | Example: Security architecture, identity, network, application owners; monthly; approves access policies and exceptions |
| Pillar owners | One accountable owner per pillar and cross-cutting capability |
| Exception process | Time-limited exceptions with compensating controls, recorded in the risk register |
| Change management | Every policy change tested in report-only mode, then enforced with rollback plan |
| Communications | User communications before each enforcement change; help desk briefed |
11. Metrics
| ID | Metric | Baseline | Target | Source |
|---|
| M-01 | Example: Workforce accounts with phishing-resistant MFA | 12% | 95% | IdP |
| M-02 | Example: Priority 1 resources behind a PEP with posture check | 0 of 2 | 2 of 2 | Application registry |
| M-03 | Example: Remote access sessions over VPN | 2 100 per day | Below 100 per day | VPN logs |
| M-04 | Example: Standing privileged accounts | 40 shared, 120 personal | 0 shared, 20 break-glass and service | PAM |
| M-05 | Example: Allowed east-west flows in data centre not on the allow list | Unknown | 0 | Flow logs |
| M-06 | Example: Access decisions logged centrally | 40% | 100% | SIEM |
| M-07 | Example: Time to deprovision a leaver | 5 days | 1 hour | Identity governance |
| M-08 | Example: ZTMM functions at or above target stage | 3 of 25 | 25 of 25 | Section 5.3 reassessment |
| [M-nn] | [Metric] | [Baseline] | [Target] | [Source] |
12. Risks
| ID | Risk | Source | Likelihood | Impact | Mitigation | Owner |
|---|
| RSK-01 | Example: Subversion of the decision process (PE or PA misconfigured or compromised) | SP 800-207 5.1 | Low | High | Policy as code with review; admin access to PE/PA under strongest controls; audit | [@name] |
| RSK-02 | Example: Denial of service or outage of PEP or PA blocks all access | SP 800-207 5.2 | Medium | High | Redundant PEPs and PA across regions; tested break-glass path | [@name] |
| RSK-03 | Example: Stolen credentials or insider within policy | SP 800-207 5.3 | Medium | High | Phishing-resistant MFA, least privilege, behavioural analytics | [@name] |
| RSK-04 | Example: Encrypted traffic reduces network inspection | SP 800-207 5.4 | High | Medium | Endpoint and PEP telemetry; metadata analysis | [@name] |
| RSK-05 | Example: Policy and log stores become high-value targets | SP 800-207 5.5 | Medium | High | Restricted access, integrity protection, retention rules | [@name] |
| RSK-06 | Example: Vendor lock-in through proprietary formats | SP 800-207 5.6 | Medium | Medium | Open standards for identity (SAML, OIDC, SCIM) and logs | [@name] |
| RSK-07 | Example: Automated non-person entities in administration misbehave or are abused | SP 800-207 5.7 | Medium | Medium | Separate identities, scoped permissions, monitoring of automation accounts | [@name] |
| RSK-08 | Example: User friction leads to shadow IT | Programme | Medium | Medium | Single sign-on, communication, phased enforcement | [@name] |
| [RSK-nn] | [Risk] | [Source] | [L / M / H] | [L / M / H] | [Mitigation] | [@name] |
13. Traceability
| Objective | Tenets | Roadmap items | Policies | Metrics |
|---|
| OBJ-01 | T-2, T-3 | ZT-NET-001, ZT-APP-001 | POL-001, POL-004 | M-02, M-03 |
| OBJ-02 | T-6 | ZT-ID-002 | POL-001 | M-01 |
| OBJ-03 | T-3, T-4, T-5 | ZT-DEV-002, ZT-ID-003 | POL-001 to POL-003 | M-02, M-04 |
| OBJ-04 | T-2 | ZT-NET-002, ZT-APP-002 | [Segment policies] | M-05 |
| OBJ-05 | T-7 | ZT-VIS-001 | All | M-06 |
| [OBJ-nn] | [Tenets] | [Items] | [Policies] | [Metrics] |
| Protect surface | Step reached (SP 800-207 7.3) | Next step | Date |
|---|
| RES-01 | Example: 7.3.4 policies formulated | 7.3.6 initial deployment in report-only mode | YYYY-MM-DD |
| RES-02 | Example: 7.3.6 initial deployment | 7.3.7 expand to all support staff | YYYY-MM-DD |
| [RES-nn] | [Step] | [Next] | YYYY-MM-DD |
14. Glossary and references
14.1 Glossary
| Term | Meaning |
|---|
| Zero trust (ZT) | Security concepts that minimise uncertainty in per-request access decisions by not granting trust based on network location or asset ownership alone |
| Zero trust architecture (ZTA) | An enterprise's plan for applying zero trust principles to its infrastructure and workflows |
| Policy engine (PE) | Component that makes the access decision |
| Policy administrator (PA) | Component that sets up or tears down the session path according to the PE's decision |
| Policy enforcement point (PEP) | Component that enables, monitors and terminates connections to a resource |
| Protect surface | A resource or group of resources protected as a unit |
| Pillar | ZTMM area of capability: Identity, Devices, Networks, Applications and Workloads, Data |
| Micro-segmentation | Dividing the network into small segments with enforcement between them |
14.2 References
| Reference | Use |
|---|
| NIST SP 800-207, Zero Trust Architecture, Rose, Borchert, Mitchell and Connelly, August 2020, doi:10.6028/NIST.SP.800-207 | Tenets (2), components (3), approaches (4), migration (5.1, 7.3), threats (12) |
| CISA, Zero Trust Maturity Model, Version 2.0, April 2023 (cisa.gov/zero-trust-maturity-model) | Pillars, functions, cross-cutting capabilities and stages (5.2, 5.3) |
| NIST SP 1800-35, Implementing a Zero Trust Architecture, final, June 2025 (csrc.nist.gov/pubs/sp/1800/35/final) | Example builds (9) |
| NIST SP 800-207A, A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments, September 2023 | Workload access in cloud-native environments (optional) |
Security Architecture Document Template (NIST SP 800-160, STRIDE) (security/security-architecture) | System-level security architecture under this plan |
Threat Model Template (STRIDE) (security/threat-model) | Threats per protect surface |
NIST CSF 2.0 Profile Template (compliance/nist-csf) | Organisation-level cybersecurity profile |
Access Review Template (ops/access-review) | Periodic access reviews during migration |
Standard and licence note
Based on NIST SP 800-207 (August 2020), NIST SP 1800-35 (final, June 2025)
and the CISA Zero Trust Maturity Model Version 2.0 (April 2023), which are
works of the United States Government and not subject to copyright in the
United States. Section numbers, component names, pillar, function and stage
names are cited; the explanations are original paraphrases. Check the
current official versions at nist.gov and cisa.gov before relying on this
plan, as updates or revisions may have been published. Original text written
for this collection. Template licence: MIT.