FedRAMP Architecture for US Government Cloud: Planning Compliance with Sparx EA

FedRAMP turns a cloud service's entire architecture into evidence. Every component in scope, every NIST SP 800-53 control, and every data flow has to be documented, defended, and kept current for the life of the authorization. Sparx EA gives cloud service providers and Federal agency teams one governed place to model FedRAMP system boundaries, control implementations, and System Security Plan (SSP) diagrams, backed by an MDG Technology that tracks each control from requirement to implementation. This piece walks through how to build that architecture and configure the MDG for control governance.

FedRAMP (the Federal Risk and Authorization Management Program) is the US government's framework for assessing and authorizing cloud services for Federal use. For cloud service providers (CSPs) pursuing authorization, the SSP is the core architectural and compliance document, and it is a heavy lift: detailed architecture diagrams, control-by-control implementation narratives, and a governed process for maintaining compliance over time. For agencies consuming an authorized service, understanding the system boundary and the control-inheritance model is itself a governance requirement. Either way, the modeling has to be rigorous and it has to stay current.

What FedRAMP is, and why it is an architecture problem

FedRAMP is the government's standardized approach to cloud security assessment, authorization, and continuous monitoring. OMB established it in 2011 to end the waste of every agency separately assessing the same cloud services. Under FedRAMP, a service goes through one rigorous assessment that multiple agencies can then reuse: the "do once, use many times" model.

Authorization comes in three levels, set by the potential impact of a breach:

FedRAMP Low covers systems where a breach would have limited impact: no personal information, no critical mission data. The control baseline is a subset of NIST SP 800-53. Few operational Federal use cases qualify; Low is mostly for public-facing informational systems.

FedRAMP Moderate is the common case. It applies to systems handling Controlled Unclassified Information (CUI), where a breach would be serious but not catastrophic, and requires roughly 325 NIST SP 800-53 controls. Most cloud services agencies use operationally need Moderate.

FedRAMP High covers data where a breach could be severe or catastrophic, such as law enforcement, financial, or Federal health records. It requires roughly 421 controls and the strictest personnel screening, physical access, and incident response requirements.

The System Security Plan (SSP) is the primary deliverable, typically hundreds of pages describing the system, its boundary, its data flows, and the implementation of every control in the applicable baseline. Crucially, the SSP must carry specific architecture diagrams: a boundary diagram, network topology, data flow, and authentication architecture. That diagramming requirement is exactly where a modeling repository earns its place, because the alternative is keeping a pile of static drawings in sync with reality by hand.

FedRAMP doesn't just ask whether a control exists. It asks where it lives in the architecture, what it protects, and whether the diagram still matches the system. That is a model, not a document.

Building the FedRAMP architecture in Sparx EA

The work breaks into four moves: draw the boundary, model the controls, link controls to the components that implement them, and generate the SSP diagrams from that one model. Each step feeds the next.

The MDG design: a FedRAMP control stereotype set

A FedRAMP MDG Technology extension turns the conventions above into enforced model rules. It provides:

1. «FedRAMP Control», extends Requirement, carries the NIST control identity and implementation-type values and relates to the status records held in the eGRC system.
2. «FedRAMP Boundary», extends Package or Boundary element, marks the ATO scope.
3. «FedRAMP System Component», extends Application Component, records component type (Web Tier / API / Data Tier / Admin) and cloud service type.
4. «FedRAMP Infrastructure»: extends Technology Node, records cloud provider, service category (Compute / Storage / Network / Security), and cloud-native service name.
5. «Inherited Control», extends Association, documents the inheritance relationship and the source authorization.
6. «POA&M Item», extends Risk element, represents a Plan of Action and Milestones item for an unsatisfied control, related to the control it addresses and the components involved. Its scheduled completion date, remediation description, and responsible party are read from the eGRC and project systems that track it.

Validation rules then check completeness: every in-scope Application Component carries a «FedRAMP System Component» stereotype; every Network element has protocol and encryption values; every control whose record says Implemented also carries an Implementation Date; every POA&M Item has a scheduled completion date. When a check fails, the finding says whether the gap is in the model or in the source record, and the owner of that record corrects it. These are the gaps assessors find, caught before the assessment instead.

Continuous monitoring as part of the model

Authorization is not the finish line. FedRAMP requires continuous monitoring (ConMon): ongoing automated assessment, vulnerability management, and POA&M tracking after the ATO is issued. That program is documented in the same repository.

Vulnerability scanning is modeled as Application Components (the scanner) with scanning relationships to in-scope Technology Nodes, with scan-frequency tagged values on each relationship. SIEM and log aggregation is the centralized log platform modeled as an Application Component collecting from every in-scope component. POA&M tracking stays in the eGRC and vulnerability systems that run it. AI connects to them, and the model relates each open vulnerability and control deficiency, with its completion date and owner, to the control and components it affects. Dashboards in Prolaborate or Power BI on that connected data can render the ConMon view: open POA&M items by age, severity, and control family, which is what the monthly ConMon deliverable to the agency authorizing official needs.

For agencies and CSPs treating this as a standing capability rather than a one-time paperwork exercise, the same discipline that makes FedRAMP defensible is the discipline that makes any regulated technology architecture auditable.

What your architects can now get done

An authorization is maintained by people who answer to the agency, the 3PAO and the authorizing official. The tools help with each job; the skill that decides the result is the architect’s.

Keeping control status and findings current

Today someone copies implementation status, assessment results and POA&M items from the control-tracking system into the model and the SSP before each deliverable.

AI-augmented, the architect says which system is the source of record for each fact and what each status means, and AI connects to the eGRC, vulnerability and ITSM systems and relates their records to the controls and components in the model.

The skill is defining statuses and sources precisely, and reviewing the exceptions before a monthly deliverable goes to the authorizing official.

Tools that help: Claude + AI Power Tools, GitHub Copilot + AI Power Tools or Kernaro AI Hub.

Producing the SSP diagrams

Today the boundary, network, data flow and authentication diagrams are drawn by hand and checked against the running system.

AI-augmented, the architect states what each diagram must show and the boundary rules it must respect, and AI builds the diagrams from the model and rebuilds them when the architecture changes.

The skill is stating the intent and the boundary rules clearly, and judging whether each diagram would satisfy an assessor.

Tools that help: Claude + AI Power Tools or GitHub Copilot + AI Power Tools.

Which tool helps depends on the job. Compare the AI options.

FAQ

We teach your architects to build and run the FedRAMP model this way on your own repository: start at For Architects. Or we build and update it for you, connected to your source systems: what we build. Either way, the ConMon and compliance dashboards land in Prolaborate or Power BI: Reporting and Power BI.