• Blog

The effects of GDPR on business cybersecurity

GDPR is the UK’s data protection law. While its most visible impact is forcing websites to display cookie banners and privacy consent prompts, it also has significant implications for how business cybersecurity systems are designed.

Any organisation that handles personal data must ensure its systems protect that data and can demonstrate this in the event of a security incident or complaint.

This guide explains how GDPR, as a general law, directly affects cybersecurity systems and what that means in practice for organisations.

Contents

• What is GDPR and why does it matter for cybersecurity?
• How does GDPR result in secure cybersecurity systems?
• What counts as personal data in GDPR?
• GDPR controllers vs processors
• How GDPR affects cybersecurity platforms

What is GDPR?

The General Data Protection Regulation (GDPR) is the primary data protection law in the UK, establishing the legal basis and core requirements for how organisations collect, use, and manage personal data.

It is the UK’s retained version of the original EU GDPR following Brexit, and is practically identical. Its most visible impact is the widespread use of cookie banners and privacy notices on websites and apps, but this is only the tip of the iceberg.

In reality, GDPR governs the entire lifecycle of personal data, including:

• data collection
• data processing
• data storage
• data sharing
• data deletion

It applies to organisations of all sizes across both the public and private sectors and covers all forms of personal data, from IP addresses and usernames tied to a real person to highly sensitive health and financial information.

Why does GDPR matter for cybersecurity?

Cybersecurity is central to GDPR because it is the set of technologies and policies that protect systems (and therefore personal data) against loss, theft, unauthorised access, and accidental exposure throughout its lifecycle.

This applies across each stage of data handling, as per the following examples:

• Data collection: Email gateways and anti-phishing tools prevent credential theft during data capture.
• Data processing: Role-based access control (RBAC) restricts who can process personal data.
• Data storage: Disk-level encryption and secure, offline backups protect stored data from breach or loss.
• Data sharing: TLS-encrypted connections protect data in transit and during external sharing.
• Data deletion: Secure wipe tools ensure data cannot be recovered after deletion.

GDPR therefore directly shapes cybersecurity expectations, as it requires organisations to protect personal data to a reasonable and appropriate standard in order to comply.

To accommodate organisations of different sizes and risk profiles, GDPR takes a risk-based approach:

• Handling low-risk personal data requires simple, consistently applied controls.
• Handling sensitive personal data across complex systems requires stronger, more structured safeguards.

GDPR also applies not only to an organisation’s own systems, but to third parties that process personal data on its behalf, such as cloud providers and payment processors. Weaknesses anywhere in this supply chain create compliance and legal risk for the controlling organisation.

The regulator responsible for enforcing GDPR in the UK is the Information Commissioner’s Office (ICO), which typically becomes involved after a security incident or a complaint is reported.

In these cases, organisations must be able to demonstrate that their security measures protected personal data to the required standard, often by referencing recognised frameworks such as ISO 27001 or Cyber Essentials Plus.

How does GDPR affect cybersecurity?

Organisations do not implement security directly from the GDPR text itself. The regulation is deliberately broad and principles-based: it defines legal obligations and expected outcomes, but does not prescribe how technical or organisational controls should be designed.

As a result, several interpretative layers exist to bridge the gap between legal data protection requirements and real-world cybersecurity systems:

1. GDPR: The fundamental legal basis

Role in data protection: Establishes the legal obligation to protect personal data and the principles to achieve it.

GDPR (as retained in UK law) is the overarching legal framework. It explains why data protection is required, establishes the lawful basis for processing, and defines high-level principles, rights, and accountability obligations.

At this level, GDPR makes data protection mandatory but remains intentionally vague and is not practically applicable to organisations. The principles that apply to cybersecurity are:

• Integrity and confidentiality: Personal data must be protected against unauthorised access, loss, alteration, or disclosure.
• Data minimisation: Personal data should be limited to what is necessary for a defined purpose, including within logs, monitoring systems, and backups.
• Storage limitation: Personal data should not be retained longer than necessary, influencing retention and deletion decisions across security tooling.
• Accountability: Organisations must demonstrate that appropriate measures were considered, implemented, and reviewed over time.

2. Article 32: The standard for testing GDPR compliance

Role in data protection: Defines the standard that regulators use to decide whether a system is compliant with GDPR.

Article 32 is the most practically relevant provision of UK GDPR for cybersecurity, as it moves beyond principles and individual rights and gives regulators a tool to test real systems and security decisions against GDPR.

It is roughly half a page of text, which, in essence, requires that:

