Lesson 1.1: 'Our focus is not politicising this incident': Director of Medimap speaks on data breach

Compliance Framework Mapping

Introduction

Welcome to Lesson 1.1: 'Our focus is not politicising this incident': Director of Medimap speaks on data breach! Over the next 45 minutes, we will explore the anatomy of a data breach, focusing on the critical moments of incident response and communication, and how the initial framing of an incident can shape its entire trajectory.

But first, let me tell you about Marcus Webb.

It's 8:15 on a Tuesday morning in October. Marcus Webb, the Director of Communications at Medimap, a healthcare technology company in London, is sipping his second coffee of the day. The office hums with the usual pre-meeting chatter, but his phone has been buzzing with unusual frequency for the last twenty minutes. The screen shows a string of messages from the Head of IT, all marked urgent.

He opens the latest one. 'Marcus, we need to talk. Now. The security team has found something. It looks like a breach.' The words feel heavy. He can hear his own heartbeat over the office noise. His mind races to the company's patient appointment booking platform, the sensitive data it holds—names, contact details, partial medical histories. He pictures the headlines.

Walking to the emergency meeting, he rehearses lines in his head. 'We are investigating an incident.' 'Patient privacy is our top priority.' But as he enters the room, the CISO's first words change everything: 'We've traced the initial access. It looks like it came from a contractor's compromised credentials. The data is already on a forum.' The decision point is here. Does he lead with transparency, or does he lead with control?

This is the story of a data breach. By the end of this lesson, you'll understand exactly why Marcus never stood a chance with his prepared statements, and more importantly, what could have saved him and his organisation.

Content Section 1: The Anatomy of a Breach Announcement

Announcing a data breach is less like reading a press release and more like performing surgery while the world watches. Every word is a scalpel. The phrase 'Our focus is not politicising this incident' isn't just corporate speak; it's a strategic deflection, a first move in a high-stakes game of reputation chess.

The First 24 Hours

The initial public statement in a breach sets the narrative for everything that follows. Research suggests that organisations that immediately acknowledge the scope and potential impact, even if details are still emerging, fare better in terms of long-term trust. The instinct is often to minimise, to use vague language like 'security incident' instead of 'data breach,' or to assure everyone that systems are 'secure' while the investigation is just beginning.

This creates a credibility gap. When further details inevitably emerge—often from external researchers or the attackers themselves—the organisation is seen as having been dishonest or incompetent. The public, and regulators, don't just judge the breach; they judge the response. A statement focusing on what the organisation is *not* doing, like 'politicising,' can be heard as an attempt to steer conversation away from what they *are* responsible for: protecting data.

The technical reality of a breach is a scramble. Forensic analysis is ongoing, the full extent of data exfiltrated is unknown, and the attack vector might still be active. But the communication reality is that the clock started the moment the breach was detected. Silence is interpreted as guilt or chaos.

Stakeholders and Conflicting Agendas

A Director of Communications like Marcus isn't speaking to one audience. He's addressing a fractured crowd with competing demands. Legal counsel wants statements that limit liability. The IT security team wants technical accuracy that doesn't give attackers more advantage. The board wants to protect share price. Customers want to know if their data is safe. Employees are scared.

The phrase 'not politicising' often emerges from this tension. It's an attempt to placate internal factions who might want to blame a rival, a nation-state, or a political ideology. It tries to frame the incident as a pure, apolitical crime. But in cybersecurity, the 'why' is often deeply political or geopolitical, and ignoring that can blind an organisation to the true nature of the threat.

DORA Article 5 DORA Article 5 requires financial entities to have a comprehensive ICT risk management framework. This includes clear communication and reporting procedures for major incidents, ensuring that public statements are consistent with internal assessments and regulatory obligations.

ISO A.5.1 ISO 27001 A.5.1 mandates that top management demonstrate leadership and commitment to information security. This includes ensuring that roles and responsibilities for incident communication are assigned and that public messaging aligns with the organisation's security policies and the gravity of the incident.

