Data rights, explained plainly
GDPR, CCPA, and what they actually require of your business. No legalese.
Why this exists
Two major laws changed how businesses must handle personal data: the General Data Protection Regulation (GDPR) in Europe, and the California Consumer Privacy Act (CCPA) in the United States.
Both laws give people specific rights over the personal data that businesses collect about them. The core idea is the same: you collected data about someone, and they should have some say in what happens to it.
The rights those laws grant include:
- Right to access: A person can ask to see what data you hold about them.
- Right to deletion: A person can ask you to delete their data. Sometimes called the "right to erasure" under GDPR.
- Right to correction: A person can ask you to fix inaccurate data.
- Right to portability: A person can ask to receive their data in a usable format.
- Right to opt out of sale: Under CCPA, a person can tell you not to sell their data.
Allies Comply focuses on the two most commonly exercised rights: access (view) and deletion. When a user submits a request through the Comply widget, they are exercising one of these rights.
GDPR vs. CCPA: what is the difference?
Both laws protect people's data rights, but they differ in scope, geography, and some details. Here is the short version.
| Topic | GDPR | CCPA |
|---|---|---|
| Who it protects | Anyone in the European Union or European Economic Area | California residents |
| Who must comply | Any organization handling EU residents' data, regardless of where the business is located | Businesses meeting certain size or revenue thresholds that handle California residents' data |
| Response time | 30 days (extendable to 90 days with notice) | 45 days (extendable to 90 days with notice) |
| Legal basis for deletion | Right to erasure; applies unless a specific exception overrides it | Right to delete; similar exceptions apply |
| Opt-out of data sale | Not a core GDPR right (but related consent rules apply) | Yes, an explicit CCPA right |
| Penalties | Up to 4% of global annual revenue or 20M euros, whichever is higher | Up to $7,500 per intentional violation; $2,500 per unintentional |
| Verification required | Reasonable verification; cannot be so burdensome it blocks the right | Reasonable verification proportionate to sensitivity of data |
If your users could be from the EU or California, you should treat all data requests as subject to the stricter of the two standards. In practice, this means the 30-day GDPR timeline and the GDPR's broader definition of personal data.
The timelines
Both laws require you to respond within a set window. Here is how to count correctly.
When the clock starts
Under GDPR, the clock starts when you receive the request, which is when the user submits the form. Not when they verify their email. Not when you see it in the dashboard.
Under CCPA, the clock also starts at receipt of the request.
Comply shows you the submission timestamp on every request. Use that as your starting point.
What counts as a response
You need to do one of three things within the window:
- Fulfill the request: provide the data (view) or delete it (delete).
- Deny the request for a valid legal reason and tell the user why.
- Notify the user that you need more time, give a reason, and fulfill within an extended deadline (90 days total under both GDPR and CCPA, with notice).
Extensions
Both laws allow a one-time extension, but you must notify the user within the original window. You cannot silently let the deadline pass and then respond later. If you need more time, tell the user before the 30-day or 45-day mark.
Valid reasons to deny a request
Denial is not a general opt-out. Both GDPR and CCPA give people real rights, and you can only deny when one of a narrow set of legal exceptions applies. Here are the ones that come up most often.
Legal obligation to retain the data
If a law or regulation requires you to keep specific data, you cannot delete it even if someone asks. Examples include financial transaction records required by tax law, employment records required by labor law, or data subject to a litigation hold.
If this applies, tell the user plainly: "We are required by [law] to retain this record for [period]. We have deleted everything else we have about you."
Cannot verify the requester's identity
If you cannot confirm that the person submitting the request is who they say they are, and fulfilling the request would risk exposing another person's data, you can ask for additional verification or deny the request.
Comply's email verification step satisfies basic identity verification for most cases. This exception is mainly relevant when the request asks for sensitive data or there are signs of fraud.
Request is excessive or repetitive
You can deny a request that is manifestly unfounded or excessive. If the same person submits identical requests week after week with no new information, that may qualify.
This exception is narrow. Regulators take a skeptical view of businesses using it to avoid legitimate requests. Document your reasoning if you use it.
Public interest or research
Under GDPR, deletion can be refused if the data is needed for public interest tasks, scientific research, or archiving in the public interest. This is rarely relevant for small businesses.
Deletion vs. anonymization
When someone asks you to delete their data, you do not always have to delete the entire database record. Sometimes anonymization is the right approach, and it is legally valid under both GDPR and CCPA.
When to delete the whole record
If a row exists solely to hold personal data and has no other business value, delete it entirely. A row in a mailing list table, for example. The whole point of that row is the person's identity. Anonymizing it leaves a useless empty shell.
When anonymization is appropriate
Some records have business value beyond the personal data they contain. An order history row is an example. The order details (items purchased, amount paid, date) are valuable for your business records and may be required for tax purposes. But the customer's name and email on that row are personal data.
In this case, anonymizing the personal fields (replacing the name with a placeholder like "Deleted User" and clearing the email) satisfies the deletion request without destroying the record entirely. The person can no longer be identified from that row.
What counts as proper anonymization
Proper anonymization means the data can no longer be traced back to a specific person, even with other information you might have. Pseudonymization (replacing a name with a code that you can look up) is not the same as anonymization. Comply uses actual value replacement, not pseudonymization.
Both GDPR and CCPA accept properly anonymized data as fulfillment of a deletion request. If you are ever asked to prove compliance, the key question is: can this record still be linked to the person who requested deletion? If no, you are covered.
Data Comply cannot reach
Comply scans your connected databases and handles data it can find there. But personal data exists in many other places, and those are your responsibility.
The linking problem
A lot of tracking data is collected without being linked to an email address. Cookies store a device ID. Analytics tools log an IP address. Ad platforms track a browser fingerprint. These records exist in your systems, but there is no reliable automatic way to connect them to the person who submitted a request.
Comply captures the requesting user's IP, user-agent, and session cookies to help with this, but those identifiers are unreliable over time. The IP may have changed. The cookies may have been cleared. Another person in the household may have shared the device.
What you need to do manually
When you receive a deletion request, check all your data systems, not just the ones Comply can see. This includes:
- Analytics tools (Google Analytics, Mixpanel, etc.) where you can look up by email or run user deletion requests through their own tools.
- Email marketing platforms (Mailchimp, etc.).
- CRM systems and customer support tools.
- Any backup or archive systems.
- Third-party ad platforms if you run retargeting.
Most major platforms have their own data deletion request mechanisms. Use them alongside Comply.
Irreversibly anonymized data
Some data categories, once collected, cannot be reliably re-linked to an individual. Aggregate analytics data is a good example: if you store "100 people visited page X on Tuesday," there is no individual to delete. Both GDPR and CCPA recognize this. If data has been irreversibly anonymized, you can disclose this to the requester as part of your response.
The key word is irreversibly. If you can look up who those 100 people were, the data is not anonymized at that level.
What Comply handles vs. what you still own
| Task | Comply handles it | You handle it |
|---|---|---|
| Request intake via widget | Yes | |
| Email verification | Yes | |
| Scanning connected databases | Yes | |
| Deletion and anonymization in connected databases | Yes (on your approval) | |
| Sending confirmation emails to requesters | Yes | |
| Request log and audit trail | Yes | |
| Data in email inboxes, spreadsheets, paper records | Yes | |
| Third-party tools (CRM, analytics, ad platforms) | Yes | |
| Unconnected databases | Yes | |
| Verifying a denial is legally valid before denying | Yes | |
| Checking tracking and analytics data manually | Yes |
Record keeping
Both GDPR and CCPA expect you to be able to demonstrate compliance if asked. That means keeping records of who submitted requests, when, what you did, and when you did it.
Comply's dashboard is your primary compliance log. Every request shows its full history: submission time, verification time, your response, and execution details. Do not delete old requests from your dashboard, even after they are completed or denied.
For deletions you performed manually (in systems Comply cannot reach), keep a brief note somewhere that you checked those systems for each request. A simple spreadsheet is fine. The goal is to be able to show a regulator that you took the request seriously and checked all your data sources.
Related: Business owner guide | Developer guide | All docs
This guide is for informational purposes. It is not legal advice. For advice specific to your business, consult a qualified attorney.