Federal civilian · Managed platform (AWS or Azure)

FedRAMP High Managed Landing Zone

A cloud foundation configured against the FedRAMP High baseline, run by Moraph so your teams can build on it

Book a demonstration Request a technical briefing Factsheet

Overview

What you are buying

Moraph sets up and operates a landing zone in AWS GovCloud (US) or Azure Government: the account structure, network boundary, identity, logging and guardrails that every application in the cloud depends on, configured against the NIST SP 800-53 High baseline. Moraph maintains the boundary and patches the shared components, and documents which controls the landing zone provides so application teams know what is left for them. Your agency's authorizing official decides what operates; Moraph supports that decision with control mappings and evidence.

The problem it solves

Agencies moving to the cloud find that each application team ends up building its own network, logging and identity setup, each with its own security documentation. The result is inconsistent configurations, duplicated effort in every authorization package, and a boundary nobody fully owns. Security staff struggle to see across accounts, and application teams wait months for a compliant place to deploy.

Each application team builds its own cloud foundation, differently
Authorization packages repeat the same control descriptions for shared infrastructure
Logging, boundary protection and identity are set up inconsistently across accounts
Patching and drift on shared components fall between teams

Who uses it

Agency CIO and cloud program offices
Application and product teams that deploy to the cloud
Information system security officers and authorizing officials
Security operations centers that need visibility across cloud accounts
Inspectors general and auditors reviewing cloud controls

Requirements it supports

Federal Information Security Modernization Act of 2014 (44 U.S.C. 3551 et seq.)FedRAMP Authorization Act (44 U.S.C. 3607 to 3616)NIST SP 800-53 Rev. 5, High control baseline (SP 800-53B)NIST SP 800-37 Rev. 2, Risk Management FrameworkOMB Memorandum M-21-31, Improving the Federal Government's Investigative and Remediation CapabilitiesOMB Memorandum M-19-26 and CISA Trusted Internet Connections (TIC) 3.0

The product supports these requirements; meeting them remains your organization’s responsibility.

Responsibilities

Who is responsible for what

Moraph builds and runs the landing zone; AWS or Microsoft runs the underlying cloud under their own terms and authorizations; your agency owns its applications, data and risk decisions.

Area	Moraph	AWS or Microsoft	Your organization
Licensing and billing	Resells cloud services where contracted, or works within your existing agreement	Provide cloud services under their own terms and pricing	Holds the agreement or approves the reseller arrangement
Platform availability	Operates the landing zone's shared components	Keep the underlying cloud regions and services available under their own commitments	Operates its applications within the landing zone
Configuration	Builds and maintains the baseline, guardrails and network hub	Provide and maintain the native services the landing zone uses	Approves the baseline through the ISSO
Identity and access	Federates identity, configures roles and manages privileged access	Secure their own infrastructure and administrative access	Runs the identity provider and approves access
Monitoring	Monitors shared components and forwards logs and events	Monitor their own infrastructure	Your SOC monitors and investigates security events
Incident response	Contains and recovers shared components and reports to your SOC	Respond to incidents in their infrastructure and notify customers	Declares incidents and handles reporting under agency procedures
Changes	Raises, tests and applies approved changes	Announce and make changes to their services	Approves changes and exceptions through the ISSO
Patches and updates	Patches the landing zone's own components on the agreed schedule	Patch the underlying cloud infrastructure and managed services	Application teams patch their own workloads unless contracted separately
Policy and risk decisions	Recommends and implements	None	Decides data categorization, policies and exceptions; the authorizing official accepts risk
Authorization	Maps controls and supplies evidence for your package	Maintain their own FedRAMP authorizations for in-scope services	Your authorizing official grants each authority to operate

See how it works

A short walkthrough

Illustrative screens of how Moraph runs the service, with fictional sample data. They are not screens of AWS/Azure itself, which belongs to its vendor.

Step 1

Onboarding tracker

During implementation, each workstream and decision is tracked with an owner at Moraph and at your agency.

