DoD Zero Trust Target Level Assessment: Prove the Outcome, Not the Product

A DoD Zero Trust Target Level assessment is not a product inventory. It is proof that 91 activity outcomes operate together under real access, failure, and recovery conditions.

Not installed. Operating.

A license can exist while access rules are bypassed. A policy can be configured while device condition never changes a decision. A dashboard can be green while a required source is missing. A shared service can claim coverage while the local system has never tested the integration. Those are implementation facts, not minor paperwork defects.

The assessment has to connect each claimed Target activity to a defined scope, accountable authority, current architecture, effective control, operating sample, direct test, exception record, and decision. If the team cannot trace that chain, it has a claim, not proof.

This guide belongs to the Zero Trust hub and the broader Cyber Situational Awareness service. Use it with the DoD Zero Trust Strategy guide to understand the department direction and with the secure cloud architecture guide to connect access decisions with CUI boundary and cloud evidence.

Freeze the DoD Zero Trust Target Level Assessment Basis

The public framework is specific. DoD organizes Zero Trust around seven pillars, 45 capabilities, and 152 activities. Public DoD, Department of the Navy, and DCSA sources identify 91 Target activities and 61 Advanced activities. DoD has described Target Level as the minimum capability outcomes and activities needed to contain, slow, or stop an adversary.

The important unit is the activity. Many capabilities include work in both Target and Advanced levels. A team cannot point to a capability name, declare it complete, and know which outcome it actually proved.

Before evidence collection begins, record the exact strategy, roadmap, capability table, reference architecture, and local direction in use. Publications can change. Names can shift. Local implementation can add constraints. A result without a frozen basis cannot be reproduced or defended.

The capability mix also explains why a simple maturity label is weak. User, device, and data capabilities have substantial work in both levels. Applications and workloads, automation and orchestration, and visibility and analytics include capabilities that are Advanced only. The assessment register should separate the levels and preserve the activity source.

Contractor Applicability Depends on the Actual Authority

The DoD strategy directs department implementation. It does not, by itself, create one identical assessment duty for every contractor, supplier, cloud service, or system.

For contractor work, start with the contract, task order, system role, information handled, customer direction, incorporated clauses, security plan, shared service agreements, and any named assessment deliverable. Preserve legal and contracting judgment with the authorized customer and counsel. Do not turn a planning guide into an invented obligation.

When a contractor operates or supports part of a DoD Zero Trust path, the evidence question is still concrete:

• Scope: which system, enclave, application, service, mission, and protected resource are included?
• Activity basis: which publication revision and which Target activities are in the agreed set?
• Responsibility: which party implements, operates, supplies evidence, tests, accepts, and closes each activity?
• Inheritance: which outcomes come from an identity, cloud, network, security, or enterprise service?
• Decision authority: who can mark a result, approve an exception, accept exposure, and require a retest?

If those five items are vague, the assessment will produce disputes instead of decisions.

Write the Assessment Charter Before Asking for Evidence

A good charter is short enough to use and specific enough to stop scope drift. It names the mission, protected resources, systems, connections, environments, identity populations, service identities, devices, applications, data classes, network paths, automation, telemetry, and incident functions in scope.

It also records the assessment period, sampling rule, test authority, production safety constraints, evidence handling, result scale, inheritance rule, exception rule, dispute path, and final decision maker.

Use a result scale that does not hide uncertainty:

• Met: the applicable activity outcome operates across the agreed scope and the evidence plus direct test support the claim.
• Partial: part of the scope or outcome is proven, but a defined gap remains.
• Not met: the outcome is absent, fails, or lacks enough evidence to support the claim.
• Inherited: an authorized provider supplies the outcome and the local consumer integration is also proven.
• Not applicable: the authorized decision maker accepts a documented rationale tied to scope and activity language.

Unknown is not met. It should not be converted into success because the evidence owner missed a deadline.

Original Research: The GS DoD Zero Trust Target Level Proof Priority Index

GS Consulting built a derived model to answer one operating question: which proof lanes should an assessment team design and test first?

The model rates twelve proof lanes from one through five across five factors:

