GDPR for apps: what to build in from the start

Key points

• Article 3 reaches companies outside the EU that offer goods or services to people in the EU, even for free. UK GDPR does the same for people in the UK.
• Every use of personal data needs one of six lawful bases. Consent is only one of them, and it must be as easy to withdraw as to give.
• Article 25 asks for data protection by design and by default: collect less, keep it for less time, and make private the starting setting.
• Cookies and similar tracking need consent unless they are strictly necessary, under the separate ePrivacy rules.
• Build access, export, correction and deletion into the product and the admin panel, so a request is a routine task, not a scramble.
• This is general information, not legal advice. For your own case, read your regulator’s guidance or ask a privacy lawyer.

Who the GDPR applies to

The General Data Protection Regulation, Regulation (EU) 2016/679, applies to companies established in the EU. Article 3 also reaches companies outside the EU when they process the personal data of people in the EU and that processing relates to offering them goods or services, whether or not the people pay, or to monitoring their behavior in the EU. A startup in India, the US or Brazil with users in the EU can be in scope for those users.

A company outside the EU that is in scope must, in most cases, name a representative in the EU in writing (Article 27). There is an exception for processing that is occasional, low risk and does not involve sensitive data on a large scale.

The UK kept the GDPR in its own law as the UK GDPR, alongside the Data Protection Act 2018. The UK regulator, the ICO, says organizations outside the UK must comply and appoint a UK representative if they offer goods or services to people in the UK or monitor their behavior. Both laws can apply to the same app. In December 2025 the European Commission renewed its decision that the UK protects data adequately, so data can flow from the EU to the UK without extra safeguards.

Two roles matter. The controller decides why and how personal data is processed; for your app, that is usually your company. A processor handles personal data on the controller’s behalf, such as your hosting provider, email service or a development agency with access to production data.

Other privacy laws follow similar ideas. California’s CCPA, as amended by the CPRA, gives residents rights to know, delete and correct their data and to opt out of its sale or sharing. India’s Digital Personal Data Protection Act, 2023 also reaches companies outside India that offer goods or services to people in India. Building the features below once usually covers much of what these laws ask for, though each has its own scope and details.

This guide is general information, not legal advice. It explains the main rules from the official texts listed below. For decisions about your own product, read your regulator’s guidance or ask a privacy lawyer.

A lawful basis for every use of data

Article 6 lists six lawful bases. Each purpose you use personal data for needs one of them, chosen before you start, and written down. Consent is not the default; for most of what an app does, another basis fits better.

Where you do rely on consent, Article 7 says people must be able to withdraw it at any time and that withdrawing must be as easy as giving it. In the product, that means unticked boxes, one purpose per choice, a record of what each person agreed to and when, and a settings screen where they can change their mind.

Health, biometric and other special categories of data under Article 9 need an extra condition on top of a lawful basis. If your app touches them, get legal advice before you build.

Privacy by design: what Article 25 means for engineering

Article 5 says personal data must be adequate, relevant and limited to what is necessary. Article 25 turns that into a design duty: build measures such as pseudonymization and data minimization into the product from the start, and make sure that by default only the data needed for each purpose is processed. That covers how much you collect, how far you process it, how long you keep it and who can see it.

• A data map: every table, field, file store, log and third-party service that holds personal data, with the purpose and lawful basis for each.
• Fewer fields. If the sign-up form asks for a date of birth or a phone number, write down why. If there is no reason, drop the field.
• Retention rules in code: scheduled jobs that delete or anonymize inactive accounts, old logs and expired records, not a policy nobody runs.
• Private by default: profiles, shared links and uploads start visible to the owner only.
• Access control in the admin panel, so staff see only the data their job needs. What is RBAC? explains roles and permissions.
• Encryption in transit and at rest, and pseudonymous IDs in analytics and logs instead of names and emails. Article 32 lists pseudonymization and encryption among the security measures to consider.
• Logs and error reports that leave out passwords, tokens and personal fields, and test data that is not a copy of production.

