NIST Cybersecurity Framework (CSF): NIST Cybersecurity Framework – Tutorial (about 60 minutes)

The NIST Cybersecurity Framework (CSF) is a free, voluntary framework from the US National Institute of Standards and Technology (NIST) that describes, in plain language, the cybersecurity outcomes an organisation should aim for and gives it a common way to talk about cybersecurity risk. It is used by companies, public bodies, universities and charities of every size, inside and outside the United States, by security teams, risk and compliance staff, IT managers and executives alike. After this tutorial you will be able to read the CSF Core, explain its six Functions, build Current and Target Profiles, choose sensible Tiers and use the framework alongside standards such as ISO/IEC 27001, NIST SP 800-53 and the CIS Controls.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is The NIST Cybersecurity Framework (CSF) 2.0, published by NIST as Cybersecurity White Paper NIST CSWP 29 on 26 February 2024 (a public draft appeared in August 2023). It replaced version 1.1 of April 2018, which was titled Framework for Improving Critical Infrastructure Cybersecurity. As of the verification date, NIST's CSF website lists 2.0 as the current, final version and announces no successor draft; NIST deliberately updates the core document rarely, while the supporting online resources (Quick-Start Guides, Informative References, Implementation Examples, Community Profiles) are revised on their own schedule. This course teaches CSF 2.0. Verified 2026-10-29.

Who this is for: engineers and IT staff who are asked to "align with NIST", security analysts and architects, risk, audit and compliance professionals, project and product managers who must report on security, and leaders who need a structured way to discuss cybersecurity with a board, customers or regulators.

Prerequisites: none. A rough idea of what risk means (something uncertain that could affect your objectives) helps, but every term is defined when it first appears.

By the end of this tutorial:

You will be able to explain why NIST created the CSF, what changed in version 2.0 and why the framework is voluntary and outcome-based.
You will be able to describe the three components of the CSF: the Core, Organizational Profiles and Tiers.
You will be able to name the six Functions and recognise the kind of outcomes grouped in each of their Categories.
You will be able to follow the five steps for creating and using an Organizational Profile and turn gaps into a prioritised action plan.
You will be able to select realistic Tiers and explain why a higher Tier is not automatically better.
You will be able to explain how use of the CSF is assessed and why there is no official NIST certification.
You will be able to position the CSF next to ISO/IEC 27001, NIST SP 800-53, the CIS Controls and the NIST Privacy Framework.

Lesson 1 – Origins, purpose and scope

Why the framework exists

By the early 2010s it was clear that cyber attacks could disrupt power grids, banks, hospitals and water systems, and that most of this critical infrastructure in the United States was owned by private companies. The government could not simply order every company to install the same controls: sectors differ enormously, technology changes fast and many good standards already existed. In February 2013 a US presidential Executive Order (EO 13636) asked NIST to work with industry to produce a voluntary framework that would help critical infrastructure organisations manage cybersecurity risk using existing standards and practices. After a year of workshops and public comment, NIST published version 1.0 in February 2014. The Cybersecurity Enhancement Act of 2014 then gave NIST an ongoing role in developing and updating it.

The framework quickly spread beyond its original audience. Companies with no critical infrastructure role, governments in other countries and small businesses found it useful because it was free, readable and not tied to any product, country or sector. Version 1.1 (April 2018) added material on supply chain risk, identity and self-assessment. In 2017 a further Executive Order directed US federal agencies to use the framework to manage their own cybersecurity risk.

What changed in version 2.0

NIST began the update to 2.0 with a request for information in 2022, published a concept paper and a public draft, and released the final version in February 2024. The main changes are:

Broader audience. The title no longer mentions critical infrastructure. The framework now addresses organisations of every size, sector and level of maturity.
A sixth Function, GOVERN. Outcomes about strategy, roles, policy, oversight and supply chain risk management were gathered into a new Function placed at the centre of the framework. Version 1.1 had five Functions.
A reorganised Core. The Core went from 23 Categories and 108 Subcategories to 22 Categories and 106 Subcategories. Some outcomes moved (for example, supply chain risk management moved from IDENTIFY to GOVERN), and new Categories such as Platform Security and Technology Infrastructure Resilience replaced older, more technology-specific ones.
Online resources. Implementation Examples, Informative References, Quick-Start Guides and Community Profiles are published and updated online, outside the main document, so they can change more often and be downloaded in machine-readable form.
Clearer Profiles and Tiers. "Framework Profiles" became Organizational Profiles and Community Profiles; "Implementation Tiers" are now simply called Tiers and are described separately for governance and management.

