RA-2: Security Categorization

Quick-reference card

What this control requires

RA-02 requires your organization to categorize every system and the information it processes based on the potential impact of a confidentiality, integrity, or availability loss. This categorization drives every downstream security decision, from which NIST SP 800-53 controls you’ll select to how much rigor your authorization process demands.

In practice, you’ll follow the methodology defined in FIPS 199 to assign impact levels (low, moderate, or high) across three security objectives for each information type your system handles. The highest impact level across all three objectives and all information types becomes the system’s overall categorization, a principle known as the high-water mark. NIST SP 800-60 provides guidance for mapping specific information types to recommended impact levels, giving you a structured starting point rather than forcing subjective judgment calls.

The categorization results don’t stay in a spreadsheet. You’re required to document them, along with the rationale behind each impact-level decision, in the system’s security plan. Your authorizing official (AO) must then review and formally approve the categorization. This three-part requirement, categorize, document, and authorize, ensures accountability and creates a defensible record for auditors and oversight bodies operating under FISMA and related federal mandates.

Why it matters

Security categorization is the single decision that shapes your entire control baseline. Get it wrong, and every control selection, resource allocation, and risk acceptance that follows inherits that error. Organizations that undercategorize systems expose sensitive data to controls designed for lower-risk environments, while those that overcategorize waste resources on unnecessary safeguards.

The risk here isn’t a dramatic breach scenario. It’s a structural governance failure that compounds quietly over time. An organization that categorizes a system as “low” when it processes personally identifiable information at a “moderate” impact level will select a baseline that omits controls the data actually requires. Auditors reviewing your information security program will flag that misalignment, and the finding cascades into questions about every control decision built on top of it.

Failure to maintain this control introduces audit risk and may result in certification withdrawal or regulatory findings. Federal agencies operating under FISMA face specific consequences, including negative audit opinions from inspectors general and potential restrictions on system authority to operate. For organizations pursuing FedRAMP authorization, an unsupported or stale categorization can delay or derail the entire process.

The connection to baseline selection makes this control foundational within the Risk Management Framework (RMF). The categorize step in SP 800-37 feeds directly into control selection, meaning a flawed categorization doesn’t just affect one control. It distorts the entire security posture assessment.

What miscategorization exposes:

• Undercategorized systems receive weaker controls than their data sensitivity warrants, leaving gaps in access control, audit logging, and encryption requirements
• Stale categorizations that haven’t been revisited after system changes fail to account for new information types, integrations, or mission changes
• Missing documentation prevents auditors from verifying how impact levels were determined, triggering findings regardless of whether the categorization itself is correct
• Unapproved categorizations that bypass AO review lack the organizational accountability required by the RMF
• Organizations that skip SP 800-60 mapping and rely on informal judgment produce categorizations that can’t withstand audit scrutiny

How to implement

For your organization

Most organizations struggle with categorization not because the methodology is complex, but because they treat it as a one-time checkbox rather than a living governance process. The most common failure mode is assigning impact levels without tracing them back to specific information types using SP 800-60 mappings.

Step 1: Inventory your information types. Before you can categorize a system, you need to know what information it processes, stores, and transmits. Work with system owners and mission owners to identify every information type, then map each one to the categories defined in NIST SP 800-53 guidance and SP 800-60 Volume II. Don’t overlook transient data flows or information types introduced through integrations with other systems.

Step 2: Assign provisional impact levels. For each information type, determine the potential impact (low, moderate, or high) if confidentiality, integrity, or availability were compromised. SP 800-60 provides recommended starting points, but you should adjust them based on your organization’s specific mission context, legal obligations, and the interconnected nature of your systems.

Step 3: Apply the high-water mark. The system’s overall categorization takes the highest impact level across all information types and all three security objectives. Document each information type’s individual impact levels alongside the final system categorization so the rationale is traceable.

Step 4: Document in the system security plan. Record the categorization results, the information types assessed, the impact levels assigned, and the justification for any deviations from SP 800-60 recommendations. This documentation needs to be specific enough that an auditor can reconstruct your decision-making process without interviewing the people who made the decisions.

