Your Analyst Asked What the Team Is Scored On and You Had Nothing: Build a Subcategory Scoreboard With NIST CSF 2.0

The views expressed are my own and do not represent those of my employer.

Imagine a detection analyst who closes forty tickets a week, tunes rules on her own time, and finds a misconfigured log source that would have hidden an intrusion. Then her annual review arrives. It says "meets expectations." Nobody can tell her what the team is measured on, so nobody can tell her what she improved.

This is post 1 of 3 in a series I am calling Security Metrics by Audience. The series covers the whole of NIST CSF 2.0, one audience at a time. This post is for the team. Post 2 is for management and works at the category and program level: trends, resourcing and cross team dependencies. Post 3 is for leadership and the CISO and works at the function and Govern level, with Tiers, risk appetite and board language.

Start here, because the rest depends on it. Most CISOs I talk with report metrics upward every quarter. Almost none give the team its own scoreboard. The result is predictable. The team cannot see its value, so it cannot defend its budget or its time. The team cannot see its gaps either, so you find them the hard way, usually in an audit finding or an incident review.

A scoreboard fixes both problems. It has to be built at the right level, and that level is the subcategory.

Why the Subcategory Is the Team's Unit of Measure

CSF 2.0, published in February 2024, defines 106 subcategories. Each one is an outcome statement. Take ID.AM-01. NIST words it as inventories of hardware managed by the organization are maintained. An engineer can act on that sentence. She can ask whether the inventory is maintained, how she would know, and what broke the last time it was not.

Now look one level up. Asset Management is a category heading. Identify is a function. Both are useful for orientation and useless for Monday morning. Nobody can fix "Identify."

A function tells you where to look. A subcategory tells an engineer what to fix on Monday.

This is also why the team's scoreboard looks different from what management and leadership see. Management needs roll-ups by category and program. Leadership needs function level views and risk language. Neither audience needs forty rows of operational detail. The team does, because the team owns those outcomes. Keep the detail where the work happens, and let it roll up from there.

Start With the Outcomes Your Team Actually Owns

Do not try to score all 106. I have seen that attempt stall in the first month, buried under a spreadsheet nobody wants to open.

Take the subcategories the team genuinely owns. For most security teams, that means a block of ID, PR, DE, RS and RC outcomes. If you need a refresher on what each category covers, I wrote function deep dives on the blog. The Identify deep dive on asset management is a good example of the reference I mean. I will not re-explain categories here.

Treat Govern differently. Most Govern outcomes belong to posts 2 and 3, because they concern strategy, policy, roles and oversight. The team still contributes evidence. Supply chain risk is the clearest example: the team supplies the findings, the exceptions and the exposure data that leadership needs to say anything meaningful about it.

Do the ownership exercise in a room, with the engineers. Put each candidate subcategory on a card and ask who is accountable. Two things will surface fast. Some outcomes have no owner at all. Others have three owners who each assume somebody else is covering it. Both are findings before you have measured anything.

Two Measures Per Outcome: Are We Doing It, and Is It Working

For every subcategory the team owns, define two measures. No more.

The coverage or gap measure answers one question: are we implementing this outcome? It is usually a percentage against a defined population, such as the share of hardware in your authoritative source that your discovery tooling also sees.

The effectiveness or value measure answers a different question: is it working, and did it prevent or shorten something? It is usually a time, a rate or a before and after comparison. Coverage tells you the control exists. Effectiveness tells you it earned its keep.

You need both because each fails alone. A team with 100 percent coverage and no effectiveness data cannot show that anything improved. A team with a great effectiveness story and no coverage data cannot say what it has not touched yet.

Then make the gap explicit. CSF lets you describe a Current Profile and a Target Profile for the outcomes you care about. For each measure, write down where you are and where you intend to be. The distance between the two is the gap. Without it, "we are mostly there" is a feeling. With it, "we are at 87 percent against a target of 98" is a work item.

One decision belongs to you. NIST does not prescribe a scoring scale for any of this, so you pick the measures deliberately. My recommendation: use percentages, counts and times wherever the data exists. Use a maturity score only where it does not, and define each level by the evidence required to earn it. Avoid vendor scoring models. They hide the assumptions you most need to see.

I have already shown how this works for one domain. My two IAM posts, IAM Metrics That Actually Matter and IAM Metrics in Practice, take identity from definitions to real conversations. Think of this series as the full framework version, split by audience.

Write the Definition Card Before You Collect a Single Number

Most metric programs fail at the definition, not the dashboard. Two people compute "percent of assets covered" and get different answers because they used different denominators. Then the number loses credibility, and a number that loses credibility is hard to get back.

