Category: Regulations and Standards

NIST Cybersecurity Framework (CSF)

Also known as: CSF, NIST CSF, Cybersecurity Framework, NIST Cybersecurity Framework 2.0, CSF 2.0

Simply put

The NIST Cybersecurity Framework is a voluntary, risk-based set of guidance developed by the U.S. National Institute of Standards and Technology to help organizations understand, manage, and reduce cybersecurity risk. It is not a rigid checklist but a flexible structure that organizations of any size or sector can adapt to their own needs. In its 2.0 version, published in February 2024, the framework organizes cybersecurity outcomes into functions covering how an organization governs, identifies, protects against, detects, responds to, and recovers from cyber threats.

Formal definition

The NIST Cybersecurity Framework (CSF) is a risk-based approach to managing cybersecurity risk, structured around three principal components: the Framework Core, Framework Profiles, and Framework Implementation Tiers. In CSF 2.0 (NIST CSWP 29, published February 26, 2024), the Core is organized around six Functions: Govern, Identify, Protect, Detect, Respond, and Recover; the Govern Function was added in 2.0 and addresses organizational context, cybersecurity strategy, roles and responsibilities, policy, and risk management oversight, and it informs how the other five Functions are applied. Profiles express an organization's current or target state of cybersecurity outcomes, while Implementation Tiers characterize the rigor of an organization's cybersecurity risk governance and management practices. CSF 2.0 also provides mapping resources relating its outcomes to other references such as NIST SP 800-53 controls. The CSF is a voluntary guidance framework and is distinct from prescriptive compliance standards such as PCI DSS; organizations should consult the current published NIST documentation for authoritative Function, Category, and Subcategory definitions rather than relying on earlier versions.

Why it matters

The NIST Cybersecurity Framework gives organizations a common vocabulary and a structured, risk-based way to describe their cybersecurity posture without prescribing a rigid checklist. For payment security and fraud teams, this matters because it provides a shared reference point that can be mapped to other standards and controls, helping bridge conversations between technical staff, risk owners, and executives. Its voluntary and adaptable nature means an organization of nearly any size or sector can align its practices to the framework's outcomes and use Profiles to track progress from a current state toward a desired target state.

The release of CSF 2.0 in February 2024 is significant because it added a sixth Core Function, Govern, alongside the previously established Identify, Protect, Detect, Respond, and Recover. The Govern Function elevates organizational context, cybersecurity strategy, roles and responsibilities, policy, and risk management oversight to a first-class element of the framework, and it informs how the other five Functions are applied. Entries or programs built on the earlier five-Function model no longer reflect the current structure, so teams should confirm their mappings and documentation against the published CSF 2.0 material.

It is important to treat the CSF as guidance rather than a compliance mandate. It is distinct from prescriptive standards such as PCI DSS, and adopting the CSF does not by itself satisfy PCI DSS or any other regulatory requirement. Used well, the framework helps organize and improve a cybersecurity program and may support risk-informed decisions, but it does not guarantee any particular security outcome and its effectiveness depends on how thoroughly an organization implements and validates the underlying practices.

Who it's relevant to

Compliance and risk officers

Compliance and risk teams can use the CSF to organize cybersecurity outcomes, express current and target states through Profiles, and map framework outcomes to control references such as NIST SP 800-53. The framework is voluntary guidance and does not replace prescriptive obligations like PCI DSS, so it is best used to structure and communicate a program rather than to demonstrate regulatory compliance on its own.

Security engineers and architects

Engineers and architects can reference the Core's six Functions—Govern, Identify, Protect, Detect, Respond, and Recover—along with their Categories and Subcategories to align technical controls to defined outcomes. The mapping resources in CSF 2.0 help connect those outcomes to more detailed control catalogs when designing and validating implementations.

Executives and governance stakeholders

The Govern Function added in CSF 2.0 gives leadership a place to address organizational context, cybersecurity strategy, roles and responsibilities, policy, and risk management oversight. Implementation Tiers can help executives characterize how rigorous their risk governance practices are and support risk-informed decisions about investment and priorities.

Payment processors, acquirers, and merchant risk teams

Organizations handling payment data can use the CSF as a common, risk-based structure to organize their broader cybersecurity program and to communicate posture across technical and business audiences. Because the CSF is distinct from PCI DSS and other payment-specific standards, teams should treat it as complementary guidance and continue to validate against the current published requirements of any applicable standard.

Inside CSF

Core Functions

The NIST CSF organizes cybersecurity activities into high-level Functions. As of CSF 2.0, there are six: Govern, Identify, Protect, Detect, Respond, and Recover. Govern was added in version 2.0 and addresses how an organization establishes, communicates, and monitors its cybersecurity risk management strategy, expectations, and policy. Earlier versions (CSF 1.0 and 1.1) defined only the five Functions Identify, Protect, Detect, Respond, and Recover. Confirm the current Function set against the published version of the framework you are using.

Govern Function

The sixth Core Function introduced in CSF 2.0. It covers cybersecurity governance topics such as organizational context, risk management strategy, roles and responsibilities, policy, and oversight, and it informs how the other five Functions are prioritized and applied. It reflects the framework's emphasis on integrating cybersecurity into broader enterprise risk management.

Categories and Subcategories

Each Function is divided into Categories (groups of related outcomes) and Subcategories (discrete, outcome-based statements). These express desired results rather than prescribing specific technologies or controls, allowing organizations to map them to their own controls and to other standards.

Framework Profiles

Profiles describe an organization's current or target alignment of Functions, Categories, and Subcategories with its business requirements, risk tolerance, and resources. Comparing a Current Profile to a Target Profile helps identify and prioritize gaps.

