Beyond legal #12: From headless chickens to coordinated data breach response - why operations beat legal theatre

An uncomfortable truth about some personal data breach response plans is they're actually more like a legal notification checklist trying to masquerade as an operational readiness artefact. They tell you what to report, when to report it, and who to notify. What they rarely address is how to contain the breach, how to investigate what actually happened, how to communicate effectively under pressure, and how to prevent the same incident from happening again.

Unfortunately, this theatre of preparedness gets exposed when an actual personal data breach occurs. The plan that looked comprehensive during the annual review becomes worthless when you're trying to work out which systems are compromised, whether customer personal data is still being exfiltrated, and how to coordinate response across legal, IT, security operations, communications, and business continuity teams, all while the clock ticks down to the regulatory notification deadline.

Three further uncomfortable truths

I begin with three statements that some data protection leaders may find provocative but I think they need to hear them:

Truth #1: Your personal data breach response plan is probably just a legal notification template

Open your incident response documentation right now. How many pages cover notification requirements (e.g., in GDPR, we're talking Art. 33 and 34) versus operational containment, forensic investigation, or crisis communications? If it's heavily weighted towards the former, you don't have an personal data breach response capability, you have a compliance document.

Truth #2: The plan falls apart at 2am on a Saturday

Imagine it's 2:15am on a Saturday. Your security operations centre detects unusual database access patterns that suggest data exfiltration. Who do you call? Do you have their actual mobile numbers? Do they know their role without reading a 50-page document?

Remember, data breaches don't conveniently occur between 9 and 5, Monday to Friday. They don't respect Christmas holidays, Easter breaks, or summer holidays. A couple of data protection professionals shared on a course I was teaching a few years ago at a conference in Brussels that they had participated in breach response on Christmas Eve, during Ramadan, and over Chinese New Year. If your team members don't have specific clauses in their employment contracts covering out-of-hours response obligations, and appropriate compensation reflected in their salaries, you're setting yourself up for failure when you need people most. I am continually amazed by the number of data protection leaders who do not have this in their contracts.

Truth #3: You discover your plan is worthless precisely when you need it most

Companies that have never tested their response plans under realistic conditions suffer the same pains: gaps appear everywhere. The forensics team can't access logs because retention policies weren't configured properly. The communications team doesn't understand the technical details well enough to draft customer notifications. Legal wants to delay disclosure while regulators expect transparency. Meanwhile, every hour of delay increases both the harm and the regulatory consequences.

Lessons from recent high-profile cases

Unless you have suffered harms yourself, or know someone who has, the past couple of years have provided some great lessons in what happens when data breach response is treated as a compliance exercise rather than an operational capability. Here are three high profile cases that continue to be talked about in the media.

Jaguar Land Rover

In September 2025, Jaguar Land Rover experienced a significant cyberattack that caused extensive operational disruptions, including production halts and supplier interruptions. The company confirmed that personal data had been compromised during the incident. While estimates of financial losses circulated, it is important to note that the reported figure of GBP 1.9 billion remains unconfirmed by the company. Regulatory bodies launched investigations emphasising the effectiveness of incident detection and response capabilities, with particular attention to supply chain and vendor-related risks.

Marks & Spencer

Marks & Spencer was hit by a ransomware attack in April 2025, which disrupted both online order fulfillment and in-store contactless payments. The attackers gained access to customer contact details, birth dates, and order histories, after initiating the breach through a sophisticated spear-phishing attack against the help desk. The incident demonstrated that strong breach response involves more than technical measures. It highlighted the critical role of staff awareness, social engineering prevention, and the challenge of distinguishing genuine support requests from deceptive attacks.

Harrods

In September 2025, Harrods notified customers of a personal data breach resulting from a vulnerability in a third-party IT service provider. The personal data of approximately 430,000 individuals was affected, though no payment information was compromised. This incident highlights the importance of factoring vendor risks into incident response planning, as Harrods, acting as the data controller, remained liable even though the breach originated from a processor.

What's the common thread here? These breaches weren't primarily legal failures, they were operational challenges involving third-party risk management, detection capabilities, forensic investigation, crisis communications, business continuity, and sustained coordination across multiple disciplines. Legal expertise was essential, but it wasn't sufficient.

Symptoms of a broken data incident and data breach response capability

Having been employed in large global corporations for many years and providing consultancy and training for similarly large companies, I have noted some of the the telltale signs that a company's incident and breach response capability exists primarily on paper:

• The "plan" is actually a document, not a capability. You may have comprehensive documentation, but if it's never been tested then you do not have a plan. Aside from testing it in anger, tabletop exercises, simulations, red team testing are different approaches you should regularly use.

• Roles are job titles, not trained individuals. Your plan specifies that "the CISO" or "the DPO" will do X, Y, Z, but those individuals have never actually practised their roles together or worked through simulated scenarios.

• You're focused on notification deadlines, not containment speed. The primary concern is "can we meet the 72-hour notification requirement?" rather than "can we stop the data exfiltration within the first hour?" This is a classic case of putting the interests of your company ahead of the rights and freedoms of affected people.

• Third-party incidents are an afterthought. As Harrods learned, many breaches occur at vendors, yet some response plans barely address how you'll coordinate when you don't directly control the compromised systems.

• Breach response exists in isolation. Your personal data breach response plan is standalone, with no integration into existing IT incident management, IT service continuity, business continuity planning, or enterprise crisis management frameworks.

• Risks to individuals are assessed generically. When assessing whether to notify individuals under say GDPR Art. 34, the analysis consists of vague statements like "high risk to privacy" rather than specific assessment of fundamental rights impacts and concrete harms.

The competencies you need

As I've done with all posts in my "beyond legal" blog series, I want to anchor competencies in the SFIA skills framework because these are measurable, definable competencies you can recruit, develop, or access when needed There are quite a few here that I want to suggest should be in the response team in addition to dedicated data protection and privacy specialists :

Incident Management (USUP) - End-to-end coordination of response activities. This is operational command under pressure, not administration.

Security Operations (see SFIA's skills for infosec) - Real-time monitoring, threat detection, and technical response. Containing threats, isolating compromised systems, and preserving forensic evidence.

Digital forensics (DGFS) - Forensic investigation involving log analysis, malware analysis, network forensics, and attack reconstruction.

Business Continuity Planning (COPL) - Maintaining critical business functions during and after an incident. The M&S incident, which affected online orders and contactless payments, required sophisticated business continuity response.

Stakeholder Relationship Management (RLMT) - Managing relationships with regulators, customers, vendors, partners, and investors during a crisis.

Communication (COMM) - Crisis communications that translate technical incidents into clear, honest, actionable messages for different audiences.

Risk Management (BURM) - As I discussed back in post #4 about risk, understanding the "ripple effects" of incidents across operational, legal, financial, and reputational risk domains.

Supplier Management (SUPP) - When incidents occur at third parties, coordinating investigation, enforcing contractual obligations, and managing response despite not controlling the compromised systems.

Notice what's absent? While legal competencies remain essential for notification and regulatory engagement, they represent one piece of a much larger operational puzzle.

Who should lead the data breach response team? (Probably not you, unless...)

Here's an uncomfortable question for data protection leaders: Should you actually lead the breach response team?

The honest answer for many is: probably not, unless you have significant operational experience managing incidents under extreme pressure.

Leading data breach response requires operational experience, cross-functional leadership, pressure resilience, the ability to meet people where they are rather than expecting them to understand GDPR articles, and organisational credibility. When you call someone at 3am, they need to take you seriously.

If you don't have this profile, that's not a failure, it's self-awareness. Many exceptional data protection leaders are brilliant at policy development and regulatory interpretation, but don't have the operational background for incident command.

In those cases, identify someone who does. Often, this is someone from IT with extensive incident management experience, ideally a situation manager, or a senior IT incident manager, the CISO, or someone who's led major incident response for IT outages. They understand how to work under pressure, coordinate across functions, and drive resolution.

Your role as data protection leader becomes strategic advisor to the response team lead, providing expertise on assessment of risks to individuals' rights and freedoms, regulatory notification requirements, data protection implications of containment decisions, and communication content.

There is some specific training for people who'll lead response teams through Kepner Tregoe. Many years ago I did book this training course for myself but the week after, the company I was working for had large global layoffs and all training got cancelled - a course I need to put on my ToDo list!

Build on what already exists

Does your company already have an IT incident management, or security incident management process?

I would think that for most large companies, the answer is yes. IT teams have been managing IT and security incidents for years, system outages, security vulnerabilities, service disruptions. They have established processes, trained personnel, escalation paths, and a track record of working under pressure, probably based around an industry standard framework like ITIL or COBIT.

Rather than starting from scratch to build a standalone "data breach response" capability, integrate with what already exists. By recognising the dependency you have on your IT and security incident management colleagues you can build on their existing capabilities, reduce friction, build relationships, and ensure consistency.

The key is ensuring that their processes include specific considerations for personal data breaches: triggers for involving data protection expertise, assessment frameworks for risks to individuals' rights and freedoms, regulatory notification decision points, and data subject communication requirements.

At the same time, you need to recognise the dependencies you have with other groups in your company:

• IT Service Continuity - When systems must be taken offline for investigation, service continuity plans kick in. The JLR incident demonstrated how production systems and business operations can be disrupted. Disaster Recovery is a critical component of IT Service Continuity, specifically dealing with the recovery of the IT infrastructure and systems after a significant, often catastrophic, event. This includes system backups and restoration, infrastructure failover, and data centre recovery strategies.

• Business Continuity Planning (BCP) - The M&S incident affected customer-facing operations. When a breach impacts critical business functions, business continuity plans provide the framework for maintaining operations.

• Crisis Management - Not every breach becomes a crisis, but some do. Understand your company's criteria for declaring a crisis and the escalation path. When a breach escalates to crisis status, it triggers executive leadership involvement and dedicated crisis communications.

Assessing risks to individuals

One of the most critical, and often most commonly botched, aspects of personal data breach response is assessing the risk to individuals' rights and freedoms. Too often, this devolves into vague statements: "There is a risk to privacy" or "Identity theft could occur."

As I discussed in post #4 about risk management, understanding ripple effects and being specific about risk is essential. When a breach occurs, you need to assess risks with precision, grounded in the Charter of Fundamental Rights of the EU and concrete harms to individuals.

Read the Charter, and then consider which specific rights might be impacted:

• Art. 7 (Respect for private and family life) - Could the breach expose intimate details, family relationships, private correspondence, or health information?

• Art. 8 (Protection of personal data) - What categories of personal data were compromised? Beyond immediate exposure, what secondary uses might occur?

• Art. 21 (Non-discrimination) - Could the exposed data lead to discriminatory treatment? If special category data was compromised, individuals face risks of discrimination in employment, insurance, housing, or access to services.

But read all 50 articles because the processing of personal data can play a part in all of them, so you need to assess practical, concrete harms: financial harm (identity theft, fraudulent transactions), physical harm (safety risks if location data or protected addresses exposed), reputational harm (damage to professional standing), psychological harm (distress and anxiety), and loss of control (inability to exercise rights over data).

This specific assessment directly informs:

• The need to notify individuals if there is a high risk to their rights and freedoms.

• Mitigation measures - what actions will you instruct the individuals to take to reduce harm.

• Communication content - explaining actual risks in clear language.

• Regulatory notification - demonstrating thorough understanding of impact, what happened, how, why, when and what you're doing about it.

In case you've not come across it, here's a reminder of the Charter of Fundamental Rights of the EU (sorry about the text size):

Testing your plan

Some companies claim to test their response capability, but scratch the surface and you'll find theatrical exercises where everyone knows their lines and complications are smoothed over.

Real testing is uncomfortable. It reveals gaps, creates friction, and generates real learning, which is exactly the point.

• Make testing realistic: Run drills at 2am on Saturday. Give participants only the information they'd actually have at each stage. Create genuine time pressure and conflicting priorities. Test handoffs between IT incident management, business continuity, and crisis management. If you're testing ransomware response, actually isolate test systems in a controlled environment. Many years ago I participated in a war game exercise where a TV studio had been set up with live news broadcasts, interviews, etc. After 2 days of being locked in the exercise (held in a nice hotel, so it wasn't all bad), we were finally let out, and it really did feel that we had all been involved in an actual breach/crisis.

• Share lessons learned: After each exercise and every real incident, conduct thorough After-Action Reviews. Document what happened versus what should have happened. Share findings broadly, brief leadership, share sanitised case studies across departments, incorporate insights into training. Don't silo lessons within the incident response team.

• Apply the improvements: Track implementation of corrective actions with specific deadlines. Close technical gaps (e.g. improve logging, strengthen access controls), process gaps (e.g. clarify escalation paths, revise playbooks), and competency gaps (e.g. recruit or train missing skills). As discussed in post #11 about measuring outcomes, measure whether your capability is actually improving.

Establish a cadence of continuous testing: quarterly tabletop exercises, annual out-of-hours technical drills, and rigorous post-incident reviews for every event, no matter how minor.

Conclusion

Here's the question I want you to honestly answer: If a significant personal data breach occurred right now, or at 23:18pm on New Years Eve, would your response be characterised by coordinated professionalism or chaotic improvisation?

Incident response capability isn't built by lawyers drafting notification templates. It's built by integrating with existing operational capabilities, ensuring the right person leads response (which may not be the data protection leader - it depends), establishing employment contracts that reflect out-of-hours obligations with appropriate compensation, coordinating seamlessly with IT service continuity and crisis management frameworks, assessing risks to individuals with specificity grounded in fundamental rights, and testing realistically while sharing and applying lessons learned.

The cases I mentioned earlier - JLR, M&S, Harrods - demonstrate how even significant companies can struggle when data breach response is treated as compliance documentation rather than operational readiness.

Your response capability is the ultimate test of whether your data protection function is genuinely embedded in your company's operations or merely performing compliance theatre. When the breach alarm sounds, there's no hiding behind policy documents, no time for debates about legal interpretation, and no opportunity to wish you'd done things differently.

Purpose and Means is a niche data protection and GRC consultancy based in Copenhagen but operating globally. We work with global corporations providing services with flexibility and a slightly different approach to the larger consultancies. We have the agility to adjust and change as your plans change. Take a look at some of our client cases to get sense of what we do.

We are experienced in working with data protection leaders and their teams in addressing troubled projects, programmes and functions. Feel free to book a call if you wish to hear more about how we can help you improve your work.