• Security must be treated as a serious organisational responsibility, not an informal or ad-hoc technical task
• Risks to personal data must be assessed
• Security measures must be proportional to those risks
• Controls must be demonstrable with evidence

Article 32 deliberately avoids prescribing specific tools, technologies, methods, or certification requirements, and does not provide implementation guidance.

Article 32’s risk-based test

Article 32 operates as a risk-based “reasonableness” test that regulators apply following a breach, complaint, or investigation. Rather than asking whether specific controls were used, regulators assess whether the organisation’s security measures were reasonable given the data risks.

In practice, this assessment considers:

• State of the art: Whether the controls reflect current, widely accepted security practices, rather than outdated or unsupported approaches.
• Cost of implementation: Recognising that security must be achievable in context, while not allowing cost alone to justify inadequate protection.
• Nature, scope, context, and purpose of processing: Including the type of personal data involved, how much data is processed, how systems are used, and who may be affected.
• Likelihood and severity of risk to individuals: The realistic probability of a security failure and the potential impact on individuals’ rights and freedoms if it occurs.

These factors are assessed together, not in isolation. More sensitive data, more complex systems, or greater potential harm to individuals raise the expected standard of security.

3. NCSC guidance: Practical guidelines for meeting Article 32 expectations

Role in data protection: Provides technical guidance on how Article 32 expectations can actually be met.

Because Article 32 does not provide actionable technical guidance, the National Cyber Security Centre (NCSC) publishes a collection of technical guides to help organisations achieve reasonable cybersecurity outcomes, many of which map directly to Article 32 expectations.

This guidance is freely available and covers a broad range of cybersecurity topics, each handled independently. They are not technical manuals that mandate specific products or prescribe architectures, but are structured around checklists and outcomes that organisations can use to assess whether their systems are appropriately protected.

Here are some examples of how specific guidelines map back to Article 32 expectations:

While NCSC guidance is widely used to shape systems, controls, and security decisions, the NCSC does not issue certifications or documentation that prove adherence to its guidance.

4. Cyber certifications: Evidence of GDPR compliance

Role in data protection: Provide structured, auditable methods for evidencing Article 32 requirements.

GDPR does not require organisations to obtain cybersecurity certifications. In fact, many small organisations handling limited amounts of personal data and operating on standard cloud platforms never pursue formal certification and still meet GDPR requirements by applying proportionate, baseline security controls.

However, many organisations choose to use recognised frameworks, schemes, or certifications to structure their cybersecurity programmes and to evidence compliance with Article 32, particularly where systems are complex, data is sensitive, or external assurance is expected.

Common frameworks and schemes used to evidence GDPR security include:

• ISO 27001: A formal information security management standard requiring risk assessment, control implementation, and continuous improvement. Commonly used where repeatability, governance, and independent certification are required.
• SOC 2 reports: Frequently used by service providers and cloud-based organisations to meet customer due diligence expectations, particularly in supplier security assessments rather than direct GDPR compliance.
• NIST frameworks: Flexible sets of security controls and risk management practices, often adopted internally by organisations with complex or technical environments, particularly where formal certification is not required.
• Cyber Essentials/Cyber Essentials Plus: A UK government-backed scheme defining a baseline set of security controls. Commonly used by smaller organisations to demonstrate adherence to basic security practices aligned with Article 32 expectations. Includes implementation of simple yet effective controls such as multi-factor authentication (MFA), single-sign on (SSO) and simple firewalls.
• Cyber Action Toolkit: An actionable toolkit made by NSCS and the UK government that guides micro and small businesses on securing simple systems. It’s an even simpler alternative to Cyber Essentials.

5. GDPR-compliant cybersecurity

Role in data protection: The security systems that protect personal data in line with Article 32.

A GDPR-compliant cybersecurity system protects personal data in proportion to the risk and can demonstrate that protection if challenged. It does not require organisations to build a “cybersecurity fortress” when data is low-risk.

Article 32 explicitly allows security to scale with context, sensitivity, and foreseeable impact, so GDPR-compliant systems may look very different at opposite ends of the risk/complexity spectrum, as shown by the diagram and comparison table below:

What counts as personal data in GDPR?

Under GDPR, personal data is any information that relates to an identifiable individual, either on its own or when combined with other data.

Crucially, this definition extends well beyond customer databases or HR systems. In cybersecurity contexts, personal data is routinely embedded in logs, monitoring tools, backups, and cybersecurity software, even when the data was collected for operational or security purposes rather than for business use.

This often catches organisations off guard. GDPR is frequently assumed to apply only to obvious datasets, while large volumes of personal data held by IT and security teams fall within scope without being labelled or treated as such.

