GDPR Compliance Guide for Security Teams

For security teams, GDPR exposure lies less in consent banners than in weak authentication, unmonitored access, slow breach response and processors nobody checked. Article 5(1)(f) and Article 32 make security a legal duty, and the regulation adds obligations on breach notification, processor contracts and international transfers. This guide covers the parts of the GDPR and UK GDPR that security and identity teams own: lawful basis for security processing, Article 32 measures, Article 28 terms, transfer impact assessments, the 72-hour breach clock, DPOs, DPIAs and fines. It is written for CISOs, security architects, IAM leads and incident responders working alongside a DPO or privacy counsel.

Key takeaways

• Article 32 is risk based, not a control list. It names pseudonymisation, encryption, resilience, restore and testing, and leaves the rest to "the state of the art" and the risk to people.
• Accountability means evidence. Article 5(2) makes the controller "responsible for, and be able to demonstrate compliance": records of processing, DPIAs, test results, access reviews and a log of every breach.
• The 72-hour clock starts at awareness. The EDPB treats a controller as aware once it has "a reasonable degree of certainty" that a security incident has compromised personal data, so triage speed and processor alerting decide the outcome.
• Processors and transfers are security work. Article 28(3) binds processors to Article 32, audits and sub-processor approval, and SCC or BCR transfers need a transfer impact assessment.
• Identity failures are fixable root causes. Missing MFA sat behind the ICO's 23andMe fine; over-broad support access and service credentials with standing access to personal data are the same class of problem.

What the GDPR asks of security teams

The GDPR applies to controllers (who determine "the purposes and means of the processing of personal data", Article 4(7)) and processors (who process "on behalf of the controller", Article 4(8)). Security obligations sit in a few articles, each producing evidence a regulator will ask for after an incident.

The other Article 5 principles (lawfulness, fairness and transparency, purpose limitation, data minimisation, accuracy, storage limitation) reach security too, through log retention and telemetry scope.

Lawful basis for security processing

Security tooling processes a lot of personal data: IP addresses, email content in mail gateways, keystrokes in privileged session recordings, browsing history in web proxies. It needs one of the six Article 6(1) bases: consent, contract, legal obligation, vital interests, public task or legitimate interests.

• Legitimate interests (Art. 6(1)(f)): the usual basis for security monitoring. Recital 49 states that processing "to the extent strictly necessary and proportionate for the purposes of ensuring network and information security" constitutes a legitimate interest. Public authorities cannot use point (f) for their tasks and generally rely on public task.
• Legitimate interest assessment (LIA): the ICO's three tests are purpose, necessity and balancing (do the person's interests, rights or freedoms override yours?). Write one LIA per monitoring capability (EDR, DLP, UEBA, session recording), not one for "security".
• Contractual necessity (Art. 6(1)(b)): covers customer authentication, not unrelated analytics on login data.
• Purpose specification and use limitation: security data cannot quietly become a productivity or disciplinary dataset. If HR wants DLP or proxy data, that is a new purpose needing its own assessment and updated employee notices.
• Consent: rarely valid for employee monitoring because of the imbalance of power in employment.

Article 32 in practice

Article 32(1) requires controllers and processors to implement "appropriate technical and organisational measures to ensure a level of security appropriate to the risk". Article 32(2) points the risk assessment at "accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to" personal data. The named measures translate into controls:

The ICO treats Cyber Essentials as a baseline, not the ceiling, and expects test results to be documented and acted on. The CNIL's 2024 security practice guide (25 factsheets) is a useful catalogue to compare against. Article 32(4) requires that anyone with access processes data only on instructions, an argument for monitoring privileged and bulk access, not just preventing it.

Where identity fits

• Customer accounts: credential stuffing is a classic Article 32 failure. Enforce or offer MFA and step-up checks before bulk export of sensitive data. See the MFA Guide.
• Workforce and support access: scope support views to the minimum fields, review access quarterly and alert on volume anomalies. See the Access Reviews Guide.
• Service accounts, API keys and tokens: integrations, ETL jobs and AI agents often hold the broadest standing access to personal data. Give each an owner, scope it to one dataset and move to short-lived credentials. See the Service Account Security Guide.

Controllers, processors and Article 28 terms

The EDPB's Guidelines 07/2020 describe the controller as deciding "the why and how" of processing. "Essential means" (which data, for how long, who has access) stay with the controller; a processor may decide practical details such as hardware or security tooling. Joint controllers (common or converging decisions on purposes and means) need an Article 26 arrangement, which the EDPB recommends be binding.

Article 28(3) lists what a data processing agreement (DPA) must contain, including documented instructions (also covering transfers) and staff confidentiality. Security teams should own or review these clauses:

