By Authorization-Ready by Design: A Landing Zone Roadmap for Federal Program Offices
A landing zone does not authorize anything, but it decides how hard authorization will be. This roadmap covers the requirements that shape a federal cloud foundation, the controls it implements, who owns each RMF step, and the SOW terms that keep the build on schedule.
No landing zone comes with an Authority to Operate. But the cloud foundation a program is built on decides much of how hard that authorization will be. A foundation designed against NIST SP 800-53, with a clear boundary and documented inheritance, gives every program on it a head start. One assembled ad hoc gives every program the same findings.
This roadmap is for the ISSM, ISSO, CISO or program manager who has to plan that foundation and defend it.
The Requirements That Shape the Foundation
| Requirement | What it means for the environment |
|---|---|
| FedRAMP Consolidated Rules (June 25, 2026) | Provider offerings are "FedRAMP Certified" in classes A through D. New Rev5 submissions stop June 11, 2027, and Rev5 authorizations end December 31, 2028. Evidence is moving to continuous, machine-readable formats |
| DoD Cloud Computing SRG | Impact levels IL2, IL4, IL5 and IL6 set requirements for the provider offering, connections and separation |
| Zero trust | OMB M-22-09 for civilian agencies; DoD target-level capabilities due by the end of FY2027. Identity, segmentation and visibility are largely built in the environment layer |
| TIC 3.0 | Boundary and telemetry design follows CISA's cloud use cases |
| FIPS 199 and 200 | Categorization sets the minimum control baseline the environment must support |
FedRAMP certification covers the cloud provider's offering, never the agency's workload. A program on a certified offering still needs its own authorization, and the landing zone is where the agency's side of the shared responsibility line gets built.
The Controls the Environment Implements
| Control family | What the program office should be able to show |
|---|---|
| AC | Access enforcement through role design and guardrails |
| AU-2, AU-6, AU-12 | Central, tamper-resistant logging and review support |
| CM-2, CM-6, CM-7 | Baselines, hardened settings and least functionality |
| CP-9, CP-10 | Backup and recovery architecture |
| IA-2, IA-5 | Federation to enterprise ICAM; authenticator management |
| SC-7, SC-8, SC-12, SC-13, SC-28 | Boundary protection, encryption, key management |
| SI-4 | Monitoring plumbing for security operations |
Each guardrail should map to the control it implements, and each control should have a written implementation statement. That is the difference between an environment and an authorizable one.
Inherited, Shared or Agency-Implemented
Every control in a cloud system falls into one of three buckets: inherited from the provider's certified offering, shared between provider and agency, or implemented by the agency. The landing zone documentation should state which is which for every environment-layer control, so each program that lands on it inherits the agency's implementations too.
Getting this right once saves every later program from rediscovering it. The format matters as well: implementation statements an assessor can verify (opens in a new tab) move faster through assessment than narrative descriptions.
Who Owns Each RMF Step
| RMF step (SP 800-37 Rev. 2) | Landing zone role | Owner |
|---|---|---|
| Prepare | Architecture inputs, boundary definition | Agency, supported |
| Categorize | Impact-level and baseline mapping inputs | System owner |
| Select | Tailoring and inheritance documentation | System owner and ISSM |
| Implement | Builds and documents environment-layer controls | Builder |
| Assess | Provides evidence | Assessor independent of the builder |
| Authorize | None | Authorizing Official |
| Monitor | Monitoring architecture | Agency continuous monitoring program |
Two lines in that table deserve emphasis. The assessor must be independent of whoever built the environment, so a contractor that builds a landing zone should not assess it. And the authorization decision belongs to the AO alone.
Language That Holds Up
The same rule applies in proposals, statements of work and status reports: describe what was engineered, not the decision that belongs to someone else.
| Accurate | Not accurate |
|---|---|
| Designed and implemented to the NIST SP 800-53 Rev. 5 moderate baseline, with evidence for the agency's assessment | An 800-53-compliant environment |
| Deployed on FedRAMP Certified services, with documented inheritance | A FedRAMP Certified environment |
| Engineered to Cloud Computing SRG IL4 requirements | IL4 authorized |
| An authorization-ready environment | ATO guaranteed |
Questions to Answer Before the Build
A program office can save weeks of design time by settling these before a contractor starts:
- What impact levels does the data require? IL2, IL4 and IL5 produce different environments, and mixing them in one design multiplies the work.
- Who owns cloud identity? If accounts are not federated to enterprise ICAM, that decision must be made first.
- Where is the boundary today? If the ISSM cannot draw the current authorization boundary, discovery needs to start there.
- How many programs are coming? A landing zone pays off when several programs will use it. With only a few, a design-only blueprint applied program by program is often the better buy.
- Who will operate it? A landing zone is a living platform. Someone in the agency, or a sustainment contract, has to own it after the build.
- What connectivity is needed, and who approves it? Circuits and connection approvals are usually the longest lead-time items, and they sit with the agency.
CUI and Contractor Environments
Some agencies share environments with contractors who handle Controlled Unclassified Information. In those cases the landing zone design may include CUI enclave patterns aligned to NIST SP 800-171. The contractor's own obligations remain separate: DoD suspended CMMC Phase 2 third-party certification on July 13, 2026 (opens in a new tab) pending a review, but the underlying 800-171 requirements and self-assessments continue. An agency enclave design does not certify any contractor, and the documentation should say so.
What the AO Sees
The payoff of an authorization-ready foundation shows up in the package the Authorizing Official reviews. Instead of each program describing its own network, logging and identity from scratch, the package references the landing zone's documented implementations and inheritance, and the program describes only what it adds. The boundary is drawn once, the evidence is consistent across programs, and residual risk at the environment layer is stated once and accepted once.
SOW Terms That Hold the Schedule
Most landing zone delays come from dependencies the agency owns. The statement of work should name them:
- Environments and impact levels in scope, enumerated with a count cap. Additional environments go through a change order.
- A decision sponsor with a five-business-day turnaround on escalated items, and schedule relief for items undecided after ten.
- ISSM design reviews on a fixed cadence, treated as mandatory.
- Network and identity dependencies with needed-by dates, especially circuits and connection approvals.
- Accounts and consumption funding provided by the agency and never inside the engagement price.
- Explicit exclusions: application migration, the full SSP package, assessment, and post-build operations.
- Milestone-based fixed price, with acceptance tied to enumerated deliverables, never to an authorization outcome.
Sequencing the Work
A practical order for a program office: confirm the categorization and impact levels; commission a design-only blueprint that includes inheritance mapping; decide, based on how many programs are coming, whether a full landing zone is worth funding; then build, validate and document it, with the first workload enclave proving the pattern. Programs that follow land in a vended environment that already carries its share of the evidence, and each one adds only its own application-layer controls to the package.
Where agencies are buying under budget pressure, the case often sits alongside cost control: duplicated environments are part of the hidden tax on a federal cloud budget (opens in a new tab), and a single foundation removes the duplication at its source.
Avalon's Cloud Architecture & Engineering service designs and builds landing zones to the NIST SP 800-53 baseline, documents inheritance and control implementation for your assessment, and keeps the builder and assessor roles separate.
