Self-assessment · sources checked 29 July 2026
GDPR website checklist: record the evidence
Do not give the site a compliance score. Test defined routes and states, capture what happened, name the decision owner, and record what you could not verify. That gives engineering, marketing, and privacy teams something they can act on.
Start here
- Use four statuses: observed, absent in the test, blocked, and decision needed. These statuses cannot establish compliance or non-compliance.
- Test a fresh visit before any choice, reject, purpose-specific acceptance, and withdrawal. Repeat on representative routes, languages, login states, and markets.
- Capture network requests, cookies and other browser storage, form destinations, vendor configuration, notices, and a synthetic rights-request trace.
- Assign two owners where needed: the person who can change the implementation and the DPO, privacy lead, or counsel who owns the legal decision.
- This checklist is a first-party self-assessment. It does not decide whether the GDPR applies, whether consent is legally valid, or whether the organisation complies.
The method
A score hides the conditions. An evidence register keeps them visible.
The same tag can stay silent on the homepage and fire early on a campaign template. A form can send to the expected CRM in Germany and to an unexpected automation endpoint in another market. “10 out of 12” cannot show either problem.
Create one row for every observation. Record the route, language, market, browser or login state, consent state, time, request or workflow, artifact, technical owner, privacy or legal owner, and next test. If access is missing, mark the row blocked. If the behavior is clear but the legal treatment is not, mark it decision needed.
The register provides operational evidence and carries no legal opinion. The GDPR text sets the legal frame. Your accountable privacy or legal role applies that frame to the organisation and facts.
Evidence register
Use these columns for every check.
| Field | Record | Example |
|---|---|---|
| Scope | Route, language, market, browser/login state, consent state | /de/contact, logged out, reject all |
| Observation | What the browser, interface, configuration, or workflow did | Request to analytics vendor appeared before any choice |
| Artifact | HAR/network row, screenshot, storage export, configuration, document, synthetic record, or ticket | HAR file and tag-manager trigger screenshot |
| Status | Observed, absent in the test, blocked, or decision needed | Observed |
| Owners | Technical owner and privacy/legal decision owner | Web team; DPO |
| Action and retest | Change required, acceptance condition, and state to repeat | Do not trigger before analytics acceptance; repeat fresh/reject/accept/withdraw |
Twelve checks
Run the website check in this order.
01
Record the applicability decision
Do not assume that anyone who can open the site is in GDPR scope. Record the establishment, audience, offering, and monitoring facts for the accountable reviewer. Article 3 covers processing in the context of an EU establishment and certain offering or monitoring involving people in the EU. Counsel or the DPO owns the conclusion.
02
Inventory the observable surface
List representative routes, forms, accounts, checkout steps, tags, pixels, embeds, cookies, local storage, CDNs, logs, error tools, CRM endpoints, and vendors. Note what needs staging, a test account, or configuration access.
03
Test each consent state
Use a fresh browser profile. Capture behavior before any choice, after reject, after each purpose-specific acceptance, and after withdrawal. The German TDDDG section 25 governs storing or accessing information on a device and contains narrow exceptions. A DPO or counsel decides how it applies to each technology.
04
Compare the notice with runtime behavior
Match observed purposes, data, recipients, countries, retention statements, and contact paths to the privacy notice. Record omissions and contradictions. Do not invent the missing legal basis or wording; send that decision to the privacy owner.
05
Check legal links by the right rule
Verify that privacy and provider-information links work from representative routes and devices. In Germany, provider information is addressed separately by section 5 DDG for services within its scope. Do not label every footer issue a GDPR finding.
06
Classify each vendor role
Record what each vendor receives and why. The accountable reviewer classifies it as processor, controller, joint controller, or another role. Article 28 agreements apply to processors; a technical inventory cannot assume every vendor has the same role.
07
Record recipients and countries
Capture the endpoint, vendor entity, processing location where known, and any onward route. Link the contract or transfer record supplied by the organisation. Mark adequacy, safeguards, supplementary measures, and disclosure wording as privacy or legal decisions.
08
Trace a synthetic rights request
Use a synthetic record. Test intake, identity-check handoff, search across the site stack and connected systems, review, response, correction, and deletion or restriction steps. Record exceptions and timing decisions. The EDPB access guidance explains the legal process; the test proves only the workflow you observed.
09
Trace every form destination
For each field, record purpose, required or optional state, destination, recipient, confirmation, marketing choice, and planned retention. Use synthetic submissions to confirm where the record appears. Flag preselected marketing choices and undocumented copies for review.
10
Collect security evidence for the path
Check transport security, administrative access, secrets handling, patch ownership, third-party scripts, logging, backups, and recovery for the scoped path. Article 32 is risk-based. A browser checklist can identify evidence and gaps, but it cannot certify the organisation’s security measures.
11
Test retention and deletion
Record the approved retention rule, system owner, deletion or anonymisation mechanism, exceptions, and evidence of execution. A value written in the privacy notice is not proof that the CRM, inbox, analytics tool, backups, and exports follow it.
12
Define change triggers and retest
Repeat affected checks when a route, tag, consent configuration, form, vendor, destination, purpose, retention rule, market, or legal decision changes. Record the release ticket and the states that must be retested. Use change triggers instead of an invented calendar interval.
Bounded browser smoke test
Run this on representative routes before release.
✓
Start with a fresh profile. Save the route, language, market, time, network log, and browser storage before making a choice.
✓
Reject the optional purposes. Record which requests and storage entries appear, disappear, or remain.
✓
Accept one purpose at a time. Record only the change caused by that choice.
✓
Withdraw or change the choice. Record future requests, new storage, and whether existing identifiers change or remain.
✓
Submit each representative form with synthetic data. Trace every destination and confirmation.
✓
Compare observed vendors and purposes with the current privacy notice and internal inventory.
✓
Mark blocked tests and legal decisions. Do not convert missing access into a pass.
Compliance next step
Get a compliance check on: GDPR website checklist
Send us where your site stands today. We reply with the risks that carry real exposure, not a generic checklist.
Legal frame
Keep the rule, observation, and decision separate.
| Source | Question it helps frame | What the self-check can prove |
|---|---|---|
| GDPR on EUR-Lex ↗ | Scope, principles, information, rights, design, processors, records, and security | Observed implementation and available artifacts only |
| TDDDG section 25 ↗ | Storage of or access to information on terminal equipment and its exceptions | What was stored or accessed in each tested state |
| DSK digital-services guidance ↗ | German regulator interpretation for consent and digital-service implementation | Interface and runtime behavior under documented conditions |
| EDPB consent guidance ↗ | Freely given, specific, informed, unambiguous consent and withdrawal questions | Choice path, presentation, and technical effect; not final legal validity |
| EDPB right-of-access guidance ↗ | Intake, identity, search, response, copies, timing, and limitations | A synthetic workflow trace with real requests and legal exceptions outside the test |
| DDG section 5 ↗ | Provider information for digital services within scope | Whether the link and displayed information are present and reachable |
When the self-check stops
Escalate the decision. Keep the evidence.
Stop at the boundary when you need to decide GDPR applicability, lawful basis, TDDDG necessity, controller or processor roles, transfer safeguards, notice wording, retention exceptions, identity checks, a rights-request refusal, DPIA need, or legal priority. Give the reviewer the register row and artifact rather than a vague concern.
Use the cookie-banner guide for a deeper consent implementation pass and the Google Analytics guide for analytics-specific questions.
If you need independent state testing, configuration evidence, finding ownership, and a post-fix retest, use the technical GDPR audit. The cost guide shows how to compare scopes and published prices.
Common questions
Questions operators ask before running the checklist.
Can this checklist prove that our website is GDPR compliant?
No. It records observable implementation evidence and unresolved decisions for a defined scope. GDPR applicability, legal bases, consent validity, contracts, transfers, retention exceptions, and organisational compliance need accountable privacy or legal review.
Does every website visitor in the EU make GDPR apply?
Mere accessibility is not the full Article 3 test. Relevant facts include processing in the context of an EU establishment, offering goods or services to people in the EU, and monitoring their behavior in the EU. Record those facts and ask the accountable reviewer to decide scope.
Does every analytics tool need consent in Germany?
Do not decide from the product label. Record what the technology stores or accesses on the device, whether a TDDDG section 25 exception is claimed, what personal data is processed, and the stated purpose and legal basis. Your DPO or counsel assesses the specific setup.
Does every vendor need a data processing agreement?
Article 28 applies when a vendor acts as a processor. Vendors can have other roles. Inventory the data, purpose, instructions, entities, and contract, then route the classification and required agreement to the accountable privacy or legal owner.
How often should we run the checklist?
Use change triggers. Repeat the affected checks when the route, tag, consent setup, form, vendor, destination, purpose, retention rule, market, or legal decision changes. The organisation can add a risk-based calendar review, but this page does not invent one interval for every site.
What should we do when a check is blocked?
Record the missing access, system, owner, or artifact and mark the row blocked. Assign an action and due owner. A blocked check is an explicit limitation. It provides neither a pass nor an automatic legal failure.
Written by
Vineet Talwar
Co-founder, Tech & Operations at Some Tech Work. WordCamp speaker across Europe and Asia, and host of the WP Shoutout podcast.
Start here
Ready to talk.Book a short diagnostic.
Tell us what needs fixing
We read every brief and reply within one business day.
Prefer to talk first?or request a tech stack audit →or email us directly →
Not sure where to start? Send the stuck decision, workflow, or page. We will say whether you need a diagnostic call, a tech stack audit, or a different first step.