When the business system stops: map cyber dependencies in defence manufacturing
A factory workstation is available and the machine beside it appears healthy. The business system holding the approved job instructions is unavailable. Can the next batch proceed?
For a defence manufacturer, that question connects cyber resilience with delivery, quality and safety. Restoring a computer is only one part of recovering the ability to do the right work with the right evidence. A production team may depend on information and approvals that sit outside the equipment itself.
This guide offers a fictional tabletop exercise for delivery, quality, IT and operational technology colleagues. Operational technology, or OT, means systems that monitor or control physical processes. A tabletop discusses a scenario using agreed materials; it does not interrupt live equipment or test a production network.
The current guidance behind the question
The NCSC’s secure OT connectivity guidance, Principle 1, published on the page as 14 January 2026, calls for documented, risk-informed decisions about connections. It asks owners to consider safety, loss of connectivity, new dependencies and tested fallback arrangements. These principles describe desirable outcomes rather than a universal minimum checklist.
The original exercise below applies that dependency question to a fictional defence supplier. It is not an NCSC case study and does not describe a known attack. Its purpose is to help a team discover which questions need an authorised answer before disruption occurs.
Choose a delivery outcome rather than an asset list
Start with a small outcome such as “produce and release one approved batch”. An asset inventory might tell you which servers exist. An outcome makes the team explain which services, people and records must work together before that batch can legitimately leave the site.
Include the production supervisor, quality representative, IT service owner, OT specialist and incident coordinator in the exercise. A commercial or delivery representative can explain customer commitments. Use approved descriptions of dependencies. Avoid distributing detailed factory architecture or programme information in a general workshop invitation.
1. Find the information that makes the work valid
Purpose: Separate the ability to operate equipment from the authority to use it for this job.
Ask where the current approved instructions, configuration references and acceptance criteria are held. Establish who can confirm that the version available is the version authorised for the work. Include the records needed to demonstrate completion and release.
For the exercise, represent these as fictional references rather than real drawings or customer requirements. Ask what happens if the authoritative system cannot be reached. An old local file may be readable without being suitable for production. Record who can decide whether an alternative is permitted.
2. Trace the less visible supporting services
Purpose: Find dependencies beyond the system named in the outage.
Ask whether the workflow depends on identity services, a licence service, a supplier portal, time synchronisation or a separate approval tool. These are prompts for investigation, not a claim that every plant uses them. Let the actual owners confirm which relationships exist.
Create one sentence for each confirmed relationship: “This step needs this service because it provides this function.” Then ask whether that function is needed continuously, at job start, during a change or before release. Different timing can produce different consequences during the same outage.
3. Describe the authorised degraded mode
Purpose: Make limits clear before pressure builds to keep production moving.
Ask the accountable operational and quality owners which activities, if any, may continue under the existing approved contingency arrangements. Record the conditions, limits, evidence and decision authority. If there is no approved fallback, record that gap rather than inventing a workaround in the meeting.
“The machine still runs” is an observation. “The next batch may proceed” is a decision requiring its own basis. A permitted pause can be the appropriate outcome. Do not bypass interlocks, improvise network connections or use an unapproved personal device to keep the exercise moving.
4. Define what recovery must demonstrate
Purpose: Prevent service availability from becoming the only restart criterion.
Ask what evidence the responsible owners need before normal work resumes. Discussion prompts include service integrity, current instructions, reconciled work records and any quality checks required after the interruption. Technical, operational and quality owners may each have a necessary part in that decision.
Agree who coordinates those confirmations and how they reach the people on shift. A message saying “IT is back” may leave production unsure whether the relevant information has been checked. Use the organisation’s authorised recovery and restart process for the actual system.
A fictional ninety-minute interruption
Illustrative scenario: a fictional components supplier loses access to its business planning service during a scheduled batch. The equipment remains available. The team has locally accessible instructions, but their approval status cannot yet be confirmed through the usual system.
At the first discussion point, ask which activities are permitted under existing contingency arrangements and who decides. At the second, introduce a proposed job change from the planning team. Ask whether that changes the basis for proceeding. At the third, announce that the service is reachable again but some work records have not been reconciled.
The exercise is complete when the team can name the unresolved questions and owners. It does not need a heroic workaround or a successful production restart. A useful finding might be that the shift supervisor has no clear route to obtain a quality decision outside normal office hours.
Measure decisions rather than confidence
Record how long participants take to identify the right decision maker and locate the relevant approved procedure. Note contradictory assumptions and missing contacts. Do not turn a tabletop into a claim that the recovery time has been achieved on real systems.
Choose one improvement afterwards: clarify the dependency record, repair the contact route or ask the accountable owner to review an uncertain contingency. Give it an owner and a review date. Testing any proposed operational change requires its own approved plan, qualified people and safe conditions.
Keep the record useful and appropriately protected
A dependency map can reveal where a supplier is vulnerable. Store it through approved arrangements and share only what each audience needs. Customer updates can explain an agreed delivery impact without exposing the internal system relationships behind it.
The starting action is small: pick one production outcome and ask which business service could prevent its safe, authorised completion even while the equipment remains available. That question connects cyber recovery to the work the supplier actually needs to deliver.
Sources and review
Reference: NCSC secure OT connectivity, Principle 1, page publication date 14 January 2026. The batch scenario, discussion sequence and review prompts are original editorial exercises. They do not specify plant controls or authorise changes, fallback operation or a restart.
You May Also Like
Is Scrum Right for Your Team? A Practical Guide to Making the Right Choice
Six Sigma and the Delicious Dominance of Domino’s Pizza
