THE ROOM WENT QUIET WHEN THE BOARD REALISED “WE’RE TIER 1, AREN’T WE?”

The CISO had just walked them through a slick heat map, a list of “critical” vulnerabilities, and three competing frameworks. Then a director asked, “So… are we good?”

He hesitated.

The slide deck said “aligned with NIST CSF”, but no one in the room could explain what their Core, Tier, or Profile really were—let alone how that translated into risk or budget.

If that sounds familiar, this article is your shortcut: a practical breakdown of NIST CSF 2.0’s structure—and how to turn it into action, not just another compliance logo.

What you’ll learn

• The structure of the NIST CSF 2.0 Core: Functions, Categories, and Subcategories
• How Implementation Tiers actually work—and what they don’t mean
• How to use Profiles (Current vs Target) to build a clear, defensible roadmap
• What’s new in CSF 2.0 (especially the Govern function and supply-chain focus)
• Real-world adoption patterns for enterprises, SMEs, and regulators
• A simple step-by-step way to start using CSF 2.0 in your organisation

Table of contents

• Understanding the NIST CSF 2.0 Core
• Implementation Tiers: Context, Not a Cybersecurity Score
• Framework Profiles: From Framework to Actionable Roadmap
• Governance and Supply Chain: What’s Truly New in CSF 2.0
• Real-World Ways Organisations Are Using CSF 2.0
• The Counter-Intuitive Lesson Most People Miss
• Key Terms Mini-Glossary
• FAQ
• Conclusion

Understanding the NIST CSF 2.0 Core

The CSF Core is the backbone of the framework: a structured catalogue of “what good looks like” in cybersecurity outcomes. In CSF 2.0 it is organised into six Functions—Govern, Identify, Protect, Detect, Respond, Recover—broken down into Categories and 106 Subcategories of specific outcomes [4][7].

If you understand the Core, you understand the framework. Everything else (Tiers, Profiles, tooling) is just how you decide how much and how fast to implement it.

How the Core is structured

At a high level:

• Functions – the big lifecycle buckets of activity
• Categories – logical groupings within each Function
• Subcategories – specific, measurable outcomes

In CSF 2.0 you have:

• Govern (GV) – strategy, risk appetite, roles, policies, supply-chain governance
• Identify (ID) – assets, business environment, risk assessment, third parties
• Protect (PR) – access control, data security, training, maintenance, protective tech
• Detect (DE) – anomalies, continuous monitoring, detection processes
• Respond (RS) – incident response planning, communications, analysis, mitigation
• Recover (RC) – recovery planning, improvements, communications

Version 1.1 had 108 Subcategories; 2.0 reorganises these and adds governance outcomes, resulting in a streamlined set of 106 Subcategories [3]. That sounds heavy, but you almost never need to implement all 106 at once—especially in smaller environments [2].

Practical use: turning the Core into day‑to‑day work

Think of each Subcategory as a user story:

“We maintain an up-to-date inventory of hardware assets” (ID.AM).
“Multi-factor authentication is enforced for privileged accounts” (PR.AC).

You can map each of these to:

• Policies
• Technical controls (e.g., MFA, EDR, backup)
• Processes (e.g., joiner/leaver, incident playbooks)
• Metrics (e.g., % of assets inventoried, mean time to detect)

Smart starting point for SMEs: research shows that as few as six high-impact controls (mostly within Identify and Protect) reduce the likelihood of commodity incidents by up to 80% [2]. You can treat those as your “minimum viable Core” and expand over time.

Common pitfalls

• Treating the list as a rigid checklist instead of a menu of outcomes
• Jumping straight into tools (“we bought X”) without mapping coverage to Functions
• Ignoring Govern and Identify, and over‑investing only in Protect and Detect

Key Takeaway
The Core is not a control library—it is a language for desired outcomes. Once you map your existing policies and tools to Core outcomes, you can finally see where your true gaps are.

Evidence: CSF 2.0 explicitly defines the Core as “a set of cybersecurity outcomes and associated security controls” rather than a prescriptive set of requirements [4][10].

Implementation Tiers: Context, Not a Cybersecurity Score

Implementation Tiers describe how formally and consistently your organisation manages cybersecurity risk; they do not certify whether you are “secure”. CSF 2.0 retains four Tiers—Partial, Risk-Informed, Repeatable, Adaptive—used to align effort with risk appetite and resources [4][8].

The fastest way to misuse the CSF is to treat Tiers as a vanity metric or a marketing badge.

What the four Tiers actually mean

• Tier 1 – Partial
  Ad hoc, reactive; limited awareness of risk at the organisational level.
