ID.AM-05 Asset prioritization: requirements and evidence

What ID.AM-05 asks you to prioritize and why assessors check it

If a gap analysis or audit request names ID.AM-05, the outcome you need to show is that your assets are ranked by classification, criticality, resources and impact on the mission. The subcategory asks whether the organization can say, before an incident, which systems matter most and why. Without that ranking, scarce response and recovery effort tends to flow to whichever system is loudest or most familiar, while a payroll database, a clinical record system or a production control server waits in the queue. Assessors check ID.AM-05 because it is the point where the inventories from the other ID.AM subcategories become decisions about where to spend people and time first.

NIST CSF 2.0 is a voluntary framework and NIST does not offer certification of it, so no one issues a pass or fail for ID.AM-05. The test is the organization's own evidence. An assessor will ask for the written prioritization criteria, the asset classes they apply to, the ranked list that results and the record showing who approved it. The three NIST Implementation Examples for this subcategory point the same way: define criteria for each class of asset, apply them, and revisit the ranking periodically or after significant change. Confirm the current wording of those examples in the NIST CSF 2.0 Reference Tool before you build your evidence set around them.

Two things usually make this hard. The first is that criteria were never written down, so each team ranks assets by its own logic and the result cannot be repeated or explained. The second is that priorities go stale. A reorganization moves ownership, a new cloud service takes over a workload, or an acquisition brings in systems nobody has classified, and the ranking still reflects the old structure. A practical first step is to ask your asset owners for the criteria they actually use, compare them, and agree on one scheme with a named owner and a review trigger tied to reorganizations and new services.

Which assets, teams and third parties fall under ID.AM-05 priorities

Before anyone can rank assets, the organization has to decide what enters the ranking. Each of the decisions below changes how many assets, owners and external services must be classified and rated, so the scope agreed at the start determines the workload more than any later step.

Asset classes that receive a priority

ID.AM-05 asks for assets to be ranked, so the first decision is which classes sit in the ranking: hardware, software, services, data and supplier services. Ranking only servers and applications leaves data stores and third-party platforms unranked, even when they carry the most sensitive records. Adding data classes usually adds the most work, because data often has no single owner. Confirm the list with your asset owners and record which classes are excluded and why.

OT, IoT and cloud in one ranking

Decide whether operational technology, IoT devices and cloud workloads share one priority scale with corporate IT. A single scale allows direct comparison of a plant controller against a payroll system, but operational owners may rate criticality differently and need separate criteria. Separate rankings are simpler to maintain but can hide dependencies that cross the boundary. Confirm with plant, facilities and cloud platform teams before drafting criteria.

Business owners who agree mission impact

Mission-impact ratings need sign-off from the people who understand what a system does for revenue, safety, patient care or regulated services. IT alone tends to rate assets by technical attributes, which can misstate impact. Name an accountable owner for each business process, record who approved each rating, and set how disagreements are escalated. The number of owners involved is a direct driver of effort, so confirm the list early.

Externally hosted services in the ranking

Software-as-a-service, infrastructure hosted by a provider and third-party APIs can support critical processes even though the organization does not run them. Including them means recording the provider relationship, the data held there and the impact of an outage. Excluding them leaves gaps in the ranking that match the gaps in supplier oversight. Confirm which external services have been inventoried under ID.AM-04 before deciding how far the ranking extends.

Scope changes after restructuring

Mergers, divisions, new business units and outsourcing change which assets belong to the organization and who owns them. Each change can move assets between rankings, orphan ratings or create duplicate records. Decide who updates the ranking when a structure changes, how quickly, and whether new units inherit existing criteria. Confirm the trigger with HR, legal and business leadership, because restructuring often happens before IT learns about it.

How to define criteria for each asset class without guessing

Asset prioritization only works when the four factors named in ID.AM-05 (classification, criticality, resources and mission impact) become ratings that someone can apply consistently. Start by choosing a short scale, such as three or four levels, for each factor and each asset class. Write one sentence per level that describes what it looks like in practice. For example, a level for mission impact might say that loss of the asset stops a customer-facing payment or regulated reporting process. Keep the scale small enough that two people rating the same server reach the same answer. Each asset class (endpoints, servers, cloud workloads, SaaS, OT devices, and data sets) needs its own definitions, because a laptop and a production database do not fail in the same way.

