Module 8: FedRAMP and Cloud Data Classifications

Module 8 Overview: FedRAMP and Cloud Data Classifications

In this module, you connect what you learned about CUI, FISMA, and contract clauses (FAR/DFARS) to cloud services and FedRAMP.

By the end of ~15 minutes, you should be able to:

• Describe how federal impact levels (FIPS 199) map into FedRAMP Low/Moderate/High baselines.
• Explain how CUI is handled in FedRAMP Moderate and High cloud environments.
• Identify shared responsibility between a cloud service provider (CSP) and an integrator/managed service provider.
• Evaluate whether a cloud architecture is appropriate for CUI or other sensitive federal data.

Context (as of late 2025)

• FedRAMP is a government-wide program established in 2011 and formally codified by the FedRAMP Authorization Act in December 2022 (part of the FY23 NDAA). It standardizes security assessment and authorization for cloud services used by U.S. federal agencies.
• FedRAMP is built on FISMA and NIST standards, especially FIPS 199, FIPS 200, NIST SP 800‑53 Rev. 5, and related guidance.

You will move step-by-step from big-picture concepts to practical checks you can apply when looking at real cloud services.

Step 1: How FedRAMP Relates to FISMA and NIST

FedRAMP exists to make FISMA compliance in the cloud more consistent and efficient.

Key relationships

• FISMA (Federal Information Security Modernization Act) requires federal agencies to:
• Categorize systems using FIPS 199 (Low, Moderate, High impact for confidentiality, integrity, availability).
• Implement security controls per FIPS 200 and NIST SP 800‑53 Rev. 5.
• FedRAMP:
• Takes those NIST controls and defines standard baselines for cloud systems.
• Provides a centralized authorization and reuse model: “Do once, use many times.”
• Uses 3PAOs (Third Party Assessment Organizations) to test CSP environments.

Important:

• FedRAMP does not replace FISMA. Instead, it gives agencies a standard way to apply FISMA requirements to cloud services.
• Agencies still own the risk and must issue their own Authority to Operate (ATO), but they can rely heavily on a CSP’s FedRAMP Authorization Package.

Think of it this way:

> FISMA + NIST define what security is needed.

> FedRAMP defines how to apply that consistently to cloud services.

Step 2: Federal Impact Levels and FedRAMP Baselines

FedRAMP baselines are built on FIPS 199 impact levels.

FIPS 199 recap (from earlier modules):

• Each system is categorized for Confidentiality, Integrity, Availability (CIA) as Low, Moderate, or High impact.
• The overall system impact level is typically the highest of the three.

FedRAMP Baselines (as of 2025)

• FedRAMP Low
• Based on Low impact FIPS 199 systems.
• Typical data: Public or low-sensitivity data where loss has limited adverse effect.
• FedRAMP Moderate
• Based on Moderate impact systems.
• This is the most common baseline for federal cloud.
• Typical data: Most CUI, PII of moderate sensitivity, mission data where compromise has serious adverse effect.
• FedRAMP High
• Based on High impact systems.
• Typical data: High-value CUI, national security–related data (non-classified but very sensitive), law enforcement operations, health or financial data where compromise could be severe.

> Rule of thumb:

> - CUI → at least FedRAMP Moderate.

> - High-value CUI or critical missions → often FedRAMP High (and may also involve NIST SP 800‑172 from Module 6).

Step 3: Mapping Data Types to FedRAMP Levels (Scenarios)

Consider these practical scenarios and how they map to FedRAMP baselines.

Scenario A: Public-facing info site

• An agency hosts a simple website with already-public information (press releases, brochures).
• No login, no PII, no CUI.
• Impact: Low confidentiality, low integrity, low availability (if it goes down, it’s inconvenient but not severe).
• FedRAMP fit: FedRAMP Low cloud service is usually sufficient.

Scenario B: Grants management system with PII

• Cloud-based system for managing grant applications.
• Stores applicants’ names, addresses, SSNs, bank info.
• Not national security–related, but compromise would be serious.
• Impact: Moderate confidentiality, moderate integrity, moderate availability.
• FedRAMP fit: FedRAMP Moderate.

Scenario C: Critical infrastructure control data

• Cloud service supporting real-time monitoring of critical infrastructure.
• Unauthorized changes could cause major physical or economic damage.
• Impact: High integrity and availability; confidentiality may be moderate or high.
• FedRAMP fit: FedRAMP High.

When you read a system description, ask:

1. What kind of data is stored/processed? (CUI, PII, operational data, etc.)
2. What happens if it’s disclosed, altered, or unavailable?
3. Which FedRAMP baseline matches that impact?

Step 4: Handling CUI in FedRAMP Moderate and High Clouds

Controlled Unclassified Information (CUI) is central to deciding on FedRAMP levels.

Key points (as of 2025)

• CUI in the cloud must be protected at least at a Moderate impact level unless an agency specifically determines a lower impact (rare for most CUI categories).
• FedRAMP Moderate and High baselines incorporate controls aligned with NIST SP 800‑171 (CUI requirements) and, for higher-risk programs, may add NIST SP 800‑172 enhancements (Module 6).

What FedRAMP Moderate/High typically enforce for CUI

• Strong access control: role-based access, least privilege, multi-factor authentication (MFA) for admins and often for users.
• Encryption:
• Data at rest (FIPS 140-validated crypto modules).
• Data in transit (TLS with FIPS-validated modules where required).
• Boundary protection: virtual network segmentation, firewalls, secure gateways.
• Audit and logging: detailed logs, time-synchronized, protected from tampering.
• Incident response: well-defined playbooks, reporting timelines, and coordination with agencies.
• Personnel and physical security: background checks as appropriate, controlled data centers.

