Module 10: Designing IT Services Around Federal Data Classifications

Step 1 – From Data Classification to System Design (Big Picture)

In this module, you’ll connect federal data classifications to concrete design decisions for IT services, focusing on Controlled Unclassified Information (CUI) and moderate‑impact systems.

By now (after Modules 8 and 9), you’ve seen:

• How CUI is defined and handled (per 32 CFR Part 2002 and NARA guidance)
• How impact levels (low/moderate/high) from FIPS 199 and NIST SP 800‑60 drive security expectations
• How FedRAMP uses those impact levels for cloud services (FedRAMP Low/Moderate/High baselines, based on NIST SP 800‑53 Rev. 5)

In this step, anchor three key ideas:

1. Classification → Requirements

• Once you know the data type (e.g., CUI, PII, FCI) and impact level (e.g., moderate confidentiality), you can map to specific control baselines (e.g., NIST 800‑53 moderate, FedRAMP Moderate).

1. Requirements → Architecture & Processes

• Those controls then shape your technical architecture (encryption, logging, network segmentation) and procedures (access reviews, incident response, training).

1. Architecture & Processes → Documentation & Evidence

• You must be able to explain and prove what you do, usually through a System Security Plan (SSP), Plans of Action and Milestones (POA&Ms), and, for cloud, FedRAMP package documents.

Over the next steps, you’ll walk through a practical design workflow for an IT service that handles CUI in a moderate‑impact system, similar to what a contractor or cloud provider supporting a U.S. federal agency would do.

Step 2 – Identify Data Types and Applicable Frameworks

The first design step is to be very clear on what data you have and what rules apply.

2.1 Identify data types

Typical federal‑related data types in IT services:

• CUI – Controlled Unclassified Information (e.g., export‑controlled technical data, law enforcement sensitive info, certain financial or health data).

→ Governed by CUI Registry (NARA) and 32 CFR Part 2002.

• FCI – Federal Contract Information (from FAR 52.204‑21). Often less sensitive than CUI but still requires basic safeguarding.
• PII – Personally Identifiable Information (e.g., names + SSNs, contact info), guided by Privacy Act and OMB/NIST privacy guidance.
• Agency‑specific sensitive data – e.g., IRS taxpayer data, DoD mission data, law enforcement case files.

2.2 Map to impact levels

Use FIPS 199 and NIST SP 800‑60 Vol. 1 & 2 to determine impact levels for:

• Confidentiality (C), Integrity (I), Availability (A)

For most CUI systems, agencies treat them as at least moderate confidentiality. Many are moderate‑impact systems overall (C=moderate, I=moderate, A=moderate).

2.3 Determine which frameworks apply (as of late 2025)

Depending on your role and customer:

• NIST SP 800‑53 Rev. 5 – Core control catalog for federal systems.
• FedRAMP Rev. 5 baselines – For cloud services used by federal agencies.
• NIST SP 800‑171 Rev. 3 – For protecting CUI in nonfederal systems (e.g., contractors) when not operating as a full FISMA system.
• DFARS 252.204‑7012 / CMMC 2.0 – If you support DoD and handle CUI in the Defense Industrial Base.
• Agency policies – e.g., DHS 4300A, IRS Pub 1075, etc.

Design rule: Never design in a vacuum. Always link your architecture to specific frameworks and impact levels before choosing controls.

Step 3 – Quick Thought Exercise: What Applies?

Imagine you’re building a cloud‑hosted case management system for a civilian federal agency. It will store:

• Names, addresses, and phone numbers of citizens
• Internal case notes marked as CUI (e.g., law enforcement sensitive)
• Uploads of documents from other agencies, some of which are also marked CUI

The system will run on a commercial cloud provider and be accessed by agency staff and a few contractors.

Your task:

1. List at least three frameworks or standards that are likely relevant to your design.
2. For each, write one sentence describing why it matters.

Pause for a minute, jot down your answers, then compare with the sample set below.

---

Sample answers to compare against (do not peek until you try):

• NIST SP 800‑53 Rev. 5 (moderate baseline)
• FedRAMP Moderate (because it’s a cloud service used by a federal agency)
• NIST SP 800‑171 Rev. 3 (because CUI may also be processed in contractor environments)
• CUI Registry / 32 CFR Part 2002 (for marking and handling CUI)
• OMB and agency‑specific privacy guidance (because of PII)

Did you get at least three of these? If not, review Step 2 before moving on.

Step 4 – Define and Enforce System Boundaries