Workstream	Moraph owner	Your owner	Status
Cloud organization and billing	Cloud architect	Cloud program lead	Complete
Network hub and TIC alignment	Network engineer	Network branch	In review
Identity federation and PIV sign-in	Cloud engineer	Identity team	In progress
Central logging and SOC forwarding	Cloud engineer	SOC lead	Waiting on SIEM endpoint
Control implementation statements	Compliance lead	ISSO	In progress
First application onboarding	Service manager	Example Benefits App team (fictional)	Not started

Step 2
Configuration baseline review
The running configuration is checked against the approved baseline, and drift is reported to your ISSO with how it will be resolved.
FedRAMP High Managed Landing Zone · Baseline checkSample data
Baseline check · Example Agency landing zone (fictional)
Baseline version
Fictional v22
Accounts checked
37
Guardrails in force
All
Drift found
2 items
Next check
Continuous
Drift items
- Account APP-014: flow logs disabled on one subnet
- Shared services: bastion host image one version behind approved
Raise change to correctRecord as accepted exception
The running configuration is checked against the approved baseline, and drift is reported to your ISSO with how it will be resolved.
Step 3
A change request
Changes to the landing zone are raised, assessed for security impact and approved by your ISSO before they are applied.
FedRAMP High Managed Landing Zone · Change CR-1207Sample data
CR-1207 · New egress rule for application APP-021
1. Request raised by application teamApplication team
2. Security impact assessed and rule scopedMoraph cloud engineer
3. Change approvedISSO
4. Rule applied as code and verifiedMoraph cloud engineer
5. Baseline and control statements updatedMoraph service manager
Changes to the landing zone are raised, assessed for security impact and approved by your ISSO before they are applied.

Step 4

Alert triage

Moraph triages alerts on shared components and passes security events to your SOC with the context they need.

Alert	Account	Description	Severity	Owner	Status
LZ-4471	APP-014	Flow logs disabled on subnet	High	Moraph engineer	Corrected; SOC informed
LZ-4468	Shared services	Bastion host patch due	Medium	Moraph engineer	Change scheduled
LZ-4462	APP-009	Guardrail blocked public storage bucket	Medium	Application team	Team notified
LZ-4459	Network hub	Inspection appliance failover	Medium	Moraph engineer	Resolved

Step 5
Monthly service review
Each month Moraph reports on the service, findings and requests, and agrees actions with your program lead and ISSO.
FedRAMP High Managed Landing Zone · Service reviewSample data
Monthly service review · Fictional sample month
Incidents
1 (closed)
Changes applied
14 of 14 approved
New environments provisioned
4
Open findings assigned to Moraph
3
Exceptions expiring
2 this month
Actions agreed
- ISSO to decide on renewal of two guardrail exceptions
- Moraph to close remaining patch findings
- Program lead to confirm onboarding order for next applications
Download reportAdd action
Each month Moraph reports on the service, findings and requests, and agrees actions with your program lead and ISSO.

Step 6

Privileged access review

Your ISSO recertifies who holds privileged access to the landing zone, and access that is no longer needed is removed.

User	Role	Approved by	Last used	Decision
Moraph engineer 0213 (fictional)	Network administrator	ISSO	This week	Keep
Moraph engineer 0198 (fictional)	Identity administrator	ISSO	Not used in review period	Remove
Agency staff 1044 (fictional)	Security auditor	ISSO	This month	Keep
Agency staff 1102 (fictional)	Break-glass administrator	ISSO	Never	Keep; sealed

Workflows

The principal workflows

