A SaaS company launches a newsletter and collects 12,000 email addresses without documenting any consent. Six months later, a recipient complains to the data protection authority. The authority demands the Record of Processing Activities, proof of consent and the TOM concept — within two weeks. Anyone who cannot produce these documents risks more than the fine alone; the authority can order the entire mailing list to be deleted.
The General Data Protection Regulation (GDPR) has applied directly throughout the EU since 25 May 2018. It replaced the old EC Data Protection Directive and harmonises data protection law across all member states. For information security it matters because it requires concrete technical and organisational measures (TOMs) whose implementation overlaps heavily with ISO 27001.
Who is affected?
Practically every organisation that does more than process purely anonymous data. The GDPR applies extraterritorially: a US company that places advertising in the EU also falls under the regulation. Concretely, it covers:
- Controllers (Art. 4 no. 7) — those who decide on the purpose and means of processing. This is usually the organisation itself.
- Processors (Art. 4 no. 8) — those who process on behalf of the controller. Classic examples: cloud providers, payroll service providers, external IT maintenance.
- Joint controllers (Art. 26) — when several organisations jointly decide on purpose and means, for example in research consortia or certain marketing partnerships.
The only exception covers processing for purely personal or household activities (Art. 2(2)(c)) — the famous “household exemption”.
What does the law require?
Six principles (Art. 5) form the foundation: lawfulness, fairness, transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, accountability. From these principles flow concrete obligations:
- Legal basis (Art. 6) — every processing activity needs one of the six legal bases: consent, contract, legal obligation, vital interests, public interest, legitimate interest.
- Record of Processing Activities (Art. 30) — mandatory for organisations with 250 or more employees, but in practice advisable for almost all.
- Data Protection Impact Assessment (Art. 35) — for high-risk processing (e.g. systematic monitoring, large-scale processing of special data categories).
- Technical and organisational measures (Art. 32) — state-of-the-art protection. This is where the bridge to ISO 27001 lies.
- Breach notification (Art. 33, 34) — notification to the supervisory authority within 72 hours, to data subjects in case of high risk.
- Data subject rights (Art. 12 ff.) — access, rectification, erasure, restriction, data portability, objection. Requests must be handled within one month.
- Data processing agreement (Art. 28) — mandatory minimum content for every processing contract that involves personal data.
In practice
Maintain the Record of Processing Activities as a living document. The most common gap in audits: the register was set up in 2018 and has not been updated since. Every new application, every new business process belongs in it. A proven practice: link each entry to the CMDB record of the underlying application.
Systematically screen for Data Protection Impact Assessments. For every new processing activity with potentially high risk, the DPIA obligation must be checked. Supervisory authorities publish positive lists (e.g. the “must list” of the German DSK). Missing a DPIA can trigger a fine even without a data breach.
Rehearse the breach notification chain. The 72-hour deadline starts when the breach becomes known, not after the final assessment. In practice, you need a clear escalation path from the person who notices the incident through to management and the DPO. Tabletop exercises uncover gaps that become expensive when a real incident hits.
Mapping to ISO 27001
The TOM requirements from Art. 32 GDPR overlap substantially with the ISO 27001 Annex A catalogue. Anyone running a certified ISMS automatically fulfils a large share of the GDPR security requirements.
Directly relevant controls:
- A.5.34 — Privacy and protection of personally identifiable information: the bridge to the GDPR; requires identification and fulfilment of all data protection requirements.
- A.5.32 — Intellectual property rights: relevant to the GDPR through data minimisation.
- A.5.13 — Labelling of information: classification of personal data as a prerequisite for appropriate protection measures.
- A.5.14 — Information transfer: secure transmission and third-country transfer.
- A.5.24 — Information security incident management planning and preparation: prerequisite for the 72-hour notification deadline.
- A.5.36 — Compliance with policies, rules and standards for information security: covers compliance review against the GDPR.
- A.6.3 — Information security awareness, education and training: data protection training is mandatory.
- A.8.10 — Information deletion: technical implementation of the right to erasure.
- A.8.11 — Data masking: pseudonymisation and anonymisation.
- A.8.24 — Use of cryptography: encryption as a central TOM measure.
- A.8.25 — Secure development life cycle: privacy by design.
Typical audit findings
- Outdated Record of Processing Activities — the most common finding. New tools, new processes, departed service providers are missing.
- Missing or incomplete DPAs — especially with cloud providers, DPAs are often accepted without review of content.
- Consents without proof — newsletter sign-ups without double-opt-in logs, tracking without documented cookie consent.
- Unclarified third-country transfers — US tools in use without a TIA, data in unknown cloud regions.
- Breach process only on paper — nobody has ever practised the notification chain, the escalation path is unknown.
- Right of access not operationalised — no specific person is named, no template exists, the one-month deadline is missed.
Sources
- GDPR full text (GDPR-info.eu) — annotated full text with references to recitals
- Regulation (EU) 2016/679 (EUR-Lex) — official EU version in all languages
- Federal Data Protection Act (BDSG) — German additions and specifications
- German Data Protection Conference (DSK) — resolutions of the German supervisory authorities
- European Data Protection Board (EDPB) — guidelines for consistent interpretation