NIST CSF Identify function explained

What the NIST CSF Identify function requires and where to start

Your customer or contract wants proof of CSF 2.0 alignment, and the Identify Function is where that work starts. In the CSF 2.0 Reference Tool export, Identify has 3 Categories, 21 Subcategories and 74 Implementation Examples. The organization owns every outcome, and only an independent assessor can issue a report on them. NIST does not offer certifications or conformity assessments for CSF, so any document claiming CSF certification is a warning sign.

The effort depends on three things you can measure before any work starts: the size of your estate (how many systems, facilities, cloud accounts and business processes you run), the number of suppliers whose services you rely on, and how much inventory material already exists. A team with a maintained configuration database and a current supplier register starts far ahead of one that keeps its records in email and personal spreadsheets. Ask your team to confirm which sources are authoritative for hardware, software, data and supplier services, and where they disagree.

Begin with the basics NIST suggests in SP 1299: list your critical business processes, then build inventories of hardware, software, services and systems, including supplier services and personal devices where staff use them for work. Map how information moves between these components, then record the risks you find in a risk register. An inventory can start as a spreadsheet, but it must be complete enough that an assessor can sample it and trace each entry to a real asset. Plan for ongoing upkeep from the start, because a snapshot taken for an audit goes stale quickly.

Asset management, risk assessment and Improvement: the three Identify Categories

The Identify Function in CSF 2.0 has three Categories: Asset Management, Risk Assessment and Improvement. Together they answer what the organization owns, what could hurt it and how the program learns from what it finds, which is why each card below is worth checking before you start mapping controls.

Asset management (ID.AM)

Seven Subcategories cover inventories of hardware, software, services, supplier services and data, plus network and data flow maps, prioritization and life cycle management. Start with a plain inventory of systems and services, including supplier-hosted services and personal devices where staff use them for work. Then document where data moves between systems, because a missing flow is the most common gap an assessor finds. Confirm who owns each inventory and how often it is reconciled against what is actually running.

Risk assessment (ID.RA)

Ten Subcategories address vulnerabilities, threat intelligence, likelihood and impact, inherent risk, risk response, change and exception management, vulnerability disclosure, authenticity checks and supplier assessment. Record each risk in a register with an owner, a likelihood and impact estimate, and a chosen response such as accept, mitigate, transfer or avoid. Treat change and exception requests as risk events, not paperwork. Confirm that the register is reviewed on a set schedule and that exceptions expire rather than persist.

Supplier risk in assessments

Within risk assessment, the supplier-related Subcategories ask the organization to identify the risk that comes from the services and products it depends on. Illustratively, a payroll provider that holds employee records belongs in the asset inventory and in the risk register with its own response. Check that each critical supplier is listed with the data it touches, the contract clauses that cover security, and the evidence you will request. This feeds the Govern Function's supply chain Category, so keep the two records consistent.

Improvement (ID.IM)

Four Subcategories are new to Identify in CSF 2.0 and cover improvements drawn from evaluations, tests, exercises and daily operations, along with maintaining incident response and other operational plans. Log each finding from a test or post-incident review, assign it an owner and track it to closure. Keep response plans current by reviewing them after exercises. Confirm that open improvements are reported to leadership and that plans show a revision date and approver.

Changes from CSF 1.1

Identify gained the Improvement Category in CSF 2.0, while much of the earlier Identify content on governance moved to the Govern Function. NIST's transition spreadsheet maps CSF 1.1 Core items to their 2.0 locations, which is the fastest way to see what moved, what was split and what is new. Use it before reusing an older Identify assessment, since a mapped item may now sit under a different Category and need new evidence.

Which inventories and registers NIST suggests you build first

The sequence SP 1299 suggests for IDENTIFY moves from business priorities to the assets that support them, then to the data paths between those assets, and finally to a risk register that records what could go wrong and what you decided to do about it. Each step produces a record an assessor can later sample against your claimed outcomes.

