Does NIST CSF work satisfy the GDPR for a US company with EU customers?
NIST CSF 2.0 can support the security evidence the GDPR expects under Article 32, but it does not satisfy the GDPR. The CSF is a voluntary outcome framework, while the GDPR is binding EU law on personal data with fines. A US company with EU customers should pursue its CSF program for enterprise cybersecurity risk management and the GDPR as the binding baseline for any personal data it processes about people in the EU. Most US firms in this position should run both, with the GDPR obligations mapped first and the CSF used to organize and evidence the security controls behind them.
Neither regime produces a certificate that closes the question. The GDPR requires no audit, attestation or certificate, and Article 42 certification is voluntary, issued for at most three years, and does not reduce the controller's or processor's responsibility. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services and has no plans for a conformity assessment program. When a customer asks for proof, the honest answer is a documented control set mapped to the CSF and to Article 32, plus evidence of testing. If a customer wants independent assurance, ask which attestation or certification it accepts, since the CSF itself cannot supply one.
Confirm two things before answering the customer. First, identify which of your processing activities involve EU personal data, since the GDPR applies to them regardless of where your company is based. Second, ask your EU counsel or data protection lead which supervisory authority would be competent for your processing, because that authority, not NIST, is the body that can investigate and fine. Using the CSF as the organizing layer is reasonable, but the GDPR obligations should be checked against the CSF's informative references rather than assumed to be covered by them.
How the GDPR and NIST CSF 2.0 differ on scope, force and proof
This table compares the GDPR and NIST CSF 2.0 on legal force, who each binds, enforcement, fines, certification and breach notification. Read it to see which obligations are binding EU law and which are voluntary outcomes you can choose to adopt, then check each row against your own EU exposure.
| Dimension | GDPR (Regulation (EU) 2016/679) | NIST CSF 2.0 |
|---|---|---|
| Legal status | Binding EU regulation, applicable in all Member States since 25 May 2018 | Voluntary NIST framework (CSWP 29, published 26 February 2024), not law |
| Who it binds | Controllers and processors handling personal data of people in the EU | No one by default; most organizations adopt it voluntarily, though some customers or suppliers require it |
| What it covers | Processing of personal data, including lawful basis, data subject rights, security and transfers | Cybersecurity outcomes across six Functions: Govern, Identify, Protect, Detect, Respond and Recover |
| Enforcement | Independent national supervisory authorities (Article 51), coordinated by the European Data Protection Board | No enforcement body; NIST is not a regulatory agency |
| Fines | Up to EUR 10 million or 2% of worldwide annual turnover, or up to EUR 20 million or 4%, whichever is higher, per Article 83 tier | None; no fines attach to the framework itself |
| Certification | No audit, attestation or certificate required; Article 42 certification is voluntary and does not reduce responsibility | NIST offers no certifications or endorsements and has no plans for a conformity assessment program |
| Breach notification | Notify the supervisory authority without undue delay and, where feasible, within 72 hours of awareness (Article 33(1)) | No notification clock; CSF outcomes cover Respond and Recover but set no reporting deadline |
| Voluntary or mandatory | Mandatory for any in-scope processing, regardless of how the organization describes its program | Voluntary for private organizations; mandatory only for U.S. federal agencies under a 2017 executive order |
Where CSF 2.0 outcomes support Article 32 security
Article 32(1) asks for security measures appropriate to the risk, and it names pseudonymisation and encryption, ongoing confidentiality, integrity, availability and resilience, timely restoration after an incident, and regular testing of effectiveness. CSF 2.0 does not use those words, but much of its outcome language covers the same ground. The Protect Function holds data security and access outcomes that support confidentiality and integrity. Detect and Respond support finding and containing incidents, and Recover supports timely restoration. Identify and Govern support the risk assessment that Article 32 treats as the starting point for choosing measures. Together, the CSF 2.0 Core has six Functions, 22 Categories and 106 Subcategories, according to NIST's CSF 2.0 dataset.
The Reference Tool export is where a compliance team does the practical work. It lists 363 Implementation Examples and informative references to standards such as SP 800-53 Rev. 5.2.0, ISO/IEC 27001:2022 and PCI DSS. Use it to find where your existing evidence (encryption configuration, access reviews, backup restore tests, vulnerability management records) may sit against Subcategories. Confirm each mapping against your own system before you cite it, because NIST states that it does not check the correctness of non-NIST mappings and that listing a mapping does not imply endorsement. Pseudonymisation and the regular testing duty need particular care, since CSF 2.0 has no single outcome that matches either one exactly.
A mapping shows where evidence may sit, not that a control meets Article 32. Article 32 asks whether your measures are appropriate to the risk you assessed for your processing, and that judgment belongs to the controller. Record the risk assessment, the chosen measures and the reasoning for each, then use CSF Subcategories as an index into that record. ENISA has also said its own mapping is not a measure of equivalence, and the same caution applies to any CSF crosswalk. Ask your data protection officer and security lead to sign off on the Article 32 mapping as a documented decision.
What the GDPR requires that the CSF does not cover
The CSF 2.0 describes cybersecurity outcomes and is silent on several duties the GDPR places on controllers and processors. ENISA notes that its mapping of standards to the regulation does not measure equivalence, so each card below needs its own evidence.
Lawful basis for processing
Article 6 requires a documented lawful basis for each processing purpose before personal data is collected or used. The CSF has no outcome for choosing a basis, so a secure system can still process data unlawfully. Check that each system's records of processing name a purpose, a basis and a retention rule, and that these are reviewed when the purpose changes.
Data subject rights handling
Controllers must respond to access, rectification, erasure, restriction and objection requests within the timelines in the regulation. The CSF covers protecting and disposing of data but does not describe how to find every copy of a person's data or verify a requester. Confirm that your systems can locate, export and delete personal data across backups, analytics stores and processors.
Breach notification to regulators
Article 33(1) requires notice to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach, unless the breach is unlikely to risk individuals. The CSF's Respond and Recover Functions help you contain incidents but do not set this clock or the content of the notice. Write a decision procedure that records awareness time and reasons for any delay.
Controller and processor contracts
Article 28 requires a written contract with each processor that sets out processing instructions, confidentiality, sub-processor controls and assistance with security and breach duties. A CSF Organizational Profile can list supplier risks, but it does not produce these terms. Review your vendor agreements against the Article 28 elements and keep the signed versions with your records.
Transfers outside the EEA
Chapter V governs transfers of personal data to third countries and restricts them unless a transfer mechanism applies. The CSF says nothing about where data is stored or who can access it from abroad. Map every location and remote access path for personal data, including support staff and sub-processors, and record the transfer mechanism for each.
Records supporting accountability
Article 5(2) makes the controller responsible for showing compliance, and the regulation has no audit or certificate that does this for you. CSF evidence such as risk assessments helps, but it must be joined with records of processing, consent or basis decisions, and rights responses. Assemble one evidence index that a supervisory authority could read without a briefing, and assign an owner to each record.
Where the work overlaps and where it does not
NIST CSF 2.0 and the GDPR share a security vocabulary, so one inventory and access program can feed both. The overlap stops where the GDPR adds legal duties, such as lawful basis, data subject rights and the 72-hour supervisory authority notice, which the CSF does not define.
Shared asset and data inventory
CSF 2.0 asks an organization to understand its assets and their business context, and Article 32 security depends on knowing where systems process personal data. One inventory tagged with both CSF outcomes and processing activities can serve both. It only helps if the inventory records which systems hold personal data and which processors touch them. Confirm that your record of processing activities under Article 30 is kept in step with the asset register, since the CSF does not require one.
Access control and logging work
CSF 2.0 Protect and Detect outcomes cover identity management, access permissions and log monitoring, which are also the technical measures Article 32 expects for confidentiality and integrity. Evidence gathered for CSF outcomes, such as access reviews and log records, can be reused for a GDPR assessment. Check that the logs retain the detail needed to determine whether a personal data breach occurred, because the GDPR sets its own clock for that decision.
Cross-framework mappings from CIS Navigator
The CIS Controls Navigator for v8.1 maps CIS Controls to 30 frameworks and versions, including NIST CSF 2.0, ISO/IEC 27001:2022 and NIS2. These mappings help a team spot controls that answer several frameworks at once. They are not a finding that the CSF satisfies the GDPR. Treat each mapping as a starting point, and confirm it against the regulation text and your own evidence before you rely on it.
Privacy law tracking under GV.OC-03
NIST publishes Implementation Examples for GV.OC-03, which cover a process for tracking privacy laws such as HIPAA, the CCPA and the GDPR, and aligning cybersecurity strategy with those requirements. This gives a US company a documented route to show that GDPR obligations are tracked at the governance level. The example is a suggestion, not a GDPR control. You still need named owners for EU law changes and evidence that the tracking process runs.
Harmonized control libraries
HITRUST states that its CSF harmonizes more than 70 authoritative sources, including the GDPR, on its framework page. A shared control library can reduce duplicated questionnaire answers across customers. The harmonization is HITRUST's own claim about its framework, and it does not show that any single control satisfies Article 32. Ask whether the mapping goes to the specific GDPR article you need and who validated it.
Breach notification and rights gaps
The CSF has no requirement to notify a supervisory authority within 72 hours, to inform individuals of a high-risk breach, or to answer data subject access, erasure or objection requests. Those duties need their own procedures, roles and records. The CSF Respond and Recover outcomes can support incident handling, but a team that stops there will miss the Article 33 and 34 clocks. Build the GDPR notification and rights workflow separately and test it.
Who assesses each framework and what it produces
This table compares who checks compliance under the GDPR and the NIST CSF, and what each one issues. Use it to see that CSF work produces internal evidence only, while GDPR obligations are enforced by supervisory authorities with no required audit or certificate.
| Question | GDPR | NIST CSF 2.0 |
|---|---|---|
| Who checks compliance | Independent national supervisory authorities enforce the GDPR (Article 51), with the EDPB resolving disputes between them | No regulator. NIST is not a regulatory agency, and most organizations use the CSF voluntarily |
| Is there a required audit or certificate | No. The GDPR requires no audit, attestation or certificate | No. NIST offers no certifications or endorsements and has no plans for a conformity assessment program |
| Voluntary certification route | Article 42 certification, valid for at most three years, issued by accredited bodies or supervisory authorities | None. Any third-party review is a private engagement, and its report does not carry NIST authority |
| Does certification reduce liability | No. Article 42 certification does not reduce the controller's or processor's responsibility | Not applicable. The CSF has no certification to rely on |
| What proof you can show a regulator | Records of processing, risk assessments and security measures under Article 32, shown on request during an investigation | Your own Current and Target Profiles, Tier decisions and evidence, which you must present in your own words |
| Assessment cycle | No fixed audit cycle. Supervisory authorities act on complaints, breaches and their own investigations | No fixed cycle. Your own review schedule sets the pace |
| Update cadence to track | GDPR text unchanged as of October 2026. Regulation (EU) 2025/2518 applies from 2 April 2027 | CSF 2.0 published 26 February 2024. Core not revised since, but Quick-Start Guides and mappings update online |
What drives the cost of running both
Running both the GDPR and the NIST CSF 2.0 program costs money in four places: your own staff time, outside counsel, technical testing and any implementation partner you hire for controls and evidence. Internal staff carry most of the load because the CSF outcomes and the GDPR records sit with the same privacy, security and IT owners. Outside counsel is usually the cost you cannot avoid for lawful basis analysis and transfer mechanisms, since the CSF does not address either. Technical testing is paid per exercise, and the GDPR's Article 32 expects you to test security measures regularly, so budget for it as a recurring line. An implementation partner is paid for the control build and the evidence set, and a written scope should show exactly which of those they deliver.
Separate the one-time work from the recurring work when you compare quotes. One-time items include data mapping, the Article 30 records of processing, policy and processor contract set-up, and the initial control build mapped to CSF Categories. Recurring items include periodic reviews, data subject request handling, breach response drills, retesting and updating the CSF Current Profile as systems change. Several drivers push these costs up or down: the volume and sensitivity of personal data, the number of processors that need contract reviews, the number of EU member states where you have customers or employees, and whether you already hold ISO/IEC 27001 or SOC 2 evidence that can be reused. Confirm each driver with your own inventory before you accept any estimate.
DeployOpen does not publish prices, and no price or duration is given here. Ask each provider for a written quote that lists the scope, deliverables and timeline, and that states which items are fixed-scope and which are retainers. Ask who performs the data mapping and counsel review, which testing is included and how many retests are covered, which evidence is delivered in what format, and whether any work is billed separately for each EU jurisdiction. Ask for the assumptions behind the quote, such as the record count and processor count, so you can re-price the work if your inventory changes.
Running both frameworks in the right order
This sequence settles GDPR scope and the legal record first, then uses the CSF 2.0 Subcategories as a single control map so one evidence set serves both the Article 32 security duty and the broader CSF outcomes.
Confirm GDPR scope and controller roles with counsel
Counsel and the privacy lead establish whether your organization acts as a controller, a processor or both for each EU data flow, and which EU establishments or targeting activities bring you within the GDPR. Confirm this with EU counsel, because the answer depends on your contracts and processing activities, not on the CSF. The step is done when a signed-off scope memo names each processing activity, its role and the supervisory authority you expect to deal with, and it is confirmed with counsel rather than assumed.
Build the personal data inventory and lawful basis record
The privacy and data owners list each system, dataset and vendor that holds personal data of people in the EU, recording the purpose, categories of data, storage location and transfer paths. For each purpose, counsel records the lawful basis under the GDPR, which the CSF does not provide. This inventory also feeds the Article 30 style records and transfer analysis under Chapter V. The output is a versioned inventory with an owner per system and a lawful basis entry per purpose, reviewed by counsel.
Set the Article 33 breach notification process
Security operations, legal and the privacy lead write a single incident procedure that tracks when the organization becomes aware of a breach, assesses the risk to individuals and prepares the notice to the competent supervisory authority. Article 33(1) requires notice without undue delay and, where feasible, within 72 hours of awareness, with reasons for any delay. Confirm with counsel and the relevant supervisory authority how they expect notices to be submitted and what they need in them. The step closes when a tabletop exercise has walked the procedure end to end and the gaps are logged.
Map CSF 2.0 Subcategories to the Article 32 measures
The security architect builds a crosswalk from the CSF 2.0 Core Subcategories to the Article 32(1) measures: pseudonymisation and encryption, ongoing confidentiality, integrity, availability and resilience, timely restoration, and regular testing of effectiveness. Use NIST's published informative references as a starting point, but treat them as NIST and non-NIST mappings that NIST does not validate and that do not show full coverage of the regulation. The output is a mapping sheet that marks each Article 32 measure as covered, partly covered or not covered by a Subcategory, with the gaps listed.
Close the gaps the CSF does not reach
Using the gap list, the team adds GDPR-specific work the CSF does not cover: data subject rights handling, lawful basis records, transfer safeguards and processor contract terms. Privacy counsel reviews each item and confirms what the supervisory authority would expect to see, since guidance from the European Data Protection Board and national authorities can differ in detail. The step closes when each gap has a named owner, a written control or procedure and a reference to the source it was checked against.
Reuse one evidence set for both frameworks
Security and privacy agree a single evidence repository, tagged by CSF Subcategory and by Article 32 measure, so that each artifact such as an access review, backup restore test or vulnerability report serves both mappings. The GDPR requires no certificate and CSF has no conformity assessment, so the evidence is internal proof of accountability for the controller, not a credential issued by a third party. The output is an index that links every Article 32 measure to its artifacts and their dates of review.
Schedule regular testing and review of the mapping
Article 32(1)(d) calls for a process of regularly testing, assessing and evaluating the effectiveness of the measures, and CSF 2.0 Subcategories call for ongoing improvement. The team sets a review cadence for the crosswalk, the inventory and the incident procedure, and runs tests such as restore exercises and security testing against the mapped controls. Confirm the cadence and test scope with counsel and your own risk owners, since neither framework fixes a frequency. The step is done when the schedule, owners and last-review dates are recorded and the mapping has been updated after the most recent test.
Questions US companies ask before hiring help with GDPR and NIST CSF
Can NIST CSF 2.0 alone satisfy the GDPR?
No. The CSF 2.0 is a voluntary outcome framework, while the GDPR is binding EU law on personal data. CSF 2.0 work can support the security of processing duty in Article 32, because the GDPR asks for measures appropriate to the risk, including encryption or pseudonymisation, resilience, timely restoration and regular testing. It does not cover the lawful basis for processing, data subject rights, transfer rules or the 72-hour breach notice to the supervisory authority under Article 33. Ask any adviser to map CSF outcomes to specific GDPR articles and to show which privacy duties remain open.
Does NIST certify our organization against the CSF?
No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services and has no plans to develop a conformity assessment program. A CSF assessment is an internal or contracted review, and its output is a set of documented Current and Target Profiles and a plan, not a certificate. Some customers or suppliers may still ask for evidence, so confirm in writing what form of evidence they accept before you promise a deliverable. The GDPR itself also issues no certificate, although Article 42 allows voluntary certification by accredited bodies.
How long does GDPR readiness take, and what sets the duration?
No general duration can be stated from the researched facts, so treat any timeline you hear as provisional until it is tied to a written scope. The main drivers are the number of systems and processing activities that hold personal data, how many processors and transfers must be reviewed, how much of the privacy documentation already exists, and how many EU data subject request and breach processes must be built or tested. Ask for a phased plan with named milestones and the evidence each phase will produce.
What does the work need from our internal staff?
Expect commitments from legal or privacy counsel, system owners, engineering, security operations, procurement and the business units that run processing. Privacy decisions such as lawful basis, retention periods and responses to data subject requests remain with your controller, not with an implementation partner. Security engineers will need time to provide configuration, logs and access records, and someone must own the risk decisions and sign-off. Ask the adviser to list each role, the hours it needs and the decisions only your staff can make.
Can we run a GDPR and CSF program ourselves?
Yes, many organizations do, provided they have privacy counsel and security staff who can read Article 32, Articles 33 and 34, and the CSF 2.0 Core. The CSF Informative References and Implementation Examples are published online and are updated more often than the framework document, so keep a dated record of which version you mapped against. A self-run program usually needs a named owner, a register of processing activities, a tested incident process and an evidence library. Outside help is most useful for independent testing, cyber range exercises and a gap review before a customer audit.
What does a fixed-scope DeployOpen engagement cover, and how is it priced?
DeployOpen works on fixed-scope engagements where scope, deliverables and timelines are agreed in writing before work starts. For this topic, that can include planning and mapping CSF 2.0 outcomes to GDPR security duties, hardening self-hosted platforms in your own infrastructure, security testing and preparing evidence for assessments. DeployOpen prepares systems and evidence but does not issue audit reports, attestations or certifications. DeployOpen does not publish a price list. A quote follows from the written scope, so ask for the deliverables, the assumptions, the client responsibilities and which items recur, such as retainers for ongoing support or continuous testing.
Do the 2026 Omnibus proposals change the GDPR text?
Not yet. As of October 2026 the GDPR text has not been amended. The Omnibus IV proposal (COM(2025) 501) has a text agreed in interinstitutional negotiations on 26 June 2026 and awaits Parliament's first-reading vote, while the Digital Omnibus proposal (COM(2025) 837) is awaiting committee decision. Separately, Regulation (EU) 2025/2518 applies from 2 April 2027 and sets additional procedural rules for cross-border enforcement. Check the European Parliament Legislative Observatory before you finalize a control mapping, and record the date you checked.
What to confirm with counsel, the supervisory authority and your own systems
Several points decide whether the GDPR applies to you and how it is enforced, and none of them is settled by the NIST CSF or by this page. First, confirm whether your processing triggers the territorial scope in Article 3. A US company with no EU establishment can still fall under the GDPR when it offers goods or services to people in the EU or monitors their behavior, so ask counsel to test each product, marketing flow and data source against those two tests. Record the answer per processing activity, not once for the whole company.
Second, ask counsel which supervisory authority would act as lead, if any. The lead authority is usually tied to your main establishment in the EU, and a US-only company may have no lead authority at all, which changes who receives your breach notice under Article 33 and who investigates a complaint. Third, if you move personal data to the United States under the EU-US Data Privacy Framework, confirm with counsel whether your recipient is certified and whether the 2023 Commission decision covers that transfer. Read the decision itself at Commission Implementing Decision (EU) 2023/1795 before relying on it.
Fourth, plan for the cross-border procedural rules in Regulation (EU) 2025/2518, which apply from 2 April 2027 and govern complaints and investigations in cross-border cases. Ask counsel how the rules will change your cooperation duties with a lead authority and your documentation needs. Finally, check sector rules that sit on top of the GDPR, such as financial, health or public sector obligations in each Member State, and confirm with your own compliance lead and technical owners which systems, logs and vendors hold personal data so that the evidence you collect for CSF outcomes matches what the regulator will ask for.
How DeployOpen prepares GDPR and NIST CSF readiness
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and prepares the controls and evidence your teams need to run both a GDPR program and a NIST CSF 2.0 profile. We work from a written scope, so you know what is covered before any work starts.
How we scope
- We agree in writing which personal data processing, systems and teams the GDPR work covers.
- We map the CSF 2.0 Functions and Categories you plan to use against those same systems.
- We confirm which Article 32 measures and breach notification steps your scope includes.
How we build
- We configure self-hosted platforms in your cloud accounts, data centers or air-gapped networks.
- We document how security of processing measures, logging and access controls operate in your environment.
- We test the resulting controls with security testing and record the results against the agreed scope.
How we hand over
- We deliver documentation that ties each CSF Subcategory and GDPR obligation to a named control and owner.
- We provide evidence packs that show how controls operated, for review by your assessors and counsel.
- We train your staff to run the incident and breach notification process within the agreed scope.
How we support
- Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as retainers.
- A retainer can keep CSF profiles, control evidence and breach runbooks current as your systems change.
- We do not issue audit reports, attestations or certifications, so your independent auditors or counsel make those determinations.
Sources and further reading
- Regulation (EU) 2016/679 (GDPR), EUR-Lex ↗
- NIST CSWP 29, The NIST Cybersecurity Framework (CSF) 2.0 (CSRC publication page) ↗
- NIST CSF 2.0 Reference Tool export: Core, Implementation Examples and Informative References ↗
- NIST Cybersecurity Framework FAQs ↗
- NIST Informative References for CSF 2.0 ↗
- NIST Cybersecurity Framework updates archive ↗