Once you know the data and frameworks, define system boundaries so you can clearly say: “CUI lives here, and here’s how we protect it.”

4.1 What is a system boundary?

A system boundary is the set of components (hardware, software, networks, people, locations) that are in scope for a particular security authorization (ATO, FedRAMP authorization, or NIST 800‑171 assessment).

You must be able to answer:

• Which servers, containers, databases, and services handle CUI?
• Which networks and subnets carry CUI traffic?
• Which users and roles can access CUI?
• Which external systems exchange CUI with your system?

4.2 Practical boundary design patterns for CUI (moderate impact)

Common approaches:

• Isolated CUI enclave
• Dedicated VPC/VNet or on‑prem segment for CUI workloads.
• Strict network controls and separate admin accounts.
• Shared platform with segmented CUI zone
• Same cloud account/tenant but separate subnets, security groups, and resource tags for CUI.
• Strong IAM policies to prevent cross‑contamination.
• Data‑layer isolation
• CUI only allowed in certain databases or storage accounts with extra controls (e.g., KMS keys, stricter logging, DLP).

4.3 Boundary documentation

You should be able to sketch (and later include in the SSP):

• A logical diagram (e.g., boxes for web tier, app tier, DB tier, admin tools, monitoring, external interfaces).
• A data flow diagram showing where CUI enters, moves, is stored, and leaves.

Design tip: When in doubt, err on the side of including more components in the boundary, then justify exclusions explicitly in documentation.

Step 5 – Example Architecture: CUI‑Capable Web Application (Moderate Impact)

Consider a CUI‑capable ticketing system hosted on a commercial cloud, supporting a federal agency at moderate impact.

5.1 High‑level architecture (visual description)

Imagine a diagram with these layers:

1. User Layer

• Federal employees connect via VPN or trusted network.
• Contractors connect via secure remote access with MFA.

1. Edge / Security Layer

• Web Application Firewall (WAF) in front of a load balancer.
• TLS 1.2+ enforced; only FIPS‑validated crypto modules.

1. Application Layer

• Auto‑scaled app servers in a private subnet.
• Access to CUI only via internal APIs.

1. Data Layer

• Encrypted relational database (e.g., managed DB) in private subnet.
• Encrypted object storage bucket for attachments, with strict bucket policies.

1. Management & Monitoring Layer

• Centralized logging (SIEM) collecting audit logs.
• Configuration management and vulnerability scanning tools.
• Separate admin jump host for privileged access.

5.2 CUI‑driven design choices

Because the system stores CUI at moderate impact, you would typically:

• Use FedRAMP Moderate‑authorized cloud services where possible.
• Enforce encryption in transit and at rest for all CUI data.
• Implement role‑based access control (RBAC) tied to federal/contractor identities.
• Enable detailed audit logging for CUI access and admin actions.
• Configure backups that inherit the same encryption and access controls.
• Limit admin access to a small group with MFA, just‑in‑time elevation, and logging.

This architecture becomes the starting point for mapping specific NIST 800‑53 controls and for writing your SSP.

Step 6 – Selecting and Tailoring Security Controls

With your boundary and architecture in mind, you now select and tailor controls from the relevant baselines.

6.1 Start from a baseline

For a moderate‑impact CUI system used by a federal agency:

• Use NIST SP 800‑53 Rev. 5 Moderate baseline as the primary control set.
• If cloud‑hosted, apply the FedRAMP Moderate baseline (which is a specific implementation of 800‑53 controls, plus FedRAMP‑specific requirements).
• If you’re a nonfederal contractor handling CUI but not operating a FISMA system, use NIST SP 800‑171 Rev. 3 (derived from 800‑53, but streamlined).

6.2 Map controls to architecture components

Example mappings:

• AC‑2 (Account Management) → Identity provider, IAM policies, user lifecycle processes.
• SC‑13 (Cryptographic Protection) → TLS configuration, disk encryption, KMS/HSM.
• AU‑2/AU‑6 (Audit and Event Logging) → SIEM, log retention, alerting rules.
• CM‑2/CM‑6 (Configuration Management) → Baseline images, IaC templates, patching.

6.3 Tailor controls based on risk and practicality

You rarely apply controls exactly as written. Tailoring includes:

• Scoping – Some controls may be “not applicable” (with justification). Example: If you have no mobile devices, some mobile‑specific controls may be out of scope.
• Compensating controls – If you cannot meet a control as written, you may use another control that provides equivalent protection (must be well‑justified and documented).
• Parameterization – Setting specific values (e.g., “session timeout = 15 minutes of inactivity”).