• Tier 2 – Risk-Informed
  Some risk processes exist; not yet enterprise-wide, but decisions are informed by risk analysis.
• Tier 3 – Repeatable
  Policies, standards, and procedures are formally defined, implemented, and reviewed.
• Tier 4 – Adaptive
  Continuous improvement based on lessons learned, analytics, and threat intelligence [4][8].

A Tier 2 startup in a high-risk sector may be in better shape than a Tier 3 municipal agency that has outdated controls but plenty of paperwork.

How to use Tiers in practice

Use Tiers for three conversations:

1. Internal alignment – “Given our size and risk, what Tier should we be aiming for in the next 24 months?”
2. Budget planning – moving from Tier 1→2 might be training and basic tooling; 2→3 usually requires more process and headcount.
3. External expectations – some regulators and cyber insurers already use CSF-like scales to price risk [2][5].

A simple approach:

• Assess your current Tier per Function (you may be Tier 3 in Protect but Tier 1 in Govern).
• Decide a realistic Target Tier per Function (e.g., Tier 2 across the board, Tier 3 in Protect/Detect).
• Build a short list of initiatives that move the dial (e.g., formal risk register to move Identify from 1→2).

Pitfalls to avoid

• Chasing Tier 4 everywhere when your sector and budget don’t justify it (Tier 4 is expensive and really aimed at critical infrastructure, defence, and similar high‑impact sectors [4]).
• Declaring a single “Tier 3 organisation” without acknowledging variation by Function.
• Treating Tier labels as compliance scores instead of risk-management context.

Mini‑Checklist: Quick Tier Sanity Check

• Do we know which Function we’re assigning this Tier to?
• Can we name two concrete behaviours that justify that Tier?
• Does this Tier align with our documented risk appetite?
• Can we explain to the board why we don’t need Tier 4 in some areas?

Evidence: NIST emphasises that Tiers are “not intended to be maturity levels” but descriptive of how risk is managed, to support risk-informed decisions [4][8].

Framework Profiles: From Framework to Actionable Roadmap

Profiles are where the CSF becomes a planning tool instead of a poster. A Profile is your customised alignment between the Core and your business requirements—usually expressed as a Current Profile and a Target Profile [3][8].

The gap between those two is your roadmap, including priorities, budget, and timelines.

Building Current and Target Profiles

Current Profile answers: What are we actually doing today?

• For each relevant Subcategory, you note whether it is:
  • Fully achieved
  • Partially achieved
  • Not in place
• You can optionally map to Tiers or internal risk scores.

Target Profile answers: What should we be doing, given our risks and obligations?

• You select the outcomes that are:
  • Required by law or regulation
  • Required by contracts or customer expectations
  • Prudent given your risk appetite

The profile difference becomes a list of initiatives like “Implement MFA for all privileged users (PR.AC)”, “Establish vendor risk assessments (GV.SC, ID.SC)”, etc.

A simple profile-building workflow

1. Define scope – whole organisation, a business unit, or a critical system.
2. Select relevant outcomes – you may ignore Subcategories that clearly don’t apply.
3. Assess the Current state – quick workshops with IT, security, ops, and business owners.
4. Design the Target Profile – with input from risk, legal, and leadership.
5. Prioritise gaps – focus first on high-impact, low-effort items (e.g., MFA, backups).
6. Assign owners and timelines – convert each gap into a project or work item.

Real-world data: one state-level audit found that only 28% of 450 municipalities could even produce a CSF Profile; the rest had scattered controls but no coherent roadmap [1]. That’s exactly the problem Profiles are intended to solve.

Key Takeaway
Profiles translate a big abstract framework into your plan. If you’re “doing CSF” without a Profile, you’re leaving most of the value on the table.

Evidence: NIST defines a Profile as “the alignment of the Framework Core with the organisation’s requirements, risk tolerance, and resources” and recommends using Current vs Target Profiles for gap analysis and improvement planning [3][8][10].

Governance and Supply Chain: What’s Truly New in CSF 2.0

CSF 2.0’s biggest structural change is the explicit Govern (GV) Function at the centre of the framework. It captures organisational context, risk management strategy, roles and responsibilities, policies, oversight, and supply-chain risk [4][7].

This is a response to reality: cyber risk is now a board-level, enterprise risk issue—not just an IT problem.

What the Govern Function covers

Govern is divided into Categories such as:

• GV.OC – Organisational Context
  Understanding mission, stakeholders, and legal/regulatory environment.
• GV.RM – Risk Management Strategy
  Documented risk appetite, criteria, and decision processes.
