PCI DSS Meets NIST CSF 2.0: What the New Mapping Means for Your Security Program

If your company handles card payments, PCI DSS is probably already part of your daily routine. But many organizations don't stop there. Boards, investors, enterprise customers and insurers increasingly ask a broader question: how well is cybersecurity managed across the whole business, not just in the cardholder data environment? The framework most often used to answer that question is the NIST Cybersecurity Framework (CSF).

So security and compliance teams often end up running two programs side by side. One answers to a Qualified Security Assessor (QSA) or a Self-Assessment Questionnaire. The other answers to leadership and the risk committee. The controls behind both are often the same, but the documentation, the reporting and the evidence collection are not.

The PCI Security Standards Council (PCI SSC) has now published an official resource that connects the two: a mapping of PCI DSS v4.0.1 to NIST CSF 2.0. In this article, we explain what the mapping contains, how to read it, where its limits are, and how you can use it to reduce duplicate work.

What PCI SSC announced

In July 2026, PCI SSC released a document that maps the requirements of PCI DSS v4.0.1 to the outcomes defined in NIST CSF 2.0. It replaces the Council's 2019 mapping, which was based on earlier versions of both frameworks. Since then, both standards have changed a lot: PCI DSS moved to version 4 with many new requirements, and NIST released CSF 2.0 in February 2024, adding a whole new function called Govern.

The mapping was created by the PCI SSC Board of Advisors, a group of representatives from merchants, banks, processors and service providers. PCI SSC describes it as a resource built by the industry, for the industry.

The release consists of three documents, all available free of charge in the PCI SSC Document Library:

• The full mapping (13 pages): a table that lists each NIST CSF 2.0 subcategory and the PCI DSS v4.0.1 requirements that support it.
• An Executive Brief (1 page): a short explanation of how the two frameworks relate, written for leadership.
• An At-a-Glance summary (2 pages): an overview of the mapping, how to use it and what it can't be used for.

If you only have five minutes, read the At-a-Glance summary. If you are responsible for control design, evidence or audit preparation, the full mapping is where the value is.

Two frameworks, two different jobs

Before looking at the mapping itself, it helps to understand why PCI DSS and NIST CSF are not the same thing, even though they share the same goal.

PCI DSS is a prescriptive standard. It defines specific technical and operational requirements for any entity that stores, processes or transmits payment account data, and for anyone who can affect the security of that data. Each requirement comes with testing procedures and guidance. Its focus is narrow and deep: protect cardholder data against the threats that the payments industry faces.

NIST CSF 2.0 is a voluntary, outcome-based framework. It describes what good cybersecurity looks like, through a taxonomy of high-level outcomes, but it deliberately does not tell you how to get there. Any organization can use it, whatever its size, sector or maturity, and it is designed to fit into enterprise risk management.

PCI SSC is very clear on one point: the two are not interchangeable, and neither replaces the other. CSF tells you where you want to end up. PCI DSS gives you a detailed route for one specific, high-risk area of your business: payments. Used together, they support a more complete approach to cybersecurity risk.

How the mapping works

The Board of Advisors took the CSF as the starting point. For every NIST CSF 2.0 subcategory (for example ID.AM-01: Inventories of hardware managed by the organization are maintained), they identified which PCI DSS v4.0.1 requirements contribute to that outcome. The result is a simple three-column table: CSF category, CSF subcategory, and the matching PCI DSS requirement numbers.

This direction matters. The mapping answers the question "If I meet my PCI DSS requirements, which CSF outcomes am I contributing to in my payment environment?" It does not go the other way round.

The headline result: the mapping covers all six CSF functions and all categories, and PCI DSS requirements map to 103 of the 106 subcategories. Here is how that breaks down by function, based on our count of the full mapping table:

Two things stand out. First, the Govern function, the newest part of the CSF, is almost fully supported. That is largely thanks to PCI DSS Requirement 12 (information security policies, risk analysis, third-party service provider management and incident response) and to the "roles and responsibilities" sub-requirements that PCI DSS v4 added at the start of every principal requirement (1.1.2, 2.1.2 and so on).

Second, a handful of PCI DSS requirements show up again and again. Requirement 12.10.1 (the incident response plan) appears in close to 30 subcategories, across Govern, Identify, Protect, Detect, Respond and Recover. Network and data-flow diagrams (1.2.3 and 1.2.4) and third-party service provider management (12.8.x) are also mapped in many places. These are the controls where good work pays off twice.

The three outcomes PCI DSS doesn't cover

The three subcategories without a PCI DSS match are just as instructive as the 103 with one:

The practical lesson: if your organization uses CSF as its enterprise framework, a strong PCI DSS program will not fill these gaps for you. Risk appetite, opportunity management and capacity planning need to be owned elsewhere, usually by enterprise risk management and IT operations.

One control, two frameworks: practical examples

The real value of the mapping is that it shows where one security control can support both a PCI DSS requirement and a CSF outcome. Here are some examples taken directly from the mapping table:

Notice how many of these come from requirements that were new or strengthened in PCI DSS v4, such as targeted risk analysis and payment page script controls. If your team has invested in getting these right for the March 2025 deadline, the mapping shows that the same work also strengthens your wider CSF posture.

