here’s a side‑by‑side comparison of your Zero Trust Maturity Model for Automated Service Releases versus the NSA Zero Trust Implementation Guideline – Discovery Phase (Jan 2026), with concrete crosswalks, deltas, and what to adjust so your model and evidence line up cleanly for audits and rollout.

---

(what’s the same / what’s different)

• Strong alignment on pillars and tenets. Both models use the standard ZT pillars and emphasize never trust, always verify; assume breach; continuous verification—and the NIST SP 800‑207 PE/PA/PEP pattern is explicitly acknowledged in the NSA guideline. [NSA - Zero...very Phase | PDF], [advisera.com]

• Scope difference. Your model spans maturity levels L1–L5 across Identities, Endpoints, Applications, Infrastructure, Data, Network and a full service‑release maturity path. The NSA Discovery Phase is intentionally foundational: inventory, catalogs, initial logging/analytics scale, policy inventory and automation readiness—not full enforcement or autonomous release. [NSA - Zero...Phase.pdf | PDF]

• Granularity difference. NSA Discovery provides capability → activity → task detail (with predecessors/successors and expected outcomes). Your model provides clear level definitions and KPIs, but fewer implementation tasks per level—useful for auditors to see “how” things were achieved. [NSA - Zero...Phase.pdf | PDF]

• Release automation coverage. Your model addresses CI/CD, security gates, rollback, risk‑based releases across five levels. NSA Discovery only sets the pre‑conditions for this (policy inventory, automation analysis, SOAR readiness, API standardization), with the execution mechanics deferred to later phases. [NSA - Zero...Phase.pdf | PDF]

---

Pillar‑by‑Pillar Crosswalk

---

Maturity & Release Automation: How they line up

Your 5‑level Service Release Maturity (Manual → Managed → Defined → Quantitatively Managed → Optimizing) includes CI/CD, security gates, automated rollback, risk‑based releases, and autonomous/self‑healing deployment. The NSA Discovery Phase maps largely to Levels 1–3 prerequisites:

• Level 1–2 enablers: policy inventory, standardized logging schema, authoritative inventories (users/devices/apps/data), and initial SOAR response patterns. [NSA - Zero...Phase.pdf | PDF]

• Level 3 stepping stones: PDP/PEP architecture definition, SDN API standards, automation analysis (identify automatable tasks and retire low‑value manual steps), and API/tool compliance checks. These are pre‑conditions to your risk‑based gating and policy‑driven releases. [NSA - Zero...Phase.pdf | PDF]

• Levels 4–5 (AI‑powered, predictive, autonomous): not in scope for Discovery; NSA indicates later phases (Phase One/Two at Target level; Phase Three/Four at Advanced) will address higher automation and orchestration. [NSA - Zero...Phase.pdf | PDF]

---

Where you’re stronger vs. where NSA Discovery adds rigor

Your model is stronger in:

• Explicit release automation levels (frequency, MTTR, CFR, rollback, JIT permissions in pipelines), including concrete service release KPIs and targets.

• End‑to‑end view that merges ZT pillars with CI/CD outcomes (e.g., “security‑first automation,” “continuous verification during releases”).

NSA Discovery adds rigor in:

• Implementation granularity: Activity‑level tasks with predecessor/successor logic and expected outcomes—useful for audit trails and repeatability. (e.g., Activity 6.2.1 requires independent audit criteria for automation: effectiveness, accuracy, efficiency, compliance, logging.) [NSA - Zero...very Phase | PDF]

• Enterprise‑grade catalogs (users, devices, apps/code, data) and enforcement‑point logging patterns (DLP/DRM) that clarify what evidence to collect, where, and in what format. [NSA - Zero...very Phase | PDF]

• API standardization & tool compliance checks before orchestration—minimizes brittle integrations during policy‑driven releases. [NSA - Zero...very Phase | PDF]

---

Gaps & Reconciliation Recommendations