NIST gave practitioners help here. In December 2024 it published the final SP 800-55, the Measurement Guide for Information Security. Volume 1 covers identifying and selecting measures, and Volume 2 covers developing an information security measurement program. The updates to Volume 1 include new information about measures documentation, reporting, data quality, and uncertainty. That last item is the one most teams skip.

I use a simple definition card for every measure. It borrows the spirit of SP 800-55 and keeps the fields short:

Name. Plain words an engineer would say out loud. Formula. Numerator, denominator and exclusions, written down. Data source. The system of record, not "various." Owner. One named person who answers for the number. Frequency. How often it is collected and reviewed. Target. The value you intend to reach and the date. Data quality note. How much you trust the number and why.

That last field changes the conversation. "This figure excludes cloud accounts until the integration finishes" is an honest sentence. It protects the team when someone challenges the number, and it points at the next improvement.

A measure without a formula and a named owner is an opinion with a chart attached.

A Worked Example, With Invented Numbers

Here is how the method looks across five functions. Every figure below is illustrative. I made the numbers up to show the shape, so do not benchmark against them. Confirm each ID and its wording against the CSF 2.0 Core before you copy anything into your own program.

Identify, ID.AM-01 (hardware inventories are maintained). Coverage: the share of hardware in the authoritative source that discovery also sees. Illustrative current state is 87 percent against a target of 98. Effectiveness: unknown devices found per month and the median days to assign an owner. Illustrative result is 11 days, falling toward 3 once the new owner workflow runs.

Protect, PR.AA-05 (access permissions, entitlements and authorizations are governed by policy, enforced and reviewed, with least privilege and separation of duties). NIST's wording says access permissions are defined in a policy and managed. Coverage: privileged account reviews completed on schedule, divided by reviews due. Illustrative current state is 72 percent against a target of 100. Effectiveness: the share of privileged entitlements removed at review, and days from decision to removal.

Detect, DE.AE-02 (potentially adverse events are analyzed to better understand associated activities). Coverage: the share of high severity detections with a named owner and a written triage procedure. Effectiveness: mean time to triage a high severity detection. Illustrative result is 38 minutes today against a target of 15. Pair it with a quality check, such as the share of triaged alerts reopened within a week.

Respond, RS.MA-05 (criteria for initiating recovery are applied). Coverage: the share of your top incident scenarios that have written recovery initiation criteria. Effectiveness: in exercises, the share where the team applied those criteria and logged the decision within the target time.

Recover, RC.RP-03 (the integrity of backups and other restoration assets is verified before use). The text reads that integrity of backups and other restoration assets is verified before using them for restoration. Coverage: the share of critical systems with a restore test in the last quarter. Effectiveness: restore test success rate, and restore time against the recovery target. Illustrative result is 83 percent success against a target of 95.

Notice what these rows share. Each has a population you can name, a number you can calculate and an owner who can act. None needs a vendor model.

Run the Review So Every Gap Gets an Owner

A scoreboard nobody reviews is wall art. Set a regular review, monthly for most teams, and keep it to thirty minutes. Walk the board left to right. For every measure that is off target, assign one owner and one date. Do not leave the room with a gap and no name next to it.

Show value realized in the same meeting. Before and after trends do the work here. If the triage tuning project cut mean time to triage from 38 minutes to 21, put both numbers on the board with the date of the change. That is how an analyst sees that her Saturday tuning mattered. It is also the evidence you need when someone asks what the team delivered.

Display matters as much as definition. I covered the display side in two earlier posts on Gemba boards and visual management. Treat the Gemba board as the format for the team's subcategory measures. The board is where the red, yellow and green live. The definition card is what stands behind each one.

Retire the Measures Nobody Acts On

Every measure costs attention. Collecting it, explaining it and defending it all take time. So apply a hard rule: if a measure has driven no decision or action across two review cycles, retire it or redesign it.

This keeps the board honest. It also protects you from the slow creep of "just add one more metric," which turns a scoreboard into a report nobody reads. I would start with eight to twelve subcategories and two measures each. Add only when a team member asks a question the board cannot answer.

A measure nobody acts on is decoration. Retire it and keep the board small enough to read in a glance.

Borrow a Target Profile Instead of Writing One From Scratch

Writing a Target Profile cold is slow. NIST publishes Community Profiles that select and annotate CSF outcomes for a given purpose, and you can use them as a seed.

Two are directly useful to a team scoreboard. The ransomware profile, NIST IR 8374r1, was published on June 11, 2026. It can help gauge an organization's readiness to counter ransomware threats. For incident response, NIST finalized SP 800-61r3 in April 2025 as a CSF 2.0 Community Profile. Those two together can seed the Detect, Respond and Recover rows of your board in an afternoon.

NIST has also built community profiles for the manufacturing, financial and telecommunications communities, among others. Check whether one matches your sector.

