How should you score asset criticality: scanner rating, CMDB field, or NIST FIPS 199?

Use all three, in layers. A scanner rating like Tenable ACR gives you a fast numeric sort but only for assets it can see. A CMDB criticality field carries owner-set business context but is frequently left empty. NIST FIPS 199 supplies the impact rationale an auditor recognizes. No single approach covers numeric sorting, business impact, full coverage, and audit defensibility at once.

Asset Criticality Scoring: ACR vs CMDB vs FIPS 199

Q: Is business_criticality on the base cmdb_ci table in ServiceNow?

No. In a standard instance the business_criticality field lives on service and application CI classes such as cmdb_ci_service and cmdb_ci_appl, not on the base cmdb_ci table. Teams that need it on all CIs typically add a custom field and propagate the value.

Q: What are the ServiceNow business criticality values?

On service and application CIs the common tiers are 1 - most critical, 2 - somewhat critical, 3 - less critical, and 4 - not critical. The field defaults to empty, so it must be populated during CI creation or a later review.

Q: What are the three FIPS 199 impact levels?

LOW means a loss of confidentiality, integrity, or availability would have a limited adverse effect; MODERATE means a serious adverse effect; HIGH means a severe or catastrophic adverse effect on operations, assets, or individuals.

Q: Can a scanner rating replace a CMDB criticality field?

No. A scanner rating only covers assets it can see and infers importance from network signals, while a CMDB tier is set by the business owner and can cover any CI. They answer related but different questions and should be reconciled, not substituted.

Q: Which asset criticality approach do auditors accept?

Auditors recognize a documented method with a rationale. FIPS 199 categorization is a formal standard; a CMDB tier is an accepted process if it is populated and reviewed; a raw scanner score is an input, not a standalone justification. The strongest evidence combines all three with dated ownership.

This comparison names at least one weakness of every approach and product discussed. It is written for change and risk managers, not as legal or compliance advice. Some outbound links may be affiliate links; they never change which tools we cover or how we assess them.

Why this matters right now

Every risk-based prioritization method ends on the same instruction: weight the result by how critical the asset is. Our recent walkthrough of VPR, EPSS, and CVSS for a CAB closed on exactly that note, and so does most vendor guidance. The problem is that “asset criticality” is not one number sitting in one place. It is at least three different things: a rating your scanner computes, a field in your configuration management database, and a categorization standard your auditor expects. They disagree, they cover different assets, and they are set by different people.

That disagreement is where change and risk programs quietly lose defensibility. If you tell an auditor a Critical-severity vulnerability was deferred because “the asset wasn’t critical,” the very next question is: critical by whose definition, set by whom, and when. If your answer is a scanner-assigned score with no owner behind it, or a CMDB field that was blank, the deferral looks like a guess. This piece compares the three approaches most teams actually have on hand, names where each one fails, and lays out how to stack them so asset context becomes evidence instead of an argument.

What is a scanner-derived rating like Tenable ACR?

Tenable’s Asset Criticality Rating (ACR) is the most common scanner-side answer. Tenable assigns an ACR to each asset to represent its relative criticality, expressed as an integer, with higher values meaning more critical to the business (Tenable Exposure Management metrics). The rating sorts into four bands: Critical is 9 to 10, High is 7 to 8, Medium is 4 to 6, and Low is 1 to 3 (Tenable Exposure Management metrics). ACR then feeds the Asset Exposure Score (AES), an integer from 0 to 1000 that combines criticality with the asset’s vulnerability exposure (Tenable Exposure Management metrics).

The appeal is that it is automatic and numeric. Tenable derives ACR from several key metrics such as business purpose, asset type, location, connectivity, capabilities, and third-party data, so a team does not have to hand-rate thousands of machines (Tenable: Vulnerabilities by ACR). Assets with a low ACR are, in Tenable’s own words, “not considered business critical” (Tenable: Vulnerabilities by ACR). Lumin customers can also adjust the default ACR to more accurately reflect organizational risk when the model gets it wrong (Tenable: Vulnerabilities by ACR).