Personal data vs special category data

GDPR distinguishes between two levels of sensitivity: personal data and special category data.

Personal data

Personal data includes any information that identifies, or could reasonably be used to identify, a person. In cybersecurity environments, this is often technical or behavioural data, rather than names or addresses. Common examples include:

• Usernames and user IDs
• IP addresses and device identifiers
• Login times and access records
• Activity logs tied to individual accounts
• Call recordings and support transcripts
• Analytics linked to user behaviour

Individually, these records may appear low risk. Combined, they can form detailed profiles of individuals’ actions, locations, and access patterns.

Special category data

Special category data is a narrower, more sensitive subset of personal data that requires additional protection. This includes data revealing:

• Health or medical information
• Biometric or genetic data
• Racial or ethnic origin
• Political opinions or religious beliefs
• Sexual orientation or sex life

Security systems rarely collect this data intentionally, but it can still appear indirectly (e.g., through uploaded files, call recordings, breach artefacts, or incident investigation data) significantly increasing regulatory risk.

Identifying personal data in cybersecurity systems

Cybersecurity and operational tools routinely aggregate large volumes of technical data over long periods. While individual records may appear innocuous, their aggregation can create highly detailed views of individual behaviour.

Common security and operational datasets that frequently contain personal data include:

• System, application, and access logs
• Endpoint Detection and Response (EDR) telemetry
• SIEM and SOC systems
• Backup systems and snapshots
• Incident investigation data
• Call recordings and customer support logs
• Usage analytics and audit trails

If these datasets are not recognised as personal data, they are often retained indefinitely, broadly accessible internally, or shared with third parties without the appropriate controls.

This creates hidden GDPR exposure, particularly during incidents, audits, or breach investigations, precisely when these datasets are most heavily accessed.

What is the difference between GDPR controller and processor?

One of the key mechanisms GDPR introduces is the distinction between data controllers and data processors. This distinction exists to ensure that personal data remains protected as it moves across multiple systems, platforms, and organisations.

In simple terms, the controller is the organisation that collects personal data and decides why and how it is processed. The processor performs the processing on the controller’s behalf and in accordance with the controller’s instructions.

An organisation can act as both a controller and a processor simultaneously, depending on the context. For example, a business may act as a controller for its own customer accounts, while also processing another organisation’s data under contract as a service provider.

The table below summarises the key differences between the two roles:

Controller responsibilities for third-party processors under GDPR

Ultimately, much of the GDPR responsibility for third-party data processing rests with the data controller, not the processor.

Third-party processors include a wide range of platforms and service providers, from large cloud and SaaS providers such as Amazon Web Services to much smaller suppliers, such as specialist service providers.

GDPR does not expect controllers to treat all third parties equally. The level of scrutiny required depends on:

• the risk the processing poses to individuals,
• the sensitivity of the personal data,
• and the nature and scale of the service being provided.

GDPR expectations for large, established processors

For widely used, mature platforms (e.g., AWS, Salesforce), GDPR compliance is rarely the primary concern. These providers typically:

• Operate mature security programmes at scale,
• Offer standard GDPR-compliant data processing agreements,
• Implement encryption, access controls, logging, and resilience by default,
• Publish security documentation and independent assurance reports.

For most organisations, accepting standard contractual terms and using these platforms as intended is sufficient. GDPR does not expect smaller organisations to audit hyperscalers or negotiate bespoke security controls with global providers.

GDPR expectations for smaller or niche processors

Greater GDPR risk tends to arise with smaller suppliers, niche platforms, or bespoke service providers, particularly where they have direct access to personal data or operate outside well-established security practices.

While in practice many businesses (especially those handling non-sensitive data) apply limited scrutiny without incident, GDPR requires a more deliberate, documented approach when supplier risk is higher or when a breach would materially affect individuals.

In these cases, expectations usually centre on three practical areas.

Due diligence

Due diligence should be proportionate to risk. Organisations should understand:

• What personal data the supplier will process,
• How data is protected,
• How incidents will be detected and reported.

This does not require exhaustive audits, but it does require informed decision-making before data is shared.

Contractual terms

Security and data protection expectations must be formally documented, typically through data processing agreements or supporting contractual clauses. These usually cover:

• permitted processing activities,
• security obligations,
• breach notification requirements,
• data return or deletion at the end of the relationship.

Ongoing oversight

Where processing is ongoing or high-risk, GDPR requires organisations to maintain reasonable oversight over time. This includes:

• periodic security reviews or questionnaires,
• reassessment following incidents or material changes,
• confirmation that data handling and deletion obligations are being met.

