How FIPS 199 security categorization for NIST 800-53 works and what it costs in effort
If a contract, agency or regulator now requires NIST SP 800-53, categorization is the first decision you make. Under FIPS 199, each system is rated low, moderate or high impact, and that level selects the SP 800-53B baseline you must start from. NIST does not publish a fixed fee or duration for this work, because NIST does not estimate compliance costs. Your effort depends mainly on how many information types the system holds and how many systems fall inside the authorization boundary. A single web application with one data type is a small exercise. A shared platform carrying health, financial and public records data is a large one, and each information type must be rated for confidentiality, integrity and availability before the system rating can be set.
Your organization owns the categorization. Your system owner and security team document the system's characteristics and the impact rating for each information type, and the high water mark rule then sets the system level. The authorizing official or a designated representative must review and approve that result under the Risk Management Framework, and an independent assessor does not sign it off for you. DeployOpen can help prepare the system inventory, the information type list and the categorization write-up, so the reviewer has a complete package to decide from. We do not approve, certify or validate the categorization, and we do not replace the authorizing official's judgment.
Ask any implementation partner for a written scope that names each system, each information type and each deliverable, including the categorization record, the review meeting and the rework allowance if the authorizing official asks for changes. Confirm who attends workshops with business owners, since the impact definitions in FIPS 199 depend on mission knowledge that engineers rarely hold. Costs recur when systems change: a new data type, a new integration or a change in mission can move the high water mark, so budget for a re-categorization review at each significant change rather than treating the first approval as permanent.
The RMF categorization tasks C-1 to C-3
The three categorization tasks turn a documented system into a reviewed categorization record, which then sets the impact level that selects the SP 800-53B baseline. Each task produces a named artifact that an authorizing official or designated representative can review and approve.
Gather the system characteristics
The system owner and the security team document what the system does, which mission or business functions it supports, what information it stores, processes and transmits, its users and interfaces, and its connections to other systems. This is the input to categorization, so the description should cover the full authorization boundary rather than a single component. The step is complete when a system description exists that a reviewer who did not build the system can follow, and that names the owner, the boundary and the information flows. Illustrative example: a claims processing application that exchanges files with a clearinghouse would list that exchange as an interface, not leave it implicit.
Identify the information types
Using the system description, the team lists each information type the system handles, such as citizen records, financial transactions or operational logs, and records the owner or mission area that depends on it. FIPS 199 applies to user and system information in electronic or non-electronic form, so paper records and system metadata belong on the list when they affect impact. The output is an inventory of information types with their owners. Confirm the list with the mission owners, because they are the people who can describe what a compromise would mean for their operations.
Assign provisional impact levels per information type
For each information type, the team rates the potential impact of a loss of confidentiality, integrity and availability as low, moderate or high, using the FIPS 199 definitions of limited, serious, and severe or catastrophic adverse effects. Ratings should reflect the operational, asset, financial and individual harms the owner describes, and the team should record the reasoning behind each rating. The output is a table of confidentiality, integrity and availability values for every information type, with a short rationale for each value that a reviewer can challenge.
Apply the high water mark to the system
The team takes the highest confidentiality value, the highest integrity value and the highest availability value across all information types, and uses those three values to set the system's security category. The system is low only if all three are low, moderate if at least one is moderate and none is high, and high if any one is high. The output is a single system impact level with the three system-level values shown beside it. Check that no information type was left out, because an omitted high-impact type will lower the result without anyone noticing.
Document the categorization record
The team writes the categorization record that brings together the system description, the information type inventory, the per-type impact values, the high water mark result and the rationale. The record should be specific enough for an assessor to trace each impact value to an information type and each information type to a mission owner. It also names the system owner and the people who prepared the record. The step is complete when the record is version-controlled with the system security documentation, so the categorization that drives control selection can be traced later.
Obtain review and approval
The categorization record goes to the authorizing official or the designated representative, who reviews the characteristics, the impact ratings and the high water mark result and then approves or returns the categorization. The approval should be recorded with the approver's name, role, date and the version of the record they reviewed. This approval is the output that closes task C-3, and it gates the selection of the SP 800-53B baseline. Confirm with your authorizing official how they want the approval captured, since the expected form depends on your agency or organization's RMF governance.
Confirm the source of the tasks
The categorization tasks are defined in NIST SP 800-37 Rev. 2, which sets out the Risk Management Framework that these three steps belong to. Read the Prepare and Categorize sections directly for the exact task wording and responsibilities, since this page explains the sequence in practical terms rather than replacing the publication. Keep a copy of the version you cite in the authorization package so reviewers can compare your categorization record with the task definitions.
Categorizing information types before the whole system
When a system handles one kind of information, categorization is short but still needs a documented decision. FIPS 199 expresses the security category of an information type as three impact values, one each for confidentiality, integrity and availability. For a single-purpose system, those values usually become the system's values directly, because there is no other information type to compare against. The inputs are the business function the system supports, the data it stores or processes and the effect a loss would have on the people and operations that rely on it.
- One information type: Record the type, its owner and the confidentiality, integrity and availability values with the reason for each.
- Form of the information: Note whether the data is electronic or paper-based, since FIPS 199 applies to both when they feed the system.
- User and system information: Record both the business data and the operational data the system generates, such as logs and configuration, even when they seem minor.
- Impact judgments: Ask the information owner and business leader to state the consequence of loss in plain terms, then have the security team review the wording.
- Documented rationale: Keep a short memo that ties each value to the FIPS 199 low, moderate or high definition.
Check that the system owner and the authorizing official agree the single information type reflects everything the system actually stores, including backups and integration feeds.
Most real deployments hold several information types with different sensitivity, so each one needs its own category before anything is combined. A customer record store, a payment reference table and an internal reporting dataset may each carry a different confidentiality value but the same availability need. FIPS 199 asks for the category of each type first, and the system-level result is then derived from those values. Treating a mixed system as one undifferentiated type either overstates the controls needed for low-sensitivity data or hides the exposure of the most sensitive data.
- Inventory by type: List each information type, where it lives and which processes create or change it.
- Separate values: Assign confidentiality, integrity and availability values to each type rather than a single label for the whole system.
- Shared components: Identify databases, message queues and admin consoles that hold several types, since they inherit the highest value they carry.
- Business input: Ask each data owner to supply the impact judgment for their own type, with a named reviewer for conflicts.
- Change tracking: Revisit the inventory when a new data type or integration is added.
Confirm that the inventory reflects what the system holds today, not only what the original design intended.
A system that receives information from other systems, partners or users has to categorize what passes through it, not only what it creates. Inbound feeds can carry sensitive data that the receiving team never generates itself, and a loss of that data can still have a serious effect on the organization or on individuals. The categorization should describe the information as it arrives and how the receiving system relies on it, including whether the system cannot function without the feed. Ownership of the source data often sits outside the team running the system, so the agreement on who supplies the impact judgment matters.
- Inbound inventory: List each source, the information types it sends and the format, electronic or non-electronic, in which it arrives.
- Reliance on feeds: Note what happens to availability if a feed stops, since this can raise the availability value even when the data is low sensitivity.
- Source-owner input: Obtain the impact judgment from the owner of the source data, documented in the interface or information exchange agreement.
- Derived information: Record whether the system combines inbound data with its own data, which can produce a more sensitive result.
- Non-electronic inputs: Include forms, faxes or printed reports that are keyed in, since they are still information that the system depends on.
Confirm with each source owner in writing that the impact values they supplied match the sensitivity of what the receiving system holds.
The impact judgments in FIPS 199 are business decisions about the consequences of loss, so they belong with people who understand the mission, the data and the people affected. The security team can frame the questions, check the reasoning against the FIPS 199 definitions and flag gaps, but it should not decide alone. The authorizing official or designated representative reviews and approves the categorization, which makes approval a governance step rather than a technical one. Clear roles prevent a common failure in which the categorization reflects only what the security team can see.
- Information owners: Provide the consequence of loss for each type, in terms of operations, financial effect and harm to individuals.
- System owner: Confirms the inventory is complete and that the information flows match the system design.
- Privacy and legal contacts: Advise where personal information raises the potential for harm to individuals beyond operational impact.
- Security team: Checks each judgment against the FIPS 199 low, moderate and high definitions and records the reasoning.
- Authorizing official: Reviews and approves the final categorization before control selection begins.
Before engaging an outside party to help, confirm that your organization owns these judgments and that any consultant documents its role as preparing the analysis rather than deciding it.
How the high water mark sets the baseline
The high water mark is the rule that turns three separate impact values into one system impact level, and that level selects the SP 800-53B baseline. Under the rule, a system is low impact only if confidentiality, integrity and availability are all low. It is moderate if at least one of the three is moderate and none is high, and it is high if any one of them is high. The system takes the highest value across all of its information types, so a single high rating on one important dataset sets the impact level for the whole system, even when every other value is low.
Consider this illustrative example. A hypothetical benefits case system holds three information types. Public program eligibility rules rate low for confidentiality, low for integrity and low for availability. Applicant contact records rate low for confidentiality, moderate for integrity and low for availability. Payment authorization records rate high for integrity because a silent change could redirect funds, and moderate for confidentiality and availability. The high water mark takes the highest value in each column: high for integrity, moderate for confidentiality and moderate for availability. Because one value is high, the system is high impact and the SP 800-53B high baseline applies to the whole system, not just to the payment records. Had the payment records been rated moderate for integrity, the system would have landed at moderate and the moderate baseline would apply.
The result selects one of the three SP 800-53B control baselines (low, moderate or high), which becomes the starting point for tailoring. The privacy baseline is separate: it applies regardless of impact level, so a low-impact system that processes PII still needs the privacy controls. Before you accept the result, confirm with your authorizing official or designated representative that each information type was rated on the FIPS 199 definitions, and that the highest value was not lowered by an assumption about data that is later combined in the same system. Verify the baseline against the official OSCAL profiles on the NIST SP 800-53B page before you cite it in the authorization package.
Who owns, prepares and approves the categorization
This table compares the organization, an implementation partner and the authorizing official across the categorization work, showing who does each task and where independence applies. Read it as a split of responsibility: the organization makes the impact judgments, the partner prepares the material, and the authorizing official approves the result. Only an independent assessor or auditor issues assessment reports, and a partner's preparation does not replace the approval.
| Party and task | Usually outsourced? | Independence boundary |
|---|---|---|
| Organization: owns the business impact judgments for confidentiality, integrity and availability | No, the organization decides | The organization must make these judgments itself; a partner can explain the FIPS 199 definitions but cannot decide the impact level |
| Organization: confirms the mission, business functions and information types the system handles | Partly, with the partner drafting from interviews | Business owners must validate the inventory, since they know which data and functions the system actually supports |
| Implementation partner: drafts the system description, information type inventory and categorization worksheet | Yes, this is commonly outsourced | The partner prepares documents only; it should not hold the authorizing official's decision or sign the categorization as approved |
| Implementation partner: documents the high water mark calculation and supporting rationale | Yes, commonly outsourced | The rationale must be traceable to the organization's own impact decisions so the reviewer can challenge it |
| Authorizing official or designated representative: reviews and approves the categorization | No, this role cannot be outsourced | Approval is an inherently governmental risk decision; the approver should not be the person who wrote the categorization |
| Independent assessor or auditor: tests whether the categorization and its documentation are accurate | Yes, by an independent party | Only an independent assessor or auditor issues assessment reports; neither the organization nor the partner can issue them |
| Confirm with your authorizing official: who signs, what format they expect and how they handle a partner-prepared package | Not applicable | Ask this before work starts so the approval step is written into the scope of work |
What makes categorization take more or less effort
Categorization effort rises or falls with the size of the system and the state of the information behind it. The six drivers below are the ones that most often decide how long the impact decisions take and how many people must sign off on them.
Number of information types
Each information type needs its own provisional impact values for confidentiality, integrity and availability before the high water mark can be applied. A system that processes dozens of distinct record types requires dozens of justifications, and each one must be traceable to a concrete harm. Start by counting the information types the system actually stores, transmits or processes, and merge types that share the same data owner and harm profile.
Systems and interconnections
Every connected system, data feed and interface affects which information crosses the authorization boundary and what a compromise could expose. Interconnections also raise the question of whether one system's categorization constrains another's. Map the boundary and data flows first, then confirm which external connections are in scope for the categorization.
Quality of existing data inventories
A current inventory of data types, owners, storage locations and processing purposes turns categorization into a review exercise. Without one, teams must reconstruct the information from application code, database schemas and interviews, which adds rounds of validation. Check whether the inventory names an owner and a purpose for each data set before workshops begin.
Business owners giving impact input
Impact ratings depend on the people who understand the mission harm from a loss, such as program managers, legal counsel and privacy officers. Each additional owner adds scheduling, disagreement and rework, especially when two owners rate the same data differently. Name one accountable decision maker per information type and set a deadline for objections so the ratings can be consolidated.
Shared with other agencies or contractors
When a system serves several agencies or is operated by a contractor, each party may hold a different view of the harm from a loss, and the impact decision must still be made by the accountable authorizing organization. Shared ownership also means agreements on who reviews and approves the result. Confirm early which organization holds the authorizing role and which partners must agree to the final categorization.
National security system status
A national security system follows separate categorization and control selection rules rather than the SP 800-53B baselines used for most federal systems. Determining status can take a dedicated review, and misclassifying a system late in the process forces the team to restart. Ask the authorizing official or the agency's security office to confirm the status in writing before any impact values are drafted.
When national security systems follow different rules
SP 800-53B does not supply its own baselines for national security systems. Instead, it points those systems to CNSSI 1253 for security categorization and control selection guidance. If your system is, or may be, a national security system, do not assume that the low, moderate or high impact results you reach under FIPS 199 map directly to the SP 800-53B baselines. The categorization and control selection rules that govern your system may come from a different source, and the decision about which source applies belongs to your authorizing body, not to the implementation team.
Before you rely on any FIPS 199 result, ask your authorizing official or designated representative, and the agency or customer that owns the system, to confirm in writing which guidance governs the system. Ask whether the system is classified as a national security system under the definitions that apply to your agency, whether CNSSI 1253 is the required reference for categorization and control selection, and whether any additional overlays or tailoring rules apply. Record the answer in the categorization documentation so that assessors, reviewers and the authorizing official can see which rule set produced the baseline.
Practical consequences follow from this. A categorization worksheet built on the general FIPS 199 process can be correct on its own terms and still be the wrong basis for an authorization if the governing guidance differs. Plan for that possibility early by confirming the rule set during the Prepare step, before control selection and boundary decisions are made, and by keeping the FIPS 199 analysis separate from the final baseline choice until the governing guidance is confirmed. If the answer is unclear, treat the question as a blocking item for the authorization schedule rather than something to resolve later in assessment.
From categorization to baseline selection, step by step
This sequence takes a system from an inventory of its information and mission to an approved FIPS 199 categorization, which then determines the SP 800-53B baseline the team starts from. Each step produces a record that the next one depends on.
Document the system's characteristics
The system owner and security lead describe the system's purpose, the mission or business functions it supports, its users, interconnections, and the authorization boundary it will fall within. Record what the system stores, processes and transmits, and which external services it relies on. The step is complete when a system description exists that someone outside the project could read and understand without a walkthrough. Confirm the boundary wording with the authorizing official's team before going further, because later steps assume it is fixed.
Inventory the information types
Identify each information type the system handles, such as customer records, payroll data, configuration data or operational telemetry, and note the owner of each. Include user and system information, and cover electronic and non-electronic forms that feed the system. The output is a list of information types with a short description and the business functions that depend on each. Ask the data owners to confirm the list, since missing types are the most common reason a categorization changes later.
Assign provisional impact levels to each information type
For each information type, assess the potential impact on the organization, its assets or individuals if confidentiality, integrity or availability were lost. Compare the potential harm against the FIPS 199 low, moderate and high definitions, and record a provisional level for each of the three security objectives. Keep the reasoning next to each rating so that an assessor can follow why a level was chosen. The output is a worksheet with one row per information type and three impact values per row.
Apply the high water mark to the system
Combine the information type ratings into a single system categorization by taking the highest value for each security objective, then take the highest of those three values as the system's overall impact level. Under the SP 800-53B selection rules, one high value makes the whole system high, and the system is low only when all three objectives are low. Write the result as confidentiality, integrity and availability values plus the overall level. The output is the provisional system categorization that the rest of the sequence reviews.
Confirm whether national security system rules apply
Before accepting the provisional categorization, decide whether the system is a national security system. If it is, SP 800-53B directs the team to CNSSI 1253 for categorization and control selection guidance rather than to its own baselines, so the SP 800-53B baseline steps below do not apply as written. Record the determination and the reason for it. The output is a documented decision that names the governing guidance, which the authorizing official can review with the rest of the categorization package.
Obtain authorizing official review and approval
Send the categorization package, including the system description, information type worksheet and high water mark result, to the authorizing official or designated representative for review. The reviewer may challenge ratings, add information types or ask for supporting rationale. Changes are recorded, and the package is approved with a signed or otherwise documented decision. The output is an approved categorization that becomes the reference for the RMF Prepare step and for control selection.
Select the SP 800-53B baseline for the approved impact level
Use the approved overall impact level to choose the matching SP 800-53B baseline: low, moderate or high. Load the corresponding baseline profile from NIST's OSCAL content or the SP 800-53B publication, and compare its controls against the system description to confirm they fit. Add the privacy baseline where the system processes PII, since it applies regardless of impact level. The output is the starting control set, which is then tailored through the RMF Prepare step and documented in the security plan.
Recategorize when information or scope changes
Treat the approved categorization as valid only while the information types and system scope remain as described. Adding a new information type, connecting the system to another system, expanding the user population or changing the authorization boundary should trigger a review of the worksheet and high water mark, with the authorizing official approving any change. Record each recategorization with its date and reason so that the history stays traceable. Confirm with the authorizing official how such triggers are defined in your own authorization process.
Questions buyers ask about FIPS 199 categorization
Can a consultant or vendor categorize our system for us?
No. A consultant or vendor can help prepare the information, but the organization owns the categorization and the authorizing official or designated representative must review and approve it (RMF Task C-3). DeployOpen can help assemble the system characteristics, inventory the information types and document the results so the decision-makers have something concrete to review, but the impact levels are the organization's own determinations. Buyers should confirm in writing which person signs the categorization and which tasks the partner performs, so that accountability stays with the organization.
How much effort does FIPS 199 categorization take?
The effort depends mostly on how many information types the system handles and how well those types are already documented. FIPS 199 asks for a potential impact rating for confidentiality, integrity and availability for each information type, so a system with a small number of well-understood data flows is far quicker to categorize than a platform that stores many kinds of user and system information. Drivers include the number of data sources and interfaces, whether business owners can state the consequences of a loss, the number of reviewers, and how many rounds of approval the authorizing official requires. Ask any partner for a quote that lists the information types in scope, the workshops planned and the review cycle, and state which of those items the client must supply.
Can one categorization cover several systems?
Only in part. Information types can be reused across systems that handle the same data, and the categorization of each information type can be carried into a new system's analysis. However, the security category is set for each information system, and the high water mark is calculated from the impact values of the system as a whole. A shared service or common platform that handles several information types still needs its own categorization record, and each system that connects to it should document how its information types and the high water mark were determined. Treat a reused categorization as a starting point that must be checked against the new system's boundary and data flows.
What happens to the categorization when the system changes?
The categorization must be revisited when the system's information types, mission, users or interconnections change in a way that could alter the potential impact. Adding a new category of sensitive data, a new integration with an external party or a new business function can raise the high water mark, which then changes the baseline selected under SP 800-53B. Organizations usually define triggers in their continuous monitoring strategy, such as significant changes to the system boundary or data, and record each review in the system security and privacy plan. Buyers should ask how the partner will flag changes and how the authorizing official will be notified before a change goes into production.
Does FIPS 199 apply to a cloud service?
Yes, when the cloud service is part of a federal information system or is being assessed against SP 800-53 for a federal or contractual purpose. The categorization applies to the information and the system as a whole, so a cloud-hosted system is categorized on the same basis as an on-premises one. Where the cloud provider supplies controls that the organization inherits, the provider's documentation and the organization's own categorization must agree on the impact levels. Organizations hosting self-hosted open-source platforms in their own cloud accounts should categorize the platform and its data directly. Confirm with the authorizing official how any inherited controls will be reflected in the categorization record.
Does NIST publish a cost estimate for categorization?
No. NIST does not estimate compliance or certification costs, and its risk management guidance does not set a price or a fixed duration for categorization. The cost of FIPS 199 work comes from staff time spent identifying information types, interviewing business owners, documenting the results and obtaining approval, plus any outside help the organization chooses to buy. To build a realistic budget, ask for a written scope that names the systems, information types, workshops and review rounds, and compare quotes on that basis. Internal staff time, approval cycles and the cost of rework when the first categorization is challenged are often larger than the consulting fee itself, so include them in the comparison.
How DeployOpen prepares categorization evidence
DeployOpen helps organizations prepare the categorization record that FIPS 199 security categorization for NIST 800-53 depends on: the system's characteristics, its information types and the high water mark. The organization owns the categorization decision, and the authorizing official or designated representative approves it. DeployOpen prepares the systems, documents and evidence that support that decision.
How we scope
- Engagements are fixed-scope, with the system boundary and information types agreed in writing before work starts.
- The written scope names which systems, data flows and information types are included in the categorization exercise.
- The scope states who on the client side approves the categorization and who receives the final record.
- Ongoing support for categorization updates after system changes is available as a retainer.
How we build
- We document system characteristics, such as components, users, data flows and external connections, from the client's environment.
- We map each information type to confidentiality, integrity and availability impact levels, following the FIPS 199 definitions.
- We apply the high water mark across the information types so the system-level impact level is traceable to its inputs.
- We flag where a national security system question arises so the client can route it to the correct guidance.
How we hand over
- Deliverables include the categorization worksheet, the information type inventory and the system characteristics record.
- Each impact rating carries a short rationale and the source of the input, so an assessor can trace it.
- The package is reviewed with the client's approving official before it is marked as final for their records.
- Handover covers the open questions the client must confirm internally before the categorization is approved.
How we support
- Categorization is revisited when the system changes, and we update the record in line with the approved scope.
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
- We help the client prepare the categorization inputs for the next control selection step, so the baseline choice is traceable.
- Questions about approval, assessor independence or national security system status should go to the client's own authorities or an independent assessor.
Sources and further reading
- NIST FIPS 199, Standards for Security Categorization of Federal Information and Information Systems ↗
- NIST SP 800-53B, Control Baselines for Information Systems and Organizations ↗
- SP 800-53 Rev. 5.2.0 catalog and SP 800-53B baseline profiles in OSCAL ↗
- NIST SP 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations ↗
- FedRAMP: Choose a Class (Consolidated Rules for 2026) ↗