The weakness is coverage and provenance. A scanner rating only exists for assets the scanner sees and licenses; an unscanned OT segment, a shadow SaaS tenant, or a decommissioned-but-still-live box gets no rating at all. And because the default score is model-inferred from network signals, it is a proxy for business importance, not a statement from the business. An auditor will accept it as an input, but “the vendor’s algorithm rated it a 4” is a thin answer when the person who owns the revenue that asset supports was never asked. Feed the scanner rating into your change risk scoring, but do not let it be the only voice.

What does the CMDB business_criticality field give you?

The configuration management database is where business context is supposed to live. In ServiceNow, the field is business_criticality, and on service and application CIs it carries owner-set named tiers: 1 - most critical, 2 - somewhat critical, 3 - less critical, and 4 - not critical (ServiceNow developer community: change risk auto-calculation). That is the strongest thing a CMDB offers over a scanner: the tier is meant to be set by, or validated with, the people who own the business service, and it can attach to any configuration item you choose to track, not just the ones a scanner reaches.

Here is the trap most teams walk into. The business_criticality field is not present on the base cmdb_ci table in a standard ServiceNow instance. ServiceNow’s own community guidance is blunt: “Business Criticality is not a field available on the cmdb_ci table. It is only available on cmdb_ci_service” and related service or application classes (ServiceNow developer community: set impact based on business criticality). One organization noted that because criticality only appears on Business Application and Service CIs, they had to create a custom criticality field on cmdb_ci to push the value up and down related CIs (ServiceNow CMDB community: CI criticality).

The second trap is that the field defaults to empty. Business criticality “defaults to empty, not a standard value,” and “many organizations forget to populate this during CI creation, making impact analysis incomplete” (ServiceNow reference: cmdb_ci_appl). A criticality tier that is authoritative in theory but blank in practice tells an auditor nothing. If you rely on the CMDB, the recurring stakeholder review that populates and re-validates those tiers is not optional housekeeping; it is the control.

How does NIST FIPS 199 fit in?

FIPS 199 is the standard an auditor already knows. Rather than a vendor score, it categorizes a system by the potential impact of losing confidentiality, integrity, or availability, across three levels. The potential impact is LOW if a loss “could be expected to have a limited adverse effect,” MODERATE if it “could be expected to have a serious adverse effect,” and HIGH if it “could be expected to have a severe or catastrophic adverse effect” on operations, assets, or individuals (NIST FIPS 199).

The categorization is expressed as a triple: SC = {(confidentiality, impact), (integrity, impact), (availability, impact)}, where each value is LOW, MODERATE, or HIGH (NIST FIPS 199). A subtle but important rule is the high water mark: a system inherits the highest impact value from among every information type it holds (NIST FIPS 199). A server that stores one HIGH-integrity data type is a HIGH-integrity system, full stop, even if everything else on it is trivial. That single rule prevents the most common criticality error: averaging a system down to “medium” because most of what it does is mundane.

The weakness of FIPS 199 is that it is human work with no numeric sort order built in. It does not hand you a 1-to-10 queue; it hands you a defensible category and a rationale. That is exactly backwards from the scanner rating, which gives you a sortable number with a weak rationale. FIPS 199 also does not populate itself: someone has to categorize each system, which is the same labor problem the CMDB field has. What it buys you is recognition. When a PCI, SOC 2, or SOX auditor asks why an asset was treated as low priority, “it categorizes LOW for availability under FIPS 199 because an outage causes only limited adverse effect” is an answer built from a standard, not from a tool’s opinion.

Which approach should drive your program?

None of them alone, and the comparison chart makes the reason visible. Each approach scores Strong on some dimensions and Gap on others, and the gaps do not overlap: the scanner rating is strong exactly where the CMDB and FIPS 199 are weak (numeric, automatic) and weak exactly where they are strong (coverage, audit standing).

