GDPR compliance,
explained plainly

The most misunderstood part of the GDPR is its reach. It does not only apply to companies based in the EU. It applies to any organization, anywhere in the world, that processes the personal data of people who are in the EU or EEA — whether to offer them goods or services, or to monitor their behaviour. This is what lawyers call its extraterritorial scope, and it is why so many Swiss, UK and US companies fall under it without having a single office in the bloc.

For a Swiss company, this is the common case. If you sell to customers in Germany, run a website that signs up users in France, or process data on behalf of an EU client, you are very likely in scope — Swiss borders do not put you outside the regulation. The test is about whose data you handle and who you are reaching, not where your servers or your headquarters sit.

If you are weighing whether the GDPR applies to you, the practical question is simple: do you handle personal data about people who are in the EU or EEA? If the answer is yes, you should assume you are in scope and work from there, rather than hoping a geographic technicality lets you off.

Before the detailed obligations, the GDPR sets out a handful of principles that everything else flows from. You should handle personal data lawfully, fairly and transparently. You should collect it only for specified, explicit purposes and not quietly repurpose it later. You should collect only what you actually need, keep it accurate, and not hold on to it longer than necessary. And you should keep it secure — protected against loss, unauthorised access and misuse.

The last principle is the one that gives the regulation its teeth: accountability. It is not enough to follow the other principles — you have to be able to demonstrate that you follow them. That single word is why GDPR compliance is, in practice, mostly a documentation and evidence exercise: the records you keep are how you prove the principles are being met.

Under the GDPR you cannot use personal data just because it would be convenient. Every distinct use of personal data needs a lawful basis, and there are exactly six to choose from: consent, performance of a contract, compliance with a legal obligation, protection of someone’s vital interests, a task carried out in the public interest, and legitimate interests.

Choosing the right basis matters because it shapes what else you have to do. If you rely on consent, it has to be freely given, specific and as easy to withdraw as it was to give — and people can withdraw it. If you rely on legitimate interests, you have to be able to show you weighed your interest against the rights of the people involved and came out the right side of that balance. The wrong basis, or a basis chosen after the fact, is a common finding when things go wrong.

The discipline the law expects is to decide the basis before you start processing, write it down, and use it consistently. In practice that means each processing activity in your records carries a stated lawful basis — which is exactly the kind of thing your records of processing activities are there to capture.

The GDPR gives people a set of rights over their own personal data, and the duty to honour them sits with you. People can ask for access to the data you hold about them, have inaccurate data corrected, and, in many cases, have their data erased, the so-called right to be forgotten. They can ask you to restrict how their data is used, to provide it in a portable form they can take elsewhere, and to object to certain uses such as direct marketing.

There are also rights around decisions made about people by automated means alone — if a purely automated process has a significant effect on someone, they have rights to understand it and, in many cases, to ask for human involvement.

What this means operationally is that you need a reliable way to receive these requests, find all the relevant data across your systems, and respond — usually within one month. Teams that have no map of where personal data lives discover, the first time a real request arrives, that simply finding everything about one person is the hard part. A current record of what you hold and where turns a stressful scramble into a routine task.

The GDPR splits the organizations that handle personal data into two roles, and your obligations depend on which one you are. A controller decides why and how personal data is processed — it is your data, your purpose. A processor handles personal data on a controller’s behalf and under its instructions, such as a SaaS vendor running a service for its customers. Many companies are both at once: a controller for their own employee and customer data, and a processor for the data their clients put into their product.

Where a controller uses a processor, the GDPR requires a written contract between them — a data processing agreement (DPA) under Article 28. The DPA sets out what the processor may and may not do with the data, the security it must maintain, how it handles sub-processors, and what happens when the relationship ends. If you sell software to EU customers, your customers will ask you to sign one as the processor; if you use vendors that touch your personal data, you should have one with each of them as the controller.

Getting the role right is foundational, because it determines who is responsible for what — including who has to answer to a supervisory authority, and who carries which part of the breach-notification duty.

