3
Consistent
Demonstrate the practiceThe practice runs consistently, supported by telemetry, tooling, or operational evidence.
Repeat the work→Preserve the record→Review the evidence
The Full Picture / A field guide to hybrid cloud
Understand the move.
Connect the responsibilities.
For the person researching what cloud means for their mission—and what help their organization may need.
Start with an example, or go straight to a question. Come back whenever you need the detail.
START WITH THREE QUESTIONS
01↗02↗03↗
What changes when we use cloud?
Begin with services you already know. See what moves, what is shared and what remains yours.
Who remains responsible?
Trace the provider, shared platform and mission team—then connect operations with security.
What should I bring back to leadership?
Gather the questions, evidence and investment implications needed to scope the next conversation.
Two perspectives / One operating environment
Enter through the question
you are carrying.
Both perspectives follow the same mission service. Neither replaces the other.
When the relationships are clearCompare investment pathways →See what evidenced progress looks like →
A learning and reference environment. All scenarios, staffing illustrations and progress snapshots are fictional. An Authorizing Official (AO) retains the authorization decision; this guide does not assess your organization.
Return to a question
Reference library
Cloud concepts, operating responsibilities and the transformation work—connected in one place.
From on-premises experience to cloud
Connect the concepts.
Each topic starts with familiar experience, then shows the operations and authorization questions side by side.
Cloud service modelsThe service model describes what you consume: infrastructure, a platform, or a finished application. Cloud offers pooled resources on demand; it is more than a change of building.
A familiar starting point
You may already separate facilities, servers, operating systems, and applications. Start with those familiar layers.
The cloud question
Ask which layers your team still configures and maintains for the specific service being considered.
Operations asks
Who patches, restores, and supports each layer?
Authorization asks
Which responsibilities are provider-supplied, shared, or mission-owned?
BoundariesAn authorization boundary identifies the system elements covered by an authorization. An external connection still needs examination even when the connected system sits outside that boundary.
A familiar starting point
A site, enclave, network segment, or organization may be your usual starting point for describing a system.
The cloud question
Draw three views separately: the network path, the operating responsibilities, and the authorization scope. Do not assume their edges coincide.
Operations asks
Where does a service cross to a team you depend on?
Authorization asks
What is inside the agreed scope, and how are outside dependencies handled?
Control inheritanceA system may receive protection from controls implemented and maintained elsewhere. Inheritance describes that relationship; its applicability needs to be established for the system.
A familiar starting point
Your organization may already rely on shared facility protection or centrally operated services.
The cloud question
Ask for the documented scope and conditions, then identify what your mission must still implement, configure, or demonstrate.
Operations asks
What shared service must remain available for the inherited protection to work?
Authorization asks
What evidence supports the inheritance claim, and what responsibility remains?
Dependencies and handoffsA dependency is something your mission needs from another component or team. A handoff is the point where work, information, or a decision passes between them.
A familiar starting point
A local application can still depend on a directory, DNS, a network link, a help desk, or a backup team.
The cloud question
Trace the whole service. For each external dependency, ask what happens if it is slow, unreachable, or unable to accept the handoff.
Operations asks
What continues locally, what stops, and who restores the connection?
Authorization asks
How are access decisions and evidence retained while the handoff is unavailable?
Evidence, findings, and decisionsEvidence supports a statement about the system. A finding interprets that evidence. A recommendation proposes what to do next. The responsible official makes the decision.
A familiar starting point
A successful backup job and a successful restore answer different questions. The same distinction matters when reading cloud readiness claims.
The cloud question
Keep the source, date, scope, unknowns, and responsible reviewer attached to the conclusion. Revisit it when the evidence or operating context changes.
Operations asks
Does the evidence demonstrate the mission service can perform or recover?
Authorization asks
What supports the review, and what decision or condition is still open?
Make the reasoning reviewable.
Here, an inference is a reasoned interpretation of evidence in its operating context. Keep what is known, what is assumed, and what still needs proof visible. These worked examples illustrate the consulting approach; they do not run an assessment.
What would change this interpretation?
Illustrative reasoning, not a finding about your environment. Missing evidence leaves a question open; it does not by itself prove failure or grant approval.
Explore how a changed assumption affects the questions →Prepare the next conversation
Bring back a better brief.
You do not need every answer before asking for help. Bring a mission example, the open questions and a clear idea of the evidence you want to see.
The service that matters
Name one mission service, who uses it and what an interruption would affect.
Understand its dependencies →The responsibilities to clarify
Identify the mission owner, shared-platform team, providers and Cybersecurity Service Provider (CSSP). Keep unknown handoffs visible.
Inspect retained skills and supplier interfaces →The proof to ask for
Ask how a release, failure or security event reaches a named decision-maker—and what record demonstrates the outcome.
Distinguish an observation from a conclusion →The investment conversation
Compare skills, conversion effort, integration, external services and sustained operations across the same mission scope.
Examine the five-year implications →
When evaluating potential help
- How will you establish our starting point and validate it with our service owners?
- What capability will our retained team need after you leave?
- How will operating records support authorization review without confusing evidence with approval?
- What assumptions could change your proposed sequence or investment?
- What will we be able to inspect at the first checkpoint?
Use “Print this view” to take these prompts into a conversation. They are research prompts, not a recommended scope, client finding or commitment.
Watch one event connect the enterprise.
Begin with a familiar service fault. Change the event or its source, then follow each owner, handoff and decision.
Reading the example: GSS = General Support System, the shared environment supporting mission systems. CSSP = Cybersecurity Service Provider. People authorize actions; the graphic illustrates the recorded handoffs.
A fictional hybrid enterpriseSelect where this event occurs · dashed outlines show illustrative GSS scopes
Defined boundary handoffNamed owner · approved interface · acknowledged receipt
One enterprise operating flow
Linked work recordsJira / ServiceNow · example alternatives
Mission operationsRelease · restore · sustain
Authorization evidenceReviewable records · retained AO decision
Provider icons, boundaries and example scope
These are fictional General Support System (GSS) scopes, not accepted authorization boundaries. Selecting a source changes the illustrated origin, not provider suitability or service availability. Only a scoped event or management-record handoff is shown; no direct cloud-to-cloud workload connectivity is implied. The detailed capability catalog retains its separately labeled Azure/Jira example.
The AWS, Microsoft, Google and Oracle provider families are named in the JWCC award announcement. A logo does not establish that a service, deployment or boundary is available or authorized for a mission.
Official diagram assets: AWS · Microsoft Azure · Google Cloud · Oracle OCI. Provider artwork keeps its colors; the People / Process / Technology colors describe responsibility, not vendor identity. GDC here illustrates a connected deployment; an air-gapped deployment needs a separately defined permitted exchange, not the live path shown here.
How does this connect to the investment story?
OPERATIONSRepeatable serviceRelease · recover · improve
AUTHORIZATIONDefensible evidenceReview · resolve · AO decision
↶ Operating evidence returns to the assessment and the next investment decision
What changes at level 4?
4
Automated
Make the evidence reusableReusable / automated evidence that supports cATO evidence expectations without asserting authorization.
Capture & link→Check quality→Route for review
Additional capability
Maintained evidence pipelines, reusable mappings, provenance, freshness checks and visible collection failures.
Additional investment
Engineering, integration, testing, skilled ownership and recurring upkeep—not simply another license.
Additional proof
Demonstrate reusable automated evidence across relevant runs, changes and failures. People still review and decide.
The routes illustrate a release-evidence pattern, not scoring criteria or mutually exclusive technology choices; a level 3 practice can already use automation. Apply the governed assessment to determine the evidence posture. Neither level grants ATO or cATO.
The mission-owner questionWhere would the additional reuse, timeliness or reduced manual effort justify its whole-life cost—and where is consistent operation sufficient for the chosen objective?
Inspect the evidence-automation dependencies →Different paths. Visible implications.
Select a pathway, then a year. These are conversation starters, not recommendations or forecasts.
Transformation planning horizon · Years 1–4Year 5 · Sustain & reassess
What belongs in the investment—not just tools and hiring
Recruiting, skills, service ownership and supplier oversight.
Dependency discovery, application remediation, platform patterns, migration and testing.
Interfaces, identity, record linkage, automation and upkeep.
Dual running, training, temporary delivery constraints and cutover support.
Specialist delivery, coverage, recurring fees and exit or transfer effort.
Platform lifecycle, licenses, evidence review, recovery exercises and skills renewal.
Compare whole-life costs and mission outcomes on the same scope. Acceleration can raise near-term demand while shortening legacy overlap; its five-year cost is not predetermined. Credit retired cost only after verified decommissioning and contractual exit.
Track what changed. Show what proves it.
An 18-month engagement within a five-year decision horizon. A later date alone never earns a better status.
18-month engagement
→ Continued investment, operations and review through year 5What would make this a real engagement tracker?
Agreed scope, baseline evidence, named owners, dated acceptance and the governed reporting pack. This view demonstrates the presentation only: it has no client input, saved progress, score calculation or connection to live records.
Illustrative learning guide · no client findings or commitmentsBrowse the reference library →
The Full Picture
What a three looks like.
Every time it matters.
People own the service. Processes govern the decisions. Technology carries the work—and leaves evidence of how it operated.
1,000 systemsFictional enterprise scale53 workstreamsCanonical catalog, linked selectively48-month horizonPlanning scaffold, evidence-led gates2 parallel outcomesOperations + authorization enablement
Sustainable operations
Qualified teams repeatedly release, detect, respond, recover and improve—with observed results across shifts and supplier handoffs.
Authorization enablement
Scoped evidence, inherited responsibilities and unresolved risk reach the appropriate review. The AO retains the authorization decision.
Operate the offering
Choose the event. Unpack the capability.
Planned work and unexpected events traverse the same operating model. Select a step, then a capability to inspect who provides it and what your retained team must know.
The traceable handoff
Fictional records. Each handoff needs an owner, an acknowledgement and an explicit disposition when it fails.
Capability map
Gold edge: involved in this step.
Blue card: the capability you are inspecting.
People run the automation
The retained team behind 1,000 systems.
Illustrative topology: 20 platform cells support 50 systems each; 50 mission teams own 20 systems each. These are planning groupings, not prescribed authorization boundaries, staffing ratios or client facts.
Size a watch pool from demand
An adjustable arithmetic illustration for one pooled triage function. System count alone cannot determine headcount.
Illustrative pooled-watch minimum
Excludes platform/release engineering, mission teams, specialist escalation, separate CSSP staffing and management. Peak concurrency, skill mix and scheduling may increase this floor.
Skill readiness needs observed tasks and teach-back: configure a source, diagnose a missing receipt, run an approved change, recover from a failed deployment and explain the retained evidence. Certificates alone do not demonstrate operation.
Investment becomes an operating habit
The 48-month path is sequenced by dependencies.
Use the canonical workstream timing as a starting scaffold. Enter the next cohort when its evidence gate is met. Reaching month 48 does not itself establish a score or an authorization.
Know and own the system
- Inventory services, boundaries, inherited support and unknown owners.
- Baseline retained skills and supplier responsibilities.
- Choose critical event paths and a bounded initial cohort.
Invest: service ownership, discovery, skills baseline and minimum monitoring.
Exit evidence: named owners and a tested initial source-to-response chain; gaps stay explicit.
Make the pattern repeatable
- Standardize GSS baselines and service intake.
- Build approved interfaces, change paths and recovery tests.
- Train primary operators and deputies on real tasks.
Invest: platform engineering, ITSM integration, telemetry quality and release automation.
Exit evidence: multiple operators complete the same workflow with traceable results and exceptions.
Prove consistency across cohorts
- Scale the proven pattern across service families.
- Exercise failure, surge, supplier and disconnected handoffs.
- Feed recurring causes into standards and skills.
Invest: reliability, detection/integration engineering, capacity and evidence maintenance.
Exit evidence: repeatable outcomes across shifts and cohorts over an agreed observation period.
Sustain and selectively automate
- Maintain the consistent practice through turnover and change.
- Reassess weak positions and recurring exceptions.
- Automate reusable evidence where it adds value.
Invest: lifecycle upkeep, succession, supplier continuity and evidence automation.
Exit evidence: durable operation and current evidence, with named owners accepting or remediating residual gaps.
These are advisory investment emphases, not replacements for individual catalog launch/completion values. Several foundational workstreams begin at month 0 and span later horizons; inspect each in the catalog below. A consistent practice may be demonstrated earlier, while some positions may remain below target.
The test of a three: can a different qualified team repeat it?
For a release: scope, approval, deployment, tests and recovery are traceable. For a fault: ownership, restoration, cause and corrective verification are observed. For an intrusion: custody, CSSP analysis, authorized response and unresolved gaps are explicit. Demonstrate this across representative operating conditions; investigate exclusions rather than inferring coverage of all 1,000 systems.
Keep the scoring method intact
Canonical scale: 0 Reactive · 1 Inconsistent · 2 Defined · 3 Consistent · 4 Automated. Three needs corroborating operational evidence; four adds reusable/automated evidence without asserting authorization. The governed assessment has 51 evidence positions across 10 domains and People / Process / Technology weights of 30 / 40 / 30. This companion neither computes scores nor changes those rules. A selected event is a way to examine the operating chain, not a substitute for evaluating the required evidence positions.
The loop returns to the client record
Deliverables become the explanation of observed operation.
One coordinated record, at three decision depths. A change or incident produces candidate evidence; the governed assessment decides what that evidence supports.
Executive Brief
The decision
Explain the current evidence posture, consequences, investment priorities, accountable owners and decisions needed. Separate the 3.0 ambition from demonstrated progress.
Transformation Plan
The investment path
Sequence the 53-workstream catalog around dependencies, funding, people, provider services and client priorities. Use the 0–48-month horizon to organize the work, not promise authorization.
Technical Analysis
The traceable basis
Preserve source records, boundary assumptions, role/tool interfaces, operational tests, reasoning and gaps. Link accepted evidence to the relevant governed assessment positions.
Event + service ID→Source / change / case records→Reviewed evidence + open gaps→Assessment positions→Workstream investments↻
These examples connect operating capabilities to transformation workstreams. They are learning aids, not findings about your organization. Evidence from your environment and review by the responsible officials determine what applies.
Canonical catalog / Practitioner crosswalk
From this capability to the transformation work.
Explore all 53 workstreams, or follow the subset relevant to a capability or event. Displayed dependencies and timing come from the catalog; applicability still needs client validation.
Sources, scope and custody
Fictional learning illustration, 24 September 2026. No live connections, client records or assessment calculations. Azure + Jira is one illustrative technology arrangement; availability, boundary suitability, procurement and data admission must be validated for the actual environment.
- Cloud Waypoint maturity terminology: level 3, Consistent, means the practice runs consistently with operational evidence. Level 4, Automated, adds reusable automated evidence. Neither level grants authorization. Compare the evidence and investment →
- Cloud Waypoint’s 53-workstream catalog supplies the workstream names, dependency links, planning scaffold and skill guideposts. Capability crosswalks and investment examples are advisory; confirm applicability and sequencing for your mission.
- Microsoft: Azure Monitor data collection rules · Log Analytics export — example collection and export mechanisms.
- Atlassian: change types · Incident and problem management — distinct but linked practices.
- NIST SP 800-137 — continuous monitoring as a program. NIST SP 800-61 Rev. 3 — incident response within cybersecurity risk management.