GDPR and Security: A Complete Guide for Businesses

GDPR and security are inseparable in practice. The General Data Protection Regulation treats the protection of personal data as a fundamental obligation, and security measures are the mechanism through which that obligation is met. Any organisation that processes the personal data of individuals in the European Economic Area must implement safeguards that match the risk its processing activities create.

This guide covers the specific security requirements embedded in the GDPR, practical steps for compliance, breach notification rules, and common failures that lead to enforcement action. The information here is educational and does not constitute legal advice. Consult a qualified data protection attorney for guidance specific to your organisation.

How GDPR and Security Are Connected

The relationship between security and GDPR runs deeper than a single article in the regulation. Data security underpins several core GDPR principles defined in Article 5, including the "integrity and confidentiality" principle in Article 5(1)(f). This principle requires that personal data is processed in a manner that ensures appropriate security, including protection against unauthorised or unlawful processing and against accidental loss, destruction, or damage.

Security is not an afterthought or add-on. It is woven into the regulation's structure through multiple provisions:

• Article 5(1)(f): The integrity and confidentiality principle
• Article 24: Responsibility of the controller to implement appropriate technical and organisational measures
• Article 25: Data protection by design and by default
• Article 28: Processor obligations, including sufficient security guarantees
• Article 32: The dedicated security article specifying required measures
• Articles 33 and 34: Breach notification obligations

When a supervisory authority investigates a complaint or conducts an audit, security practices are among the first things examined. Organisations that treat security as separate from their GDPR compliance programme are structuring their efforts incorrectly.

Article 32: The Core GDPR Security Requirements

Article 32 is the primary provision governing security under the GDPR. It requires controllers and processors to implement "appropriate technical and organisational measures to ensure a level of security appropriate to the risk." The article provides a non-exhaustive list of measures to consider:

1. Pseudonymisation and encryption of personal data
2. Confidentiality, integrity, availability, and resilience of processing systems and services
3. Ability to restore the availability and access to personal data in a timely manner following a physical or technical incident
4. Regular testing, assessing, and evaluating the effectiveness of technical and organisational measures

The word "appropriate" is doing significant work in this article. The GDPR does not mandate specific technologies, firewalls, or encryption algorithms. Instead, it requires a risk-based approach where the measures you choose must be proportionate to four factors:

• The state of the art in security technology
• The cost of implementation
• The nature, scope, context, and purposes of processing
• The risk of varying likelihood and severity for the rights and freedoms of data subjects

A small business processing basic customer contact details has different obligations than a health technology company processing medical records. Both must perform a risk assessment and implement measures that match their specific processing activities.

Technical Security Measures for GDPR Compliance

Translating Article 32's principles into concrete security controls requires mapping regulatory language to practical technology decisions. The following measures address the most common areas where supervisory authorities expect to see adequate protections.

Encryption

Article 32(1)(a) explicitly names encryption as an appropriate measure. In practice, this means:

• Data in transit: TLS 1.2 or higher for all connections handling personal data, including internal services
• Data at rest: Encryption of databases, backups, and file storage containing personal data
• Key management: Secure storage and rotation of encryption keys, separate from the encrypted data

Encryption also provides a concrete benefit under Article 34(3)(a). If breached data was encrypted with a method that renders it unintelligible to anyone without the decryption key, and the key was not compromised, the controller may not need to notify affected data subjects.

Access Controls

The principle of least privilege is a fundamental security and GDPR requirement. Employees and systems should access only the personal data necessary for their specific role or function.

• Role-based access control (RBAC) mapping job functions to data access permissions
• Multi-factor authentication for any system containing personal data
• Regular access reviews to remove permissions when roles change
• Logging and monitoring of access to personal data stores

Network Security

Perimeter and internal network defences protect against unauthorised access:

• Firewalls, intrusion detection, and intrusion prevention systems
• Network segmentation isolating systems that process personal data
• Secure configuration baselines for servers, endpoints, and network devices
• Vulnerability management programmes with regular patching cycles

Data Minimisation and Pseudonymisation