If you add AI features that process personal data, the same rules apply to the prompts, logs and files you send to a model provider, and the EU AI Act may add duties of its own; see Does the EU AI Act apply to my AI app?.

Consent, cookies and tracking

Cookies sit under a separate EU law, the ePrivacy Directive. Article 5(3) allows storing or reading information on a person’s device only with their consent, after clear and comprehensive information about the purposes. The exceptions are technical storage needed to carry a communication, and storage strictly necessary to provide a service the person explicitly asked for, such as a login session or a shopping cart.

The UK rules, in PECR, work the same way, with some extra exceptions added in 2025. The ICO’s guidance says that analytics used only to improve your own service, and settings that remember how a person wants the site to look, can be set without consent, as long as you explain them and give a simple, free way to object. Advertising, including ad measurement, still needs consent. The ICO also makes clear that the rules cover more than cookies: tracking pixels, link decoration, device fingerprinting and web storage are included.

• Load no analytics, ads or tracking tags until the person has agreed, unless an exception clearly applies.
• Make rejecting as easy as accepting, on the first screen, with no pre-ticked choices.
• Store each consent choice with a timestamp and the version of the text shown.
• Keep a link in the footer or settings to change the choice later.
• Show the banner and the privacy notice in the languages you serve. Multilingual websites covers translating the rest of the site.
• Mobile apps count too: SDKs that read device identifiers fall under the same rules.

User rights your product must support

People can ask what you hold about them and ask you to fix, export or delete it. Under Article 12 you must answer without undue delay and within one month, which can be extended by two further months for complex or numerous requests if you tell the person within the first month. Building the tools before launch is what makes those limits easy to meet.

Add an internal view for handling requests: who asked, how you checked their identity, what you did and when. The EDPB’s guide for small businesses suggests keeping a record of requests and your reasons, and you may ask for more information when you have reasonable doubts about who is asking.

Processors, DPAs and international transfers

Every vendor that handles personal data for you is a processor, and Article 28 requires a contract with each one, usually called a data processing agreement or DPA. It must say what the vendor may do with the data, require confidentiality and security, and cover deletion or return at the end. Most large vendors publish a standard DPA; keep a signed or accepted copy, and a list of your processors to show in your privacy notice.

Sending personal data outside the EU, or letting someone outside the EU access it, is a transfer, and it needs a legal route. The simplest is an adequacy decision: the Commission’s list includes the UK, Japan, Brazil, Switzerland, Canada for commercial organizations, and US companies that take part in the EU-US Data Privacy Framework. For other countries, contracts such as standard contractual clauses are the usual route. The UK has its own adequacy regulations and its own transfer agreement.

• Choose a hosting region on purpose and write it down.
• For each vendor, note where the data goes and which transfer route covers it.
• Remember people as well as servers: a support team or a development team abroad with access to production data is also a transfer.

Breaches, records and the paperwork behind the product

Under Article 33, a controller must report a personal data breach to its supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to put people at risk. Under Article 34, if the risk is high, the people affected must be told as well. You can only meet that if you can see a breach: audit logs, alerts on unusual access, and a short written plan of who does what. The web app security checklist covers the controls that make breaches less likely and easier to spot.

Article 30 asks for a record of processing activities: what you process, why, about whom, who receives it, where it goes and how long you keep it. Companies with fewer than 250 people are exempt only if their processing is occasional, unlikely to put people at risk and free of special categories of data; most apps process user data all the time, so plan to keep one. The data map from the design stage is most of it.

1. Map the personal data the app will collect, and the lawful basis for each purpose, before you design the screens.
2. Cut the fields you cannot justify, and set retention rules for the ones you keep.
3. Build consent, privacy settings, export, correction and account deletion into the first release.
4. Give the admin panel roles, audit logs and a view for handling requests.
5. Sign a DPA with every processor and record where each one stores data.
6. Write the privacy notice from the data map, so it matches what the code does.
7. Write a breach plan and keep the record of processing up to date as features change.

When BYD Tech builds a web app, the code lives in the client’s GitHub from day one, the founders are on the calls, and AI-assisted work is reviewed by an engineer. Web app development describes how a project starts.