You bought the company and inherited the system that is not in your inventory

On 11 November Maersk confirmed a security incident, and the sentence that matters does not describe the attack: it describes the place. The unauthorised access and data extraction happened on a legacy local system which the company says came "from a previous acquisition". Not the ERP. Not email. Not the platform that moves the containers. A machine that once belonged to another company and that, when it changed owner, did not change custodian.

We don't move containers, and you probably don't either. But we have seen that system inside twenty-person companies: the server that arrived when a branch was absorbed, the box the departing provider left running, the application that was going to be there six months and has been powered on for nine years. It always has the same biography: it works, nobody looks at it, and it is on no list. And when something happens inside it, the notification deadlines run exactly as if it had happened on your own long-standing machine. The clock does not ask who owned the server.

What the company says and what only the extortionist says

It is worth separating the two columns before drawing conclusions, because almost all the noise of these days mixes them.

Both columns can be true at once. "No sensitive data has been disclosed" and "data left that box" fit in the same week, and they still leave work behind: somebody has to prove what exactly was on that machine. If it is not inventoried, that proof starts by reconstructing it from scratch, under pressure, with the clock running.

Three public dates and one that never gets published

Lined up, the dates tell the story better than any analysis:

Between the first and the third there are four years, two months and eleven days. That is how long a system can live inside a group without anyone claiming it. Not because the integration was bad: because every integration prioritises what invoices — finance, orders, email, payroll — and leaves what nobody sees for "later". Across 223 warehouses there is a great deal of "later".

Why the inherited system is the most fragile thing you run

It is not bad luck, it is structural. A system that arrives from outside skips, one by one, every control you apply to what you build yourself:

We say it often because it is the axis of everything we do: failure is inevitable, an outage is a design decision. A disk dying in a replicated machine is maintenance paperwork; the same disk in the inherited box nobody looks at is a very long week.

The notification clock does not ask who owned the machine

This is where it stops being a technical matter. If that system held personal data, Article 33 of the GDPR requires you to notify the supervisory authority — the AEPD in Spain — without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk. Not 72 hours from understanding what happened: from knowing. And the notification asks you to describe which categories of data and roughly how many data subjects are affected. That sentence, applied to an uninventoried machine, is the expensive part of the incident.

If you are also in scope for NIS2, Article 23 adds a staggered clock: early warning within 24 hours, notification within 72, and a final report within a month. And here comes the Spanish nuance many people use as an excuse: NIS2 is still not law in Spain. The transposition deadline expired on 17 October 2024, and on 8 July 2026 the European Commission referred Spain — along with Ireland, France and the Netherlands — to the Court of Justice, asking for a lump sum and daily penalties until transposition is notified.

And there is a far faster route than the official gazette for this to reach you: your customer's questionnaire. We wrote about it back then in NIS2 in Spain: the law is not here yet, your customer's questionnaire is, and it still holds. Whoever buys from you is already asking about your asset inventory even if the legislator has not got there yet.

The six questions we ask when we take over an inherited infrastructure

This is not a 200-control audit. These are six questions that, in one afternoon, tell you whether you have a problem or just an old box. What matters about each is the shape of the answer: if it is a name and a date, fine; if it is "the guy before me handled that", you have work ahead.

The same company, two outages that look nothing alike

This company is already a staple of resilience talks because of 2017: NotPetya cost it between 250 and 300 million dollars, by its own chairman's account at Davos, and the rebuild recounted at the time was 4,000 servers, 45,000 PCs and 2,500 applications brought back in ten days. That one stopped the business: container terminals run by hand, ships waiting.

This week's is the other kind, and that is what makes it the more useful example: it has not stopped a single ship. Nobody will put this in a keynote with photos of idle cranes. And it still opens a forensic investigation, notification duties, customer calls asking whether their data was in there, and an uncomfortable question at the next board meeting. There is a third category between a failure and an outage: the incident that does not stop you, but obliges you. Redundancy is no help for that one; knowing what you have is.

When NOT to touch anything

Not every inherited system deserves a migration project, and selling you one would be the easy move. If that machine holds no personal data, carries no credentials that work anywhere else, talks to neither the Internet nor the corporate network, and its purpose is understood, the right answer is cheap: document it, put it in the inventory with an owner and a review date, leave it on its VLAN and get on with your life. The mistake is not having an old system; the mistake is not knowing you have it.

And the flip side: do not rush to switch it off on a Friday afternoon to get the problem off your desk either. Blindly powering down a system that an unmapped process depends on is, literally, choosing your own outage. First you look at who talks to it; then you decide.

What you buy when you buy a company

You buy its book of business, its people and its warehouses. You also buy its ownerless servers, its local accounts, its data processing agreements and its maintenance debt. The first set shows up in the valuation; the second shows up four years later, on a Saturday, in an extortion listing. Between the two there is only an honest inventory and somebody with a name next to each machine. It is boring work, and it is exactly what separates an incident from a crisis.

At everyWAN we build that inventory and the plan that holds it up as part of compliance and continuity, and we stay on afterwards to maintain whatever remains powered on through IT maintenance. Not for the dashboard screenshot: because the day you have to write a notification within 72 hours, having it or not having it is worth exactly those 72 hours.

Sources (verified on 11 Nov 2026): Maersk statements on the incident and the inherited local system, which the company describes as coming "from a previous acquisition" — The Register and Container News; extortion listing of 7 Nov 2026 (100 GB claimed, $5M, 30 days, "your OCF / LF Logistics platform" named verbatim), as reported by trade coverage and public extortion-site trackers; closing of the LF Logistics acquisition on 31 Aug 2022 for $3.6bn and 223 warehouses — maersk.com; referral of Spain to the CJEU over NIS2 on 8 Jul 2026 and the 17 Oct 2024 transposition deadline — European Commission; 72-hour notification duty — GDPR Art. 33; 24 h / 72 h / 1 month deadlines — NIS2 Directive Art. 23; Spanish framework in force — Royal Decree 43/2021. Cover photo: "Warehouse filled with stacked pallets…", by Shixart1985, CC BY 2.0, via Wikimedia Commons (cropped).