Purpose in one sentence

The CSF helps an organisation understand, assess, prioritise and communicate its cybersecurity risks. It does this by giving everyone, from the board to the system administrator, a shared list of desirable results. It says what good looks like; it deliberately does not say how to achieve it. The "how" is left to the organisation, guided by other standards, its own context and the online resources NIST links to.

Scope

The outcomes are written to be neutral about sector, country and technology. They apply to all information and communications technology (ICT) an organisation uses, including traditional IT, operational technology (OT) such as industrial control systems, the Internet of Things (IoT), cloud and mobile environments and systems that use artificial intelligence. The framework can be applied to a whole organisation or to a part of it, such as one product line, one data centre or one threat such as ransomware. It is voluntary in itself, although governments, regulators or customers may make its use a requirement in a contract or policy.

Lesson 2 – Key concepts and vocabulary

The CSF uses a small vocabulary very consistently. Learning these terms well makes the rest of the framework easy to read.

Cybersecurity risk – the possibility that a threat exploits a weakness in technology, people or processes and harms the organisation, the people it serves or others, combined with how likely that is and how bad it would be.
Outcome – a desired result stated without prescribing the method. "Backups are created, protected and tested" is an outcome; "use product X nightly" would be a method.
CSF Core – the taxonomy (structured list) of cybersecurity outcomes at the heart of the framework, arranged as Functions, Categories and Subcategories.
Function – the highest grouping of outcomes. There are six, each named with a verb: GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND and RECOVER.
Category – a group of related outcomes inside a Function, such as Asset Management or Incident Analysis. Each has a short identifier like ID.AM.
Subcategory – a more specific technical or management outcome inside a Category, identified like ID.AM-01. Subcategories are not an exhaustive list of everything an organisation might do.
Informative Reference – a mapping that links a Core outcome to a passage in another standard, guideline or regulation that helps achieve it, for example a control in NIST SP 800-53.
Implementation Example – a short, action-oriented illustration of one possible way to achieve a Subcategory, using verbs such as document, monitor, assess or exercise. Examples are notional, not mandatory.
Organizational Profile – a description of an organisation's cybersecurity posture expressed in terms of Core outcomes. It contains a Current Profile, a Target Profile or both.
Current Profile – the part of an Organizational Profile that records which outcomes are being achieved today and how well.
Target Profile – the part that records the outcomes the organisation has chosen and prioritised for the future, taking expected changes such as new laws, technologies and threats into account.
Community Profile – a baseline of CSF outcomes published for a group of organisations with shared interests, such as a sector, a technology or a threat type. An organisation can adopt it as the starting point for its own Target Profile.
Tier – a characterisation of how rigorous an organisation's cybersecurity risk governance and management practices are, from Tier 1 (Partial) to Tier 4 (Adaptive).
Gap analysis – the comparison of Current and Target Profiles to find and understand the differences that need action.
Action plan – a prioritised list of work to close gaps, often kept as a risk register or a Plan of Action and Milestones (POA&M).
Risk appetite and risk tolerance – the broad amount and type of risk leadership is willing to pursue or retain (appetite), and the acceptable variation around specific objectives (tolerance). Both are set under GOVERN.
Cybersecurity supply chain risk management (C-SCRM) – managing the cybersecurity risks that come from suppliers, products and services the organisation buys or depends on.
Enterprise risk management (ERM) – the organisation-wide practice of managing all kinds of risk (financial, legal, operational, cyber and others) together so leadership can make balanced decisions.

Outcomes, not a checklist

