The server is back. Can production return safely too?

Industrial recovery after a cyber incident has more than one finish line. It is not enough for an administrator to sign in or for a primary server to respond. Planning, material flow, suppliers, logistics, sales channels and the work performed by people on site must all work together. Each layer can be technically available yet still be unready to perform safely at real volume.

On 7 October 2025, Jaguar Land Rover said production stoppages since the start of September were linked to a cyber incident and had affected wholesale volumes. The same announcement described a phased manufacturing return: the Wolverhampton engine plant was due to welcome colleagues back from 8 October, followed shortly by teams in Nitra and Solihull. Source: JLR announcement, 7 October 2025

The timeline itself is instructive. It does not say whether JLR’s backups failed or succeeded, and it does not identify the incident mechanism. It does show a staged return involving several locations. A recovery team should therefore design its plan around business capabilities, not a list of servers.

Operational return has its own dependencies

In its financial update of 14 November 2025, JLR said production had returned to normal levels following the incident. It described restoring vehicle-wholesale systems, restarting its Global Parts Logistics Centre, and fast-tracking finance for qualifying suppliers during the restart phase. It also attributed weaker performance to a combination of the incident, US tariffs, lower volumes and other factors. Source: JLR Q2 FY26 results

That is an important warning against a simple causal story. A revenue or volume decline is not automatically all caused by an attack. Even when a technical service is available again, the company must verify that it can safely support planning, ordering, manufacturing, shipping and invoicing. Recovery acceptance cannot therefore be an IT sign-off alone.

Our analysis and recommendations

We recommend describing recovery through tangible business outcomes. An outcome might be: process an order, release a production schedule, deliver a part, ship a vehicle, repair a customer’s car or settle an invoice. For every outcome, identify its owner, applications, data flows, external partners, manual steps and safe-start conditions. This produces a dependency map that remains useful under pressure.

Backups are necessary, but they do not on their own prove a service can recover. A test should check data readability, restoration order, permissions, network connections, integrations, performance and the operations team’s ability to repeat the procedure. If the only test restores a virtual machine, the business has not yet tested its ability to deliver its product or service.

Split recovery into gates. The first confirms technical integrity and evidence about what remains isolated. The second verifies that critical data and interfaces produce correct results. The third is business acceptance: the accountable operational owner runs a real scenario at a defined volume and confirms that the risk is acceptable. Only then should capacity expand. This may feel slower initially, but it reduces the risk that a faulty or unsafe process stops production again.

Four recovery stages with a gate before each next step: technical integrity, data and interfaces, business acceptance and only then scaling up capacity.
Staged recovery with a gate between steps – approach recommended by SXIZA, not a description of JLR’s internal process.

Exercises must include suppliers and logistics. Agree in advance on contacts, the minimum information needed to continue work, fallback communications and a way to measure the growing backlog. Communicate precisely what is available, what is still being checked, and when the next status update will arrive. JLR’s case shows that recovery has a social and commercial dimension: technology must earn the trust of the people who plan and perform work through it.

Sources