Should you pursue NIST CSF or PCI DSS first?
If your organization stores, processes or transmits cardholder data, PCI DSS is the mandatory standard you must validate, and the NIST CSF is a voluntary enterprise outcome framework with no certification. For most card-handling organizations, PCI DSS comes first. The payment brands or your acquirer decide which validation route applies, whether that is a Report on Compliance completed by a Qualified Security Assessor or a Self-Assessment Questionnaire, and that decision sets the deadline. Confirm the required route in writing with your acquirer before you plan any other work. Once the validation scope is fixed, the CSF can organize the wider security program around it, using an Organizational Profile scoped to the cardholder data environment and the systems that connect to it.
Do the CSF alone when no cardholder data is stored, processed or transmitted, and your payment exposure is limited to something that does not affect the cardholder data environment. Do the CSF alone also when the enterprise program needs to cover more than the payment scope and no payment brand or acquirer has asked for validation. In that case, ask your acquirer and any payment processors to confirm in writing that you have no validation obligation, because the payment brands decide, not the PCI SSC. Keep the CSF scope documented so an assessor can later see why card systems were excluded.
Do both when you handle account data and also need an enterprise program that covers identity, supplier risk, recovery and governance beyond the cardholder data environment. Use the CSF to set the enterprise goals and Target Profile, then map PCI DSS requirements into the CSF's informative references so one set of evidence serves both. Expect that PCI DSS validation proves only the scope it covers, so a clean ROC or SAQ does not show the wider program is working. Where a QSA reviews SOC 2 evidence, it may rely on it only after independent review, which can reduce duplicate evidence work. Ask your QSA to confirm which artifacts they will accept before you build the shared evidence set.
NIST CSF 2.0 and PCI DSS side by side
This table compares who owns each framework, who it applies to, how it is structured, whether it is mandatory, which version is current and what proof each produces. Read it to see why the CSF can shape an enterprise program while only PCI DSS validation proves compliance for account data.
| Dimension | NIST CSF 2.0 | PCI DSS v4.0.1 |
|---|---|---|
| Owner | National Institute of Standards and Technology (NIST) | PCI Security Standards Council (PCI SSC) |
| Who it applies to | Any organization, regardless of size, sector or maturity, on a voluntary basis | Entities that store, process or transmit cardholder data or sensitive authentication data, or could affect the cardholder data environment |
| Structure | Six Functions (Govern, Identify, Protect, Detect, Respond, Recover), 22 Categories and 106 Subcategories | 12 principal requirements grouped under six goals |
| Voluntary or mandatory | Voluntary; NIST is not a regulator, though some customers or suppliers may require it | Mandatory for entities in scope, as set by the payment brands and acquirers |
| Current version | CSF 2.0, published February 26, 2024; no revision of the Core as of October 2026 | PCI DSS v4.0.1 is the only active version; v4.0 retired on December 31, 2024 |
| Proof produced | None. NIST offers no certifications or conformity assessment program; you document your own Current and Target Profiles | Report on Compliance (ROC) by a Qualified Security Assessor, or a Self-Assessment Questionnaire (SAQ), each with an Attestation of Compliance (AOC) |
| Who decides validation | Your organization decides how to use the framework and what evidence to keep | Compliance-accepting entities, typically payment brands and acquirers, decide whether you validate with a ROC or an SAQ |
| Recurring testing | Set by your own risk decisions and internal policy | Fixed frequencies, such as quarterly ASV and internal scans and penetration tests at least every 12 months |
Who requires PCI DSS, and why the CSF is a choice
PCI DSS applies to any entity that stores, processes or transmits cardholder data or sensitive authentication data, and to any entity that could affect the security of that cardholder data environment. In practice that covers merchants, processors, acquirers, issuers and service providers. If your organization touches card data directly, or hosts, manages or connects systems that could affect it, start by confirming with your acquirer or payment brand which validation level applies to you, because the requirement comes from the payment ecosystem rather than from a law you can read on your own.
The PCI Security Standards Council owns and maintains the standard, but it does not enforce compliance or impose penalties. The individual payment brands decide which entities must comply and validate, and they run any enforcement programs. Compliance-accepting entities, typically payment brands and acquirers, also decide whether you file a ROC or an SAQ and may require that only a subset of requirements be tested and documented in a ROC. Ask your acquirer in writing which validation type and which Attestation of Compliance they expect, and whether they accept reuse of evidence from other audits.
The CSF sits on the other side of that line. NIST is not a regulator, the framework is voluntary, and nothing in it obliges your organization to adopt it. Some customers and suppliers do require it contractually, and a 2017 executive order made it mandatory for U.S. federal agencies. The framework's Organizational Profiles let you scope the effort to the whole organization or to a subset, such as financial systems, or to a threat such as ransomware against those systems. A CSF profile can organize cardholder-data work alongside the rest of the program, but it does not replace the validation your acquirer requires.
Which PCI DSS validation route applies to you
Visa requires an annual Report on Compliance (ROC) completed by a Qualified Security Assessor (QSA) for Level 1 merchants and Level 1 service providers. The ROC is a detailed assessment on an official PCI SSC template, and it ends with an Attestation of Compliance (AOC). A certificate does not replace it, because PCI SSC does not recognize certificates as validation.
- Who it covers: Level 1 merchants and Level 1 service providers under Visa's published validation rules.
- Who performs it: A QSA chosen by you, working against the requirements in scope for your cardholder data environment.
- What you deliver: The ROC and the AOC, which your acquirer or payment brand reviews.
- Recurring work: The assessment is annual, so evidence collection and testing must be kept current throughout the year.
- Scope note: Your payment brand or acquirer may accept a ROC that tests only a subset of requirements, so ask which subset applies before scoping the engagement.
Confirm your merchant or provider level and the exact validation route with your acquirer or payment brand before you contract a QSA.
Visa requires an annual Self-Assessment Questionnaire (SAQ) for Level 2 and Level 3 merchants. The SAQ is completed by you on an official PCI SSC template and is validated with an Attestation of Compliance (AOC). No QSA is required by this Visa rule, but the questionnaire still asks for a documented, accurate account of how each applicable requirement is met.
- Who it covers: Level 2 and Level 3 merchants under Visa's published validation rules.
- Who completes it: Your own team, with the SAQ type selected to match how you accept and process card data.
- What you deliver: The completed SAQ and its AOC, submitted to your acquirer or payment brand.
- Recurring work: The SAQ is annual, and the quarterly scanning and periodic penetration testing that apply to your SAQ type still have to run on schedule.
- Scope note: Accuracy matters because the attestation is a formal statement, so ask your acquirer whether they expect internal review or an independent check.
Confirm the SAQ type and any additional evidence your acquirer expects before you begin the questionnaire.
Visa requires an annual SAQ for Level 2 service providers, which is a different route from the ROC that Level 1 service providers must complete. Service providers handle card data for other organizations, so the scope of the SAQ often includes their hosting, administrative access and connections to customer environments. Read the questionnaire type and its applicable requirements carefully, because the choice of SAQ type determines what you must attest to.
- Who it covers: Level 2 service providers under Visa's published validation rules.
- Who completes it: Your team, using the SAQ type that matches your service model.
- What you deliver: The SAQ and AOC, which your customers' acquirers or payment brands may ask to see.
- Customer questions: Some customers ask for a service provider AOC or additional evidence, so confirm what each relationship requires.
- Scope note: Changes in service design, such as a new hosting environment, can change which requirements apply between cycles.
Confirm your service provider level, the SAQ type and any customer-specific validation requests with your acquirer and payment brands.
Compliance-accepting entities, typically payment brands and acquirers, decide whether an entity validates with a ROC or an SAQ. They may also require that only a subset of requirements be tested and documented in a ROC. This means the published Visa level rules are a starting point, and the requirements you must demonstrate can be narrowed or confirmed by your acquirer.
- Who decides: The compliance-accepting entity, not the PCI SSC, which does not enforce compliance or set validation routes for individual merchants.
- What may change: The route you use and the subset of requirements tested in a ROC.
- What stays fixed: The PCI DSS requirements themselves and the testing frequencies, such as quarterly scans and penetration tests every 12 months.
- Written confirmation: Ask for the decision in writing, including the requirement subset and the deadline for submission.
- Scope note: A narrowed scope still needs an accurate cardholder data environment definition, so document it before any assessor starts work.
Confirm your route and any subset of requirements in writing with your acquirer before you scope a ROC or select an SAQ.
Where the CSF and PCI DSS work overlaps
The CSF and PCI DSS meet in published mappings, shared evidence and common tooling. Each overlap below shows where controls relate, and none of them lets a mapping stand in for a PCI DSS assessment.
PCI DSS as an informative reference
NIST's CSF 2.0 Reference Tool export lists PCI DSS among the standards linked to CSF Subcategories through informative references. Use that link to see which CSF outcomes touch your cardholder data controls, then check each linked PCI DSS requirement against your own environment. The link identifies a relationship. It does not show that your implementation meets the requirement, so confirm the wording and version with your QSA or acquirer.
Mappings come with limits
NIST develops informative references itself and also accepts those developed by non-NIST entities. NIST states that it does not check the correctness of non-NIST mappings and that listing a mapping does not imply endorsement. Treat every PCI DSS line in the export as a starting point that your team validates, and record who produced each mapping and when you reviewed it.
Third-party CIS Navigator crosswalk
The CIS Controls Navigator for v8.1 maps both CSF 2.0 and PCI DSS v4.0, which lets a team move from CSF Subcategories to PCI DSS requirements through a common set of safeguards. This is useful for planning control owners and evidence sources. A two-hop path through CIS safeguards is an analyst's aid, so confirm each resulting link against the PCI DSS requirement text before you rely on it for scoping.
Reusing SOC 2 evidence
PCI SSC guidance states that a QSA cannot rely on a SOC 2 or SOC 3 report for a PCI DSS assessment, but may reuse the underlying evidence after independently reviewing it. If your organization already produces SOC 2 evidence for access reviews, logging or change management, the same artifacts may support PCI DSS testing. Ask your QSA which evidence they will accept, how far they will review it, and which PCI DSS requirements still need fresh testing.
Shared control owners
Both frameworks assign work to the same teams: access administration, log review, vulnerability management and third-party oversight. A CSF profile that lists these owners and their outcomes can serve as the shared record for the wider program, while PCI DSS requires its own assessment documents. Map each PCI DSS requirement to a named owner and a CSF Subcategory so that gaps show up before the assessment does.
Recurring test cadence
PCI DSS fixes testing frequencies that a CSF profile does not set: external and internal scans at least every three months, and penetration and segmentation tests on fixed cycles. A CSF-based program can schedule these tests as recurring activities under its Detect and Identify outcomes. Confirm that the frequencies in your plan match the PCI DSS v4.0.1 text your assessor uses, and keep dated evidence for each run.
What only PCI DSS validation proves
Only a PCI DSS assessment produces proof that payment brands recognize for account data. That proof is a Report on Compliance (ROC) completed by a Qualified Security Assessor, or a Self-Assessment Questionnaire (SAQ), each carrying an Attestation of Compliance (AOC) on the official PCI SSC templates. A certificate is not recognized as validation, so a vendor's badge or a framework certificate will not satisfy an acquirer or a payment brand. Before you plan the work, confirm with your acquirer or the relevant payment brand which validation type applies to you. Visa's published levels are a starting point, but the compliance-accepting entity makes the final call, and it may require only a subset of requirements to be documented in a ROC.
The CSF produces something different: a self-assessed view of your cybersecurity outcomes, typically captured as Current and Target Organizational Profiles. NIST does not offer certifications, endorsements or a conformity assessment program for CSF implementations, so no CSF profile can stand in for an AOC. Mapping your CSF Subcategories to PCI DSS requirements helps you reuse evidence, but the mapping does not transfer validation. Treat the profile as the planning and governance record and the AOC as the external proof of the cardholder data environment's compliance status.
The Current and Target profiles are internal records unless a customer, acquirer, regulator or auditor asks for them. Decide early who owns them, where they are stored and what version history you keep, because a profile that was never reviewed by an assessor carries no external weight. When a payment brand or customer asks what you have validated, answer with the AOC and its scope, and use the profile only to explain your wider program. If you need to show a regulator how the CSF and PCI DSS relate, confirm with that regulator what evidence format it accepts before you build the package.
Doing both: order, scope and shared evidence
This sequence settles the PCI DSS obligation first, because the payment brands set it, then uses the validated evidence to scope a broader CSF profile without paying for the same work twice. The result is one dated testing calendar and one evidence set that both programs can cite.
Confirm the cardholder data environment and validation level
Start with the acquirer or the payment brand that sets your obligations. Ask them which entities and systems count as in scope for cardholder data, which validation level applies to you, and whether they accept a ROC or an SAQ for that level. Compliance-accepting entities decide this, and they may also limit which requirements must be tested and documented in a ROC. The output is a written scope statement that names the systems, the validation type and the acquirer's acceptance, which becomes the boundary for every later step.
Complete the PCI DSS validation on official templates
Have the in-scope team complete the validation on the official PCI SSC templates: a Report on Compliance completed by a Qualified Security Assessor, or a Self-Assessment Questionnaire, each closed with an Attestation of Compliance. Use PCI DSS v4.0.1, the only active version, and confirm the requirements that apply through the defined or customized approach. A certificate does not count as validation, so the signed AOC and supporting evidence are the output you keep and provide to the acquirer.
Put the recurring PCI testing calendar in place first
Before drafting anything broader, schedule the recurring tests that PCI DSS fixes. External ASV scans and internal scans run at least every three months. Internal and external penetration tests run at least every 12 months. Segmentation tests run every 12 months, or every six months for service providers. Assign an owner to each recurring test and record the dates in one calendar, so the CSF program later builds on evidence that already exists on a fixed cadence. The output is a dated calendar with a named owner for each test.
Build an organizational CSF profile around the PCI scope
With the PCI boundary defined, create a CSF Organizational Profile for the wider program. CSWP 29 allows several profiles, each with its own scope, so a profile can cover the cardholder data environment's supporting business functions or the whole organization. Record the Current Profile, then the Target Profile and the Tier you want to reach for each outcome. Governance outcomes such as GV.OC-03 can track the contractual requirements from acquirers and payment brands. The output is a signed profile with a stated scope and a gap list.
Map PCI requirements to CSF outcomes using published references
Use NIST's published CSF 2.0 informative references to link PCI DSS requirements to CSF Subcategories. NIST does not check non-NIST mappings and listing a mapping does not imply endorsement, so check each link against your own PCI evidence before relying on it. Where a mapping holds, mark the outcome as supported by existing PCI evidence and record the requirement reference. Where it does not, add a gap entry. The output is a reviewed mapping table that shows which CSF outcomes already have evidence and which need new work.
Reuse shared evidence without duplicating testing
Collect the artifacts that serve both programs, such as scan reports, penetration test results, segmentation test records, access reviews and change records, and store them once with a reference to the PCI requirement and the CSF Subcategory they support. Where the cardholder environment also runs SOC 2 audits, a QSA may reuse that evidence after an independent review, which can reduce duplicated evidence work. Confirm with the QSA which artifacts they will accept before you restructure the repository. The output is one evidence index that both the QSA and the CSF profile owners can cite.
Review the profile against the PCI calendar each cycle
Set a regular review that checks the CSF profile against the PCI results and the recurring test dates. When PCI DSS changes, confirm the impact on the mapping, since the PCI SSC has run a request for comments on the next iteration but has announced no release date. When CSF informative references or Quick-Start Guides update, which NIST publishes online, refresh the mapping table. Record what changed and who approved it. The output is a dated revision of the profile and the evidence index, with a note of any PCI requirement whose mapping was affected.
Who assesses each framework and what it issues
This table compares who checks each framework, what document or proof comes out of the check, and how often it recurs. Read it to see which obligations are self-assessed and which require an external assessor and a signed attestation.
| Dimension | NIST CSF 2.0 | PCI DSS v4.0.1 |
|---|---|---|
| Who assesses | The organization itself. NIST does not offer certifications or a conformity assessment program for the CSF. | A Qualified Security Assessor for a ROC, or the entity itself for an SAQ, depending on the level set by the payment brand. |
| Output produced | Whatever records you choose to keep, such as a Current and Target Organizational Profile and a Tier assessment. No NIST-issued certificate. | A Report on Compliance or Self-Assessment Questionnaire, each with an Attestation of Compliance. Certificates are not recognized as validation. |
| Who decides the level | No external party. You define scope and Organizational Profiles. | The compliance-accepting entity, typically a payment brand or acquirer, decides whether you file a ROC or an SAQ. |
| Assessment cycle | No fixed cycle. Set your own review rhythm and confirm what a customer or regulator expects. | Annual validation, with the payment brand setting the timing and any subset testing it requires. |
| Recurring technical tests | None prescribed by the framework. Testing frequency is a program decision. | External and internal scans at least every three months. Internal and external penetration tests at least every 12 months. |
| Confirm with your acquirer | Whether a customer or partner asks for CSF-aligned evidence in their contract. | Which validation type applies to your merchant or service provider level, and whether a QSA must reuse or review SOC 2 evidence. |
What do buyers ask before they hire help for PCI DSS and the CSF?
What drives the cost of a ROC or SAQ, and what should I ask for in a written scope?
The cost depends on which validation path you follow and how much evidence you already have. A Report on Compliance is completed by a Qualified Security Assessor, so the assessor's time is the main recurring fee, while an SAQ is completed by your organization using PCI SSC templates. Compliance-accepting entities, typically payment brands and acquirers, decide whether you validate with a ROC or an SAQ, and they may require only a subset of requirements to be documented in a ROC (PCI SSC FAQ 1473). Ask for a written scope that names the cardholder data environment, the systems and locations in it, the validation type, the requirements covered, the evidence to be produced, and which items are one-time work (such as segmentation design or policy writing) versus recurring work (such as scans and testing at the frequencies PCI DSS sets). Ask the vendor to separate their fees from any tooling or third-party testing you must buy.
Can we complete an SAQ in-house without outside help?
Often yes, if your payment flows are simple and your team can read each requirement against your own environment. The SAQ is a self-assessment on an official PCI SSC template, finished with an Attestation of Compliance, so the work and the accountability sit with your organization. Which SAQ applies, and whether you are eligible for it at all, depends on how you accept cardholder data and on the acquirer or payment brand that governs you. Recurring testing still applies: external and internal scans at least every three months and penetration tests at least every 12 months are fixed frequencies, so confirm you can run or buy those services on schedule. Check the SAQ type and your reporting obligations with your acquirer before you start.
How long does PCI DSS readiness take, and what changes the timeline?
No fixed duration applies to every organization, so treat any single number from a vendor with caution and ask for the basis. Readiness depends on how many systems sit in scope, how well segmentation is already defined, how complete your policies and asset inventory are, and whether existing audits can supply evidence. PCI SSC states that a QSA may reuse evidence from a SOC 2 or SOC 3 report after independently reviewing it, which can reduce duplicated evidence work (PCI SSC FAQ 1567). Ask the provider to break the timeline into discovery, remediation, evidence collection and assessment, and to state which parts depend on your own change windows or staff availability.
Can we use the NIST CSF alone instead of getting PCI DSS validation?
The CSF can organize your enterprise security program, but it cannot replace PCI DSS validation for account data. NIST does not offer certifications or endorsements of CSF-related implementations, and it has no plans for a conformity assessment program, so a CSF profile produces internal evidence only. PCI DSS, by contrast, is validated through a ROC or SAQ with an AOC, and the payment brands and acquirers decide whether you must validate. Many teams use the CSF to scope the wider program and map PCI DSS as an informative reference, then run PCI DSS assessment separately. If your acquirer or payment brand requires validation, a CSF profile alone will not satisfy that obligation.
Which PCI DSS version applies now, and what should we plan for next?
PCI DSS v4.0.1 is the only active version. It was published on 11 June 2024 as a limited revision of v4.0 with no added or deleted requirements, and v4.0 was retired on 31 December 2024. Of the 64 new requirements introduced in v4.0, 51 were future-dated and became effective on 31 March 2025, so assessments now expect them. From 3 June to 20 July 2026 the PCI SSC ran a request for comments to begin the next iteration of the standard, but as of October 2026 it had announced no release date for a new version. Plan against v4.0.1, confirm with your acquirer whether any transition deadline applies to you, and watch the PCI SSC publications for the next release.
What does DeployOpen provide for PCI DSS and the CSF, and what does it not provide?
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and it prepares systems, controls and evidence for compliance assessments. It also runs security testing, which can support requirements such as scanning and penetration testing, though the testing scope and frequency must be agreed against PCI DSS requirements in writing. DeployOpen does not issue a ROC, an SAQ, an Attestation of Compliance or any certification, and it is not a PCI SSC-listed QSA. Those documents come from a Qualified Security Assessor or from your own signed SAQ. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. Ask any provider, including DeployOpen, to confirm which deliverables it covers and which validation steps remain with your assessor.
What to confirm with your acquirer and assessor
Before you scope a PCI DSS program against the CSF, confirm the facts that decide what you must validate. Your merchant or service provider level sets the validation path: Visa, for example, requires an annual ROC by a QSA for Level 1 merchants and Level 1 service providers, and an annual SAQ for Level 2 and 3 merchants and Level 2 service providers. Ask your acquirer whether your level and the path it implies match what they have on file, because the payment brand and acquirer decide these matters, not the PCI SSC.
Next, ask whether your acquirer accepts an SAQ or requires a ROC, and whether it requires only a subset of requirements to be tested and documented in a ROC. The PCI SSC notes that compliance-accepting entities make this call (PCI SSC FAQ 1473), so get the answer in writing before your QSA or internal team plans evidence collection. Also confirm the scope of the cardholder data environment and any segmentation testing you must support, since the testing frequencies in the standard are fixed and recur.
Finally, confirm which future-dated requirements now apply to you. Most of the 64 new requirements from v4.0 became effective on 31 March 2025, and PCI DSS v4.0.1 is the only active version. Ask your QSA how they expect a customized approach to be evidenced, including the documented objective, the risk analysis and the testing that shows the objective is met, because that evidence is different from a defined approach checklist. Ask your largest customers and suppliers whether they expect a CSF profile, and which Organizational Profile scope they want covered. These are questions for your payment brand, acquirer and QSA, not conclusions this page can reach for you.
How DeployOpen prepares you for both frameworks
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and prepares systems and evidence for compliance assessments. We do not issue audit reports, attestations or certifications, so the PCI DSS ROC or SAQ still comes from a QSA or from your own assessment, and the CSF profile stays yours to maintain.
How we scope
- Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts
- Scope lists which systems fall in the cardholder data environment and which sit in the wider CSF profile
- Written scope names the Organizational Profiles, owners and PCI DSS requirements that the work will support
- Ask us to state which evidence is ours to prepare and which belongs to your QSA or assessor
How we build
- Controls are implemented and hardened on your cloud accounts, data centers or air-gapped networks
- Configuration is mapped to CSF Subcategories and to the PCI DSS requirements in your written scope
- Scans and penetration tests are scheduled to the PCI DSS testing frequencies that apply to your validation level
- Security testing covers applications, APIs, cloud and infrastructure where the written scope includes them
How we hand over
- Deliverables include documentation of configurations, control evidence and the mapping between CSF outcomes and PCI DSS requirements
- Runbooks and backup and upgrade procedures are handed to your own staff so the platform stays operable
- Evidence is organized on the templates your assessor or acquirer expects, so review does not depend on us
- Handover sessions walk your team through what each artifact proves and what it does not prove
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, separate from the initial fixed scope
- Retainers can track PCI DSS version changes and CSF updates, such as new Quick-Start Guides or informative reference mappings
- Ask us to confirm in the quote which support tasks recur, who performs them and how they are priced
- Support does not replace the annual validation decision, which your acquirer or brand makes
