GDPR cybersecurity requirements: the 5 articles that make security mandatory

GDPR doesn't just protect privacy, it mandates demonstrable cybersecurity controls. Learn how Articles 25, 32, 33–34, 35 and 28 map to real security obligations.

Most teams I speak with treat GDPR as a privacy law and cybersecurity as an IT problem. They're managed in separate spreadsheets, reviewed in separate meetings, and owned by different people. The trouble is, GDPR doesn't see it that way.

Under the regulation, failing to implement appropriate security isn't a technical oversight, it's a legal one. And regulators will ask for evidence. Not promises, not policies gathering dust on a shared drive. Actual, demonstrable evidence that your controls are working.

Here's how the two disciplines genuinely intersect, and what it means for your day-to-day compliance programme.

Where GDPR meets cybersecurity (the 60-second view)

GDPR frames security as an integral part of protecting the rights of individuals whose data you process. Article 32 requires you to protect the confidentiality, integrity, availability and resilience of personal data. Article 25 requires you to build security in from the start. Articles 33 and 34 require you to detect and report breaches fast. Article 35 asks you to assess security risks before you even begin high-risk processing. Article 28 makes security a contractual obligation that flows down to every vendor you use.

The NCSC and ICO reinforced this in their joint GDPR security outcomes framework, which groups everything into four practical aims: manage security risk, protect personal data against cyber-attack, detect security events, and minimise impact. That four-part model is a useful operating lens for any compliance or security team.

Article 32: security of processing

This is the centrepiece. Article 32 requires controllers and processors to implement "appropriate technical and organisational measures" to ensure a level of security appropriate to the risk. Specific measures it calls out include:

• Encryption and pseudonymisation of personal data
• Confidentiality, integrity, availability and resilience of systems
• The ability to restore availability and access to personal data after an incident
• A process for regularly testing, assessing, and evaluating the effectiveness of measures

The phrase "appropriate to the risk" matters. GDPR doesn't mandate specific products or configurations. It mandates outcomes. You decide which controls achieve those outcomes given your threat landscape, but you must be able to demonstrate the decision was reasoned.

In practice, that means your cybersecurity risk assessment isn't just an IT exercise, it's your primary GDPR evidence artefact for Article 32. Monthly vulnerability scanning, penetration test reports, and access control reviews all feed directly into it.

Article 25: data protection by design and by default

Article 25 requires you to bake security into system design, not retrofit it later. By default, only the minimum personal data necessary for a given purpose should be processed, and it shouldn't be accessible to an indefinite number of people without deliberate action.

For engineers and architects, this translates directly into familiar security controls:

• Least privilege access: users and services get only the permissions they need, nothing more
• Data minimisation: don't collect or retain fields you don't actually use
• Restrictive defaults: new user accounts should default to minimal access, not administrator rights
• Separation of environments: production data shouldn't live in development or test environments

These aren't abstract privacy concepts. They're design decisions that directly reduce your breach impact radius. A well-scoped SOC 2 requirements programme for SaaS companies maps almost perfectly onto Article 25 obligations.

Articles 33 and 34: breach notification duties

A personal data breach is defined broadly: any security incident that leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. A ransomware attack that encrypts customer records qualifies. So does an employee accidentally emailing a client list to the wrong recipient.

Once you're aware of a notifiable breach, two clocks start:

1. 72 hours: report to your supervisory authority (the ICO in the UK) without undue delay, and where feasible within 72 hours of becoming aware. If you can't meet the 72-hour window, you must submit the notification with reasons for the delay alongside it. Processors must notify the controller without undue delay after becoming aware.
2. Without undue delay (no fixed window): communicate the breach directly to affected individuals if it's likely to result in high risk to their rights and freedoms (Article 34).

Your notification needs to cover: the nature of the breach, approximate number of individuals and records involved, likely consequences, measures taken or proposed to address it, and your DPO or other contact point.

Understanding what constitutes a data breach and maintaining a documented incident log is half the battle. The other half is having a response process that actually works within that window.

GDPR incident response: a working timeline

Here's a reusable structure you can adapt for your own runbooks:

If not all details are available within 72 hours, the ICO accepts phased notifications, submit what you know and follow up. Don't wait until everything is confirmed.

Article 35: DPIAs combine privacy and security risk

