Governance and mission ownershipGovernance is the authority gate: the AO relationship, risk tolerance, and decision forum must exist before any authorization package can be sponsored.
OpenCollapse
GOV-1
Cloud governance charter, decision forum, and decision logGateAccountable forum with documented decision rights and escalation path to the AO.
M0 → M6
GOV-2
AO alignment and organizational risk-tolerance definitionGateDesignated Authorizing Official engaged; risk tolerance stated (RMF Prepare).
M0 → M6
GOV-3
Cloud operating model, roles, and RACINamed owners for platform, security, operations, and mission interfaces.
M0 → M6
GOV-4
Workforce skills baseline and development planSkills inventory, gap assessment, and funded upskilling path (AR-049/050).
M0 → M18
GOV-5
Policy and standards set published as inheritable baselinePolicy delivered as reusable standards that landing-zone and pipeline controls inherit.
M0 → M12
Application and dependency visibilityVisibility is the scoping gate: wave grouping, boundary design, and package scoping all consume the dependency map.
OpenCollapse
ADV-1
Application inventory and ownership modelGateComplete inventory with named mission owners (RMF Categorize input).
M0 → M6
ADV-2
Automated dependency discovery (MAP ADM pattern, 12–16 weeks)GateTool-based dependency and interface map replacing static diagrams.
M0 → M6
ADV-3
Workload classification and data-sensitivity mappingGateImpact-level alignment per workload; drives IL4/IL5/IL6 placement decisions.
M0 → M12
ADV-4
Interface, API, and data-flow inventory with governanceDocumented flows, retention, and lineage supporting boundary and CDS decisions.
M3 → M18
ADV-5
Continuous dependency mapping operationalizedInventory currency maintained automatically; feeds every wave and authorization decision.
M12 → M24
Platform / landing-zone readinessThe landing zone is the primary production gate: no workload leaves sandbox for an authorized mission-cloud environment until the accredited platform boundary, tenancy, identity, and baseline exist to receive it.
OpenCollapse
PLZ-1
Authorized cloud-service and tenancy / account architectureGateDocumented provider and acquisition path with environment and account segmentation model.
M0 → M6
PLZ-2
DODIN connectivity and Cloud Access Point boundaryGateApproved transport path and CAP entry for IL4/IL5 traffic.
M0 → M12
PLZ-3
SCCA stack stand-up or inherited equivalent (BCAP / VDSS / VDMS / TCCM)GateMandated shared security components in place or inherited from an enterprise provider.
M0 → M18
PLZ-4
Identity, credential, and privileged access integration (ICAM)GateEnterprise identity, MFA, and privileged-access model wired into the platform.
M0 → M12
PLZ-5
Landing-zone baseline as code (hardened, drift-monitored)GateIaC-delivered, CIS-hardened baseline; new environments standable in hours.
M3 → M18
PLZ-6
Network segmentation and Zero Trust boundary enforcementMicro-segmentation and policy enforcement aligned to ZT target activities.
M6 → M24
PLZ-7
Multi-IL environment pattern (IL4/IL5 separation, IL6 path)Repeatable pattern for standing up additional impact levels without redesign.
M12 → M36
Security control inheritanceInheritance is the package-scoping gate: what the platform provides determines what each workload package must still prove.
OpenCollapse
SCI-1
Shared-control map (CSP / SCCA / platform / client)GateEvery control assigned to its provider; residual client controls identified.
M0 → M6
SCI-2
Common control provider designation (RMF Task P-5)GateInheritance documented in the authorization package, not assumed informally.
M0 → M12
SCI-3
Data protection, encryption, and key management modelGateKMS ownership, key hierarchy, and encryption posture per impact level.
M3 → M18
SCI-4
Inheritable control catalog delivered as code and validatedPlatform controls consumed by default and continuously validated (ZT tenet).
M12 → M36
RMF / ATO / cATO evidenceAuthorization is a client/AO decision gate: IATT may allow bounded testing, operational use requires the applicable authorization, and cATO is a later continuous-evidence posture rather than a scheduled release event.
OpenCollapse
ATO-1
Authorization inventory and evidence ownership mapGateEvery required evidence item has a named owner and a currency status.
M0 → M6
ATO-2
Package assembly: SSP, control matrix, POA&M, assessment prepGateSubmission-ready package scoped by the inheritance map (SCI-1/2).
M3 → M12
ATO-3
Operational authorization assessment and AO decision windowGateAssessed evidence supports an AO risk decision; operational production use waits for the applicable authorization.
M12 → M18
ATO-4
Continuous monitoring strategy and toolingConMon plan feeding near-real-time control status toward the AO.
M6 → M24
ATO-5
Zero Trust pillar maturity toward approved target levelsPillar-by-pillar progression evidenced against the current DoD and component Zero Trust roadmap.
M6 → M36
ATO-6
cATO evidence automation (ConMon / ACD / SSSC pillars)Authorization sustained by automated, inheritable evidence continuously available to the AO.
M18 → M48
DevSecOps / CI/CD / IaC / CaC toolchainThe toolchain is the evidence-velocity gate: it determines whether score-4 (automated, reusable) evidence is achievable anywhere else.
OpenCollapse
DSO-1
DevSecOps reference-design selection and platform decisionGateApproved DoD Enterprise DevSecOps Reference Design path selected (build vs. inherit).
M0 → M6
DSO-2
CI/CD pipeline with enforced security gatesGateAuthorized software pipeline; no production path around the gates.
M3 → M18
DSO-3
IaC / CaC maturity across platform and workloadsInfrastructure and configuration expressed, reviewed, and deployed as code.
M3 → M18
DSO-4
Software supply-chain integrity (hardened images, SBOM, signing)Provenance-verified artifacts satisfying the cATO SSSC pillar.
M6 → M24
DSO-5
Production onboarding and intake workflowGateDefined, repeatable path from sandbox through pilot to production promotion.
M6 → M18
DSO-6
Evidence-as-by-product automationEvery release emits its own authorization evidence; documentation effort collapses.
M18 → M36
Operations / observability / incident / vulnerability / configuration managementOperations is the sustainment gate: the AO expects credible Day-2 evidence before production, and ConMon consumes its telemetry from day one.
OpenCollapse
OPS-1
Logging, monitoring, backup, and recovery baselineGatePlatform-wide telemetry, retention, restore, and recovery baseline before first workload.
M0 → M6
OPS-2
Day-2 operations model and support tieringGateNamed operational ownership, escalation, and support tiers.
M0 → M12
OPS-3
Vulnerability, configuration, compliance, and cloud-security visibilityGateScan cadence, posture and entitlement coverage, remediation SLAs, and drift detection with coverage evidence.
M3 → M18
OPS-4
Endpoint and device trust (EDR, comply-to-connect)Device posture enforcement aligned to ZT device pillar.
M6 → M24
OPS-5
Service-level objectives and observability maturitySLO-driven operations; alerting tied to mission impact rather than raw noise.
M12 → M24
OPS-6
Automated drift detection feeding AO-visible ConMonNear-real-time control status aggregation — the cATO ConMon pillar operating.
M18 → M36
ITIL service practices and change enablementService practice is the throughput gate: manual change boards become the binding constraint on deployment frequency once pipelines mature.
OpenCollapse
ITL-1
Incident, change, problem, and request proceduresGateDocumented, consistently followed procedures with named process owners.
M0 → M12
ITL-2
Service catalog and request fulfillmentPublished catalog with self-service entry points for common requests.
M6 → M18
ITL-3
Workflow-integrated service managementGateITSM tooling wired to operational telemetry and delivery workflow.
M12 → M24
ITL-4
Pipeline-based change enablementGateStandard changes pre-approved through the pipeline; records emitted automatically.
M18 → M36
FinOps / service catalog / chargeback / showbackFinOps is the sustainability gate: consumption funding, tagging, and accountability determine whether the platform survives its second budget year.
OpenCollapse
FIN-1
Acquisition, ordering, funding, and reversibility postureGateActive path capable of obtaining authorized services at the required impact level, with consumption and transition-out assumptions visible.
M0 → M6
FIN-2
Consumption policy, budget structure, and tagging standardCost allocation possible from the first production workload.
M0 → M12
FIN-3
Showback / chargeback model with mission-owner visibilityOwners see and answer for their consumption.
M6 → M24
FIN-4
Commitment and anomaly managementSpend anomalies detected and dispositioned; commitments managed within appropriations constraints.
M12 → M24
FIN-5
FinOps Operate loop with continuous optimizationInform -> Optimize -> Operate cycle running with documented savings.
M18 → M36
Migration execution and rollback readinessExecution is the cutover gate: no wave moves without readiness criteria, a rollback path, and authorization carried for the migrated system.
OpenCollapse
MIG-1
Candidate workload list and dependency-informed wave groupingGateWaves grouped from current inventory, mission criticality, recovery tiers, and dependency evidence rather than a spreadsheet list alone.
M0 → M6
MIG-2
Per-wave readiness assessment and MAP disposition assignmentGateEvery workload carries Lift / Modernize / Platform / Contain before cutover.
M3 → M12
MIG-3
Production promotion path with rollback readinessGateDocumented, exercised promotion and rollback path, method-agnostic (post-ATO release mechanics).
M6 → M18
MIG-4
Retain / contain register with active containment plansBoundary, latency, and dependency constraints documented with containment posture.
M0 → M18
MIG-5
Migration factory maturity and progressive deliveryRepeatable wave execution; rollback and reversibility are engineering properties, not events.
M18 → M36