Establish
Moraph builds the landing zone in your agency's AWS GovCloud (US) or Azure Government organization: account or subscription structure, network hub, identity, logging and guardrails, to a baseline your ISSO approves.
- Agency cloud organization and billing confirmed with the cloud provider
- Account or subscription structure and network design agreed
- Identity federated with your agency's identity provider, including PIV sign-in
- Central logging, guardrails and encryption keys configured
- Baseline documented and approved by your ISSO
Onboard an application
When an application team needs a place to deploy, Moraph provisions an account or subscription inside the landing zone with the guardrails, network connections and logging already in place.
- Application team requests an environment with its data categorization
- Request approved by the cloud program office and ISSO
- Account or subscription created with guardrails and logging applied
- Network connectivity to the hub and agency network configured
- Team receives the list of controls the landing zone provides and those left to them
Operate
Moraph monitors the shared components, maintains the boundary, patches what it manages and checks the configuration for drift, reporting each month.
- Boundary, identity and logging components monitored
- Security events forwarded to your agency's security operations
- Patches to managed components applied on the agreed schedule
- Drift from the approved baseline detected and corrected through change requests
- Monthly service review covers incidents, changes, findings and capacity
Support authorization
The landing zone's control implementations are documented once, so application packages can reference them rather than repeat them. Evidence is kept current for continuous monitoring.
- Control implementation statements maintained for the landing zone
- Customer responsibility matrix issued to each application team
- Evidence collected for assessments and continuous monitoring
- Findings tracked in the plan of action and milestones with owners
- Changes assessed for security impact before they are applied

Roles and permissions

Who does what in the product

Each role below is a starting point. During implementation we set them up to match your teams, and every action anyone takes is recorded in the audit trail.

Cloud program lead

Cloud program manager, enterprise architect, deputy CIO for infrastructure

Owns the landing zone on the agency's behalf and decides which teams and applications use it.

Sees

All accounts or subscriptions, their owners and their purpose
Cost and capacity by program and application
Open requests, changes and service performance
Monthly service reports

Does

Approves new environments for application teams
Sets tagging and cost allocation standards
Agrees priorities and roadmap for the landing zone with Moraph
Reviews the monthly service report and agrees actions
Manages the agency's relationship with the cloud provider alongside Moraph

Cannot

Change the security baseline without ISSO approval
Bypass guardrails for an application
Edit or delete audit logs

Approvals: Approves new environments and program-level decisions; security changes need the ISSO.
Notified about: New environment requests, cost thresholds, major incidents and changes awaiting decision.

Application team

Application owner, DevSecOps engineer, product team lead

Builds and runs an application inside the landing zone, relying on the controls it provides.

Sees

Their own accounts or subscriptions and resources
The guardrails that apply to them and why
Their customer responsibility matrix
Their own cost and logs

Does

Requests environments for development, test and production
Deploys and operates their application within the guardrails
Requests network connections, exceptions or changes through Moraph
Implements and documents the controls left to them
Patches and maintains their own workloads unless contracted separately

Cannot

Disable logging, guardrails or boundary controls
Create connections outside the approved network paths
See other teams' accounts

Approvals: Exceptions to guardrails and new network paths need ISSO approval.
Notified about: Environment ready, guardrail violations in their accounts, and decisions on their requests.

ISSO

Information system security officer, ISSM, cloud security lead

Answers for the landing zone's security and controls what changes are made to it.

Sees

The approved baseline and any drift
Change requests, exceptions and patch status
Control implementation statements and evidence
Plan of action and milestones items and their owners

Does

Approves the baseline and changes to it
Approves or rejects exceptions to guardrails
Reviews security impact of changes before they are applied
Maintains the authorization package and continuous monitoring with Moraph's evidence
Runs periodic access reviews of privileged accounts

Cannot

Approve a change they raised without a second approver
Edit or delete audit logs
Grant an exception that the authorizing official has reserved to themselves

Approvals: Approves changes, exceptions and patch schedules; risk acceptance rests with the authorizing official.
Notified about: Changes and exceptions awaiting approval, drift, new findings and access reviews coming due.

SOC analyst

Security operations analyst, incident responder

Watches for and investigates security events across the landing zone using the logs Moraph forwards.

Sees

Security events and logs from every account
Guardrail violations and configuration alerts
Incident records shared with Moraph

Does

Investigates security events and declares incidents
Requests containment actions from Moraph or application teams
Records findings and lessons learned
Reports incidents under agency procedures

Cannot

Change the landing zone configuration directly
Delete or alter logs
Access application data beyond what an investigation authorizes

Approvals: Containment actions that change the landing zone are carried out by Moraph and recorded; incident reporting follows agency procedures.
Notified about: High-severity events, guardrail violations and incident updates from Moraph.

Moraph cloud engineer

Moraph cloud and network engineers (US citizens with the clearances the contract requires)