The most important idea in this vocabulary is that the Core lists outcomes. NIST states clearly that the Core is not a checklist of actions, and that the order and size of Functions, Categories and Subcategories says nothing about which comes first or which matters most. Two organisations may achieve the same Subcategory in very different ways: a five-person design studio might protect its backups with an encrypted cloud service, while a bank uses immutable storage in several data centres. Both can honestly say the outcome is achieved for their risk level.

Another way to see this: the Core is the "what", the Informative References and Implementation Examples are hints about the "how", the Profiles record "where we are and where we want to be", and the Tiers describe "how rigorously we manage all of this".

Lesson 3 – Structure of the framework

Three components plus online resources

CSF 2.0 has three components. The Core is the hierarchy of outcomes. Organizational Profiles describe a current or target posture using those outcomes. Tiers can be applied to Profiles to describe the rigour of governance and management. Around these three components NIST maintains a suite of online resources: Informative References, Implementation Examples, Quick-Start Guides, Organizational Profile templates and a repository of Community Profiles. The CSF 2.0 Reference Tool on the NIST website lets you browse the Core with its References and Examples and export them as spreadsheets or machine-readable files.

Figure 1 – The Core is a three-level hierarchy of outcomes; online Examples and References suggest how each Subcategory can be achieved.

The six Functions

Each Function is summarised below in plain words, followed by its Categories with their identifiers. The Category names are public; the descriptions are paraphrased.

GOVERN (GV) – set direction and oversee

GOVERN covers how the organisation decides what cybersecurity must achieve, who is accountable and how leaders check that it is working. It connects cybersecurity to the organisation's mission and to enterprise risk management. Its six Categories are Organizational Context (GV.OC: mission, stakeholders, legal and contractual requirements, dependencies), Risk Management Strategy (GV.RM: objectives, risk appetite and tolerance, standard methods for describing risk, and positive risks or opportunities), Roles, Responsibilities, and Authorities (GV.RR: leadership accountability, resources and cybersecurity in HR practices), Policy (GV.PO), Oversight (GV.OV: reviewing strategy and performance and adjusting) and Cybersecurity Supply Chain Risk Management (GV.SC). GOVERN is the largest Function, with 31 Subcategories.

IDENTIFY (ID) – understand current risk

IDENTIFY is about knowing what you have and what could go wrong with it. Asset Management (ID.AM) covers inventories of hardware, software, services, data and network flows and their prioritisation. Risk Assessment (ID.RA) covers vulnerabilities, threat intelligence, likelihood and impact, choosing responses to risks, change management and vulnerability disclosure. Improvement (ID.IM) is new in this place in 2.0: it collects lessons from evaluations, tests, exercises, daily operations and incidents so that every Function gets better over time.

PROTECT (PR) – apply safeguards

PROTECT uses safeguards to lower the likelihood and impact of adverse events. Its five Categories are Identity Management, Authentication, and Access Control (PR.AA), Awareness and Training (PR.AT), Data Security (PR.DS: data at rest, in transit and in use, and backups), Platform Security (PR.PS: configuration, maintenance, software installation and logging on physical and virtual platforms) and Technology Infrastructure Resilience (PR.IR: architectures that protect networks and keep enough capacity and redundancy).

DETECT (DE) – find and analyse possible attacks

DETECT makes it possible to discover anomalies, indicators of compromise and other suspicious events in good time. Continuous Monitoring (DE.CM) watches networks, the physical environment, personnel activity, external service providers and computing environments. Adverse Event Analysis (DE.AE) correlates and analyses what monitoring finds, estimates impact and declares incidents when criteria are met.

RESPOND (RS) – act on detected incidents

RESPOND contains the effects of an incident. Incident Management (RS.MA) runs the response plan, triages and prioritises incidents and escalates them. Incident Analysis (RS.AN) investigates what happened and preserves evidence. Incident Response Reporting and Communication (RS.CO) informs internal and external stakeholders, including regulators where required. Incident Mitigation (RS.MI) contains and eradicates the incident.

RECOVER (RC) – restore normal operations

RECOVER restores assets and services affected by an incident. Incident Recovery Plan Execution (RC.RP) covers selecting recovery actions, checking the integrity of backups before restoring, verifying restored systems and formally declaring the end of recovery. Incident Recovery Communication (RC.CO) coordinates updates to stakeholders and the public during restoration.