• Target coverage pressure, 25 percent: how broadly the lane affects the Target activity set.
• Cross pillar dependency, 20 percent: how many other controls depend on the lane working correctly.
• Access decision leverage, 20 percent: how directly the lane changes access to a protected resource.
• Evidence decay, 20 percent: how quickly a configuration, sample, or review stops representing current operation.
• Failure consequence, 15 percent: what can happen when the outcome fails, is bypassed, or cannot recover.

Each rating is multiplied by its weight, divided by five, and summed to a score from zero through 100. Ratings and weights are GS assumptions. They are documented in the downloadable research workbook so a team can replace them.

The top result is decisive. Outcome tests and recovery score 100 because every factor is severe. A team can collect hundreds of screenshots and still miss whether a deny decision works, whether movement is contained, whether missing telemetry is detected, or whether a failed action can be restored safely.

User identity and privilege score 97. Data catalog, labels, and access score 96. Cross pillar integration, device inventory and condition, logging and SIEM coverage, and policy decision and enforcement each score 93. The pattern is clear: the highest priorities are the evidence lanes that decide access, connect pillars, change quickly, and expose failure.

Two sensitivity cases shift more weight toward evidence decay or mission resilience. The largest rank movement is five places, but outcome tests and recovery remain first in both cases. That stability supports an assessment sequence that designs direct tests before teams begin gathering files.

The formula driven research workbook preserves the weights, ratings, public signals, sensitivity analysis, assessment matrix, decision path, failure modes, evidence packet, and source register. Teams should replace the GS assumptions with local evidence before making a decision.

Use One Proof Matrix Across the Seven Pillars

Separate pillar teams are useful for ownership. Separate proof standards are not. Every activity claim should answer the same four questions:

1. What current activity and outcome are being claimed?
2. What minimum evidence shows the outcome operates across the scope?
3. What direct test challenges the claim?
4. What record preserves the observed result and decision?

The matrix prevents one common error: allowing a strong document set in one pillar to mask a broken integration elsewhere. Identity can authenticate correctly while an unhealthy device is ignored. Data can be labeled while the policy engine never reads the label. Network segments can exist while an alternate path bypasses enforcement. Logging can be enabled while no one notices a missing source.

Assess the complete decision path. The resource request, subject identity, device condition, resource attributes, data context, policy decision, enforcement result, telemetry, analytic signal, incident action, and recovery record should tell one consistent story.

Build an Activity Register That Can Survive Review

The activity register is the control plane for the assessment. One row should represent one activity within the agreed scope. At minimum, keep:

• activity identifier, title, pillar, capability, level, publication revision, and source location;
• plain language outcome, predecessor, successor, dependency, and shared service;
• system, environment, protected resource, population, and boundary in scope;
• implementation owner, operating owner, evidence owner, test owner, and decision authority;
• required proof, operating period, sample rule, direct test, and acceptance rule;
• status, finding, exception, corrective action, due date, retest, and final decision.

Do not copy the roadmap into a spreadsheet and call it an assessment register. Translate each activity into the local architecture and operating outcome. If the activity depends on an enterprise identity service, name the provider, service commitment, evidence location, local integration, failure mode, and consumer test.

Inheritance is not a blank row. It is a two part proof. The provider must support the claimed outcome, and the local system must consume that service correctly. A current provider statement without a local test proves only half the path.

Collect Operating Samples, Not a Prepared Moment

Configuration proves intent. Operating evidence shows whether the intent survives normal work.

Define the period and expected population before selecting samples. For identity and privilege, reconcile joins, moves, departures, role changes, approvals, expirations, denied requests, emergency access, reviews, and revocations. For device, reconcile managed assets, unknown assets, health state, policy exceptions, vulnerability state, and access results. For data, connect catalog, label, owner, permission, use, sharing, retention, and access decisions.

For visibility and analytics, begin with an expected source list. Compare it with actual coverage. Then sample alerts, investigations, cases, escalation, containment, recovery, and closure. A SIEM screenshot does not establish complete telemetry or a working response.

Every sample should preserve source, time, subject, resource, decision context, expected result, observed result, owner, and any exception. If the team cannot reconstruct why access was allowed or denied, the evidence chain is incomplete.

Demonstrate the Outcome and Challenge the Failure

