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:

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:

CSF Implementation Tiers

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.

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:

1. Where are we exposed? (Top 3-5 material risks)
2. What are we doing about it? (Specific investments, named owners, dates)
3. 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