← Glossary

Regulation & Compliance

GDPR (General Data Protection Regulation)

Also: General Data Protection Regulation · Regulation (EU) 2016/679 · RGPD · DSGVO · personal data breach · pseudonymisation

Last reviewed: — regulation changes; check the primary source below before relying on a date or a threshold.

In one sentence

The GDPR is the EU regulation, in force since 25 May 2018, that governs any processing of personal data — including the IP addresses, usernames and e-mail addresses in your logs — and requires security "appropriate to the risk" plus breach notification within 72 hours.

Why it matters to security people

Most GDPR guidance is written for lawyers and marketers. For a SOC or an engineer three articles do the work:

  • Article 32 — security of processing. Controllers and processors must implement "appropriate technical and organisational measures", explicitly naming pseudonymisation, encryption, confidentiality/integrity/availability/resilience, restoration after an incident and regular testing. This is the legal hook for every hardening decision you make.
  • Article 33 — breach notification. A personal data breach (loss of confidentiality, integrity or availability — a ransomware encryption counts even with no exfiltration) must be notified to the supervisory authority within 72 hours of becoming aware, unless it is unlikely to result in a risk to people. Article 34 adds notifying the affected individuals when the risk is high.
  • Article 4(1) — what "personal data" means. Anything relating to an identifiable person. The Court of Justice confirmed (Breyer, C-582/14) that a dynamic IP address is personal data for a party that can plausibly obtain the identity. So your web logs, your firewall logs and the pastebin you share with a vendor are all processing.

Fines run to €20 m or 4 % of worldwide turnover, but the day-to-day cost is smaller and constant: every log you export, every incident you write up and every threat-intel feed you subscribe to needs a lawful basis and a data-minimisation reflex.

The concepts you will actually use

Controller vs processor. The controller decides why and how; the processor acts on instructions (your cloud provider, your MSSP). Both have security duties; the processor must notify the controller of a breach "without undue delay" so the controller can make the 72 hours.

Pseudonymisation vs anonymisation. Pseudonymised data (a hash of the user ID, an IP with the last octet zeroed but a lookup table kept) is still personal data — the GDPR applies, but Article 32 explicitly counts pseudonymisation as a security measure and Article 34 may excuse individual notification if the leaked data was unintelligible. Anonymised data, where re-identification is no longer reasonably possible, falls outside the Regulation entirely. Most "anonymised" logs are in fact pseudonymised.

Legitimate interest for security. Recital 49 says processing "to the extent strictly necessary" for network and information security is a legitimate interest — the basis for running an IDS, retaining logs, or sharing indicators. "Strictly necessary" is the constraint: retention periods and sharing scope must be justified.

Data protection by design (Article 25) and the DPIA (Article 35) for high-risk processing — large-scale monitoring of employees or customers qualifies, which includes an ambitious SIEM deployment.

Try it yourself hands-on

A vendor's support engineer asks for "the last hour of proxy logs" to debug an outage. The log contains client IPs, usernames and a session token. Sending it as-is is a disclosure of personal data to a third party with no basis; refusing blocks the fix. The GDPR-compliant middle is pseudonymisation.

  1. Paste the excerpt into the Log Redactor: 
    2026-09-18T14:02:11Z 203.0.113.42 jdoe@example.com GET /portal/export sid=9f3c2a7e4b… 502
2026-09-18T14:02:12Z 203.0.113.42 jdoe@example.com GET /portal/export sid=9f3c2a7e4b… 502
2026-09-18T14:02:14Z 198.51.100.7  m.rossi@example.com GET /portal/export 502
  2. Enable the IP, e-mail and session-token rules and pick the Full Anonymization IP mode. Replacement is consistent: 203.0.113.42 becomes the same documentation-range address (192.0.2.1) on every line and jdoe@example.com becomes user_01@redacted.tld, so the engineer can still see that one client hit the endpoint twice, which is the debugging signal. Nothing leaves your browser during this step.
  3. Copy the redacted output. What you send now relates to 192.0.2.1 and user_01; the mapping between those and the real values only ever existed in your browser tab. That is pseudonymisation in the Article 4(5) sense — and because the table never left, it is not a disclosure of personal data to the vendor.
  4. Record it. One line in your processing register: "proxy log excerpt, pseudonymised, shared with <vendor> on 2026-09-18 for incident #4711, basis: legitimate interest (Recital 49), retention: deleted after ticket closure". The Compliance Reference Database has the article text if you need to quote it.

Now the harder case: the outage turns out to be an attacker who downloaded the export. Open the Incident Report Generator and note the moment of awareness — the 72 hours to the CNPD start there, not at the end of your investigation, and Article 33(4) lets you notify in phases when you do not have everything yet.

Common misreadings

  • "Anonymised" logs usually are not. Truncating an IP while keeping timestamps and user agents is pseudonymisation; treat it as personal data.
  • Availability loss is a breach. Encrypted-but-restored-from-backup ransomware may still need notifying if people were affected in the meantime.
  • Threat intelligence contains personal data. Attacker e-mail addresses and IPs are personal data too; sharing them is lawful under Recital 49, but "strictly necessary" still applies to what you keep and for how long.