Content Section 2: The Technical and Communication Kill Chain

Understanding a data breach reveals why communication is so hard. Let me show you exactly how Marcus's prepared statements were disconnected from the technical reality unfolding in his own server logs.

Parallel Timelines

While Marcus drafts statements, the attack has its own lifecycle. It begins with initial access—perhaps that compromised contractor credential. Then, the attacker establishes persistence, creates backdoors, and moves laterally through the network, searching for databases. They find the patient booking data, package it, and exfiltrate it, often using encrypted channels to blend with normal traffic.

Meanwhile, the communication team is on a different timeline. The first internal alert triggers a war room. The initial assessment is 'potential incident.' Legal holds are placed on evidence. The decision is made: do we notify the public now, or wait until we know more? This delay, often hours or days, is where the attacker's timeline and the organisation's public timeline fatally diverge.

The data is already sold or leaked by the time the company confirms the breach. So when Marcus finally speaks, his audience may already have seen their own data on a forum. His 'we are investigating' feels hollow because, for the victims, the investigation is over; the harm is done.

The Fog of War

In the early hours, information is contradictory. One tool shows anomalous outbound traffic; another shows nothing. A server log suggests data was accessed; the database admin says the logs are incomplete. This technical fog makes drafting a clear, accurate public statement almost impossible.

The pressure to say *something* leads to generic language. But generic language about a specific, technical crime creates ambiguity. 'We have engaged leading security firms' doesn't say if the hole is plugged. 'We are notifying affected individuals' doesn't say if it's 100 or 100,000 people. This ambiguity breeds fear and speculation, which the organisation then has to manage alongside the actual breach.

Why Traditional PR Playbooks Fail

Notice what all of these methods have in common. They assume the organisation controls the narrative timeline. In a digital data breach, you do not. The attacker and the internet set the pace.

Standard crisis communication is built for product recalls or executive scandals, not for live cyber incidents. Here’s how standard methods break down:

NIST ID.RA-1 NIST CSF ID.RA-1 requires identifying asset vulnerabilities. A failure in communication during a breach is itself an operational vulnerability, as it can exacerbate the impact of the technical breach, leading to greater regulatory fines and loss of trust.

NIS2 Article 21 NIS2 Article 21 mandates risk management measures, which include having incident response plans. These plans must encompass communication strategies that ensure early warning to stakeholders and competent authorities, not just technical containment.

Content Section 3: Detection: Seeing the Story in the Logs

Marcus's IT team likely had systems that knew something was wrong. They just couldn't translate those signals into a story Marcus could use. Effective detection isn't just about alerts; it's about generating the narrative evidence needed for responsible communication.

Network-Level Indicators

The first clues are often in the network flow. A sudden spike in outbound data transfer from a database server to an unfamiliar external IP, especially outside business hours, is a classic sign. Research suggests that monitoring for data transfer volumes that exceed historical baselines from specific assets is a key detection method.

Other signs include connections to known malicious IPs or domains, or the use of non-standard ports for data transmission. The problem is these signals can be buried in noise. The IT team might see the alert, but without immediate context—'Is this a scheduled backup or a theft?'—they can't give Marcus a clear 'what' and 'how much.' This uncertainty feeds directly into vague public statements.

Endpoint and Database-Level Indicators

On the servers themselves, unusual process activity is a tell. A database admin tool running at an odd time, or by a user account not associated with the DBA team, points to hands-on-keyboard activity. Large, unusual query patterns—like 'SELECT * FROM patients' executed from a new IP address—are massive red flags.

Logging these events is one thing; correlating them into a coherent attack story is another. This correlation is what turns technical indicators into communicable facts: 'We have evidence that an unauthorised actor accessed our patient database using stolen credentials and exported a copy.' That's a fact Marcus can use.

Identity and Access Signals

The breach often starts with identity. Failed login attempts followed by a success from a new location, or a user account accessing resources they never normally use, are critical early warnings. The use of privileged accounts for routine tasks is another risk indicator.

