Cloud Waypoint combines cloud foundation design and application dependency mapping to prepare modernization decisions and authorization inputs. Follow the work from ownership and system boundaries through evidence, review and handover.
Bring mission priorities, existing architecture and documents, and the people who own the applications and decisions. Cloud Foundations prepares foundation design, draft security documents, corrective actions and an operating model for review. With ADM, approved observation and owner validation strengthen dependency and migration planning.
Week 4 and Week 8 describe the standard Foundations schedule, including two advance weeks for the data call. Foundations is approximately eight weeks; Application Dependency Mapping requires at least twelve weeks of observation, overlapping Foundations, with approximately eighteen to twenty weeks total for the combined engagement. Timing depends on agreed scope, access, telemetry and participant availability. ADM delivery and acceptance milestones are agreed for the combined scope, not promised at Week 8. These are preparation estimates, not authorization or migration completion dates.
The nine-stage Cloud Waypoint spine adds delivery detail without creating another framework. These links show where each NIST RMF step is prepared; the governing organization retains tailoring, assessment, risk, and authorization authority.
PrepareAuthority + FrameworkSet roles, priorities, context, sources, and the authorization approach.
CategorizeBoundaryEstablish the system boundary, information types, impact, dependencies, and data flows.
SelectRequirementsChoose and tailor the control baseline, overlays, inheritance, and responsibilities.
ImplementImplementationPut selected controls and supporting operating work into effect and document how they work.
AssessEvidence + AssessmentCollect evidence, test implementation, record findings, and preserve assessor independence.
AuthorizeRisk decisionGive the designated authorizing official the evidence, conditions, and residual risk record for a decision.
MonitorContinuityMaintain evidence, configuration, vulnerabilities, changes, incidents, remediation, and authorization impact.
DoD policy context — CSRMC. The Department announced the Cybersecurity Risk Management Construct in September 2025. Confirm the component’s current implementation and transition instructions with its authorizing chain; this NIST crosswalk does not substitute for those instructions. Read the official announcement.
CURRENT OUTPUTS
Know what is available before planning the handover.
15 exports available · 9 partial outputs · 7 not exported, including client-owned operations. Availability describes the software output, not completed client evidence, contracted scope or authorization acceptance. Partial and unavailable items are identified at each stage.
SIX PATHWAYS
Use the same questions. Respect each authority.
DoD RMFDoD mission authorization
Formal authorization pathway. NIST RMF implemented through DoD policy. Cloud and cyber services contribute evidence; the mission AO retains the system authorization decision.
Confirm the recognized route. The responsible authority confirms applicability, required evidence and acceptance for this engagement. This comparison is not recognition or certification of Cloud Waypoint.
Formal authorization pathway. The same NIST RMF spine, applied through FISMA, OMB direction, and each agency’s authorization policy.
Confirm the recognized route. The responsible authority confirms applicability, required evidence and acceptance for this engagement. This comparison is not recognition or certification of Cloud Waypoint.
Cloud-service evidence plus agency authorization. FedRAMP High provides a reusable cloud-service security package. The agency still authorizes the federal information system and its specific use of the service.
Confirm the recognized route. The responsible authority confirms applicability, required evidence and acceptance for this engagement. This comparison is not recognition or certification of Cloud Waypoint.
FedRAMP providerCommercial cloud and service provider certification
Commercial-provider lens across the FedRAMP lifecycle. For a commercial software, SaaS, or managed-service provider pursuing FedRAMP Marketplace certification or validation. Historical Moderate aligns to Class C Advanced; historical High aligns to Class D High Assurance. The provider owns the offering and evidence, a recognized assessor supplies independent assessment where required, FedRAMP grants the Marketplace designation, and each agency AO decides agency-system use.
Confirm the recognized route. The responsible authority confirms applicability, required evidence and acceptance for this engagement. This comparison is not recognition or certification of Cloud Waypoint.
State / localState, local, tribal, and education pathways
Jurisdiction-selected authorization or assurance. A jurisdiction may use NIST RMF, GovRAMP cloud assurance, its own policy, or a combination. The named government authority decides what constitutes acceptance.
Confirm the recognized route. The responsible authority confirms applicability, required evidence and acceptance for this engagement. This comparison is not recognition or certification of Cloud Waypoint.
Outcome-oriented cybersecurity risk management. CSF 2.0 organizes outcomes through Govern, Identify, Protect, Detect, Respond, and Recover. It can stand alone for improvement or support formal authorization; it does not itself issue an ATO.
Confirm the recognized route. The responsible authority confirms applicability, required evidence and acceptance for this engagement. This comparison is not recognition or certification of Cloud Waypoint.
Cloud FoundationsGovernance, ownership, decision rights and workforce evidence positions.
Cloud FoundationsDecision and stakeholder registers identify accountable people and open calls.
Closeout proofA charter, named decision owners, accepted responsibilities, and dated client decisions can support movement; a consultant-authored role chart alone cannot.
Path differences
DoD RMFAuthorization strategy
Federal RMFAgency authorization strategy
FedRAMP HighAuthorization plan
FedRAMP providerCertification strategy
State / localAuthority and acceptance criteria
CSF 2.0Cybersecurity risk strategy
Outputs and remaining work
Export availableDecision and authority registerCSV / HTML · Named authorities, open decisions, owners, evidence basis, and next decision.
Export availableStakeholder and responsibility starterCSV / HTML · A reviewable role and RACI starting point for the client record.
Not currently exportedTarget operating intentNot produced by the Studio today: the record holds no governed target-posture structure (alternatives, limits, attestation) to assemble it from.
Cloud FoundationsStandards-linked policy, authorization-package, inheritance, data, acquisition, and Zero Trust evidence positions.
Cloud FoundationsSource-traced rationale and a governed distinction between requirements, reference patterns, and client decisions.
Closeout proofApproved policy, applicability, or tailoring decisions may move the reading. A crosswalk that has not been adopted improves readiness and traceability only.
Path differences
DoD RMFDoDI 8510.01
Federal RMFFISMA
FedRAMP HighFedRAMP High baseline
FedRAMP providerFedRAMP Consolidated Rules
State / localNIST RMF or CSF 2.0
CSF 2.0NIST CSF 2.0
Outputs and remaining work
Partial outputStandards crosswalkCSV / HTML · Each assessed position against its standard and the reference sources the Studio carries, with unresolved tailoring visible. The client's own policies are not in the record, so no policy is mapped.
Export availableTailoring and applicability worksheetCSV / HTML · Written once control selection is complete. Owners are the recorded providers, a control with none reads not recorded, and open decisions are named rather than resolved. Written only once the control selection is complete (categorization holds a level for C, I and A).
Not currently exportedClient policy action queueNot produced by the Studio today: the record holds no accepted policy gaps to queue.
ADMADM reconciles declared and observed dependencies as matched, unmatched, conflict, or never declared.
Foundations + ADMThe record already carries application ownership, boundary, interface, data-flow, integration, and infrastructure context.
Closeout proofOwner-confirmed inventory and reconciled dependencies can support movement. Observation is evidence of communication, not proof that the path is approved or complete.
Path differences
DoD RMFSystem description
Federal RMFSystem description
FedRAMP HighAuthorization boundary diagram
FedRAMP providerCloud service offering description
State / localBoundary diagram
CSF 2.0Scope statement
Outputs and remaining work
Export availableApplication and dependency registerCSV / HTML · Applications, owners, interfaces, observations, conflicts, and unresolved crossings. Requires Application Dependency Mapping, with applications and dependencies recorded.
Not currently exportedCMDB starter seedNot produced by the Studio today: the Studio imports inventory but writes no candidate configuration items or relationships.
Partial outputBoundary and data-flow packCSV / HTML · Boundary components, flows, interconnections and limitations as CSV and HTML; diagrams appear within Package readiness. A separate SVG file and a single bundled pack are not supplied.
Not currently exportedServiceNow / JSM candidate topologyNot produced by the Studio today: no CMDB classes, identifiers or reconciliation rules are generated.
Cloud FoundationsControl inheritance, shared responsibility and technical control positions.
Foundations + ADMEvidence records connect assessed positions, selected controls, current facts, gaps and actions. Each output below states its actual scope.
Closeout proofA confirmed allocation and accepted responsibility model can support movement. Cloud Waypoint does not select the final baseline or accept inherited risk.
Path differences
DoD RMFSecurity categorization
Federal RMFImpact categorization
FedRAMP HighHigh baseline
FedRAMP providerControl responsibility matrix
State / localControl matrix
CSF 2.0Current Profile
Outputs and remaining work
Partial outputResponsibility and inheritance matrixCSV / HTML · SSP draft, a responsibility and ownership register with unresolved ownership visible, and an inheritance CSV when control selection is complete. Separate provider, enterprise, platform, GSS and workload tiers are not recorded. Written only once the control selection is complete (categorization holds a level for C, I and A).
Export availableControl and position traceability registerCSV / HTML · Traces each assessed position and each selected control to its sources or evidence, workstreams, findings or open weaknesses, owner and open decisions. Controls and positions, not requirements; the record holds no position-to-control mapping, so none is drawn.
Partial outputDecision and gap worksheetCSV / HTML · Open decisions and unmet acceptance tests held for disposition, with their reasons. The record holds no agency, component, jurisdiction or workload deltas, so none are listed.
Foundations + ADMTransformation planning connects workstreams, dependencies, gates and horizons.
Foundations + ADMPlanning and Jira-shaped CSVs support client work management; tool-specific import mapping requires validation.
Closeout proofA plan or backlog is not implementation evidence. Movement above Defined requires adopted workflow and current operating proof from the client environment.
Path differences
DoD RMFSystem Security Plan (SSP)
Federal RMFSSP
FedRAMP HighCSP SSP
FedRAMP providerSystem Security Plan or security decision record
State / localSystem plan
CSF 2.0Roadmap
Outputs and remaining work
Export availableJira work boardCSV · Jira-shaped CSV for client review and mapping. ServiceNow import compatibility is not established. Carries the workstreams placed on the storyboard; with none placed the file holds only its header.
Partial outputTransformation project planCSV · Planning CSV available. A Microsoft Project XML file is also generated and checked against Microsoft's published schema; opening it in Microsoft Project has not yet been confirmed. Carries the workstreams placed on the storyboard; with none placed the file holds only its header.
Not currently exportedMoSCoW decision-ready backlogNot produced by the Studio today: the Studio does not model Must, Should, Could or Won't priorities.
Partial outputProcess Asset Library starterHTML / JSON · HTML reference and a generated JSON process library. Most content is the practice's fixed library, labelled as such; roles per process, measures and tests are not recorded.
Closeout proofOnly attributable, current evidence changes the closeout reading. A generated index makes evidence usable but does not make an unsupported control effective.
Path differences
DoD RMFImplementation statements
Federal RMFControl evidence
FedRAMP HighSSP
FedRAMP providerCertification evidence index
State / localGovRAMP or provider package
CSF 2.0Profile evidence
Outputs and remaining work
Export availableEvidence and traceability indexCSV / HTML · Evidence pointer, source, position, confirmation, limitation, and related action.
Export availablePOA&M and remediation seedCSV · Findings, owners, milestones, evidence needs, dependencies, and status for client import.
Export availableIntegrity and provenance manifestJSON · Included within the closeout or client pack; not a standalone download.
Partial outputOperational evidence return contractCSV / HTML · What the client's systems return for closeout verification: source, location, retention, owner and cadence, from the record. Export formats and field layouts for each client system are not specified.
Cloud FoundationsFindings remain separate from authorization and from document completeness.
Closeout proofCloud Waypoint may reassess evidence posture with the client. Independent assessors retain assessment conclusions and the governing authority retains acceptance.
Path differences
DoD RMFSecurity Assessment Plan (SAP)
Federal RMFSAP
FedRAMP High3PAO assessment results
FedRAMP providerAssessment plan
State / localAssessment report
CSF 2.0Updated Current Profile
Outputs and remaining work
Export availableAssessment posture exportCSV / HTML · Each applicable position, score, label, rationale, gap, evidence, quality, confidence, and confirmation. Requires a Foundations engagement with populated assessment evidence.
Export availableFindings and gap registerCSV / HTML · Reviewable findings tied to evidence positions and transformation actions. Requires a Foundations engagement with populated assessment evidence.
Export availableAssessor handover indexCSV / HTML · Evidence locations, test needs, open questions, package sections, and named custodians; not an SAP or SAR.
Cloud FoundationsExecutive brief and decision register surface conditions and unresolved actions.
Cloud FoundationsConsultant recommendations remain separate from assessment and authority decisions.
Closeout proofA dated client decision can close an open decision and change evidence posture. Only the designated authority accepts, conditions, transfers, treats, or rejects risk.
Path differences
DoD RMFAuthorization decision document
Federal RMFATO or other agency decision
FedRAMP HighFedRAMP authorization package
FedRAMP providerFedRAMP Marketplace designation
State / localJurisdiction decision record
CSF 2.0Funded roadmap
Outputs and remaining work
Partial outputExecutive decision briefHTML · HTML brief available; PDF uses the browser print function rather than a generated PDF export.
Export availableDecision and gate registerCSV / HTML · Decision, authority, evidence basis, dependencies, due point, and unresolved conditions.
Export availableRisk-response action queueCSV · Jira-shaped CSV of actions for client review. Import mapping and action approval remain with the client.
Cloud FoundationsTransformation and operating-model reports prepare the receiving team for continued work.
Foundations + ADMProcess references and handover outputs help receiving teams define continuing work; available files and limitations are identified below.
Closeout proofThe closeout delta is measured only after evidence review. Sustained Level 3 or Level 4 requires client operation beyond the handover date and may need later verification.
Path differences
DoD RMFContinuous-monitoring strategy
Federal RMFMonitoring reports
FedRAMP HighContinuous-monitoring submissions
FedRAMP providerContinuous-monitoring strategy
State / localMonitoring reports
CSF 2.0Revised Profiles
Outputs and remaining work
Partial outputTransformation and continuation packCSV / HTML · Transformation reports and CSV available. A Microsoft Project XML file is also generated and checked against Microsoft's published schema; opening it in Microsoft Project has not yet been confirmed. Carries the workstreams placed on the storyboard; with none placed the file holds only its header.
Export availableMaturity movement receiptJSON / HTML · Compares a sealed baseline and a sealed closeout of the same scope and method: evidence completeness and, separately, maturity over readings confirmed in both. A pair that is not comparable gets no movement, only the reasons; the records do not carry the Studio release that scored each reading. Requires a comparable baseline and closeout record of the same engagement (same scope and method).
Not currently exportedITSM / CMDB integration starterNot produced by the Studio today: the process library's event taxonomy is teaching content; nothing is generated from the record for ITSM or CMDB tools.
Client-ownedAdopted client operationsClient systems and records · Client-owned: the client configures, owns and operates it. The Studio does not produce it.
When immutable baseline and closeout records cover the same applicable 51 evidence positions, compare the confirmed readings and report the 0–4 average, the existing 30/40/30 People–Process–Technology composite, domain movement, changed positions, and confirmation coverage.
0 → 1 when a supported intent, draft artifact, or occasional practice now exists.
1 → 2 only when a named client owner confirms the practice is defined and operating.
2 → 3 only when current telemetry, tooling, tickets, exports, or repeated operational evidence show consistent execution.
3 → 4 only when reusable automation produces governed, monitored, exception-handled evidence.
A delivered template or export can improve completeness without changing maturity. Target Level 3 or Level 4 remains a separate, client-specific decision.
Maturity receiptCompare only explicitly retained baseline and closeout records with the same scope and method. Output availability is stated in the handover list; document delivery alone does not establish maturity improvement.
AUTHORITY BOUNDARY
Cloud Waypoint prepares the decision. The designated authority makes it.
Cloud Foundations and Application Dependency Mapping can establish, strengthen, and organize evidence. They do not certify a provider, assess their own work, grant FedRAMP status, issue an ATO, or accept risk for the client.
Public projection of the governed Team navigator · source model SHA-256 da5ff605c6d24d543a2a559c58019ccb0721ddac9a785ff144cd2d7076971525 · export manifest SHA-256 8c9a337e8b89a31f1d61c8ebd5defbc71eaca0446a06cee5b065accb29394420 · engagement crosswalk SHA-256 61fa6163cff97e3431c1e93847e4c168f9fc960958fc87900f5c60c95c933e29
Integrated engagement detail
ONE ENGAGEMENT, DIFFERENT VIEWS
How the guide, questions and packages connect.
The Studio organizes the work in seven stages. The navigator asks nine delivery questions. Four packages group the work for review and acceptance. These are views of the same engagement, not competing timelines or authorization decisions.
Stage names describe preparation and navigation; an engagement assessment does not replace an independent control assessment or an authorization decision. See each output’s prerequisites and limitations in the navigator.
Capture the boundary, inherited controls and operating responsibilities in the draft security plan and concept of operations. Track gaps as corrective actions with owners.
STRENGTHEN WITH OBSERVATION
Bring application evidence into the review.
With dependency mapping, owners review observed flows to refine connections, control responsibilities and migration groupings.
Explore what moves when authorization is delayedSupporting detail
THE HOLD
What actually waits, and what only looks like it does.
Green work starts the day you decide to start. Dashed work genuinely waits for the landing-zone letter. Choose a later month for the letter and watch what moves: the blocked chain slides with it, and the green work never does, because it was never waiting.
Letter at M1: the blocked chain finishes about six weeks later, at M2.5. By then 0 of the six unblocked workstreams are finished and 3 more are in motion. The queue in front of the letter was always longer than the queue behind it.
0unblocked lanes already finished when the letter lands
3more in motion that day
M2.5testers reach IL5 — moves month for month with the letter
Letter at M2: the blocked chain finishes about six weeks later, at M3.5. By then 0 of the six unblocked workstreams are finished and 5 more are in motion. The queue in front of the letter was always longer than the queue behind it.
0unblocked lanes already finished when the letter lands
5more in motion that day
M3.5testers reach IL5 — moves month for month with the letter
Letter at M3: the blocked chain finishes about six weeks later, at M4.5. By then 0 of the six unblocked workstreams are finished and 6 more are in motion. The queue in front of the letter was always longer than the queue behind it.
0unblocked lanes already finished when the letter lands
6more in motion that day
M4.5testers reach IL5 — moves month for month with the letter
Letter slips to M4, 1 month late. Testers now reach IL5 at M5.5, month for month with the slip. Notice what did not move: every green lane. The delay was added to the end, not saved — unless the green work idled too, which is the one mistake this chart exists to prevent.
1unblocked lanes already finished when the letter lands
5more in motion that day
M5.5testers reach IL5 — moves month for month with the letter
Letter slips to M5, 2 months late. Testers now reach IL5 at M6.5, month for month with the slip. Notice what did not move: every green lane. The delay was added to the end, not saved — unless the green work idled too, which is the one mistake this chart exists to prevent.
3unblocked lanes already finished when the letter lands
3more in motion that day
M6.5testers reach IL5 — moves month for month with the letter
Letter slips to M6, 3 months late. Testers now reach IL5 at M7.5, month for month with the slip. Notice what did not move: every green lane. The delay was added to the end, not saved — unless the green work idled too, which is the one mistake this chart exists to prevent.
4unblocked lanes already finished when the letter lands
2more in motion that day
M7.5testers reach IL5 — moves month for month with the letter
Letter slips to M7, 4 months late. Testers now reach IL5 at M8.5, month for month with the slip. Notice what did not move: every green lane. The delay was added to the end, not saved — unless the green work idled too, which is the one mistake this chart exists to prevent.
5unblocked lanes already finished when the letter lands
1more in motion that day
M8.5testers reach IL5 — moves month for month with the letter
Letter slips to M8, 5 months late. Testers now reach IL5 at M9.5, month for month with the slip. Notice what did not move: every green lane. The delay was added to the end, not saved — unless the green work idled too, which is the one mistake this chart exists to prevent.
6unblocked lanes already finished when the letter lands
0more in motion that day
M9.5testers reach IL5 — moves month for month with the letter
M0M2M4M6M8M10M12
Can start before the landing-zone letter — needs no letter, start now
Categorize and select controlsM0–M4
Confirm inherited mission servicesM0–M5
Define the application shapeM0–M6
Map mission users to ICAM groupsM1–M5
Plan the dual run and the fail-backM1–M7
Draft the mission service catalogM2–M8
Genuinely waits for the landing-zone letter — and only for the letter
Vend the workload account to the test OU
Place the ZTNA connector in the IL VPC
Establish tester access to IL5
After the authorizationAdmitting production users and live CUI, then cutting over, belong to the authorization calendar, not to this chart.
Landing-zone letter
Needs no letter — start nowGenuinely waits on the tenancy
Illustrative durations for a mid-sized program. The shape is the point: the unblocked column is longer than the blocked one, and every month spent not doing it is added to the end, not saved.
Timing, evidence and the two environmentsSupporting detail
Foundations is approximately eight weeks, including the two advance weeks of the data call, and can stand alone on mission-attested evidence. Dependency mapping is recommended: at least twelve weeks of observation, overlapping Foundations. The combined engagement is approximately eighteen to twenty weeks.
The scope covers IL5 and IL6. Shared decisions stay aligned; each environment retains its architecture, evidence and operating differences. The provider’s landing-zone authorization is a separate clock. Foundations mechanics · Dependency & Launch.
YOUR NEXT MOVE
Choose the on-ramp. Carry the package forward.
Leave with a current-state picture, a transformation plan and a working start on the Risk Management Framework (RMF) package. Continue with your team, a delivery partner or a suitable platform, confirming what can be inherited and what remains yours.
Set the pace from evidence, team capacity and required approvals.
Carry the preparation into the next authorization.
Where this sits
The mission map places foundation design, authorization preparation and operations on the wider cloud adoption road.
What follows
Carry the boundary, control responsibilities and evidence into ATO acceleration, a complementary follow-on supporting the mission system’s own authorization.
Week 4 and Week 8 describe the standard Foundations schedule, including two advance weeks for the data call. Foundations is approximately eight weeks; Application Dependency Mapping requires at least twelve weeks of observation, overlapping Foundations, with approximately eighteen to twenty weeks total for the combined engagement. Timing depends on agreed scope, access, telemetry and participant availability. ADM delivery and acceptance milestones are agreed for the combined scope, not promised at Week 8. These are preparation estimates, not authorization or migration completion dates.
When Application Dependency Mapping (ADM) is included: Device42 and the practitioner produce the following work within these package families; these are not additional Studio export claims. The client supplies approved discovery access, credential owners, a migration list and application owners for validation. Discovery and observation take place only in the approved client environment. Foundations-only scope excludes these items.
Package contents and intended readersSupporting detail
Week 4
Midpoint snapshot
Where the mission stands, confirmed with the people who own it, while there is still time to change course.
Foundations receiptFor the sponsor The entry: the moment, the thesis, who signs.
AssessmentFor the engineer and the ISSM Fifty-one positions with their evidence quality and confidence, and the trace an assessor can follow.
With Application Dependency Mapping
Conditional on agreed ADM scope and its observation and review milestones.
Discovery design and prerequisitesFor the engineer and the ISSM Every in-scope class has a discovery method, a credential owner and a path; the design agreed with the ISSM. The ISSM's written approval of the appliance is tracked as a checkpoint, not a condition of acceptance.
Week 8
Readiness package
For the authorizing chain and operators: proposed foundation decisions, control evidence and gaps, draft security documents, corrective actions and operating responsibilities for review.
GSS exit receipt ZTFor the engineer and the ISSM The nine foundation decisions and their instruments.
Package readiness ZTFor the engineer and the ISSM Authority, boundary, categorization and inheritance, and where every selected control stands, read from the evidence.
System security plan — draft ZTFor the engineer and the ISSM Statements assembled from the record; refused rather than invented.
Plan of action & milestones ZTFor the engineer and the ISSM Findings with clocks, owners, and closure evidence.
CONOPS document ZTFor the program The eight-section concept of operations and its annex instruments, the RACI among them.
With Application Dependency Mapping
Conditional on agreed ADM scope and its observation and review milestones.
Discovery baseline reportFor the engineer and the ISSM Every in-scope class discovered; coverage of the migration list at the agreed threshold, the remainder named; every record owned or listed unowned; drawn on no less than thirty days of dependency sampling, across a month-end.
Dependency maps and affinity groupsFor the engineer and the ISSM Every business application on the list has a diagram reviewed by its owner; external dependencies, day-one flows and crossings marked.
Business application registerFor the engineer and the ISSM Every candidate workload is a defined business application with owner, hosting, data families and dependencies.
Data-quality reportFor the engineer and the ISSM Duplicates, unowned, stale and unreachable records counted at the baseline, and trended again at handover.
Week 8
Transformation package
For the program and its leadership: what moves, in what order, through which gates, the road from today's reading to the next level, and the brief leadership needs to decide.
Transformation plan ZTFor the program What moves, in what order, through which gates, with every workstream sized and placed on its horizon.
The road aheadFor the program From the reading to the next level, step by step, with guardrails.
Executive briefFor the sponsor What leadership needs to understand and decide.
Week 8
Final package
The handover: what was accepted, every open item with an owner, and the sealed record over all of it.
Closeout receiptFor the sponsor What was handed over and accepted, every open item with an owner, and the record sealed by digest.
With Application Dependency Mapping
Conditional on agreed ADM scope and its observation and review milestones.
Utilization and right-sizing reportFor the engineer and the ISSM Eight weeks of samples on every in-scope server; a sizing per workload with its basis.
Dependency-informed wave planFor the program Every wave lists its members and crossings; receiving team and rollback written by the practitioner with the Program; no affinity group split without a recorded reason.
Device42 runbook and handover receiptFor the program Discovery schedule, credential rotation, refresh and data-quality pass documented and run once by the platform owner.
A USABLE HANDOVER
Prepare once. Carry the work forward.
Keep the documents aligned.
Shared boundaries, control responsibilities and findings feed the documents from one record. The executive brief and transformation plan give leadership a concise view of the work.
Give the receiving team a working foundation.
The concept of operations carries the service catalog, responsibility assignments and interconnection specifications. The closeout receipt records acceptance and open work with owners.
Where the Zero Trust inputs liveSupporting detail
The pre-plan travels inside the existing deliverables. Migration sequencing, operating responsibilities, boundaries and control responsibilities stay connected. The draft system security plan and plan of action and milestones (POA&M) are assembled from the record for review, with supporting evidence and gaps visible.
Decision packages support the officials responsible for funding, procurement, release and deployment. The authorizing official retains every authorization decision.
Workshop scope and agenda
WHAT YOU LEAVE WITH
A defined move. A named owner.
The preparation priorities
Which existing designs and documents to build on, where the gaps are and which workstream should begin first.
The next accountable action
A scoped next step: the documents and evidence to prepare, who reviews them and who owns the work.
SOURCING THE WORK
Build, contract, acquire or join.
Build
Own the foundation, staffing, operations and authorization responsibilities directly.
Contract
Use specialist capacity for defined work; specify the responsibilities retained by the mission.
Acquire
Consume a service where capability is better bought than engineered.
Join
Inherit enterprise capabilities and tenancy obligations through an existing program.
Apply these choices to the environment and to individual services. Paths may be combined. See the same sourcing choices on the mission map →. The mission retains the decision to adopt cloud, retain, modernize in place or defer.
The questions behind the starting recommendationSupporting detail
FROM MANDATE TO NEXT MOVE
Move from a mandate to a defensible next move.
The road every mission walks, in the order it asks its questions. The workshop starts it; the preparation that follows carries it.
01
Mandate
Move or modernize.
Question
What mission result makes the change worthwhile?
Outcome
A clear statement of the mission result the change must deliver.
02
Uncertainty
See the whole decision field.
Question
What must be understood before anyone chooses a path?
Outcome
One view of the applications, infrastructure, dependencies, authorization, data, funding, shared services, and owners involved.
03
Cloud Waypoint
Build a shared understanding.
Question
What can the mission use, inherit, or trust today?
Outcome
A shared view of what exists, what the Department provides, and what is genuinely missing.
04
Path
Leverage. Establish. Sequence.
Question
What should carry forward, be established, and begin first?
Outcome
A practical path showing what to reuse, what foundations to establish, and which engineering and authorization decisions come first.
05
Decision
Name the value before the move.
Question
Where can cloud create enough mission value to justify movement?
Outcome
A specific value case: enable a focused AI or machine-learning use case, inherit resilience, decouple a constrained back end, or improve mission speed, continuity, security, or cost.
06
Next move
Turn the decision into owned work.
Question
What happens next, and who owns the decision?
Outcome
A defined move, its value case, its decision owner, the next engineering action, and who operates and pays for it after launch—carried into Foundations as the first accountable work.
Movement is optional. Retain, modernize in place, or defer when cloud would add cost without enough mission value.
THREE HOURS · FOUR CONVERSATIONS
The working agenda.
00–30
Mission & outcomes
What must improve, and who decides?
30–75
Foundation & responsibilities
What can be inherited, and who designs and operates the rest?
75–135
Applications & documents
What evidence and paperwork exist, and what needs preparation?
135–180
Scope & ownership
What should we prepare first, and who owns the next action?
CLOUD WAYPOINT
Move preparation forward. Start with a conversation.