Part 1 · assessment and mitigation recommendations · published v1.0 · 14 October 2026

The business stops when supporting IT stops

SC07 · Manufacturing · logistics · distribution

Real incident Client risk Possible routes Assessment Recommendations

What really happened

JLR announced a phased manufacturing restart on 7 October 2025 following its early-September cyber incident, alongside a financing measure to support qualifying suppliers’ cashflow.

JLR · manufacturing restart statement, 7 October 2025

Evidence limit: The company statement demonstrates operational and supplier impact. It does not identify an initial intrusion route; the proposed routes below are assessment hypotheses.

The question for the client

Which digital dependency could halt our operation, and can we contain an incident and restore essential work?

Business impact: Lost output, missed deliveries, supplier cashflow pressure and prolonged recovery. Effects may spread beyond the directly attacked organisation.

Systems involved: Identity, production scheduling, warehouse/ERP systems, supplier connections, administration, backups and recovery dependencies.
Where people fit: IT responders and business owners must coordinate priorities; suppliers may carry access and recovery dependencies. Technical failure and response decisions can both interrupt operations.

How a similar risk could develop here

Proposed client threat model, not a reconstruction of undocumented incident details.

Compromise an identity, exposed service or supplier route → expand reach through weak boundaries → disable or encrypt essential supporting systems → disrupt production and supplier operations.

Each route depends on several controls. If one stage is blocked, later checks can only continue as a separately authorised, clearly labelled assumed-compromise test. Do not claim an end-to-end attack succeeded merely because a downstream test identity was supplied.

Referenced attack-vector guides

Approval is specific, never inherited from the guide. Check the client, campaign, individual person/asset, method, channel, time window and risk ceiling. Deny overrides allow; absent, expired or withdrawn permission blocks the action. LOW/MED/HIGH describe proposed test impact, not permission or finding severity. Read the approval rules.

Assessment playbook · Part 1

Start with G01 scope and Target Management, G02 intelligence gathering where needed, and G03 tool/resource preflight. Each selected vector receives its own scoped invocation record.

SC07-S01LOW · proposed test impact

1. Map the business dependencies

Identify essential services, allowable downtime and the identity/vendor dependencies needed to recover them.

Why this is needed

It tests a barrier in the route above and helps answer: Which digital dependency could halt our operation, and can we contain an incident and restore essential work?

Vector / method

Tools and guides

Target Management / CRM · native service; handoff is not automatic execution
Business continuity owner · client/operator supplied

Repository input

recovery-matrix.csv · RES-026 · published assessment resource; pin its version/hash in the case record.

Output

Business dependency map; attach evidence, target ID, vector version and approval revision.

Measure

Critical dependencies with verified owner and recovery input / selected dependencies. Agree the acceptance threshold before testing; state raw counts, denominator, conditions and limitations. Compare prohibited cases with a permitted/clean control.

Current result

NOT ASSESSED. This is a prepared playbook; no client test or finding is being invented.

Recommendation on failure

Document the missing service dependency and realistic recovery requirements. Define an observable acceptance criterion for a later retest. No implementation work is allocated now.

SC07-S02MED · proposed test impact

2. Check containment in a lab

Test approved identity and network boundaries using benign events and clean controls; do not deploy ransomware.

Why this is needed

It tests a barrier in the route above and helps answer: Which digital dependency could halt our operation, and can we contain an incident and restore essential work?

Vector / method

Tools and guides

Repository input

network-flows.csv · RES-019 · published assessment resource; pin its version/hash in the case record.

Output

Boundary and detection report; attach evidence, target ID, vector version and approval revision.

Measure

Prohibited paths blocked; detection and containment decision times. Agree the acceptance threshold before testing; state raw counts, denominator, conditions and limitations. Compare prohibited cases with a permitted/clean control.

Current result

NOT ASSESSED. This is a prepared playbook; no client test or finding is being invented.

Recommendation on failure

Reduce the evidenced privilege or network path and improve detection of the approved benign event. Define an observable acceptance criterion for a later retest. No implementation work is allocated now.

SC07-S03MED · proposed test impact

3. Measure isolated recovery

Restore an agreed sample into isolation and validate representative business functions.

Why this is needed

It tests a barrier in the route above and helps answer: Which digital dependency could halt our operation, and can we contain an incident and restore essential work?

Vector / method

V09 · Lateral movement, data theft and ransomware impact

Tools and guides

Client backup/restore tooling in isolation · client/operator supplied

Repository input

recovery-matrix.csv · RES-026 · published assessment resource; pin its version/hash in the case record.

Output

Recovery evidence and assurance gaps; attach evidence, target ID, vector version and approval revision.

Measure

Actual restore time; data age; business cases passed / executed cases. Agree the acceptance threshold before testing; state raw counts, denominator, conditions and limitations. Compare prohibited cases with a permitted/clean control.

Current result

NOT ASSESSED. This is a prepared playbook; no client test or finding is being invented.

Recommendation on failure

Improve the failing backup, identity, application or business-validation dependency; establish evidence before claiming recovery readiness. Define an observable acceptance criterion for a later retest. No implementation work is allocated now.

Use one step-result record per case and G06 reporting for the client deliverable. The report must explain successes, failures, uncertainty, prohibitions and coverage limits.

Recommendations to reduce the risk

Reduce the likelihood: Reduce exposed entry points and privileges, validate supplier access and improve containment boundaries.

Reduce the impact if it happens: Protect and test backups, reduce critical single dependencies and rehearse business continuity decisions.

How to verify improvement later: repeat the failed control case and a permitted/clean comparison using the same agreed measure; compare conditions and evidence. A better test pass rate alone is not a quantified reduction in business risk.

End of Part 1: evidence-backed findings and mitigation recommendations. The implementation action plan, allocated work, commercial service packaging and costs are deliberately deferred.

Supporting TenguProtect capabilities

Baseline from the 13 October operational audit. This does not claim the complete service is ready or that permissions are already enforced across every agent.

Capability	Observed readiness	Remaining gap
Network exposure, segmentation and ransomware containment	Partial; selected network fixture required	Verify tools under the real worker account and demonstrate findings, exceptions and retest on a small owned network.
Active Directory and privileged identity	Partial; verified launcher failures	Repair selected Impacket-related and Evil-WinRM runtime issues only if needed, then prove collection and reporting in an isolated directory lab.
Detection validation and purple-team exercises	Operator platforms live; end-to-end exercise unproven	Choose one primary platform, define safe techniques and prove a lab exercise, evidence export, cleanup and defender acceptance before client delivery.
Ransomware preparedness, backups and recovery	Recovery readiness unproven	Define recovery-time and data-loss targets; verify off-host backups and perform an isolated restore. Existing rollback archives are not a full recovery test.