Because accountability is the whole game, the GDPR names specific records you are expected to keep. The first is your records of processing activities — the RoPA, under Article 30. It is a structured inventory of what personal data you process, why, on what lawful basis, who you share it with, where it goes, and how long you keep it. It is, in practice, the master map of your data processing, and it is usually the first thing a supervisory authority asks to see.

The second is the data protection impact assessment, the DPIA, under Article 35. When a particular kind of processing is likely to result in a high risk to people (large-scale profiling, systematic monitoring, sensitive data at scale) you are required to assess that risk before you start, document how you will mitigate it, and in some cases consult your supervisory authority. A DPIA is not paperwork for its own sake; it is the structured think-before-you-build step the law expects for the riskiest things you do.

Both records share a failure mode: they drift. A RoPA written once and never touched stops matching reality the moment you add a new tool or a new data flow, and a DPIA filed and forgotten gives you no protection if the processing it covered has since changed. Keeping them current, and linked to the actual systems and decisions they describe, is most of what living up to accountability really means.

When a personal-data breach happens (data lost, stolen, exposed or accessed by the wrong people) the GDPR puts you on a clock. Where the breach is likely to risk people’s rights and freedoms, you must notify your supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it. If the risk to the people affected is high, you also have to tell them directly, in plain language.

Seventy-two hours is short, and the clock starts when you become aware, not when you have finished investigating. That is precisely why a breach response works far better when it is prepared in advance than improvised under pressure: knowing who decides, what gets assessed, and where the contact details and templates live is the difference between a controlled notification and a missed deadline. Notably, not every breach has to be reported, since the duty turns on the risk to people, but you are expected to assess and record that judgement either way, even for breaches you decide not to report.

Because there is no GDPR certificate to wave, the question customers and authorities actually ask is "show me". Showing means producing evidence: your RoPA, your lawful-basis decisions, your processor agreements, your DPIAs for high-risk processing, your breach log, your privacy notices, and the records that prove you handle data subject requests on time. Accountability is not an attitude — it is a folder of current, consistent documents you can open on request.

This is where many teams quietly struggle. The obligations are spread across legal, product, security and operations, and the evidence ends up scattered across drives, inboxes and spreadsheets that drift apart over time. When a customer’s due-diligence questionnaire or a supervisory query lands, reconstructing a coherent picture from those fragments is the expensive part — not the underlying practices, which are often fine.

Keeping the accountability records in one place, current and linked to the systems and policies they describe, turns "show me your GDPR compliance" from a fire drill into a routine export. That is the same discipline that makes the rest of the regulation manageable: less a project you finish than a system you keep running.

For Swiss companies, the GDPR rarely arrives alone. Switzerland has its own modernised data protection law (the new Federal Act on Data Protection, the Swiss nFADP, in force since September 2023) and the two were deliberately brought close together. The nFADP raised Swiss rules to a standard broadly aligned with European expectations, which is part of why Switzerland continues to be recognised as offering an adequate level of protection for data flowing from the EU.

The two are not identical, so you cannot simply treat one as a copy of the other. But they overlap heavily: both turn on lawful processing, transparency, data subject rights, records of processing and breach handling. In practice a Swiss company serving EU customers needs to satisfy both at once — and because so much of the underlying work is shared, the sensible approach is to maintain it once and map it to each law, rather than running two disconnected compliance efforts side by side.

The GDPR is backed by fines large enough to change behaviour. For the most serious infringements, supervisory authorities can impose penalties of up to 20 million euros, or 4% of an organization’s total worldwide annual turnover, whichever is higher. A second, lower tier covers less severe breaches. The headline number is deliberately tied to global turnover so that it bites large organizations as hard as small ones.

Fines, though, are usually not the first cost teams feel. Lost or stalled deals are. Enterprise and public-sector buyers increasingly ask for evidence of GDPR compliance before they will sign, and a vague or missing answer slows the sale long before any regulator gets involved. Reputational damage from a mishandled breach can outlast any fine. The reassuring side of this is that the work that protects you from all three (clear records, honoured rights, a prepared breach response) is the same work, done once and kept current.