NIST RMF System Categorization with FIPS 199 in 2026

NIST RMF system categorization is the first real decision in the Risk Management Framework, and every later step depends on it. You decide how bad it would be if the information and the system were compromised, record that as a category, and use it to select controls, scope assessments and set authorization effort. FIPS 199, the federal standard that defines the categories, is short, but applying it well takes care. A category that is too low leaves real risks uncovered, and one that is too high wastes money on unneeded controls.

This guide explains FIPS 199 impact levels, how to categorize information types and systems, and how the result feeds the rest of the RMF. It sits alongside our guides to the NIST RMF, NIST RMF versus FedRAMP and NIST SP 800-30 risk assessment.

What FIPS 199 defines

FIPS 199 establishes a standard for categorizing federal information and information systems according to the level of concern for three security objectives: confidentiality, integrity and availability. For each objective, the potential impact of a compromise is rated low, moderate or high.

Impact level	Definition in FIPS 199
Low	A loss could be expected to have a limited adverse effect on operations, assets or individuals
Moderate	A loss could be expected to have a serious adverse effect
High	A loss could be expected to have a severe or catastrophic adverse effect

The standard gives examples for each level. A limited effect might mean degraded mission capability, minor asset damage, minor financial loss or minor harm to individuals. A serious effect involves significant degradation, substantial damage, considerable loss or significant harm not involving loss of life. A severe or catastrophic effect includes loss of mission capability, major damage or loss, and catastrophic harm such as loss of life or serious life-threatening injuries.

The categorization format

FIPS 199 records a category in a set format: SC of the subject equals a set of three pairs, one each for confidentiality, integrity and availability, each with an impact value of low, moderate or high. For information types only, confidentiality may be marked not applicable. For example, a public web page of announcements might be low for confidentiality, moderate for integrity and low for availability.

Step 1: identify information types

Start with the information the system processes, stores or transmits. List the types, such as personnel records, financial data, law enforcement data, public information or system configuration data. Many organizations use NIST Special Publication 800-60 as a catalogue of information types with provisional impact levels. Involve the information owners, because they understand the consequences of disclosure, tampering and loss.

Assess each objective separately

For each information type, assess confidentiality, integrity and availability independently. Ask what would happen if the information were disclosed to the wrong people, altered without authorization or unavailable for a period. Record the reasoning and any special factors, such as legal obligations, mission criticality or the number of individuals affected. Adjust the provisional levels when your context justifies it, and document why.

Step 2 of NIST RMF system categorization: apply the high water mark

For the information system, FIPS 199 says the impact values assigned to each security objective must be the highest values, the high water mark, among the categories of each type of information on the system. If one type of information has high confidentiality impact, the system is high for confidentiality, even if other types are low. The standard also says systems cannot use not applicable for any objective, because the system itself requires baseline protection.

Information type	Confidentiality	Integrity	Availability
Type A	Moderate	Moderate	Low
Type B	Low	High	Moderate
System (high water mark)	Moderate	High	Moderate

The example table is invented for illustration. The system inherits the highest value in each column.

Step 3: review and approve

Document the categorization in the system security plan, including the information types, impact ratings, rationale and any adjustments. Have the system owner, information owners and the security officer review it, and have the authorizing official or delegate approve it. Reviewers should challenge low ratings on integrity and availability, which are often underestimated, and check consistency with similar systems.

How the category drives the rest of the RMF

• Control selection. The category determines the control baseline, with additional tailoring for your environment.
• Assessment depth. Higher categories usually need more rigorous assessment and monitoring.
• Authorization. The category informs who approves the system and how much risk that person is asked to accept.
• Monitoring. Continuous monitoring plans scale with the category.

Our guide to the cybersecurity risk register shows how to track residual risks after controls, and plans of action and milestones explains how weaknesses are managed.

Revisit NIST RMF system categorization when things change

A category is not permanent. Review it when the system takes on new information types, connects to new systems, changes its mission or after a major incident. Also revisit it periodically as part of continuous monitoring. Record each review and any change, and update the control baseline if the category changes.

Documenting NIST RMF system categorization in the security plan

The categorization record should let a reader understand the decision without asking anyone. Include the system name and boundary, the list of information types with their sources, the impact rating for each objective with a short rationale, the high water mark result, any adjustments to provisional ratings and the approvals with dates. Attach or reference the business impact analysis and any legal or contractual drivers. When assessors and authorizing officials later ask why a control baseline was chosen, this record is the first document they will read, so keep it tidy and current. Good NIST RMF system categorization records also make reuse easier, because similar systems can start from proven ratings.

Categorization and risk response

The category sets the starting point for risk decisions, but it does not replace them. After controls are selected and assessed, remaining risks still need a response: accept, mitigate, transfer or avoid, as described in our guide to NIST risk response. A high category means a high potential impact, not necessarily a high likelihood. Combine the category with threat and vulnerability information to judge the actual risk, and record the decision with the authorizing official.

Shared systems and inheritance

Many systems depend on shared services such as identity providers, networks and cloud platforms. When you categorize a system, consider the services it relies on, and confirm that their categories are at least as high as the information they support. Controls provided by a shared service can be inherited, but you must document which are inherited, which are shared and which are yours alone. This avoids gaps where each party assumes the other is responsible. Where a cloud provider holds an authorization, check that its impact level covers your information.

Involving the right people

Categorization works best as a short workshop, not a solo task. Bring in the system owner, information owners, a privacy specialist, the security officer and someone who knows operations. Ask the group to describe realistic bad days: what happens if the data leaks, if it is altered, if it is down for a week. Those stories turn abstract impact levels into concrete judgements, and they often reveal dependencies that the documents miss.

A hypothetical example

A hypothetical agency office builds a case tracking system that holds personal details of applicants, decision notes and public statistics. The team lists three information types and assesses each. Applicant records are moderate for confidentiality because disclosure would seriously harm individuals, and moderate for integrity. Decision notes are moderate for integrity. Statistics are low across the board. Availability is rated low because the office can work manually for days. By the high water mark, the system is categorized as moderate for confidentiality and integrity and low for availability. A reviewer challenges the availability rating, noting that a statutory deadline could be missed after a long outage, and the owners raise availability to moderate with a short rationale. The example is invented for illustration.

Common mistakes in NIST RMF system categorization

• Categorizing the system before identifying information types.
• Rating everything moderate without reasoning.
• Underestimating integrity and availability impacts.
• Forgetting that the system uses the high water mark across information types.
• Marking a system not applicable for an objective.
• Failing to review categorization after significant changes.

Read the full text of FIPS 199 and the related NIST guidance. If your organization is not a federal agency, use the standard as a structured approach and adapt the language.

Templates for NIST RMF system categorization

To avoid building categorization worksheets, information type inventories and approval records from scratch, the NIST Risk Management Toolkit provides documents you can adapt. Have your security officer check them against current NIST guidance.

NIST RMF system categorization FAQ

What are the FIPS 199 impact levels?

Low, moderate and high, based on the potential effect of a compromise on operations, assets and individuals.

What is the high water mark?

The highest impact value for each security objective among the information types on the system, which becomes the system’s category.

Can a system be not applicable for confidentiality?

Not according to FIPS 199. That option is only for information types.

Who approves the categorization?

The system owner and information owners review it, and the authorizing official or delegate approves it, according to common practice.

How often should it be reviewed?

Whenever the system or its information changes significantly, and periodically as part of continuous monitoring.