Why the Functions are drawn as a wheel

NIST draws the Functions as a wheel with GOVERN in the middle, because governance informs how the other five are carried out and because all of them relate to each other. Assets categorised under IDENTIFY are secured under PROTECT; planning and testing under GOVERN and IDENTIFY make detection, response and recovery faster. The Functions are meant to run concurrently, not one after another. GOVERN, IDENTIFY, PROTECT and DETECT activities happen continuously. RESPOND and RECOVER capabilities must be ready at all times and are exercised when an incident occurs.

Figure 2 – GOVERN steers the five other Functions; prevention and detection run continuously while response and recovery stay ready.

Reading a Subcategory

Subcategories follow the pattern FUNCTION.CATEGORY-number, for example PR.DS-11 in Data Security, which concerns backups being created, protected, maintained and tested. The numbering has deliberate gaps: where a version 1.1 Subcategory was moved or withdrawn, its number was not reused, which helps people compare old and new mappings. NIST publishes a spreadsheet that maps the 1.1 Core to the 2.0 Core for organisations making the transition.

Profiles and Tiers in the structure

Profiles and Tiers do not add more outcomes; they are ways of using the Core. A Profile selects the outcomes relevant to a scope and records current and target states. Tiers describe the rigour of practices across four levels, with separate descriptions for cybersecurity risk governance (matching GOVERN) and cybersecurity risk management (matching the other five Functions). Lesson 4 shows how they are used together.

Lesson 4 – How it works in practice

The five-step Profile process

The CSF describes one practical way to use Organizational Profiles to drive continuous improvement. NIST's Quick-Start Guide on Organizational Profiles (SP 1301) expands it with questions and a spreadsheet template.

Scope the Profile. Write down the facts and assumptions the Profile rests on: why you are creating it, which parts of the organisation, systems, data, suppliers and threats it covers, and who will build, approve and use it. An organisation can maintain several Profiles with different scopes, for instance one for corporate IT, one for factory OT and one focused on ransomware.
Gather information. Collect policies, risk priorities, business impact analyses (BIA), enterprise risk registers, legal and contractual requirements, existing standards, procedures, tools and work roles. A relevant Community Profile is often a valuable input.
Create the Profile. Decide which outcomes apply and what information to record for each. For the Current Profile, document the practices in place, their status and a rating. For the Target Profile, document goals and their priority. Consider the risk implications of the current state when setting priorities.
Analyse gaps and create an action plan. Compare the two Profiles outcome by outcome, understand why each gap matters, and write a prioritised plan (risk register, risk detail report or POA&M) with owners, resources and dates.
Implement the plan and update the Profile. Carry out the work, then update the Current Profile to reflect progress. Repeat the cycle as often as needed, because requirements, technology and threats keep changing.

Figure 3 – The five steps for creating and using an Organizational Profile form a continuous improvement loop.

What a Profile actually looks like

Most organisations keep Profiles in a spreadsheet, and NIST provides a notional template. Each row is a Core outcome, usually at Subcategory level. Typical columns for the Current Profile are practices (the policies, procedures and tools in place, with links to evidence), status (whether and to what degree the outcome is achieved) and rating (on any scale the organisation prefers, such as low/medium/high, 1 to 5 or a percentage). Target Profile columns usually include priority and goals, the latter often drawing on Informative References. You may add, remove or rename columns, and you may add your own outcomes for risks the Core does not cover. The framework cares about the decisions the Profile supports, not the exact format.

A good Profile row reads like a short story: "We have a configuration policy, but baselines exist only for Windows servers; partially achieved; rated 2 of 5. Target: baselines for all servers and network devices, checked automatically; priority high, because misconfiguration featured in two recent incidents."

Choosing Tiers

Tiers give a broader picture than individual Profile rows. They describe how an organisation views cybersecurity risk and the processes it uses to manage it:

