Zero Trust preparation playbook

Draft client turnover companion · Zero Trust Preparation · 6 October 2026

Prepare one selected access use case for a defensible next decision. This guide connects authoritative references to client facts, current investments, conceptual options, ownership and a proposed validation plan. It does not replace the standards or create a separate Zero Trust methodology. The outcome can be a qualified option, a narrower next scope or a documented hold. It is not pillar scoring, maturity certification, demonstrated control effectiveness or an authorization outcome.

Inputs can come from Foundations or equivalent standalone evidence. Neither Foundations nor Application Dependency Mapping is a required purchase. The existing module is zero-trust in pursue/services/modules.json; its quantities, specialist participation, handling and review arrangements must be agreed before work. This pack adds no offering, engine field or schema. The existing 30 requests, 51 positions, 10 domains and 53 workstreams remain unchanged.

1. Establish the boundary and the receiving decision

Record the selected service, access problem, resource/data, identity populations, security boundary and explicit exclusions. Name the service owner, qualified Zero Trust/security specialist, policy representative, receiving custodian and client acceptance authority. Identify identity, endpoint, network, application/data and operations reviewers; do not assume one consultant covers all specialties. Confirm permitted evidence, access method, storage, retention and return arrangements before inspecting material.

Fictional example: an approved group of analysts accesses a retained reporting service across a cloud/GSS boundary. The service also uses a workload identity to read a data store. The selected question is whether current access decisions and enforcement can support the proposed access policy without breaking essential service dependencies. The human session and service-to-data call are separate flows. Backup, monitoring, administration and emergency paths are identified as dependencies or exclusions, not silently treated as covered.

Define quantities and decision expectations without inventing dates or duration. A bounded preparation package can disclose unknowns and still meet agreed artifact criteria. Missing data permission stops the affected evidence work. Missing specialist or policy input changes the supportable conclusion; it does not become an assumed favorable answer. Keep a record of who agreed to narrow, defer or proceed with a qualified scope.

2. Reference exact sources and record client applicability

NIST SP 800-207, August 2020, provides the conceptual anchor: section 2.1 describes Zero Trust tenets; section 3 separates policy engine, policy administrator and enforcement point; sections 7.3.1–7.3.5 address actors, assets, processes, candidate policies and solution selection. Network location alone is not a basis for implicit trust. These references guide discussion; client authorities determine applicable requirements and authorization conditions. (NIST publication and full text)

DoD references: Strategy, Reference architecture v2.0, Roadmap v1.1. These are versioned research references, not a verified complete inventory of current policy. Record later component direction or conflicting editions for the responsible client authority to resolve.

NSA released its Primer and Discovery guidance January 14, 2026, followed by Phase One and Phase Two January 30, 2026. Its May 28, 2026 portal launch provides current activity-level access. The PDF downloads returned access errors during research; official HTML activity pages were readable. Use those precise page headings and retrieval dates, not invented PDF page numbers. The portal identifies its alignment with the defense CIO framework; its implementation suggestions should not be converted into universal product mandates. (January release, Phase release, ZIG portal)

Maintain one row per claimed requirement: issuer, title, edition/date, exact section/activity, source location, client applicability rationale, confirming authority, decision status and linked flow. A source can be guidance without being an adopted requirement. Keep FedCiv, DoD and IC applicability separate; do not transfer roadmap dates or authority from one population to another. This bounded pack does not establish FedCiv/IC policy applicability. The client supplies its applicable directives and adoption record.

3. Describe current trust before proposing products

The following are our recommended preparation records, tailored with client specialists rather than copied implementation instructions. Give each statement an evidence reference, date, scope and state: declared, observed, inferred, unknown or contradicted. An existing diagram is a declaration until its relevant relationships are corroborated; an export reflects its collection period and filters. Owner validation establishes business meaning, while technical evidence supports the described mechanism.

For the fictional reporting service, distinguish the analyst's identity from the application's database identity. Successful user authentication does not establish the permissions of the downstream workload. Record whether access uses local or federated identities and where ownership or credential lifecycle is uncertain. Do not infer that a gateway governs a direct administrative or service route merely because it fronts the user interface.