Every rating needs a named owner. The business owner of a system usually sets mission impact and criticality, the data owner sets classification, and the platform or IT team supplies the resource dependencies such as recovery time, licensing, staff and capacity. Record who set each rating and when, so the decision can be audited. The inputs come from the inventories you already maintain: hardware records from ID.AM-01, software and service records from ID.AM-02, supplier services from ID.AM-04 and data classifications from ID.AM-07. Confirm that those inventories carry the fields you need before you design the scale, because a rating cannot be better than the record it sits on. Compare your method with the risk assessment controls RA-2, RA-3 and RA-9 in NIST SP 800-53 Rev. 5.2.0, which the CSF 2.0 Reference Tool lists as informative references for ID.AM-05. Check whether your existing risk method already defines impact and categorization, so that you reuse those scales rather than creating a parallel set.

The ranking has to change what happens. Use the top tiers to decide what gets continuous monitoring first, which findings from vulnerability scanning are patched first, and which systems are restored first after an incident. Translate each tier into a rule your teams can run, for example a required scan frequency or a recovery order listed in the recovery plan. Review the ratings when the organization changes, such as after a merger, a new regulated product, or a move of a workload to a new cloud account, because the Implementation Examples for ID.AM-05 call for periodic updates and updates after significant change. As an exercise, pick ten assets from different classes and ask two owners to rate them independently. Where the ratings differ, the criteria need clearer wording before you publish them.

How to implement asset prioritization in six steps

This sequence turns a raw asset list into an approved, owned ranking that drives monitoring, patching and recovery order, and that gets revisited when the organization changes. Each step produces a record you can show an assessor.

Start from the approved asset inventory
Take the hardware, software, services and data inventories from the ID.AM-01 through ID.AM-04 work as the starting list, and confirm that each entry has an identifier, a business owner and a location. Remove duplicates and flag entries with no owner. The output is a single working list that the team agrees is complete enough to rank, with known gaps recorded as open items rather than silently dropped.
Define prioritization criteria for each asset class
Write down the criteria you will use to rank each class of asset, such as servers, endpoints, network devices, SaaS applications, data stores and OT equipment. Criteria should cover classification of the data handled, criticality to business processes, the resources the asset consumes or depends on, and the impact on the mission if it fails or is compromised. The output is a short criteria document approved by the risk owner, with each criterion written so two people would score the same asset the same way.
Assign each asset a priority tier and owner
Apply the approved criteria to every asset on the list and place it in a defined tier, for example a small number of tiers that you name and describe in the criteria document. Record a named owner for each asset who can accept the tier and answer for changes to it. The output is a tiered register where every asset has both a tier and an accountable person, and where exceptions are listed with the reason they were approved.
Connect tiers to monitoring, patching and recovery
Map each tier to the operational practices that depend on it: which assets receive the most detailed monitoring, which are patched first and within which change windows, and which are restored first after an incident. Confirm the mapping with the teams that run those processes. The output is a short table linking tiers to monitoring scope, patch priority and recovery order, which the incident response and vulnerability management plans can reference directly.
Set review triggers for periodic and change-driven updates
Define the events that force a re-ranking, such as a new system going live, a change in what data an asset processes, a merger or divestiture, a material incident, or a change to the criteria themselves, along with the scheduled review cycle you adopt. Assign who runs each review. The output is a written update procedure that states the triggers and the reviewer for each, so that the ranking stays current instead of reflecting the state of a single year.
Record the first approved ranking
Bring the criteria, tiered register, owner assignments, operational mappings and update procedure to the body that governs cybersecurity risk, and record its approval with the date and version. Store the approved ranking in your asset management or GRC system so it can be exported as evidence. The output is a versioned, approved ranking that serves as the baseline for the next review and as the evidence an independent assessor would ask to see.

How an assessor tests ID.AM-05 and what they ask to see

This table compares what an assessor checks for each part of ID.AM-05, the evidence they request, how they select samples and the findings that appear most often. Read it as a checklist: if the criteria, rankings, change records and downstream uses cannot be shown together, the Subcategory is hard to support.