Tier 1 – Partial: cybersecurity is handled case by case. Priorities are not formally linked to objectives or threats, awareness of risk is limited and supplier risk is largely unknown.
Tier 2 – Risk Informed: management approves risk practices and priorities are informed by objectives and threats, but there is no organisation-wide approach, assessments are not repeated regularly and information is shared informally.
Tier 3 – Repeatable: practices are formally approved as policy, applied across the organisation and regularly updated. Staff have the skills for their roles, monitoring is consistent and supplier risks are acted on through agreements and governance structures.
Tier 4 – Adaptive: the organisation adapts continuously using lessons learned and predictive indicators, executives monitor cyber risk in the same context as financial and other risks, budgets reflect the current and predicted risk environment, supplier risks are acted on using real-time or near real-time information, and cybersecurity information is shared constantly inside the organisation and with authorised third parties.

Figure 4 – Tiers describe increasing rigour; leadership chooses a target Tier by weighing risk, obligations and cost, not by aiming for the top.

Tier selection is a leadership decision. NIST's Tiers Quick-Start Guide (SP 1302) suggests choosing Tiers for the organisation as a whole or per Function or Category, rather than per Subcategory, and considering current practices, the threat environment, legal and regulatory requirements, information sharing, business objectives, supply chain requirements and constraints such as budget. Progressing to a higher Tier is encouraged when risks or mandates justify it or a cost-benefit analysis shows it is worthwhile. A small low-risk business may reasonably target Tier 2 for most areas; a payment processor will probably need Tier 3 or 4. The chosen Tiers then inform the Profiles: if leadership wants Tier 3 for PROTECT, the Target Profile should describe Protect outcomes that are formally defined, consistently applied and reviewed.

Who does what

The CSF encourages information to flow in both directions between three levels. Executives set mission priorities, risk appetite, accountability and resources, and integrate cyber risk with ERM. Managers translate those expectations into Target Profiles and action plans for their business units. Practitioners implement and operate the safeguards and report measurements such as key performance indicators (KPIs) and key risk indicators (KRIs) back up the chain. Updated priorities then flow down again in the next version of the Profiles.

Figure 5 – The CSF supports two-way risk communication between executives, managers and practitioners and links cyber risk to enterprise risk management.

Using the online resources

Once you know your gaps, the online resources help you close them. Implementation Examples suggest concrete first actions for each Subcategory. Informative References point to detailed guidance; you should pick the references most relevant to your situation rather than trying to satisfy every mapping. Quick-Start Guides offer short, audience-specific advice: NIST has published guides on small businesses (SP 1300), Organizational Profiles (SP 1301), Tiers (SP 1302), enterprise risk management (SP 1303), supply chain risk management (SP 1305), cybersecurity, ERM and workforce management (SP 1308) and Informative References (SP 1347), among others, plus a resource and overview guide (SP 1299).

Lesson 5 – Assessment, certification and compliance

There is no official CSF certification

NIST's CSF FAQ states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and that it does not intend to create a formal conformity testing programme. The framework is guidance: it has no "shall" requirements an auditor could test for pass or fail, and every organisation tailors it. A statement such as "we are NIST CSF certified" therefore does not refer to anything NIST issues. Some consultancies and private schemes offer CSF-based assessments or attestations, and these can be useful, but they are their own products and their value depends on who performed them, what scope they covered and what evidence they examined.

When someone says they "comply with" or "are aligned to" the CSF, the sensible follow-up questions are: Which Profile scope? Who assessed it, internally or independently? What scale and evidence were used? What were the gaps, and what is the action plan?

How organisations assess their use of the CSF

Self-assessment. The most common approach. A team rates each in-scope outcome in the Current Profile, ideally with evidence such as policies, configuration exports, tickets, test reports and training records. The Profile template's status and rating columns support this directly.
Internal audit. Internal auditors use the Core as a structured checklist of areas to examine and test whether stated practices really operate. They often report by Function or Category so the board can see where risk sits.
Independent assessment. An external firm reviews the Profile, interviews staff and samples evidence. This adds credibility for boards, investors, insurers and customers, but it is still an assessment, not a NIST certification.
Tier review. Leadership compares actual practices with the Tier descriptions for governance and management to see whether the organisation operates at the rigour it intended.

Making ratings meaningful

