You've built the app. You've written the privacy policy. You've added a cookie banner. Job done, right?
Not quite. GDPR compliance isn't a single checkbox — it's a spread of technical, legal, and operational requirements that touch almost every layer of a web project. Fines for non-compliance can reach €20 million or 4% of global annual turnover, whichever is higher. And yes, small sites get caught too.
This checklist covers the areas developers are most commonly responsible for — or at least need to flag to their clients before handoff.
- Lawful Basis for Processing Data
Before you collect a single byte of personal data, you need a lawful basis under Article 6 of GDPR. The six lawful bases are:
Consent — the user has actively agreed
Contract — processing is necessary to fulfil a contract with the user
Legal obligation — you're required to process the data by law
Vital interests — processing is necessary to protect someone's life
Public task — you're carrying out a task in the public interest
Legitimate interests — you have a genuine, proportionate reason to process
Most web apps rely on consent or contract. The mistake developers make is assuming consent is implied. It isn't. Consent must be freely given, specific, informed, and unambiguous. Pre-ticked boxes don't count.
Check: Have you identified and documented the lawful basis for every type of personal data your site processes?
- Cookie Consent
Cookies that are not strictly necessary require explicit, opt-in consent before they fire. This includes:
Analytics cookies (Google Analytics, Plausible, Fathom)
Marketing/retargeting pixels (Meta Pixel, Google Ads)
Session recording tools (Hotjar, FullStory)
A/B testing tools (Optimizely, VWO)
A compliant cookie banner must:
Present options clearly, without dark patterns
Make declining as easy as accepting (no grey-out on the reject button)
Not pre-select any non-essential categories
Allow users to withdraw consent at any time
Not block access to the site if the user declines
Check: Are all non-essential scripts blocked until consent is given? Inspect your network tab on first load with a clean session — anything firing before consent is a violation.
- Privacy Policy
You need one. It needs to be written in plain language, not legalese. It must cover:
Who you are and how to contact you (and your DPO if applicable)
What personal data you collect and why
The lawful basis for each type of processing
How long you retain data
Who you share data with (third-party processors, sub-processors)
Users' rights under GDPR (access, rectification, erasure, portability, objection)
Whether you transfer data outside the UK/EEA, and the safeguards in place
How users can make a complaint to the ICO (or relevant supervisory authority)
Check: Is the privacy policy linked from every page that collects data (forms, checkout, sign-up)? Is it accessible before the user submits any personal information?
- Data Minimisation
GDPR's data minimisation principle (Article 5) requires that you only collect what you actually need. This is somewhere developers can make a real difference at the design stage.
Common violations:
Contact forms asking for phone numbers that are never used
Sign-up forms requiring date of birth for no functional reason
Server logs retaining full IP addresses indefinitely
Analytics collecting more granular data than necessary
Check: Go through every form and data collection point on the site. For each field, ask: do we actually need this to deliver the service? If not, remove it.
- Data Retention
Storing data indefinitely is a GDPR violation. You need a retention policy that defines how long each category of data is kept, and a mechanism to delete or anonymise it after that period.
Common areas to address:
User account data — what happens when an account is deleted or inactive?
Order/transaction records — often kept for tax/legal reasons, but there's still a limit
Contact form submissions — usually no reason to keep these beyond a few months
Server and application logs — consider truncating or anonymising IP addresses
Email marketing lists — unsubscribers should be purged or suppressed
Check: Do you have automated deletion or anonymisation in place, or are you relying on manual processes? Manual processes tend not to happen.
User Rights
GDPR grants users several rights that your application needs to support. Depending on your scale and tooling, some of these can be handled manually, but the process needs to exist and you need to be able to respond within 30 days.
Right of access (SAR) — Users can request a copy of all data you hold about them. You need to be able to export this.
Right to erasure — The "right to be forgotten." You must be able to delete a user's data from your systems, including backups (within reason) and any third-party processors you've passed data to.
Right to rectification — Users can ask you to correct inaccurate data.
Right to portability — Users can request their data in a machine-readable format (e.g. JSON or CSV).
Right to object — Users can object to certain types of processing, particularly direct marketing.
Check: How would you currently handle a subject access request? Do you know every place a user's data lives (database, email platform, analytics, CRM, support tool)?
Third-Party Processors
Every third-party tool you integrate with that handles personal data on your behalf is a data processor. Under GDPR, you must have a Data Processing Agreement (DPA) in place with each of them.
Most reputable SaaS providers have a DPA you can sign or accept online (Stripe, Mailchimp, AWS, Google, etc.). You also need to list them in your privacy policy.
If any of these processors are based outside the UK or EEA, you need appropriate safeguards for the transfer — usually Standard Contractual Clauses (SCCs).
Check: Make a list of every third-party tool that touches personal data. Have you signed their DPA? Are they in your privacy policy?
Forms and Data Collection Points
Every form that collects personal data needs:
A clear explanation of what the data will be used for (at the point of collection, not buried in a privacy policy)
A link to your privacy policy
Explicit consent where required (e.g. for marketing emails — a pre-ticked opt-in doesn't count)
HTTPS (non-negotiable)
Check: Audit every form on the site. Is there any form collecting data without a clear purpose statement and privacy policy link?
- Security Measures
GDPR requires "appropriate technical and organisational measures" to protect personal data (Article 32). For most web applications, this means:
HTTPS everywhere (HSTS is a good addition)
Passwords hashed with a modern algorithm (bcrypt, Argon2) — never stored in plain text
Access controls — does only the right people/systems have access to personal data?
Dependency management — are you keeping libraries up to date? Outdated dependencies are a common breach vector
Database security — is your database exposed to the internet? Are credentials stored securely?
Regular backups, stored securely
Check: When did you last review who has access to your production database and admin panels? Principle of least privilege applies.
- Data Breach Response Plan
Under GDPR, if you suffer a personal data breach, you have 72 hours to notify your supervisory authority (the ICO in the UK) if the breach is likely to result in risk to individuals. High-risk breaches also require direct notification to affected users.
This means you need:
A way to detect breaches (monitoring, alerts)
A documented process for assessing severity
Clear ownership of who notifies the ICO
A record of breaches (even those you don't report)
Check: If you discovered a breach today, do you know exactly what to do and who is responsible?
- Records of Processing Activities (ROPA)
If your organisation has 250 or more employees, you're required to maintain a formal Record of Processing Activities under Article 30. Below that threshold it's best practice, and the ICO strongly recommends it.
A ROPA documents:
What personal data you process
Why you process it
Who has access to it
Where it's stored (including third-country transfers)
How long you keep it
Check: Even if you're not required to maintain a formal ROPA, do you have enough documentation to answer an ICO enquiry confidently?
- Age Verification (if applicable)
If your service is directed at or likely to be used by children, you have additional obligations. In the UK, the Children's Code (Age Appropriate Design Code) sets high standards for services likely to be accessed by under-18s, including defaulting to high privacy settings and not profiling children.
If there's any chance your service reaches minors, this needs specific legal advice — it's one of the more complex areas of UK data law right now.
Check: Is your service likely to be used by under-18s? If so, have you addressed the Children's Code?
Wrapping Up
GDPR compliance isn't something you bolt on at the end of a project — it needs to be considered from the start. The good news is that most of it is straightforward once you know what to look for.
If you're handing off a project to a client or want a quick sense of where a site stands, ClearlyCompliant analyses your site's GDPR compliance and delivers a detailed PDF report covering the key risk areas — useful as a starting point or a sanity check before launch.
Disclaimer: This article is for informational purposes and does not constitute legal advice. For specific legal questions around GDPR compliance, consult a qualified data protection professional.