Implementation Tiers

Tiers characterize the rigor and maturity of an organization's cybersecurity risk management practices along a range. They are intended to describe practices, not to serve as strict maturity levels or a certification.

Relationship to PCI DSS and other standards

The CSF is a voluntary, risk-based framework of cybersecurity outcomes; it is distinct from PCI DSS and from PCI standards such as PA-DSS, the PCI Software Security Framework, PCI PIN, PCI P2PE, and PCI 3DS. The CSF does not replace PCI DSS or define payment-specific requirements. Organizations may map CSF outcomes to controls in PCI DSS and other standards, but such mapping does not by itself demonstrate PCI DSS compliance.

Common questions

Answers to the questions practitioners most commonly ask about CSF.

Does achieving PCI DSS compliance mean my organization has implemented the NIST Cybersecurity Framework?

No. PCI DSS and the NIST CSF are separate frameworks with different scopes and governance. PCI DSS is a prescriptive standard maintained by the PCI Security Standards Council that focuses on protecting cardholder data within a defined cardholder data environment. The NIST CSF is a voluntary, outcome-based framework maintained by NIST that organizes cybersecurity activities across its Core Functions to help manage risk broadly across an organization. Mapping exists between the two, and CSF outcomes can support PCI DSS objectives, but satisfying one does not automatically satisfy the other. Each must be validated on its own terms.

Is the CSF Core made up of five functions?

Not in the current version. CSF 2.0 defines six Core Functions: Govern, Identify, Protect, Detect, Respond, and Recover. The Govern function was added in version 2.0 and addresses how an organization establishes, communicates, and monitors its cybersecurity risk management strategy, expectations, and policy. Earlier material describing only five functions reflects the prior version. Readers should confirm the current Core structure and category wording against the CSF version published by NIST rather than assuming a fixed set of five functions.

How can a payment organization use the CSF Govern function alongside its PCI DSS program?

The Govern function focuses on cybersecurity risk management strategy, roles and responsibilities, policy, and oversight, which can align with the governance and accountability expectations found in a PCI DSS program. An organization can use Govern outcomes to document risk tolerance, assign ownership for controls protecting the cardholder data environment, and ensure leadership oversight. This is intended to complement PCI DSS validation, not replace it. Confirm specific PCI DSS requirement wording against the current published standard, since numbering and phrasing differ between versions.

What is a CSF Profile and how might it help scope a security program?

A Profile in the CSF describes an organization's current or target alignment of Core outcomes to its business needs, risk tolerance, and resources. Teams can build a Current Profile to capture existing practices and a Target Profile to define desired outcomes, then use the gap between them to prioritize work. In a payment context, a Profile can help organize efforts around protecting cardholder data, but it does not itself validate PCI DSS scope or compliance, which depend on separate assessment against the applicable standard.

How do CSF Implementation Tiers relate to maturity, and what are their limits?

Implementation Tiers describe the degree to which an organization's cybersecurity risk management practices exhibit the characteristics defined in the framework, ranging from partial to adaptive. Tiers are intended to provide context on how risk is managed and are not a formal maturity model or a certification. A higher Tier does not by itself demonstrate compliance with PCI DSS or any other standard, and Tier selection should reflect risk appetite and business needs rather than being treated as a score to maximize.

Can mapping CSF outcomes to PCI DSS controls reduce duplicated effort, and what should teams watch for?

Mapping CSF outcomes to PCI DSS controls can help teams identify overlap and reuse evidence where the same activity supports both, which may reduce duplicated effort. However, a mapping is a reference aid, not a compliance shortcut. Coverage in one framework does not guarantee coverage in the other, because scope, required rigor, and validation methods differ. Teams should confirm each PCI DSS requirement against the current published standard and validate CSF outcomes on their own terms rather than relying on the mapping label alone.

Common misconceptions

The NIST CSF Core consists of five Functions: Identify, Protect, Detect, Respond, and Recover.

That five-Function structure reflects CSF 1.0 and 1.1. CSF 2.0 adds a sixth Function, Govern, making six Core Functions. Confirm the Function set against the version of the framework you are referencing.

Adopting the NIST CSF makes an organization PCI DSS compliant.

The CSF and PCI DSS are separate. The CSF is a voluntary, outcome-based framework, while PCI DSS is a payment-card data security standard with its own requirements and validation. Mapping CSF outcomes to PCI DSS controls may help organize efforts but does not demonstrate PCI DSS compliance on its own.

The CSF Implementation Tiers are maturity levels or a certification that proves strong security.

Tiers describe the character and rigor of risk management practices; they are not a certification and are not intended to be treated as a strict maturity scorecard. Higher Tiers do not guarantee reduced risk or fraud.

Best practices

Confirm which version of the CSF you are applying (for example, whether the Govern Function applies) and align internal documentation to the current published framework rather than an outdated five-Function model.

Use the Govern Function to establish clear roles, risk management strategy, and oversight, and let those governance outcomes inform how you prioritize the Identify, Protect, Detect, Respond, and Recover Functions.

Develop Current and Target Profiles to identify gaps, then prioritize remediation based on business requirements, risk tolerance, and available resources.

Map CSF outcomes to your PCI DSS controls and other applicable standards to reduce duplicated effort, while treating the CSF and PCI DSS as separate and validating PCI DSS compliance through its own process.

Treat Implementation Tiers as a description of practice rigor to guide improvement, not as a certification or a guarantee that risk or fraud has been eliminated.

Revisit Profiles and Tiers periodically as the framework, your environment, and applicable card brand or network rules change, and reconfirm terminology against the current published sources.