octoplant, NIS2 and IEC 62443: Recovery and Change Evidence for OT

The octoplant NIS2 question comes from European plants that have discovered they are in scope of the directive and need to show an auditor how OT recovery and change are controlled. AMDT lists NIS2 and IEC 62443 among the frameworks its products support (AMDT). The honest summary: octoplant produces strong evidence for backup, recovery, change records and asset knowledge, which are a real part of both frameworks. Neither framework is satisfied by a tool. This page sits under octoplant compliance in the AMDT cluster.

What NIS2 asks of an OT operator, and where octoplant fits

NIS2 (Directive (EU) 2022/2555) replaced the original NIS Directive, with member states due to transpose it by October 2024. It widened scope to many manufacturers: its annexes cover energy, drinking water and waste water, and also food, chemicals, medical devices, electronics, electrical equipment, machinery and vehicles. Most of the work sits in Article 21, a list of risk-management measures. The ones that touch OT change and recovery:

• (b) Incident handling
• (c) Business continuity, such as backup management and disaster recovery, and crisis management
• (d) Supply chain security, including the security of direct suppliers
• (e) Security in acquisition, development and maintenance, including vulnerability handling
• (f) Policies to assess the effectiveness of the measures
• (i) Access control and asset management

Two other articles change the stakes. Article 20 makes management bodies approve the measures and oversee them, with personal accountability. Article 23 sets reporting deadlines for significant incidents: an early warning within 24 hours, a notification within 72 hours and a final report within a month.

What IEC 62443 asks, in the same area

IEC 62443 is a family of standards rather than a law, and in Europe it is the usual technical reference for implementing NIS2 measures in OT. Three parts matter here:

• IEC 62443-2-1 sets requirements for the asset owner’s security programme. Configuration management, backup and restore, and asset inventory are recurring themes.
• IEC 62443-3-3 sets system security requirements, including SR 7.3 control system backup, SR 7.4 control system recovery and reconstitution, SR 7.6 network and security configuration settings, SR 7.8 control system component inventory and SR 2.8 auditable events.
• IEC 62443-4-1 and 4-2 cover the supplier’s development process and individual components. These are what a product certification refers to, and we found none for octoplant. AMDT’s Trust Center lists ISO/IEC 27001:2022, ISO 9001:2015 and TISAX.

How the two fit together. NIS2 says what an entity must achieve and makes management answerable for it. IEC 62443 gives OT teams a vocabulary for how: zones, conduits, security levels and specific system requirements. A plant that frames its backup and change controls in 62443 terms usually finds its NIS2 evidence already organised. The reverse rarely holds, because NIS2 text is too general to test a controller against. One more regulation sits close by: the EU Cyber Resilience Act places obligations on manufacturers of products with digital elements, so it reaches a plant mainly through what its suppliers, AMDT among them, must provide.

octoplant NIS2 and IEC 62443 evidence an auditor asks for

Requirement	Evidence an auditor asks for	octoplant source	What the plant must add
NIS2 21(2)(c), 62443 SR 7.3	Backups exist, are current and cover the asset list	Job history, repository, failed-job alerts	Scope definition, backup policy, off-site copy of the server
NIS2 21(2)(c), 62443 SR 7.4	Recovery has been tested	Known-good versions, restore records	A dated recovery exercise and its lessons
NIS2 21(2)(b)	Incidents are detected and handled	Change detection alerts, compare reports	Incident procedure, triage records, reporting
62443-2-1 configuration management	Approved baselines and controlled change	Approved versions, check-in history, approvals	Change procedure, approver list
NIS2 21(2)(i), 62443 SR 7.8	An asset inventory with versions	Device list, firmware data, octovision inventory	Assets the tool cannot reach, ownership
NIS2 21(2)(e)	Vulnerabilities are identified and handled	octovision CVE matching	Risk decisions, patch plans, compensating controls
NIS2 21(2)(d)	Suppliers are assessed	AMDT certificates, vulnerability reporting channel	Supplier risk assessment, contract terms

Where a change tool earns its place in an incident

An illustrative case. A food plant’s engineering workstation is hit by ransomware on a Saturday. By Sunday morning the incident team needs to know whether any controller logic was altered. A scheduled compare across every PLC, run against the approved versions, either shows no differences or lists the three that changed. That is the difference between an early warning that says “OT impact unknown” and one that says “no controller changes detected; workstations being rebuilt.” The restore side is covered on disaster recovery.

Using octoplant in a NIS2 programme: a practical order

Plants that buy a tool first and define scope later end up with evidence for the machines that were easy to connect, not for the ones that matter. A sequence that holds up in an audit:

1. Agree scope with the risk assessment. Which lines and systems are essential to the service the entity provides? Those assets are in scope first.
2. Build the asset list and compare it with what the tool reaches. The gap is the first finding, and it should be recorded, not hidden.
3. Back up before anything else. A complete, current backup across in-scope assets is the quickest reduction in recovery risk and the easiest evidence to show.
4. Prove one restore per asset class. A PLC, a robot, an HMI and a drive, each restored from the repository and recorded.
5. Approve baselines. Only once versions are approved does change detection mean anything.
6. Route alerts into the incident process. A change alert that lands in one engineer’s inbox is not incident handling. Define triage, escalation and the record kept.
7. Report to management. Article 20 makes management accountable, so give them a short, regular view: coverage, job success, open deviations and the date of the last recovery test.

Where it gets hard

• The octoplant server becomes a crown jewel. It holds every program in the plant and, through jobs, reaches every device. It belongs in a well-defined zone with controlled conduits, as our guide to OT network segmentation in brownfield plants describes, and its own backup belongs off-site.
• Network devices are often forgotten. AMDT partners list switch and firewall configurations among supported device types, with examples such as Hirschmann, SCALANCE, mGuard and Stratix (iOpen). Coverage varies; check the current matrix with AMDT before claiming SR 7.6 evidence.
• Supply chain works both ways. Under Article 21(2)(d), AMDT and its integration partner are suppliers to assess. The absence of a 62443-4-1 certification is not disqualifying, but it should be recorded and reasoned in the assessment.
• Effectiveness has to be shown. Article 21(2)(f) expects the plant to assess whether measures work. Job success rates, alert response times and the date of the last restore test are the obvious metrics.
• National transposition differs. Registration, supervision and penalties vary by member state.

An OT network assessment establishes the zone model and the asset baseline these measures rest on. For the North American equivalent, see octoplant and NERC CIP; for regulated pharma, see octoplant and 21 CFR Part 11.