GDPR for websites and apps: how to do it in practice

It often starts with a single email. A former customer writes and asks to have all their data deleted. The owner looks into it and finds the customer’s name in the booking system, the newsletter tool, the shared inbox where the contact form lands, the accounting software, an old spreadsheet and a recording from a heatmap tool that marketing installed three years ago. Nobody knows exactly which of these may be deleted and which must be kept. That is GDPR in real life: a question of overview.

This guide is about GDPR in the software you have built or already run: website, webshop, customer portal and app. We are developers and designers, so we focus on the practical and technical parts. The legal assessment of your specific processing belongs with a lawyer, and the guidance from Datatilsynet is a good place to start.

What does GDPR require of a website or app?

GDPR sets out a number of principles that all processing of personal data must follow. Translated into software, they mean you should be able to answer six questions for every type of data: Why do we collect it? What is the lawful basis? Do we need every field? How long do we keep it? Who has access, including at suppliers? And how do we protect it? If you can answer those, you are well on your way.

• Lawfulness and transparency: a lawful basis for each processing activity and a privacy policy that explains it in language customers understand.
• Purpose limitation: data collected for a booking is used for the booking. Using it for marketing requires its own basis.
• Data minimisation: ask only for what you need. A date of birth is rarely necessary for a newsletter.
• Storage limitation: fixed deletion deadlines built into the system, independent of someone remembering.
• Integrity and confidentiality: encryption, access control, logging and backups that match the risk.
• Accountability: you must be able to document that you comply, and that is where records and agreements come in.

How do you make a data map for your website?

A data map is the most important document you can make. Walk through the website and app page by page and write down where personal data comes in: forms, login, payments, chat, analytics, newsletter, job applications and integrations with other systems. For each, note where the data ends up and who processes it. The table below shows a typical extract from a service company with online booking.

Once the map is done, most people discover two things. There are more tools than anyone thought, and some of them are no longer used. The easiest GDPR measure you can take is to remove the scripts and integrations that create no value. Every extra supplier is an agreement to maintain and a possible route out for data.

Which suppliers need a data processing agreement?

Every supplier that processes personal data on your behalf. That is typically hosting, the operations supplier and a developer with access to production data, email provider, newsletter tool, CRM, support system, analytics tool, chat widget and payment solution where it is not itself a controller. Large SaaS providers have a standard agreement you accept in their terms. Smaller suppliers often need to be asked. The key content is instructions, security, confidentiality, use of sub-processors, transfers outside the EU, help with breaches and deletion or return of data when the relationship ends.

Where data is stored matters a great deal, because transfers to countries outside the EU and EEA require a specific legal basis. We go through the options in our guide to hosting data in the EU. The short advice is that EU hosting makes the agreements simpler, and that you should always know the list of sub-processors.

When do you need consent, and when not?

Many people think GDPR means consent for everything. Consent is one of six lawful bases, and for most core features of a website or app another basis is the right one. When a customer books an appointment, you process her address to fulfil the contract. When you keep an invoice, you do so because the law requires it. Consent is used where the customer genuinely can opt in and out without losing the service itself: newsletters, non-essential cookies, sharing with partners and similar.

Cookies have their own rules on top of GDPR, and there consent is the main rule for everything that is not strictly necessary. We cover that in our guide to cookie banner rules.

How do you handle access and deletion requests?

Users have the right to access their data, have it corrected, have it deleted when there is no longer a basis for keeping it, and in some cases receive it in a machine-readable format. As a rule you must respond within one month. In a solution with ten customers a year that can be handled manually. In an app with thousands of users it should be a feature. Apple also requires apps that offer account creation to let users delete their account inside the app, which we explain in our guide to App Store approval.

What about backups?

Backups are the question we hear most often. It is rarely practical to delete one person from an encrypted backup, and it is not what is normally done either. Instead, backups rotate with a fixed lifetime, for example 30 days, and if a backup is ever restored, the deletions are replayed. Describe this in the data processing agreement and in the privacy policy so it is transparent.

Logs, access and security: what does GDPR require technically?

GDPR requires security appropriate to the risk, and it must be built in from the start: privacy by design and by default. For a typical business solution that means encryption in transit and at rest, login with strong passwords or MitID and two-factor authentication for administrators, roles so staff only see what they need, logging of who viewed and changed data, and tested backups. Logs themselves need care: log events and IDs, and avoid writing names, CPR numbers or message content into them.

Our software security checklist goes into detail with 30 concrete checks. If you process sensitive data such as health information or CPR numbers, the requirements increase, and we then recommend a proper impact assessment with a lawyer involved from the start.

GDPR checklist for your website and app

1. Make a data map of every place personal data comes in.
2. Record purpose, lawful basis and retention for each type of data.
3. Remove form fields, scripts and tools you do not need.
4. Get data processing agreements from every supplier and store them in one place.
5. Check where data is stored and which sub-processors are used.
6. Write a privacy policy in plain language and link to it from every form.
7. Use consent only where it is the right basis, and make withdrawal just as easy.
8. Build automatic deletion after fixed deadlines into the system.
9. Make access and deletion a feature, or describe a manual procedure that can be completed within a month.
10. Turn on two-factor authentication for all administrators, and assign least-privilege roles.
11. Log access to personal data without writing personal data into the log.
12. Agree a data breach procedure with your supplier so the 72-hour deadline can be met.

What does it cost to make a solution GDPR-ready?

Built in from the start, the extra cost is small. Deletion after fixed deadlines, roles, logging and an export feature are typically a few days of work in a new solution. It gets expensive when it has to be retrofitted into a system where customer data is scattered across unstructured tables, or where nobody knows which integrations pass data on. A realistic example: a service company with 20 employees gets a new booking solution with customer login. The data map and privacy policy take a workshop of a couple of hours. Automatic deletion of inactive customers after a fixed period, a delete-account button and export of personal data are three of the features in the package, and the data processing agreement with the developer is signed together with the contract. None of it requires a separate GDPR project.

With us, security and backups are part of the fixed monthly plan, and you own both code and data, which makes it easy to document where everything lives. Read more about ownership in our guide who owns the code. If you are starting a new solution, describe it in a short request and we will send a fixed price within 24 hours with the GDPR features listed.

Which GDPR mistakes do we see most often in practice?

Contact forms that send everything to a shared inbox that is never cleaned up. Test environments with a copy of the real customer database that several developers can access. Former employees who still have admin access. Analytics and marketing scripts that load before the user has consented. And newsletter lists where nobody can document when and how people signed up. All five can be fixed in a day or two once someone owns the task. We recommend putting a yearly GDPR review in the calendar together with your supplier.