A GDPR compliance audit is the mechanism through which an organisation’s accountability claims are tested against reality. Privacy notices can be published; RoPAs can be drafted; DPAs can be signed — but without periodic verification that these documents accurately reflect actual processing activities and that the controls they describe are genuinely operational, the compliance programme is a paper exercise that will fail at the first real test.
GDPR does not mandate internal audits explicitly, but the accountability principle (Article 5(2)) effectively requires them. An organisation that cannot demonstrate through periodic review that its compliance records are accurate and its controls are effective cannot credibly claim to be accountable. DPAs increasingly expect to see evidence of compliance verification as part of the accountability portfolio they assess during investigations.
Types of GDPR Audit
GDPR AUDIT TYPES — PURPOSE AND SCOPE
| Audit Type | Purpose | Who Conducts It | Typical Frequency |
|---|---|---|---|
| Internal compliance audit | Assess the organisation’s own GDPR programme against all obligations; identify gaps; generate remediation plan | DPO, internal privacy team, or internal audit function with privacy expertise | Annually; triggered by material processing changes |
| Third-party / external audit | Independent assessment of compliance programme; higher credibility with regulators and enterprise clients; may produce publishable report | External privacy consultants; specialised GDPR audit firms; Big Four advisory practices | Every 2–3 years; on significant programme changes; pre-certification |
| Processor audit (Art. 28 right) | Exercise the controller’s contractual right to audit processors; verify processor’s compliance with DPA obligations; assess sub-processor chain | Controller’s privacy team; external auditors acting for controller; standardised questionnaire in first instance | At least annually via questionnaire; on-site as needed for high-risk processors |
| Incident-triggered review | Post-breach or post-complaint review to identify root cause and assess compliance of affected processing | DPO plus relevant technical and operational team; may engage external support | Triggered by material incident; breach; DPA investigation |
| DPIA review | Periodic reassessment of high-risk processing under Art. 35; verify that risk mitigation measures remain in place and effective | Privacy team; DPO; may include IT, Legal, business team for the relevant processing | At least every 3 years; when processing changes materially; when supervisory authority guidance changes |
Audit Scope and Planning
An effective GDPR audit begins with a defined scope that specifies which processing activities, organisational units, and compliance obligations are being assessed. Attempting to audit every aspect of GDPR compliance in a single exercise is rarely productive — a risk-based approach that prioritises the highest-risk processing activities and the compliance areas most likely to have drifted from documented standards produces more actionable findings.
RISK-BASED AUDIT SCOPE PRIORITISATION
| Priority Area | Why High Priority | Audit Focus |
|---|---|---|
| Special category data processing | Higher fine tier; consent or Art. 9(2) basis required; stricter security obligations | Lawful basis for each Art. 9 processing activity; access controls; retention; DPIA completion |
| Consent-based processing (marketing, advertising, cookies) | Most frequently litigated compliance area; consent validity is strictly tested; dark patterns enforcement increasing | Consent mechanism design; consent records; granularity; withdrawal mechanism; CMP audit |
| International data transfers | Post-Schrems II; EU-US transfers under DPF risk; SCC version compliance | Transfer register; SCC version used; TIA completion; DPF certification verification for US transfers |
| Processor relationships | Art. 28 DPA requirements; sub-processor management; security guarantees | Processor register completeness; DPA execution; sub-processor lists; annual processor review records |
| Data subject rights fulfilment | Most direct trigger for DPA complaints; deadline breaches are visible and evidenced | SAR log; response times; exemption decision records; channel coverage |
| Breach detection and notification | 72-hour deadline; breach register maintenance; non-notified breach documentation | Breach register; notification timeliness; risk assessment quality; post-incident review records |
Audit Methodology: The Four-Stage Process
GDPR AUDIT — FOUR-STAGE METHODOLOGY
| Stage | Activity | Output |
|---|---|---|
| 1. Planning | Define scope and risk prioritisation; identify audit criteria (GDPR articles, EDPB guidelines, internal policies); identify evidence sources; prepare audit programme and interview schedule; notify relevant teams | Audit programme document; scope statement; evidence request list; interview schedule |
| 2. Evidence collection | Document review (RoPA, DPAs, LIAs, DPIAs, breach register, training records, privacy notices, consent records); system testing (data mapping tool review, consent platform audit, SAR tracking system); staff interviews (privacy team, IT, HR, Marketing, Legal) | Evidence file; annotated document review notes; interview records; system testing results |
| 3. Analysis and gap assessment | Compare evidence against audit criteria; identify gaps (control absent; control exists but not documented; control documented but not operational; control operational but not evidenced); assess severity of each gap | Gap register with severity ratings; root cause assessment for significant gaps; draft findings |
| 4. Reporting and remediation planning | Draft audit report with findings, evidence, recommendations, and risk ratings; management response; agree remediation actions and owners; set timelines; schedule follow-up verification | Audit report; management action plan; remediation tracker; follow-up audit date |
Evidence Collection: What to Review
GDPR AUDIT — EVIDENCE COLLECTION FRAMEWORK
| Compliance Area | Documents to Review | Systems/Processes to Test |
|---|---|---|
| RoPA and data mapping | Current RoPA; previous versions; change log; data flow diagrams | Compare RoPA to actual systems inventory; identify systems not in RoPA; check retention periods are implemented |
| Lawful basis | LIA records; consent records; contract necessity assessments; DPO advice on basis selection | Test consent records against collection mechanism; verify LIA predates processing; check basis is correctly documented in RoPA |
| Privacy notices | Current notices; version history; update log; notices at each collection point | Accessibility from all pages; mobile readability; consent notice text against consent mechanism |
| Data subject rights | SAR and rights request log; response letters; exemption decisions; acknowledgement templates | Response time analysis against 30-day deadline; check all channels covered; verify exemption reasoning quality |
| Processors | Processor register; executed DPAs; vendor assessment records; sub-processor lists | Compare processor register to actual vendor list; check DPA execution dates; identify new vendors without DPAs |
| Transfers | Transfer register; executed SCCs (check version); TIA records; DPF verification for US entities | Map processors to countries; identify non-EEA transfers without transfer register entry; check SCC version (2021 required) |
| Security | TOMs schedule; security policy; penetration test reports; access review records; incident response procedure | Verify pen test was conducted within 12 months; check access review completion; confirm encryption standards |
| Breaches | Breach register; DPA notification records; individual notification records | Calculate notification timeliness for notified breaches; review risk assessment quality for non-notified breaches |
| Training | Training completion records; training content; role-based training matrix | Verify all data-handling staff trained; confirm training refreshed within required period; check training content covers relevant obligations |
Gap Assessment and Reporting
The gap assessment is the analytical core of the audit — the stage where evidence is compared against what the compliance programme claims. Gaps fall into four categories that differ in both severity and remediation approach. The audit report should classify each gap by type and recommend remediation proportionate to the risk it represents.
GAP CLASSIFICATION FRAMEWORK
| Gap Type | Description | Risk Level | Remediation Approach |
|---|---|---|---|
| Control absent | A required control does not exist; no policy, procedure, or technical measure in place | High | Immediate implementation required; may require DPA notification if gap created unlawful processing |
| Control exists, not documented | A control is operational but there is no documentation of it; cannot demonstrate compliance to DPA | Medium-High | Document the control; verify it is operating consistently; update RoPA/accountability record |
| Control documented, not operational | Documented policy or procedure exists but is not being followed in practice; most dangerous gap type | High | Investigate cause; re-train or re-enforce; update procedure to reflect what is actually done; verify compliance |
| Control operational, not evidenced | Control is in place and operating but no evidence is retained to demonstrate compliance | Medium | Implement evidence retention for the control; update accountability record |
| BITLION INSIGHT | The most dangerous gap type — consistently — is ‘control documented, not operational.’ An organisation that has a privacy notice on its website that does not match its actual processing, or a DPIA procedure that is never actually followed, or an SAR deadline in its procedure that its team routinely misses, is in a worse position than one with no documentation at all. The reason is simple: the documentation creates an expectation it cannot meet. When a DPA investigates and compares the documented procedure to the actual practice, the gap is directly evidenced — by the organisation’s own records. |