Privacy compliance is the one area of an organization where the policy is almost always excellent and the practice is almost always unknown. The privacy notice was written by lawyers and says the right things. The retention schedule is a well-formatted table. The records of processing were compiled in 2018 for the GDPR deadline and have been signed off annually since. What nobody has checked is whether the leaver files are actually deleted after six years, whether the thirty-eight people who asked for their data last year got it within the month the law allows, whether the plant CCTV system that watches the loading bay appears anywhere in the records, or whether the fourteen suppliers who receive employee data have signed the contract terms the regulation requires. Privacy auditing is the discipline of checking those things, and it produces findings in every organization that has never had them checked.
This guide is the method for auditing a privacy program, anchored on the GDPR because it is the most demanding and most copied of the privacy regimes and portable to the UK GDPR, California’s CPRA and the twenty US state laws in force in 2026. It sets out the legal landscape in one table, the nine components of a privacy program and the controls in each, the records-of-processing reconciliation that most programs fail, the data subject request test, the retention test that asks whether deletion actually happens, processor contracts and international transfers, consent, breach readiness, impact assessments, a twelve-test program, a portability map to the US state laws, and a worked example at Pennine Foods plc, a UK food manufacturer whose audit found twenty-seven processing activities missing from its records and leaver files kept eleven years against a six-year policy. It is written for internal auditors and compliance functions rather than privacy lawyers; the legal analysis of applicability is the privacy officer’s job, and the audit begins where that analysis ends.
In this guide
- The legal landscape in one table, and why applicability comes first
- The nine components of a privacy program
- Records of processing: the reconciliation most programs fail
- Data subject requests: the clock, the search and the log
- Retention: does deletion actually happen?
- Processors, contracts and international transfers
- Lawful basis, notices and consent mechanics
- Breach notification readiness and the 72-hour clock
- Impact assessments and privacy by design
- The twelve-test program
- Portability: the US state laws and the CPRA
- Worked example: Pennine Foods plc audits its privacy program
- Common mistakes
The legal landscape in one table, and why applicability comes first
Every privacy audit begins with an applicability analysis, performed by or with the privacy officer, that states which regimes apply to which processing and why. The GDPR applies to organizations established in the EU and to those outside it that offer goods or services to, or monitor, people in the EU; the UK GDPR mirrors it for the UK; the CPRA applies to businesses meeting California’s thresholds; the other US state laws have their own thresholds, most built on Virginia’s template, and most exempt data already covered by sector laws such as GLBA for financial institutions and HIPAA for health information. An audit that tests a US distributor against GDPR requirements, or a bank against a state law that exempts its customer data, wastes its hours and its credibility. The table gives the requirements the audit is most likely to test under the anchor regime, with the article references auditees and counsel expect, and the equivalents are mapped in the portability section later.
| Requirement | GDPR reference | What the audit tests |
|---|---|---|
| Principles: lawfulness, purpose limitation, data minimization, accuracy, storage limitation, integrity and confidentiality, accountability | Article 5 | Whether each processing activity can be shown to meet them; accountability means the organization must be able to demonstrate compliance, which is the basis of every test below |
| Lawful basis for processing | Article 6 (and Article 9 for special categories) | A basis recorded for every activity; consent valid where relied on; legitimate interests assessed where relied on |
| Transparency and notices | Articles 12 to 14 | Notices exist, are accurate against actual processing, and reach data subjects at collection |
| Data subject rights: access, rectification, erasure, restriction, portability, objection, automated decisions | Articles 15 to 22; Article 12(3) timing | Requests answered within one month, extendable by two months for complex cases with notice; identity verified; searches complete |
| Processor contracts | Article 28 | Written terms with the mandatory clauses for every processor; sub-processor controls |
| Records of processing activities | Article 30 | Complete, current, and reconciled to the systems that actually process data |
| Security of processing | Article 32 | Measures appropriate to the risk; overlaps with the cybersecurity program |
| Breach notification | Articles 33 and 34 | Supervisory authority within 72 hours of awareness unless unlikely to result in risk; data subjects without undue delay where high risk; internal breach register of all breaches |
| Data protection impact assessments | Article 35 | Performed before high-risk processing; register; consultation where residual risk is high |
| Data protection officer | Article 37 | Designated where required; independent; resourced |
| International transfers | Chapter V (Articles 44 to 49) | A valid mechanism for every transfer: adequacy decision (including the EU-US Data Privacy Framework of July 2023, upheld by the EU General Court in September 2025), standard contractual clauses with a transfer impact assessment, or another lawful route |
| Penalties | Article 83 | Up to 20 million euros or 4 percent of worldwide annual turnover for the higher tier, 10 million or 2 percent for the lower; the exposure the report is framed against |
The nine components of a privacy program
A privacy program that can demonstrate compliance, which is what the accountability principle requires, has nine components, and each produces evidence the audit can test. The table gives them with the controls and the evidence. ISO/IEC 27701 structures a privacy information management system along similar lines for organizations that want certification, and the NIST Privacy Framework offers a function-based alternative; neither is required, and the components below are the common denominator of the regimes and the frameworks.
| # | Component | Key controls | Evidence |
|---|---|---|---|
| 1 | Governance and accountability | Privacy officer or DPO with independence and access to the board; policies; training with completion tracking; privacy risk in the risk register; reporting | Appointment, reporting lines, policy set with review dates, training records, board papers |
| 2 | Records of processing and data mapping | Inventory of processing activities with purposes, categories, recipients, transfers, retention and security measures; data flow maps; reconciliation to systems | The records; reconciliation workpaper; flow diagrams |
| 3 | Lawful basis and purpose limitation | Basis recorded per activity; legitimate interests assessments; consent records; purpose compatibility checks for new uses | Basis register; assessments; consent logs |
| 4 | Transparency and consent mechanics | Notices accurate and delivered at collection; layered notices; consent capture granular, recorded and withdrawable; cookie and tracking consent | Notices versus records; consent platform records; website testing |
| 5 | Data subject rights handling | Intake channels; identity verification; search across all systems; response within the clock; log with dates and outcomes; exemptions applied with reasons | Request log; sample of responses; search procedure |
| 6 | Retention and deletion | Retention schedule tied to the records; deletion executed in systems, backups and archives; legal hold; disposal evidence | Schedule; system retention settings; deletion evidence; sample testing |
| 7 | Processors and transfers | Processor inventory; Article 28 terms for each; sub-processor lists; transfer mechanism per recipient; transfer impact assessments; due diligence | Contract register; DPAs; transfer register; assessments |
| 8 | Security and breach management | Security measures appropriate to risk; breach identification, assessment, register and notification within the clocks; integration with incident response | Breach register; incident records; notification records; the incident response audit |
| 9 | Impact assessments and privacy by design | Screening for high-risk processing; DPIAs before go-live; register; privacy requirements in projects and procurement | DPIA register and documents; project gate evidence |
Records of processing: the reconciliation most programs fail
The records of processing activities are the privacy program’s inventory, and everything else depends on them: a processing activity that is not in the records has no recorded lawful basis, no retention period, no notice, no processor contract and no impact assessment, because nobody knew to ask. The records are also the document most often compiled once and maintained by signature. The audit tests completeness by reconciliation, in the same way the IT audit plan reconciles the technology universe: take every source that reveals processing of personal data and compare it with the records. The application inventory, filtered for systems holding personal data. The HR, payroll, benefits and recruitment systems. The marketing and customer platforms. The vendor master and contracts register, filtered for suppliers who receive personal data. The physical estate: CCTV, access control, vehicle telematics, visitor systems. The websites and mobile applications, with their trackers. Projects in flight. Each activity found in a source and absent from the records is an unrecorded activity, and the count of them is the first finding. The table gives the sources and the activities that typically hide in each.
| Source | Activities typically missing from the records |
|---|---|
| Application inventory with data classification | Reporting databases and data warehouses holding copies; legacy systems; departmental tools |
| HR, payroll and recruitment systems | Candidate data retained after hiring decisions; background checks; occupational health; employee monitoring |
| Marketing and sales platforms | Purchased lists; event data; promotions microsites; analytics and tracking |
| Vendor master and contracts | Every supplier receiving personal data who is not listed as a processor |
| Physical security and operations | CCTV, access badges, visitor logs, vehicle and driver telematics, plant safety systems |
| Web and mobile | Cookies and trackers, chatbots, account systems, third-party embeds |
| Project portfolio | New systems and analytics initiatives, including AI deployments, that started processing before anyone recorded them |
| Shared drives and email | Spreadsheets of personal data outside any system; the unmanaged tail |
Data subject requests: the clock, the search and the log
Data subject requests are where the privacy program meets the public, and they are the component regulators hear about first, because a person whose request was ignored complains. The GDPR allows one month from receipt, extendable by a further two months for complex or numerous requests provided the person is told within the first month; the US state laws mostly allow forty-five days with a forty-five-day extension. The audit tests five things across the population of requests in the period, which should be complete from the log and is checked against the intake channels, the privacy mailbox, the web form, the call center notes and the complaints the regulator has forwarded. Timeliness: receipt date to response date for every request, with the distribution and the late ones. Identity verification: proportionate, recorded, and not used as an obstacle. Completeness of the search: which systems were searched for each request against the systems the records say hold that category of person’s data; a subject access response built from the CRM alone when HR, email and the telematics platform also hold the person’s data is incomplete, and the audit finds this by comparing the search list with the records. Exemptions and redactions: applied with a recorded reason. And the log itself: every request, its type, dates, outcome and handler. The metrics reported are volume by type, median and maximum response time, proportion late, and proportion where the search covered all relevant systems.
Retention: does deletion actually happen?
The test that separates policy from practice
Storage limitation is the principle organizations most often breach without knowing it, because a retention schedule is a document and deletion is an action that has to be configured, executed and evidenced in each system, its backups and its archives. The audit test is direct: for a sample of categories with a stated retention period, select records that are past it and check whether they still exist. Leaver personnel files after the schedule’s six years; unsuccessful candidates’ applications after six months; customer accounts closed a decade ago; call recordings; CCTV footage past its thirty days; email of departed employees. The check is performed in the system, in the backup catalog and in any archive, because a record deleted from the live system and retained in a backup for seven years has not been deleted for the regulation’s purposes without a documented justification. Where retention is automated, the test inspects the configuration and its change history as for any automated control; where it is manual, the test looks for the evidence of the last disposal run and usually finds none. Legal holds are the legitimate exception and need their own register, so that a hold applied for a case closed in 2021 is not the reason nothing has ever been deleted. The table sets out the comparison the audit produces.
| Category | Schedule says | System setting | Oldest record found | Backup and archive | Result |
|---|---|---|---|---|---|
| Leaver personnel files | 6 years after leaving | No automated deletion | 11 years | Retained indefinitely | Not executed |
| Unsuccessful candidate data | 6 months | Recruitment platform set to 24 months | 4 years (exports on a shared drive) | Not applicable | Setting wrong; exports uncontrolled |
| CCTV footage | 30 days | Overwrite at 30 days on 9 of 12 recorders | 7 months on 3 recorders | None | Partial |
| Customer accounts (closed) | 7 years after closure | No deletion routine | Since system implementation | Retained | Not executed |
| Employee email after departure | 12 months | Mailboxes converted to shared, never removed | 9 years | Retained | Not executed |
Processors, contracts and international transfers
Every supplier that processes personal data on the organization’s behalf is a processor, and Article 28 requires a written contract with specific terms: processing only on documented instructions, confidentiality, security measures, sub-processor controls, assistance with rights and breaches, deletion or return at the end, and audit rights. The audit builds the processor population from the vendor master and the records rather than from the privacy team’s list, and tests each for a contract with the mandatory terms, usually a data processing agreement, for the sub-processor list and the notification of changes, for due diligence proportionate to the data, which is where the SOC 2 review and the Third-Party Topical Requirement come in, and for the end-of-contract deletion evidence. Transfers add a second layer: for every recipient outside the EU or UK, a lawful mechanism recorded in a transfer register, an adequacy decision, certification under the EU-US Data Privacy Framework checked on the official list, standard contractual clauses in the 2021 form with a transfer impact assessment, or another route, with the mechanism’s currency checked against the legal developments the privacy officer tracks. Cloud providers, SaaS tools and group companies in other countries are transfers most organizations forget, and support access from an offshore engineer is a transfer too.
Lawful basis, notices and consent mechanics
Consent is one of six lawful bases and the one most often relied on wrongly, because it is the one people have heard of. Where an organization relies on consent it must be freely given, specific, informed and unambiguous, recorded with what was consented to and when, and as easy to withdraw as to give; where it relies on legitimate interests it must have performed and recorded the balancing assessment; where it relies on contract or legal obligation the basis should be identifiable from the activity. The audit tests the basis register against the records, samples consent records from the platforms that capture them for the required attributes, tests withdrawal end to end by submitting one, and compares the privacy notices with the records to find processing the notice does not mention, which is the commonest transparency finding. Cookie and tracking consent on websites and applications is tested by inspection: what fires before consent, whether rejection is as easy as acceptance, and whether the consent platform’s records match the trackers actually present. Employee monitoring, telematics, CCTV and any AI-assisted decision about people are tested for the specific notice and basis each requires, because each is where an organization’s actual processing has run ahead of its notices.
Breach notification readiness and the 72-hour clock
The 72-hour clock starts when the organization becomes aware of a personal data breach, and it can only be met if incidents involving personal data reach the privacy officer as a matter of routine, which is a design question for the incident response process covered in the incident response audit. The privacy audit tests four things on top of that: the breach register, which must record every personal data breach whether or not it was notified, with the facts, effects and remedial action; the assessment of each entry against the risk threshold for notification, with the reasoning; the notifications made, their timing against the clock and their content; and the communications to data subjects where the risk was high. The register is reconciled to the incident list and to the help-desk tickets mentioning lost devices, misdirected emails and similar events, because a misdirected email containing a spreadsheet of employees is a personal data breach that IT will not classify as a security incident. Organizations under several regimes need a clock inventory: the GDPR’s 72 hours, the state laws’ 30 to 60 days, sector rules, and contractual commitments to customers, which the incident response guide’s clock table covers.
Impact assessments and privacy by design
A data protection impact assessment is required before processing likely to result in a high risk to individuals, systematic monitoring, large-scale processing of special categories, new technologies applied to people, profiling with significant effects, and the supervisory authorities’ published lists add specifics such as employee monitoring and biometric systems. The program needs a screening step at project initiation that asks the questions, a DPIA where screening says so, a register, and consultation with the authority where residual risk remains high. The audit tests the screening by taking the project portfolio and the unrecorded activities found in the records reconciliation and asking which should have been screened; it tests the DPIAs performed for their content, the description of processing, the necessity and proportionality analysis, the risks to individuals and the measures; and it tests whether the measures were implemented, which is the step most often missed. Privacy by design is the broader control that the screening operates inside: privacy requirements in the project methodology, in procurement templates and in the change process, so that the telematics platform, the CCTV upgrade and the analytics initiative reach the privacy officer before go-live rather than in the audit.
The twelve-test program
The program covers the nine components for a twelve-month period. Populations are the records, the request log, the processor list, the breach register and the project portfolio, each reconciled before it is used; samples follow the usual sizes and the sampling memo discipline. The privacy officer is both the main auditee and, usually, the audit’s best ally, because the findings are the evidence they need for resources.
| # | Test | Population | Evidence | What a failure looks like |
|---|---|---|---|---|
| 1 | Confirm the applicability analysis and governance: regimes, DPO designation, policies, training, board reporting | Program documentation | Applicability memo; appointment; policy set; training completion; board papers | No analysis; DPO without independence; training at 40 percent |
| 2 | Reconcile the records of processing to every source | All sources in the table above | Reconciliation with each unrecorded activity listed | Activities missing; records not updated since implementation |
| 3 | Test lawful basis and legitimate interests assessments | All activities; sample of 25 for assessment quality | Basis register; assessments; consent records where relied on | No basis recorded; consent relied on for employment processing |
| 4 | Compare notices with actual processing | All notices; records | Line-by-line comparison | Processing not disclosed; recipients and transfers omitted |
| 5 | Test data subject requests | All requests in the period, reconciled to intake channels | Log; dates; search lists; responses; exemptions | Late responses; searches limited to one system; unanswered requests |
| 6 | Test retention execution | Sample of categories; records past retention in each | System, backup and archive checks; disposal evidence; legal hold register | Records years past schedule; no deletion ever executed |
| 7 | Test processor contracts and due diligence | All processors from the vendor master and records | DPAs with mandatory terms; sub-processor lists; due diligence records; end-of-contract deletion | Processors without terms; sub-processors unknown |
| 8 | Test international transfers | All recipients outside the EU or UK | Transfer register; mechanism evidence; framework certification checks; impact assessments | Transfers with no mechanism; expired or wrong-form clauses |
| 9 | Test consent capture and withdrawal, including web tracking | Consent platforms; websites and apps | Consent records; withdrawal test; tracker inspection before consent | Trackers firing before consent; withdrawal harder than consent |
| 10 | Test breach management | Breach register reconciled to incidents and help-desk tickets | Register; assessments; notifications with timing | Breaches unrecorded; 72 hours missed; misdirected emails unassessed |
| 11 | Test impact assessments and privacy by design | Project portfolio; unrecorded activities; DPIA register | Screening records; DPIAs; implementation of measures; project gate evidence | High-risk processing without a DPIA; measures never implemented |
| 12 | Test security of processing for the highest-risk activities | Activities involving special categories or large scale | Access controls, encryption, logging for the systems involved; link to ITGC and cyber work | Special-category data on open shares; no access logging |
Portability: the US state laws and the CPRA
By 2026 twenty US states have comprehensive consumer privacy laws in force, counting Florida’s narrower statute, with Indiana, Kentucky and Rhode Island taking effect on 1 January 2026, most of them built on Virginia’s template and California’s CPRA the outlier with its own agency and rulemaking. The components above port directly; what changes is the vocabulary, the thresholds, the rights and the clocks. The table maps the GDPR-anchored components to their US equivalents, so that a program built to the anchor can be audited against the state laws with the same tests and different criteria. Two US-specific controls have no GDPR equivalent and need their own tests: honoring universal opt-out signals such as the Global Privacy Control in the states that require it, and the data broker registration and deletion mechanisms California has added.
| Component | GDPR | CPRA and the state laws (typical) | Audit adjustment |
|---|---|---|---|
| Applicability | Establishment or targeting of people in the EU | Revenue, consumer-count or data-sale thresholds; GLBA and HIPAA data exempt; employee data exempt outside California | Threshold analysis per state; exemptions mapped |
| Lawful basis | Six bases; consent strict | No general basis requirement; opt-in consent for sensitive data in most states; opt-out for sale, sharing and targeted advertising | Test opt-out mechanisms and sensitive-data consent instead of a basis register |
| Rights and clocks | One month, extendable by two | Typically 45 days, extendable by 45; rights to access, delete, correct, portability, opt out; appeal process in many states | Same request test with the state clock; test the appeal channel |
| Records and assessments | Article 30 records; DPIAs | Data protection assessments for targeted advertising, sale, profiling and sensitive data; California risk assessments and cybersecurity audits under CPPA rules | Assessment register keyed to the triggering activities |
| Processors | Article 28 contracts | Processor or service provider contracts with specified terms; California’s service provider and contractor definitions | Same contract test with the state’s mandatory terms |
| Notices | Articles 12 to 14 | Privacy notice at collection; “Do Not Sell or Share” links; notice of financial incentives | Website inspection for the required links and signal handling |
| Breach | 72 hours to the authority | State breach notification laws with 30 to 60 day clocks and attorney general thresholds; separate from the privacy statutes | Clock inventory by state of residence of affected individuals |
Worked example: Pennine Foods plc audits its privacy program
Pennine Foods plc is a 900-million-pound UK food manufacturer with plants, a distribution fleet and a consumer promotions business, subject to the UK GDPR under the supervision of the Information Commissioner’s Office. Its privacy program had been built for the 2018 deadline by a project team and handed to a data protection officer who also ran compliance; the records of processing held 61 activities and had been signed off each year. The internal audit function’s FY26 plan included a 240-hour privacy program audit, performed by two auditors with the DPO as the main contact and the HR, marketing and fleet directors as auditees in their own right.
The reconciliation found 88 processing activities against the 61 recorded. The 27 missing included the plant CCTV systems at all three sites, the driver telematics platform installed in 2023 that recorded location, speed and camera footage for 340 drivers, a consumer promotions microsite run by an agency, the occupational health provider, three recruitment tools, and the analytics warehouse that copied customer and employee data nightly. None of the 27 had a recorded lawful basis, a retention period or a processor contract, and the telematics platform, which met the criteria for an impact assessment on any reading, had never had one; the fleet director had understood it as a safety system. The request log held 38 data subject requests, of which 9 had been answered after the one-month limit, 3 had never been answered, and 22 had been answered from the HR system alone when the records showed the person’s data in at least four systems. The retention test produced the table shown earlier: leaver files kept eleven years against six, candidate data exported to shared drives and kept four years, CCTV overwriting correctly at nine of twelve recorders, departed employees’ mailboxes retained for nine years. Of 40 processors identified from the vendor master, 14 had no Article 28 terms, including the occupational health provider and the promotions agency, and 6 recipients outside the UK had no transfer mechanism recorded, among them a support team in India for the telematics platform. The breach register held six entries; the incident list and help-desk tickets produced eleven candidate events, five of them misdirected emails containing employee data that had never been assessed against the 72-hour clock.
| Component | Result | Finding and rating |
|---|---|---|
| Records of processing | 61 recorded; 88 found; 27 unrecorded including CCTV, telematics, promotions microsite, occupational health, recruitment tools, analytics warehouse | Records completeness (High) |
| Lawful basis and notices | No basis for the 27; employee notice silent on telematics and CCTV; consumer notice silent on the agency | Basis and transparency (High, combined with records) |
| Data subject requests | 38 requests; 9 late, 3 unanswered; 22 searched in one system only | Rights handling (High) |
| Retention | Deletion never executed for leaver files, closed accounts, mailboxes; candidate data on shared drives | Retention execution (High) |
| Processors and transfers | 14 of 40 without Article 28 terms; 6 transfers without a mechanism | Processor governance (Medium) |
| Breach management | 6 registered; 11 candidate events; 5 misdirected emails unassessed | Breach register and intake (Medium) |
| Impact assessments | None for telematics or CCTV; screening absent from the project method | DPIA and privacy by design (Medium) |
| Governance | DPO combined with compliance and under-resourced; training 58 percent complete; no board reporting | Governance (Medium) |
The report was organized by component with one root cause: the program had been a project with an end date rather than an operation with an owner, and nothing had connected new processing, new suppliers or new requests to it since 2018. The recommendations were an owned records process wired into procurement and project gates, a request procedure with a cross-system search list derived from the records, a retention execution program starting with the four categories tested, contract remediation for the 14 processors and mechanisms for the 6 transfers, a breach intake from the help desk, DPIAs for telematics and CCTV, and a resourced DPO reporting to the audit committee twice a year. The audit committee asked for the telematics DPIA before the next meeting and for the request metrics quarterly; the DPO used the report to obtain a second privacy analyst, which was the outcome the audit had been designed to produce.
Common mistakes
- Auditing the policy set. Notices, schedules and records are documents; the audit tests execution against each of them.
- Skipping the applicability analysis. Testing the wrong regime wastes the audit and misleads the committee.
- Accepting the records as complete. Reconcile to applications, HR, marketing, vendors, physical systems, web and projects.
- Sampling requests from the log. Reconcile the log to the intake channels first; the unanswered requests are not in the log.
- Testing retention by reading the schedule. Go and find records past their date, in the system, the backups and the archives.
- Building the processor list from the privacy team’s list. Start from the vendor master.
- Forgetting transfers inside the group and inside support arrangements. Offshore support access is a transfer.
- Treating breaches as security incidents only. Misdirected emails and lost devices are personal data breaches; reconcile the register to the help desk.
- Relying on consent everywhere. Test that the basis fits the activity, especially for employees.
- Writing findings against the DPO. The root cause is usually resourcing and integration; write the recommendation to the people who can fix that.
Related guides
- How to audit incident response
- How to review a SOC 2 report
- The Third-Party Topical Requirement
- Auditing cybersecurity programs
- How to audit identity and access management
- Testing automated controls and system configurations
- Building the IT audit plan
- Internal audit vs. compliance
- Audit sample sizes: 25, 40, 60
- Root cause analysis for audit findings
- UK SOX and Provision 29
- Regulation & Compliance guides
Leave a Reply