Ratings only help if they are consistent. Define the scale in writing before you start (for example, what "3 of 5" means), apply it the same way across teams, base each rating on evidence rather than opinion, and record who rated what and when. Avoid adding all the ratings into a single "CSF score": it hides which important outcomes are weak and invites people to chase the number instead of reducing risk. A better report shows, for each Function or Category, the current rating, the target and the trend since the last review, so leaders can see both the gaps and the progress.

Where the CSF becomes a requirement

The framework is voluntary in itself, but others can make it mandatory. US federal agencies have been directed to use it, and their annual cybersecurity reporting under the Federal Information Security Modernization Act (FISMA) has been organised around the CSF Functions. Some regulators, industry bodies and governments outside the United States reference it, and many customers ask suppliers to describe their security in CSF terms in questionnaires or contracts. In each case the obligation comes from that law, policy or contract, which defines what evidence is expected. The CSF itself also suggests that a Target Profile can be shared with suppliers to express the outcomes they are expected to achieve.

Compliance versus risk management

A useful mental model: compliance frameworks ask "did you do the required things?"; the CSF asks "are you achieving the outcomes that matter for your risks, and how rigorously do you manage that?" An organisation can use the CSF to organise its compliance obligations (by mapping each law or standard through Informative References) while still deciding priorities based on its own risk.

Lesson 6 – Worked example

This fictional example follows one organisation through the five-step process. The details are invented to illustrate the method.

The organisation

Harbourline Logistics is a regional freight and warehousing company with about 700 staff, three warehouses, a fleet of trucks with telematics units, a cloud-hosted transport management system (TMS) used by customers to book shipments, and an on-premises warehouse management system that controls conveyor and sorting equipment. A competitor recently suffered a ransomware attack that stopped deliveries for nine days. Harbourline's board asks: "Could that happen to us, and what should we do first?" The new head of information security, Amara, proposes using the CSF.

Step 1 – Scope

Amara and the chief operating officer agree on a first Profile scoped to keeping freight moving during and after a ransomware attack. It covers the TMS, the warehouse systems including OT equipment, email and identity services, backups and the two managed service providers that run the network and the TMS hosting. Payroll and the marketing website are left for a later Profile. The scope document names the owner (Amara), the approver (the COO on behalf of the executive committee) and the contributors (IT operations, the warehouse engineering lead, procurement and legal).

Step 2 – Gather information

The team collects the information security policy (last updated four years ago), the enterprise risk register, a business impact analysis showing that the TMS can be down for no more than 24 hours before contracts incur penalties, customer contract clauses on incident notification, recent penetration test results and the asset lists IT already holds. They also download a ransomware-related Community Profile listed on the NIST CSF website and the CSF Organizational Profile template.

Step 3 – Create the Profiles

Using the Community Profile as the basis for the Target Profile, the team removes outcomes that clearly do not apply and adds one of their own: "Warehouse OT can run in a safe manual mode when IT systems are unavailable." For each in-scope Subcategory they record current practices and evidence. Some extracts from the Current Profile:

GOVERN – risk strategy: no written risk appetite statement; cyber risk appears once in the enterprise register as "IT failure". Rated 1 of 5.
GOVERN – supply chain: managed service providers are known, but contracts contain no security requirements or incident duties. Rated 2.
IDENTIFY – assets: server and laptop inventory exists; OT devices and cloud services are not inventoried. Rated 2.
PROTECT – access: multi-factor authentication for email, but not for remote administration of the warehouse systems. Rated 2.
PROTECT – backups: nightly backups exist but sit on the same network as production and have never been restored in a test. Rated 1.
DETECT – monitoring: antivirus alerts go to a shared mailbox checked "when possible". Rated 1.
RESPOND and RECOVER: no written incident response plan; the provider's contact list is out of date. Rated 1.

The executive committee, guided by Amara, sets Tiers: Tier 3 (Repeatable) as the target for governance and for PROTECT and RECOVER, which the business impact analysis shows are critical; Tier 2 (Risk Informed) for the rest in the first year, moving to Tier 3 later. They also approve a short risk appetite statement: the company will not accept more than 24 hours of TMS disruption from a cyber incident.

Step 4 – Gap analysis and action plan