Builds, operates, patches and maintains the landing zone's shared components.

Sees

Landing zone configuration, health and drift
Platform logs and alerts for shared components
Approved changes and maintenance windows
Environment requests

Does

Builds environments for application teams from the standard pattern
Monitors shared components and triages alerts
Applies approved changes and patches in agreed windows
Corrects drift through change requests
Takes containment actions requested by your SOC and records them

Cannot

Access application data in agency workloads
Use agency encryption keys without explicit, time-bound authorization
Make an unapproved change, except emergency actions recorded and reviewed under the incident process

Approvals: Planned changes need ISSO approval; emergency actions are reported to the ISSO and reviewed afterwards.
Notified about: Alerts, drift, approved changes scheduled, new environment requests and SOC containment requests.

Moraph service manager

Moraph service delivery manager

Is accountable for the service and runs the monthly service review.

Sees

Service performance, incidents and open requests
Change and patch calendars
Cost and capacity trends

Does

Runs the monthly service review and agrees actions
Coordinates requests between application teams, the ISSO and Moraph engineers
Tracks findings assigned to Moraph through to closure
Manages escalations to the cloud provider

Cannot

Approve changes or exceptions on the agency's behalf
Access application data
Change the baseline

Approvals: Nothing they do changes the landing zone without ISSO approval.
Notified about: Major incidents, escalations, overdue findings and requests waiting on decisions.

Auditor (read-only)

Inspector general staff, security control assessor, internal auditor

Reviews the landing zone's configuration, access and changes without being able to change anything.

Sees

The baseline, drift results and change history
Privileged access and access review results
Control implementation statements and evidence
Logs within the scope granted

Does

Reads and searches records within their scope
Exports records and evidence, with each export logged
Records review notes where enabled

Cannot

Change, approve or delete anything
See application data unless separately granted
Keep access after it expires

Approvals: Their access is approved by the ISSO with a scope and an end date.
Notified about: Nothing by default; access granted and expiring is confirmed to the ISSO.

Permissions at a glance

Action	Program lead	App team	ISSO	SOC analyst	Moraph eng.	Service mgr	Auditor
Request a new environment	Full	Own work only	View only	No access	View only	View only	No access
Approve a new environment	Approves	No access	Approves	No access	No access	No access	View only
Provision accounts or subscriptions	View only	No access	View only	No access	Full	View only	View only
Deploy application workloads	No access	Own work only	No access	No access	No access	No access	No access
Change baseline or guardrails	View only	No access	Approves	No access	Own work only	View only	View only
Grant a guardrail exception	View only	No access	Approves	No access	No access	No access	View only
Apply patches to shared components	No access	No access	Approves	No access	Full	View only	View only
Investigate security events	No access	Own work only	View only	Full	View only	No access	No access
View central logs	No access	Own work only	View only	Full	View only	No access	View only
Manage privileged access	No access	No access	Approves	No access	Own work only	No access	View only
View cost reports	Full	Own work only	View only	No access	View only	Full	View only
Maintain control evidence	View only	Own work only	Full	No access	Own work only	View only	View only

Full
Own work only
Approves
View only
No access

How access is controlled

Nobody approves their own change: changes raised by Moraph or agency staff are approved by the ISSO, and changes the ISSO raises need a second approver. Risk acceptance stays with your authorizing official.
Application teams own their workloads; Moraph owns the shared components. The customer responsibility matrix issued to each team sets out exactly where the line falls.
Roles follow groups in your agency's identity provider, and privileged access to the landing zone is time-bound and recorded.
Moraph work on federal tickets is done only by US citizens holding the clearances the contract requires, and the landing zone is hosted only in US regions.

Features

What it does

Account and subscription structure

A multi-account or multi-subscription layout that separates shared services, security tooling and each application's environments.

Boundary protection

A network hub with controlled ingress and egress, inspection, and connections to the agency network aligned with your TIC 3.0 approach.

Federated identity

Sign-in through your agency's identity provider, including PIV, with privileged access separated and recorded.

Guardrails

Preventive policies, applied through AWS Organizations or Azure Policy, that stop accounts from disabling logging, using unapproved regions or creating public exposure without approval.

