What privacy reviews ask for: consent, notices and requests

A customer’s security questionnaire or a partner’s due diligence team rarely stops at your privacy policy, because they want the records behind it. A policy says you ask permission. A consent table shows that you did.

Reviews under GDPR, UK GDPR and CCPA differ in vocabulary and in what counts as a valid basis, yet the system questions look alike. Where is the record? Who can change it? How would you find every record for one person across the invoice archive, the support desk, the mailing list export and last year’s trade show spreadsheet?

This article describes the technical records only. Your legal adviser decides what is enough.

One checkbox column is not a record. A reviewer expects a row for each choice holding the person’s ID, purpose, timestamp and source, whether web form, mobile app, paper sign-up or trade show import.

Wording matters. Store the language shown and the version of the text, so a French sign-up can be traced to the French notice of that week. Store withdrawals as new rows, not overwrites. The history is the evidence.

Imported lists are the usual weak spot. A spreadsheet of contacts from a past event carries no source, no date and no wording, so a reviewer cannot tell what those people agreed to receive. Expect the question.

Privacy notices change whenever someone adds an analytics tool, a new processor or a new country, and reviewers then ask for the notice in force on a given date. They want the change list too.

Keep each version as a dated, read-only file with a short change note, and link it to the form or screen that displayed it. Without that link, you cannot say which text a customer accepted when they ticked the box on the old checkout page during a past campaign. That is the gap.

Cookie banners follow the same rule. Log the categories offered, the choice made, the banner version and the consent string or cookie value the browser stored on that visit. Screenshots alone do not count.

Expect a request register. Each entry holds the date received, the person’s identity check, the type of request, the systems searched, the date closed and the outcome. A reviewer may pick three entries at random and ask you to walk the full trail from the first email to the closing letter.

The hard part is the search. Personal data sits in the main database, but also in invoices, support tickets, email exports, backups and spreadsheets on a salesperson’s laptop. A system that cannot list every place one person appears will miss records, which turns a closed request into an open finding.

Erasure needs a rule for what stays. Tax invoices may have to be kept. Record the reason for each exception, such as a tax invoice or an open dispute, and let your adviser confirm that the reason holds in your case.

Retention comes next. A table lists data type, purpose, period and the scheduled job or named person that removes each record when the period ends. A rule nobody runs is worse than no rule at all, because it exposes the gap between the written policy and what the servers actually do.

The audit log answers a different question, namely who looked at or changed this record and when, across admin screens, exports and API calls. Store it apart from the data it describes, with write access closed to editors, so nobody can erase their own trail after a bulk export or a bad edit.

Before the review, pick one real person. Trace that person from the sign-up form through billing, support, backups and the audit log, fix whatever you cannot find, and write the steps down as a repeatable test.