Industrial cybersecurity as an obligation: duties, notifications and evidence

Three sources of duty that get conflated

Sectoral regimes reach organisations whose disruption would affect essential services or supply, and they typically concern governance, risk management and reporting rather than specific technical controls. Product-side expectations attach to what you sell: connected machinery, controllers and software increasingly carry security requirements as a condition of market access. Customer requirements arrive through contracts and questionnaires with their own deadlines. The three ask overlapping questions in incompatible formats, which is why a single internal evidence set mapped to each request beats answering every enquiry from scratch. Mapping each incoming question to that internal set also reveals where the genuine gaps sit.

Incident notification runs on a clock you cannot negotiate

Where a reporting duty applies, the demanding part is not the report but recognising in time that something reportable happened, deciding under pressure whether it meets the threshold, and reaching the right authority while the incident is still live. Manufacturers with thin out-of-hours cover discover the gap at the worst moment. Establish in advance who can make the call, who contacts which body, what information is expected in a first notification, and how the decision is recorded. Practising it once is worth more than a written procedure nobody has read.

The evidence set that answers most requests

Whoever asks, the underlying questions converge: what assets exist and who owns them, how the control network is separated from business systems and from vendor access, how remote connections are authenticated and logged, how changes are managed, what backups exist and when they were last restored, and who does what during an incident. Holding this as a maintained set of artefacts rather than as tribal knowledge is the difference between a two-day response and a three-week scramble. The asset inventory is the foundation and is usually the weakest item. Few plants can name every device on the control network without sending somebody to look.

Selling connected equipment brings duties with a long tail

A manufacturer whose products contain software or connectivity may face expectations to handle vulnerabilities, provide updates and communicate with customers about weaknesses over the product's supported life. That is unfamiliar to firms whose machines were previously shipped and forgotten, and it implies a route for someone outside the company to report a problem and get a response. It also raises awkward questions about equipment already in the field with components no longer supported by their own suppliers, which is a portfolio decision rather than a technical one. Decide what supported life you are prepared to state before a customer decides it for you.

Reading the duty from the authority, not from a vendor

National cybersecurity authorities publish scope guidance and reporting mechanics; standards bodies publish the technical frameworks, including the IEC 62443 series widely used for industrial systems; and government cyber agencies issue advisories. The engineering practice of segmenting and hardening a plant is covered in our automation material. What this page cannot do is tell you whether a regime applies to your entity, because that turns on sector definitions and size tests decided nationally. Take the scope question to the competent authority or to counsel. Vendor marketing describing a product as compliant is not evidence about your own position.

Frequently asked questions

We are a mid-sized parts maker. Do sectoral cyber duties reach us?

Scope tests usually combine sector and size, so many independent component manufacturers sit outside direct regimes while suppliers to energy, water, transport, healthcare or defence chains may not. Even where no statutory duty applies, large customers frequently impose comparable requirements contractually, and their questionnaires can be more prescriptive than the law. Establish the statutory position with the competent authority in your country, then treat customer demands as a separate commercial workstream.

What does a customer security questionnaire usually want to see?

Beyond policies, the substantive answers concern network separation between office and production systems, control of vendor remote access, patching approach for equipment that cannot be taken offline, backup and restoration evidence, incident response arrangements and personnel security. Answers that describe intentions rather than implemented controls tend to trigger follow-up or an audit. Where a control genuinely does not exist because of legacy equipment, saying so with a compensating measure reads better than an optimistic tick.

Who should own this in a factory with a small IT team?

Ownership needs to bridge two groups who often barely speak: the IT function that understands networks and identity, and the engineers who own the control systems and will veto anything that risks production. A single named owner with authority over both, supported externally where specialist depth is missing, works better than assigning it to whichever team answered the last questionnaire. Senior sponsorship matters because most meaningful changes require planned downtime.