When Stopping The Attack Means Disrupting Your Own Organisation

“When a Vendor Becomes Unsafe, Speed Determines the Outcome” examined how your teams can narrow an unsafe supplier connection and control what runs when they restore it.

Jaguar Land Rover’s protective shutdown disrupted retail and production, creating an operational burden that continued into the restart. A restriction can be technically narrow and still interrupt work across shifts or suppliers. Your service owners need to know what the alternative can carry and when it will reach its limit.

“The Attack Did Not Wait for the Meeting to Finish” follows a proposed restriction through a live discussion as new attacker activity changes the access that responders need to interrupt.

On 2 September 2025, Jaguar Land Rover reported that it had proactively shut down systems to mitigate a cyber incident. Retail and production activities were severely disrupted. The protective action and its operational cost appeared together in the company’s first statement.

In June 2026, The New York Times reported that the attackers had used novel ransomware with an encryption method that some investigators had never seen in a previous attack.

A shutdown can be necessary while creating another urgent task. Production schedules, supplier commitments and customer obligations continue after systems are taken offline. The people responsible for those services need to understand what can still be done and how long the alternative arrangements can hold.

JLR described the shutdown as action to mitigate the incident. The public statements establish the purpose of the shutdown and the disruption that followed. For your executive team, the comparable decision is to weigh the expected interruption against the exposure of leaving the affected systems available.

Broad isolation may be appropriate when several systems appear affected. The joint StopRansomware Guide recognises that isolating individual systems may be impractical when an incident reaches several systems or subnets. Your executive team should judge the response against the exposure and options understood at the time.

Once the restriction is in place, service owners need to identify which work has stopped, who depends on it and how long it can be deferred. A stopped production line may be visible immediately. The orders, payments and supplier commitments affected by the shutdown can take longer to trace.

Consider an illustrative production service that shares an account with an overnight order-transfer process. Restricting that account may address a credible threat and stop the transfer. The technical change affects one account. Its operational consequence reaches the people preparing the next shift’s work.

The service owner needs to explain that dependency without turning the explanation into an open-ended request to leave the route available. Security needs to explain the exposure addressed by the restriction. Together, those accounts give the incident lead a basis for choosing the intervention and deciding how the interrupted work will be handled.

A targeted restriction can preserve more options when it covers the activity that needs to stop. Check the services that depend on the same account or connection. If the incident has moved beyond that scope, a wider restriction may be necessary despite its greater service cost.

JLR’s 7 October statement described a phased manufacturing restart alongside supplier support: a help desk, manual settlement of outstanding invoices and the return of automated payments. Supplier financing also formed part of the response. The work of sustaining operations had extended beyond restoring access to a system.

For the illustrative production service, a manual order transfer might keep selected work moving. Someone still needs to establish its capacity, check the information being transferred and decide which orders take priority. Staff may be able to handle a short interruption without being able to sustain the same workload for several days.

The fallback has to respect the restriction. An improvised transfer that reopens the unsafe route can undo the protective action. If your teams cannot establish a safe alternative, keep the service paused and assign responsibility for the backlog, supplier impact and staffing pressure.

Service owners should report when those arrangements approach their limits. An alternative that works for the first shift can leave the next shift with incomplete records or an unmanageable queue. The incident team needs that information while deciding whether to maintain, change or widen the response.

When ransomware begins encrypting files on a protected share, our platform can cut off the source before more files are affected. Ransomware Containment detects active encryption on supported SMB and NFS file services without endpoint agents. Depending on the configured response, it can automatically disable the affected account in Active Directory, disconnect the affected laptop by disabling its network adapter, or shut down the device.

Each action interrupts different work. In the production example above, disabling the shared account would also stop the overnight order transfer, even if the systems that process the orders remain available. Your service owner needs to know which orders must reach the next shift and how to get them there safely while the account remains disabled.

A useful exercise starts with a service your organisation depends on and a restriction that would interrupt it. Ask the service owner how much work could still be completed per shift, what must be deferred and when the backlog would exceed the available capacity. Include a dependency whose interruption affects another team or supplier.

Use those answers to decide whether the alternative needs more capacity, a dependency can be reduced or a pause must be accepted. Where work moves to a supplier or another team, give that team a chance to test its own capacity before relying on it.

If the restriction lasts beyond the first shift, who will recognise that the fallback has reached its limit, and what work will they stop accepting?

“The Attack Did Not Wait for the Meeting to Finish” picks up before a restriction has been applied. It follows an incident team weighing the disruption of ending a remote session, then learning that the same account is active on another server. The decision now has to account for both routes.