What is GDPR?

GDPR comes up in nearly every discussion about digital systems, but what the regulation actually requires isn’t always crystal clear for the people commissioning the work. Here’s what you need to know to ask the right questions and avoid expensive mistakes – without the legal jargon.

What GDPR is

GDPR (General Data Protection Regulation) is the EU’s shared law for how personal data may be handled. It applies across the entire union and to everyone processing data about people in the EU – regardless of where the company itself is based.

Put simply, the purpose is to give individuals control over their data and to force organizations to handle it responsibly. Instead of a patchwork of national rules, there’s now one shared framework, and it places concrete requirements on every system that touches personal data.

For a buyer, that means data protection isn’t something you tack on at the end, but a precondition that shapes how the system gets built.

Personal data is broader than you think

The most common misconception is that personal data is just about names and national ID numbers. In reality, the concept is much broader: personal data is any information that can be tied to an identifiable person.

It includes the obvious – name, address, national ID number – but also things many people forget:

• Email addresses and phone numbers.
• IP numbers and device IDs.
• Customer IDs and account numbers in your own systems.
• Location data and behavioral patterns.

Even details that seem harmless on their own can become personal data if, together, they point to someone. The rule of thumb is simple: if the information can be linked to a person, directly or indirectly, it falls under GDPR. That’s why most systems process personal data in practice, even when you don’t think so at first.

The roles: controller and processor

GDPR divides responsibility between two roles, and keeping them apart is central to every systems project.

The data controller is whoever decides why and how data should be processed. That’s usually you – the company that owns the customer relationship and makes the decisions about what’s collected and for what.

A data processor handles data on the controller’s behalf, according to the controller’s instructions. A cloud vendor that stores your data, or a systems partner that hosts your service, are typical processors. They don’t decide over the data – they handle it on your assignment, and the relationship is governed by an agreement (a data processing agreement).

The distinction determines who carries which responsibility when something goes wrong, and it should be sorted out before a system goes live.

What it requires of a systems project

Translated into practice, GDPR sets three main requirements that need to be built in, not patched on afterward.

Lawful basis means you must have a valid reason for every instance of processing – you can’t collect data just because it’s convenient. Data minimization means the system should only ask for what’s actually needed; every extra field is a risk and a liability. Deletion requires that data can be purged and removed, which has to be part of the design from the start.

Breaking the rules can bring substantial penalties – serious violations can result in fines in the millions, on top of the reputational damage.

How to put this to use

You don’t need to become a lawyer, but you do need to ask the right questions early. Which personal data will the system handle, and why? What lawful basis does it rest on? How is the data protected and purged? Who is the controller and who is the processor?

Raising this already at the requirements stage is both cheaper and safer than patching it in later. If you’d like help building real data protection in from the start, at Weapp we’re happy to be part of that systems work from the very first sketch.