Does GDPR Compliance Cover CCPA?

Partly, and the crosswalk number is a trap in both directions. In our framework mapping dataset, GDPR maps to 59 distinct NIST SP 800-53 Rev 5 controls and CCPA with CPRA maps to 215, of which 50 are shared. So 85 percent of everything GDPR reaches sits inside the California footprint, and only 23 percent of what California reaches sits inside GDPR's, which reads like California is the larger programme until you look at what each lens is made of. The California side is the 2025 regulations, whose cybersecurity audit, risk assessment and automated decision-making articles map to acquisition, configuration and system-integrity controls by the dozen; the GDPR side is the articles for which the source framework carries a NIST 800-53 mapping at all, and 62 of the article paragraphs in that source carry none. The contrarian version: the crosswalk cannot see most of GDPR and sees the security half of the California regulations very well, so neither percentage says anything about whether one programme covers the other.

This article shows what the two footprints are made of, explains why a security-control crosswalk is the wrong instrument for a rights statute, names the obligations that never appear in any mapping, and gives the small number of things that genuinely do transfer.

Key takeaways

• Measured on our dataset: GDPR reaches 59 NIST 800-53 controls, CCPA and CPRA reach 215, and 50 are shared. That is 85 percent of the GDPR footprint and 23 percent of the CCPA footprint.
• The California footprint is large because the lens is the 2025 regulations, including the cybersecurity audit, risk assessment and automated decision-making technology articles: System and Services Acquisition (30), Configuration Management (23) and System and Information Integrity (23) lead it. The GDPR footprint is small because most GDPR articles map, in the source framework, to controls that carry no NIST 800-53 mapping.
• Neither fact is a defect in the mapping. Both follow from what the instruments are and from what a control catalogue can express: an audit and risk-assessment regulation maps well, and a rights statute mostly does not.
• The obligations that actually consume a California privacy budget, opt-out signal handling, notice content, request verification, are procedural and appear in no control crosswalk.
• Use the mapping to find reusable security evidence. Do not use it to size a CCPA programme, in either direction.

What the two footprints are made of

Both frameworks in our dataset are mapped to NIST SP 800-53 Rev 5, so the shared ground is the intersection of the NIST controls each one reaches, listed in full on the GDPR to CCPA pair page.

The GDPR side reaches 59 controls, spread thinly across every family: Program Management 11, PII Processing and Transparency 9, Incident Response 5, System and Information Integrity 5, Access Control 4, System and Communications Protection 4, three each in Assessment and Monitoring, Contingency Planning and Personnel Security, two in Risk Assessment, and one each in the other ten. Twenty of those are the family policy-and-procedure controls, one per family.

The CCPA and CPRA side reaches 215, and it is a security footprint before it is a privacy one: System and Services Acquisition 30, Configuration Management 23, System and Information Integrity 23, Program Management 21, System and Communications Protection 18, PII Processing and Transparency 12, Access Control 11, Identification and Authentication 10, and the remaining families in single digits. That shape comes from the 2025 California regulations, which added articles on cybersecurity audits, risk assessments and automated decision-making technology, and those articles are what a control mapper can attach real security controls to.

The shared 50 are the privacy-programme core plus the policy layer: authority to process, processing purposes, consent, privacy notice, privacy policies on websites and services, specific categories of personal information (Social Security numbers and First Amendment information), individual access and individual requests, complaint management, privacy impact assessments, information management and retention, the privacy programme plan, plus all twenty family policy-and-procedure controls (every one GDPR reaches is also in the California footprint) and a handful of security controls both sides reach (cryptographic protection, contingency planning, continuous monitoring, privileged accounts, position risk designation).

Nine controls are reached by GDPR and not by the California side in this dataset, and they are a revealing set: data sanitization, incident monitoring, incident reporting, the breaches enhancement of the incident response plan, privacy reporting, the risk management strategy, position descriptions, revocation of consent, and information disposal. Breach handling and consent withdrawal, in other words: the obligations GDPR states as duties of the controller and California states mostly as consumer rights and regulator process. The other direction is 165 controls reached only by the California side, almost all of them security-programme controls the audit and risk-assessment articles enumerate.

Why a control crosswalk under-reads a rights statute