DoD public reporting on the Department of the Navy Flank Speed assessment is instructive. The assessment used service demonstrations and Purple Team testing, and the service reported meeting all 91 Target activities. The useful lesson is the method, not the score: make the service show the outcome, then challenge it.

Direct tests should cover both expected use and credible misuse:

• Allow: a valid subject, healthy device, permitted resource, and approved context receive the expected access.
• Deny: an invalid identity, unhealthy device, prohibited label, expired privilege, or unapproved path is blocked.
• Change: altered role, device state, resource attribute, data label, risk signal, or session context changes the decision.
• Revoke: access ends when authority, employment, role, device trust, or exception ends.
• Move: an attempted alternate path or lateral movement is contained and observed.
• Detect: missing telemetry, unusual behavior, denied events, and control failure create the expected signal.
• Respond: the team can investigate, contain, communicate, and close the event with authority.
• Recover: failed automation, enforcement, dependency, or response can stop safely and restore the approved state.

Write the expected outcome before the test. Preserve the setup, data, operator, witness, observed result, logs, defect, corrective action, and matched retest. A demonstration without an expected result becomes a tour.

Run a Five Stage Assessment Path

The most efficient assessment is designed from the decision backward. Evidence requests follow the outcome and test plan. They do not begin as a broad request for every security artifact the program owns.

Stage one freezes scope, revision, authority, and the Target set. Stage two maps activities to outcomes, dependencies, and evidence. Stage three samples actual operation. Stage four runs direct tests, including failure and recovery. Stage five records the result and gives every gap a closure path.

Do not wait until the final meeting to define what counts as met. Decision rules belong in the charter. The assessment team should know how partial scope, inherited services, missing evidence, open defects, temporary exceptions, and unsafe production tests will be handled before findings appear.

Six Failure Modes That Create False Confidence

Weak assessments are usually predictable. They accept a substitute for the outcome that matters.

The direct test for a capability label is simple: select the capability and trace every applicable Target activity to current evidence. The direct test for product presence is live behavior. The direct test for isolated pillars is one access decision that crosses the complete path.

Prepared evidence should be challenged with a defined operating period and an expected population. Inherited services should be traced to the provider record and a local consumer test. Exceptions should expire, roll back, and receive a matched retest. If the team cannot do those things, leadership should know exactly which claim remains open.

Keep One Minimum Evidence Packet

An assessment becomes expensive when the team has to rebuild the story for every review. Keep the source, evidence, test, defect, decision, and closure record in one chain.

The packet should be easy to navigate from either direction. An activity should lead to its implementation, samples, tests, findings, and decision. A log, ticket, or screenshot should lead back to the system, activity, period, owner, and test it supports.

Keep evidence handling proportional to sensitivity. Do not expose protected architecture, identities, vulnerabilities, or event data in a broad collaboration space simply to make review convenient. Record the locator, custodian, access rule, and integrity method when the artifact cannot travel with the packet.

A Practical 90 Day Assessment Plan

Days 1 through 15: Freeze the basis

• Confirm customer authority, contract context, system scope, protected resources, environments, and decision maker.
• Freeze the strategy, roadmap, activity table, architecture, and local direction revisions.
• Create the activity register and assign implementation, evidence, test, and decision owners.
• Write result definitions, sampling rules, evidence handling, production safety constraints, and dispute paths.

Days 16 through 35: Map outcomes and dependencies

• Translate each applicable Target activity into a local observable outcome.
• Map identity, device, application, data, network, policy, enforcement, telemetry, response, and recovery paths.
• Identify predecessors, successors, shared services, inherited outcomes, bypass paths, and known exceptions.
• Write evidence requests and direct tests from the outcome backward.

Days 36 through 60: Collect operating samples

• Reconcile expected populations and select samples from the chartered period.
• Connect configuration, change, approval, denial, exception, review, incident, and recovery records.
• Challenge stale, prepared, incomplete, and inherited evidence before testing begins.
• Open findings for missing proof instead of waiting for the final report.

Days 61 through 80: Demonstrate and challenge

