NIST CSF 2.0Implementation GuideJune 13, 2026· 13 min read
How to Implement the NIST CSF 2.0 Identify Function: A Practitioner's Guide
You cannot protect what you don't know you have. The Identify function is the foundation of every mature security program - it covers asset management, risk assessment, and continuous improvement. This guide breaks down all three ID categories with practical implementation steps for organizations at every stage. (First step: discover you have 40% more assets than anyone thought. This is normal. This is also concerning.)
What the Identify Function Covers
In CSF 2.0, the Identify function has three categories: ID.AM (Asset Management), ID.RA (Risk Assessment), and ID.IM (Improvement). CSF 1.1 had four categories in Identify - CSF 2.0 reorganized them, moving Business Environment (ID.BE) content into the new Govern function and renaming Risk Assessment to align more clearly with its purpose.
The Identify function answers three foundational questions: What do you have? (ID.AM) What are the risks to what you have? (ID.RA) What are you doing to get better based on what you learn? (ID.IM). The answers to these questions shape every other function in the framework.
Implementation principle: Identify work is never done. Asset inventories get stale, risks change, and lessons from incidents reveal new gaps. Build Identify as a living program, not a one-time project you complete and forget.
ID.AM - Asset Management
Also known as: "wait, we have a server in the closet doing what?"
ID.AM requires the organization to identify, document, and understand its assets - hardware, software, data, services, and the people and external systems that interact with them. You cannot make defensible risk decisions without knowing what you're trying to protect. Most organizations, when they run real asset discovery for the first time, find at least one device that nobody can explain. Treat it as a treasure hunt with higher stakes.
ID.AM-01 through ID.AM-08
Build and maintain a comprehensive asset inventory
CSF 2.0 expanded the asset management scope significantly from CSF 1.1. ID.AM now explicitly includes software (ID.AM-02), services (ID.AM-03), systems in the external environment (ID.AM-04), supplier-provided components (ID.AM-05), data (ID.AM-07), and systems that support critical functions (ID.AM-08), in addition to hardware (ID.AM-01). The full scope is broader than many organizations initially expect.
How to implement:
Start with hardware: run a network discovery scan (Nmap, Lansweeper, or your RMM tool) and reconcile the results against your known device list. Every device that can access your network needs to be documented
Build a software inventory: use endpoint management tools (Microsoft Intune, CrowdStrike, or similar) to pull installed software from managed devices. Flag unauthorized or unmanaged software
Document services: this includes cloud services (SaaS, IaaS, PaaS), external APIs your systems call, and internal services that other systems depend on
ID.AM-07 requires data classification - not just knowing where data lives, but categorizing it by sensitivity. Start with three tiers: public, internal, and sensitive/regulated
Map dependencies: ID.AM-08 requires identifying systems that support critical business functions. Ask "if this system went offline for 48 hours, what business impact would result?" High-impact systems need heightened protection and continuity planning
Include supplier-provided systems in your inventory (ID.AM-05) - if a vendor manages a system that processes your data, that system belongs in your inventory even if you don't own it
Establish an asset management lifecycle: how are assets added to the inventory, who reviews it, how often is it reconciled, and what's the process for decommissioning assets?
Common mistake: Organizations create an asset inventory once as a spreadsheet, then never update it. Within six months it's inaccurate. Asset management needs to be a process, not a document - assets should be added at provisioning and removed at decommission, with periodic reconciliation scans to catch everything in between.
ID.RA - Risk Assessment
Also known as: the document leadership approves without reading and IT updates without telling anyone.
ID.RA requires the organization to understand and document the cybersecurity risks to its assets, operations, and personnel. This is not just vulnerability scanning - it's a structured process for identifying threats, assessing likelihood and impact, and producing prioritized risk information that drives security decisions.
ID.RA-01 through ID.RA-10
Build a risk assessment process, not just a risk assessment document
ID.RA in CSF 2.0 covers identifying vulnerabilities (ID.RA-01), threat intelligence (ID.RA-02), threat and vulnerability combinations (ID.RA-03), potential business impacts (ID.RA-04), likelihood of exploitation (ID.RA-05), risk determination from all of the above (ID.RA-06), risk responses (ID.RA-07), informing other practices and stakeholders (ID.RA-08), documented risk assessments (ID.RA-09), and integration of risk assessment outputs into risk management processes (ID.RA-10).
How to implement:
Establish an annual risk assessment process. Document the methodology: how do you score likelihood (1–5 scale, qualitative tiers, etc.), how do you score impact, how do you combine them into a risk rating, and what risk ratings trigger which responses
ID.RA-01 requires identifying vulnerabilities across your asset inventory - run authenticated vulnerability scans quarterly at minimum against all in-scope systems
ID.RA-02 requires consuming threat intelligence - at a minimum, subscribe to CISA's free Known Exploited Vulnerabilities (KEV) catalog and free threat advisories. Many cyber insurance carriers also provide threat intel feeds
ID.RA-04 requires assessing potential business impact - for each significant risk, document what the business consequence would be if the risk materialized (financial loss, regulatory penalty, operational disruption, reputational damage)
Produce a risk register: a living document that lists identified risks, their scores, assigned owners, response decisions (accept, mitigate, transfer, avoid), and remediation status
ID.RA-08 requires that risk assessment results inform stakeholders and relevant security practices - the risk register should be reviewed with leadership as part of GV.OV oversight activities
Don't limit risk assessments to technology. People risks (untrained staff, insider threats), process risks (no change management, no backup testing), and environmental risks (physical security gaps, natural disasters) belong in your risk register too
Common mistake: Treating ID.RA as "we run Nessus and look at the report." Vulnerability scanning is one input to a risk assessment, not a risk assessment itself. A risk assessment requires business context - impact on operations, likelihood in your specific threat environment, and decisions about how to respond - that a scanner output alone doesn't provide.
ID.IM - Improvement
The function that asks you to learn from your mistakes. Harder than it sounds.
ID.IM is the feedback loop that keeps the Identify function current. It requires the organization to use the outputs of assessments, exercises, incidents, and monitoring to identify improvements to the security program and implement them.
ID.IM-01 through ID.IM-04
Close the loop - assessments and incidents must drive program changes
ID.IM has four subcategories: improvements from assessments and exercises (ID.IM-01), improvements from security testing (ID.IM-02), improvements from incident response activities (ID.IM-03), and improvements from continuous monitoring (ID.IM-04). The common thread is that learning must produce action - finding gaps without fixing them doesn't satisfy ID.IM.
How to implement:
After every risk assessment, document findings as action items with owners and due dates. Track completion. An annual risk assessment that produces a report that no one acts on satisfies neither the spirit nor the letter of ID.IM
After tabletop exercises or incident response drills, conduct a structured after-action review. Document what worked, what didn't, and what process or policy changes result
After security incidents, conduct lessons-learned reviews within 30 days. The output should be specific - not "we need better security awareness training" but "we're updating the phishing simulation program to include the specific pretexts used in this incident and adding a mandatory re-training trigger for anyone who fails"
Establish a formal mechanism for tracking improvements: a security improvement log, a project tracker, or integration with your ITSM platform. Untracked improvements don't get done
ID.IM-04 ties continuous monitoring outputs to improvement - when your monitoring identifies a pattern (repeated failed logins from a specific geography, recurring misconfiguration type), that pattern should feed into risk assessment updates and control improvements, not just alert generation
Common mistake: Exercises produce after-action reports that get filed and never revisited. ID.IM requires closing the loop - the improvement items from an exercise need to be tracked to completion and the next exercise needs to test whether last year's gaps were fixed.
How Identify Feeds the Rest of the Framework
The Identify function is upstream of everything else in CSF 2.0. Your asset inventory (ID.AM) defines the scope of your Protect (PR) controls - you can't configure identity controls or data security without knowing what assets and data you're protecting. Your risk assessment (ID.RA) prioritizes which Protect and Detect controls get resources first. Your improvement process (ID.IM) incorporates what you learn from Detect and Respond activities back into Identify - closing the loop across all six functions.
Organizations that skip or underfund Identify work tend to protect the wrong things, miss risks that don't show up in technical scans, and repeat the same incidents without organizational learning. Getting Identify right is the highest-leverage investment in a CSF 2.0 program.
Evidence tip: For ID.AM, the primary evidence is an asset inventory document or system. For ID.RA, it's a risk register and risk assessment methodology document. For ID.IM, it's after-action review reports and improvement tracking records. Make sure each category has at least one dated artifact before calling implementation complete.
Policy Documentation for Your CSF 2.0 Identify Program
Your asset management and risk assessment processes need written policy backing to satisfy GV.PO and to pass any review. Our NIST CSF 2.0 Full Policy Bundle includes policy language for the Identify function alongside all five other CSF 2.0 functions - professionally written, framework-aligned, and ready to adapt.
ID.AM (Asset Management) focuses on identifying and documenting your own organization's assets - hardware, software, data, and services. GV.SC (Supply Chain Risk Management) focuses on the cybersecurity risks introduced by external suppliers and vendors. There is overlap - ID.AM-05 specifically requires documenting supplier-provided components in your asset inventory - but they serve different purposes. ID.AM answers "what do we have?"; GV.SC answers "what risk do our suppliers introduce?"
CSF 2.0 does not prescribe a specific frequency, but most guidance recommends annual risk assessments at minimum, with more frequent reviews triggered by significant changes - new systems, new vendors, regulatory changes, major incidents, or business model shifts. ID.RA-09 requires that risk assessment results inform decision-making. Completing an annual risk assessment and updating it quarterly when significant changes occur is a defensible approach for most organizations.
For hardware discovery, Nmap, Lansweeper, or your RMM tool's built-in inventory work well for smaller environments. Larger organizations typically use dedicated CMDB or ITAM platforms like ServiceNow, Tanium, or Microsoft Defender for Endpoint. For software inventory, endpoint detection platforms track installed software well. For cloud environments, use cloud-native tools - AWS Config, Azure Policy, and GCP Asset Inventory provide real-time asset visibility within each platform.
For CSF 2.0 purposes, vulnerabilities include technical vulnerabilities (unpatched software, misconfigurations, weak authentication), process vulnerabilities (no patch management process, no access review), environmental vulnerabilities (physical access gaps, natural disaster exposure), and human vulnerabilities (untrained staff, social engineering susceptibility). ID.RA-01 requires identifying vulnerabilities broadly, not just running CVE scans. A comprehensive risk assessment should cover all of these categories.
ID.IM is the feedback loop that makes the Identify function dynamic rather than a one-time exercise. After every significant incident, conduct a lessons-learned review and document what changed. After annual risk assessments, update your risk register and track remediation. After tabletop exercises, document gaps and improvements. ID.IM-01 through ID.IM-04 cover improvements from assessments, exercises, incidents, and continuous monitoring respectively - each requires documented findings and tracked action items, not just verbal discussions.