Central logging

Logs from every account collected centrally and retained to support OMB M-21-31, and forwarded to your security operations.

Encryption and key management

Encryption at rest and in transit using the cloud provider's key management services, with keys controlled by your agency.

Environment provisioning

New accounts or subscriptions for application teams created from a standard pattern, with guardrails, logging and networking already applied.

Patching of shared components

Moraph patches the landing zone's own components, such as network appliances, bastion hosts and shared tooling, on the schedule your ISSO agrees.

Drift detection

The approved configuration is checked continuously, and differences are reported and corrected through change requests.

Control inheritance documentation

Control implementation statements and a customer responsibility matrix, so application teams know which controls the landing zone provides and which remain theirs.

Cost and tagging

Tagging standards and cost reports by account, application and program, so spending can be attributed.

Backup and recovery

Backup policies for shared components and an agreed recovery approach, tested with your staff.

Integrations

How it connects to your systems

Connects to	How	What flows
AWS GovCloud (US) or Azure Government	The landing zone is built in your agency's organization or tenant on the cloud provider, using its native account, network, policy and key management services.	In and out: configuration, policy and resource state through the provider's APIs.
Agency identity provider	Users sign in through your identity provider with PIV or other approved authenticators, and roles follow its groups.	In: user identity, authentication context and group membership.
Agency network and TIC	Connections between the landing zone and your agency network follow your TIC 3.0 architecture.	In and out: network traffic through approved paths only.
Security operations and SIEM	Logs and security events from every account forwarded to your agency's security operations tooling.	Out: cloud audit logs, network flow logs and guardrail events.
Continuous Diagnostics and Mitigation	Asset and configuration data made available to your agency's CDM tooling where your agency requires it.	Out: asset inventory and configuration state.
Governance, risk and compliance tooling	Control implementation statements and evidence shared with your GRC tool or Moraph's FedRAMP ATO Accelerator.	Out: control statements, evidence and findings.
Moraph Work API	Environment requests, changes, findings and service reports available to your service management tools.	Out: requests, changes, findings and service metrics.

Each integration is confirmed in discovery and specified in the design. See how an engagement progresses.

Security and privacy

How your data is protected

Single sign-on

Users sign in through your agency's identity provider, so your authentication policies, including PIV, apply.

Role-based and privileged access

Access follows each person's role; privileged access to shared components is time-bound, approved and recorded.

Encryption and keys

Data is encrypted at rest and in transit, with keys controlled by your agency that Moraph staff cannot use without explicit, time-bound authorization.

Complete audit trail

Every configuration change, privileged session and approval is logged with the person and time, and the logs cannot be edited.

US-only hosting and cleared staff

The landing zone runs only in US government cloud regions, and Moraph's federal work is handled by US citizens with active clearances.

Tested releases

Security testing gates every change to Moraph's templates and automation, and a software bill of materials is kept for the components Moraph supplies.

Company-wide controls, independent audits (SOC 2 Type II and ISO/IEC 27001) and data residency are described in our Trust Center, where you can request the evidence pack.

Reporting

What you can report on

11 standard reports, grouped by who uses them. Each shows who it is for, how it can be broken down, how it is delivered and what it is used for. The data behind them is also available to your own reporting tools.

Service

Monthly service review

For cloud program lead and ISSO

Incidents, changes, environment requests, patching status, findings and actions agreed at the last review.

Break down by: Month, Component, Incident severity, Action owner
Delivered as: PDF; review meeting
Used for: Holding Moraph to account and agreeing priorities.

Environment requests

For cloud program lead and application teams

Requests for new accounts or subscriptions, their approvals and their status.

Break down by: Application, Environment type, Status, Age
Delivered as: Live dashboard
Used for: Making sure application teams are not left waiting on approvals or builds.

Change and patch record

For iSSO and auditors

Every change and patch to shared components, with who raised, approved and applied it and the outcome.

Break down by: Change type, Approver, Component, Outcome
Delivered as: Live view; CSV export
Used for: Evidencing that the landing zone changes only through approved requests.

Security and compliance

Baseline drift

