Business continuity

When a cyberattack stops business.

October 15, 2026 6 min read

In autumn 2025 a cyber incident halted Jaguar Land Rover's production for around five weeks and rippled through its supply chain. The lesson for a smaller business is uncomfortable: you can be fully operational and still unable to trade, because the systems you depend on belong to someone else.

See what the case shows → Talk through your resilience

You don't have to be the target to be hit. The Jaguar Land Rover incident is a clear, recent example of how an attack on one large organization becomes an operational and cash-flow problem for the smaller businesses around it — even when their own systems stay available.

For an SMB, the practical risk is rarely only your own security. It is your dependence: a major customer that stops ordering, a supplier that cannot ship, or a shared system that goes dark and takes your orders, invoices, or schedules with it.

The useful test is not whether you could be breached. It is whether you could keep trading, and keep records straight, if a system you rely on — yours or someone else's — were unavailable for a week.

What the JLR case actually shows.

Sticking to what the official sources establish, rather than the unconfirmed claims around it:

The disruption lasted weeks. JLR halted production after the September 2025 incident and began a phased manufacturing restart from 8 October.
Payment processes were affected. JLR moved to manual supplier payments for a period before restoring automated systems, and later introduced a financing scheme to pay qualifying suppliers early.
Suppliers needed active support. JLR set up a supplier help desk and accelerated payments for qualifying suppliers to ease the cash-flow strain. JLR's recovery and financing announcement sets out the detail.
The impact spread down the chain. The UK government and the SMMT acknowledged a significant impact across the wider automotive supply chain, much of it smaller firms. Government–industry joint statement, 19 September 2025.

Note what these sources do not establish: the attacker's entry point, or any particular security failure. So the transferable lessons here are about resilience and operational fallback — not blame, and not a checklist that would have "prevented" it.

Four ways a partner's outage hits you.

These are illustrative exposures, not predictions about any specific business.

Area What can break for you Practical preparation What to check

Orders & records A shared system holding live orders and customer details goes dark Keep an exportable, current copy of open orders and key customer data Can you see outstanding work without the partner's system?

Communication Customers can't reach you, or hear nothing while you scramble A pre-agreed channel and a ready holding message for an outage How fast can you tell customers what's happening?

Payments Automated invoicing or payment runs stall A manual way to pay critical suppliers and chase what you're owed Could you pay staff and key suppliers by hand for a week?

Trading continuity Work halts because one input or customer is unavailable A known fallback for the critical step, and a restart plan How long can you trade before the stoppage really bites?

Each row is the same question in a different place: when this goes down, what do we do instead, and who owns it?

Keep trading through the outage.

The goal of a plan is not to look prepared. It is to let the business keep operating, on paper if it has to, while systems are down.

When a key system or partner goes down, switch to a known fallback, keep records by hand, tell customers what's happening, and reconcile once systems return.

JLR's shift to manual supplier payments is the pattern in miniature: when the automated path failed, the work continued by hand until systems returned. A smaller business needs the same — a fallback it has actually tried, not one it assumes will work.

Prepare before, not during.

General continuity advice holds up, as long as you treat it as preparation rather than a guarantee:

Know your dependencies. List the unsupported software, missing updates, and overlooked systems — including the ones you rely on but do not own.
Test recovery for real. Confirm that your backups actually restore working operations, not just that the backup job ran. An untested backup is a hope, not a plan.
Limit access. Review administrator permissions and keep sensitive systems separated, so one compromised account does not reach everything.
Prepare a response. Assign who does what, and practise a scenario — including the low-tech one where the main system is simply unavailable.
Train the team. Give staff a clear, simple way to recognize and report something suspicious, and to follow the fallback when it is needed.

One honest caveat: no checklist prevents every incident, and claims that a product "ensures" protection deserve suspicion. The strongest, most transferable lesson from JLR is narrower and more useful — verify that you can recover and keep operating, rather than assume your protection is enough.

Build the fallback you can prove.

Resilience is worth paying for only if it works when tested. Decide which customer, supplier, or system you cannot trade without; write down the manual fallback for each; and actually run it once, in a quiet week, before you need it in a bad one. Measure how long you could keep going, and where the plan breaks.

For CYBERCUBE, the useful starting point is the single dependency whose outage would hurt most — a shared ordering system, a payment process, a key supplier's portal. Map the fallback, keep your own copy of the records that matter, and test that you can keep trading before an outage forces the question. Tell us where your business can't afford to stop, and we can help design a dependable fallback.