🗳️ Vote for us on PodRadar Security Theatre Exposed — Passkeys, the CISA Leak & Your Cyber Insurance Vote now →
Lucy Harper reviewing printed source documents at a light wooden desk in a bright, airy office

Case Study

The Warning Nobody Acted On: How Meridian's Cyber Essentials Certificate Survived Longer Than Their Client Data Did

Editorial note: The case study below is a fictional composite. “Meridian Professional Services” is not a real company. The incident described is constructed from patterns that appear repeatedly in published ICO enforcement reports, NCSC post-incident reviews, and public breach disclosures. All events, individuals, and specific details are invented for illustrative purposes. The patterns they reflect are real.


This is a case study about a forty-person accountancy firm in Leeds. The firm does not exist. Every individual named in this piece is fictional. The patterns of behaviour described appear, with depressing regularity, in real ICO enforcement reports, published post-incident reviews, and breach disclosures that have reached the public record.

I have constructed this as a composite because the specific firms involved in real incidents are often legally constrained from full disclosure, the details that would make the pattern clearest are frequently redacted, and the result is that the industry reads about consequences without fully understanding causes.

What follows is a clear account of causes.


The Business

Meridian Professional Services was established in 2011 by two chartered accountants. By 2024, it employed forty-two people across two sites: a main office in Leeds city centre and a smaller satellite in Harrogate. Clients included small and medium businesses across Yorkshire and the Humber region, several local charities, and a handful of sole traders.

In 2023, Meridian achieved Cyber Essentials certification. The partners were proud of this. It featured in their email footer and was mentioned in client proposals as evidence of the firm’s commitment to security.

Their IT infrastructure was managed by a combination of internal staff and an external MSP contracted for monitoring and first-line support. The internal IT resource was a single network administrator, Priya, hired in early 2022.


The Warning

In May 2024, Priya completed a routine review of the firm’s remote access infrastructure. Meridian operated a VPN solution for staff who worked from home: a setup that had been expanded quickly and without much documentation during 2020 and never properly reviewed since.

During the review, Priya identified that the VPN appliance was running firmware that had been superseded seventeen months earlier. A known vulnerability in this version, publicly documented and assigned a CVE, allowed an attacker with network access to bypass authentication under specific conditions.

Priya wrote this up in a one-page internal report, assigned it a severity of high, and submitted it to the IT management channel.

She received no response.

In July 2024, she raised it verbally at the monthly IT and operations meeting. She was told by the senior partner responsible for technology that the vulnerability was “theoretical because we haven’t been attacked,” that the environment was unusual enough that the specific exploit conditions were unlikely to apply, and that they would “look at it next quarter when the budget cycle resets.”

In August 2024, Priya submitted a second written report, this time including the CVE number, a link to the NCSC advisory, and a cost estimate for the patch deployment: approximately four hours of her time plus a scheduled maintenance window.

She was asked, at the next team meeting, whether the issue was “genuinely urgent or one of these security-industry things.”

Priya began looking for a new job in September 2024.


The Attack

In November 2024, Meridian’s systems were compromised.

The initial access point was the unpatched VPN appliance. The attacker exploited the documented vulnerability to gain a foothold without valid credentials. From there, they moved laterally through the internal network over a period of approximately eleven days.

Two factors substantially increased the blast radius. First, a number of internal accounts had accumulated administrative permissions over time, including accounts used by staff whose roles did not require admin access but who had been given it for convenience during a system migration two years earlier. Nobody had cleaned up the permissions after the migration was complete.

Second, several staff members had been using a third-party AI notetaking application in client meetings. This application had been introduced by one partner who found it useful for summarising meeting notes, and had spread informally across the team. It was connected to Meridian’s Microsoft 365 tenant. Nobody had assessed its data handling terms. Client names, financial details, and meeting content had been processed through it for approximately eight months.

When the attacker exfiltrated data, they had access to client financial records, tax information, correspondence, and the meeting note archive from the AI application. Approximately 1,200 client records were affected.


The Discovery

Meridian discovered the breach not through their own monitoring but through a notification from their MSP, who identified anomalous outbound traffic during a routine check eleven days after the initial compromise.

By this point, the attacker had completed their operation. The data had been exfiltrated. The MSP isolated the affected systems within twenty-four hours of discovery.

Meridian’s incident response plan, a document created during the Cyber Essentials certification process, was found in a shared folder. It had not been tested. Several of the contacts listed in it were no longer employed by the firm. The document referred to a backup system that had been decommissioned eight months earlier and replaced with a cloud backup solution that was not mentioned anywhere in the plan.