One more to watch. The Cyber AI Profile, NIST IR 8596, is still in development. NIST released the preliminary draft on December 16, 2025, and a regulatory tracker showed it still in draft status as of September 7, 2026. Do not build a scoreboard on a draft. Read it, and plan to revisit your AI related rows when it is final.

A profile is a starting point, not a verdict. Remove outcomes your team does not own and tighten targets to match your risk.

The One Page Template

Here is the page I would copy. Make one per subcategory, or one row per subcategory in a shared sheet. Keep it to a page so people actually fill it in.

Subcategory ID and outcome statement. Copy NIST's wording exactly.

Accountable owner. One name.

Current state and target state. One sentence each, tied to your Current and Target Profile.

Coverage measure. Name, formula, population, data source, frequency, target and date.

Effectiveness measure. Name, formula, data source, frequency, target and date.

Data quality note. What the number excludes and how much you trust it.

Gap and action. The distance to target, the next step, the owner and the due date.

Value realized. The before and after figures, with the date of the change that moved them.

Review decision. Keep, fix or retire, plus the date of the next review.

Getting Organizational Support: Sell the Scoreboard in the Language of Risk

This work needs support at every level. Each audience cares about a different thing, so pitch it that way.

The team. Lead with fairness and visibility. The board shows what each person owns and what they improved. It is not a ranking and it must never become a punishment tool. If people fear the numbers, they will game them.

Peers in IT and the business. Many of your measures depend on their data and their action. Inventory depends on IT operations. Access reviews depend on application owners. Pitch shared outcomes, and ask for one data feed and one named contact. Avoid handing them a list of your complaints.

Executives. They do not want subcategory detail. They want to know whether the organization is getting better at the things that reduce loss. Tell them the team scoreboard feeds the management and leadership views, so every number they see can be traced to evidence. Frame the ask as a thirty minute monthly review and access to data sources, not a new tool purchase.

Finance and audit. Definition cards and data quality notes are your credibility. They show that a number can be reproduced, which is what an auditor and a finance partner both need.

The board. The board will not see this board, and it should not. What it needs is confidence that the figures on its slides come from somewhere real. In board terms: "Every number we report to you is built from operational measures that an owner is accountable for, and the gaps have dates." I will cover the board facing layer in post 3. For the Govern view, my board and executive guide to the CSF 2.0 Govern function is the bridge.

Key Points

• Measure at the subcategory level for the team. Management and leadership get roll-ups.
• Score only the subcategories the team owns, mostly ID, PR, DE, RS and RC.
• Define two measures per outcome: coverage ("are we doing it?") and effectiveness ("is it working?").
• Write the gap against a Target Profile so it is a number, not a feeling.
• Give every measure a definition card with a formula, source, owner, frequency, target and data quality note.
• Review monthly. Every gap gets one owner and one date.
• Show before and after trends so the team sees its own value.
• Retire any measure that drives no action across two review cycles.

Pro Tips

Start with eight subcategories. Pick the ones tied to your last two incidents or audit findings. Those are the outcomes people already care about, so adoption is easy.

Have someone other than the owner sample the evidence. Owners score themselves generously, and I do not blame them. A quarterly spot check by a peer, on a handful of records, keeps the board honest and catches definition drift early.

Pair every speed measure with a quality check. Mean time to triage falls fast when analysts close alerts without reading them. A reopen rate next to it makes the trade visible.

Put the uncertainty on the board. A small note beside a number saying "excludes cloud accounts" builds more trust than a clean number that later proves wrong.

Record the decision each measure drove. At the end of the quarter, count them. A measure with no recorded decisions is your next retirement candidate, and the count is also a strong story for leadership.

Pitfalls to Avoid

Do not score all 106 subcategories on day one. Build a small board that people use, then widen it.

Do not assess the policy instead of the practice. If access reviews are required on paper but half the applications skip them, your coverage number must say so.

Do not let the board become a performance ranking. The moment individuals are compared, the data gets shaded, and the scoreboard stops telling you the truth.

Do not skip the definition card. A number without a formula will be challenged in its first meeting, and you will have no answer.

Do not adopt a vendor scoring model and treat it as the framework. CSF 2.0 does not mandate a scale, so choose measures you can explain and reproduce.

Do not treat a Community Profile as your Target Profile without edits. It is a seed. Your risk and your ownership decide the final target.

Final Thought

The best teams I know do not wait for a review cycle to learn whether they are winning, because they can see it on the board every week, with a name and a date beside every gap, and that visibility is what turns a group of capable engineers into a team that improves on purpose.

If you build the scoreboard this month, I would love to hear which subcategory you started with and what the first gap looked like. Leave a comment, subscribe so you catch posts 2 and 3 of this series, or share this with a CISO who still reports metrics upward only. I read every one.