Test area	What the assessor checks	Evidence requested	Common findings
Documented criteria	Whether prioritization criteria are defined for each asset class, covering classification, criticality, resources and mission impact	Criteria document or standard with asset classes, scoring factors, owners and approval date	Criteria exist in a policy but no class-level definitions; factors are named but not weighted or explained
Applied ranking	Whether the current asset list is ranked using those criteria, and whether the ranking matches the documented method	Ranked asset inventory with the criteria value recorded for each asset, plus the scoring worksheet	Criteria exist but are not applied; rankings are assigned by intuition or by whoever filled in the inventory
Sample across asset classes	Whether assets from each class (for example servers, endpoints, cloud workloads, OT devices and key applications) carry a priority that follows the criteria	Sample of assets from each class with classification, criticality rating, resource and mission impact notes	High-value assets sorted correctly while one class, such as OT or cloud, has no priority or a default value
Ownership of priorities	Whether each prioritized asset has a named owner who can confirm or change its rating	Owner field in the inventory and records of owner review	Assets with no owner, or owners who have never reviewed the rating
Updates over time	Whether priorities are reviewed on a stated schedule and after significant organizational change, such as mergers, new business lines or new regulated services	Review records, dated revisions to the ranking, and change tickets that trigger reprioritization	Rankings that predate major changes, with no record of re-review after reorganization, acquisition or new services
Use of priorities in other processes	Whether the ranking drives vulnerability handling, backup scope, monitoring coverage, recovery order or resource allocation	Examples where the ranking changed a patch window, monitoring scope, backup schedule or response order	Ranking is maintained as a spreadsheet and not referenced by any operational process
Consistency with related Subcategories	Whether priorities align with the hardware, software, data and supplier inventories and with the risk assessment	Cross-references between the ranked list and the inventories under ID.AM-01, ID.AM-02, ID.AM-04 and ID.AM-07	Ranked assets that do not appear in the inventory, or inventory items with no priority at all
Confirm before testing	Which parts of the criteria and ranking are owned by the organization and which are supplied by an implementation partner	Written roles for who sets criteria, who scores assets and who approves changes	Assessor cannot tell who approved a rating, so the record is treated as unsupported

Evidence that shows asset priorities are defined, applied and current

An assessor testing ID.AM-05 Asset prioritization looks for three things: written criteria, a ranking that follows them, and proof that the ranking was kept current. The cards below cover the artifacts that show each of these. Most of them are produced as a side effect of normal operations, so the work is keeping them dated, owned and linked to one another.

Written criteria per asset class

A short, approved document that defines each asset class (for example, customer-facing applications, internal databases, OT controllers, endpoints) and the rules used to rank it by classification, criticality, resources and mission impact. Each class should name the scoring factors, the scale used, and who can change a rule. To check it, confirm the criteria exist for every class in your inventories, not only the classes that were easy to define. Ask whether the criteria are tied to the data classification and business impact definitions used elsewhere in your risk program.

Ranked asset register with owners

An export from your asset management system (for example, GLPI Assets or a Wazuh-fed inventory) showing each asset, its class, its priority tier, a named owner and the date its priority was last set. The register is the primary artifact an assessor samples. Check that every high-priority asset traces to a record and that no asset is left unranked. Also confirm that owners are real people or roles who can answer questions, not shared mailboxes.

Business owner approval records

Signed or recorded confirmation from business owners that the priority assigned to their systems reflects mission impact. Approval can come through a ticketing workflow, meeting minutes or a sign-off form, but it should name the approver, the assets covered and the date. Assessors often ask who decided a system was low priority and whether that person had the authority to do so. Keep approvals with the register so the two can be compared during testing.

Priority-driven monitoring and patching

Evidence that priorities change what the organization does. Examples include vulnerability scan schedules that scan higher-priority assets more often, patch windows that address critical assets first, or monitoring rules that alert more aggressively on crown-jewel systems. Pull scan configurations, patch deployment reports and alert rules and show that they reference the priority field. A ranking that no operational process reads is a common finding, so this card is the proof that the ranking is applied.

Change-triggered review records

Records showing that priorities were reviewed after significant organizational change, such as a merger, a new regulated service, a major cloud migration or a change in the business impact of an outage. The NIST implementation examples for ID.AM-05 call for updates after significant change, so keep a log of triggers and the review that followed each one. Ask whether your change management process has a step that asks, for each change, whether any asset's priority needs to move.

Dated history of ranking updates

A versioned log of every change to an asset's priority, with the old value, the new value, the reason and the approver. This history answers the assessor question of whether priorities are updated periodically or only once. Confirm that your system keeps history rather than overwriting values, and that the periodic review cycle you set is visible in the log. A history that shows no changes for years can be as concerning as one that shows constant churn, so be ready to explain the review rhythm.

What prioritizing assets costs in tooling, effort and review

This table compares the cost components of building and keeping asset prioritization criteria in place, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to structure a quote request, since the license line can be zero for the open-source tools while staff time and hosting remain. The main takeaway is that most of the expense sits in people's time, which scales with the number of asset classes and how often the organization reorganizes.