GDPR-compliant cybersecurity breach response

Any security incident that results in the loss, disclosure, or unauthorised access to personal data is a personal data breach under GDPR and triggers mandatory response obligations.

Most breaches arise from internal errors or poor configuration rather than sophisticated attacks. Failure to respond correctly can lead to warnings or fines from the ICO. This is what a GDPR-compliant breach response looks like:

1. Immediate/automated response

When a breach is detected (whether through automated alerts or direct notification from malware or an attacker), security teams activate their incident response procedures. GDPR expects organisations to have rapid response measures in place to contain the incident and prevent further impact.

2. Assess whether personal data is involved

Once the incident is stabilised, the first question is whether personal data was affected. If no personal data is involved, GDPR breach obligations do not apply. If personal data may be involved, organisations must assess and document:

• Which systems and datasets were affected
• What categories of personal data were exposed
• The approximate number of individuals impacted
• The potential impact on individuals’ rights and freedoms

This assessment must be evidence-based. Inability to identify affected data or clearly explain decision-making is often treated as a failure of appropriate security measures, even where the technical incident itself was limited.

3. Risk evaluation and decision to notify

GDPR does not require every personal data breach to be reported. Instead, organisations must determine whether the breach is likely to result in a risk to individuals.

This risk-based judgement is central to GDPR compliance. Organisations must be able to justify why a breach was reported (or not) and document that decision, even where notification is not required.

4. Regulator notification (where required)

Where a breach is likely to result in a risk to individuals’ rights and freedoms, it must be reported to the Information Commissioner’s Office (ICO) without undue delay and, where feasible, within 72 hours of becoming aware of it.

Initial notifications may be incomplete, but:

• Delays must be explained
• Additional information must be provided as it becomes available

The 72-hour requirement is not about perfect information, but about timely and transparent escalation.

5. Notification to affected individuals (where required)

If a breach is likely to result in a high risk to individuals (such as fraud, identity theft, financial loss, or significant distress), affected individuals must also be informed without undue delay. Communications should:

• Clearly describe what happened
• Explain the likely consequences
• Set out what the organisation has done
• Advise individuals on steps they can take to protect themselves

Not all reportable breaches require individual notification, but where they do, delays are closely scrutinised.

6. Evidence, remediation, and learning

Throughout the response, organisations are expected to retain evidence supporting their actions and decisions. At a minimum, this typically includes:

• Timeline: When the incident occurred, was detected, and was contained
• Scope: Affected systems, accounts, and datasets
• Root cause: How the incident occurred, at an appropriate level
• Affected data: Categories of personal data and number of individuals
• Mitigations: Actions taken to contain the breach and prevent recurrence

How GDPR affects cybersecurity platforms

Cybersecurity solutions routinely process personal data as part of normal operation. GDPR does not restrict their use, but it does require that data collection, access, retention, and oversight are proportionate and justifiable.

• Next-Generation Firewalls (NGFWs): Minimise personal data logging from Deep Packet Inspection (DPI) capabilities to the minimum required.
• SIEM/log management: Minimise logged personal data, apply defined retention periods, restrict access, and redact identifiers when full detail is not required.
• Endpoint Detection and Response (EDR/MDR): Limit user-linked telemetry to what is necessary, manage providers as data processors, and consider data residency and transfers.
• Email compromise security: Control access to quarantined content, ensure scanning is proportionate, and limit use of message data to security purposes.
• Backups: Encrypt data, define retention limits, manage immutability carefully, and ensure restores do not reintroduce excessive or compromised data.
• Vulnerability scanners: Avoid unnecessary user or asset identifiers, restrict access to scan results, and limit long-term retention.
• DLP tools: Balance monitoring with employee privacy, apply proportional controls, and document the justification for surveillance activities.

GDPR for business cybersecurity – FAQs

Our business cybersecurity experts answer commonly asked questions regarding GDPR:

UK GDPR vs EU GDPR in cybersecurity terms

From a cybersecurity perspective, there is no material difference between UK GDPR and EU GDPR.  The cybersecurity requirements are the same: risk-based security controls, breach response, and accountability under Article 32.

The difference is who regulates it: In the UK, enforcement sits with the Information Commissioner’s Office rather than EU authorities.

Is GDPR a cybersecurity law?

No. GDPR is a data protection law, not a cybersecurity law. However, it requires organisations to use appropriate cybersecurity measures wherever personal data is processed. In practice, this means poor cybersecurity can lead directly to GDPR violations when personal data is exposed, lost, or accessed without authorisation.

Back to blog Back to broadband guides

• Share:
• 
• 
• 
•