| name | csf-mapping |
| description | Map your security posture against the NIST Cybersecurity Framework 2.0 (Govern, Identify, Protect, Detect, Respond, Recover). Produce a gap analysis, current/target tier assessment, and roadmap in the governance language that boards, auditors, and CISOs actually use. Use when the user mentions 'NIST CSF,' 'CSF 2.0,' 'cybersecurity framework,' 'security posture,' 'governance mapping,' 'CSF gap analysis,' 'CSF tiers,' 'cybersecurity maturity,' 'security roadmap,' 'CISO report,' 'board reporting,' 'security program,' or needs to translate technical findings into governance language. |
| allowed-tools | Read, Grep, Glob, Bash, WebSearch |
CSF Mapping — NIST Cybersecurity Framework 2.0 Posture Assessment
Translate your security posture into the language every CISO, board, auditor, and insurer already speaks. Distinct from the audit skills (which find specific issues); this skill assesses your program against a recognized framework and produces governance-ready output.
NIST CSF 2.0 is the framework that, as of 2024, replaced CSF 1.1. It added a sixth function — Govern — recognizing that the others can't work without governance backing.
The six functions:
| Function | What it covers |
|---|
| Govern (GV) | Cybersecurity strategy, roles, policies, oversight, supply chain risk |
| Identify (ID) | Asset inventory, business environment, risk assessment, supply chain |
| Protect (PR) | Access control, awareness, data security, baseline configurations, maintenance, protective tech |
| Detect (DE) | Continuous monitoring, anomaly detection, adverse event analysis |
| Respond (RS) | Incident management, analysis, mitigation, reporting, comms |
| Recover (RC) | Recovery planning, improvements, communications |
Each function contains Categories (e.g., PR.AA — Identity Management, Authentication, and Access Control), and each category contains Subcategories (e.g., PR.AA-01 — Identities and credentials for authorized users, services, and hardware are managed).
This skill maps your reality to those Subcategories.
Cross-references: every audit skill in this repo (they produce evidence that becomes the "current state" entries here), iam-audit (most of PR.AA), siem-detection (most of DE), incident-triage (most of RS), threat-modeling (informs ID.RA risk assessment), breach-patterns (informs ID.IM improvements from lessons learned).
Methodology
Step 1 — Establish scope
CSF assessments are scope-bounded. Decide which of these you're assessing:
- Whole organization — every system, every business unit
- One product / service — for vendor due-diligence questionnaires (SIG, CAIQ)
- One environment — production cloud only, or PCI-in-scope only
- Regulatory scope — HIPAA-covered systems, FedRAMP boundary, etc.
Write down what's in and what's out. Most CSF assessments fail at scope drift.
Step 2 — Choose your CSF profile
CSF 2.0 introduced Organizational Profiles — instead of "score every Subcategory equally," you tailor based on what matters.
- Current Profile — where you actually are
- Target Profile — where you want to be (informed by business goals, regulatory requirements, risk appetite)
- Community Profile — pre-built profile for your sector (manufacturing, healthcare, financial services — published by NIST and others)
For a first-pass assessment, start with a Community Profile if one exists for your sector, then tailor.
Step 3 — Assess each Subcategory
For each Subcategory in scope:
| Field | What to record |
|---|
| ID | e.g., PR.AA-05 |
| Subcategory text | Verbatim from NIST or paraphrased |
| Current state | What you actually do today (evidence, not aspiration) |
| Evidence | Document / system / process that proves the current state |
| Tier | Partial / Risk-Informed / Repeatable / Adaptive (1-4) |
| Target tier | What you're aiming for |
| Gap | The delta |
| Plan | What closes the gap |
| Owner | Who's accountable |
| Timeline | When |
CSF Implementation Tiers
| Tier | Name | Characteristic |
|---|
| 1 | Partial | Ad-hoc, reactive, undocumented; awareness is informal |
| 2 | Risk-Informed | Risk management is approved but not org-wide; processes are repeatable for some teams |
| 3 | Repeatable | Documented org-wide policies; consistent processes; risk-informed budgeting |
| 4 | Adaptive | Continuous improvement; quantitative risk; learning from incidents (yours and peers'); cybersecurity culture |
Tier 4 is rare and expensive. Most mature SaaS orgs target Tier 3 across most subcategories. Set targets based on what the business actually needs, not what looks good.
Step 4 — Identify gaps and prioritize
For each gap, ask:
- Impact if exploited / not addressed (regulatory, reputational, financial)
- Likelihood given current threat landscape and your specific exposure
- Cost to close (engineering hours, tooling, headcount)
- Dependencies on other gaps closing first
Prioritize by Risk × Cost-to-close — not just by risk. Some critical-risk items take a year and three vendors; some quick wins reduce real risk in a sprint.
Step 5 — Build the roadmap
CSF roadmaps usually run in quarters with annual targets. A useful structure:
- Next 30 days — immediate gaps (quick wins, low-cost high-risk items)
- Next 90 days — medium effort, named owners, defined success criteria
- Next 12 months — strategic gaps requiring budget approval, tooling decisions, headcount
- Annual review — full reassessment; profile refresh; tier movement
Each item on the roadmap names: the Subcategory it closes, the owner, the budget, the success metric, the review date.
Subcategory cross-references to skills in this repo
A useful shortcut — these are the audit skills that produce evidence for which CSF Subcategories.
| CSF Subcategory | Audit skill | Type of evidence |
|---|
GV.SC (Supply Chain Risk) | dependency-audit | CVE inventory, vendor list, supply chain risk register |
ID.AM (Asset Management) | cloud-audit, container-audit, recon | Asset inventory output |
ID.RA (Risk Assessment) | threat-modeling, breach-patterns | Threat models, breach-pattern coverage doc |
ID.IM (Improvement from past incidents) | incident-triage post-mortems, breach-patterns | Post-incident reviews, lessons-learned applied |
PR.AA (Identity & Access Control) | iam-audit | IAM audit reports, role inventory |
PR.DS (Data Security) | crypto-audit, secrets-audit | Crypto posture, secrets management posture |
PR.PS (Platform Security) | container-audit, cloud-audit | K8s hardening, cloud posture |
PR.IR (Infrastructure Resilience) | container-audit, cloud-audit | Network policy, segmentation, backup posture |
DE.CM (Continuous Monitoring) | siem-detection, soc-operations | SIEM coverage, ATT&CK Navigator export |
DE.AE (Anomaly & Event Analysis) | siem-detection, threat-hunting | Detection rule inventory, hunt findings |
RS.MA (Incident Management) | incident-triage, soc-operations | IR plan, runbooks, recent incident reports |
RS.AN (Analysis) |
For Subcategories without direct skill coverage, the gap is usually "we have technical depth but not the program-level artifact." E.g., RC.RP-01 (Recovery plan is executed during or after an incident) needs an actual documented and tested BCP/DR plan — running incident-triage doesn't automatically produce one.
High-impact gaps most orgs have
Patterns I see repeatedly in CSF assessments. Not universal, but starting points:
- GV.OC-04 (Critical objectives, capabilities, and services are identified and communicated) — Most orgs can't name their crown-jewel systems consistently across security, IT, and engineering
- GV.SC (Supply Chain Risk Management category) — Either no vendor risk program at all, or one that exists on paper but doesn't actually gate procurement
- ID.AM-08 (Systems, hardware, software, services, and data are managed throughout their life cycles) — Asset inventory is "the SaaS vendor's list" plus "what we remember"
- ID.IM-04 (Incident response plans are exercised) — Plan exists, last tested three years ago
- PR.AA-05 (Access permissions and authorizations are managed, incorporating the principles of least privilege) — Quarterly access review exists in policy, not in practice
- PR.DS-01 (The confidentiality, integrity, and availability of data-at-rest are protected) — Encryption at rest "yes," but key management is "ask AWS"
- DE.AE-08 (Incidents are declared when adverse events meet defined criteria) — Criteria not actually defined; "we'll know when we see it"
- RS.CO-02 (Internal and external stakeholders are notified of incidents) — Notification matrix is in someone's head
- RC.RP-01 (Recovery plan is executed) — Documented, never tested
Output Format
# NIST CSF 2.0 Posture Assessment
## Organization: [name]
## Scope: [what's in / out]
## Date: [date]
## Assessor: [name]
## Executive summary
[2-3 paragraphs in plain English — overall posture, top 3 risks, top 3 wins, recommended 90-day priorities]
## Profile
### Tier summary across functions
| Function | Current tier | Target tier |
|----------|--------------|-------------|
| GV | 2 | 3 |
| ID | 2 | 3 |
| PR | 3 | 3 |
| DE | 2 | 3 |
| RS | 3 | 3 |
| RC | 1 | 2 |
### Per-Subcategory detail
| Subcategory | Current state | Evidence | Tier | Target | Gap | Owner | Timeline |
|-------------|---------------|----------|------|--------|-----|-------|----------|
## Prioritized roadmap
### Next 30 days
- [Item, owner, success metric]
### Next 90 days
- [Item, owner, success metric]
### Next 12 months
- [Item, owner, success metric]
## Cross-references
[Links to evidence — audit reports, IR plans, IAM reports, etc.]
Translating to board language
Boards don't want Subcategory IDs. They want answers to three questions:
- Where are we exposed? (Top 3-5 material risks)
- What are we doing about it? (Specific investments, named owners, dates)
- How will we know we're better? (Quantitative metrics, target dates)
Use the CSF assessment as the backing detail. The board view is a one-page heatmap and three slides of priorities. The assessment goes in the appendix.
Boundaries
- This skill produces governance artifacts and roadmaps — not exploitation
- CSF assessments are not audits in the regulatory sense (SOC 2 audit, FedRAMP assessment, ISO 27001 certification audit are all separate processes); CSF mapping informs those but doesn't replace them
- For audited environments (PCI, HIPAA, FedRAMP), the auditor's specific framework is authoritative; CSF mapping is a useful complement
- Refuse to inflate tier ratings without evidence — Tier 3 means "evidence of documented org-wide processes," not "we hope to do this someday"
- Where the assessment surfaces a finding that needs immediate action (active incident, exposed system), hand off to
incident-triage or the relevant audit skill
References
- NIST Cybersecurity Framework 2.0 (
nist.gov/cyberframework)
- NIST CSF 2.0 Quick Start Guides
- NIST CSF Community Profiles (sector-specific starting points)
- NIST SP 800-53 (controls catalog — provides specific controls that map to CSF Subcategories)
- ISO 27001:2022 (alternative ISMS framework — frequently mapped against CSF for organizations doing both)
- CIS Critical Security Controls v8 (alternative prioritized framework — strong overlap with CSF)
- Cybersecurity Maturity Model Certification (CMMC) — for DoD contractors; uses CSF + NIST 800-171
- "Cybersecurity Risk Management: Mastering the Fundamentals Using the NIST Cybersecurity Framework" — Cynthia Brumfield
