Breached (Part 2)

What They Did Wrong

This account is based on a real-world case. Names, locations, and identifying details have been changed or obscured to protect those involved and, frankly, to save a few blushes. (Missed Part 1 - See here)

The firewall had been changed 31 days before the breach.

It should have been a simple job. The kind of upgrade no one thinks about again. New box. New firmware. Clean handover.

But someone had missed something.

On Day 1, shortly after Katie’s call with the NCA, her MSP—Harwood IT Solutions—was contacted. A support ticket was opened. At 4:42 p.m., a note was added to that ticket by a junior tech:

Misconfiguration suspected on new firewall install. Likely vector. Do not tell the client.

Katie Roberts was copied in by mistake.

Day 2.

I arrived on-site just before 9 a.m. The weather was grey and close. The sort that presses on your chest. I’d been engaged as the Incident Manager that morning and came straight in.

I was shown into the server room, offered tea, and handed a Wi-Fi password written on a post-it note stuck to a whiteboard.

I asked for the firewall configs.

They hesitated. Said someone would “dig them out.”

By 10:00 a.m. I’d seen enough. I asked for a face-to-face meeting the next morning—11 a.m., boardroom, no excuses. I wanted Harwood’s Account Manager and a director in that room.

The response was almost instant: “Oh, not sure that’s possible for tomorrow.”

Not possible.

Not during a breach.

Day 3.

I requested endpoint agents be deployed across the estate. My SOC needed to see inside. Fast.

I asked Harwood to redirect all logging—firewall, VPN, auth—to the SOC. Nothing excessive. Just eyes where eyes should be.

They refused. Said it would “impact their visibility.”

That was their line.

They’d rather no one see anything than risk not seeing it themselves.

The firewall logs I’d requested on Day 2? Still absent.

Day 4.

It was a Saturday. I spent most of it reviewing asset inventories, system notes, and ticket history. Around midday, I sent a structured action list to Harwood. Ten points. All reasonable.

Item 1: Full firewall log dump.

Silence.

Day 6.

Finally, an admission.

They couldn’t provide logs for successful VPN logins. Only failed ones.

Same date range. Same device.

Same dataset.

And they couldn’t explain why.

That evening, Katie gave me sign-off to deploy a lightweight audit tool across the network. Within minutes, the first reports started coming in.

Day 7.

Boardroom. Morning.

Katie sat at the head of the table, sleeves rolled. I placed the report in front of her: 400+ vulnerabilities. Many critical. Some older than their office furniture. Unpatched Windows Server 2016 still running core workloads.

Harwood’s team flipped through the pages. They started talking like lawyers.

“These are old.”

“Already known.”

“Superseded.”

Katie let them talk.

Then she opened her folder.

She read from the printed support ticket. Slowly. Word by word.

The line that mattered?

“Do not tell the client.”

That was when the silence came.

Not technical.

Not procedural.

Human.

Because this wasn’t about vulnerabilities anymore.

It was about trust.

And trust—once breached—isn’t easily patched.