Skip to main content
Readiness Authority
Category: Security Controls

NIST CSF Core Functions

Also known as: CSF, Cybersecurity Framework Functions, CSF Functions, NIST Cybersecurity Framework Core Functions
Simply put

The NIST Cybersecurity Framework Core Functions are the highest-level categories the framework uses to organize cybersecurity activities and outcomes. They provide a common way for organizations to think about managing cyber risk, from understanding their assets to responding to and recovering from incidents. They are a voluntary framework for improving security practices and are not an insurance policy or a source of coverage.

Formal definition

The Core Functions are the top-level organizing structure of the NIST Cybersecurity Framework, grouping cybersecurity outcomes at their highest level. Under CSF 1.1 there are five Functions: Identify, Protect, Detect, Respond, and Recover. CSF 2.0, published February 26, 2024, adds a sixth Function, GOVERN, resulting in GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, and RECOVER. These Functions are a control and governance framework used to structure and communicate cybersecurity risk management activities; they are distinct from insurance coverage constructs (such as triggers, retentions, sublimits, or waiting periods) and from specific resilience metrics such as RTO or RPO. Adoption or alignment with the framework supports risk mitigation but does not itself transfer risk or guarantee that any resulting loss would be covered under a cyber policy, which depends on the specific policy wording, endorsements, exclusions, and jurisdiction.

Why it matters

The NIST CSF Core Functions give organizations and the professionals who advise them a shared vocabulary for describing what a cybersecurity program does, spanning the full lifecycle from understanding assets and risks through detecting, responding to, and recovering from incidents. For risk managers and CISOs, this common structure makes it easier to identify gaps, communicate priorities to boards, and demonstrate a coherent approach to managing cyber risk rather than a collection of disconnected controls.

For the insurance side of the market, alignment with the Core Functions is increasingly relevant to how underwriters assess an applicant's security posture and how brokers position a submission. However, it is important to keep two things distinct: the framework is a voluntary tool for risk mitigation, while a cyber insurance policy is a mechanism for risk transfer. Adopting or aligning with the CSF does not reduce whether a specific loss is covered; coverage depends on the policy wording, endorsements, exclusions, conditions precedent, and jurisdiction. The framework can inform underwriting conversations and support arguments about reasonable security practices, but it does not itself guarantee coverage or serve as a source of it.

The practical significance also lies in the difference between demonstrating capability and achieving an outcome. Mapping a program to the Core Functions can show that an organization has structured its activities across governance, protection, detection, response, and recovery, but it does not by itself establish resilience or prove that any particular recovery objective will be met. Professionals should treat the Functions as an organizing and communication layer, not as a substitute for measured resilience metrics or for the specific terms that determine whether a claim is paid.

Who it's relevant to

CISOs and Security Teams
Security leaders use the Core Functions to structure their programs, identify gaps across the cybersecurity lifecycle, and communicate priorities to executives and boards in a consistent way. The addition of GOVERN in CSF 2.0 gives explicit prominence to oversight of the risk management strategy, which can help frame board-level conversations.
Underwriters and Brokers
Alignment with the Core Functions can inform how an applicant's security posture is described and assessed during underwriting, and can help brokers present a coherent submission. Both should remember that framework alignment supports risk mitigation but does not transfer risk or determine coverage, which turns on the specific policy wording, endorsements, exclusions, and jurisdiction.
Risk Managers
Risk managers can use the Functions as a shared vocabulary to coordinate mitigation efforts with insurance decisions, distinguishing what the organization does to reduce likelihood and impact from what it transfers through a policy. The framework does not, by itself, constitute resilience or guarantee any particular recovery outcome.
Compliance and Legal Professionals
Compliance and legal teams may reference the Core Functions when demonstrating a structured approach to managing cyber risk. Because the framework is voluntary and is not a regulation or insurance instrument, its role in any given matter depends on how it is used and on applicable requirements; it should not be treated as establishing legal obligations or coverage on its own.

Inside CSF

Govern (GV)
The function establishing and monitoring the organization's cybersecurity risk management strategy, expectations, and policy. Added as a distinct function in the CSF 2.0 revision, it addresses organizational context, risk management strategy, roles and responsibilities, policy, and oversight. It is a resilience and governance concept, not an insurance policy term, and does not by itself transfer or reduce financial risk.
Identify (ID)
Activities to develop an organizational understanding of assets, data, systems, capabilities, and the associated cybersecurity risks. This supports risk mitigation by informing where controls are needed, but it is a preparedness measure rather than a coverage trigger or resilience metric such as RTO or RPO.
Protect (PR)
Safeguards to limit or contain the impact of a potential cybersecurity event, spanning areas such as access control, awareness, data security, and protective technology. This is a risk mitigation function aimed at reducing likelihood or impact; it is distinct from risk transfer through insurance.
Detect (DE)
Activities to identify the occurrence of a cybersecurity event on a timely basis, including monitoring and detection processes. Detection is a security function; it is not the same as an insurance policy's notification condition, though timely detection often supports meeting such conditions precedent.
Respond (RS)
Actions taken regarding a detected cybersecurity incident, including response planning, communications, analysis, mitigation, and improvements. This corresponds to incident response in the resilience domain and should be distinguished from broader crisis management, which addresses organization-wide leadership and communication decisions.
Recover (RC)
Activities to maintain plans for resilience and to restore capabilities or services impaired by an incident, including recovery planning and improvements. This function relates to disaster recovery and business continuity concepts but is not itself a measurement such as RTO or RPO, which are objectives set by the organization rather than functions of the framework.

