Why a GDPR audit matters even if nothing has gone wrong
The GDPR has been enforced since May 2018 — but most SaaS companies approach compliance reactively: fix something when a customer asks, update the privacy policy when you remember, respond to a DSR when it arrives. The problem is that the largest GDPR fines don't typically happen because something catastrophic occurred. They happen because organisations couldn't demonstrate they had a legitimate basis for processing, couldn't respond to access requests properly, or had no records to show supervisory authorities what they were doing and why.
A GDPR compliance audit is how you find out where those gaps are before a supervisory authority investigation, a data breach, or an enterprise customer's due diligence request exposes them.
GDPR audit scope: what you're checking
A full GDPR compliance audit covers nine areas:
- Lawful basis and purpose — Art. 5, 6, 9
- Transparency and privacy notices — Art. 12-14
- Data subject rights processes — Art. 15-22
- Records of processing activities — Art. 30
- Processor and sub-processor management — Art. 28
- Security and data protection — Art. 32, 25
- Breach notification — Art. 33-34
- Data Protection Impact Assessments — Art. 35-36
- International data transfers — Art. 44-49
- Accountability and governance — Art. 5(2), 24, 37-39
1. Lawful basis and purpose (Art. 5-6, 9)
The most common GDPR enforcement finding is relying on consent for everything — then failing to manage consent properly. Or not documenting any lawful basis at all.
What auditors check
- Is there a documented lawful basis for every processing activity in the RoPA?
- Is the basis actually valid — not just claimed?
- Is purpose limitation being respected — data not used for incompatible purposes?
- For special category data (Art. 9): is there an Art. 9(2) condition documented, not just an Art. 6 basis?
Common failures
| Failure | Why it matters | Fix |
|---|---|---|
| Consent used as lawful basis for employee data | Consent isn't freely given when there's an employment relationship — use Art. 6(1)(c) legal obligation or (b) contract | Switch to correct basis and document it |
| No LIA conducted when relying on legitimate interests | Art. 6(1)(f) requires a 3-part test to be documented — cannot just claim LI without analysis | Conduct and document LIA for each LI basis |
| Health data processed without Art. 9(2) condition | Special category data requires both Art. 6 and Art. 9 basis — one is not sufficient | Identify applicable Art. 9(2) condition; document in RoPA |
| Consent not specific or unbundled | Bundled consent ("agree to everything") is not valid consent — must be granular per purpose | Rebuild consent flows with per-purpose toggles |
2. Privacy notices (Art. 12-14)
Art. 13 requires providing a privacy notice at the time personal data is collected from the data subject. The mandatory elements include:
- Controller identity and contact details
- DPO contact (if applicable)
- Purposes and lawful basis for each processing activity
- Legitimate interests pursued (if Art. 6(1)(f) is the basis)
- Recipients or categories of recipients
- International transfers and the safeguards used
- Retention period or criteria for determining it
- All data subject rights (Art. 15-22)
- Right to withdraw consent
- Right to lodge a complaint with a supervisory authority
- Whether provision of data is a statutory/contractual requirement
- Whether automated decision-making (Art. 22) is involved
What trips companies up: the notice is too vague ("we share data with trusted partners"), doesn't list specific sub-processors or recipients, and doesn't give retention periods per data type — just "we keep it as long as necessary."
3. Data subject rights (Art. 15-22)
GDPR gives data subjects eight rights. Most SaaS companies have a privacy policy that mentions them but no operational process to actually fulfil them within the 1-month deadline.
| Right | Article | Deadline | Most common failure |
|---|---|---|---|
| Access (SAR) | Art. 15 | 1 month | Can't produce complete data from all systems — only from main DB |
| Rectification | Art. 16 | 1 month | No process to update data in third-party integrations |
| Erasure | Art. 17 | "Without undue delay" | Doesn't delete from backups within defined timeframe; no sub-processor deletion |
| Restriction | Art. 18 | "Without undue delay" | No technical capability to flag records as restricted while dispute resolved |
| Portability | Art. 20 | 1 month | Only applies where processing based on consent or contract + automated means — misapplied |
| Object (direct marketing) | Art. 21(2-3) | Immediately — no conditions | Opt-out takes 24-48h to process; still sends one more email |
| Automated decision-making | Art. 22 | On request | Company doesn't realise Art. 22 applies to their AI; no human review mechanism |
The direct marketing opt-out is unconditional. Art. 21(3) says that once an objection to direct marketing is received, personal data must no longer be used for that purpose. There is no "manifestly unfounded" exception for this right, unlike most others. Organisations that delay actioning opt-outs by days — or that continue sending after opt-out — are in clear violation.
4. Records of Processing Activities (Art. 30)
The RoPA is often the first thing supervisory authorities request in an investigation. If it doesn't exist or is incomplete, it signals broader non-compliance.
A compliant RoPA entry includes:
- Name and contact details of controller (and DPO if applicable)
- Purpose of processing
- Categories of data subjects
- Categories of personal data
- Categories of recipients (including sub-processors)
- International transfers — country and safeguard mechanism
- Retention periods
- General description of technical and organisational security measures
The Art. 30(5) exception for organisations with fewer than 250 employees is narrower than often assumed. It only applies if processing is not occasional, not likely to result in a risk, and does not include special category data or criminal data. Most SaaS companies process customer data on an ongoing basis — which means the exception doesn't apply.
5. Processor agreements (Art. 28)
Every tool that processes personal data on your behalf is a processor. This includes: AWS, GCP, Azure, Stripe, HubSpot, Intercom, Mixpanel, SendGrid, Zendesk, Notion, Slack, GitHub, Google Analytics, Sentry, and hundreds of others. Every one requires a DPA.
The DPA must include the 8 elements of Art. 28(3):
- (a) Only process on documented instructions
- (b) Confidentiality obligations for persons authorised to process
- (c) Implement Art. 32 security measures
- (d) Sub-processor obligations flow down
- (e) Assist with data subject rights
- (f) Assist with breach notification
- (g) Delete or return data at end of service
- (h) Audit rights — provide all information necessary
Most major SaaS providers make their DPAs available online. AWS, Google Cloud, Microsoft Azure, Stripe, HubSpot, and most others have pre-signed DPAs you accept as part of their ToS or via a data processing addendum. The failure is usually not signing them at all, or not keeping a record that you did.
6. Security (Art. 32) and privacy by design (Art. 25)
Art. 32 requires "appropriate technical and organisational measures" taking into account state of the art, implementation costs, the nature/scope/context of processing, and the risk to data subjects. This is a risk-based standard — not a fixed checklist.
Specific measures mentioned in the Regulation: pseudonymisation, encryption, ongoing confidentiality/integrity/availability/resilience, ability to restore data after incidents, and regular security testing.
Art. 25(1) — privacy by design — requires that data protection is considered and integrated at the design stage of processing, not retrofitted. Art. 25(2) — privacy by default — means that, by default, only the minimum necessary data is processed. Default settings cannot collect more data than necessary.
For SaaS companies, the most common Art. 25(2) violation: analytics tools that collect full IP addresses and fingerprint users by default; session recording tools that capture form inputs by default; third-party scripts that set analytics cookies without consent.
7. Breach notification (Art. 33-34)
The 72-hour clock for supervisory authority notification starts when you become aware of a breach — not when you complete your investigation. You can notify and update (Art. 33(4) allows phased notification), but waiting until the investigation is complete before notifying will almost always exceed 72 hours and create a secondary compliance failure.
Individual notification (Art. 34) is required where a breach is likely to result in high risk to natural persons — using the same types of assessment as a DPIA (large-scale, special category, highly sensitive data, financial data). High risk indicators: data that enables identity theft, exposes vulnerable persons, enables financial fraud, or exposes health/location/biometric data at scale.
8. DPIAs (Art. 35)
A DPIA is mandatory before beginning processing that is likely to result in a high risk. The EDPB's nine criteria (WP248) indicate when a DPIA is likely required — if your processing meets two or more criteria, a DPIA is strongly recommended:
- Evaluation or scoring (profiling)
- Automated decision-making with legal effects
- Systematic monitoring
- Sensitive data or highly personal data (special categories, financial, location, health)
- Large scale
- Matching or combining datasets
- Data concerning vulnerable data subjects
- Innovative use of technology
- Prevents data subjects from exercising a right or using a service
Most HealthTech, HR tech, AdTech, FinTech, and AI-enabled SaaS companies processing personal data at scale will meet multiple criteria. The absence of a DPIA for such processing is a significant compliance gap.
9. International transfers (Art. 44-49)
Post-Schrems II, international transfers to the US require either: the EU-US Data Privacy Framework (if the US recipient is certified), or Standard Contractual Clauses (2021 EU SCCs, not the deprecated 2001/2010 versions) with a Transfer Impact Assessment (TIA).
A TIA is required for all SCC transfers. It assesses: whether the receiving country's law can compel the processor to disclose transferred data (surveillance law, government access), and whether supplementary measures are needed to maintain the protection level required by GDPR.
For US processors (AWS US-East, GCP, Stripe, HubSpot, etc.) with an EU-US DPF certification, the transfer mechanism is the DPF adequacy decision — which is simpler but depends on the recipient maintaining their certification and the political stability of the framework.
Accountability: demonstrating compliance
Art. 5(2) requires controllers to be able to demonstrate compliance with the Art. 5 principles. The practical output of an accountability programme is a documentation package: RoPA, DPAs, DPIAs, consent records, breach register, training records, and the policies that govern all of these.
The most common accountability gap: the company has good intentions and practices but no documentation. "We know who our sub-processors are" is not the same as a maintained sub-processor list. "We train staff on GDPR" is not the same as training completion records.
Use the GDPR Compliance Audit Checklist Generator to run a structured self-assessment across all obligation areas — scored by area with a prioritised remediation report. For specific tools: GDPR Article 30 RoPA Generator, DPIA Template Generator, GDPR DPA Generator, Breach Notification Template, and DSAR Policy Generator.