NIST CSF Identify Maturity: Where Programs Fall Short
How to assess NIST CSF 2.0 Identify maturity: score asset management, risk assessment and improvement on coverage and effectiveness, then brief the board.
Loading...
How to assess NIST CSF 2.0 Identify maturity: score asset management, risk assessment and improvement on coverage and effectiveness, then brief the board.
What AI-driven security solutions really do: alert triage, behavior-based detection, risk ranking and automated response, and how to test the AI claims.
Most Identify maturity assessments end with a score. The score goes into a slide deck, the deck goes to the board, and six months later the asset inventory and the risk register look exactly like they did before anyone started. The assessment got done, but the risk stayed where it was.
Identify sits underneath everything else in the NIST Cybersecurity Framework. Your EDR can only protect the devices it's installed on, and your SIEM can only watch the systems that send it logs, so every asset missing from your inventory is also missing from those controls. If your Identify function is weak, every other control you pay for has gaps you can't see.
CISOs know the inventory matters. The trouble is that most assessments measure the wrong things: whether an inventory exists instead of whether it's complete, whether a risk assessment was done instead of whether anyone acted on it. They tell you what you have on paper and very little about what holds up when an attacker goes looking for the asset you forgot.
Browse the Full Cybersecurity Market. Every Category.
Every category on CybersecTools, from AI Security and Cloud Security to Threat Intelligence and Offensive Security. Filter by use case, industry, or company size.
CSF 2.0 moved governance and supply chain risk management into the new Govern function, so Identify now has three categories. The Govern maturity guide covers the parts that moved.
| Category | What a mature program can show |
|---|---|
| Asset management (ID.AM) | Inventories of hardware, software, services, data flows, data and supplier services, each asset with an owner and a priority, managed from purchase to disposal |
| Risk assessment (ID.RA) | Known vulnerabilities and threats, likelihood and impact for each risk, a chosen response, tracked exceptions, and checks on suppliers and products before you buy |
| Improvement (ID.IM) | Fixes that come out of assessments, tests, exercises and incidents, and plans that get updated because of them |
Most frameworks, CMMI-based or otherwise, ask whether you have a policy, a product and a process. You tick all three, reach Level 3 and satisfy your auditor, and the Identify function can still be broken.
That happens because an artifact and a control aren't the same thing. A CMDB that covers 60% of your servers leaves the other 40% outside every process that depends on it. A risk register that was filled in for the audit and never opened again is the same story: it exists, and it protects very little.
So when I build an assessment, I change the first question for every category. Instead of "do we have this?", I ask "what share of what's really out there does this cover, and how do we know?" That one change reshapes everything the assessment finds.
Say your inventory covers every laptop the company issued. It probably doesn't cover the cloud accounts a product team opened with a credit card, the SaaS apps the business bought without IT, or the legacy server your ERP team won't migrate because it "still works fine." Those gaps are where attackers look first.
A mature Identify program maps every asset type against the inventory, and that map usually shows something uncomfortable. These are the asset types most inventories miss:
Most programs cover the first group well and get steadily worse with each group after it. That gap is also a budget conversation, because when you show your CFO that, say, 30 internet-facing systems have no owner, you're showing a risk with a number on it. It's also a specific project with a clear scope, which is much easier to fund.
Risk assessment is usually the hardest part of Identify to get right. CISOs understand it fine. It's just uncomfortable to finish, because a real assessment ends in a decision, and decisions mean someone has to accept a risk, pay to reduce it or explain why it's still open.
That makes a weak risk process a leadership problem more than a technical one. If your predecessor kept a risk register where nothing ever got accepted or closed, that history is still in your program, and those open risks are now yours. Assess risk maturity on four questions:
Programs tend to score well on vulnerabilities, since that's what scanners produce. They score worse on decisions and exceptions, because those need people to commit, and a product can't do that for you.
Asset lifecycle work sounds boring, and that's why risk piles up in it for years. Every time a project spins up a server and nobody records it, the inventory drifts further from reality. And every time a system is retired on paper but left running, you've left a door open that nobody is watching.
The numbers add up fast. Take a company that adds 100 cloud workloads a month: that's 1,200 a year that need an owner and a rating just to stand still. If 10% slip through, 120 assets a year sit outside every process, which is 360 after three years, and each one is a possible way in. Treat these as example numbers and put in your own.
Test the process with a sample instead of reading the policy. Take 20 assets your EDR or cloud console can see today, check whether each one is in the inventory with an owner and a rating, and do the same in reverse for 20 inventory records. That sample will tell you more about your real maturity than any questionnaire.
The yearly lessons-learned meeting is the classic example of ceremonial security. Your team writes up the incident, lists ten fixes and sends the document around. The auditor sees a report, and six months later most of the fixes are still open.
The meeting usually isn't the problem. Most improvement work has no tracking behind it, so if a test shows a gap and nothing is assigned for 30 days, the test didn't do anything. Mature improvement has three things most programs lack:
If your GRC platform can record findings but nobody closes them, someone still has to chase each one by hand. The same pattern shows up in access reviews, covered in why the quarterly access review is broken.
Compare Cybersecurity solutions side by side
Features, integrations, NIST coverage and deployment for every Cybersecurity solution we list, in one table.
The most honest Identify assessment starts from the attacker's side. Before you score anything, run an external discovery of your own domains and IP ranges and count how many results aren't in your inventory. That one number cuts straight through scores built on artifacts.
For the structured part, score each category on two axes. Coverage is the share of real assets or risks where the practice applies, and effectiveness is whether it works when you test it. An inventory with 100% coverage on paper and a 60% match against discovery is still immature. Here's a scoring model for the three Identify categories:
| Category | Coverage score (0 to 5) | Effectiveness score (0 to 5) | Combined maturity |
|---|---|---|---|
| Asset management | % of discovered assets in the inventory with an owner | Sample match rate between inventory and discovery | Average of the two |
| Risk assessment | % of critical assets assessed in the last 12 months | % of top risks with a decision and a date | Average of the two |
| Improvement | % of findings turned into tracked tasks | % of those tasks closed on time | Average of the two |
Score each category on what actually works. Where coverage and effectiveness pull apart, that's your real risk.
Your board doesn't want a maturity score. They want to know what it means for the business. "We are at Level 2.3 on Identify" tells a board member who runs a manufacturing company nothing, while "We found 30 internet-facing systems nobody owns, and nobody is patching them" tells them the risk.
Turn every major finding into a business impact statement: "If this gap is exploited, the likely outcome is X, with an estimated impact of Y." You don't need an exact dollar figure. You need a believable scenario that links the technical gap to something the board already worries about, like ransomware, regulatory fines or customer data exposure.
Then order the remediation roadmap by risk removed per dollar spent. Giving owners to your internet-facing systems costs less and removes more risk than a new GRC platform, and showing that math builds credibility and makes the budget conversation easier. For the metrics boards respond to, see security metrics your board cares about.
Identify remediation projects usually fail for two reasons. The first is scope. "Build a complete asset inventory" is an open-ended program, and it tends to lose its executive sponsor around month 6 and get cancelled when the budget cycle resets.
The second is underestimating how much has to change. Buying a discovery product is the easy part. The hard part is getting product teams to register what they deploy and getting system owners to make risk decisions, and that needs executive backing, change management and a clear answer to "what's in it for me?"
Plan the roadmap in 90-day blocks, each with an outcome you can measure. For an organization of 1,000 to 5,000 employees, a realistic 12-month Identify roadmap looks like this:
Each milestone gives you a measurable drop in risk to report to the board, and that steady reporting is what keeps the program funded. If your team is small, building a NIST CSF Identify program with a team of five covers what to do first.
Check a vendor before you sign
Mandos tracks funding, acquisitions, hiring and news for security companies. Look up any vendor on your shortlist before the renewal.
An Identify maturity assessment is only worth doing if it gives you accurate findings and funded fixes. Most programs run the assessment and skip the uncomfortable parts. They score the inventory they have instead of the assets that exist, show the board a number and move on, while the risk stays put. Score on coverage and effectiveness, put findings in business terms before they reach the board, and order the fixes by risk removed per dollar. Then check your work from the attacker's side: if an external scan finds systems your inventory doesn't, your score describes where you hope to be, and that's the gap to close first.
Identify is the function that helps you understand your current cybersecurity risk. In CSF 2.0 it has three categories: asset management (ID.AM), risk assessment (ID.RA) and improvement (ID.IM). Governance and supply chain risk management, which used to sit partly in Identify, moved to the new Govern function.
Score each category on two things: coverage, meaning the share of real assets or risks a practice applies to, and effectiveness, meaning whether it works when tested. Then test it from the attacker's side by comparing an external discovery scan against your inventory. Report the result to the board as business risk instead of a level number.
External assessments are priced by scope and company size, so get quotes from two or three firms. A thorough internal one costs mostly staff time. Internal assessments are more accurate because your people know where the problems are, but they also tend to be optimistic. Use an outside firm when you need board-level credibility for the findings, or when you suspect internal politics are hiding the real picture.
Report three numbers: the share of discovered assets that are in the inventory with an owner, the number of exploited vulnerabilities open on critical systems, and the share of top risks with a decision. Those three tell a board what it needs to know without any technical background. Show them quarter over quarter so the board sees the direction as well as the current state.
The two overlap more than they conflict. Asset inventories, risk assessments and vulnerability management are required by SOC 2, ISO 27001, HIPAA and most cyber insurance policies. Order the work to meet compliance first, but design each practice to actually work. A risk assessment that ends in real decisions satisfies your auditor and lowers your risk, while one that copies last year's answers only satisfies the auditor.
Fix what you have in most cases. Replacing it costs months of migration and leaves a gap in the inventory during the switch. The real question is why it's out of date. If nobody feeds it, connect it to the sources that already see your assets, like cloud consoles and EDR. If teams won't register what they deploy, that's a leadership conversation, and buying a new product won't fix it.
Supplier connections are some of the least assessed and highest-risk assets you have. Treat every vendor with direct system access as part of your inventory, and check whether you assessed the supplier before you bought, whether its access is limited to what it needs, and whether you remove it when the contract ends. The SolarWinds compromise reached its victims through a trusted supplier's software update, so the assessment isn't complete without suppliers. The third-party risk category lists products for this.
For a company with two or three people working on it and enough budget, plan on 18 to 24 months. Teams that try to go faster usually get a discovery product deployed without anyone using its findings, which gives you Level 3 artifacts with Level 1 security. Technology is rarely what holds it up. Getting teams to register what they deploy, and getting owners to make risk decisions across several budget cycles, are what take the time.
I wrote this guide from my own work leading security programs. Product and category links point to the CybersecTools catalog of 9,168 security products. Read the methodology for how we review products.