The asymmetry is not an accident of authorship. It follows from how the two instruments are written, from which parts of each a control catalogue can express, and from a limit of the source data that is worth stating plainly.

GDPR carries a dedicated security article. Article 32(1) requires the controller and processor to "implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk", and then names four categories: pseudonymisation and encryption, ongoing confidentiality, integrity, availability and resilience, restoration of availability after an incident, and "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures". That is four control families' worth of obligation in one paragraph, and Article 32 is where most of GDPR's security controls in our mapping come from. That text is reproduced on gdpr-info.eu, a reference site operated by a data-protection consultancy that sells services in this market; the authoritative text is the Regulation itself in the Official Journal.

Most of the rest of GDPR is not written that way. Processor contracts, data protection officers, transfers, records of processing, the rights themselves: our source framework maps those articles to its own privacy controls, and for 62 of the GDPR article paragraphs it carries, those privacy controls have no NIST SP 800-53 Rev 5 counterpart, so they contribute nothing to the footprint. The 59 is not GDPR's weight; it is the part of GDPR a security-control catalogue can hold.

California's statutory security obligation is one sentence, and it delegates. Civil Code section 1798.100(e) requires a business that collects personal information to "implement reasonable security procedures and practices appropriate to the nature of the personal information to protect the personal information from unauthorized or illegal access, destruction, use, modification, or disclosure in accordance with Section 1798.81.5." A reasonableness standard that cross-references a separate breach statute gives a control mapper almost nothing. What changed the picture is the regulations: the cybersecurity audit and risk assessment articles enumerate the components an audit must cover and the assessment must document, and that enumeration is what maps to 215 controls.

So the honest reading of the 85 percent is: of the part of GDPR a security catalogue can see at all, California's audit and assessment regulations reach most of it. And the honest reading of the 23 percent is that the California regulations describe a great deal of security programme content that GDPR states in one article. Neither number measures whether a GDPR programme satisfies a California regulator, and both are much less useful than they sound.

The obligations no mapping will show you

Everything that makes a California privacy programme expensive is procedural, and procedure does not map to a security-control catalogue.

Rights request handling and verification. Intake, identity verification proportional to the sensitivity of the request, response within a deadline, and a record of what was done. One NIST control gestures at this; a working programme is a process, a queue, and a team.

Opt-out of sale and sharing, including universal signals. The link, the flow, the propagation to downstream recipients, and the handling of browser-based universal opt-out signals. Our US state privacy laws guide covers which states require signal recognition and the applicability thresholds, and it is the page to read for whether California applies to you at all.

Notice content and placement. What has to be disclosed, where, and updated on what cadence.

Service provider and contractor terms. Contract language with defined content, which is a legal deliverable rather than a control.

Assessment and audit obligations under the California regulations. These are rulemaking-driven and move; treat any specific requirement you read as needing a date check against the agency's own published regulations rather than a vendor summary.

None of the five appears in a NIST 800-53 crosswalk in any meaningful form. If you scope a California programme from a mapping, you will scope the cheap half.

What genuinely does transfer

The mapping is not useless. It is precise about a narrow and real thing.

If you have run a GDPR programme properly, the following usually carry over with tagging rather than rework: your record of what personal data you hold and why, your lawful basis and purpose documentation, your privacy notice machinery, your consent capture flows, your privacy impact assessments, your retention schedule, your complaint handling, your privacy programme plan, and the policy layer of your security programme. Those are the 50 shared controls, restated in artifact terms.

What does not transfer is the shape of the rights. GDPR access, rectification, erasure, portability and objection are not the same set as California's know, delete, correct, opt out of sale or sharing, and limit use of sensitive personal information. The overlap is real and the verification standards, deadlines and exceptions differ, so a request workflow built for one needs rework rather than reuse. Our piece on GRC platforms versus people covers where tooling helps with that and where it does not.

The other direction is worth stating too, because it is asked less often and the crosswalk flatters it most. Nine of GDPR's 59 mapped controls are outside the California footprint, which sounds like a California programme is nearly a GDPR programme. It is not. The 59 is the fraction of GDPR a security catalogue can see; the processor contracts, the data protection officer, the transfer mechanisms and the records of processing sit among the 62 article paragraphs that map to nothing in it, so "we are CCPA compliant" tells a European counterparty very little, and the crosswalk cannot tell you that.