Identify critical business processes first
Start by listing the business processes that matter most to the organization, such as payments, patient records, production scheduling or customer support. Leadership or process owners should confirm the list, because every later inventory is judged by whether it supports these processes. Record each process with its owner and the systems it depends on. The step is done when every critical process has a named owner and a short list of supporting systems that the business agrees is complete enough to act on. An assessor will ask to see this list and trace a sample process to the asset records below it.
Build the hardware inventory
Create a record of the physical devices that connect to or store organizational data, including servers, network equipment, endpoints, mobile devices and facilities-related systems where they matter to a critical process. IT operations usually owns this, with input from the process owners. Include a unique identifier, location, owner and the critical process each device supports. The step is complete when a reconciliation against network discovery, directory or cloud records finds no unexplained devices. Ask the assessor's likely question: can you show how a device that appears on the network is traced back to a named owner?
Build the software and system inventory
List the applications, operating systems, platforms and the systems that combine them, with version, vendor, owner, hosting location and the data classes each holds. For self-hosted open-source platforms, include the version and the component stack, since patching and vulnerability work depends on it. The step is done when every system tied to a critical process appears once, with an owner and a lifecycle status. Evidence is the exported register and the date of its last reconciliation.
Inventory services, supplier services and personal devices
Extend the inventory to externally provided services, including cloud platforms, managed providers, software-as-a-service tools and any supplier that holds or processes organizational data. SP 1299 notes that a spreadsheet can be enough at this stage, and it also covers personal devices used for work. Record the service, the contract owner, the data involved and whether the supplier's controls have been reviewed. The step is complete when each supplier entry links to a contract or due diligence record. Confirm with your legal or procurement team where those records are kept, because supplier evidence often sits outside IT.
Document information flows
Map how data moves between the inventoried systems, suppliers and users: where it is created, where it is stored, who or what it passes through, and where it leaves the organization. Draw the flows for each critical process and mark the points where sensitive data crosses a trust boundary. Owners of the processes should review the maps against how work is actually done, not only against the architecture diagrams. The step is done when each critical process has a current flow diagram tied to inventory identifiers. An assessor often samples one flow and asks you to show every system and supplier it touches.
Record risks in a risk register
Use the process, asset and flow records to write down the cybersecurity risks each critical process faces, such as an unpatched system, a supplier outage or an exposed data store. For each risk, record the affected assets, the likelihood and impact as estimated by the owner, the current controls, and the chosen response: accept, mitigate, transfer or avoid. Link each entry back to its asset and process identifiers. NIST's ERM and business impact analysis resources in the CSF materials can guide the method. The step is complete when the register is reviewed by the risk owner and the response decisions are signed off at the level your governance requires.
Confirm the records stay current
Set a review routine for the inventories, flow maps and risk register, and record who performs each review and what changed. Changes to systems, suppliers or processes should trigger an update to the affected records, and the register should note when a risk is closed or accepted. Keep dated versions so an assessor can see how the records changed over time. The step is done when the change log and review sign-offs exist for the most recent cycle. Ask your assessor what they expect to see for currency, because expectations differ between self-assessment, internal audit and independent review.

What Identify means for the executive, the compliance lead and procurement

Identify is the Function that tells leadership what the organization is exposed to: which assets, data flows, suppliers and risks matter most. Executives rarely need the inventory itself, but they do need to know whether it exists, who maintains it, and whether the risk register feeds funding decisions. Budget and deadline questions depend on the current state, which is why the first question is usually a baseline rather than a project plan. NIST does not publish cost or duration figures for Identify work, so any number has to come from the organization's own scoping and vendor quotes.

Budget questions: Ask what is one-time (initial discovery, tooling, first risk assessment) and what recurs (inventory upkeep, reassessment, staff time).
Deadline questions: Ask which contractual or regulatory date drives the work and whether the first milestone is a baseline, not full coverage.
Board view: Expect a short summary of asset coverage gaps, open risks by owner, and the status of the improvement actions that come out of assessments.
Decision rights: Confirm who accepts each risk and who can stop a system from going live when its risk is unrecorded.
Limits: Ask for independent assessment when leadership needs assurance, since internal reporting does not replace it.

Before approving any budget, confirm that the proposed scope names the asset classes, business units and suppliers it covers.

What must exist before an Identify assessment starts

An assessor testing the Identify Function starts from records, not interviews. The six cards below are the artifacts NIST points to as the starting point for ID.AM, ID.RA and ID.IM, and each one should exist and be current before anyone schedules fieldwork.

Current asset inventory with owners

A list of hardware, software, systems, facilities and data stores, each with a named owner and a last-reviewed date. NIST notes this can begin as a simple spreadsheet, but it must cover personal devices and supplier-hosted services too. To check it, pick a sample of production hosts from the network and confirm each appears in the inventory with an owner. An assessor will sample gaps between live systems and the list.

