GDPR Compliance Checklist for Web Applications

Most GDPR writing is aimed at lawyers and DPOs. This checklist is for the engineers and CTOs who actually ship the web app. Each item below is something you will either build, configure, or document. The checklist is structured around the UK GDPR's principles and the rights it gives data subjects, but read as a to-do list for a web application build or refactor.

1. Know what data you hold and why

GDPR's first principle is lawfulness. You must have a lawful basis for every piece of personal data you process. The six bases are: consent, contract, legal obligation, vital interests, public task, and legitimate interests. For most SaaS and e-commerce apps, the practical bases are contract (data needed to deliver the service the user signed up for), consent (marketing, analytics cookies), and legitimate interests (fraud prevention, security).

• Maintain a Record of Processing Activities (ROPA) listing each category of personal data, the lawful basis, retention period, and transfer destinations. This is a document, but it should be derived from the data model, not invented in a meeting.
• Every database table containing personal data should be mapped to a ROPA entry. If you cannot map a table, either it should not exist or the ROPA is incomplete.

2. Collect the minimum data for the stated purpose

Data minimisation (Article 5(1)(c)) is concrete: do not ask for more than you need. Engineering implication:

• Audit sign-up forms. Every optional field with a business case should stay; every "nice to have" should go.
• Remove analytics tags and third-party pixels that collect personal data unless you have a genuine need and a lawful basis.
• When integrating third-party APIs, send only the fields required. If the third party accepts more than you need, filter at your boundary.

3. Consent that is granular, revocable, and auditable

Where consent is the lawful basis — cookies, marketing emails, optional profile fields — it must be freely given, specific, informed, and unambiguous. The cookie banner is the most visible consent surface, but consent shows up in the data model too:

• A user_consents table with columns: user ID, consent category (analytics, marketing, profiling), granted-at timestamp, withdrawn-at timestamp, consent-string version.
• Consent collected via checkbox UI, not pre-ticked.
• Withdrawal of consent is the same number of clicks as granting it.
• A "consent string" that a user can request a copy of, which shows the exact wording they agreed to and when.