The aim is to keep your maturity structure and KPIs, but ground them with NSA‑style activities so auditors (ISO 27001, SOC 2) and engineers see “how” each level is realized.

1. Bind each of your maturity checkpoints to NSA Discovery Activities (add one column to your roadmap):

   • Identities L2–L3 → Activity 1.1.1 Inventory User (authoritative sources, privileged vs. non‑privileged). Evidence: user catalog exports, joiner/mover/leaver tickets, PAM enrollment logs. [NSA - Zero...very Phase | PDF]

   • Endpoints L2–L3 → Activities 2.1.1 (device inventory/health) and 2.3.4 (NextGen AV integrated with C2C/EDR). Evidence: device compliance posture, NAC decisions, EPP→C2C telemetry. [NSA - Zero...very Phase | PDF]

   • Applications L2–L3 → Activity 3.1.1 (application & code identification; supportability, location, dependencies). Evidence: app inventory, SCM/registry exports, SBOM analogs. [NSA - Zero...very Phase | PDF]

   • Data L2–L3 → Activities 4.1.1, 4.4.1, 4.4.2 (data catalog + DLP/DRM enforcement point logging). Evidence: data catalog, DLP/DRM log fields, policy exception logs. [NSA - Zero...very Phase | PDF]

   • Infrastructure/Network L3 → Activities 5.1.1, 5.2.1 (granular access rules; SDN API definitions). Evidence: policy objects, SDN controller API specs, segmentation policies. [NSA - Zero...very Phase | PDF]

   • Automation for Releases L3→L4 → Activities 6.1.1, 6.2.1, 6.5.1, 6.6.1 (policy inventory, task & response automation analysis, SOAR playbooks, API/tool compliance). Evidence: policy inventory, automation audit criteria and results, SOAR runbooks and execution logs, API conformance checklist. [NSA - Zero...very Phase | PDF]

2. Embed NIST SP 800‑207 language in your design docs and pipeline gates (for credibility and clarity):

   • Call out where your CI/CD gates act as PEPs, what component is your PE (policy engine for release decisions), and what orchestrator (GitOps/SDN/IdP) plays PA (translating decisions to enforcement). [advisera.com]

3. Strengthen your evidence model to satisfy ISO 27001 and SOC 2 using NSA Discovery outputs:

   • ISO/IEC 27001:2022 SoA: map A.5.16–A.5.18 (Identity/Access) to Activity 1.1.1; A.8.9 (Configuration), A.8.16 (Monitoring) to Activities 2.1.1/2.3.4; A.8.28 (Secure coding) to Activity 3.1.1; A.8.12 (DLP), A.8.11 (Data masking) to 4.4.1/4.4.2; A.5.23 (Cloud) & A.5.30 (ICT readiness) to SDN & logging scale activities. [elevateconsult.com]

   • SOC 2 (TSC): show CC6 (logical access) via identity/device catalogs and deny‑by‑default policies; CC7 (system operations) via logging/analytics and SOAR runbooks; CC8 (change management) via CI/CD policy gates and rollback tests linked to PDP/PEP decisions. [onlinelibr....wiley.com]

4. Adopt NSA’s automation audit criteria for your Level‑4/5 automation claims: document per automated control/playbook: effectiveness, accuracy, efficiency, compliance, logging & monitoring evidence. This materially strengthens the “Quantitatively Managed/Optimizing” levels. [NSA - Zero...very Phase | PDF]

5. Close a subtle terminology gap: your model uses “Policy Engine/Administrator/Enforcement” conceptually; NSA Discovery speaks in PDP/PEP and concrete enforcement points (NGFW, DLP/DRM, SDN). Harmonize the labels in architecture diagrams and pipeline docs to avoid confusion during audits. [NSA - Zero...very Phase | PDF], [advisera.com]

---

Example: tying your Release Level 3 (Defined) to NSA Discovery evidence

• Your requirement: “Comprehensive CI/CD, automated security validation, automated rollback, policy‑driven release.”

