Data privacy under GDPR and CCPA: a practical guide

A vendor shows a support chatbot. The presentation continues until a participant inquires about the origin of the training data. The data comprises eighteen months of live chat transcripts. These records contain names, order numbers, and occasional references to health conditions that were used to explain product returns. There is no documentation that the individuals consented to their data being used for training purposes, and the demonstration proceeds. The question stays unanswered throughout the meeting. This issue ought to have been settled prior to exporting the data.

GDPR and CCPA are two separate regulatory frameworks governing data privacy. They employ comparable terminology yet are based on different legal foundations. Under GDPR, a business must establish a lawful basis for processing data before it starts. Conversely, CCPA permits businesses to collect data by default, as long as they inform consumers and give them the option to opt out.

Data privacy under GDPR differs from that under CCPA. Both regulations address "privacy" and demand comparable documentation, which frequently causes confusion. GDPR is based on the principle that a valid reason is required before processing personal data. CCPA follows the principle that data may be processed, yet individuals retain the right to control its use. Confusing the two can lead to deploying a consent banner unnecessarily, or providing a California-style opt-out link when a different method is needed for GDPR compliance.

Shipshape Data develops data and AI systems for its clients. Privacy concerns represent the most frequent cause of AI project failure. This occurs when data was gathered for a different purpose years prior to model training, and the original collection terms were not re-examined. This guide outlines the requirements of GDPR and CCPA. It highlights the differences between these two systems. The text provides information on lawful bases, consent, and data subject rights. It also discusses data minimisation and retention. It examines how obligations shift when personal data is used to feed or train a model. This information does not constitute legal advice. It does not substitute for a lawyer who understands your particular processing activities. This guide assists practitioners in identifying where legal obligations apply.

Why privacy failures cost more than the fine

GDPR fines attract considerable media attention due to the high potential penalties. Fines may reach twenty million euros or four per cent of an organisation's global annual turnover, whichever is higher. Although these numbers act as a deterrent, they are not the most common financial outcome because maximum penalties are seldom imposed. The more common costs linked to non-compliance are less visible and harder to anticipate.

The fine is the least of it

Answering a data subject access request demands considerable time. You must identify every system holding the individual's data, decide which information you may legally withhold, and deliver a response within the prescribed timeframe. Poor handling of these requests can damage your reputation. The breach notification deadline starts when you first become aware of the incident, not when the investigation ends. As a result, you will have the least information available during the most challenging period.

A data subject access request is a formal obligation that your legal team must fulfil. It entails an individual requesting, within one month, a full record of the data you retain about them and the origin of that information. During their first request, most organisations discover that they lack a clear understanding of their own data holdings.

Enforcement reaches further down than the headlines suggest

The cases that make the news are the large ones. UK and EU regulators have also fined small businesses over things as ordinary as a badly configured marketing list or a CCTV system nobody registered a purpose for. CCPA works differently: California's Attorney General and Privacy Protection Agency enforce it directly, and consumers get a narrow private right of action for certain breaches, with statutory damages set between roughly a hundred and seven hundred and fifty dollars per incident. Multiply that across a customer list.

GDPR and CCPA solve different problems

If you consider these as the same law with different wording, you will develop the wrong programme. They start from opposite default positions.

Opt-in against opt-out, the fork everything hangs on

GDPR starts with the rule that processing personal data is prohibited unless a business can point to one of six specific lawful grounds. Processing cannot take place without a lawful basis, even if the individual objects. CCPA takes a different approach. A business is generally allowed to collect and use personal information for its operations. The law mainly works by giving consumers transparency and the right to opt out, particularly concerning the sale or sharing of their data. GDPR requires permission before data is processed. CCPA notifies the consumer of the activity and allows them to object.

If a company mixes up these two concepts, it might request unnecessary consent or neglect to provide a required opt-out link.

Responsible parties and oversight authorities

GDPR applies to any entity that processes the personal data of individuals in the EU or UK. The regulation covers businesses irrespective of their size or location. A startup with three employees and European customers must comply right away. CCPA applies only when a business satisfies specific criteria. These criteria include exceeding a revenue threshold, handling data for a large number of California residents, or deriving most revenue from selling that data. A small business might not be subject to CCPA at all, even if it must follow GDPR because it has a single customer in the EU.