For cookie banners specifically, PECR (the UK's cookie law) is the actual regulation, not GDPR. PECR requires consent for non-essential cookies; strictly necessary session and CSRF cookies are exempt. Most UK sites ship analytics, which is not strictly necessary and does require consent.

4. Subject rights, built into the product

Articles 15–22 give individuals rights over their data. Your web application must support each without you having to run custom queries against production. The engineering implications:

• Right of access (Article 15). Users can request a copy of their personal data. Build a "Download my data" button in account settings that produces a machine-readable export (JSON or CSV). Manual DSAR handling is acceptable at low volume but should not be the long-term plan.
• Right to rectification (Article 16). Users can correct inaccurate data. Any personal-data field surfaced in the UI must be editable, or there must be a clearly signposted route to request rectification.
• Right to erasure (Article 17). The "right to be forgotten" is narrower than commonly understood — it applies where the data is no longer needed, consent is withdrawn, or data was unlawfully processed. Build a soft-delete-and-anonymise flow rather than a hard-delete: personal identifiers are removed, internal IDs and business records remain, and audit logs retain enough for legal or security needs.
• Right to restrict processing (Article 18). A less-used right, but build a flag on the user record that suppresses processing (no emails, no profiling) while the user's dispute is pending.
• Right to data portability (Article 20). The export from Article 15 doubles as the portability artefact if it is machine-readable.
• Right to object (Article 21). A one-click unsubscribe in every marketing email. This is also a PECR requirement.

5. Privacy by design and by default

Article 25 requires that privacy considerations are built into the system from the outset. In engineering terms:

• New features are designed with a data-protection impact assessment (DPIA) where processing is novel, large-scale, or involves special-category data.
• Default settings err on the side of privacy. New users start with marketing emails off and public profiles private.
• Pseudonymisation (replacing identifiers with tokens) is used wherever the business doesn't need real identifiers — analytics, logging, internal tooling.
• Sensitive fields (addresses, national insurance numbers, payment details) are encrypted at rest at the column level, not just via disk encryption.

6. Retention and deletion

Article 5(1)(e) requires that personal data is kept no longer than necessary. Pragmatic engineering:

• Every database table containing personal data has a documented retention period in the ROPA.
• A retention job (Laravel scheduled task, cron) enforces it — anonymising or deleting records past the threshold.
• Audit logs retain only what is needed for security and legal purposes, not forever.
• Backups and replica data are captured in the retention policy. A deletion that leaves the data in a backup for another year is not a deletion.

7. Security and breach response

Article 32 requires "appropriate technical and organisational measures", which is the vague-sounding phrase that in practice means application security, access control, and regular testing. Concrete steps:

• Encrypt personal data at rest (database column-level or transparent disk encryption, plus explicit encryption of very sensitive fields).
• TLS 1.2+ on every endpoint. Redirect HTTP to HTTPS. HSTS header. Modern cipher suites.
• Role-based access control. Staff who do not need access to personal data should not have it.
• Audit logs covering data access by staff and administrators.
• Regular external penetration testing — see our pen test checklist for the scope.
• A documented incident response runbook. A breach that is only noticed by a customer tweet is a governance failure, not an engineering one.

When a breach does occur, the clock starts when you become aware. You have 72 hours to notify the ICO if the breach is likely to result in a risk to individuals' rights and freedoms. Direct notification to affected individuals is required if the risk is high. The runbook should include the decision tree for both.

8. International transfers

If personal data leaves the UK, you need a transfer mechanism. The main options: adequacy decisions (UK has adequacy with the EU and a list of other countries), Standard Contractual Clauses (SCCs), or the UK International Data Transfer Agreement (IDTA). Practical engineering implications:

• Inventory third-party processors — your hosting provider, database-as-a-service, email sender, analytics, customer support platform — and note where each stores data.
• Sign data processing agreements with each that include the transfer mechanism.
• For US-based processors, check that they comply with the UK–US Data Bridge or have appropriate SCCs in place.

9. Vendor and data processor management

Under Article 28, you need a written contract with every data processor covering scope, instructions, confidentiality, subprocessors, security, assistance with subject rights, and deletion at end of contract. This is paperwork but it has engineering implications too — every third-party integration you ship creates a new processor you need to paper over. Before adding a new vendor, ask:

• Is there an existing vendor that can do this? Reducing processors reduces your GDPR surface.
• Does the vendor have a published DPA? Most SaaS tools do. Sign it.
• Where does the vendor store data, and is the transfer mechanism in place?

10. Documentation and accountability

GDPR requires that you can demonstrate compliance, not just achieve it. Documents to maintain:

• ROPA (Article 30).
• DPIAs for high-risk processing.
• Privacy notice on the website.
• Cookie policy with a category table.
• Data processor contracts.
• Incident response runbook and log of incidents (whether they reached ICO threshold or not).
• Staff training records — engineering included.

How this fits with a Laravel or modern web app build

If you are building or maintaining a web application on Laravel (or any modern framework), the patterns above map cleanly onto existing tooling. Policies and gates for access control; Eloquent observers for anonymisation; scheduled commands for retention; queued jobs for data export; the standard users.email_verified_at/deleted_at columns extended with anonymised_at and consent_version. YUPL's Laravel engineering team has done this on a dozen UK SaaS products.

GDPR compliance and security overlap heavily — Article 32 is why the ICO routinely cites penetration testing and access-control weaknesses in fines. A good UK compliance programme pairs the legal work above with an annual CREST-accredited penetration test so that the "appropriate technical measures" phrase has evidence behind it.

If you want a review of your current web application against this checklist, get in touch — we run fixed-scope GDPR readiness reviews that produce a gap analysis and a prioritised remediation plan.

About the author. Spencer Schotel is CTO of YUPL, a CREST-accredited UK agency specialising in Laravel engineering and penetration testing. This article is general information, not legal advice.