Commissioning software or a client portal: what does the GDPR require?

Who is responsible: you or your developer?

The GDPR distinguishes between the controller and the processor. You decide why and how customer data is used, so you are the controller. That stays true when someone else builds or hosts the software.

Your developer becomes a processor as soon as they process personal data on your behalf: hosting, maintenance and support, or working with real customer data during the build. For that situation, Article 28 of the GDPR requires a data processing agreement.

A party that only writes the code and never touches real data is not a processor. In practice that is rare: whoever hosts, maintains or helps during an outage sees data sooner or later.

What belongs in the data processing agreement?

Article 28 sets a minimum. Check that it covers:

• Which data, about whom, for what purpose and for how long.
• That the processor acts only on your documented instructions.
• That the processor's staff are bound by confidentiality.
• Which security measures the processor takes.
• Which sub-processors are involved, such as hosting, email or storage, and that you approve new ones.
• That the processor helps with requests from data subjects and with data breaches.
• What happens to the data when the contract ends: returned or deleted.
• That you may check whether the agreements are being kept.

Also ask where the data is stored. If it sits outside the EU, or a US service is involved, that transfer needs its own legal basis. The EU-US Data Privacy Framework survived a challenge at the EU General Court in September 2025, but an appeal is pending. Hosting inside the EU removes that risk.

Privacy by design: requirements to put in your brief

Article 25 calls for data protection by design and by default. That sounds abstract, but it translates into concrete features. Put these in your requirements and you can compare quotes fairly too:

You have one month to respond to a request for access or erasure. If that means searching tables by hand, every request is work all over again. A button in the admin saves you that.

Test and development data

An often forgotten point: what does your developer test with? A copy of your real customer list in a test environment is processing too, often with weaker security than production.

Agree that work is done with made-up or anonymised test data. If real data does need to be looked at, during an outage for example, record who may do so and make sure it is logged.

Do you need a DPIA?

A DPIA is a risk assessment done up front. Article 35 makes it mandatory when processing is likely to result in a high risk. The Dutch Data Protection Authority keeps a list of 17 types of processing that always require one, such as large-scale profiling, camera surveillance and processing health data on a large scale.

An ordinary client portal for quotes, appointments and invoices is usually not on that list. If you process health data, track people's behaviour or combine large amounts of data, it may well be required. When in doubt, do a short DPIA. It makes you put the risks on paper, and the software gets better for it.

The record of processing activities

Article 30 requires a record of processing activities. Organisations with fewer than 250 employees are exempt, but not when processing is more than occasional. You use a client portal or CRM every day, so in practice you need that record. Add the new software to it when it goes live.

When things go wrong: data breaches

In 2025 the Dutch Data Protection Authority received 39,407 data breach notifications, more than the year before. A breach must be reported without undue delay and, where feasible, within 72 hours. If the risk is high, you also inform the people affected. Every breach, including ones you don't report, is recorded internally.

72 hours is short. So agree with your developer in advance who spots a breach, who calls you, and what information you get: which data, how many people, and since when. Good logging makes the difference between 'we don't know' and a precise report.

Fines show that access control is no formality. HagaZiekenhuis, a Dutch hospital, was fined €460,000 in 2019 because staff could look into patient records too easily and this was not properly monitored. The Dutch Ministry of Foreign Affairs was fined €565,000 in 2022 for a poorly secured visa system.

Larger organisations: NIS2 and the Dutch Cybersecurity Act

Since 15 August 2026 the Netherlands has applied the Cyberbeveiligingswet, its implementation of the EU NIS2 directive. Organisations in 18 sectors must check for themselves whether they are covered. Those that are must also look after security in their supply chain, including their software suppliers.

A software developer is usually not covered directly, but receives the requirements through its client's contract. If you work for or at such an organisation, ask up front which requirements apply to secure development, access, logging and incident reporting.

Checklist for your conversation with a developer

1. Who hosts the software, and where is the data stored?
2. Which sub-processors do you use, and in which country are they based?
3. How are permissions set up: could a customer ever reach another customer's data?
4. Is it logged who views or changes which data?
5. How does login work, and is there two-factor authentication for admins?
6. What do you test with: real or made-up data?
7. How often are backups made, and has restoring been tested?
8. Can I export and delete one person's data?
9. Who spots a data breach, and how quickly will I hear about it?
10. What do I get if we part ways: code, data and documentation?

If you don't get concrete answers to these questions, that is an answer too. Also read custom vs off-the-shelf software on ownership and exit, and what maintenance costs once the software is running.

How Vorteca approaches it

For portals and systems with customer data we start with permissions, not with screens. Who can see what is enforced in the database itself: even if something goes wrong in the interface, a customer only gets their own data back.

Invitation and reset links are single-use and expire. We store only a hashed version, not the link itself. Admin actions stay admin-only, and secret keys never end up in code that runs in the browser.

The client portal article covers what such a portal costs and how long the build takes.

What does a secure portal cost at Vorteca?

Vorteca Core covers hosting, monitoring, security and technical maintenance. See portals or all packages on the pricing page.