Series Introduction
Every IRP, PIR, playbook, and tabletop in this series maps back to NIST CSF 2.0.
If you want your security work to look mature, consistent, and defensible, you can’t just say “we follow NIST CSF 2.0.” You need to understand how Functions, Categories, and Outcomes actually fit together and how to use those mappings in real work.
This is the master reference that explains that structure and shows you how to apply it.
Articles in the series:
- Post‑Incident Review (PIR) Example
- Tabletop Exercise Scenario
- Facilitator’s Script
- Participant Handout
- After‑Action Report (AAR)
The Three-Layer Pyramid: Functions, Categories, Outcomes
NIST CSF 2.0 is built like a three‑layer pyramid. Each layer becomes more specific as you move downward, and each one plays a different role in how you design, assess, and improve your security program.
1. Functions – The Strategic Buckets (GV, ID, PR, DE, RS, RC)
Functions are the highest level. They describe what your security program must achieve at a strategic level:
- Govern
- Identify
- Protect
- Detect
- Respond
- Recover
Think of Functions as the chapters of your security book.
2. Categories – The Capability Areas (e.g., PR.AA, RS.MI, DE.CM)
Categories sit inside each Function. They define the specific areas of capability you need to build.
Examples:
- PR.AA – Identity Management, Authentication & Access Control
- DE.CM – Continuous Monitoring
- RS.MI – Mitigation
Categories are the sections inside each chapter.
3. Outcomes – The Expected Results (e.g., PR.AA‑01, RS.MI‑03)
Outcomes are the most detailed level. They describe what “good” looks like.
Examples:
- PR.AA‑01 – Identities are managed
- RS.MI‑03 – Incidents are contained
- DE.CM‑02 – Security telemetry is collected
Outcomes are the paragraphs that define the actual expectations.
The Simple Difference
- Functions = broad purpose
- Categories = capability areas
- Outcomes = specific expectations
Together, they give you a structured, measurable, modern way to build and improve your security program.
How to Use CSF 2.0 Mappings in Real Work
Most CSF explainers stop at “here’s the framework.” This section is the part practitioners actually need. How to use the mappings in day‑to‑day security work.
1. In a PIR (Post‑Incident Review)
Use Function + Category to anchor your actions:
- Mandatory cyber training → PR.AT
- Improve OAuth governance → PR.AA
- Improve SOC alerting → DE.CM
- Update IRP annually → ID.IM
This makes your PIR read like a structured, framework‑aligned document instead of a loose list of ideas.
2. In an IRP (Incident Response Plan)
Use Function → Category → Outcome to give your plan teeth:
- Containment actions follow RS.MI‑02
- Communications follow RS.CO‑03
Referencing the codes shows that your process is grounded in a recognised framework.
3. In Playbooks
Use Outcome‑level mapping for specific scenarios.
Example MFA fatigue playbook:
- PR.AA‑03 – Strong authentication enforced
- DE.AE‑02 – Anomalous sign‑in patterns detected
- RS.MI‑03 – Compromised sessions contained
Now your playbook isn’t just “steps”, it’s a concrete implementation of CSF 2.0 expectations.
4. In Remediation Tables
Use Category‑level mapping to keep remediation structured.
| Action | Mapping |
|---|---|
| Mandatory cyber training | PR.AT |
| Improve OAuth governance | PR.AA |
| Enhance SOC monitoring | DE.CM |
This makes it easy to roll remediation up into governance and reporting.
5. In Governance Documents
Use GOVERN (GV) to anchor leadership and oversight:
- GV.PO → Policies & procedures
- GV.OC → Oversight & culture
- GV.RM → Risk management strategy
This is where the new GOVERN function shines, it gives you a way to talk about security as a leadership responsibility, not just a technical one.
NIST CSF 2.0 Function → Category Mapping
Below is the high‑level mapping from the NIST CSF 2.0 core.
GOVERN (GV)
Leadership, oversight, and organisational direction.
| Category Code | Category Name |
|---|---|
| GV.OC | Oversight & Culture |
| GV.RM | Risk Management Strategy |
| GV.PO | Policy & Procedures |
| GV.SC | Supply Chain Risk Management |
(Improvement activities at the governance level are captured through GV.OC and ID.IM rather than a standalone “GV.IM” category.)
IDENTIFY (ID)
Understanding assets, risks, and organisational context.
| Category Code | Category Name |
|---|---|
| ID.AM | Asset Management |
| ID.RA | Risk Assessment |
| ID.IM | Improvement |
PROTECT (PR)
Controls that prevent or reduce the likelihood of incidents.
| Category Code | Category Name |
|---|---|
| PR.AA | Identity Management, Authentication & Access Control |
| PR.DS | Data Security |
| PR.PS | Platform Security |
| PR.MA | Maintenance |
| PR.AT | Awareness & Training |
DETECT (DE)
Monitoring, detection, and anomaly identification.
| Category Code | Category Name |
|---|---|
| DE.AE | Anomalies & Events |
| DE.CM | Continuous Monitoring |
| DE.IM | Improvement |
RESPOND (RS)
Actions taken during an incident.
| Category Code | Category Name |
|---|---|
| RS.MI | Mitigation |
| RS.CO | Communications |
| RS.AN | Analysis |
RECOVER (RC)
Restoring services and learning from incidents.
| Category Code | Category Name |
|---|---|
| RC.RP | Recovery Planning |
| RC.IM | Improvement |
| RC.CO | Communications |
Outcomes: What “Good” Looks Like
CSF 2.0 defines Outcomes under each Category. These are the specific expectations you can use as a checklist or design target.
Examples:
- GV.OC‑01 – Leadership sets clear cybersecurity expectations
- ID.AM‑02 – Assets are inventoried and owned
- PR.AA‑01 – Identities are managed throughout their lifecycle
- DE.CM‑03 – Security telemetry is collected and analysed
- RS.MI‑03 – Incidents are contained to limit impact
- RC.IM‑02 – Lessons learned are incorporated into recovery planning
You don’t need to memorise all 106 Outcomes. What matters is:
- knowing they exist
- knowing where to find them in the official CSF 2.0 core
- and using them as a reference when you design IRPs, PIRs, playbooks, and governance documents
Why This Reference Matters
Frameworks are only useful if they make real work easier.
Once you understand Functions, Categories, and Outcomes:
- your IRPs stop being “just documents” and become framework‑aligned plans
- your PIRs stop being “lists of lessons” and become structured improvement records
- your playbooks stop being “steps in a vacuum” and become concrete implementations of CSF 2.0 expectations
- your governance stops being “policy for policy’s sake” and becomes traceable back to recognised best practice
This article is the backbone behind the rest of the IRP series. It’s the piece you can point to when someone asks:
“What do all these CSF codes actually mean, and how do we use them?”
Now you have an answer.
Continue Reading
This is part of an ongoing series. If you want the full picture, the rest of the articles are worth your time.
How to Write an After Action Report (AAR) for Cyber Tabletop Exercises
How to Run a Cybersecurity Tabletop Exercise: Facilitator Script with Discussion Prompts
How to Run a Cybersecurity Tabletop Exercise: A Complete Example Scenario and Facilitation Guide
How to Write a Post-Incident Review (PIR) Report (With Real-World Example)
How to Build an Incident Response Plan: A Complete NIST CSF 2.0 Example
How to Write a Modern Incident Response Plan (IRP) Using NIST CSF 2.0
The Evolution of Incident Response: Updating the Classic NIST IRP to the 2026 Framework