For High-value CUI or critical programs, agencies may layer on:

• Additional controls inspired by NIST SP 800‑172 (e.g., more advanced monitoring, deception, or segmentation) even if FedRAMP baseline doesn’t explicitly require them.

> In practice: If a workload contains CUI, you should almost automatically be thinking “FedRAMP Moderate or High, plus 800‑171, and maybe 800‑172 if it’s high-value CUI.”

Step 5: Thought Exercise – Is This Cloud Service OK for CUI?

Imagine you’re helping an agency choose a cloud file-sharing service for CUI.

You see three marketing blurbs:

1. Service X: “FedRAMP Ready – Low Impact. Great for public information sharing.”
2. Service Y: “FedRAMP Authorized – Moderate Impact. Supports CUI and PII.”
3. Service Z: “Commercial cloud, ISO 27001 certified. No FedRAMP authorization.”

Your task:

• Rank these services from most appropriate to least appropriate for CUI.
• For each, note one reason why it is or is not appropriate.

Write down your answer before you scroll.

---

Suggested reasoning

• Most appropriate: Service Y
• Has FedRAMP Moderate Authorization, explicitly supports CUI.
• Less appropriate: Service X
• Only FedRAMP Low; usually not sufficient for most CUI.
• Least appropriate: Service Z
• May be secure in general, but has no FedRAMP authorization for federal use. Agencies would face a much heavier lift to justify and authorize it for CUI.

When evaluating real products, you should always ask:

• What FedRAMP baseline is authorized?
• Is it Authorized, In Process, or just Ready in the FedRAMP Marketplace?
• Does the documentation explicitly mention CUI and relevant NIST standards?

Step 6: Shared Responsibility – CSP vs. Integrator/Customer

In cloud security, not everything is handled by the CSP. FedRAMP uses a shared responsibility model.

Roles

• Cloud Service Provider (CSP) – e.g., AWS, Azure, Google Cloud, or SaaS vendors.
• Responsible for securing the cloud infrastructure and platform defined in their FedRAMP boundary.
• Implements most physical, many network, and some platform controls.
• Integrator / Managed Service Provider / Agency customer
• Builds and configures applications on top of the FedRAMP-authorized service.
• Responsible for inherited vs. customer-responsible controls.

Types of responsibilities

• CSP responsibilities (examples):
• Data center physical security.
• Hypervisor security, core network segmentation.
• Base logging services and platform patching.
• Customer/integrator responsibilities (examples):
• Configuring access control lists, IAM roles, and MFA for users.
• Classifying data and ensuring CUI is only stored in approved services.
• Application-level encryption choices (e.g., key management policies).
• Implementing incident response and continuous monitoring for their own applications.

> FedRAMP documentation for each CSP includes an RACI or responsibility matrix that spells out which controls are Provider, Customer, or Shared. You must read this when designing a CUI-capable architecture.

Step 7: Architecture Example – CUI on a FedRAMP Moderate IaaS

Imagine you are building a CUI-handling web application on a FedRAMP Moderate-authorized IaaS (Infrastructure as a Service) provider.

Provider (CSP) handles:

• FedRAMP Moderate controls for:
• Data center physical security.
• Core network isolation (e.g., virtual private cloud features).
• Baseline logging (e.g., flow logs, API logs) and infrastructure patching.
• FIPS 140-validated crypto modules in storage and network services.

You (integrator/customer) must handle:

• System categorization: Confirm this is a Moderate impact system with CUI.
• Configuration:
• Use private subnets, restrict public exposure.
• Enforce MFA and least-privilege roles in IAM.
• Turn on encryption at rest for storage volumes and databases.
• Require TLS for all web traffic.
• Application security:
• Input validation, secure coding practices.
• Application-level logging and monitoring.
• Data handling:
• Ensure CUI is stored only in FedRAMP-authorized services.
• Define clear data retention and destruction policies.
• Continuous monitoring:
• Review logs regularly.
• Respond to alerts and document incidents.

If an audit asks, “How is CUI protected?” you would show both:

• The FedRAMP authorization package (what the CSP does).
• Your own system security plan (SSP) and configuration evidence (what you do).

Step 8: Quick Check – Matching Data to FedRAMP Levels

Test your understanding of how data sensitivity maps to FedRAMP baselines.

Step 9: Quick Check – Shared Responsibility

Now confirm you understand who does what in the FedRAMP shared responsibility model.

Step 10: Flashcard Review – Key FedRAMP and CUI Terms

Flip these cards (mentally or with a partner) to reinforce the core terms from this module.

Step 11: Apply It – Quick Architecture Review for CUI

Imagine you are reviewing a proposed architecture for a CUI-handling system:

• Uses a FedRAMP High-authorized IaaS provider.
• Stores CUI in object storage that is not encrypted by default.
• Application servers are in a public subnet with security groups allowing SSH from any IP.
• IAM users are created without MFA.

Your task:

1. Identify at least three red flags for CUI protection.
2. For each, state whether the CSP or the customer/integrator is primarily responsible for fixing it.

Pause and think before reading a sample answer.

---

Sample red flags and responsibilities

• Unencrypted object storage for CUI – Customer/integrator must enable encryption and choose proper key management.
• Public-facing servers with broad SSH access – Customer/integrator must tighten network security groups, use bastion hosts or VPN, and restrict SSH.
• No MFA for IAM users – Customer/integrator must enforce MFA and least-privilege roles.

Even with FedRAMP High, a poor configuration by the customer can still put CUI at risk. Always combine FedRAMP authorization with secure architecture and configuration.