Cost component	One-time or recurring	Who is paid or who spends time	What drives it up or down
Tooling or licenses	Recurring (license line may be zero)	Vendor or open-source project; hosting and admin staff	GLPI, Wazuh and CISO Assistant are open source under the licenses listed in the facts, so license cost can be zero. Hosting, storage and admin time still apply. Confirm any paid support or hosted option with the vendor.
Initial criteria workshops	One-time	Internal asset owners, IT, security and risk staff; any consultant facilitating	Number of asset classes, number of business units involved, and whether criteria already exist in a classification policy. Reusing existing data owner definitions shortens the work.
Asset-owner and engineering time for classification	One-time, then recurring as assets change	Internal asset owners and platform engineers tagging assets with classification, criticality and mission impact	Asset count and how much metadata is missing from current inventories. Inventories built from ID.AM-01 and ID.AM-02 reduce manual tagging.
Ongoing evidence upkeep	Recurring	Internal inventory and security operations staff; any managed service retainer	Frequency of priority reviews, rate of new assets, and whether the tooling pushes inventory automatically. Automated collection lowers manual effort.
Update work after organizational change	Recurring, event-driven	Asset owners, IT leadership and risk staff	Reorganization frequency, mergers, new product lines and cloud migrations. Each change may require reclassification, so a stable operating model keeps this cost down.
External review of criteria	Recurring or periodic	Independent consultant or internal audit reviewer	Scope of criteria, whether reviewers are internal or external, and how many classes the review covers. Ask for a fixed scope in writing.
Auditor sampling effort	Recurring at each assessment	Auditor or assessor (independent); internal staff producing samples	Number of assets sampled and how well records show the priority assigned and the date it was last reviewed. Clear, dated records reduce follow-up requests.

Using GLPI, Wazuh and CISO Assistant to hold priority data

ID.AM-05 asks for a ranking that reflects classification, criticality, resources and mission impact, and that stays current as the organization changes. The three tools below cover different parts of that job: one holds the asset register, one discovers what is actually running, and one records the criteria and review cycle against the framework. Confirm each tool's fields and licensing terms in your own environment before you design around them.

GLPI as the asset register

GLPI's Assets module manages computers, monitors, software, network equipment, peripherals, printers, phones and racks. Records can be entered manually or pushed automatically by the GLPI Agent, which is native inventory built into GLPI since version 10. Priority values need a home on each asset record, so check whether your version provides a criticality or priority field, or whether you must add one as a custom field. GLPI is licensed under GPL-3.0-or-later, which governs how you may modify and redistribute it.

Wazuh for discovery

The Wazuh Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups, and Windows updates from each endpoint. The data is stored in the Wazuh indexer and shown in dashboard inventory views and reports. Use it to check whether the asset list in your register matches what runs on the network, and to flag devices that appear without a priority. Wazuh is licensed under GPL-2.0-only. Confirm which asset classes your agents cover, since network and OT devices may need other sources.

CISO Assistant for criteria and reviews

CISO Assistant ships more than 200 frameworks, including NIST CSF, and runs audits and compliance assessments against them with automatic mapping between frameworks. It is a practical place to record the prioritization criteria for each asset class, the owner of each criterion, and the date of each review, so the ID.AM-05 evidence sits next to the framework outcome it supports. Confirm that your version supports the custom fields and review scheduling you need. CISO Assistant is licensed under AGPL-3.0-only, which applies to modified versions you make available over a network.

Who owns the priorities, who prepares the evidence and who tests it

Your organization owns the asset priorities. That means the prioritization criteria, the ratings applied to each asset and the final ranking are decisions made by staff who answer for the business outcome. ID.AM-05 asks that assets be ranked by classification, criticality, resources and impact on the mission, so the people who understand the mission and the data must set those criteria before any tool is configured.

Criteria owners: Define the rules for each asset class, such as what makes a system mission critical, and approve changes to those rules.
Asset owners: Rate the systems, data stores and services they are accountable for, and confirm the dependencies they rely on.
Security lead: Reviews the ranking, approves it and decides when a reprioritization is needed after a significant organizational change.
Records owner: Keeps dated approvals, meeting notes and version history of the criteria so the ranking can be traced over time.
Business continuity contact: Confirms that the top-ranked assets match recovery priorities in the continuity plan.

Confirm with your auditor which of these named roles and approval records they expect to sample.

Common questions about ID.AM-05 cost, effort and outsourcing

How long does asset prioritization take to set up?

No duration is published for ID.AM-05, so the time depends on your environment and the scope you agree. The main drivers are how many asset classes you need to rank, whether an asset inventory already exists (ID.AM-01 and ID.AM-02 feed the ranking), how many business owners must agree on criticality, and whether the mission impact of each system is already documented. An organization with a current inventory and named system owners will move faster than one that must build both first. Ask any partner for a phased schedule tied to the written scope, with each phase's inputs and sign-off named.

