Who Should Implement GDPR? Legal, Security — or Both?

The EU General Data Protection Regulation (GDPR) is one of the most comprehensive privacy laws. It requires both legal interpretation and technical enforcement — a combination that raises an essential question inside nearly every organization:

Who is responsible for implementing and maintaining GDPR? Should it be led by the Legal and Information Security teams, or should it be a collaborative effort?

In our work at CodeFortress, we’ve seen all three models in practice and how each one plays out. The conclusion is clear: treating GDPR as the responsibility of a single team leads to gaps, misalignment, and risk.

Why This Matters

GDPR isn’t just about ticking boxes or avoiding fines. At its core, it’s about building trust by creating transparent, accountable data practices that can withstand customer, partner, and regulator scrutiny.

Still, many organizations fall into one of two traps:

• The legal-only approach involves legal teams drafting comprehensive privacy policies, updating contracts, and publishing terms and notices without ensuring that technical systems support those promises. Everything looks compliant on paper, yet critical safeguards may be missing in practice: data might not be encrypted, retention limits may be unenforced, and user requests might not be technically possible to fulfill. 

• The tech-only approach involves Security and IT teams focusing on infrastructure, implementing firewalls, encryption, access control, and monitoring without understanding the legal context. They may retain data longer than allowed, miss consent or transparency requirements, or fail to identify what qualifies as a reportable breach.

Both approaches result in exposure and inefficiency. Policies exist without enforcement, and controls exist without justification. And when something goes wrong — a breach, an audit, or a data subject request — the gaps become painfully visible. We've seen this lead to delays, internal finger-pointing, and, in some cases, regulatory penalties.

The alternative is simple: Legal and Security must work together, with clear roles, proper sequencing, and shared validation.

Defining the Boundaries: Legal vs. Technical Responsibilities

Understanding who does what under GDPR is the first step toward making it work. The most effective programs treat GDPR implementation as a two-stage process:

• Legal defines the rules – what personal data is processed, why, and under what basis.

• Security implements the controls – how those obligations are enforced in systems and operations.

Let’s break it down.

Legal Defines the Rules of the Game

The Legal team lays the foundation. They define what data and processing activities fall under the regulation, explain why they’re subject to GDPR, and determine the lawful basis for each. They establish which data must be protected, how long it can be kept, and data subjects' rights.

The Legal team owns the interpretation and scoping of GDPR. They determine how the law applies to the organization’s data processing activities. This includes:

• Identifying what types of personal data are collected

• Understanding why the data is processed and under what lawful basis (e.g., consent, contract, legitimate interest)

• Defining how long data can be kept and what rights individuals have (access, deletion, correction, etc.)

• Reviewing third-party agreements and setting up Data Processing Agreements (DPAs)

• Ensuring compliance with international data transfer rules

They translate legal text into operational obligations, setting the standards the rest of the organization must follow.

Security Brings the Law to Life

Once the legal framework is defined, the Information Security and IT teams take over. Their job is to turn legal obligations into system-level protections. This includes:

• Encrypting personal data in transit and at rest

• Implementing role-based access controls, monitoring, and audit logging

• Designing systems for data minimization, retention, and secure deletion

• Establishing and testing incident detection and breach notification workflows

• Automating data subject rights such as export, correction, and erasure

• Applying privacy-by-design in system architecture and software development

• Performing technical risk assessments and contributing to DPIAs

• Maintaining documentation of controls, policies, and procedures

• Participating in data mapping to align systems with legal understanding

Security’s role is not just to protect — it’s to make compliance measurable, testable, and defensible.

A Practical Model for GDPR Implementation

To make this collaboration work, we follow a structured approach. It’s not about Legal becoming technical or Security interpreting the law — it’s about aligning their strengths in the correct order.

1. Legal Leads the Scope

Every GDPR program starts with a legal foundation. At this stage, we work closely with the organization’s legal or compliance team to define what personal data is collected, why it’s processed, under what lawful basis, and how long it should be retained. This includes clarifying data subject rights, identifying high-risk processing activities, and reviewing international data transfers and third-party contracts.

The goal is to translate regulatory obligations into a clear, structured scope that can be handed to technical teams. Without this alignment, security teams often operate in the dark, protecting systems without fully understanding what needs protecting or why. A legally sound scope ensures the rest of the implementation is both compliant and targeted.

2. Security Builds the Controls

Once the legal scope is clear, the focus shifts to technical execution. Working with security and IT teams, we help design and implement the controls to enforce the earlier obligations. This includes encryption, access management, monitoring, secure deletion, and support for data subject rights such as access and erasure.

Rather than applying generic security practices, this phase tailors controls to the organization’s specific privacy risks and compliance needs. We ensure the technology stack protects data and aligns with legal promises, making the implementation practical and provable.

3. Joint Validation and Simulation

GDPR compliance isn’t static — it must be tested, monitored, and continuously improved. In this phase, we bring Legal and Security together to validate that everything works as intended. We simulate data subject access requests, rehearse breach response scenarios, and review documentation and metrics.

This collaborative validation helps both sides understand their roles in real-world situations. It surfaces gaps before they become audit findings and builds a culture of shared accountability between legal, security, and operational teams.

4. ISO 27701 as a Privacy Governance Framework

We recommend that organizations formalize their privacy programs by adopting ISO 27701, the privacy extension of ISO 27001.

It provides a structured governance model that:

• Defines clear roles and responsibilities for privacy and security

• Aligns technical and legal documentation

• Offers a framework for continuous improvement

• Serves as a bridge between day-to-day practice and audit expectations

While GDPR doesn’t offer certification, ISO 27701 helps demonstrate that your privacy program is organized, accountable, and mature.

The Role of the DPO: Legal, Technical, or External?

Under GDPR, some organizations are required to appoint a Data Protection Officer (DPO) who is responsible for overseeing compliance, advising on obligations, and acting as a point of contact for regulators and data subjects.

The regulation allows for flexibility in where this role sits. In some companies, the DPO comes from the Legal team, bringing strong knowledge of regulatory language and contractual frameworks. In others, the DPO has a technical background, often from Security or IT, with a deep understanding of systems and data flows.

Their independence, access, and support matter more than the DPO’s origin. A legally trained DPO who collaborates closely with Security can be highly effective—and the reverse is equally true. Some organizations, especially smaller ones, choose to outsource the DPO function to external specialists, which is fully allowed under GDPR.

What’s important is not just who holds the title but also whether that person (or team) is embedded in the organization’s privacy program, informed about legal and technical activities, and empowered to challenge decisions when needed.

The DPO should not be a figurehead — they should be part of the feedback loop that keeps GDPR efforts grounded, active, and accountable.

Final Thoughts

GDPR isn’t just about ticking off legal tasks or tightening technical controls—it’s about making privacy a genuine, working part of an organization's function.

The most successful teams don’t debate whether Legal or Security owns compliance. They align, coordinate, and build on each other’s strengths. Legal defines the boundaries. Security builds the systems. Together, they create something neither could do alone: a privacy program that works in the real world.

This collaboration isn't always easy—it takes effort, communication, and mutual respect. But when it's done right, the result isn't just compliance—it's trust, clarity, and it’s the ability to confidently say

“Yes — we know where our data is, why we have it, and how it’s protected.”

That’s not just a regulatory checkbox. That’s good governance. And increasingly, that’s what customers, partners, and regulators expect.

If you're working toward GDPR compliance, ask what needs to be done, who should do it, and how they'll work together.

That’s where authentic privacy leadership begins.