• GV.RR – Roles, Responsibilities, Authorities
  Who owns what, and how they are empowered.
• GV.PO – Policy
  Cybersecurity policies that are current, approved, and communicated.
• GV.OV – Oversight
  Board or senior-management oversight of cyber risk.
• GV.SC – Cybersecurity Supply Chain Risk Management
  How you set requirements and monitor third parties.

In practice, this means you should be able to answer, in plain language:
“Who is accountable for cyber risk? How much risk are we willing to take? What do we expect from our vendors?”

Why supply-chain got its own spotlight

Attacks like SolarWinds and countless compromised MSPs showed that your security is only as strong as your weakest supplier. CSF 2.0 responds by:

• Explicitly calling out supply-chain risk in both Govern and Identify
• Encouraging organisations to set and communicate minimum expectations to vendors
• Aligning more closely with related standards like NIST SP 800‑171 and CMMC [4][7]

For many mid-size firms, this is the first time third‑party risk is treated as a first-class citizen rather than an afterthought.

Pro Tip
If you don’t have the capacity for a full third‑party risk programme, start small:

• Require MFA and patching SLAs in contracts for critical vendors
• Ask for evidence of some recognised framework (CSF, ISO 27001, SOC 2)
• Maintain a simple critical vendor inventory with data-flow notes

Evidence: Surveys cited in CSF 2.0 development show boards and CIOs expect the new Govern function to drive more formal cyber-risk committees and clearer supply-chain oversight [3][5].

Real-World Ways Organisations Are Using CSF 2.0

On paper, CSF 2.0 is “voluntary guidance”. In reality, it’s becoming a de facto global baseline: more than 130 countries reference it in policy, and around 60% of large US enterprises use CSF terminology in board reports [5].

But adoption looks very different in a 30-person SaaS startup, a city government, and a multinational bank.

Typical adoption patterns

Small and mid-size enterprises (SMEs)

• Use a subset of high-impact controls (e.g., asset inventory, backups, MFA, training) [2].
• Build a lightweight Current/Target Profile in spreadsheets.
• Leverage the framework to negotiate cyber insurance discounts once they reach a defined maturity baseline [2].

Large enterprises

• Map CSF 2.0 against existing frameworks (ISO 27001, NIST 800‑53, SOC 2) to harmonise controls.
• Use Tiers and Profiles at business-unit level to prioritise investments.
• Automate evidence collection and reporting using GRC tools that ingest the CSF 2.0 JSON schema [3].

Public sector and regulators

• Mandate minimum maturity levels or specific CSF-aligned practices in banking, energy, and telecom sectors [1][5].
• Use Profiles as part of supervisory assessments and incident reporting templates.

Turning CSF into decisions, not just documents

Concrete examples of CSF 2.0 driving real change:

• Budget justification – tying investment requests to Target Profile gaps (“To move Protect from Tier 1 to Tier 2, we need X and Y”).
• Insurance leverage – insurers offering lower premiums where clients can show documented, independently-verified CSF maturity [2].
• Policy rationalisation – universities and hospitals consolidating overlapping policies into a CSF-aligned structure to reduce maintenance overhead [6].

Key Takeaway
The organisations getting the most value from CSF 2.0 use it as a decision framework: for budgets, priorities, vendor expectations, and board reporting—not just as a badge on a slide.

Evidence: Multiple surveys and case studies show growing CSF references in board reporting, regulatory mandates in certain sectors, and insurer use of CSF-like maturity scales to price risk [1][2][5][6].

The Counter-Intuitive Lesson Most People Miss

The most counter-intuitive aspect of NIST CSF 2.0 is that you can—and often should—start small. Many assume a framework with 106 Subcategories and a central Governance wheel must be implemented “end-to-end” to be worthwhile. The data and field experience suggest the opposite.

High-performing SMEs often begin with a tiny subset of controls and a very rough Profile, yet achieve meaningful risk reduction much faster than bigger organisations chasing full, formal alignment.

Why “smaller and sharper” beats “big and blurry”

Several realities drive this:

• Diminishing returns – a handful of well-chosen controls (especially in Identify and Protect) block most opportunistic attacks [2].
• Execution capacity – a 20-person company doesn’t have the staff to manage 106 outcomes; focusing on the top 10-20 that truly matter is more honest and effective.
• Clarity for people – staff can actually remember and follow a short, CSF-aligned playbook.

On the other hand, sprawling programmes that try to cover every Subcategory from day one often stall. They produce documentation, not resilience.

How to apply this lesson without cutting corners

