How to Manage Operational Technology (OT) Under DCC

Industrial control systems have traditionally sat outside IT's compliance conversations, too specialised, too fragile, too critical to production to touch.

Defence Cyber Certification (DCC) changes that. If operational technology (OT) is essential to how your organisation delivers its contracted work, it is in scope, full stop.

Why OT can't be waved through

DCC scope is drawn around what an organisation genuinely depends on to operate, not around what happens to be easiest to secure. A CNC machine running around the clock as a core part of production is exactly the kind of system the scheme is designed to capture: lose it, and the business stops delivering. That makes it a legitimate cyber risk regardless of whether it has an IP address on the corporate network.

The scheme's own guidance is explicit on this point: operational technology must be considered where it is essential to the organisation, with appropriate compensating controls applied where standard IT measures cannot be used directly. The second half of that sentence is the important part for technical managers: DCC does not expect OT to be secured the same way as a laptop, but it does expect a defensible answer for how the risk is managed instead.

Why the standard playbook doesn't work here

Most IT security controls assume a device that can be patched, rebooted, and have an agent installed without consequence. OT rarely allows any of that:

• Anti-malware and endpoint agents are frequently unsupported by machine vendors, or simply incompatible with the embedded or legacy operating systems many controllers still run.
• Patching windows are constrained by production schedules; a machine running 24/7 as a core service often cannot be taken offline for updates without a significant commercial impact.
• Reboots and configuration changes carry a real risk of miscalibration, safety incidents, or voided vendor warranties on equipment that may be decades old.
• Network monitoring tools built for IT estates often cannot parse the proprietary protocols OT systems use.

Trying to force standard IT controls onto this environment does not just fail technically; it can create genuine safety and continuity risks that outweigh the cyber benefit. Assessors are not looking for evidence that OT has been forced into the IT mould; they are looking for evidence that its risk has been properly understood and proportionately managed.

What "proportionate" looks like in practice

The path through this is compensating controls, documented clearly enough that an assessor can see the reasoning, not just the outcome. In practice, that tends to draw on a mix of:

• Network segmentation — isolating OT from the corporate IT network and the internet, with tightly controlled, logged pathways where connectivity is unavoidable.
• Secure by Design (SbD) principles — building security considerations into how new OT is specified and procured, rather than retrofitting it after installation.
• Physical and procedural controls — restricting physical access to machine controllers, locking down USB and removable media use, and controlling who can make configuration changes and how.
• Compensating monitoring — where agent-based detection is not possible, monitoring the network perimeter around the OT estate instead of the endpoints themselves.
• Vendor and lifecycle management — documenting end-of-life and unsupported software risk explicitly, with a plan for it, rather than leaving it unaddressed.

The evidence assessors actually want to see

The common failure mode here is not having controls; most engineering-led organisations already manage OT risk informally, through good production discipline and vendor relationships. The failure is not having that risk management written down in a form an assessor can evaluate. A rationale that says, in effect, "we cannot install anti-malware on this controller because X, so instead we do Y and Z, and here is why we consider that proportionate" is exactly the kind of documentation that satisfies a control without forcing an unsafe change onto the shop floor.

Technical managers are usually the best-placed people in the organisation to write that rationale; they understand the constraints better than anyone in IT or compliance. The job for compliance teams is to make sure that knowledge gets captured and mapped against the relevant DCC controls before assessment, rather than surfacing for the first time when an assessor asks the question.

If your organisation has OT in scope for DCC and needs help translating shop-floor risk management into assessor-ready evidence, contact Periculo. We work with engineering and manufacturing teams to document compensating controls that hold up under assessment without disrupting production