Article 25 requires data protection by design, which includes collecting only the data you need and retaining it only as long as necessary. Pseudonymisation, where identifying fields are replaced with artificial identifiers, reduces risk if data is accessed without authorisation.

Organisational Security Measures Under the GDPR

Technical controls are only part of the picture. The GDPR explicitly requires organisational measures alongside technical ones. These include policies, training, governance structures, and processes that shape how people handle personal data.

Policies and Documentation

• Written information security policy aligned with GDPR requirements
• Data protection impact assessments (DPIAs) for high-risk processing, as required by Article 35
• Records of processing activities under Article 30
• Documented procedures for access requests, data deletion, and breach response

Staff Training

Human error remains one of the leading causes of data breaches. Article 39(1)(b) assigns the Data Protection Officer the task of monitoring training and awareness. Effective training programmes cover:

• Recognising phishing and social engineering attempts
• Proper handling, storage, and sharing of personal data
• When and how to report suspected security incidents
• Role-specific training for staff in high-risk positions (IT, HR, customer support)

Vendor and Processor Management

Article 28 requires that controllers use only processors providing "sufficient guarantees" of appropriate technical and organisational measures. This means security due diligence is mandatory before engaging any third party that will process personal data on your behalf.

Data processing agreements must include specific security obligations, breach notification requirements, audit rights, and instructions for data handling. A privacy policy generator can help you document your data sharing practices with processors, but the underlying contractual framework requires direct legal attention.

GDPR Data Breach Notification Requirements

Articles 33 and 34 create a structured breach notification regime that ties directly to your security posture. Understanding these rules is critical because every security incident involving personal data triggers specific legal obligations.

Notification to the Supervisory Authority (Article 33)

When a personal data breach occurs, the controller must notify the competent supervisory authority within 72 hours of becoming aware of the breach, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. The notification must include:

• The nature of the breach, including the categories and approximate number of data subjects affected
• The name and contact details of the Data Protection Officer or other contact point
• A description of the likely consequences of the breach
• A description of the measures taken or proposed to address the breach and mitigate its effects

If full details are not available within 72 hours, information may be provided in phases. The controller must document the reasons for any delay beyond the 72-hour window.

Notification to Data Subjects (Article 34)

When a breach is likely to result in a high risk to the rights and freedoms of affected individuals, the controller must also notify those data subjects directly "without undue delay." This notification must use clear and plain language, describing what happened, what data was affected, and what steps the individual can take to protect themselves.

Three exceptions apply under Article 34(3):

1. The controller had appropriate protections in place (such as encryption) that render the data unintelligible
2. The controller took subsequent measures eliminating the high risk
3. Notification would involve disproportionate effort, in which case a public communication is acceptable

Building an Incident Response Plan

Compliance with the 72-hour notification deadline requires preparation. Organisations should maintain:

• A documented incident response plan with clear roles and escalation procedures
• Pre-drafted notification templates for both authorities and data subjects
• Contact details for relevant supervisory authorities
• A breach register documenting all incidents, including those that did not require notification

Common GDPR Security Failures and Enforcement Examples

Examining enforcement actions reveals what supervisory authorities consider inadequate security. These cases provide practical guidance on where regulators draw the line.

Inadequate Access Controls

Multiple enforcement actions have targeted organisations where too many employees had access to personal data without business justification. The Spanish Data Protection Agency (AEPD) and the Italian Garante have both issued fines where internal access controls failed to prevent unauthorised viewing of customer records.

Failure to Encrypt

The European Data Protection Board has consistently emphasised encryption as a baseline expectation for data in transit. Several national supervisory authorities have imposed fines where personal data was transmitted over unencrypted channels, particularly for sensitive categories of data such as health information.

Delayed Breach Notification

The 72-hour notification deadline has generated enforcement action across multiple jurisdictions. Organisations that discovered breaches but delayed reporting, sometimes by weeks or months, have faced fines specifically for the notification failure independent of the underlying security weakness.

Insufficient Vendor Oversight

Controllers have been fined for engaging processors without adequate security assessments or data processing agreements. The GDPR holds controllers responsible for verifying that their processors maintain appropriate security, and "we trusted our vendor" is not an adequate defence.