A Data Protection Impact Assessment is required before any processing "likely to result in a high risk" to individuals' rights and freedoms. For most SaaS and tech teams, this means new features involving large-scale profiling, biometric data, systematic monitoring, or novel use of personal data.

A DPIA isn't just a privacy checklist. It's a structured security risk assessment applied to a specific processing activity. A useful DPIA input list for technical teams:

• Data flows: what data is collected, where it lives, who can access it
• Security posture: current controls protecting the data in scope
• Threat and impact analysis: what could go wrong, and what's the effect on individuals
• Mitigations: specific controls added to reduce identified risks
• Residual risk: what risk remains after mitigations, and whether it's acceptable

If residual risk is high and can't be mitigated, you must consult your supervisory authority before starting. The cybersecurity risk assessment work your team already does for ISO 27001 or NIS2 feeds directly into this.

Article 28: security-by-contract with processors and vendors

Every vendor who processes personal data on your behalf is a processor, and GDPR Article 28 requires your contracts with them to include specific security terms: implementing appropriate technical and organisational measures, maintaining confidentiality, assisting with breach notifications and DPIAs, and supporting your audit rights.

For sub-processors (vendors your vendors use), the same security obligations must flow down.

A practical vendor security due diligence checklist for GDPR Article 28 compliance:

• Does the vendor have documented security controls (ISO 27001, SOC 2, or equivalent)?
• Can they provide evidence of regular testing (pen tests, scan reports)?
• Do their contracts include breach notification timelines that allow you to meet your 72-hour obligation?
• Have they identified and contractually bound their sub-processors?
• Do they support your audit rights (direct audit or third-party assurance reports)?

This is an area where dealing with sub-service organisations in your audit scope becomes directly relevant to your GDPR obligations.

A practical GDPR control map

Here's how the key articles translate into controls and evidence artefacts:

GDPR is outcomes-based throughout. You're not ticking boxes, you're building a demonstrable case that your security is appropriate to the risk you carry.

What to ask your security and legal teams

If you're a compliance officer trying to join these dots across teams, these questions help:

For your engineering and security team:

• Which controls specifically protect personal data confidentiality, integrity and availability?
• How often are they tested, and where are the test outputs stored?
• What's the recovery time objective if personal data systems become unavailable?

For your vendors:

• What's your breach notification SLA, and does it fit within our 72-hour window?
• Can you provide a current penetration test summary or third-party assurance report?
• Which sub-processors handle our personal data, and what controls apply to them?

For your DPO or legal team:

• Do our processor contracts include all Article 28 required terms?
• Have we identified all processing activities that require a DPIA?
• Is our breach notification template pre-approved and ready to submit?

One thing that helps here is having your compliance and security programmes structured so evidence generated for one standard is reusable for others. Securance's Single Audit, Multiple Standards approach is built on exactly this principle, the same governance and cybersecurity work you do for ISO 27001 or NIS2 feeds your GDPR evidence pack without duplicating effort.

Frequently asked questions

Is GDPR a cybersecurity law?

Not technically. GDPR is data protection law. But it mandates security-of-processing as a legal obligation, which means cybersecurity controls are directly enforceable under it. Poor security can result in ICO enforcement action independently of whether a breach actually occurred.

Does GDPR specify which exact controls to use?

No. GDPR requires measures "appropriate to the risk", the regulation is deliberately technology-neutral. You choose the controls based on a risk assessment. What you must be able to show is that your choice was proportionate and reasoned.

If we use encryption, do we still need to notify after a breach?

Encryption is a significant mitigating factor. If data is stolen but rendered unintelligible through strong encryption, the risk to individuals may be low enough that data subject notification under Article 34 isn't required. You should still assess the incident, document your reasoning, and notify the ICO if in doubt. The assessment and documentation are not optional.

How do UK GDPR and EU GDPR differ for cybersecurity purposes?

Very little, in practice. UK GDPR retains the same Article logic (32, 33, 34, 25, 35, 28) as the EU regulation. The ICO is the supervisory authority for UK-based controllers, and UK-specific guidance from the ICO and NCSC applies. If you operate in both jurisdictions, the controls and evidence requirements are substantially the same, the main difference is which regulator you notify and where your Lead Supervisory Authority sits for cross-border processing.