What does the work need from our team?

The work needs people who know the business, not only the technology. ID.AM-05 asks you to rank assets by classification, criticality, resources and mission impact, so you need owners who can state what each service does, what it depends on and what an outage costs. Security or IT staff will usually run the process and maintain the records, while business leaders approve the criteria. Plan time for workshops, for reviewing draft rankings and for agreeing the criteria for each asset class. Confirm the named owners and their availability before work starts.

Can we do asset prioritization in-house with open-source tools?

Yes, in part. Open-source tools can hold the inventory that prioritization depends on. GLPI's Assets module records computers, software, network equipment and other hardware, and it can receive automatic data from the GLPI Agent. Wazuh's Syscollector module collects hardware, software, open ports, services and other endpoint data for inventory views and reports. CISO Assistant can record assessments and map requirements between frameworks. None of these tools decides criticality for you. The ranking criteria, the owner sign-offs and the record of changes are organizational work. Confirm each tool's current capabilities in its documentation before you rely on it for a specific step.

What should a partner own, and what should we keep?

The organization owns its controls, so you keep the decisions. You should retain approval of the prioritization criteria, the final ranking of each asset class and the business sign-off for mission impact. A partner such as DeployOpen can prepare the systems and evidence: deploying and configuring the inventory and discovery tools, setting up the record of asset classes and ranks, documenting the process, and preparing the evidence an assessor will request. Neither the organization nor a partner issues an attestation. Only an independent auditor or assessor does. Write this split into the scope so each deliverable has one named owner.

Does NIST certify ID.AM-05 or the CSF?

No. NIST does not certify ID.AM-05, and it does not certify any organization against the CSF. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans to develop a conformity assessment program. Any claim of NIST certification for ID.AM-05 should be treated as a red flag. Organizations that need outside confirmation usually ask an independent assessor to review their CSF alignment and evidence, and that assessor's report is their own work product, not a NIST certificate. Ask your customer or regulator which form of assurance they accept before you commission anything.

How often do asset priorities need updating?

The NIST Implementation Examples for ID.AM-05 describe tracking and updating priorities periodically and after significant organizational change. NIST does not publish a fixed interval in the supplied material, so set one in your own policy and document it. Triggers that usually justify an early review include a new business service, a merger or divestiture, a major cloud migration, a change in regulatory scope, or a material incident. Ask your auditor or customer which review cycle they expect, because contracts and other frameworks may set their own interval.

What should we ask for in a written scope?

A written scope should name the asset classes in scope, the systems and sites covered, and the criteria your organization will use for each class. It should list the deliverables, such as the criteria document, the ranked register, the update procedure and the evidence pack, with an owner and a due point for each. Ask the partner to state what they will configure, what they will document, and what remains your responsibility. Include the change triggers that cause a re-ranking, the tools in scope and their deployment model, and how sign-off and handover work. Request a quote that follows directly from this scope, with recurring support listed separately from one-time work.

How DeployOpen scopes and prepares ID.AM-05 evidence

DeployOpen works on ID.AM-05 by preparing the systems and records that show how assets are ranked by classification, criticality, resources and mission impact. The organization keeps ownership of its priority criteria and decisions, and an independent assessor reviews the result.

How we scope

Agree in writing which asset classes, business units and platforms fall within the ID.AM-05 prioritization work.
Confirm who owns the criteria for each asset class, and who approves priority rankings inside the organization.
Define the systems in scope, such as GLPI or Wazuh deployments, and the sources of asset data they will feed.

How we build

Configure the asset inventory in GLPI so each asset carries classification, owner and criticality fields for ranking.
Connect Wazuh Syscollector inventory data to the same records so priority reflects what is actually deployed.
Set up CISO Assistant to hold ID.AM-05 control mappings, assessment records and review dates for each priority decision.

How we hand over

Deliver the written prioritization criteria for each asset class, along with the configuration that enforces them.
Provide the ranked inventory exports, change logs and review records that the organization can show to an assessor.
Document the periodic and change-triggered update procedure, with named owners and the evidence each update produces.

How we support

Offer ongoing support and periodic reviews of priority rankings as the organization changes, available as a retainer.
Assist with questions from internal auditors or an independent assessor about how the ranking was produced.
Confirm with the organization any changes to ID.AM-05 mappings in the NIST CSF 2.0 Reference Tool before updating records.

ID.AM-05 Asset prioritization