This guide provides an overview of the NIST Cybersecurity Framework 2.0 and outlines the key stages for compliance.
Introducing the NIST Cybersecurity Framework
The National Institute of Standards and Technology (NIST) is a US government agency founded in 1901 by Congress (originally as the National Bureau of Standards), and forms part of the United States Department of Commerce. Initially focused on standardising physical weights and measures, NIST’s role has expanded over time to cover many aspects of technology and its use and included the investigation into the collapse of the World Trade Center as a result of the September 11th attacks. Some aspects of NIST’s role are explicitly laid out in US legislation and in 2013 an Executive Order from President Obama (EO 13636 – “Improving Critical Infrastructure Cybersecurity”) mandated the creation of a Cybersecurity Framework (CSF), with the Cybersecurity Enhancement Act of 2014 placing further emphasis on NIST’s role in cybersecurity. The first version of the Framework was published in 2014 and it was updated in April 2018 with CSF 1.1.
The use of the Cybersecurity Framework was made compulsory for federal agencies by President Trump in an Executive Order (EO 13800 – “Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure”) in 2017. A strong aspect of the legislation dealing with the CSF is the need for it to stay up to date, to drive improvement and to encourage close cooperation between the private and public sectors. To this end, NIST has embarked on the journey to CSF 2.0 with a comprehensive program of consultation, including a series of well-attended workshops and invitations for comment, culminating in the publication of CSF 2.0 in February 2024.
What’s New in Version 2.0
Version 2.0 of the CSF represents an “opening out” of the framework to position it as being generally applicable, not only to the public and private sectors in the USA, but also internationally. The emphasis is less on protecting critical infrastructure (although this is still a major goal) and more towards improving cybersecurity standards across the full range of industrial sectors, including within small and medium-sized businesses. This change is reflected in the new name of simply “Cybersecurity Framework”, compared to the previous name of “Framework for Improving Critical Infrastructure Cybersecurity”.
Another obvious enhancement is the creation of the new “Govern” function, a cross-cutting set of categories intended to provide overall direction to the existing five functions: Identify, Protect, Detect, Respond and Recover.
The Govern (GV) function consists of the following categories:
Organisational Context (GV.OC)
Risk Management Strategy (GV.RM)
Roles, Responsibilities and Authorities (GV.RR)
Policy (GV.PO)
Oversight (GV.OV)
Cybersecurity Supply Chain Risk Management (GV.SC)
Many of the subcategories covered within the above list have been taken from the Identify (ID) function, with a few also being extracted from other functions within the CSF V1.1.
Other significant changes include:
Informative references will now be provided online, to provide for easier and more frequent updating
Implementation examples will be provided to help with interpretation of the sub-categories
The use of tiers has been clarified
Revised guidance on how to create and use framework profiles
Clearer emphasis on improvement, with the creation of an Improvement category within the Identify function
The Main Principles of the NIST Cybersecurity Framework
The NIST CSF 2.0 consists of a number of building blocks which, when used together, allow an organisation to put in place a risk-based framework tailored to their specific environment. This section explains briefly what those building blocks are.
Functions
Functions provide an overall structure for the framework and group together related categories as shown in the list below. In many respects, it may help to view the first three functions as “proactive”, as they deal with the process of assessing and treating risk ahead of time, and the latter three functions as “reactive”, as they cover the more real-time process of detecting and dealing with cybersecurity incidents.
However, NIST is clear that this is not intended to be a process model, so activities may be taking place within all of the functions at the same time.
The functions are usually color-coded to provide a degree of familiarity when working with the framework.
Categories
Categories provide the next level of detail below functions, as shown in the list below. Again, they are not necessarily intended to be done in the order in which they appear but are a way of grouping together the sub-categories below them which give more detail about specific activities that can be done to improve cybersecurity.
Govern (GV):
GV.OC – Organisational Context
GV.RM – Risk Management Strategy
GV.RR – Roles, Responsibilities, and Authorities
GV.PO – Policy
GV.OV – Oversight
GV.SC – Cybersecurity Supply Chain Risk Management
Identify (ID):
ID.AM – Asset Management
ID.RA – Risk Assessment
ID.IM – Improvement
Protect (PR):
PR.AA – Identity Management, Authentication, and Access Control
PR.AT – Awareness and Training
PR.DS – Data Security
PR.PS – Platform Security
PR.IR – Technology Infrastructure Resilience
Detect (DE):
DE.CM – Continuous Monitoring
DE.AE – Adverse Event Analysis
Respond (RS):
RS.MA – Incident Management
RS.AN – Incident Analysis
RS.CO – Incident Response Reporting and Communication
RS.MI – Incident Mitigation
Recover (RC):
RC.RP – Incident Recovery Plan Execution
RC.CO – Incident Recovery Communication
Subcategories
Subcategories are where we get into the detail of the outcomes that we are looking to achieve. The table below shows the subcategories for the Organisational Context (GV.OC) category, which is within the Govern (GV) function.
Each subcategory has a reference (for example GV.OC-01) which allows it to be uniquely identified within the framework.
The subcategories are written as statements of fact (for example “The organisational mission is understood…”) and the aim of the organisation in implementing the framework is to be able to agree with each relevant statement.
Category | Subcategory |
Organizational Context (GV.OC): The circumstances — mission, stakeholder expectations, and legal, regulatory, and contractual requirements — surrounding the organization’s cybersecurity risk management decisions are understood (formerly ID.BE) | GV.OC-01: The organizational mission is understood and informs cybersecurity risk management (formerly ID.BE-02, ID.BE-03). |
GV.OC-02: Internal and external stakeholders are determined, and their needs and expectations regarding cybersecurity risk management are understood. | |
GV.OC-03: Legal, regulatory, and contractual requirements regarding cybersecurity — including privacy and civil liberties obligations — are understood and managed (formerly ID.GV-03). | |
GV.OC-04: Critical objectives, capabilities, and services that stakeholders depend on or expect from the organization are determined and communicated (formerly ID.BE-04, ID.BE-05). | |
GV.OC-05: Outcomes, capabilities, and services that the organization depends on are determined and communicated (formerly ID.BE-01, ID.BE-04). |
Implementation Examples
New with CSF 2.0 is the use of implementation examples. These are intended to be illustrative rather than definitive and are used to give a better idea of the kinds of tasks that should be performed to achieve the goal stated in the sub-category. They may not all apply to a particular organisation and so should be used as guidelines only. The table below shows some typical implementation examples.
Subcategory | Implementation Examples |
GV.OC-01: The organizational mission is understood and informs cybersecurity risk management (formerly ID.BE-02, ID.BE-03) | Ex1: Share the organization’s mission (e.g., through vision and mission statements, marketing, and service strategies) to provide a basis for identifying risks that may impede that mission. |
GV.OC-02: Internal and external stakeholders are determined, and their needs and expectations regarding cybersecurity risk management are understood | Ex1: Identify relevant internal stakeholders and their cybersecurity-related expectations (e.g., performance and risk expectations of officers, directors, and advisors; cultural expectations of employees) Ex2: Identify relevant external stakeholders and their cybersecurity-related expectations (e.g., privacy expectations of customers, business expectations of partnerships, compliance expectations of regulators, ethics expectations of society). |
Informative References
One of the intentions of the CSF is to be able to leverage the content of other standards and it does this through the use of informative references. For each subcategory a list of specific references to other standards is given. References are commonly taken from the following:
Centre for Internet Security – Critical Security Controls
ISO/IEC 27001 international standard for information security
COBIT 5 – Control Objectives for Information Technologies
NIST SP 800-53 Security and Privacy Controls for Information Systems and Organisations
ISA 62443 – International Society of Automation standards
Whereas these were listed directly in the main CSF document previously, the intention with 2.0 is to maintain these separately in a tool accessible via the NIST website.
Tiers
Four levels of rigor are defined within the CSF to judge an organisation’s practices within two areas:
Cybersecurity risk governance
Cybersecurity risk management
The four levels used are:
Tier 1 – Partial
Tier 2 – Risk informed
Tier 3 – Repeatable
Tier 4 – Adaptive
In effect, the tiers are similar to levels of maturity used in other frameworks, but NIST is keen to point out that not every organisation needs to be at Tier 4 for each of the three areas. The additional effort required to reach a higher tier needs to be cost-justified.
Tiers are an optional part of the framework and they are intended to be used at a number of different levels as appropriate, from a high level aspiration of “becoming a Tier 3 organisation” to a more specific goal of “improving the Cybersecurity Supply Chain Risk Management category from Tier 2 to Tier 3”.
Profiles
Within the context of the CSF, a profile is a description of parts of the framework that are either in place already (a current profile) or that the organisation aspires to meet (a target profile). In common terms this comparison between current state and desired state is often called a gap assessment, although this is not a term used by NIST. There is no standard way to create a profile, and it may be done at a number of different levels; for example at the highest level by function and at the lowest by subcategory. A further level of granularity can be introduced by the use of tiers (as described above).
The key output of the use of profiles is an action plan to move the organisation’s cybersecurity from where it is now to where it is desired to be.
NIST CSF Toolkit
The CertiKit NIST Cybersecurity Toolkit includes a comprehensive set of resources, including templates, guides and expert support to help your organisation implement the requirements of the framework.