Comparing the two Profiles, the team scores each gap by how much it contributes to the nine-day-outage scenario and by effort. The resulting action plan, kept as a risk register with owners and dates, starts like this:

Move backups to an isolated, immutable store and run a full restore test of the TMS every quarter (owner: IT operations; 3 months).
Enforce multi-factor authentication on all remote and administrative access, including the providers' accounts (owner: identity team; 2 months).
Write and exercise an incident response and recovery plan with the two providers, including customer and regulator notification steps and criteria for declaring recovery complete (owner: Amara and legal; 4 months).
Add security requirements, incident notification duties and the right to review evidence to both provider contracts at renewal (owner: procurement; 9 months).
Contract a managed detection service to monitor alerts around the clock (owner: Amara; 4 months).
Build an inventory of OT devices and cloud services and record their criticality (owner: warehouse engineering and IT; 6 months).
Update the information security policy, approve it at executive level and add cyber risk properly to the enterprise risk register (owner: COO; 3 months).

Step 5 – Implement and update

Six months later the first restore test reveals that one database backup was corrupt, a finding recorded under IDENTIFY's Improvement Category and fixed. A tabletop exercise with the providers shows that the TMS host's escalation path did not reach anyone at weekends; the contract change is accelerated. Amara updates the Current Profile, reports progress to the board as a one-page view by Function (green, amber, red against target) and proposes a second Profile covering payroll and personal data.

What the example teaches

Harbourline did not try to achieve all 106 Subcategories at once or to reach Tier 4 everywhere. It used GOVERN to obtain a clear statement of what mattered, scoped a Profile to its most serious risk, reused a Community Profile rather than starting from nothing, relied on evidence when rating, tied every action to an owner and kept the cycle going. The same method works for a ten-person firm with a smaller spreadsheet or for a multinational with dozens of Profiles.

Lesson 7 – Relationship to other standards and frameworks

The CSF is designed to sit on top of, and connect, other sources of guidance. It answers "what outcomes, with what priority?"; other standards often answer "with which controls?" or "under what management system?". The table compares it with the frameworks you are most likely to meet.

Framework	What it is	Certification	How it relates to the CSF
NIST CSF 2.0	Voluntary taxonomy of cybersecurity outcomes with Profiles and Tiers	None from NIST	The common language and prioritisation layer
ISO/IEC 27001	International standard for an information security management system (ISMS), with a reference set of controls in Annex A	Yes, by accredited certification bodies	Many organisations run a certified ISMS and use the CSF to present posture and priorities; mappings between the two exist
NIST SP 800-53 Rev. 5	Detailed catalogue of security and privacy controls, used widely by US federal systems	No certification; federal systems are authorised through the NIST Risk Management Framework	A primary source of Informative References: controls that help achieve CSF Subcategories
CIS Critical Security Controls v8.1	Prioritised set of technical safeguards grouped into Implementation Groups	No official certification of organisations	CIS publishes a mapping to CSF 2.0 and added a governance function in v8.1 to match it
NIST Privacy Framework	Voluntary framework for privacy risk with a similar Core, Profiles and Tiers structure	None	Used together with the CSF; privacy risks can arise even without a security incident
NIST Risk Management Framework (SP 800-37)	Step-by-step process to select, implement, assess, authorise and monitor controls for systems	Authorisation to operate for federal systems, not certification	The CSF can guide organisation-level priorities that the RMF then applies system by system

Common combinations

CSF and ISO/IEC 27001. These complement each other well. ISO/IEC 27001 provides a certifiable management system: scope, leadership, risk assessment, Statement of Applicability, internal audit and management review. The CSF provides an outcome-based vocabulary that executives and customers often find easier to read. A company might keep its ISO certificate and also report its Current and Target Profiles to the board. The CSF does not replace ISO certification, and an ISO certificate does not automatically mean every CSF outcome is achieved at the desired level.

CSF and control catalogues. SP 800-53 and the CIS Controls give much more detailed guidance than the CSF. Through Informative References, a team can see which controls support each Subcategory, use those it already has as evidence in the Current Profile and choose additional ones to reach the Target Profile.