Lawful basis comes before consent

Consent is the lawful basis that organisations typically select first, yet it is often the wrong choice. GDPR offers six bases: consent, contract, legal obligation, vital interests, public task, and legitimate interests. The contract basis applies to processing needed to provide the service a person requested. Legitimate interests applies to processing that is proportionate and expected, provided you have conducted a balancing test showing your interests do not outweigh the individual's rights. Consent is required only when no other basis applies. Using consent as a default renders a compliance programme unstable, since consent can be withdrawn at any time. If that occurs, any processing based on that consent must cease immediately.

What makes consent valid

For consent to be valid under GDPR, it must be freely given, purpose-specific, and informed. It requires a clear affirmative action instead of silence or pre-ticked boxes. Withdrawing consent must be as easy as giving it. Merging consent for a privacy policy with consent for marketing is generally prohibited, because the choice is not free if the user must accept marketing to use the service. Creating granular consent for each specific purpose demands more effort, yet it offers a more accurate description of what is being requested.

How the CCPA defines its scope differently

The CCPA does not employ the concept of lawful basis as its primary framework. Instead, the law relies on a notice-and-choice model. Organisations must inform individuals about the data they collect and its purpose, while permitting them to opt out of the sale or sharing of that information. Mandatory opt-in consent is required only in certain situations, such as when selling the data of a known minor or processing sensitive categories like precise geolocation, health information, or biometric identifiers. If you treat these requirements as the same as GDPR consent, you will either create unnecessary processes for California or fail to meet the standards required in Europe.

Legal rights of individuals

Both laws give individuals rights over their own data, but these rights differ. GDPR provides a more complete set of rights: access, rectification, erasure, restriction of processing, data portability, the right to object, and rights related to automated decision-making, in addition to the basic right to be informed. Our guide to the eight GDPR data subject rights details each right, including how to fulfil a request and acknowledge it. CCPA's list is shorter and focuses more on transactions: the right to know what has been collected, the right to delete, the right to correct, the right to opt out of sale or sharing, and the right to limit the use of sensitive personal information, as well as the right not to be discriminated against for exercising these rights.

The response clock is shorter than people think

The GDPR requires you to respond to most requests within one month. You may extend this by two months for complex cases, provided you notify the individual of the extension. The CCPA allows businesses forty-five days to respond and permits one similar extension. Both regulations assume you can locate all of a person's data. Organisations often struggle because fulfilling a request requires searching every system that contains a portion of a record. If you have not mapped your data beforehand, the first request you receive will force you to perform that mapping exercise.

Erasure is not absolute either.

You may typically retain data required by a legal obligation, an active contract, or a defence against a claim, as long as you can identify the specific exception. If you delete a live record but keep it in an unedited backup for eleven months, you have an operational problem rather than a valid method for bypassing retention rules.

Minimisation and retention: collecting less, keeping it for less time

Two GDPR principles are more practical than any of the specific rights. Data must be adequate, relevant, and limited to what is necessary. It also must not be kept longer than its purpose requires. Neither principle prohibits any specific action. Instead, both require you to justify decisions that would otherwise go unquestioned. This is why these principles are often ignored until an audit occurs.

The instinct to keep everything is the enemy here

Most organisations collect more information than their stated purposes require. It is easy to add extra fields to a form, and few people reject the collection of "just in case" data. This same habit affects data retention. Deleting information can feel risky while keeping it feels safe. As a result, many records are stored for years after they are no longer useful.

This is backwards.

Storing personal data that you do not use creates risk without providing any value. Retaining extra information or keeping records for longer than necessary increases the burden of proof if a regulator questions your data practices. A written retention policy is ineffective if it is not followed. To reduce actual risk, you must assign a specific retention period to every category of data during the design phase. You should automate the deletion process instead of relying on manual tasks. This process requires acknowledging that data kept for six years may not have been accessed for the last four.

What changes once the data trains or runs a model

These principles remain relevant when using artificial intelligence. The effects are simply more difficult to observe.

Training data must justify its own use

Data collected for a specific reason, such as managing a support desk or processing an order, does not automatically have a lawful basis for a different purpose like training a model. This reuse constitutes new processing. It requires its own justification rather than relying on the consent or contract that applied to the original collection.

