GDPR checklist for a business application

A GDPR-ready business application is designed that way from the requirements stage, not fixed after launch. It collects only the data needed for a written purpose, sets a retention period for each type of data, lets people exercise their rights, restricts access by role and logs sensitive operations. And the contract with your developer must include the processor terms required by Article 28.

This checklist is for companies commissioning an internal tool or a client portal that handles personal data of people in the European Union. It follows the text of the regulation and the developer guidance published by France's data protection authority, the CNIL's GDPR guide for developers (in French, also on GitHub). It is not legal advice: for sensitive processing, involve your data protection officer (DPO) or a lawyer.

Why GDPR is a design question

Article 25 of Regulation (EU) 2016/679 requires data protection by design and by default. The controller must build appropriate technical and organisational measures into the processing from the moment its means are decided, and by default process only the data necessary for each purpose.

In practice, a choice made on a prototype screen (a mandatory date of birth field, a history kept forever, an export button open to every user) is a compliance decision. Fixing it after launch means data clean-up and extra development; getting it right during scoping costs almost nothing.

One distinction matters from the start. Your company decides why and how the data is processed, so you are the controller. The agency or studio that builds, hosts or maintains the application is usually a processor. You cannot hand off responsibility for compliance entirely, even though your vendor must help you meet it.

If your users are in the United Kingdom, the UK has kept its own version of the rules, the UK GDPR, supervised by the Information Commissioner's Office. The principles below are the same in substance.

The checklist, principle by principle

The principles in Article 5 translate fairly directly into software requirements.

Purpose and lawful basis. Every processing activity needs an explicit purpose and a lawful basis: contract, legal obligation, legitimate interests or consent, among others. For internal tools it is usually the employment contract or legitimate interests. Consent is rarely the right basis between an employer and its staff, because it is hard to show it was freely given.

Data minimisation. Every form field must earn its place. A technician's personal phone number, a customer photo, a contact's date of birth: if the tool works without it, do not ask for it. Less data also means less damage if something leaks.

Retention. This is the requirement most often forgotten. An application that keeps everything forever does not comply. Set a period for each category (inactive customer records, job files, login logs) and have the software enforce it through deletion, archiving or anonymisation.

Data subject rights. Access, rectification, erasure, objection and portability: the application should let an administrator find all data about one person, export it and delete it without calling a developer. A per-person export and a deletion routine that also removes attached files cover most requests.

Transparency. People must know what is processed, why, for how long and by whom. In a client portal, that means a privacy notice reachable from the app; for an internal tool, a notice to employees.

Security proportionate to the risk

Article 32 asks for security "appropriate to the risk" and lists, among other measures, pseudonymisation and encryption, the ability to ensure confidentiality, integrity and availability, the ability to restore access to data after an incident, and regular testing of the measures. For a business application, the baseline is well known:

• strong authentication, with two-factor login for admin accounts;
• role-based access: sales staff do not see payroll, a subcontractor sees only their own jobs;
• encryption in transit (HTTPS) and of backups;
• logging of access and of sensitive exports;
• tested backups, with a restore that has actually been tried;
• dependency updates as part of ongoing maintenance.

We cover this in more depth in business application security: the essentials.

After a personal data breach, Article 33 requires the controller to notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to people. The application must therefore keep logs that show what happened, and the contract must oblige your vendor to alert you without delay.

Records of processing and impact assessments

The record of processing activities (Article 30) lists your processing, its purposes, the categories of data and people, the recipients and the retention periods. Organisations with fewer than 250 employees are exempt, except when the processing is likely to result in a risk, is not occasional, or involves special category or criminal offence data. The CNIL notes on its page about the record that payroll and customer management are non-occasional processing, which makes the exemption narrow. A new business application will almost always go into the record.

A data protection impact assessment (DPIA, Article 35) is required only when processing is likely to result in a high risk: systematic and extensive evaluation of people including profiling, large-scale processing of sensitive data, or large-scale monitoring of a publicly accessible area. Continuous location tracking of staff or health data deserve a check with your DPO.

What the processor contract must say

As soon as your vendor handles personal data for you, Article 28 requires a written contract. Among other things, it must provide that the vendor:

• processes the data only on your documented instructions, including for transfers outside the EU;
• binds its staff to confidentiality;
• applies the security measures of Article 32;
• uses another processor (a hosting provider, an email service) only with your written authorisation, and tells you about changes;
• helps you answer data subject requests and handle breaches;
• deletes or returns the data, at your choice, when the service ends;
• gives you the information needed to demonstrate compliance and allows audits.

These terms sit alongside the rest of the development contract (scope, acceptance, ownership, exit), covered in software development contract: the clauses to check. Hosting location and transfers outside Europe are covered in where to host a business application in Europe.

The most common mistakes

• Copying the production database to a developer laptop. Test with fictitious or pseudonymised data.
• Unrestricted spreadsheet exports. An export open to everyone cancels out role-based access. Limit it and log it.
• Forgetting attachments. Deleting a record but keeping its files means keeping the data.
• Piling up third-party tools. Every added service (analytics, support chat, email delivery) is another processor to authorise and document.
• No documentation. Without a record and a description of your measures, you cannot demonstrate compliance, which Article 5 requires.

The stakes are real: the most serious infringements can lead to fines of up to 20 million euros or 4% of total worldwide annual turnover, whichever is higher (Article 83). For a small company, though, the first benefit is practical: an application that keeps only what it needs is easier to secure and to maintain.

Where to start

List the personal data the tool will handle, with the purpose and retention period of each item, before writing a single feature. At LPR Studio, these questions come up during scoping (see our approach): the free prototype, presented in a video call within 5 working days, already shows the screens, fields and user roles, and therefore who will see what. That is the right moment to review it with your DPO.