Step 5: Obtain AO approval. Submit the categorization to your authorizing official or their designated representative for formal review and approval. The AO’s sign-off confirms that leadership accepts the categorization and the control baseline it drives.

Step 6: Establish a review cadence. Categorization isn’t permanent. Revisit it whenever the system undergoes significant changes, absorbs new information types, or when organizational mission priorities shift. Tie recategorization reviews to your system development life cycle (SDLC) milestones and change management processes tracked through CM-08.

Common mistakes to avoid:

• Copying another system’s categorization without performing an independent information-type analysis
• Failing to include privacy risk assessments when the system processes personally identifiable information
• Treating categorization as an IT-only exercise instead of involving mission owners, privacy officials, CIOs, and senior information security officers
• Not updating categorization when systems are interconnected or when data-sharing agreements change

Evidence examples

Cross-framework mapping

Related controls

• CM-08 — System Component Inventory: categorization relies on an accurate inventory of system components and the information types they process, and feeds back into maintaining that inventory
• MP-04 — Media Storage: the system’s security categorization determines the handling and storage protections required for media containing system information
• PL-02 — System Security and Privacy Plans: categorization results must be documented within the system security plan, making PL-02 the vehicle for recording RA-02 outputs
• PL-10 — Baseline Selection: the impact level established by RA-02 directly determines which control baseline (low, moderate, or high) applies to the system
• PL-11 — Baseline Tailoring: after baseline selection driven by categorization, PL-11 governs how organizations adjust the selected baseline to their specific operational context
• PM-07 — Enterprise Architecture: security categorization informs how systems are positioned within the enterprise architecture and how risk is distributed across the organization
• RA-03 — Risk Assessment: the categorization from RA-02 provides the foundation for conducting risk assessments by establishing the system’s sensitivity and impact context
• RA-05 — Vulnerability Monitoring and Scanning: the system’s categorization level influences the frequency, depth, and priority of vulnerability scanning activities
• RA-07 — Risk Response: categorization context informs how the organization prioritizes and responds to identified risks based on system impact levels
• RA-08 — Privacy Impact Assessments: privacy impact assessments may influence categorization decisions, particularly for systems processing personally identifiable information

Frequently asked questions

What is NIST SP 800-53 RA-02

RA-02 requires organizations to classify each system by the potential impact of losing its confidentiality, integrity, or availability using FIPS 199 impact levels. The resulting categorization determines which control baseline applies and must be documented in the system security plan with formal approval from the authorizing official. This control sits within the Risk Assessment family and applies at the organizational level across all three baselines (low, moderate, and high).

What happens if RA-02 is not implemented

Without a documented and approved security categorization, your organization can’t defensibly select a control baseline, meaning every subsequent control decision lacks a traceable foundation. Auditors will flag the absence as a systemic finding because the categorization drives the entire RMF process, from baseline selection through continuous monitoring. Federal agencies risk negative FISMA audit opinions, and organizations pursuing FedRAMP authorization may face delays or denials until a proper FIPS 199 categorization is completed and approved by the authorizing official.

How do you audit RA-02

Auditors verify that each system has a completed FIPS 199 categorization worksheet documenting the information types processed and their assigned confidentiality, integrity, and availability impact levels. They confirm that the categorization rationale appears in the system security plan alongside evidence that the authorizing official reviewed and formally approved the decision. The audit also checks whether the categorization has been revisited when the system underwent significant changes, new information types were introduced, or when mission priorities shifted.

How does security categorization determine which NIST 800-53 controls apply

The FIPS 199 impact levels assigned during categorization map directly to one of three control baselines (low, moderate, or high) defined in NIST SP 800-53B. A system categorized as “moderate” receives the moderate baseline, which includes all low-baseline controls plus additional controls addressing the higher impact threshold. Organizations then tailor the selected baseline through PL-11, adding or removing specific controls based on operational context, but the categorization remains the starting point that sets the floor for minimum security requirements.