• NSA Discovery evidence to attach:

  1. Policy Inventory & Development (6.1.1) — the policy catalog that your PE uses to decide release gates. [NSA - Zero...very Phase | PDF]

  2. Task Automation Analysis (6.2.1) — a list of pipeline tasks marked automatable, audit criteria, and the audit results. [NSA - Zero...very Phase | PDF]

  3. API Standardization/Tool Compliance (6.6.1) — proof that scanners, SDN, IdP, C2C, EDR, and deployment tools conform to standard APIs used by the PA/PEP. [NSA - Zero...very Phase | PDF]

  4. Visibility & Analytics (7.1) — standardized log schemas and scale plan to ensure every release action is observable. [NSA - Zero...very Phase | PDF]

• NIST anchoring: document which components are PE, PA, PEP in the release flow diagram (e.g., PE = policy service; PA = orchestrator that pushes policies to gateways; PEPs = admission controller, WAF, ZTNA proxy). [advisera.com]

---

Where to extend your model (quick wins)

• Add a one‑page “NSA Discovery Traceability” annex: For each maturity level KPI, list the NSA activity (ID), evidence object, and system of record. This makes ISO/SOC 2 sampling trivial. [NSA - Zero...Phase.pdf | PDF]

• Introduce an “Automation Audit Register” (from Activity 6.2.1): for every automated release control, store the audit criteria, test results, last review date, and rollback validation logs. [NSA - Zero...very Phase | PDF]

• Standardize API schemas early (Activity 6.6.1): publish a minimal OpenAPI/JSON schema for policy inputs/outputs so platforms (IdP, SDN, EDR/DLP, CI/CD) integrate cleanly. [NSA - Zero...very Phase | PDF]

---

Final take

Your maturity model is broader (especially on automated service releases and KPIs). The NSA Discovery guideline is deeper in foundational activities, evidence patterns, and interoperability hygiene. The best outcome is to keep your maturity ladder and operationalize each rung with NSA Discovery’s activities and artifacts—annotated with NIST SP 800‑207 PE/PA/PEP labels—so auditors and engineers have a shared, testable blueprint. [NSA - Zero...very Phase | PDF], [advisera.com]

Zero Trust Maturity Assessment – Expanded Analysis

Alignment Overview

This section expands on the alignment between your Zero Trust maturity model and the NSA Zero Trust Implementation Guideline Discovery Phase. It details the shared architectural principles including continuous verification, explicit trust evaluation, and adherence to the NIST SP 800-207 model.

Scope Differences

Your model spans all maturity levels from foundational controls to autonomous security operations, whereas the NSA Discovery Phase focuses only on foundational activities such as cataloging identities, devices, applications, and data as well as establishing logging and initial automation readiness.

Pillar Crosswalk Summary

Each pillar from your model maps to NSA capabilities, but with the NSA framework providing deeper activity-level implementation guidance. Your model describes what maturity looks like, while NSA describes how to implement each stage.

Release Automation Comparison

Your service release maturity model outlines CI/CD automation, security gating, continuous verification, and autonomous remediation. In contrast, NSA Discovery focuses on preparing the environment—policy inventory, automation analysis, SOAR readiness—not implementing full automation yet.

Strengths of Your Model

Your model provides clear maturity level definitions, KPIs, and release automation metrics. These are essential for enterprise measurement, reporting, and governance.

Strengths of NSA Discovery

The NSA provides highly detailed implementation tasks, predecessor/successor logic, and expected outcomes, strengthening auditability and consistency across teams.

Gaps and Enhancements

To reconcile the two, link your maturity levels to specific NSA activities, adopt NSA-style audit criteria for automation, and standardize API schemas early to ensure interoperability.

Recommendations

It is recommended to map each maturity criterion to NSA activities, enrich documentation with NIST SP 800-207 terminology (PE/PA/PEP), and integrate NSA evidence expectations into your governance artifacts.