Module 1: The US Federal Information Landscape

Step 1 – The Big Picture: How the US Government Handles Information

In this module, you’ll map out the US federal information landscape and see where IT service providers (like cloud vendors, SaaS platforms, and integrators) fit.

Key idea: The US government separates information into two broad worlds:

1. National security information

• Tied to defense, intelligence, and foreign relations.
• Can be classified (Confidential, Secret, Top Secret) under Executive Order (EO) 13526 and related directives.

1. Non‑national security (civilian) information

• Used by most civilian agencies (e.g., HHS, DHS, IRS, EPA).
• Usually unclassified, but often still sensitive and protected (e.g., health data, tax records, PII).

Today’s focus is on how the federal government protects non‑national security information, especially under FISMA and NIST/FIPS standards, and what that means for contractors and cloud providers.

> Visualize two overlapping circles:

> - Circle 1: Classified national security information (DoD, NSA, CIA, etc.).

> - Circle 2: Unclassified but protected information (civilian agencies, most contractor systems).

> This module mostly lives in Circle 2, but you need to know where Circle 1 starts and ends.

Step 2 – National Security vs. Non‑National Security Information

2.1 National security classified information

National security information is information that, if disclosed without authorization, could damage national security. It is controlled mainly by:

• Executive Order 13526 (signed 2009; still the main classification EO as of late 2025)
• Classification levels:
• Confidential – damage to national security
• Secret – serious damage
• Top Secret – exceptionally grave damage
• Controlled under systems like ICD 503, DoD Instruction 8510.01, and special programs (SCI, SAPs).

This kind of information is typically handled in classified environments (e.g., JWICS, SIPRNet) with strict clearance requirements.

2.2 Unclassified but protected information

Most information used by civilian agencies is unclassified but still must be protected. Examples:

• Personally Identifiable Information (PII) – Social Security Numbers, addresses, biometrics
• Protected Health Information (PHI) – health records (HIPAA context)
• Tax data – IRS records
• Law enforcement sensitive data – investigations, case files

Key categories and terms you’ll see:

• CUI – Controlled Unclassified Information
• Established by 32 CFR Part 2002 and EO 13556.
• A standardized way to mark and protect sensitive but unclassified information across the federal government.
• SBU – Sensitive But Unclassified (older, now largely replaced by CUI terminology). You may still see SBU in legacy docs, but CUI is the current standard.

Why this matters for IT providers:

Most federal IT contracts involve unclassified but protected data (often CUI). Your security obligations will usually be defined in terms of FISMA, NIST, FIPS, and CUI requirements, not classified information rules.

Step 3 – Example: Classifying a Real‑World Scenario

Consider these three situations and how they fit into the landscape:

1. A DoD system storing targeting data for overseas operations

• Type: National security information
• Likely classification: Secret or Top Secret
• Environment: Classified network (e.g., SIPRNet, JWICS)
• Frameworks: DoD/IC‑specific (e.g., ICD 503), not the focus of this course.

1. A cloud‑hosted system for a civilian agency that manages grant applications

• Contains PII (names, SSNs, bank info).
• Type: Unclassified but protected (likely CUI)
• Frameworks: FISMA, NIST SP 800‑53, FIPS 199/200, FedRAMP (if cloud).

1. A public website for a national park

• Mostly public information (park hours, maps).
• Type: Unclassified and mostly not sensitive
• Still subject to FISMA, but usually low‑impact per FIPS 199.

> Mental check: As an IT provider, you are far more likely to work on systems like #2 and #3 than #1. That’s why this module focuses on the civilian, non‑classified side.

Step 4 – FISMA: The Backbone of Federal Information Security

4.1 What is FISMA?

FISMA = Federal Information Security Modernization Act.

There were two major versions:

• FISMA 2002 – originally established federal information security requirements.
• FISMA 2014 – updated and modernized FISMA, clarifying roles for DHS and OMB.

As of late 2025, FISMA 2014 is still the operative law, though Congress has considered further updates.

4.2 What FISMA requires (in plain language)

FISMA requires federal agencies to:

1. Inventory information systems (including systems operated by contractors on their behalf).
2. Categorize information and systems by impact (FIPS 199).
3. Select and implement security controls (NIST SP 800‑53).
4. Assess and authorize systems (NIST SP 800‑37 RMF process).
5. Continuously monitor security posture.
6. Report annually to OMB and Congress on security status and incidents.

4.3 Why FISMA matters for IT service providers

FISMA explicitly covers information systems used or operated by an agency or by a contractor of an agency. That means:

• If you run a system for a federal agency (on‑prem, hosted, or cloud), FISMA applies.
• You may be required to implement NIST SP 800‑53 controls, undergo assessments, and support the agency’s Authorization to Operate (ATO) process.

> Think of FISMA as the legal driver that forces agencies to follow NIST and FIPS standards and to push those requirements into contracts with nonfederal systems (your systems).

Step 5 – Agencies, Contractors, and Nonfederal Systems

5.1 Key roles

• Federal agencies – Own the mission and the data. Responsible for compliance with FISMA. Examples: HHS, DHS, NASA, GSA.

• Contractors / IT service providers – Operate systems on behalf of agencies (e.g., cloud hosting, SaaS, managed services, development). These are often called nonfederal systems.