Documented critical services

A short register of the business processes and services the organization cannot run without, with the systems each one depends on. SP 1299 suggests identifying critical business processes first because later risk decisions and recovery priorities depend on them. Check that each critical service names its dependencies and that the list was approved by someone accountable for the business process. An assessor will ask how each critical service was chosen and when it was last reviewed.

Maintained risk register

A register that records each identified cybersecurity risk with its likelihood, impact, owner, response and status. The Risk Assessment category expects risks to be tied to threats, vulnerabilities and business impact rather than listed as generic concerns. Check that risks link back to assets and critical services and that closed risks show how they were resolved. An assessor will sample entries and trace each one to an asset and a decision.

Data flow records for sensitive data

Diagrams or tables showing where sensitive data is created, stored, processed and transmitted, including links to external services and backups. These records support the asset management outcomes on network and data flow mapping. Check that flows cross-reference the inventory and that each external recipient is named. An assessor will pick one sensitive data type and follow it from entry point to storage to deletion.

Supplier service inventory

A list of the external services, cloud providers, managed service providers and software suppliers the organization relies on, with what each one hosts or does and who is accountable for the relationship. NIST's guidance treats supplier services as part of the asset picture, so they belong in the inventory, not in a separate procurement file. Check that each supplier appears with a business owner and a contact for security incidents. An assessor will compare the supplier list against outbound data flows and billing records to find services nobody recorded.

Dated record of improvement actions

A log of improvements drawn from audits, tests, exercises, incidents and routine operations, each with an owner, a due date and a closure note. The Improvement Category asks the organization to act on lessons learned and to keep its response plans current. Check that entries have dates and that completed actions show evidence of completion. An assessor will look for the most recent exercise or incident and confirm that its findings appear here.

How an assessor tests Identify and what the Implementation Examples show

CSF 2.0 has no certification, so nobody issues a pass mark for Identify. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services and has no plans for a conformity assessment program. An assessment of Identify is therefore a gap analysis, a self-assessment or an independent assessment, and the organization decides which one answers the question its customer, board or regulator is asking. A gap analysis compares the Current Profile with the Target Profile, a self-assessment is run by the organization against the Subcategories, and an independent assessment is bought from an outside firm that reports its own findings. Before any of these starts, confirm in writing who sets the scope, which assets and suppliers are in it, and what evidence the assessor will accept.

The Reference Tool export lists 363 Implementation Examples across the Core, and the ones for ID.IM-01 show how an assessor can test the Improvement Subcategory. The examples name three approaches: self-assessments of critical services, investment in third-party assessments or independent audits of the cybersecurity program, and automated evaluation of compliance with selected requirements. Use the export at the NIST CSF 2.0 Reference Tool download to read the exact example text for ID.IM-01, since the examples are published online and can change more often than CSWP 29.

For an assessment file, the practical test is whether the organization can show that a self-assessment or audit produced a dated list of improvements and that someone owns each one. Ask the assessor which evidence they will sample: the scope of each critical service assessment, the audit report or findings log, the tool configuration and output for any automated checks, and the tracked remediation items with closure dates. Automated evaluation only counts if the reader can explain which requirements the tool checks and how results are reviewed. Confirm these expectations with the assessor before fieldwork rather than after.

Who is paid for Identify work and what drives each cost

This table compares the six cost components of Identify work by who is paid, whether the cost is one-time or recurring, and what pushes it up or down. Read it as a checklist for a quote: each row names a line item to ask about. The main takeaway is that inventories and risk registers are built once but must be kept current, so the recurring review effort is often the larger long-term cost.

Cost component	Who is paid	One-time or recurring, and what drives it
Internal staff time	Your own staff (salary cost, not a fee)	Both. Owners of assets, data flows and risks must confirm entries, and the effort grows with the number of systems, business processes and business units in scope.
Implementation partner for inventories and registers	External consultant or partner, under a fixed-scope written agreement	Mostly one-time. Drivers are the number of asset classes, the state of existing records, the number of data flows to map and whether a risk register is built from scratch. Ask for the deliverables list and the inventory fields.
Tooling, including self-hosted open-source options	Software vendor or hosting provider for commercial tools; internal or partner staff for self-hosted open-source deployment	Both. Licenses and hosting recur, while setup and integration are one-time. Drivers are asset discovery coverage, integration with existing systems and whether the tool runs inside your own infrastructure. Confirm which features the product actually provides before buying.
Independent assessor	Independent auditor or assessor, not DeployOpen or the implementation partner	Typically periodic. Drivers are the scope of the assessment, the depth of testing and whether the assessment is an independent audit of the program. Ask how the assessor will test the inventories and risk register.
Recurring review effort	Your own staff, plus any partner retained for ongoing support	Recurring. Drivers are how often inventories are reviewed, how fast assets and suppliers change, and how many risks are re-scored. Ask for the review cadence and who owns each update in the proposal.