• Security (28(3)(c)): the processor "takes all measures required pursuant to Article 32". Attach a security annex with concrete commitments (encryption, admin MFA, logging, patching, incident SLAs).
• Sub-processors (28(2) and 28(3)(d)): no new sub-processor without prior specific or general written authorisation; under general authorisation the controller must be told of changes and able to object.
• Assistance (28(3)(e) and (f)): help with data subject rights and Articles 32 to 36 (breach notification, DPIAs). Set the processor's breach notification window in hours, since Article 33(2) only says "without undue delay".
• Deletion and audit (28(3)(g) and (h)): deletion or return at the end of the service, and audits "including inspections". Accept ISO/IEC 27001 certificates or SOC 2 reports for routine assurance and keep the right to targeted audits after an incident.

Outsourced support is where this fails most visibly. In the Coinbase insider breach, contracted support agents used access they already held to copy customer records, including government ID images. See the Third-Party Access Guide.

International transfers and transfer impact assessments

A transfer happens whenever personal data is sent to, or made accessible from, outside the EEA, including remote access by support teams or cloud administrators. Chapter V allows it only under these routes:

The Commission adopted the DPF adequacy decision on 10 July 2023 and states that the US safeguards, including redress, apply to all transfers to US companies whatever the mechanism, which helps SCC assessments. The EU General Court dismissed a challenge to the DPF (Latombe) on 3 September 2025; track any appeal, because invalidation would push DPF transfers back onto SCCs overnight.

The EDPB's Recommendations 01/2020 give the six-step roadmap a transfer impact assessment follows: know your transfers; identify the transfer tool; assess whether the Article 46 tool is effective in light of the destination's law and practice; adopt supplementary measures; take procedural steps; re-evaluate at intervals. Security owns steps 1 and 4: flow mapping (including remote admin and backups) and measures. The strongest is encryption with keys kept under the exporter's control in the EEA so the importer never sees cleartext; pseudonymisation with the lookup table kept in the EEA is the other. Neither works where the importer must read data in the clear, such as a support desk.

UK GDPR: the UK uses its own adequacy regulations, the International Data Transfer Agreement (IDTA), the Addendum to the EU SCCs and UK BCRs, with a transfer risk assessment showing protection is "not materially lower". The Data (Use and Access) Act 2025 (Royal Assent 19 June 2025) amends the UK GDPR, adding a transfer "data protection test" and recognised legitimate interests, so check current ICO guidance before reusing EU templates.

Personal data breach response and the 72-hour clock

A personal data breach is "a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to" personal data (Article 4(12)). That covers availability, so ransomware that only encrypts data is still a breach. Article 33(1) requires notification to the lead supervisory authority "without undue delay and, where feasible, not later than 72 hours" after becoming aware, unless the breach is unlikely to result in a risk to individuals. Article 34 adds communication to individuals where the risk is high.

1. Detect and triage (hours 0 to 24): confirm personal data is involved. EDPB Guidelines 9/2022 allow a short initial investigation before the clock starts.
2. Scope: data categories, approximate numbers of people and records, and identities the attacker used. Check encryption and key exposure: the EDPB states that a confidentiality breach of "properly encrypted personal data may not need to be notified" if the key is intact.
3. Assess risk: no risk (record only), risk (notify the authority) or high risk (also notify individuals). Special category, ID, credential and financial data push toward high risk.
4. Notify: Article 33(3) requires the nature of the breach, DPO contact, likely consequences and measures taken. Information may follow in phases (33(4)); late notifications must give reasons.
5. Record everything: under Article 33(5), "the controller must keep documentation of all breaches" (EDPB), notified or not.

Two traps. For non-EU controllers, an Article 27 representative does not give access to the one-stop-shop, so the EDPB expects notification "to every supervisory authority for which affected data subjects reside". And a processor's slow internal escalation consumes the controller's 72 hours. The Commission's Digital Omnibus proposal of 19 November 2025 would raise the threshold to high risk, allow 96 hours and add a single reporting entry point shared with NIS2 and DORA; until adopted, plan for the current rules.

DPOs, DPIAs, records and enforcement

• When a DPO is mandatory (Art. 37(1)): public authorities; core activities involving "regular and systematic monitoring of data subjects on a large scale"; and large-scale processing of special category or criminal offence data. Contact details must be published and given to the supervisory authority (37(7)).
• Independence (Art. 38): the DPO takes no instructions on their tasks, cannot be penalised for performing them and reports to the highest management level; other duties must not create a conflict of interests (38(6)). A CISO or head of IT who decides how personal data is processed is usually a poor fit for the role.
• DPIA triggers (Art. 35): processing "likely to result in a high risk", including large-scale special category data, systematic monitoring of public areas and automated decisions with significant effects. Insider-risk platforms, employee UEBA, biometrics and AI agents with customer data access typically need one.
• Records of processing (Art. 30): the under-250 employee exemption falls away if processing is not occasional, is risky or involves special category data, so almost everyone keeps one. Make the security column specific ("AES-256 at rest, MFA for all admin access, logs kept 13 months"), not "industry standard security".

Fines

Because Article 5(1)(f) sits in the higher tier, security failures can reach 4% when framed as a breach of the integrity and confidentiality principle. Authorities such as the ICO, the CNIL and Spain's AEPD investigate after notifications; for cross-border processing the lead authority sits where the controller has its main EU establishment. The ICO's £2.31 million fine against 23andMe in June 2025 was a security case: no mandatory MFA, no extra verification before raw genetic data downloads and ineffective monitoring during a credential stuffing campaign from April to September 2023.