For iSSO and Moraph engineers

Differences between the approved baseline and the running configuration, by account and control, and how each was resolved.

Break down by: Account or subscription, Control family, Drift status, Age
Delivered as: Live dashboard; PDF export
Used for: Continuous monitoring and keeping the baseline intact.

Guardrail violations and exceptions

For iSSO and application teams

Actions blocked or flagged by guardrails, and exceptions granted with their approver and expiry.

Break down by: Account, Guardrail, Application team, Exception status
Delivered as: Live view; CSV export
Used for: Finding teams that need help and making sure exceptions do not outlive their reason.

Control inheritance

For iSSO, application teams and assessors

Each control in the High baseline and whether it is provided by the cloud provider, the landing zone, the application team or shared.

Break down by: Control family, Responsible party, Application
Delivered as: PDF and CSV export
Used for: Writing application authorization packages without repeating shared control descriptions.

Plan of action and milestones

For iSSO and authorizing official's staff

Open findings for the landing zone with owner, planned remediation and status.

Break down by: Severity, Owner, Control family, Status
Delivered as: Live view; CSV export in your agency's format
Used for: Tracking remediation for continuous monitoring and authorization decisions.

Privileged access review

For iSSO

Who holds privileged access to shared components, when it was approved and when it was last used.

Break down by: User, Role, Approver, Last use
Delivered as: Live view; PDF and CSV export
Used for: Periodic recertification and removing access that is no longer needed.

Audit trail extract

For iSSO, inspectors general and auditors

Configuration changes, privileged sessions and approvals for a selected account, user or period.

Break down by: Account, User, Action, Date range
Delivered as: On request; CSV and PDF export
Used for: Answering audit and investigation requests without assembling logs by hand.

Cost and capacity

Cost by program and application

For cloud program lead and finance

Cloud spending by account, application and program, using the agreed tags.

Break down by: Program, Application, Service, Month
Delivered as: Live dashboard; CSV export
Used for: Attributing cloud costs and spotting unexpected growth.

Tagging compliance

For cloud program lead and application teams

Resources missing required tags, by account and team.

Break down by: Account, Missing tag, Application team
Delivered as: Live view; scheduled email
Used for: Keeping cost and ownership data accurate.

Exports, access and evidence

Reports can be exported to CSV and summary reports to PDF, and scheduled to the people entitled to see them.
Reports respect each viewer's role: application teams see their own accounts, the ISSO and program lead see the whole landing zone.
Requests, changes, findings and service metrics are available through the Moraph Work API, and control evidence can be shared with your GRC tooling.
Compliance and audit reports can be run as of a past date and give the same result each time; running and exporting a report is itself logged.
Cost reports use the cloud provider's billing data and the agency's tags; Moraph does not change the provider's billing.

Deployment

Where and how it runs

AWS GovCloud (US)

Built in your agency's AWS GovCloud (US) organization, using AWS Organizations, Control Tower or equivalent native services.

Azure Government

Built in your agency's Azure Government tenant, using management groups, Azure Policy and equivalent native services.

Both providers

Landing zones in both clouds with a common set of guardrails, logging and reporting, scoped in the proposal.

Security controls, independent audits and data residency are set out in our Trust Center. Engagement models and what drives a quotation are on Working with Moraph.

Implementation

What a rollout involves

The general phases are on Working with Moraph. For this product, they involve the following.

Discovery

We review your cloud agreements, network and identity architecture, existing accounts and the applications waiting to move. We need contacts from your network, identity and security teams.

Design

Account structure, network hub, TIC alignment, identity, logging and guardrails are designed and agreed with your architects and ISSO.

Build

The landing zone is built as code in your cloud organization, so its configuration is repeatable and every change is reviewable.

Control documentation

Control implementation statements and the customer responsibility matrix are written for the landing zone and reviewed with your ISSO.

First applications

One or more application teams are onboarded first, and the provisioning process is adjusted from what they find.

Assessment support and operations

We support your assessment with evidence, then move to steady-state operations with drift monitoring, patching and monthly service reviews.

Limitations

What it does not do

Worth knowing before you evaluate it.

