Guide

Custom software and data protection: what GDPR requires

As soon as custom software processes personal data, clear obligations apply. What these are specifically, what is almost always missing in practice, and what is actually sufficient.

Request assessment ↗Custom software

Quote on requestfrom 8 weeks to first versionAs of 2026

In short

As soon as custom software processes personal data, you need a legal basis, purpose limitation, defined deletion periods, information for data subjects, and a data processing agreement with each involved service provider. In practice, the same three points are almost always missing: the deletion period, the notice at the point of collection, and clarification of whether the provider uses the data for its own training.

01 — Data Protection

What GDPR requires

As soon as personal data is processed — and that happens faster than expected, for instance as soon as someone enters a name or phone number — the usual obligations apply: name the legal basis, define the purpose, maintain data minimization, define retention periods, inform data subjects.

In practice, this means for custom software: a data processing agreement with each involved service provider, verification of where processing takes place, a documented deletion period, and a clear passage in the privacy policy. Three things are almost always missing in practice: the defined deletion period, the notice at the point where data is collected, and clarification of whether the provider uses the data for its own training.

A data protection impact assessment is only required when there's likely high risk — not for most projects of this type. The review itself should still be documented so that if questions arise, it's clear why it was omitted.

02 — Contract

What needs to be clarified in writing

Ownership of data and access. They belong to the client. If a provider won't clearly confirm this, that's the most important information from the conversation.
Handover upon termination. In what format, within what timeframe, at what cost.
No minimum term without consideration. Lock-in is justifiable if something is delivered in return — otherwise not.
What a later change costs. The total cost isn't determined by the project price, but by the hourly rate in year three.
Documentation as a deliverable. Not as a promise, but as a line item in the proposal.

03 — Risks

What can go wrong

The system answers incorrectly. Containable by having it work exclusively from verified content and escalate when uncertain rather than guess. This is a configuration decision, not a property of the technology.
The effort is underestimated. Most common reason: unclear starting situation. An honest assessment of the current state before the proposal prevents this more reliably than any buffer.
No one maintains it. The biggest risk of all — and the most easily avoidable.
Data protection gaps. Almost always arise from missing deletion deadlines and unclear responsibility, rarely from the technology itself.
Vendor lock-in. Avoidable if access credentials, data, and documentation contractually remain with the client.

04 — Questions

Frequently asked questions

How do we avoid the project going off the rails?

Small steps with usable results, fixed budgets per step, and the option to exit after each step. Large fixed-price projects over twelve months are the most reliable path to disappointment — for both sides.

Can we start with a spreadsheet?

Often yes, and that's a good test. If the spreadsheet maps the process and only fails due to multi-user capability, permissions, or data volume, the requirement is clear and the project is calculable.

Who owns the source code?

You do, completely, upon payment. That's in the contract. You can take it to any other developer — that's the point.

What if we discover new requirements during development?

That's normal and planned for, because we work in small steps. A new requirement is incorporated into the next step, instead of stalling the entire project.

How many users can a system like this handle?

That depends on the architecture, which we plan according to your expected growth — from a few users in your own business to several hundred across multiple locations.

When does custom software pay off compared to standard software?

When your process is a genuine competitive advantage, when standard software only fits seventy percent and the rest ends up as manual work, or when license costs per user exceed the development cost over a few years. If it's only about convenience, standard software is cheaper.

Does this run on our own servers or in the cloud?

Both are possible. For most businesses, a cloud solution is lower-maintenance; where data must not leave the premises, we set it up on your own infrastructure.

05 — Next

Custom software by region

Next step

Send us a few sentences about your project.

We read every inquiry ourselves and respond personally. No sales team, no callback form into the void.

Send inquiry ↗ office@pipeline-solutions.at OR +43 681 207 64 203