Who owns Identify controls, who prepares evidence and who assesses

Your team owns every Identify outcome. NIST's CSF 2.0 framework is voluntary and NIST does not certify anyone, so the organization is accountable for deciding what its critical business processes are, which assets matter, which risks it accepts and which improvements it funds. A partner can draft an inventory, but leadership must approve the scope, the risk criteria and any decision to accept a residual risk.

Decisions on scope: Confirm which business services, systems, sites and supplier services fall inside the Identify inventory and risk assessment.
Risk acceptance: Record who signs off on each accepted risk in the risk register, at what level, and when it is reviewed.
Asset ownership: Name an accountable owner for each asset category so that inventory records stay current after the project ends.
Improvement decisions: Decide which findings from ID.IM self-assessments, tests and incidents become funded actions.
Policy and resourcing: Approve the policies and budget that make Identify records routine rather than a one-time exercise.

Before engaging anyone, confirm that a named executive owns the Identify outcomes and that your own staff can maintain the records once a partner has handed them over.

What usually stalls Identify work and how to avoid it

Identify work rarely fails because the framework is hard to follow. It stalls when the inventories, flow records and risk registers that Identify depends on go stale, lack owners or stay on paper. The cards below cover the failure points that come up most often and a practical fix for each.

Inventories built once and never maintained

A hardware and software list compiled for an audit goes stale within weeks as systems are added, retired or moved to new hosts. Identify expects inventories to reflect what is running today, so an outdated list gives the wrong picture for every later Protect and Detect decision. Fix it by tying inventory updates to change tickets and onboarding steps, and by checking the list against a live discovery scan on a fixed schedule. Ask who signs off each update and where the record lives. A spreadsheet is acceptable only if someone is accountable for keeping it current.

Shadow IT and personal devices missing

Software-as-a-service accounts bought by business teams and personal devices used for work often never reach the central inventory. NIST's suggested starting point explicitly includes supplier services and personal devices, so gaps here weaken the whole asset picture. Fix it by reviewing expense records and identity provider logs for unmanaged applications, and by setting a clear rule that any system holding company data must be registered. Confirm with business unit leads which tools they use outside procurement.

Data flows left undocumented

Teams often know where their own systems sit but not how data moves between them, including transfers to processors, backups and partner interfaces. Without flow records, risk assessments miss the paths an attacker or a failed integration would use. Fix it by mapping flows for each critical business process, starting with the data that carries the most regulatory or contractual weight. Ask each process owner to name every system that receives the data and every external party that touches it.

Risk registers without owners

A risk register that lists threats but names no accountable owner tends to stay static, because nobody is responsible for reviewing treatment decisions. Identify's risk assessment outcomes call for recording likelihood, impact and response, and those entries only mean something when a named person decides on them. Fix it by assigning one owner per risk, setting a review date, and recording the decision taken, whether that is accept, mitigate, transfer or avoid. Check that owners have the authority and budget to act on what they own.

Treating Identify as a document exercise

Teams sometimes produce a policy, an asset list and a risk table for an assessment and then stop, so the outputs never feed decisions. NIST frames Identify as understanding current risk and improving practice across all six Functions, and the Improvement Category expects lessons from tests, exercises and incidents to change the records. Fix it by scheduling a review of inventories and risks after each significant test or incident, and by tracking the changes made as a result. Ask whether the last exercise altered any asset record or risk entry.

Common questions about the NIST CSF Identify function

Can we do the NIST CSF Identify function in-house?