NSA's Activity 1.1.1 identifies authoritative identity sources and lifecycle context, including privileged identities; Activity 3.1.1 calls for application/code inventory context such as versions, ownership, hosting and support. Consult the original activities for their detail. This module inspects agreed existing records; it does not execute their discovery or implementation tasks. (User activity 1.1.1, Application activity 3.1.1)

Map responsibility separately from capability. The provider, GSS operator, identity team, application owner, data owner and CSSP can have different duties. Record evidence for common-control or service inheritance and its exclusions. An available feature or supplier statement does not demonstrate that the client configured, inherited or operates it.

4. Compare options, exceptions and degraded behavior

Start with the existing investment inventory: product/service, version, entitlement, owner, known interfaces, boundary and evidence of use. Classify each option as retain, configure, integrate, acquire or investigate. A missing owner or unclear policy is not automatically a software gap. A feature missing from the current entitlement requires an acquisition decision, not an assumption that a new tool is already funded.

For each selected flow, compare the current arrangement, an interim option and a future design candidate against the same question. Record dependencies, affected users/workloads, anticipated benefit, operational burden, compatibility, uncertainty and reason to reject or defer. These are conceptual options for specialist review; provide no live policy syntax, privileged-access changes or deployment commands.

Do not choose a universal fail-open or fail-closed rule. Show the security and mission consequences, then assign the policy decision to the appropriate authority. Temporary access is not acceptable merely because it expires; its scope, monitoring and approval must be justified. A monitoring outage can remove required evidence even while access still works. Where required evidence is absent and no interim arrangement is accepted, affected design or authorization decisions remain held.

For our fictional case, an identity-provider outage raises two distinct questions: whether existing analyst sessions may continue and whether the workload can continue database access. The answer depends on current policy, dependency state and mission tolerance. The preparation output is a decision record and unresolved questions, not a fabricated emergency procedure. Any later engineering or operational exception requires separately authorized work.

5. Propose validation without claiming execution

Define a later validation question for each material assumption. Record proposed environment, sample, prerequisites, permissions, qualified operator, expected observations, stop condition and accepting reviewer. Leave results unknown and execution status “not executed.” A tabletop can review a plan but cannot establish control effectiveness. A product demonstration cannot establish the client's integrated behavior.

The proposed plan should specify evidence retention and handling, reversibility or recovery needs, and any impact requiring mission-owner agreement. Exact thresholds, durations and acceptable outcomes remain client decisions. No test, scan, agent installation or production connection occurs under this preparation module. Missing testing authority does not prevent documenting the plan; it prevents presenting the plan as executed.

6. Deliver a traceable package and an explicit completion sequence

The turnover contains five integrated artifacts: applicability/current-state trust register; access/data-flow and responsibility views; gap/exception register; policy/design options and proposed validation plan; prioritized preparation handover. Editable working templates and read-only prompts accompany this guide in plus-delivery/turnover/zero-trust/. Blank values mean unknown or unagreed, never zero risk or automatic acceptance.

Link each material item as requirement/recommendation → exact source → client applicability → flow/evidence → local decision/action → owner → dependency → acceptance evidence. Identify policy, evidence, design and implementation gaps separately. Assign an owner or record an ownership gap; explain what can proceed, what is held and what fact would change the recommendation. Sequence acquiring evidence, resolving authority, evaluating existing tools and any later acquisition/integration/configuration. Avoid turning a roadmap or indicative module duration into a delivery commitment.

Submission includes version, date, evidence limits and a matrix against agreed criteria. Named reviewers classify comments as an in-scope deficiency or a new request; record the disposition and corrections. Written artifact acceptance identifies the version, accepted criteria and outstanding items. Silence, elapsed time or workshop attendance does not count. A receiving owner can accept a complete gap register while the underlying operational risk remains unresolved.

Handover is ready when selected-flow coverage is explicit, sources and applicability are traceable, material uncertainty remains visible, options are qualified, validation is clearly proposed, and every material item has a decision, owner or documented hold. The receiving custodian acknowledges maintenance responsibility and review triggers such as policy, identity, boundary, dependency or product changes. Artifact acceptance does not authorize implementation, accept security risk, approve inheritance or grant ATO/cATO. The appropriate client authorities retain those decisions.