Rolling out a GDPR security programme

1. Inventory first: map systems holding personal data (including SaaS, logs, backups and data lakes) to the record of processing, tagging special category data and the human and non-human identities that can read each store.
2. Set the risk baseline: rate the Article 32(2) outcomes per store and set target controls, mapped to ISO/IEC 27001 Annex A or NIST CSF 2.0.
3. Fix identity exposure: MFA on every route to personal data, no shared or dormant accounts, scoped service credentials. Pilot conditional access in report-only mode for two weeks, then enforce by ring (admins, support, everyone), with a documented break-glass path as rollback.
4. Encrypt and pseudonymise: start with backups, exports and analytics copies; run pseudonymised pipelines in parallel until reports reconcile, then retire the cleartext copy.
5. Contracts and transfers: add security annexes to DPAs, list sub-processors, complete TIAs.
6. Breach readiness: write the 72-hour runbook, pre-agree risk criteria with the DPO and run a tabletop including a processor notifying late.
7. Retention: run deletion jobs in report-only mode, check counts, then enable deletion with a short backup recovery window as rollback.
8. Prove it: schedule Article 32(1)(d) testing and report results annually.

Small vs large organisations: a 50-person SaaS company may reasonably rely on its cloud provider's encryption, its identity provider's MFA, Cyber Essentials and one annual penetration test, documented in two pages. A multinational with BCRs, many processors and special category data needs a control framework, a TIA register and a breach team on call. The legal test is the same; what is "appropriate" scales with risk.

Detection and measurement

Log access to personal data stores per identity (who, which records, how many rows), IAM and key management admin actions, bulk exports and API pulls, and changes to sharing or retention settings. Keep logs only as long as your LIA justifies. Useful metrics:

• MFA coverage: share of workforce, admin and customer accounts with access to personal data protected by MFA.
• Time to awareness and time to notify: median hours from first alert to awareness, and from awareness to notification.
• Processor assurance coverage: share of processors with a current DPA, security annex and assurance evidence under 12 months old.
• Non-human access to personal data: service accounts, API keys and tokens that can read personal data, and the share with a named owner and rotation under 90 days.
• Restore success: share of systems holding personal data with a successful restore test in the last 12 months.
• TIA completion: share of SCC and BCR transfers with a current TIA.

Framework mapping

Common failure patterns

• Optional MFA on accounts that hold sensitive data: the 23andMe breach turned reused passwords into a UK GDPR fine because MFA was not mandatory and bulk downloads needed no step-up.
• Broad standing access for support and outsourced staff: full-record views for every agent make insider and bribery cases large, as the Coinbase breach showed.
• Agents and integrations outside the risk assessment: in the AEPD AI agent breach notified in 2026, an attacker's AI agent logged in, probed the application and modified personal data. DPIAs that ignore automated access miss this.
• Waiting for full forensics before notifying: the 72 hours run from reasonable certainty, not from the final report; notify in phases.
• Generic DPAs: Article 28 clauses copied without a security annex or breach SLA cannot show "sufficient guarantees".
• Treating pseudonymised data as anonymous: the EDPB states pseudonymised data "remains information related to an identifiable natural person, and thus is personal data"; only data passing Recital 26's "means reasonably likely to be used" test is anonymous.

Practitioner checklist

• Link every system holding personal data to its record of processing entry and security measures.
• Write a legitimate interest assessment for each monitoring tool and set log retention to match it.
• Enforce MFA on every workforce, admin and support route to personal data, and offer or require it for customers.
• Inventory service accounts, API keys and agent credentials with access to personal data; assign owners and scope them.
• Add a security annex and a breach notification SLA in hours to every Article 28 contract.
• Maintain a TIA register for SCC and BCR transfers, with encryption and key location recorded.
• Run a yearly 72-hour breach tabletop that includes a processor-reported incident.
• Log every breach in an Article 33(5) register, including the ones you decided not to notify.
• Restore-test and penetration test systems holding personal data at least annually.

Standards and references

• EUR-Lex: Regulation (EU) 2016/679 (General Data Protection Regulation)
• EDPB: Guidelines 9/2022 on personal data breach notification under GDPR
• EDPB: Guidelines 07/2020 on the concepts of controller and processor in the GDPR
• EDPB: Recommendations 01/2020 on measures that supplement transfer tools
• EDPB: Guidelines 01/2025 on Pseudonymisation
• ICO: A guide to data security
• European Commission: EU-US data transfers
• NIST: The NIST Cybersecurity Framework (CSF) 2.0

Related NHI Mgmt Group resources: Identity Data Privacy and Consent Guide · Identity Security Regulatory Map · Third-Party Access Guide · Leaked Credential Response Playbook. This guide summarises GDPR and UK GDPR obligations relevant to security teams and is not legal advice.