Yes, most organizations start Identify with their own staff, because the core work is knowing your own assets, processes, data flows and risks. NIST's SP 1299 suggests that inventories can be as simple as a spreadsheet, and it lists supplier services and personal devices among the things to record. The harder parts are usually the ones that need time and access across teams: agreeing which processes are critical, mapping how data moves between systems, and keeping the risk register current. Organizations often bring in an outside party for an independent view of the program or to build the tooling, but the organization still owns its risk decisions. Confirm with your own leadership which parts your team can sustain after the first pass.

How much effort does a CSF asset inventory take, and what drives it?

The effort depends mainly on how many systems, cloud accounts, facilities, suppliers and devices you have, how fragmented your ownership records are, and whether discovery tools already exist. An illustrative case: a single-site organization with one data center and a few business applications can usually build a first list through interviews and existing records, while a multi-region organization with many cloud accounts needs automated discovery and owner sign-off for each asset. Costs fall into staff time for the people who own each system, tooling for discovery, and ongoing upkeep as assets change. Ask any provider to break the quote into discovery, validation, data flow mapping and risk register setup, and to state what is one-time and what must be maintained each quarter.

Is there a NIST CSF certification I can get for Identify?

No. 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 organization that claims CSF certification, or a certified Identify rating, should be asked which independent body issued it and against what published criteria. In practice, buyers ask for a self-assessment against the Identify Categories, an independent assessment of the cybersecurity program, or evidence mapped to another standard they already use. Where a customer requires a formal attestation, that attestation has to come from an independent auditor or assessor, not from the implementation partner.

What does the Identify function need from our team?

Identify needs named owners who can answer for systems, data and suppliers, along with access to configuration records, network diagrams and contract files. Risk and business leaders must agree on critical processes and risk tolerance, because asset priorities and risk ratings depend on those choices. Your security or IT team usually runs the discovery and keeps records accurate, while legal and procurement supply contract and supplier information. Plan for regular review meetings so the improvement work under ID.IM stays current. Before starting, confirm who signs off on the inventory and who will update it when systems change.

How does the Identify function relate to ISO 27001?

Identify overlaps with ISO/IEC 27001:2022 in areas such as asset inventories, risk assessment and continual improvement, but the two frameworks are built differently. The CSF organizes outcomes into Functions and Categories and is voluntary, while ISO 27001 is a management system standard that can be certified by an accredited certification body. Many organizations use an existing ISO 27001 asset register and risk process as evidence for ID.AM and ID.RA, then add CSF-specific outcomes such as supplier risk and improvement tracking. Any mapping between the two should be built and checked by your team or an advisor, not assumed from titles. Confirm with your auditor how they will accept shared evidence.

Can we assess a supplier's Identify practices?

Yes. Identify includes supplier services in asset management and supplier-related risks in risk assessment, so you can ask a supplier for evidence that they keep their own inventories, document data flows and maintain risk registers. In practice, buyers request a questionnaire, a recent independent report or certificate, and evidence of how the supplier reviews its own risks. The Identify outcomes are a reasonable checklist, but the supplier's governance and supply chain practices sit mostly under the Govern Function. Ask suppliers to state which parts of their environment are in scope, and verify important claims through independent assessment rather than self-reporting alone.

How DeployOpen prepares Identify evidence in your environment

DeployOpen works inside your own infrastructure to build the asset inventories, data flow records and risk register that the Identify Function calls for. The organization keeps ownership of its risk decisions, and DeployOpen prepares the systems and documented evidence that show how those decisions were supported.

How we scope

Engagements are fixed-scope, with the Identify deliverables, systems and locations agreed in writing before work starts.
The written scope names which asset classes are covered, such as hardware, software, services, supplier services and personal devices.
Scope also states which critical business processes and information flows the inventories and data flow records will describe.

How we build

Inventories are generated from your cloud accounts, data centers or air-gapped networks, then reviewed with your asset owners.
Data flow records and network maps are drafted from the systems in scope, with gaps flagged for your teams to confirm.
Risk register entries are structured so each risk links to an owner, an asset and a recorded response.

How we hand over

You receive the inventories, data flow records, risk register and supporting procedures in formats your team can maintain.
Documentation explains how each artifact was produced, so an internal team or an independent assessor can repeat the steps.
Your organization decides what to accept, what to fund and what to report to leadership. DeployOpen does not issue audit reports or certifications.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, which can keep inventories current as systems change.
Retainer scope, response expectations and review cadence are written into the agreement, so you can confirm them before signing.
Improvement findings from tests and exercises can feed back into the register, supporting the Improvement Category of Identify.