CSF and privacy. Cybersecurity and privacy overlap where personal data could lose confidentiality, integrity or availability, but privacy problems can also arise from authorised processing, such as collecting too much data. NIST positions the Privacy Framework and the CSF as partners for that reason.

CSF and enterprise risk. NIST's IR 8286 series and SP 800-221 explain how cybersecurity risk registers feed enterprise risk registers. GOVERN outcomes such as risk appetite and standard risk descriptions make this integration possible. The NIST AI Risk Management Framework uses a similar Function, Category and Subcategory structure for AI risks.

Sector and regional rules. Regulations such as sector security rules or national cybersecurity laws can be linked to the Core as Informative References, so a single Profile can show how one safeguard supports several obligations. This reduces duplicated effort for organisations that face many requirements.

Common pitfalls and best practices

Pitfalls

Treating the Core as a checklist. Ticking all 106 Subcategories as "done" without asking whether each outcome is achieved at the level your risk requires wastes effort on low-value items and hides weak spots.
Chasing Tier 4 everywhere. Higher Tiers cost money and effort. Targeting the top Tier in every area regardless of risk, mandates or budget is not what the framework recommends.
Skipping GOVERN. A Profile built only by the security team, with no leadership input on risk appetite, priorities and resources, produces a technically tidy plan that nobody funds or owns.
Undefined scope. A Profile that tries to cover "everything" without stated boundaries and assumptions becomes vague and impossible to assess.
Ratings without evidence. Scores based on opinion vary between teams and over time, so progress reports become meaningless.
Claiming certification. Telling customers you are "NIST CSF certified" misrepresents the framework and can damage trust once someone asks for the certificate.
A one-off project. Building a Profile once and never updating it ignores the continuous improvement cycle at the heart of the method.
Delaying Respond and Recover. Postponing incident response until protection is "finished" leaves the organisation unprepared, because incidents happen regardless.

Best practices

Start with a focused scope tied to a real business concern, such as ransomware against a critical service, and expand later.
Get leadership to set direction: risk appetite, accountable owners, Tier targets and resources.
Reuse what exists: Community Profiles, the NIST template, Implementation Examples and mappings to the standards you already follow.
Define your rating scale in writing and back every rating with evidence and a date.
Prioritise gaps by risk, using business impact analysis and threat information, and give every action an owner and deadline.
Work all Functions concurrently, keeping detection, response and recovery capabilities ready while protection improves.
Use Profiles to communicate with boards, customers and suppliers, including sharing target outcomes with key suppliers.
Review and update regularly, feeding lessons from tests, exercises and incidents into the Improvement Category.

Summary and key takeaways

The NIST CSF 2.0 (February 2024) is a free, voluntary, outcome-based framework for managing cybersecurity risk, suitable for organisations of any size or sector.
It has three components: the Core (Functions, Categories, Subcategories), Organizational Profiles and Tiers, supported by online Informative References, Implementation Examples, Quick-Start Guides and Community Profiles.
The six Functions are GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND and RECOVER; GOVERN sits at the centre and all Functions run concurrently.
The Core says what to achieve, not how; organisations choose methods suited to their own risks, often guided by other standards.
Current and Target Profiles, a gap analysis and a prioritised action plan turn the framework into a repeatable improvement cycle.
Tiers (Partial, Risk Informed, Repeatable, Adaptive) describe rigour and are chosen by leadership based on risk, mandates and cost.
NIST offers no certification; credibility comes from clear scope, evidence-based assessment and, where needed, independent review.
The CSF works alongside ISO/IEC 27001, SP 800-53, the CIS Controls and the Privacy Framework as a common language that ties them together.

Reflection questions

Think of your own organisation or a team you know. What would be a good scope for a first Organizational Profile, and why would that scope matter most to leadership?
For each of the six Functions, name one outcome your organisation already achieves well and one where you suspect a gap. What evidence would you use to confirm each?
Which Tier would you recommend as a realistic target for governance in your organisation over the next year, and what arguments about cost, risk and obligations would you present?
If a key supplier told you it was "fully aligned with the NIST CSF", which questions would you ask, and what would you want to see before trusting the statement?
Your organisation already follows another standard or regulation. How would you use Informative References to avoid doing the same work twice when you introduce the CSF?