• Use the Core to identify your “vital few” outcomes.
• Build a very small Target Profile for the first 6–12 months (perhaps a single page).
• Treat Tier and Profile scores as guides, not goals.
• Only expand once your initial set of outcomes is genuinely embedded in day-to-day work.

Mini‑Checklist: Are We Overbuilding Our CSF Programme?

• Do we know which Function we’re assigning this Tier to?
• Can we name two concrete behaviours that justify that Tier?
• Does this Tier align with our documented risk appetite?
• Are we writing policies no one reads, instead of fixing obvious gaps?

This “start small, then scale” approach is built into the framework’s design principles: NIST emphasises that the CSF is intended to be “prioritised, flexible, and cost-effective” rather than all-or-nothing [3][10].

Key Terms Mini-Glossary

• NIST CSF 2.0 – The 2024 version of the NIST Cybersecurity Framework, a voluntary, risk-based guide for managing cyber risk across any sector [4].
• Core – The heart of the CSF, structured into Functions, Categories, and Subcategories that describe desired cybersecurity outcomes [3][8].
• Function – A high-level group of cybersecurity activities (Govern, Identify, Protect, Detect, Respond, Recover) representing the risk-management lifecycle [4][7].
• Category – A subdivision within a Function that groups related outcomes (e.g., Asset Management under Identify) [3].
• Subcategory – The most granular outcome in the Core; a concrete statement of “what good looks like” (e.g., “hardware assets are inventoried”) [8].
• Implementation Tier – A qualitative description (Partial to Adaptive) of how an organisation manages cybersecurity risk, used for context rather than certification [4].
• Profile – An organisation’s alignment of the Core with its specific requirements and risk tolerance, usually expressed as Current and Target states [3][10].
• Govern Function (GV) – The central CSF 2.0 Function covering organisational context, risk strategy, roles, policy, oversight, and supply-chain risk [4][7].
• Supply-Chain Risk Management – The process of identifying, assessing, and managing cybersecurity risks introduced by third-party vendors and partners [4][7].
• GRC Tooling – Governance, Risk, and Compliance software that automates evidence collection, control mapping, and reporting against frameworks like CSF 2.0 [3][6].

FAQ

1. Is NIST CSF 2.0 mandatory?

For most private-sector organisations, CSF 2.0 is voluntary guidance, not a regulation. However, it is mandatory or effectively required in some US federal contexts and is increasingly referenced by regulators and insurers as an expected baseline [5][8].

2. How is CSF 2.0 different from 1.1?

CSF 2.0 adds the Govern Function, strengthens supply-chain guidance, updates and clarifies Subcategory language, and expands implementation examples and mappings. It also broadens scope beyond “critical infrastructure” to all organisations [4][7][10].

3. Do we need to implement all 106 Subcategories?

No. NIST explicitly designed the CSF to be prioritised and flexible. Many SMEs start with a subset of high-impact outcomes and expand gradually as their capability and risk profile evolve [2][3].

4. How does CSF compare to ISO 27001 or SOC 2?

CSF is a framework of outcomes, not a certifiable standard. ISO 27001 and SOC 2 are audit schemes with specific requirements. Many organisations use CSF as an overarching blueprint and map its outcomes to ISO, SOC 2, and other standards they must comply with [6][8].

5. Who should own the CSF programme in an organisation?

Ownership varies, but best practice is joint stewardship: Govern elements sit with executive risk/governance functions, while operational Functions (Identify, Protect, etc.) are usually led by the CISO or security lead with strong business involvement [5][7].

6. How long does it take to build a first CSF profile?

With focused workshops and a pragmatic scope, many organisations can produce an initial Current/Target Profile in a few working days. Larger, multi-entity organisations may take longer, but months-long efforts are usually a sign of overengineering rather than framework necessity [2][3].

Conclusion

Back in that quiet boardroom, the problem wasn’t that the organisation lacked controls—it was that nobody could map them clearly to Core outcomes, Tiers, or a Profile the business understood. Once they reframed their thinking around CSF 2.0’s structure, the conversation changed from “Are we secure?” to “Which outcomes matter most, and what will it cost to achieve them?”

That is the real power of NIST CSF 2.0:

• The Core gives you a shared language.
• The Tiers give you context and realism.
• The Profiles give you a roadmap.
• The Govern Function connects it all to strategy, supply chain, and accountability.

If your organisation is still juggling disconnected controls and compliance checklists, use CSF 2.0 as the backbone of a single, coherent story about cyber risk and improvement. Start small, be brutally honest about your Current Profile, and use the framework to focus your next twelve months of effort where it will actually move the needle.