Comparison matrix of Tenable ACR, ServiceNow CMDB business_criticality, and NIST FIPS 199 across five dimensions: numeric sortable output, set automatically, reflects business impact, covers assets not in the scanner, and auditor-recognized as a method. No approach scores Strong on all five.

Read across the rows and the layering strategy writes itself. Let the scanner rating do the fast triage sort for everything it can see. Let the CMDB tier carry the business owner’s voice and extend criticality to assets the scanner never touches. Let FIPS 199 supply the impact rationale that survives an audit. The single number you act on should be the reconciliation of all three, not any one of them treated as ground truth. Where they disagree, the disagreement itself is a finding worth logging.

What to do about it

Inventory first, criticality second. Establish and maintain an accurate inventory of all enterprise assets, recording owner and department for each, and review it at least bi-annually (CIS Control 1). You cannot rate what you have not listed.
Pull your scanner ratings and read the bands, not just the numbers. Confirm which assets have no rating at all, because those are your coverage blind spots, not your low-criticality assets.
Audit your CMDB business_criticality field for emptiness. Run a report of production service and application CIs with the field blank; treat every blank as an open task, not a “low” default (ServiceNow reference: cmdb_ci_appl).
Assign a FIPS 199 category to every system that touches regulated or business-critical data, applying the high water mark so a single sensitive data type sets the level (NIST FIPS 199).
Reconcile the three for your top-tier assets. Where the scanner says Low but the CMDB owner says most critical, the owner wins and the ACR gets a manual override (Tenable: Vulnerabilities by ACR).
Write the rationale down at the point of decision. A dated criticality record with an owner and a FIPS 199 category is the evidence that turns a deferral from a guess into a documented decision.
Re-validate quarterly with the business. Criticality drifts as services launch and retire; a stale tier is as useless to an auditor as a blank one.

Frequently asked questions

What is Tenable ACR and how is it scored? Asset Criticality Rating is Tenable’s integer rating of how critical an asset is to the business, banded as Critical 9-10, High 7-8, Medium 4-6, and Low 1-3, derived from signals like business purpose, asset type, location, and connectivity (Tenable Exposure Management metrics).

Is business_criticality on the base cmdb_ci table in ServiceNow? No. In a standard instance it lives on service and application CI classes, not the base cmdb_ci table; teams that need it everywhere add a custom field (ServiceNow community).

What are the ServiceNow business criticality values? On service and application CIs the tiers are 1 - most critical, 2 - somewhat critical, 3 - less critical, and 4 - not critical, and the field defaults to empty (ServiceNow developer community).

What are the three FIPS 199 impact levels? LOW is a limited adverse effect, MODERATE is a serious adverse effect, and HIGH is a severe or catastrophic adverse effect on operations, assets, or individuals (NIST FIPS 199).

What is the FIPS 199 high water mark? A system inherits the highest impact value from among every information type it holds, so one HIGH data type sets the whole system to HIGH for that objective (NIST FIPS 199).

Can a scanner rating replace a CMDB criticality field? No; a scanner rating only covers assets it sees and infers importance, while a CMDB tier is owner-set and can cover any CI (Tenable: Vulnerabilities by ACR).

Which asset criticality approach do auditors accept? A documented method with a rationale: FIPS 199 is a formal standard, a populated and reviewed CMDB tier is an accepted process, and a raw scanner score is an input rather than a standalone justification (NIST FIPS 199).

This connects directly to defending a risk-based program overall, which we covered in the audit-defensibility SOP for risk-based patching. Asset criticality is the field that SOP leans on hardest, so getting it right is the difference between a documented decision and a shrug. For more on the tooling side, see the tools comparisons pillar.

Sources

#asset-criticality #cmdb #tenable-acr #fips-199 #vulnerability-prioritization

Published August 19, 2026.