Manufacturing cyber risk: test dispatch

Retrospective covering 10 August 2026, written on 9 September 2026. Survey claims come from Make UK's published summary; the exercise is my proposed response.

Manufacturing cyber risk is easier to discuss when the question is whether a customer order can leave the factory. My recommendation after Make UK's August report is to test that specific outcome with operations, IT and purchasing in the same room.

On 10 August, Make UK published findings stating that 30% of manufacturers had experienced a cyber incident during the previous year, directly or through their supply chain. Its summary said only around half had an incident response plan. Make UK report summary.

What the survey tells an IT leader

Make UK also reported delivery delays among manufacturers affected by supplier attacks. The relevant figure was 31% of that affected group, not 31% of all manufacturers. Keeping the denominator attached to the claim matters. Make UK's findings.

The summary is a reason to examine operational dependencies. It is not a substitute for assessing a particular site's exposure, and it does not establish that every manufacturer has the same problems. I have not used it to estimate a financial loss or an individual firm's likelihood of attack.

For an East Riding or wider UK manufacturer, the practical question is local: which interruption would prevent your next dispatch, and who can authorise the response?

Follow one order through the business

Choose an ordinary order with familiar materials and a normal delivery route. Ask a member of the operations team to describe the work rather than starting with the IT asset register.

Record the information needed to accept the order, schedule production, obtain materials, confirm quality, produce dispatch documents and arrange delivery. Note where that information lives and who relies on it. Include any spreadsheet, mailbox or supplier portal that the process owner mentions.

My preference is a simple table with one row per step. The purpose is to make an assumption visible, such as dispatch believing that IT retains a copy of a document while IT believes the logistics provider owns it.

Treat missing answers as work items. Avoid filling them with what the team hopes would happen.

Pick a scenario that exposes a decision

For the first exercise, I would make the order-management system unavailable while a dispatch deadline approaches. This is a proposed scenario, not an assertion about an actual incident.

Ask the team to continue the discussion using only the information it can demonstrate is available. If somebody says they would export the schedule, establish whether that export exists before the outage or depends on the unavailable system.

Introduce a second decision: a supplier cannot confirm the next delivery. Ask who can approve substitution, communicate a delay or change the production plan. Record any action requiring a named person's knowledge or an inaccessible approval route.

A tabletop exercise should produce decisions and gaps. It should not involve switching off equipment to make the scenario feel more realistic.

Keep office IT and production responsibilities clear

The NCSC's operational technology design example emphasises understanding the whole process and involving appropriate specialists, including operators, process control and safety expertise. It also distinguishes business, process and safety functions. NCSC operational technology case study.

My recommendation is to use that distinction when assigning exercise actions. An office-system owner should not casually approve a change to machinery or its control environment. Identify who is competent to assess each proposed action and involve the supplier where necessary.

The first useful outcome may simply be a clearer diagram and a list of decision owners. That is more valuable than a technically ambitious exercise conducted without the people who understand the process.

For broader preparation, use the existing incident response plan guide as a starting point for roles and communications.

Ask suppliers about a specific interruption

Replace a general question about whether a supplier is secure with a question about your dependency. Ask what happens to order status, delivery confirmation or support if the supplier's normal portal is unavailable.

Request an alternative contact route and agree who checks it remains current. For a critical supplier, discuss the information your team needs to continue a limited operation or make a responsible customer commitment.

I would record the answer beside the affected order stage. That makes supplier assurance part of the working process rather than a separate questionnaire stored by procurement. Your ICT supplier risk register can then prioritise follow-up against actual operational consequences.

Test recovery against the next business action

A restored file is useful only if the relevant person can use it. The NCSC advises organisations to understand how to restore backups and check they contain important data. NCSC backup guidance.

For this exercise, ask the process owner to identify the record needed for the next step. Plan a separate, controlled recovery test for that record in an appropriate environment. The acceptance question is whether the restored information supports the intended action, including the version and context the user needs.

Record who accepted the result and what remains missing. Do not turn a successful technical restore into a claim that the whole production process has been recovered.

Report the unresolved orders, not just the controls

The management update should identify the order stages that remain exposed, the decisions needed and the person responsible for each improvement. Where a cost estimate is needed, ask finance and operations to build it from the site's own assumptions.

My preferred next step is to rerun the same scenario after the most important gaps are addressed. That provides a practical comparison without inventing a maturity score. It also connects the business continuity plan to a customer outcome that the board and factory team both recognise.