See it work
Follow one event across the enterprise.
A mission service slows down. Watch who sees it, who acts and who proves it's fixed.
Colors show who owns each step: provider, shared platform, mission, security. Select a step to hold on it.
Seeing an event reach the right owner and return with evidence of resolution makes the operating model concrete. Foundations defines the responsibilities, interfaces and evidence requirements. Foundations Plus ADM adds observed workload dependencies to refine those handoffs. This work guides implementation and rehearsal, giving the responsible authority a clearer basis for downstream review and approval.
What keeps working when the connection changes?
Switch connection states to explore how the mission and enterprise work together.
Seeing how a change in connectivity affects the mission makes continuity needs clear. Foundations records what needs to continue locally, who responds and how service is restored. Foundations Plus ADM adds observed dependencies to refine that design. The resulting operating plan guides testing and supplies evidence requirements for the responsible authority’s downstream review and approval.
Illustrative scenario for discussion. See selected handover previews →
Reference
The ideas behind a cloud decision, in order.
Each concept builds on the one before it: service models, shared responsibility, boundaries, inheritance, then evidence and decisions. Open a term, or go to the source.
Service models IaaS · PaaS · SaaS
How much of the stack the provider runs for you.
Shared responsibility
Which controls the provider, the platform and the mission each own.
Authorization boundary
What the authorization covers. Anything crossing it needs an agreement.
Control inheritance
Using a control another authorized system already provides, with its scope written down.
ATO Authorization to Operate
The official's decision to accept the risk of running the system.
POA&M
Known gaps, each with a fix, an owner and a date.
CSSP
The cybersecurity service provider that watches and responds for the enterprise.
Continuous monitoring
The reporting rhythm that keeps an authorization current.
After preparation: where the authorization months go
The same five moves, two ways. The longer path is not a slower team. It is the same team building in sequence what the shorter path acquires.
A planning model, not a promise: the shorter path needs a usable contract vehicle, an acquired boundary, long-lead connections ordered in week one and owners who decide weekly. The timing shown is one illustrative set of assumptions, including an approximately ninety-day evidence window. The required observation period, test window and decision cadence are set by the applicable authority and engagement; these are not universal durations or an authorization forecast.
DoD provenance. Requirements matched to your agency.
Our method brings the discipline of DoD cloud preparation to federal civilian agencies: understand the boundary, make responsibilities explicit and carry evidence into decisions. The applicable rules come from your agency, jurisdiction or institution.
| Path | Start from | Reuse | Keep in view |
|---|---|---|---|
| DoD missions | The applicable DoD and component instructions, the mission information and the proposed hosting boundary | Controls inherited from the cloud offering's provisional authorization, with mission-owned controls named | The provider's provisional authorization and the mission system's authorization cover different scopes |
| Federal civilian | The agency's own system authorization under its RMF | The offering's FedRAMP package, and what it lets the agency inherit | FedRAMP covers the provider's offering; the agency still decides for its own system |
NIST SP 800-53 Rev. 5 provides a shared security and privacy control foundation for federal control discussions. Baseline selection, parameters, overlays and evidence obligations differ. DoD RMF governs the risk-management process; the Cloud Computing SRG adds requirements for DoD cloud use. FedRAMP helps agencies evaluate and reuse cloud-service evidence within its applicable scope. We connect that evidence to the customer’s own responsibilities and review process. Provider status does not replace the customer’s approval decision.
Program references: FedRAMP agency use · NIST SP 800-53 Rev. 5 · GSA cloud security and DoD SRG.
Cloud Waypoint can export the system security plan and the plan of action and milestones as OSCAL 1.2.3 files, and the controls as an eMASS-shaped sheet for preparation. Not a claim of OSCAL conformance or of acceptance by eMASS, Xacta or any agency.
For leadership
Brief leadership
You don't 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.
Name one mission service, who uses it and what an interruption would affect.
Identify the mission owner, shared-platform team, providers and Cybersecurity Service Provider (CSSP). Keep unknown handoffs visible.
Ask how a release, failure or security event reaches a named decision-maker, and what record demonstrates the outcome.
Compare skills, conversion effort, integration, external services and sustained operations across the same mission scope. System count alone cannot set headcount.
Investment becomes an operating habit: the 48-month path
Enter the next cohort when its evidence gate is met; the retained team of service owners, shared engineering and the mission and CSSP interfaces carries it. Reaching month 48 does not by itself establish a score or an authorization, and these are advisory emphases, not a cost estimate.
What a 3 looks like
People own the service, processes govern the decisions, and technology carries the work and leaves evidence of how it operated. A plan, a tool purchase, a certificate or an elapsed month cannot raise it.
Adds reusable automated evidence. Neither level grants authorization. A drafted document is not an operating practice.
When evaluating potential help, ask
- 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?
Research prompts, not a recommended scope, a client finding or a commitment.
Security architecture and deployment review
Understand the offline Workbench’s architecture, data handling and the evidence a receiving security team should review. Read the public security overview (PDF, 3 pages). Package-specific evidence is available on request.
Historical method example
This retained film illustrates shared-service responsibilities. It is background teaching material from the earlier offering.