Web Security
GDPR Checklist for Websites (2026): 12 Checks for Business Owners
A practical GDPR checklist for websites. Concrete actions for consent, cookies, forms, user rights, retention, security and third-party services.
Kevin A. Sommerstein7 min read
GDPR checklist for websites 2026
GDPR compliance is not a legal document problem, it is a systems problem. This GDPR checklist for websites breaks the requirements down into twelve areas you can act on directly in code.
As a developer, you need to know what data the website collects and turn the rules into code: what to build, configure or remove.
First the quick version to tick off, then each item with concrete examples.
Quick GDPR checklist for websites (2026)
Twelve checks that cover the essentials. If you can tick all of them, your website is in good shape:
- Map all personal data: what is collected, where it is stored and who receives it
- Tie every data point to a lawful basis and remove fields you do not need
- Make consent active, split by purpose and easy to withdraw
- Block analytics and marketing scripts until the user has said yes
- Trim your forms: collect only what is needed and explain why next to the field
- Build working flows for access, correction, deletion and export
- Set retention periods and automate deletion, including logs and backups
- Use HTTPS everywhere, encrypt sensitive data and restrict access by role
- List all third-party services and make sure processing agreements are in place
- Make sure the privacy policy describes what the system actually does
- Never use real personal data in test and development environments
- Have an incident process: logging, alerts and fast identification of affected users
Below we go through each item with what to review in practice and one example per area.
Map the data
Before you touch cookie banners or privacy policies, you need to understand how data actually moves through the system.
What to review:
- List all personal data collected, for example names, email addresses, IP addresses, user IDs and behavioral data.
- Follow every data point from the browser onward to the backend, databases, logs, analytics tools and external services.
- Document where data is stored, including databases, backups, logging systems and cloud storage.
- Identify every recipient, such as analytics vendors, email services, error monitoring and CDNs.
Example: If a contact form posts to an API, logs the full request, forwards it by email and stores details in a CRM, every one of those flows needs to be documented.
Lawful basis
Every piece of data you collect must have a clear purpose.
What to review:
- Tie each type of data to a lawful basis, such as consent, contract or legitimate interest.
- Remove fields that serve no actual function.
- Do not collect optional information unless you can justify why it is needed.
Example: If a newsletter signup only requires an email address, fields for name, company and phone number should be removed unless they are actually used.
Consent in practice
Consent must be active, granular and easy to withdraw.
What to review:
- Use unchecked options for consent.
- Split consent into categories, for example analytics, marketing and necessary functions.
- Store consent state server-side or in persistent client storage.
- Give users a clear way to change or withdraw their consent.
Example: A settings page where the user can turn off analytics afterwards, which also deletes the analytics cookies.
Cookies and tracking
Showing a banner is not enough. The code has to actually respect the choice.
What to review:
- Block all non-essential scripts until consent exists.
- Load analytics, ads and session recording tools only after opt-in.
- Avoid firing any tracking on the first page load.
- Respect Do Not Track settings where relevant.
Example: Do not initialize analytics until the user has actually accepted analytics cookies, for example by loading GA4 through Google Consent Mode only after opt-in, or by choosing a cookieless alternative like Plausible and skipping the banner for analytics entirely.
Forms
Forms are often the biggest source of unnecessary data collection.
What to review:
- Review every field and collect only what is needed.
- Explain the purpose right at the form, not buried in a policy.
- Remove hidden fields that collect personal data unless absolutely necessary.
- Make sure frontend and backend enforce the same validation rules.
Example: A signup form with the text: "We use your email address to create your account and send password resets."
User rights
Rights have to work in reality, not just on paper.
What to review:
- Give users a way to see what data is stored about them.
- Let users correct inaccurate data themselves where possible.
- Build deletion or anonymization flows across every system.
- Offer data export in a structured, machine-readable format.
Example: A button in account settings that starts deletion of user data, revokes tokens and removes analytics identifiers.
Retention
Storing data with no end date is a liability.
What to review:
- Set clear time limits for how long each type of data is kept.
- Automate deletion or anonymization.
- Apply the same logic to backups and logs where possible.
Example: Contact form submissions are deleted automatically after 90 days unless they belong to an active case.
Security
Security is a baseline requirement in GDPR, not an optional extra.
What to review:
- Use HTTPS everywhere, including internally.
- Encrypt sensitive data where relevant.
- Restrict access based on roles.
- Log access to personal data and monitor for anomalies.
- Alert on suspicious behavior.
Example: The database is reachable only through application accounts and every administrative query is logged.
Third-party services
Every external service increases the risk.
What to review:
- List every external service that receives personal data.
- Make sure data processing agreements are in place where required.
- Find out where the data is stored geographically.
- Remove integrations that are no longer used.
Example: Removing an old chat widget that still loads tracking scripts even though nobody uses it.
Privacy policy and code
The policy must describe what the system actually does.
What to review:
- Make sure the technology matches what the policy says.
- Update the policy whenever data flows change.
- Tie consents and rights to actual working features.
Example: If the policy says analytics is optional, analytics tools must stay blocked until consent is given.
Environments
Shortcuts in development create problems in production.
What to review:
- Never use real user data in test or development environments.
- Mask or generate test data.
- Restrict access to production data and logs.
Example: Replace production databases with anonymized data in staging environments.
Incident readiness
Assume something will eventually go wrong.
What to review:
- Log security-relevant events with timestamps and identifiers.
- Monitor for unauthorized access and data leaks.
- Document a clear incident process.
- Make sure affected users and data types can be identified quickly.
Example: Central logging that makes it possible to filter events per user ID during an incident.
If you cannot explain what data your website collects, why it collects it and how it gets deleted, the system is not GDPR ready. Keep the data flows simple, track intentionally and build deletion in from day one, and the rest of the work gets much easier.
Want to see the principles in practice? Our own privacy policy is written to mirror exactly what the website does, nothing more and nothing less:
See our privacy policy as a living example
GDPR is not the only legal requirement on your website either. Since June 2025 the European Accessibility Act applies to many companies as well:
European Accessibility Act: the rules in force in 2026
Want a website where GDPR is solved from the start?
Developly builds websites on Next.js where data flows, consent and deletion are designed in from the beginning instead of patched on afterwards. Get in touch and we will look at where your website stands.
Frequently asked questions
Only if it sets cookies that are not strictly necessary. Session cookies for login or a shopping cart require no consent. If you run neither analytics, advertising nor embedded content that tracks, you can often drop the banner entirely, which is better for the user experience too.
GA4 can be used, but only if the tool loads after consent and is configured correctly. If you want to skip the consent requirement for analytics entirely, there are cookieless European alternatives such as Plausible or a properly configured Matomo.
Fines of up to 20 million euros or 4 percent of global annual turnover, whichever is higher, enforced by national data protection authorities. For smaller companies the most common first step is an inquiry or a reprimand, but even an inquiry costs time and trust.
Yes. GDPR applies to every organisation that processes personal data about people in the EU, regardless of size. The requirements are the same, but for a small business with few data flows the work is usually much easier to carry out and document.