• Oversight bodies:
• OMB – Issues government‑wide guidance on FISMA implementation.
• DHS / CISA – Supports civilian agencies with cyber operations, directives, and shared services.
• NIST – Publishes standards and guidelines (SPs, FIPS).

5.2 What is a nonfederal system?

In NIST and OMB guidance, a nonfederal system is an information system that is not owned or operated by a federal agency, but:

• Processes, stores, or transmits federal information, or
• Provides a service to a federal agency that relies on information technology.

Examples:

• A commercial cloud provider hosting an agency’s application.
• A contractor‑managed case management system for a federal program.
• A SaaS product used by an agency to manage HR or finance.

5.3 How requirements flow to nonfederal systems

Requirements typically flow via:

• Contracts and task orders (e.g., FAR, agency supplements).
• Security clauses referencing FISMA, NIST SP 800‑53, FedRAMP, CUI rules, and sometimes agency‑specific policies.

As a provider, you don’t usually deal with FISMA law directly; you deal with the contract language and NIST/FIPS requirements it references.

Step 6 – Core NIST and FIPS Documents You Must Know

Here are the core documents shaping expectations for federal information systems and contractors. Versions and statuses are current as of late 2025; always check for the latest revisions in practice.

1. FIPS 199 – Standards for Security Categorization of Federal Information and Information Systems

• Defines impact levels: Low, Moderate, High for confidentiality, integrity, availability.
• Agencies use it to decide how much protection a system needs.

1. FIPS 200 – Minimum Security Requirements for Federal Information and Information Systems

• Establishes minimum security requirements across 17 control families.
• Points to NIST SP 800‑53 as the catalog of controls.

1. NIST SP 800‑53, Rev. 5 – Security and Privacy Controls for Information Systems and Organizations

• The main control catalog.
• Defines families like AC (Access Control), AU (Audit and Accountability), SC (System and Communications Protection), etc.
• Used by both agencies and many contractors.

1. NIST SP 800‑37, Rev. 2 – Risk Management Framework (RMF)

• Describes the 6‑step RMF process: Categorize → Select → Implement → Assess → Authorize → Monitor.
• Governs how systems get an Authorization to Operate (ATO).

1. NIST SP 800‑60, Vol. 1 & 2

• Helps agencies map information types (e.g., health, legal, emergency response) to FIPS 199 impact levels.

1. NIST SP 800‑171, Rev. 3 (finalized 2024) – Protecting CUI in Nonfederal Systems and Organizations

• Applies when CUI is in nonfederal systems (very common for contractors).
• Based on a subset of SP 800‑53 controls tailored for contractors.

1. NIST SP 800‑171A

• Provides assessment procedures for SP 800‑171 requirements.

> For this course, the big four to remember are: FIPS 199, FIPS 200, NIST SP 800‑53, NIST SP 800‑171.

> Historical note: Some older documents (e.g., SP 800‑53 Rev. 4) are still referenced in legacy ATOs, but Rev. 5 and newer CUI guidance (SP 800‑171 Rev. 3) are the current direction.

Step 7 – Thought Exercise: Mapping a System to the Framework

Imagine you work for a small company that has just won a contract to build and host a case management system for a civilian federal agency.

The system will:

• Store PII (names, SSNs, addresses)
• Manage benefit eligibility decisions
• Send email notifications to applicants

Your task: In your own words (mentally or in notes), answer these questions:

1. Is this national security or non‑national security information?

• What clues tell you?

1. Is the information likely to be CUI?

• Why or why not?

1. Which core NIST/FIPS documents are almost certainly relevant?

• Pick at least three from this list: FIPS 199, FIPS 200, NIST SP 800‑53, NIST SP 800‑37, NIST SP 800‑60, NIST SP 800‑171.

1. Where do you (as the contractor) fit in the FISMA picture?

• Are you a federal agency? A nonfederal system? Something else?

(Pause and actually think through this. In a live class, you’d compare your answers with a partner or the instructor.)

Step 8 – Quick Check: National Security vs. Civilian Information

Answer this question to check your understanding.

Step 9 – Quick Check: Matching NIST/FIPS Documents

Match each description to the correct document.

Step 10 – Flashcards: Core Terms in the Federal Information Landscape

Flip through these flashcards (mentally or with a study tool) to reinforce key terms.

Step 11 – Apply It: Mini Checklist for IT Providers

Imagine your company is responding to a Request for Proposals (RFP) from a federal civilian agency. The RFP states that the system will process CUI and references FISMA, FIPS 199/200, NIST SP 800‑53, and NIST SP 800‑171.

Create a quick mental or written checklist:

1. Information type

• What kind of data (PII, PHI, financial, law enforcement)?
• Likely CUI? Why?

1. Impact level (FIPS 199)

• Would you expect Low, Moderate, or High?
• Which dimension (confidentiality, integrity, availability) seems most critical?

1. Control sets

• Which documents will you use to plan controls:
• For the agency system: NIST SP 800‑53?
• For your nonfederal environment: NIST SP 800‑171?

1. Contract language

• What clauses would you look for about security requirements, incident reporting, and assessments?

1. Questions for the agency

• List 2–3 clarifying questions you’d ask (e.g., expected impact level, FedRAMP requirements, data residency, CUI categories).

This kind of structured thinking is how practitioners connect law → policy → standards → contracts → technical controls.