For a DevOps lead, CCPA compliance is mostly a question of where personal data sits outside the product database: logs, backups, queues, staging copies and vendor tools. If those places are not mapped and bounded by retention, a delete or opt-out request cannot be completed reliably.
Which parts of CCPA land on infrastructure?
The California Attorney General's summary lists the consumer rights: know, delete, correct, opt out of sale or sharing (including through the Global Privacy Control), limit use of sensitive personal information, and not be discriminated against for exercising them. Application teams own the request forms. Infrastructure teams own everything those requests touch.
Whether your company is a covered business is a legal question, so confirm it with counsel. The operational work below is sensible either way.
Where does personal data hide?
Walk one real request through the stack and list what you find. Common places:
- Application logs that record emails, IPs or full request bodies.
- Error trackers that capture user context.
- Message queues and dead-letter queues holding events with user fields.
- Staging and test databases cloned from production.
- Object storage buckets with exports and uploads.
- Backups and snapshots.
- Observability and support tools with copy-pasted customer data.
A constructed example: a payments service logs the whole request on a 500 error. Those logs ship to a hosted search tool with a one year retention. A deletion request cleans the database, but the person's email stays searchable for months.
How should retention be set?
Pick the shortest retention each store can live with, and enforce it in configuration, not in a wiki page. Debug logs rarely need to hold personal data at all. Scrub or hash identifiers at the logger, before data leaves the process. Sampling, field allow-lists and a log schema review in pull requests do more than a cleanup job.
For backups, decide whether deleted records are allowed to age out on the normal cycle, and make restores replay a deletion list so a recovery does not resurrect erased data. Write that rule down so the team and counsel read the same policy.
How do you make a delete repeatable?
Treat a delete as a job with a request ID. The job calls each store and each processor in order, records success or failure, and retries. Idempotency matters: running it twice must be safe. Alert on jobs that stay open. Keep the log of what was deleted and when, without keeping the personal data you just removed.
How do opt-outs reach tags and exports?
The opt-out of sale or sharing, including the Global Privacy Control signal, needs a single source of truth that the web tier, tag manager and batch exports all read. On the server side, make the data export job check that flag before sending a row to an ad or analytics partner. Test with a browser that sends the signal and confirm which network calls still fire.
What to do
- Pick one real user and trace every place their data appears.
- Remove personal data from logs at the logger, and set a retention period per store.
- Stop cloning production personal data into staging, or mask it during the copy.
- Build the delete job with a request ID, retries and a completion log.
- Define the backup rule and make restores replay pending deletions.
- Make exports and tags read the opt-out flag, and test it with the Global Privacy Control signal.
- Add a quarterly drill with a synthetic person.
Quick check
Do logs count as personal information stores?
If they contain identifiers such as emails or IP addresses tied to a person, they hold personal information and belong in your data map and deletion scope. Ask counsel how the law applies to your case.
How can we test an opt-out signal?
Use a browser that sends the Global Privacy Control signal, load your site, and inspect network calls. Any call to an advertising or analytics partner that should be off is a gap.
Sources
Last reviewed: 18 October 2026.