How to Audit Your GDPR Security Posture

Regular security auditing is not just a best practice under the GDPR. Article 32(1)(d) explicitly requires "a process for regularly testing, assessing, and evaluating the effectiveness of technical and organisational measures." Here is a structured approach:

1. Inventory your processing activities: Identify all personal data you collect, where it is stored, who has access, and which processors handle it
2. Conduct a risk assessment: Evaluate the likelihood and severity of harm to data subjects from each processing activity
3. Map current controls to risks: Document which technical and organisational measures address each identified risk
4. Identify gaps: Compare your current controls against Article 32 requirements, supervisory authority guidance, and industry standards such as ISO 27001
5. Prioritise remediation: Address high-risk gaps first, document your rationale, and set deadlines
6. Test your controls: Conduct penetration testing, access reviews, phishing simulations, and incident response exercises
7. Review and repeat: Security auditing is a continuous process, not a one-time exercise

Tools like TermsBox's compliance scanner can help identify what cookies, trackers, and third-party services your website uses, which feeds directly into your records of processing activities and vendor assessments. Once you know what data your site collects, you can ensure your privacy policy generator output accurately reflects your processing and security measures.

GDPR Security Requirements for Websites Specifically

Websites present specific security and GDPR challenges because they are public-facing, interact with visitors' personal data in real time, and typically rely on numerous third-party services.

Cookie and Tracker Compliance

Websites commonly load analytics scripts, advertising pixels, and social media widgets that collect personal data. Under the GDPR and the ePrivacy Directive, most of these require informed consent before activation. Your website needs:

• A cookie consent mechanism (CMP) that blocks non-essential cookies until consent is given
• A cookie policy generator output that accurately lists all cookies and their purposes
• Regular scanning to detect new trackers introduced by third-party scripts

Form and Data Collection Security

Contact forms, checkout processes, and account registration pages must transmit data over encrypted connections. Input validation and sanitisation prevent injection attacks that could expose stored personal data.

Third-Party Script Risks

Every JavaScript file loaded from an external domain is a potential security and compliance risk. Supply chain attacks, where a legitimate third-party script is compromised, can expose your visitors' personal data. Implement Content Security Policy headers and monitor third-party script behaviour.

Hosting and Infrastructure

Your hosting environment must meet GDPR security standards. This includes server-level encryption, access logging, regular backups, and physical security at data centre locations. If your hosting provider operates as a processor, you need a data processing agreement covering their security obligations.

Frequently Asked Questions

What security measures does the GDPR require?

The GDPR does not prescribe specific technologies. Article 32 requires "appropriate technical and organisational measures" based on the state of the art, implementation costs, and the nature, scope, context, and purposes of processing. It explicitly names pseudonymisation, encryption, confidentiality controls, resilience measures, regular testing, and the ability to restore data after an incident. Supervisory authorities evaluate adequacy based on the risk to data subjects, not a fixed checklist.

How quickly must a data breach be reported under the GDPR?

Under Article 33, controllers must notify the relevant supervisory authority within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. If notification is delayed beyond 72 hours, the controller must provide reasons for the delay. Article 34 requires direct notification to affected data subjects "without undue delay" when the breach is likely to result in a high risk to their rights.

What are the penalties for GDPR security failures?

Security violations under Article 32 can trigger fines of up to 10 million EUR or 2% of annual global turnover, whichever is higher. If the security failure leads to a broader violation, such as unlawful processing or failure to report a breach, fines can reach 20 million EUR or 4% of annual global turnover. Supervisory authorities also have the power to issue warnings, reprimands, and orders to bring processing into compliance.

Does the GDPR require encryption of personal data?

Encryption is not an absolute requirement under the GDPR. Article 32(1)(a) lists pseudonymisation and encryption as examples of appropriate measures, but whether encryption is necessary depends on a risk assessment. However, Article 34(3)(a) provides a practical incentive: if breached data was encrypted and the key was not compromised, the controller may be exempt from notifying affected data subjects. In practice, regulators strongly expect encryption for data in transit and increasingly for data at rest.