Moraph is not the cloud provider. AWS and Microsoft's own service commitments, roadmaps and outages apply, and cloud services and licences are subject to their terms.
Moraph does not hold a FedRAMP authorization for the landing zone. The underlying cloud services carry the provider's own authorizations; your authorizing official decides whether systems built on the landing zone operate, and Moraph supports that with control mappings and evidence.
The name refers to the FedRAMP High baseline the landing zone is configured against. How many controls an application inherits depends on the application and is set out in its customer responsibility matrix.
Application teams remain responsible for their own workloads, code, data and the controls the matrix assigns to them, including patching their workloads unless contracted separately.
The landing zone does not replace your security operations center; it forwards logs and events for your SOC to monitor and investigate.
It is built only in US government cloud regions and is not intended for workloads that require a classified environment.
Bringing existing accounts that were built differently into the landing zone may require rework, assessed account by account during discovery.
Cost reporting depends on the provider's billing data and on application teams applying the agreed tags.

Evaluation checklist

What to test in a demonstration or pilot

Questions worth putting to us, and to any other vendor you are considering.

Ask for a sample customer responsibility matrix and check it against one of your applications
Walk through onboarding an application from request to a ready environment
Review how drift is detected, reported and corrected, and who approves the correction
Confirm how logs reach your SOC and what is retained
Check the responsibilities table against your agency's operating model and your cloud agreement
Ask your ISSO to review sample control implementation statements

Questions

Frequently asked questions

Is the landing zone FedRAMP authorized?

No, and Moraph does not claim it is. The underlying AWS GovCloud (US) and Azure Government services hold their own FedRAMP authorizations. The landing zone is configured against the High baseline, and Moraph supplies control mappings and evidence for your agency's own authorization decisions.

How much does an application inherit?

It depends on the application. Each team receives a customer responsibility matrix showing which controls the cloud provider and the landing zone provide and which remain theirs.

Can we use our existing cloud agreement?

Yes. Moraph can work within your agency's existing agreement with AWS or Microsoft, or resell cloud services where your contract allows.

Who patches our applications?

Moraph patches the landing zone's shared components. Application teams patch their own workloads, unless that is added to Moraph's scope separately.

How is it priced?

As a managed service, usually driven by the number of accounts or subscriptions and the scope of operations, with design and build charged separately and cloud consumption billed under your agreement. See Working with Moraph for what drives a quotation.

Is there an accessibility conformance report?

Ask for one through the procurement request form at /how-to-buy/request, naming the components you are evaluating.

Next steps

Buying through a formal procurement? See How to buy for purchasing routes, accessibility conformance reports and company information. Documentation: FedRAMP High Managed Landing Zone guides on docs.moraph.com (getting started and security guides are public; setup, administration and integration guides are for client accounts). Support: FedRAMP High Managed Landing Zone support guide.

FedRAMP High Managed Landing Zone

What you are buying

The problem it solves

Who uses it

Requirements it supports

Who is responsible for what

A short walkthrough

Onboarding tracker

Configuration baseline review

A change request

Alert triage

Monthly service review

Privileged access review

The principal workflows

Establish

Onboard an application

Operate

Support authorization

Who does what in the product

Cloud program lead

Sees

Does

Cannot

Application team

Sees

Does

Cannot

ISSO

Sees

Does

Cannot

SOC analyst

Sees

Does

Cannot

Moraph cloud engineer

Sees

Does

Cannot

Moraph service manager

Sees

Does

Cannot

Auditor (read-only)

Sees

Does

Cannot

Permissions at a glance

How access is controlled

What it does

Account and subscription structure

Boundary protection

Federated identity

Guardrails

Central logging

Encryption and key management

Environment provisioning

Patching of shared components

Drift detection

Control inheritance documentation

Cost and tagging

Backup and recovery

How it connects to your systems

How your data is protected

Single sign-on

Role-based and privileged access

Encryption and keys

Complete audit trail

US-only hosting and cleared staff

Tested releases

What you can report on

Service

Monthly service review

Environment requests

Change and patch record

Security and compliance

Baseline drift

Guardrail violations and exceptions

Control inheritance

Plan of action and milestones