Prepare the move and the authorization together.
One shared picture of the applications, the boundary and the responsibilities, carried from the first working session to the authorizing official. Decisions stay with the mission.
We are cloud consultants who understand enterprise operations and cloud migration strategy, and we help your ISSM bridge to the future concept of operations — the boundary, what’s inherited, what’s shared, what’s still yours — so the authorization package starts from the cloud architecture as it will be built. Not a finished package, but a jumpstart: your ISSM, ISSO and Authorizing Official keep their roles.
- Eight weeksto a foundation design, draft SSP and CONOPS, and operating model
- Authorization starts earlythe evidence Prepare, Categorize and Select need, collected as the work runs, so your ISSM begins ahead; Assess and Authorize stay with the government
- Nothing waits that need not waitsix workstreams start before the landing-zone letter arrives
- UnderstandWhat you run, what it depends on, and who owns it.
- ShapeThe options, and what each one asks of the security review.
- PrepareThe next move, the owners, and the evidence to bring.
You bring what you have.
Your teams leave with work they can use.
Three stages. We start from your existing material and fill the gaps together.
-
Establish the starting point
You bring
- Inventories and architecture
- Mission priorities
- Existing security documents
We work through
- Scope and information needs
- Current-state gaps
- Named officials and boundary
You take forward
- Mission context
- Proposed boundary
- Evidence position and open questions
-
Connect the design and the responsibilities
You bring
- Application communication data
- Hosting designs and provider evidence
- Service agreements
We work through
- Dependencies and modernization options
- Shared services and inheritance
- Handoffs among teams
You take forward
- Foundation design
- Draft SSP and CONOPS
- Responsibility map and actions
-
Sequence the transition and hand over
You bring
- Delivery priorities
- Change windows
- Receiving-team constraints
We work through
- Modernization pathways
- Transition sequence
- Implementation still needed
You take forward
- Transformation plan and brief
- Draft authorization inputs
- Closeout with owners
Protected evidence is reviewed in your environment and stays there. See what the handover looks like →
Most of the work is not waiting on anyone.
The provider’s landing-zone letter gates three tasks. Six others can start the day you decide. Move the letter and see what moves with it.
Letter at M3: the blocked chain finishes about six weeks later, at M4.5. By then all six open workstreams are in motion. The queue in front of the letter was always longer than the queue behind it.
Start now · needs no letter
Waits for the letter · and only for the letter
Illustrative durations for a mid-sized program. Admitting production users and live CUI comes after authorization and is not on this chart.
About eight weeks to a foundation.
Eighteen to twenty with the application picture.
Both run alongside the provider’s own authorization clock, which belongs to the provider.
The first two foundation weeks are the advance data call. Illustrative timing for IL5 and IL6. Durations depend on scope, access, telemetry and availability. They are not authorization or migration commitments.
We prepare. Your officials decide.
The work sits inside the first three steps of the Risk Management Framework, so the teams that implement, assess and authorize receive something usable.
- PrepareSet the context
- CategorizeUnderstand impact
- SelectChoose controls
- ImplementPut controls to work
- AssessEvaluate effectiveness
- AuthorizeThe AO decides
- MonitorKeep evidence current
What we contribute
Boundary and dependency context, draft security documents, named responsibilities and open actions.
What stays with you
Assessment, risk acceptance and the authorization itself. The authorizing official retains every risk decision.
Not a DoD mission? The method travels. The requirements vary.
DoD. A provisional authorization for the cloud offering and the authorization for your mission system cover different scopes. An IATT carries its own conditions and limits.
Federal civilian. FedRAMP addresses the provider’s offering. Your agency still makes the risk decision for its own system.
State, local and education. We start from the jurisdiction’s or institution’s policies, data obligations and adopted frameworks, including FERPA where it applies.
Operating disconnected or at the edge?
- What must keep working without external connectivity?
- Which application and data dependencies cross the proposed boundary?
- Who owns infrastructure, platform administration and application operations?
- What evidence does the authorizing chain require?
The first step is a three-hour working session
Leave with a clear next move.
One conversation with your application, cloud foundation and cybersecurity leads in the same room. The workshop informs the choice. The mission decides.
A move worth examining
Adopt cloud, retain what works, modernize in place, or defer.
Preparation priorities
Designs to reuse, gaps to resolve, reviews to plan.
The next accountable action
A scoped next step and an owner to confirm it.
- Mission and outcomesWhat must improve, and who decides?
- Foundation and responsibilitiesWhat the provider delivers, what the landing zone delivers, what stays yours.
- Applications and evidenceWhat connects, what can be reused, what needs preparation?
- Scope and ownershipWhat happens first, and who carries it forward?
Who to bring and what to prepare
Bring the mission sponsor, application owner, cybersecurity lead and a hosting or operations representative. Add acquisition or funding when their decisions shape the next step.
Prepare an approved, non-sensitive summary of goals, application landscape, known constraints and the current security review path. Note which inventories, architecture, security plans and provider agreements could feed a later data call. Agree secure handling before sharing anything protected.
Who does what under each delivery model
Illustrative only. A mission may combine these. Confirm assignments against the actual service agreements. R performs · A owns completion · C consulted · I informed.
Join a shared service
| Activity | Mission team | Enterprise service | Cyber team |
|---|---|---|---|
| Set mission priorities | A/R | C | I |
| Run the foundation service | C | A/R | C |
| Deliver agreed cyber monitoring | C | C | A/R |
| Maintain security-package inputs | A/R | R | R |
| Plan the application transition | A/R | C | C |
Contract the service
| Activity | Mission team | Contracted foundation | Cyber team |
|---|---|---|---|
| Set mission priorities | A/R | C | I |
| Run the foundation service | A | R | C |
| Deliver agreed cyber monitoring | C | C | A/R |
| Maintain security-package inputs | A/R | R | R |
| Plan the application transition | A/R | C | C |
Operate internally
| Activity | Mission team | Internal foundation | Cyber team |
|---|---|---|---|
| Set mission priorities | A/R | C | I |
| Run the foundation service | C | A/R | C |
| Deliver agreed cyber monitoring | C | C | A/R |
| Maintain security-package inputs | A/R | R | R |
| Plan the application transition | A/R | C | C |
Start with a conversation.
Tell us the decision in front of you and who should be in the room. We will reply with a proposed date and a short prep note.
Keep it non-sensitive. No credentials, CUI, client evidence or mission data in email or in this form.