Monitoring for these signals allows an organisation to potentially stop an attack before data exfiltration. More importantly for communication, it provides early attribution and scope. Knowing 'it was this contractor's account' and 'they only had access to these three systems' allows for a more precise and confident public update than 'we are investigating a broad network incident.'

SOC2 CC3.1 SOC 2 CC3.1 requires a commitment to integrity. Demonstrating integrity during a breach means your public communications are consistent with the evidence your detection systems are generating. Overstating containment or understating impact based on poor detection data violates this principle.

GDPR Article 32 GDPR Article 32 requires appropriate technical measures to ensure security. This includes the ability to detect a breach in a timely manner. The quality and speed of your detection directly determine the accuracy and timeliness of your mandatory breach notification to regulators and data subjects.

Content Section 4: Documenting for Defence and Compliance

A well-managed breach response, even if the breach itself was severe, generates a mountain of evidence. This evidence isn't just for fixing systems; it's your defence in the court of law, regulation, and public opinion. Think of it as building a shield from the wreckage.

Evidence Generation

This lesson provides documentation for multiple compliance frameworks:

For DORA Article 5 auditors... For DORA auditors, you can now demonstrate that your training includes scenario-based planning for ICT-related incident communication, a key part of the operational risk management framework.

For ISO A.5.1 auditors... For ISO 27001 assessors, you can evidence that management responsibilities for incident communication have been defined and exercised through this training, supporting leadership commitment to information security.

For NIST RS.CO-4 auditors... For NIST CSF reviewers, you can show that personnel have been trained in the 'Communications' subcategory of the Respond function, specifically in coordinating with external stakeholders during incidents.

Audit Trail

Document your completion of this lesson:

• Lesson title and date completed
• Time invested: approximately 45 minutes
• Key learnings in your own words
• Activity submission reference
• Follow-up actions identified

Conclusion

Let me tell you how Marcus's story ended.

Marcus's initial statement, focusing on what the company wouldn't do, was picked apart online. Cybersecurity journalists contrasted it with data samples already circulating. The narrative became 'Medimap is more concerned with its image than with its patients.' Trust eroded. The company faced increased regulatory scrutiny, class-action lawsuits, and a significant drop in user registrations. Marcus spent the next six months in constant crisis meetings, his original role consumed by the breach fallout.

A year later, Medimap had rebuilt. They hired a dedicated CISO with a seat at the executive table. Their incident response plan was rewritten to integrate communications and technical teams from minute one. They now run quarterly breach simulation exercises where the comms director has to draft statements based on live, simulated technical feeds.

But it doesn't have to be your story. That's why we're here.

You should now understand that breach communication is a core security discipline, not just a PR task. You understand how the technical timeline of an attack destroys traditional crisis communication models. You know the key detection signals that must be translated into public facts. And you understand how to document your preparedness for the inevitable questions from regulators and auditors.

Next, we'll explore Next, we'll explore Lesson 1.2: 'The Duality of the Insider Threat.' We'll look at how the most damaging breaches often start with a familiar face, and why technical controls alone can't stop them.

See you there.

Resources

The course materials folder contains downloadable resources for this lesson:

• Lesson 1.1 Quick Reference Card - Summarise the key communication pitfalls and immediate response steps for a data breach, based on the 'Medimap' case study, on a single page.
• Compliance Mapping Worksheet - Map your organisation's data breach communication procedures to the specific requirements in DORA Article 5, ISO 27001 A.5.1, NIST CSF RS.CO, NIS2 Article 21, SOC 2 CC3.1, and GDPR Article 32.
• Risk Assessment Template - Assess your organisation's specific exposure to communication failures during a data breach based on the misalignment of technical and PR timelines covered in this lesson.
• Further reading - Links to official framework documentation (NIST SP 800-61 on Incident Handling, ICO guidance on breach communication) and threat intelligence sources on attacker communication tactics following breaches.

'Our focus is not politicising this incident': Director of Medimap speaks on data breach Defence Masterclass | Threat Intelligence | Lesson 1.1
© LimitedView Limited | 2026