GDPR: what it is and who it applies to

The GDPR is the European Union's data protection regulation. It applies to organisations established in the EU, and also to organisations outside the EU that process personal data of people in the EU when offering them goods or services or monitoring their behaviour there. It sets duties for controllers and processors.

Where does the scope come from?

Article 3 sets out three cases.

First, an organisation with an establishment in the EU. The regulation covers processing connected to the activities of that establishment, even if the processing itself happens outside the EU.

Second, an organisation without an EU establishment. The GDPR can still apply if it processes personal data of people who are in the EU and the processing relates to offering goods or services to them, whether or not they pay, or to monitoring their behaviour as far as it takes place in the EU.

Third, a controller located somewhere that a Member State's law applies under public international law.

So a company in the United States with no office in Europe can be in scope if it sells to people in the EU or tracks their behaviour. The test is about the people, not the location of your servers.

Who is a controller and who is a processor?

A controller decides why and how personal data is processed. A processor handles data on a controller's behalf. A software vendor that stores customer data for its clients is usually a processor for that data and a controller for its own staff and marketing data. Both roles have security duties.

What does it ask for on security?

Article 32 requires controllers and processors to apply technical and organisational measures that give a level of security appropriate to the risk. It names examples: pseudonymising and encrypting personal data, keeping systems confidential, intact, available and resilient, restoring access promptly after an incident, and regularly testing how well measures work.

It lists what to weigh: the state of technology, implementation cost, the nature and purposes of processing, and the risk to people's rights and freedoms. Following an approved code of conduct or certification mechanism can help demonstrate compliance.

That wording is deliberate. There is no fixed checklist; the measures must fit the risk. For a software team, that makes your engineering records the proof: how you patch, how you control access, how you test.

What about breach notification?

Article 33 covers notifying the supervisory authority of a personal data breach. We could not retrieve its text for this review, so read it in the regulation and check your deadlines with your data protection officer or counsel.

Where does software supply chain work fit?

The regulation says measures must be appropriate to the risk, and vulnerable components in a system that holds personal data are a risk you can name and measure. Keeping an inventory of your dependencies, fixing exploited vulnerabilities quickly and scanning for leaked secrets are the kinds of measures you can point to. Safeguard supports that evidence trail. It does not make you GDPR compliant, and no tool can, because the regulation is about how you handle data, not only which software you run.

What to do

1. Work out whether you have an EU establishment or serve or monitor people in the EU.
2. Map what personal data you hold, where it lives and who processes it.
3. Decide for each data set whether you are a controller or processor.
4. Write down the measures you apply to protect it, tied to the risk.
5. Keep dated evidence of patching, access reviews and testing.
6. Review contracts with processors and sub-processors.
7. Agree a breach response plan and read Article 33 with counsel.

Quick check

Sources

• GDPR Article 3, territorial scope
• GDPR Article 32, security of processing

Last reviewed: 18 October 2026.