• Run allow, deny, change, revoke, movement, telemetry loss, response, failure, and recovery tests.
• Preserve expected and observed results, logs, witnesses, defects, corrective actions, and matched retests.
• Exercise shared service failure and local consumer behavior where authority permits.
• Escalate unsafe tests and define an alternate proof method without disguising the limitation.

Days 81 through 90: Decide and close

• Record met, partial, not met, inherited, or not applicable by activity.
• Give every open claim a rationale, owner, due date, protection, decision authority, and retest.
• Report both the activity result and the cross pillar failure paths that leadership needs to manage.
• Approve the next evidence refresh and assessment trigger before the team disbands.

Ninety days is a planning frame, not a universal promise. Scope, test authority, production constraints, shared services, evidence quality, and system complexity will change the schedule. The operating standard does not change: no success claim without current activity proof and an observable outcome.

Sources, Method, and Planning Caveat

The research package uses twelve public sources. Primary DoD sources define the framework, Target intent, roadmap, activity structure, architecture, and milestone. Department of the Navy and DCSA sources confirm public counts and provide implementation and training context. CISA and NIST sources add maturity, architecture, planning, integration, and test guidance.

• Department of Defense Zero Trust Strategy
• DoD Zero Trust Capability Execution Roadmap
• DoD Zero Trust Capabilities and Activities
• DoD Zero Trust release and Target Level explanation
• Department of the Navy Zero Trust Implementation Intent
• Department of the Navy Flank Speed assessment report
• DCSA Introduction to DOD Zero Trust Student Guide
• Department of Defense Zero Trust Reference Architecture
• CISA Zero Trust Maturity Model Version 2.0
• NIST SP 800-207 Zero Trust Architecture
• NIST SP 1800-35 Implementing a Zero Trust Architecture
• NIST CSWP 20 Planning for a Zero Trust Architecture

Planning caveat: The GS DoD Zero Trust Target Level Proof Priority Index, proof matrix, decision path, failure analysis, and evidence packet are GS Consulting derived planning tools based on cited public sources and documented assumptions. They are not official legal, contract, audit, compliance, NIST, CISA, DoD, DCSA, or regulatory determinations. They do not inspect a system, determine activity completion, validate inheritance, authorize risk, or issue an official assessment result.

Frequently Asked Questions

What is the DoD Zero Trust Target Level?

Target Level is the set of Zero Trust capability outcomes and activities that DoD describes as the minimum needed to contain, slow, or stop an adversary. Public DoD and component sources identify 91 Target activities across seven pillars. Teams should freeze the exact publication revision used for an assessment.

How many activities are in the DoD Zero Trust Target Level?

Public DoD, Department of the Navy, and DCSA sources identify 91 Target activities and 61 Advanced activities within a framework of 45 capabilities and 152 total activities. Completion is assessed at the activity level because many capabilities contain work in both levels.

What evidence supports a DoD Zero Trust Target Level assessment?

Useful evidence connects scope, the current activity, accountable authority, architecture, effective configuration, operating samples, exceptions, direct test results, defects, retests, and the final decision. A product list or one prepared screenshot does not prove repeated operation.

Does buying a Zero Trust product satisfy Target Level?

No. A product may support one or more activities, but Target Level is about implemented outcomes across connected pillars. The assessment should test allow, deny, revoke, device condition, data context, movement limits, telemetry, response, failure, and recovery as applicable to the system.

Does DoD Zero Trust Target Level automatically apply to every contractor?

No universal conclusion should be inferred from the strategy alone. Contractor duties depend on the contract, system role, information handled, customer direction, and incorporated requirements. Contractors supporting an assessment should agree the activity revision, scope, evidence, inherited services, decision authority, and delivery format with the customer.

Is the GS Proof Priority Index an official DoD assessment method?

No. It is a GS Consulting derived planning model built from cited public sources and documented assumptions. It helps sequence assessment design and evidence work. It does not determine activity completion, validate inheritance, authorize risk, or issue an official DoD result.

Related Reading

• Zero Trust Hub
• DoD Zero Trust Strategy
• Secure Cloud Architecture for Federal Contractors Handling CUI
• Continuous Control Monitoring for GovCon
• Building Audit Trails for Automated Workflows

The standard is simple: no Target Level claim without a current activity, a responsible authority, operating evidence, a direct test, and a closure decision.