Common questions

Answers to the questions practitioners most commonly ask about CSF.

Does adopting the NIST CSF Core Functions mean my organization has cyber insurance coverage?
No. The NIST CSF Core Functions are a set of security and resilience activities, not an insurance policy term, and they do not transfer any risk. Implementing them may improve your risk posture and can factor into underwriting decisions, but coverage for a given loss depends entirely on the specific policy wording, endorsements, exclusions, and conditions of a separate cyber insurance contract. The framework and the policy are distinct instruments serving different purposes.
Are the NIST CSF Core Functions a step-by-step incident response or recovery plan I can follow during an event?
Not directly. The Core Functions organize cybersecurity outcomes at a high level rather than providing operational runbooks. Concepts such as incident response, crisis management, disaster recovery, and business continuity remain distinct disciplines with their own procedures, and the framework does not replace them. The functions can help structure your overall program and point to where such plans belong, but you still need dedicated, detailed plans and defined objectives to execute during and after an incident.
How can we use the Core Functions to map our existing controls and identify gaps?
Organizations commonly use the Core Functions as an organizing structure to categorize current activities and compare them against desired outcomes, surfacing areas where controls are absent or immature. This mapping is a planning and assessment exercise; it does not itself establish coverage or constitute a resilience metric. Treat the result as an input to prioritization rather than a certification of adequacy, since the framework is descriptive rather than prescriptive about specific control implementations.
How do the Core Functions relate to the recovery objectives like RTO and RPO that we set for our systems?
The Core Functions include recovery-oriented outcomes at a conceptual level, but they are not the same as quantitative recovery objectives. Recovery time objective (RTO) and recovery point objective (RPO) are specific targets you define within disaster recovery and business continuity planning. You would set and validate those objectives separately; the framework can indicate that recovery capabilities should exist, but it does not dictate the numeric targets appropriate for your organization.
How should we approach implementing the Core Functions if we also rely on other standards or frameworks?
The Core Functions are often used alongside other standards and control catalogs rather than in place of them, and they are not intended to be interchangeable with any single standard. Organizations frequently cross-reference the functions with the more detailed requirements of standards they already follow. Because different standards bodies define concepts and scope differently, verify how each source uses a given term before treating overlapping requirements as equivalent.
Can our progress against the Core Functions be shared with underwriters or brokers during placement?
Organizations may choose to describe their security program in terms of the Core Functions when communicating with underwriters or brokers, and such information can inform how a risk is assessed. However, how any of this affects terms, pricing, retentions, or coverage is subject to each insurer's own evaluation and the specific policy wording. Presenting alignment with the framework is not a guarantee of favorable terms, and it does not by itself satisfy any conditions precedent that a policy may impose.

Common misconceptions

Adopting the NIST CSF Core Functions makes an organization compliant or automatically satisfies insurer requirements.
The CSF is a voluntary framework describing outcomes across functions, not a compliance certification or a policy condition. Whether alignment with the CSF affects underwriting, pricing, or coverage depends entirely on the specific insurer's requirements and policy wording; the framework itself confers no coverage.
Implementing the Core Functions constitutes resilience or transfers risk.
The functions support risk mitigation and preparedness by helping reduce likelihood and impact, but they do not by themselves guarantee resilience and do not transfer financial risk. Risk transfer is achieved through insurance, which is a separate mechanism that does not reduce the likelihood of an incident.
The Recover function is the same as having a defined RTO or RPO.
Recover is a category of outcomes covering recovery planning and restoration. Recovery time objective (RTO) and recovery point objective (RPO) are distinct, measurable targets an organization sets; the framework may inform them but does not define or replace them.

Best practices

Treat the Core Functions as a structure for organizing security and resilience outcomes, and map your existing controls and plans against each function to identify gaps rather than assuming coverage of all six.
Keep governance (Govern) distinct from operational functions, ensuring risk management strategy, roles, and oversight are explicitly defined rather than assumed within Identify or Protect.
Distinguish the framework's Respond and Recover functions from your insurance program, and separately confirm how policy conditions precedent, notification requirements, and exclusions interact with your incident response and recovery activities under the specific wording.
Set and document measurable objectives such as RTO and RPO independently, using the Recover function to inform planning but not as a substitute for those metrics.
Use the functions to strengthen risk mitigation while recognizing that they do not transfer financial risk; coordinate them with any risk transfer, acceptance, or avoidance decisions.
Review alignment across functions periodically and coordinate with brokers and underwriters to understand which, if any, elements they consider relevant, rather than assuming framework adoption alone affects coverage terms.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide