If you are building a small web app or SaaS with users in Europe, GDPR for web apps is not optional, but it is less mysterious than its reputation. For a small product it comes down to a few decisions and a few features to build before launch. This guide walks through them with article numbers, so you can check the text yourself.
This is general information, not legal advice. If your app handles health data, children's data or other sensitive data, talk to a lawyer.
Does the GDPR apply to your web app?
Probably. Under Article 3, the regulation applies to processing "in the context of the activities of an establishment of a controller or a processor in the Union, regardless of whether the processing takes place in the Union or not." It also reaches businesses outside the EU when they offer goods or services to people in the Union, "irrespective of whether a payment of the data subject is required", or when they monitor those people's behaviour.
So a free app is covered just like a paid one, and a developer outside Europe who targets European users can fall under Article 3(2).
Norway is not in the EU, but Datatilsynet, the Norwegian data protection authority, explains that the GDPR was incorporated into the EEA Agreement and became applicable in Norway on 20 July 2018, and that Norway "is thus bound by the GDPR in the same manner as EU Member States."
Being small does not exempt you. The European Commission's explainer is blunt: "If a company is a small and medium-sized enterprise (SME) processing personal data, it must comply with the GDPR." Some obligations are relaxed where processing is not core to the business, but for a web app it usually is.
What counts as personal data in an app
Article 4(1) defines personal data as any information relating to an identified or identifiable person, and lists "an online identifier" alongside names and location data. In a typical app that covers:
- names and email addresses on accounts
- IP addresses in server and access logs
- user IDs, session identifiers and device identifiers
- anything users enter about themselves: profile fields, uploads, support messages
- analytics events tied to a user or a device
"Processing" in Article 4(2) covers nearly any operation on that data, from collection to erasure. A users table means you are processing personal data.
The Commission also notes that data which has been "de-identified, encrypted or pseudonymised but can be used to re-identify a person remains personal data". Only irreversible anonymisation takes data out of scope. Hashing an email address does not.
Controller or processor: know your role
Under Article 4(7), the controller decides the purposes and means of processing: for your own app, you. The companies that host your database, send your email or run payments on your instructions are usually processors under Article 4(8).
Article 28(3) requires processing by a processor to be "governed by a contract or other legal act", which among other things binds the processor to your documented instructions and to confidentiality. That is why many providers offer a standard data processing agreement. List every vendor that touches user data, file each agreement, and reuse the list in your privacy policy.
Pick a lawful basis for each purpose
Article 6(1) says processing is lawful "only if and to the extent that at least one of the following applies", then lists six bases. Four of them cover almost everything a small app does:
| What your app does | Basis that usually fits | Where |
|---|---|---|
| Create the account, store user content, deliver the service | Necessary for a contract with the user | Article 6(1)(b) |
| Keep invoices and accounting records | Legal obligation | Article 6(1)(c) |
| Security logging, abuse and fraud prevention | Legitimate interests | Article 6(1)(f), Recital 49 |
| Newsletters, optional analytics, ad tracking | Consent | Article 6(1)(a) |
Recital 49 states that processing "strictly necessary and proportionate" for network and information security is a legitimate interest, and Recital 47 says the same of processing strictly necessary for preventing fraud. Legitimate interests always involve a balancing test, though: the basis fails where your interests are "overridden by the interests or fundamental rights and freedoms of the data subject".
Decide per purpose, because each basis carries different rules. Consent must be "freely given, specific, informed and unambiguous" (Article 4(11)), and Article 7(3) adds: "It shall be as easy to withdraw as to give consent." Use consent only where the user genuinely has a choice. Article 7(4) also warns against making a service conditional on consent to processing it does not need, such as a sign-up form that forces acceptance of marketing email.
Turn the principles into build decisions
Article 5 sets out the principles. Each one maps to something you can build or decide:
- Lawfulness, fairness and transparency. Have a lawful basis and publish a privacy policy that tells the truth. Our guide on what a privacy policy for an app must include covers the contents.
- Purpose limitation. Data collected to log someone in is not automatically available for marketing.
- Data minimisation. Collect only what is "adequate, relevant and limited to what is necessary". If you never use a phone number, do not ask for one.
- Accuracy. Let users edit their own details.
- Storage limitation. Decide how long each kind of data lives, then delete it on schedule. Inactive accounts, old logs and orphaned uploads are the usual leftovers.
- Integrity and confidentiality. Security appropriate to the risk, covered below.
Article 5(2) makes the controller "responsible for, and be able to demonstrate compliance with" all of the above. Article 25 adds that, by default, only data "necessary for each specific purpose" should be processed.
Build user rights into the product
Articles 15 to 22 give people rights over their data. The ones small apps actually receive are:
- access to their data (Article 15)
- correction of inaccurate data (Article 16)
- erasure (Article 17)
- a copy in a "structured, commonly used and machine-readable format" where portability applies (Article 20)
- objection to processing based on legitimate interests (Article 21)
Article 12(3) gives you one month to act on a request, extendable by two further months for complex or numerous requests. The cheapest way to comply is to build the features: edit details in settings, export to JSON or CSV, and a delete-account button that removes rows and stored files. Remember copies outside your database, such as your email provider's contact list.
Security and breach response
Article 32 requires security "appropriate to the risk" and names examples such as pseudonymisation, encryption and the ability to restore data after an incident. For a small app the baseline is HTTPS, a managed auth provider or properly hashed passwords, access control between users, secrets out of the repository, and tested backups. The pre-launch checklist for generated code shows how to test the access-control part with two real accounts.
If something goes wrong, Article 33 requires you to notify the supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware of it", unless the breach is unlikely to result in a risk to people. Article 34 adds telling affected users directly when the risk is high. Decide now who makes that call.
Paperwork: what you need and what you probably do not
Records of processing. Article 30 requires a written record of your processing: purposes, categories of people and data, recipients, transfers, planned erasure time limits and a description of security measures. Article 30(5) exempts organisations with fewer than 250 employees, but not where the processing "is not occasional", is likely to result in a risk, or involves special categories of data. An app processing user data daily is hard to call occasional, and a spreadsheet is cheap, so keep one.
Data protection officer. Article 37 requires one for public bodies and where core activities involve "regular and systematic monitoring of data subjects on a large scale" or large-scale special-category data. Most small apps need none.
EU representative. If you are outside the EU and Article 3(2) applies, Article 27 requires you to designate a representative in the Union in writing. The exemption in Article 27(2) covers only processing that is occasional, excludes large-scale special-category data and is unlikely to result in a risk.
Cookies are a separate rule
Analytics scripts, pixels and anything else that stores or reads information on a device also fall under the ePrivacy rules, covered in our guide to cookie consent banners.
What is at stake
Article 83(5) sets the upper tier of fines at "up to 20 000 000 EUR, or in the case of an undertaking, up to 4 % of the total worldwide annual turnover of the preceding financial year, whichever is higher" for breaches of the principles, the conditions for consent and the data subject rights. Those are maximums, not typical amounts.
GDPR for web apps: the short version
- List every kind of personal data you collect, why, and on which Article 6 basis.
- List every vendor that touches that data and file their data processing agreements.
- Collect less, set retention periods and delete on schedule.
- Ship edit, export and delete-account features before launch.
- Test access control with two accounts.
- Write a one-page breach plan and a simple record of processing.
- Publish a privacy policy that matches all of the above.