Key point: Tailoring is not about relaxing security; it’s about making controls fit your actual system and risk while still meeting federal expectations.

Step 7 – Quick Check: Baselines and CUI

Test your understanding of how baselines relate to CUI systems.

Step 8 – Documenting the System Security Plan (SSP)

The System Security Plan (SSP) is your master document that explains how your system meets required controls.

8.1 What an SSP typically includes

For a CUI, moderate‑impact system, an SSP usually covers:

• System overview – Purpose, users, data types (including CUI categories), impact levels.
• System boundary description – Components, locations, diagrams, and data flows.
• Control implementation statements – For each required control (e.g., from 800‑53 or 800‑171), a clear description of how you implement it.
• Interconnections – External systems, interfaces, and how they are protected.
• Roles and responsibilities – System owner, ISSO, admins, users, contractors.

8.2 Writing good control implementation statements

For each control, answer:

1. Who is responsible? (e.g., CSP vs. customer vs. integrator)
2. What technical and procedural measures are in place?
3. Where in the architecture is it implemented?
4. How is it monitored and maintained?

Weak statement example:

> AC‑2: We manage user accounts.

Better statement example:

> AC‑2: User accounts are managed through the agency’s enterprise identity provider integrated with the CSP’s IAM service. New accounts require manager and security officer approval via the ticketing system. Accounts are automatically disabled after 35 days of inactivity and reviewed quarterly by the system owner. Admin accounts are separate from user accounts and require MFA.

8.3 SSPs in FedRAMP and 800‑171 contexts

• FedRAMP – Uses a standardized SSP template; CSPs submit detailed control implementations and shared responsibility clarifications.
• NIST 800‑171 – Organizations create SSPs describing how they meet each 800‑171 requirement; this is critical for DoD and other CUI‑related contracts.

Remember: Auditors and authorizing officials will rely heavily on your SSP to understand and assess your system.

Step 9 – Example: Control Implementation Snippet in YAML

Here is a simplified example of how a team might structure control implementation details in a machine‑readable format (e.g., as part of an internal compliance as code approach).

Step 10 – Managing Gaps with POA&Ms

Even well‑designed systems rarely meet every requirement on day one. That’s where POA&Ms come in.

10.1 What is a POA&M?

A Plan of Action and Milestones (POA&M) is a tracked list of security weaknesses, each with:

• Description of the issue and affected controls
• Root cause (if known)
• Risk rating (e.g., low/medium/high)
• Planned remediation actions
• Milestones and due dates
• Current status and responsible owner

In FedRAMP and many agency processes, POA&Ms are mandatory and are regularly reviewed.

10.2 Example POA&M entries for a CUI system

• Missing quarterly access review evidence for one quarter

→ Action: Update process and backfill review; due in 30 days.

• Legacy API endpoint still supports weak cipher suite

→ Action: Update TLS configuration and retest; due in 15 days.

• Some admin actions not fully captured in central logs

→ Action: Update logging configuration and SIEM parsers; due in 45 days.

10.3 Why POA&Ms matter for CUI

For CUI systems, agencies and DoD (via DFARS/CMMC) expect continuous improvement and transparency. A realistic POA&M shows that:

• You understand your gaps
• You have a credible plan to close them
• You are tracking progress and not ignoring issues

Design mindset: Plan for POA&Ms from the start. Build processes to detect, log, and remediate issues as part of normal operations.

Step 11 – Flashcard Review: Key Terms

Flip through these cards to reinforce core concepts from this module.

Step 12 – Design Walkthrough: Apply It to a New Service

To consolidate everything, walk through a mini design exercise.

Scenario: You are helping design a managed file transfer service for a federal agency. It will:

• Transfer and store files marked as CUI (moderate impact)
• Integrate with the agency’s identity provider
• Run on a commercial cloud platform

Your task – outline your approach in 5–7 bullet points:

1. Data & framework identification

• Which data types are involved? Which frameworks and baselines apply?

1. System boundary

• What components (e.g., SFTP endpoints, storage, key management, logging, admin tools) are inside the boundary?

1. Key controls & architecture choices

• How will you handle encryption, access control, logging, and network segmentation?

1. SSP highlights

• What are the most important things you would describe in the SSP for this service?

1. POA&M planning

• Identify at least one likely gap or risk and how you would track it in a POA&M.

Write your answer as if you were briefing a security architect. If you can do this clearly and concretely, you are successfully designing IT services around federal data classifications.