The flip side is also useful. If a CSF self-assessment shows weak results in an area like supplier risk (GV.SC), the mapping tells you exactly which PCI DSS controls already exist in that area and could be extended beyond the cardholder data environment.

What the mapping is not

Every page of the mapping carries the same disclaimer, and it is worth taking seriously: the mapping is not a tool for demonstrating compliance with either PCI DSS or NIST CSF. Meeting a PCI DSS requirement does not mean the matching CSF outcome is achieved, and achieving a CSF outcome does not mean the PCI DSS requirement is met.

Why? There are three main reasons:

• Scope. PCI DSS applies to the cardholder data environment and connected systems. CSF outcomes usually apply to the entire organization. Strong MFA in your CDE says nothing about MFA on your HR system.
• Depth. A CSF subcategory describes an outcome in one sentence. The PCI DSS requirements mapped to it may only cover part of that outcome, or cover it in a very specific way.
• Validation. A QSA will assess you against PCI DSS testing procedures, not against CSF outcomes. A strong CSF profile won't replace your Report on Compliance or SAQ.

So don't tell your acquirer that you're "NIST aligned, therefore PCI compliant", and don't tell your board that "PCI compliance means we've covered NIST". PCI SSC also recommends that organizations consult their internal security and legal teams to decide which requirements actually apply to them.

How to put the mapping to work

The mapping is a reference table, not a methodology. Here is a practical way to use it:

1. Start with your existing PCI DSS evidence. List the controls and evidence you already produce for your ROC or SAQ: policies, diagrams, risk analyses, scan reports, log reviews, incident response tests.
2. Tag that evidence with CSF subcategories. Use the mapping to label each piece of evidence with the CSF outcomes it supports. Many teams do this in their GRC tool or a simple spreadsheet.
3. Run a gap analysis in both directions. Look for CSF subcategories where your PCI DSS evidence only covers the payment environment, and decide whether the control should be extended to the rest of the business. Also note the three subcategories with no PCI DSS match.
4. Build one control, test once, report twice. Where a control supports both frameworks, design and test it to the stricter standard (usually PCI DSS), then reuse the results in your CSF reporting.
5. Use internal evaluations as dress rehearsals. PCI SSC notes that internal evaluations of control effectiveness can help you prepare for a PCI DSS assessment, a CSF assessment, or both.
6. Talk the right language to the right audience. Use CSF functions when you report to the board, and PCI DSS requirement numbers when you talk to your QSA. The mapping lets you translate between the two.

This is especially helpful for organizations that are not US-based. CSF 2.0 is increasingly used internationally as a common structure for cyber risk, for example in vendor questionnaires from enterprise customers. Being able to show how your PCI DSS controls support CSF outcomes can shorten those security reviews.

Where scope reduction fits in

The mapping makes one thing very visible: PCI DSS controls touch almost every part of a modern cybersecurity program. Every system in your cardholder data environment needs inventories, diagrams, hardening, logging, monitoring, vulnerability management and incident response. The more systems that are in scope, the more evidence you have to produce, for PCI DSS and, through the mapping, for CSF as well.

That's why reducing PCI DSS scope is still one of the most effective things you can do. If raw card data never reaches your servers, because it is tokenized by a PCI DSS Level 1 service provider before it enters your environment, those servers no longer store, process or transmit cardholder data. Depending on your setup, that can mean a much smaller assessment, often a simpler SAQ, and far fewer controls to run and document.

The mapping also shows what doesn't go away when you outsource. When a third party handles card data for you, the PCI DSS requirements for managing third-party service providers (12.8.1 to 12.8.5) still apply. In CSF terms, they map to the Cybersecurity Supply Chain Risk Management category (GV.SC) and to supplier inventory (ID.AM-04). In practice, that means:

• keep an up-to-date list of the service providers that handle or could affect account data,
• have written agreements in which they acknowledge their responsibility for the data,
• monitor their PCI DSS compliance status at least once a year, for example through their Attestation of Compliance (AOC),
• and document which requirements they manage and which remain with you.

So scope reduction and good supplier governance go hand in hand. The result is a smaller, cleaner environment that is easier to defend and easier to report on, whichever framework your stakeholders ask about.

Conclusion

The new PCI DSS v4.0.1 to NIST CSF 2.0 mapping doesn't change any requirement, and it won't make your next assessment pass on its own. What it does is give security, compliance and risk teams a shared, official vocabulary. With PCI DSS requirements supporting 103 of the 106 CSF outcomes, most of the work you already do for payment security also counts toward your broader cybersecurity goals.

The smart approach: build controls once, test them to the PCI DSS standard, reuse the evidence for CSF reporting, and be honest about the gaps, both the three outcomes PCI DSS doesn't cover and the parts of your business outside the cardholder data environment. And wherever possible, keep that environment as small as you can.

You can download the full mapping, the Executive Brief and the At-a-Glance summary from the PCI SSC Document Library.

This article is for general information only and does not constitute legal or compliance advice. Please consult your QSA or internal security and legal teams to determine which requirements apply to your organization.