This is not theoretical.

Italy's data protection authority temporarily ordered ChatGPT blocked in March 2023 over exactly this kind of question, including whether the training data had a valid legal basis and whether users had been properly informed. The service returned once changes were made, and the episode previews the question any regulator eventually asks: where did this come from, and did anyone agree to this specific use.

The model remembers what the record forgot

It is easy to delete a row from a database. It is difficult to delete what a model learned from that row during training. This is because the information is no longer a separate fact. It is spread across weights that also represent millions of other records. Real machine unlearning involves removing the influence of one person without retraining the entire model. This is currently a difficult technical problem. The honest answer to "can you erase me from the model" is often "not without retraining it." Using pseudonyms for data before training is helpful. However, large language models can memorise and sometimes repeat parts of their training data. Using pseudonyms is therefore not always a sufficient protection.

Sending personal data to someone else's model is still a transfer

When you use a hosted large language model with customer data, that information leaves your organisation. It goes to a processor or a sub-processor. If that vendor is outside the UK or EU, this is a cross-border transfer. You must use a legal mechanism like standard contractual clauses. These requirements apply even when the interface is a chat window rather than a database connection. If you do not need personal data, you should consider using synthetic or de-identified alternatives instead of real data. Our article on synthetic data explains the trade-offs involved in that choice.

Automated decisions still need a human somewhere

The GDPR provides individuals with the right to avoid decisions made only through automated processing, such as profiling, when those decisions have legal or significant consequences. Examples include being denied a loan or a job. If a model generates a score and a person approves it without a meaningful review, the process does not meet these legal standards. California is adopting similar regulations. The CPRA includes rules for automated decision-making that establish requirements for notice and the ability to opt out. When the output of a model affects a person, an accountable individual must be able to explain the result. In cases where the law requires it, that individual must also be able to override the model's decision.

The unglamorous mechanics that keep you compliant

None of the above stays true on its own. It needs a small set of unglamorous, recurring admin behind it, and skipping this is how a programme that looks fine on paper turns out to have nobody who can answer a regulator's first question.

Assess the risk before you build, not after

GDPR requires you to complete a data protection impact assessment before you begin any processing likely to result in high risks to individuals. This requirement applies to significant AI projects that use personal data. Examples include large-scale profiling, systematic monitoring, and the processing of sensitive categories at scale. Our guide to DPIAs explains the necessary contents of these assessments. You will have to retrofit your work if you wait until the model is in production to perform this assessment. You should address issues during the design phase instead. Retrofitting often shows that the existing architecture cannot support the safeguards required by the assessment.

Records, contracts, and the seventy-two-hour clock

The GDPR requires you to maintain an updated record of your processing activities. You must keep this document current instead of creating it only for an audit. Every processor that handles personal data for you, such as an AI vendor, must sign a data processing agreement. This agreement must define the specific permissions and restrictions for using that data. If a data breach occurs, you have seventy-two hours to notify the appropriate authority. This time limit begins when you become aware of the breach, rather than when your investigation ends. The CCPA does not establish a specific notification window, but you must still follow California's separate breach notification laws.

Where to start

Begin by identifying your actual data holdings rather than relying on existing data maps. Most organisations that believe they know where personal data is stored are incorrect about at least one system. This often involves a spreadsheet, a support tool, or a training export created eighteen months ago that was never logged. Creating this inventory is tedious, but it is the necessary basis for all subsequent work. Next, determine for each dataset which lawful basis or CCPA disclosure applies. Verify that the retention period aligns with a legitimate purpose and confirm that any data used for AI systems was collected specifically for that use. Address these gaps before building the next model rather than attempting to fix them afterwards.

Privacy compliance is a continuous process rather than a single task. You must maintain this discipline as your data and systems evolve. This is particularly important when using AI, as technical questions become more complex and errors are more difficult to detect. If you are developing an AI system using data with uncertain privacy status, or if you require an assessment of how GDPR or CCPA applies to your specific processing activities, talk to us. We prefer to help you identify gaps before they are discovered through a data subject access request.

Our data consultants build these systems for UK organisations. We focus on the foundation first to ensure the results are reliable.

Frequently asked questions