The honest caveat

Five limits on everything above.

Our California lens is the regulations, not the whole statute. The identifiers in it are numbered regulation sections, 262 of them. Statutory obligations that no regulation section elaborates are under-represented by construction.

Our GDPR lens is the part of GDPR the source can pivot. The lens carries 54 article paragraphs. The source framework cites 62 more whose privacy controls have no NIST SP 800-53 Rev 5 mapping, so they are absent from the footprint rather than counted as zero. A small GDPR number here is a statement about the catalogue, not about the Regulation.

A mapped control is not an implemented control, and neither is a shared one. The dataset says both laws point at the same NIST control. It says nothing about whether what you built satisfies either regulator.

Two controls on a shared row are related through the NIST control between them. They are not asserted to be equivalent, and we do not publish an authored GDPR-to-CCPA crosswalk, because we have not sourced one and inventing one would be a fabrication.

Privacy law moves faster than mapping data. The California regulations keep moving and other states keep arriving. Treat this mapping as a stable structural picture and every specific obligation as something to re-check against the agency's own published regulations rather than against this page.

Against our own interest: if California is your only privacy exposure and your business is under the applicability thresholds, the correct amount of consulting to buy is close to none. Read the thresholds in the state privacy guide, confirm the answer, and spend the budget on the rights-request process instead. We would rather say that than sell a mapping exercise to a company that does not need one.

Where Top Floor fits

Where an outside team is worth paying for is the multi-jurisdiction case the numbers above describe: a European footprint and a California footprint and a sales team promising both to enterprise buyers next quarter. That is what global privacy work is scoped around, and it starts from one data map and one rights process rather than two parallel programmes.

For the single-jurisdiction versions, GDPR and CCPA are the service pages, and the honest sequencing advice is the same one the crosswalk implies: build the harder programme once, then extend it, rather than building the easier one and discovering it was not a foundation.

How to decide this week

Open the GDPR to CCPA pair page and read the 50 shared controls as a checklist of evidence you may already hold. Tag whatever you find to both regimes now, while you can remember where it came from.

Then write down the five procedural obligations listed above and mark each one as built, partly built, or absent. That list, not the 85 percent, is your California scope. If the answer is that four of the five are absent, your GDPR programme has bought you less than the crosswalk suggests, and that is a normal and recoverable position rather than a failure. It is just not the position a percentage would have told you about.

Frequently asked questions

Does GDPR compliance make us CCPA compliant?

No. In our mapping dataset, 50 of the 59 NIST SP 800-53 controls GDPR reaches are also reached by the California privacy regulations, which sounds like most of the way. But the GDPR footprint is small precisely because most of GDPR maps to privacy controls a security catalogue cannot see, the California footprint is large because its 2025 regulations enumerate audit and risk-assessment content, and the obligations that consume a California budget, rights request handling, opt-out and universal signal support, notice content, and service provider contract terms, are procedural and appear in no control mapping. GDPR work gives you a strong head start on documentation and consent machinery, not compliance.

What is the actual overlap between GDPR and CCPA?

GDPR maps to 59 distinct NIST SP 800-53 Rev 5 controls in our dataset, CCPA with CPRA maps to 215, and 50 are shared. That is 85 percent of the GDPR footprint and 23 percent of the CCPA footprint, from the same intersection. The shared set is the privacy-programme core, notice, consent, purposes, individual requests, complaint handling and impact assessment, plus the policy-and-procedure control of every one of the twenty NIST families.

Can I reuse my GDPR data subject request process for CCPA?

Partly. The intake, the identity verification concept, the record-keeping and the escalation path transfer. The rights themselves do not line up one to one, and the deadlines, verification standards and exceptions differ, so the workflow needs rework rather than a relabel. Budget for a review of every branch in the process rather than a mapping exercise.

Why does a security control crosswalk under-represent privacy law?

Because a crosswalk maps to a security and privacy control catalogue, and much of privacy law is not control content at all. Deadlines, disclosure text, contract clauses, applicability thresholds and verification standards have no control to attach to. A crosswalk is a good instrument for finding reusable security evidence across regimes and a poor instrument for sizing a privacy programme, and using it for the second job is the mistake this article exists to prevent.