Data Mapping
Before touching consent banners or privacy policies, map your data flows.
Checklist actions:
- List every personal data field collected, including names, emails, IP addresses, user IDs, and behavioral events.
- Trace where each data point flows, from browser to backend, database, logs, analytics, and third parties.
- Document storage locations, including databases, backups, log aggregation tools, and cloud buckets.
- Identify all recipients, including analytics providers, email services, error monitoring, and CDNs.
Concrete example: If a contact form sends submissions to your API, logs request bodies, forwards data to email, and stores records in a CRM, all four destinations must be documented.
Lawful Basis
Every data category must have a reason to exist.
Checklist actions:
- Assign a lawful basis to each data category, such as consent, contract, or legitimate interest.
- Remove fields that do not support a clear purpose.
- Do not collect optional data unless you can justify why it is needed.
Concrete example: If newsletter signup only requires an email address, remove name, company, and phone fields unless they are actively used.
Consent Mechanics
Consent must be explicit, granular, and reversible.
Checklist actions:
- Use unchecked opt-in controls for consent.
- Separate consent by category, such as analytics, marketing, and functional cookies.
- Store consent state server side or in a durable client store.
- Provide a visible way to withdraw consent and update stored preferences.
Concrete example: A settings panel that lets users disable analytics after initially opting in, triggering deletion of analytics cookies.
Cookie and Tracker Control
Scripts must respect consent, not just display a banner.
Checklist actions:
- Block all non-essential scripts until consent is granted.
- Load analytics, ads, or session replay tools dynamically after opt-in.
- Avoid firing tracking pixels on initial page load.
- Respect Do Not Track headers where applicable.
Concrete example: Disable Google Analytics initialization until the analytics consent flag is true, instead of loading it by default.
Forms and Inputs
Forms are a primary source of unnecessary data collection.
Checklist actions:
- Apply data minimization to every form field.
- Display a short purpose explanation near each form, not hidden in a policy link.
- Remove hidden fields that collect personal data unless strictly required.
- Validate that frontend and backend enforce the same field constraints.
Concrete example: A signup form stating “We use your email only to create your account and send password resets” directly under the email field.
User Rights Implementation
User rights must be actionable, not theoretical.
Checklist actions:
- Provide a way for users to request access to their stored data.
- Allow users to correct inaccurate information without support tickets when possible.
- Implement deletion workflows that remove or anonymize user data across systems.
- Support data export in a structured, machine readable format.
Concrete example: An account dashboard button that triggers background jobs to delete user records, revoke tokens, and purge analytics identifiers.
Data Retention
Keeping data forever is a compliance risk.
Checklist actions:
- Define retention periods for each data category.
- Implement scheduled deletion or anonymization jobs.
- Apply retention logic to backups and logs where feasible.
Concrete example: Automatically deleting contact form submissions after 90 days unless they are linked to an active support case.
Security Measures
Security is a core GDPR requirement, not an optional enhancement.
Checklist actions:
- Enforce HTTPS everywhere, including internal tools.
- Encrypt sensitive data at rest when relevant.
- Limit access by role, not convenience.
- Log access to personal data and monitor for anomalies.
- Detect and alert on suspicious behavior.
Concrete example: Restricting database access to application roles only and logging all admin queries touching user tables.
Third Party Services
Every external service expands your risk surface.
Checklist actions:
- Inventory all third party services that receive personal data.
- Confirm data processing agreements exist where required.
- Understand where data is stored geographically.
- Disable integrations that are unused or unnecessary.
Concrete example: Removing a legacy chat widget that still loads tracking scripts even though it is no longer used.
Privacy Policy Integration
The policy must describe what the code actually does.
Checklist actions:
- Verify that technical behavior matches documented claims.
- Update the policy when adding, removing, or changing data flows.
- Link consent categories and user rights to concrete features.
Concrete example: If the policy says analytics are optional, ensure analytics are technically blocked until consent.
Environment Separation
Development shortcuts can create compliance violations.
Checklist actions:
- Never use real user data in development or staging environments.
- Mask or generate synthetic data for testing.
- Restrict access to production data and logs.
Concrete example: Replacing production database snapshots with anonymized datasets before loading into staging.
Breach Readiness
Assume incidents will happen and prepare accordingly.
Checklist actions:
- Log security relevant events with timestamps and identifiers.
- Monitor for unauthorized access or data exfiltration.
- Document an internal response process with clear ownership.
- Be able to identify affected users and data types quickly.
Concrete example: Centralized logging that allows filtering by user ID and event type during incident investigation.
Final Developer Reality Check
If you cannot explain what data your website collects, why it collects it, and how to delete it, your system is not GDPR ready. Compliance improves when data flows are simpler, tracking is intentional, and features are built with deletion in mind from day one.