GDPR in a web application: Decisions to make before the first database

01Map personal data and responsibilities

This guide covers the EU GDPR for a typical business application. Confirm sector rules and specific lawful bases with the person responsible for data protection. UK operations require a separate assessment under the UK GDPR framework described by the ICO. Translating a privacy notice into English does not determine the applicable law.

Trace one enquiry through the form, server, database, email, CRM, backup and support process. Record the purpose, recipients and retention at each point. Include message queues, search indexes, exports and error reports. These secondary copies can be easy to miss when the brief focuses on visible screens.

Under the GDPR, the controller determines purposes and means; a processor acts on the controller’s behalf. Writing application code does not automatically make a developer a processor. Assess the actual handling of personal data, including maintenance access, and record who makes the decisions.

02Give every field a specific purpose

Ask which step cannot be completed without a proposed field. Delivering a digital guide probably does not need somebody’s home address. An open notes field can collect information you never intended to hold. Explain what belongs there and consider limiting its use.

The EDPB describes protection by design and by default. Turn that into a recurring design review for every new table, event and integration. A hidden required field in an API still collects data, even if the customer never sees a form control.

This is a working brief, not a completed legal assessment. Fill it with the actual data handled by your application. Return answers such as “just in case” to the product owner for a concrete decision. Removing an unnecessary field also removes the work of protecting and maintaining it.

03Consent is one lawful basis, not a universal solution

Assign an appropriate lawful basis to each purpose. The EDPB distinguishes contract, legal obligation, consent and legitimate interests among the available bases. Necessary work on a quotation requested by an individual may fall under pre-contractual steps. Marketing requires its own assessment; it does not automatically become necessary for fulfilling a contract.

Where you rely on consent, design a demonstrable choice and an easy withdrawal process. As an implementation approach, record its purpose, the notice version, time and method. A changed preference should reach connected systems too. A checkbox saying “I agree to GDPR” does not define any of this.

The information you give people should reflect operations: who uses the data, for what purposes, which recipients receive it and how rights can be exercised. Put a relevant explanation at the collection point. Do not rewrite the purpose after building an integration merely to make the paperwork fit.

04Check access against the individual record

Create an access matrix for customers, support staff, customer organisation administrators and technical administrators. Specify the operations each role needs. In a multi-tenant application, check which organisation owns a record, including attachments, exports and search results.

Hiding a button does not authorise the request. The server must check it. Include attempts to open another organisation’s identifier and to reuse a link after access has been revoked. For exceptional support access, design a limited permission and an auditable reason instead of a permanently shared administrator password.

The EDPB requires security proportionate to risk. Choose measures based on the consequences of disclosure, alteration and loss. Give transport encryption, key management, backup restoration and updates a named owner. A security setting nobody maintains will not remain useful simply because it appeared in a launch checklist.

05Make deletion part of the data model

Set justified retention periods for each category and define when the clock starts. An abandoned form and an accounting record with a statutory retention requirement have different needs. There is no single retention period that applies to every record in every application.

Consider an illustrative account closure: sign-in stops, unnecessary profile details are removed, and records subject to a retention obligation remain separately with restricted access. Confirm the exact treatment for your operation. Erasure has exceptions; the system should support an explanation of what remains and why.

Include replicas, indexes and suppliers in the plan. Define backup retention, access and the recovery procedure so that restoring a backup does not silently return deleted information to normal use. A “deleted” flag is not physical deletion. Pseudonymised information is also not automatically anonymous. Keep those differences visible in the technical brief.

06Give people’s rights a working support process

Design request intake, proportionate identity verification, retrieval and secure delivery of the response. The EDPB gives a basic response period of one month. Where an extension is justified, the individual must be informed in time. Do not wait for a real request to discover all the copies you hold.

Test access, correction, erasure and restriction using relevant scenarios. Portability does not apply automatically to every item of personal data. A customer export must not expose other people’s contacts, password hashes or internal secrets. A technically successful database download is not necessarily a correctly fulfilled request.

07Assess suppliers using actual data flows

For hosting, email, monitoring and AI services, identify the data received, retention and subprocessors. Where a controller and processor relationship exists, address the Article 28 agreement. A supplier’s “GDPR ready” label does not identify the right configuration for your purpose.

Transfers outside the EEA require additional consideration. Verify the relevant transfer mechanism and any further safeguards. Choosing an EU server region does not settle the question if another recipient outside the EEA can access information through support or a related service. Capture those accesses when designing system integrations.

08Review cookies, logs and test data separately

Permission to store cookies and the lawful basis for subsequent personal-data processing are separate questions. For Czech deployments, the Czech authority explains the necessary-cookie exception and straightforward refusal of other cookies. Assess national rules for your target markets; Czech guidance does not replace UK or other national requirements. Test the actual network requests before a choice and after withdrawal.

Keep passwords, tokens and unnecessary form contents out of logs. Avoid personal data in URLs. Use synthetic test data where another approach is not justified. A production database on a contractor’s laptop is not harmless because its filename says “test”. Review session recordings and support screenshots as well as the main application database.

09Prepare for a breach before launch

Record the decision maker, evidence preservation process and the information needed to establish the scope. The EDPB distinguishes breach notification duties: the controller notifies the authority without undue delay and, where feasible, within 72 hours of awareness unless risk to people’s rights and freedoms is unlikely. A processor informs the controller without undue delay.

Affected people require communication without undue delay when a breach is likely to create high risk, subject to GDPR exceptions. Document breaches. Also assess whether a data protection impact assessment, or DPIA, is required where planned processing is likely to create high risk. Being a small business does not automatically remove all record-keeping duties.

10Common questions

Discuss data protection while designing your application. Specific rules are easier to build into the data model before launch than retrofit into live operations.