How to Build a NIST CSF Identify Program With a Team of 5
How to build the NIST CSF 2.0 Identify function with five people: asset inventory, risk assessment and improvement, what to buy, what to tell the board.
Loading...
How to build the NIST CSF 2.0 Identify function with five people: asset inventory, risk assessment and improvement, what to buy, what to tell 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.
Building the Identify function with a team of five is less a staffing problem than a prioritization problem. Most security leaders in this spot spend the first six months trying to do everything at once, and they end up with an asset inventory that is half right, a risk register nobody reads and a spreadsheet of exceptions that nobody owns. By then the team is tired, and the board wants to know why "unknown assets" keeps showing up in the audit findings.
That matters because every other function in the NIST Cybersecurity Framework leans on Identify. You can't protect a server you don't know about, and you can't detect an attack on a SaaS app nobody told you the business bought. Five people who focus on the right assets and risks can still build something real, though, if you set up the team well and agree on what to leave alone for now.
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.
In CSF 2.0, governance and supply chain risk moved out of Identify into the new Govern function, and the Govern guide covers that side. What stays in Identify is asset management, risk assessment and improvement. For a small team that comes down to two questions you should be able to answer on any given day: what do we have, and what could go wrong with it?
| Category | What it asks | What it looks like in practice |
|---|---|---|
| Asset management (ID.AM) | Do you know your hardware, software, services, data and suppliers, and which ones matter most? | An inventory with an owner and a criticality rating for each asset |
| Risk assessment (ID.RA) | Do you know your vulnerabilities and threats, and how likely and how bad each risk is? | A ranked risk register with a decision and an owner for each top risk |
| Improvement (ID.IM) | Do lessons from audits, tests and incidents change how you work? | A tracked list of fixes that came out of reviews, exercises and real incidents |
When you start a new program, it's tempting to open the CSF subcategories and start mapping gaps one by one. That exercise has its place later, but frameworks are written to be complete, and a team of five will drown if it tries to be complete in year one.
So start with how attackers actually get in, and inventory those paths first. In most organizations that means internet-facing systems nobody remembers deploying, unpatched software on assets without an owner, and third-party connections that were set up for a project and never closed. Let those shape your first 90 days. Everything else is important eventually, it just isn't important now.
You need three kinds of skill on the team, and five people with the same skill set won't give you that. I think about it as the rule of thirds: some technical depth, some operational discipline and someone who can translate all of it for the business. A structure that works looks like this:
The most common mistake is hiring five engineers. You get plenty of technical skill and nobody who can walk the CFO or the audit committee through the risk register, and it's usually the program manager who gets you through budget season.
Order matters more than speed here. If five people try to build a complete inventory, a full risk assessment and a GRC rollout at the same time, none of them gets finished, so pick the order by how much risk each step removes for the effort it takes.
| Phase | Focus | What you finish with |
|---|---|---|
| Days 1 to 30 | Find what you have and stop the worst exposure | A first inventory of internet-facing systems, cloud accounts, SaaS apps, service accounts and third-party connections |
| Days 31 to 90 | Give every important asset an owner and a rating | Owners and criticality ratings on your crown-jewel systems, with known exploited vulnerabilities on them tracked weekly |
| Days 91 to 180 | Run a real risk assessment and close the loop | A ranked risk register, an exception process with end dates, and a defensible baseline to show auditors and the board |
Days 1 to 30. Pull what you already have from cloud consoles, your EDR, your identity provider and your finance system, then compare the lists. Look hardest at internet-facing systems, service accounts whose passwords haven't changed in years and every connection a third party has into your network. Expect this to turn up a few things you'll want to fix that same week.
Days 31 to 90. Give each important asset a named owner and a criticality rating, starting with the systems that hold your most sensitive data or keep revenue coming in. Don't wait for a perfect inventory, because a rough ranking you can act on now is better than a perfect one in eight months. Then track the known exploited vulnerabilities on those assets as a weekly number.
Days 91 to 180. Run your first proper risk assessment on the ranked assets and put the results in a risk register where each top risk has an owner, a decision and a date. Set up an exception process with end dates, and start a short list of fixes that come out of incidents and tests. That loop is the improvement part of Identify, and it gives you something concrete to show auditors and the board.
After 180 days you should have a defensible baseline. It won't be a mature program yet, and you should say so plainly when you report to leadership.
A five-person Identify team can't buy everything. Vendors will tell you that you need CAASM, exposure management, a GRC platform, third-party risk software and data classification all at once. You don't, at least not yet. Buy in this order:
Vendor cost calculators usually leave out integration work, the hours your engineer spends on professional services calls, and the months of tuning before the product gives you reliable data. Build those costs into your evaluation. As a rough example, a product that costs $150K a year but takes 40% of one engineer's time can really cost closer to $250K.
Compare Cybersecurity solutions side by side
Features, integrations, NIST coverage and deployment for every Cybersecurity solution we list, in one table.
Your board doesn't want a technical briefing on your CMDB. They want to know what could go wrong, how bad it would be, and what you're doing about it. Four metrics answer that in business language:
When the board asks about return on the spend, point to the drop in unknown assets and the time to close exploited vulnerabilities on critical systems. Both are numbers an auditor can check, and they're also the numbers your cyber insurance carrier tends to ask about. For more on what boards respond to, see security metrics your board cares about.
A five-person team rarely has procurement support. So your engineers sit in vendor demos and your program manager negotiates contracts, while the work that reduces risk waits. You need a faster way to evaluate.
The old way is an RFP, six weeks of waiting for responses, scoring 200-page documents, a 90-day POC and three months of negotiation, which adds up to about eight months. The faster way is to write down your three must-have technical requirements, run a two-week proof of concept with your own data, and decide. You won't get it perfectly right, but you'll get it done.
In the contract, push on three things: multi-year pricing with a cap on yearly increases, a right-to-audit clause for any vendor that holds your asset and risk data, and a clear support SLA for P1 incidents. Most vendors will agree to all three if you ask directly, and most buyers never ask.
You can build a solid Identify program in 18 months with five people. You can also watch it fall apart within 12 months if upkeep isn't part of how the team works, because inventories go stale, exceptions pile up and the risk assessment turns into a ritual nobody believes in.
The annual risk assessment is a good example. Most teams run it because the auditors require it. They send a questionnaire to system owners, copy last year's ratings where nobody answered and call it done, and nobody checks whether a single decision changed because of it. The ritual keeps going while the risk stays where it was.
Build upkeep into the program from day one. Track whether the inventory matches what discovery finds, not only whether an inventory exists, and count the risks that got a real decision rather than the assessments completed. Then talk openly with your team about which controls are working and which are ceremonial.
Five people is a starting point, and at some point the program will outgrow the team. The question is how to make the case so it gets approved.
Don't argue from workload, because every team has too much work. Argue from risk: name the gaps that exist because you lack capacity, put a size on the risk they carry, and show what a sixth or seventh person would close.
For example, say your analyst spends their time chasing system owners for questionnaire answers, so nobody reviews the third-party connections into your network. That gap carries a risk you can put a number on, because a breach that comes in through a forgotten supplier connection has a cost, and so does another analyst. Your CFO can work with that comparison.
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.
Five people is a constraint you can plan around. The teams that do well make hard calls on priorities early, staff for balance rather than technical depth alone, and measure from day one. They also stop doing things that look like security but don't reduce risk: the inventory nobody reconciles, the risk register with no decisions in it, the assessment that copies last year's answers. Those patterns turn a promising program into a compliance exercise, so build with your five people and your real threats in mind.
Three categories. Asset management (ID.AM) covers your inventories of hardware, software, services, data and suppliers, plus how you rank them. Risk assessment (ID.RA) covers vulnerabilities, threats, likelihood, impact and the decisions you make about each risk. Improvement (ID.IM) covers how lessons from evaluations, tests and incidents change the program.
A credible baseline takes about 180 days with a focused team. That means an inventory of your internet-facing and crown-jewel assets with owners, exploited vulnerabilities on those assets tracked weekly, and a ranked risk register. A mature program with continuous discovery, supplier assessments and a working improvement loop takes 18 to 24 months, so aim for defensible first and perfect later.
Report outcomes instead of subcategories. Inventory coverage, unknown assets found and exploited vulnerabilities on critical systems are numbers any board member can read. Tie them to your cyber insurance requirements and your last audit findings, and the conversation gets much more useful.
Yes, if you shorten the evaluation. Run two-week technical POCs instead of 90-day pilots, and use three must-have requirements instead of a 50-point RFP scorecard. Give vendor management to your program manager and keep your engineers out of sales cycles, because every hour an engineer spends in a demo is an hour not spent reducing risk.
Buying a GRC platform before they have a clean inventory and a working risk process. GRC is useful when its inputs are accurate. Without them, your team spends months configuring expensive shelfware, so build the inventory and the risk register first and add the platform on top of something that works.
Reconcile the inventory against discovery every quarter and track the gap. Count how many risks got a real decision, rather than whether the assessment was completed. Once a quarter, look at the fixes that came out of incidents and tests and check which ones actually shipped. Decay is predictable, which means you can prevent it if measurement is part of how the team works from the start.
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.