The Aftermath

Meridian reported the breach to the ICO within 72 hours of discovery, as required under UK GDPR. They commissioned an external forensic investigation. They notified affected clients.

The forensic investigation identified the initial access vector, the lateral movement path, and the data exfiltrated. It also identified the internal reports Priya had submitted in May and August 2024.

The ICO investigation considered these reports as evidence that the firm had been aware of a material vulnerability and had not addressed it. This is a significant factor in ICO enforcement: the regulatory position distinguishes clearly between vulnerabilities that were unknown and those that were identified but not remediated.

Meridian received an enforcement notice and a fine. The fine was not the largest aspect of the cost. The forensic investigation, external legal advice, client notification, and remediation work consumed significantly more. Several long-standing clients terminated their engagement with the firm. One client, a logistics business whose payroll data was among those exfiltrated, pursued a civil claim.

The total financial impact over eighteen months was estimated internally at approximately £380,000.

The senior partner who described the vulnerability as “theoretical” is no longer with the firm.


What the Pattern Shows

I want to draw out the specific factors in this case, because they are not unusual.

A known vulnerability dismissed as theoretical. The CVE existed. The NCSC had published an advisory. The patch was available. The business chose not to apply it on the basis that exploitation was unlikely given their environment. This reasoning was incorrect.

A warning documented and ignored. Priya’s reports existed in writing. They included the CVE reference, the NCSC advisory link, and a cost estimate. The firm’s decision not to act on them was not ignorance. It was a considered choice that turned out to be wrong.

Permission creep amplifying the blast radius. The lateral movement was enabled not just by the initial vulnerability but by excessive permissions that had never been cleaned up after a migration. This is a separate and independently addressable problem.

Shadow tooling creating unassessed data exposure. The AI notetaking application was not the initial access point. But it substantially increased the volume and sensitivity of data the attacker was able to exfiltrate, and it had been introduced with no governance, no assessment, and no awareness of what data was being processed through it.

An incident response plan that had never been tested. The plan existed for compliance purposes. It failed in practice because it had not been maintained and had never been exercised under real conditions.


What Meridian Should Have Done

This is the easier part to write.

The patch for the VPN vulnerability would have cost four hours of internal time and a maintenance window. The Priya problem was actually a process problem: there was no route for a technical concern to reach a decision-maker and receive a formal response. Creating that route costs nothing.

The permission cleanup was a half-day project. The AI tool governance required someone to read the terms and make a decision: approved with restrictions, replaced, or discontinued.

The incident response plan required a quarterly review and an annual test. Neither happened.

None of these are expensive interventions. None require specialist knowledge beyond what Priya was already bringing to the team. What they required was a business culture that responded to uncomfortable information with curiosity rather than dismissal.

The forty-two employees of Meridian Professional Services, and the 1,200 clients whose data was exfiltrated, deserved that culture.


What This Means for Your Business

  1. Document, don’t just discuss. If a security concern is raised verbally and does not receive a formal written response within one week, it has not been acknowledged. Create a process that produces a paper trail.

  2. Assign severity and a response obligation. A high-severity finding should require a formal response within five working days. That response should either commit to remediation with a timeline, or document the risk acceptance rationale. “We’ll look at it next quarter” is not a response.

  3. Know what data your tools are touching. Before any third-party application is connected to your business systems, assess what data it accesses and where that data goes. This applies to AI tools in particular.

  4. Test your incident response plan. Not review it. Test it. Walk through the first four hours of a hypothetical breach with the people who would actually be in the room. You will find gaps. That is the point.

  5. If someone is warning you, listen. This is the most important item on the list. The Priya problem is not a technical problem. It is a leadership problem. The £380,000 outcome was not the price of a VPN vulnerability. It was the price of five months of dismissing a well-documented warning from someone whose job it was to identify exactly this kind of risk.


Sources and Basis

SourceArticle
ICOICO Enforcement Actions and Fines Register
NCSCVulnerability Management: Patching Guidance
ICOData Security Incident Trends
DSIT / UK GovernmentCyber Security Breaches Survey 2025
NCSCIncident Management: NCSC Guidance
ICOGDPR: Personal Data Breaches — Reporting Requirements

Note: Meridian Professional Services is a fictional composite case study. Patterns and regulatory consequences are based on published ICO enforcement decisions and NCSC guidance.


Related Posts:


Filed under

  • Case Study
  • UK Business
  • Security Culture
  • ICO Enforcement
  • SMB Breach