NIST CSF Identify Function

What is the NIST CSF Identify function?

The Identify (ID) function is where a NIST CSF program begins. Its purpose is to develop an organizational understanding of cybersecurity risk to systems, people, assets, data, and capabilities. Identify is not glamorous — no dashboards full of blocked attacks, no incident response war rooms — but it is the function that determines whether every other function has something coherent to act on.

You cannot protect an asset you do not know you own. You cannot detect anomalies in a data flow you have never mapped. You cannot respond to an incident without knowing which systems are critical. You cannot recover what you have not inventoried. Identify is the groundwork that makes the Protect, Detect, Respond, and Recover functions possible, and it is the input that feeds the Govern function's risk management strategy.

Identify is also the function most often shortchanged. Teams rush into Protect because controls feel tangible, and they discover months later that their scope was wrong, their risk register was stale, and their supply chain exposure was invisible. Mature organizations invest heavily and continuously in Identify.

How Identify changed in NIST CSF 2.0

NIST CSF 2.0 restructured the Identify function. Two of the original Identify categories moved to the new Govern function:

• Governance (ID.GV) was elevated to the Govern function and split into GV.OC, GV.RR, GV.PO, and GV.OV.
• Risk Management Strategy (ID.RM) became GV.RM.
• Supply Chain Risk Management (ID.SC) moved to GV.SC.

What remains in Identify is tightly focused on knowing what you have and what is at risk: Asset Management, Risk Assessment, and Improvement. The Business Environment outcomes from CSF 1.1 were folded into GV.OC but continue to inform Identify activities. The result is a leaner, more operationally focused Identify function that pairs cleanly with the strategic Govern function above it.

The categories of the Identify function

In NIST CSF 1.1 the Identify function also included Business Environment (ID.BE), Governance (ID.GV), Risk Management Strategy (ID.RM), and Supply Chain Risk Management (ID.SC). Those outcomes now live in the Govern function in NIST CSF 2.0.

Asset Management (ID.AM)

ID.AM is the most foundational category in the entire NIST Cybersecurity Framework. It requires the organization to identify and manage all of the assets that enable it to achieve its business purposes, consistent with their relative importance to business objectives and the organization's risk strategy. Assets include physical devices, operating systems and applications, data, personnel, and external systems the organization depends on.

Practical ID.AM outcomes include:

• A current inventory of hardware and physical devices.
• A current inventory of software platforms and applications, including open-source components and SaaS subscriptions.
• An inventory of data classified by sensitivity and regulatory obligation, linked to the systems that store and process it. (See our data classification primer.)
• A map of communication and data flows — which systems talk to which, over which protocols, across which trust boundaries.
• An inventory of external information systems the organization depends on, including suppliers, SaaS vendors, and managed services.
• Prioritization of assets by criticality so that Protect, Detect, Respond, and Recover can focus on what matters most.

Risk Assessment (ID.RA)

ID.RA is where the organization systematically identifies, analyzes, and prioritizes cybersecurity risks. ID.RA covers threat intelligence collection and analysis, vulnerability identification, likelihood and impact analysis, and risk determination. A mature ID.RA program produces a prioritized risk register that feeds directly into the Govern function's risk management strategy (GV.RM) and drives investment decisions across the other functions.

ID.RA is not a one-time activity. Threats evolve, the business changes, and new vulnerabilities are disclosed daily. Risk assessments should be refreshed on a regular cadence and triggered by significant events — major system changes, acquisitions, new product launches, or significant incidents.

Improvement (ID.IM)

ID.IM is new in NIST CSF 2.0. It captures the outcomes associated with continuous improvement of the cybersecurity program based on assessments, tests, exercises, incidents, and audits. ID.IM asks whether the organization systematically captures lessons learned and translates them into updated policies, controls, and practices. Without ID.IM, the NIST Cybersecurity Framework stops evolving with the organization.

Implementation guidance

A pragmatic sequence for building out the Identify function:

1. Pick an authoritative asset system of record. Choose one tool (a CMDB, an endpoint management platform, or a cloud asset inventory) as the source of truth. Integrate data from other tools into it rather than maintaining parallel inventories.
2. Classify data. Map every sensitive data type to the systems that store and process it. Link data classification to regulatory obligations (HIPAA, PCI DSS, GDPR, CUI) captured in the Govern function.
3. Draw a data flow diagram. Even a rough diagram beats no diagram. Iterate it over time.
4. Build a prioritized risk register. Begin with qualitative scoring (high / medium / low) and mature toward quantitative methods over time. Use the risk register as the single place where business, compliance, and engineering risks live.
5. Schedule formal risk assessments. Pick a cadence (quarterly for dynamic environments, annually for stable ones) and stick to it. Trigger ad-hoc assessments after major changes.
6. Close the improvement loop. After every audit, tabletop exercise, penetration test, or incident, capture lessons learned in ID.IM and feed them back into policy and control updates.

Common challenges

Identify fails for a handful of recurring reasons:

• Shadow IT and shadow SaaS. Employees adopt tools the security team never sees. ID.AM erodes continuously unless the organization has a discovery and procurement process that catches new SaaS and cloud accounts early.
• Inventory without criticality. A 50,000-row CMDB is useless if every asset has the same priority. ID.AM must include criticality scoring that drives where Protect and Detect resources are applied.
• Risk register as a spreadsheet graveyard. Registers maintained in static spreadsheets drift out of date within weeks. Treat the risk register as a living artifact with owners, due dates, and review cadences.
• Disconnected data classification. Data classification schemes that nobody uses are common. Tie classification to access control, encryption, and DLP decisions so that the classification actually changes behavior.
• Identify as a one-off project. Many organizations treat Identify as a project to finish rather than a continuous capability. NIST CSF 2.0's ID.IM category is a deliberate counterweight.

How episki helps

episki turns the Identify function into an always-on capability. Asset inventories, data classifications, data flow maps, and risk registers are maintained in one place, linked to the NIST CSF subcategories they satisfy and to the corresponding outcomes in SOC 2, ISO 27001, HIPAA, PCI DSS, and CMMC. Integrations pull hardware, software, and cloud asset data directly from the tools that already know. Risk assessments, improvement actions, and lessons-learned loops become tracked workflows rather than documents in a shared drive.

Ready to make the NIST CSF Identify function live? Start a trial or book a demo and stand up a working NIST CSF Identify profile in days, not quarters.