NIS2 Article 21(2)(c) in Manufacturing: Setting OT-Realistic RTO/RPO When a Cold SCADA Restart Takes Days, Not Hours

In a 2026 benchmark study of manufacturing organisations, only 18% could meet their declared recovery time objectives during an actual restoration test. Not 80%. Not 50%. Eighteen percent. The remaining four in five had set RTO targets based on IT recovery norms — and discovered, under test conditions, that operational technology environments take substantially longer to restore than anyone had assumed.

NIS2’s Article 21(2)(c) has turned that planning gap into a compliance liability. Every medium-sized and large manufacturer in Annex II sectors is now legally required to maintain a business continuity plan covering backup management, disaster recovery, and crisis management — and to demonstrate its adequacy to national competent authorities on demand.

This article covers the specific challenges of Article 21(2)(c) compliance in manufacturing OT environments: why SCADA cold restart timelines are fundamentally different from IT failover windows, how to build a business impact analysis that captures just-in-time cascade effects, how to set tier-appropriate RTO/RPO targets that will withstand audit scrutiny, and what manual fallback documentation the directive requires but most BCPs omit.

Which Manufacturers Are Subject to NIS2?

Manufacturing is listed in Annex II of Directive (EU) 2022/2555, which means manufacturers qualify as important entities. That classification affects supervisory intensity, not the technical obligations themselves: both important and essential entities must comply with Article 21’s full set of risk management measures, including Article 21(2)(c) on business continuity.

The size threshold that triggers NIS2 obligations is the medium-enterprise ceiling: organisations with 50 or more employees or annual turnover above €10 million. Below that threshold, NIS2 does not apply — unless your organisation is the sole provider of a service essential to critical activities in a member state, poses a public safety risk if disrupted, or has been designated as nationally critical by the competent authority regardless of size.

The Annex II manufacturing sectors covered include:

• Medical devices and in vitro diagnostics
• Computer, electronic, and optical products
• Electrical equipment
• Machinery and mechanical equipment
• Motor vehicles, trailers, and semi-trailers
• Other transport equipment

Food manufacturing is separately covered in Annex II under its own sector designation. Chemical and pharmaceutical manufacturers may be classified as essential entities under Annex I depending on their specific activity and member state transposition choices, which affects supervisory regime but not the Article 21 technical requirements.

If your organisation manufactures in any of these categories and employs at least 50 people, Article 21(2)(c) compliance is a legal obligation. Article 21(4) of the directive requires non-compliant entities to take “all necessary, appropriate and proportionate corrective measures without undue delay.” Under Article 20, management bodies may be held personally liable for oversight failures — a provision that has substantially changed how boards engage with NIS2 compliance.

The proportionality principle in Article 21(1) allows smaller manufacturers to calibrate the scale of their BCP based on risk exposure, organisation size, and implementation cost — but it does not create an exemption from having one.

What Article 21(2)(c) Requires — and What CIR 2024/2690 Adds

The directive text is brief. Article 21(2)(c) requires entities to implement measures addressing “business continuity, such as backup management and disaster recovery, and crisis management.” The “such as” framing confirms those three elements are illustrative, not exhaustive — the obligation extends to any mechanism that maintains operational continuity following a disruptive incident.

Commission Implementing Regulation (EU) 2024/2690 translates that single sentence into a structured set of requirements in its Annex 4. While the CIR is directly binding only on digital infrastructure entities (cloud providers, DNS registries, CDN operators, managed service providers), national competent authorities across the EU have adopted it as the practical benchmark for all NIS2 entities — meaning its requirements define what “adequate” looks like when an auditor reviews your manufacturing BCP.

Under CIR Annex 4, a compliant business continuity and disaster recovery plan must include:

• Purpose and scope — which systems and processes are covered
• Roles and contacts — named individuals with plan activation authority
• Activation conditions — defined criteria that trigger the plan
• Recovery order — sequenced restoration priorities across systems
• Operation-specific recovery plans — including objectives (your RTO and RPO for each system or process)
• Required resources — backups, redundancies, facilities, staffing
• Restoration procedures — step-by-step recovery instructions

Backup plans must additionally specify recovery times, completeness verification procedures, secure offsite storage at sufficient distance from the primary site, appropriate access controls, data restoration capability, and retention periods aligned with regulatory and business requirements. CIR 4.2.6 explicitly mandates regular testing of backup copies and redundancies — not scheduled backup job logs, but verified restoration under realistic conditions.

One critical point: the CIR does not prescribe numeric RTO or RPO values. Your organisation is required to derive those targets from its own business impact analysis and risk assessment results. That flexibility is intentional — but it places the burden of justification on you. An auditor will not accept “we aim for 24 hours” without evidence that 24 hours was the output of a documented BIA process, appropriate to your sector’s actual risk profile.

Why Your IT Recovery Playbook Won’t Survive an OT Incident

Most manufacturers inherit their BCP from the IT department. The plan was written for file servers, email systems, and ERP applications. It assumes recovery means spinning up a cloud instance from a snapshot, or restoring from a nightly backup onto equivalent hardware within a few hours. That assumption breaks in an operational technology environment.

NIST Special Publication 800-82 Rev. 3 — the definitive guidance on OT security — acknowledges the fundamental mismatch: OT systems prioritise availability and process continuity above all other security properties, and they operate under constraints that IT architectures do not face. The practical consequences for recovery planning are significant.

Consider what a cold restart means for a SCADA system. Unlike an application server, SCADA does not start up to a running state. Every PLC on the network must re-establish communications with the SCADA server and confirm its configuration is intact. In a medium-complexity plant, that verification sequence — checking every field device, confirming I/O mapping, validating control logic versions against the live configuration archive — can consume 24 to 48 hours before operators can safely resume production. Add the time required to verify physical process states (temperature, pressure, chemical conditions) and complete safety sign-offs, and realistic Tier 1 OT recovery windows in manufacturing extend to several days, not the hours that IT-derived BCPs assume.

The Macrium 2026 benchmark study found that only 18% of manufacturers meet their declared recovery time objectives during actual restoration tests. That gap exists precisely because RTOs were set using IT benchmarks and never validated against OT reality. The same study found that ICS and SCADA systems are backed up by only approximately 54% of manufacturers — a coverage gap that makes the RTO question moot for nearly half the sector before recovery even begins.

Three structural differences drive the OT-IT recovery gap:

1. Proprietary real-time operating systems: Many SCADA servers and HMIs run on operating systems that predate modern virtualisation. There is no VM snapshot to roll back to. Recovery requires a physical rebuild from configuration archives, which may themselves be months old or stored on offline engineering workstations that have since been retired from service.
2. Physical process state dependency: IT recovery proceeds independently of the physical world. OT recovery cannot. A DCS cannot receive control commands until the physical process is verified to be in a safe, known state — a validation that is a human, manual process and cannot be automated away.
3. Legacy equipment with no native backup capability: A PLC purchased in 2004 may have its configuration documented only in a proprietary binary format on a laptop that was decommissioned years ago. Recovering that PLC means either locating the original configuration file or re-programming from scratch against original engineering drawings — a task measured in days, not hours.

OT-Specific BIA: Mapping the JIT Cascade

A manufacturing BIA that stops at “which systems are critical?” will miss the most important question for Article 21(2)(c) analysis: what is the cascading commercial impact of a production halt, and how quickly does that damage become irreversible?

Just-in-time manufacturing operates with minimal inventory buffers. When a production line stops, the impact does not stay contained. Components scheduled for delivery in 48 hours have nowhere to go, triggering your supplier’s own shutdown. Finished goods due for dispatch trigger customer penalty clauses. Workers on shift produce nothing but continue to draw wages. When the line eventually restarts, the backlog of missed orders cannot be fully recovered — it is simply lost revenue and potentially lost customer relationships.

Research published on the Minimum Viable Factory (MVF) recovery framework describes this challenge precisely: in a constrained-recovery scenario, recovery sequencing becomes a decision about which production capability to restore first, not an attempt to restore everything simultaneously. The practical implication is that your BIA must answer three questions that standard IT BCP templates never ask:

1. What is the production capability threshold below which customer relationships become unrecoverable? This is your true Maximum Tolerable Period of Disruption — and it is almost always shorter than technical staff assume, because commercial damage accumulates faster than system restoration timelines allow.
2. Which product lines, if partially restored, prevent the most significant commercial damage? The answer to this question drives your Tier 1 recovery sequence — which systems must come back first to reach the Minimum Viable Factory state.
3. Which suppliers and customers have their own JIT dependencies on your output? Their MTPD may be shorter than yours, making their pressure on your recovery timeline a material compliance consideration.

For NIS2 compliance, the BIA output must be documented and must justify the RTO/RPO targets set for each system or process. A manufacturing BIA that does not model the JIT cascade — and that does not account for first- and second-tier supplier and customer dependencies — will not withstand a competent authority review, because it will not explain why the declared RTO is appropriate.

Setting RTO/RPO for Manufacturing OT: A Three-Tier Framework

Because CIR Annex 4 requires operation-specific recovery objectives, you need a tiered framework that assigns different RTO/RPO targets to each layer of the manufacturing technology stack. Applying a single enterprise-wide RTO — the most common BCP error auditors identify in manufacturing entities — conflates systems with completely different recovery characteristics.

Tier	Systems	Realistic OT RTO	RPO Principle	Primary Recovery Mechanism
Tier 1 — Process Control (Purdue Levels 0–2)	SCADA, DCS, PLC networks, HMIs, field sensors	72–120 hours (cold restart scenario)	Process state integrity takes priority over data completeness; last known safe state must be recoverable from configuration archives	Configuration archive restore + PLC re-commissioning + physical safety sign-off
Tier 2 — Manufacturing Operations (Purdue Level 3)	MES, historian, quality databases, OEE platforms	4–24 hours	15–60 minute window; production batch records cannot be lost without regulatory and traceability consequences	VM snapshot restore or on-premises backup recovery to equivalent hardware
Tier 3 — Business Functions (Purdue Levels 4–5)	ERP, logistics, HR, finance, email	2–8 hours	Near-zero via cloud replication	Cloud failover or standard IT DR procedures

The 72–120 hour Tier 1 RTO is not a failure of ambition — it is the honest output of a BIA that accounts for PLC re-commissioning time, configuration verification, and physical process validation. Setting Tier 1 RTO at 4 hours may look better in a board presentation, but it will not be achievable in a real incident, and a competent authority auditor who asks to see restoration test results will expose the gap immediately.

For RPO at Tier 1, the relevant question is not “how old can our last backup be?” but “can we recover to a known safe process state?” That requires configuration archives for every PLC and SCADA component — not just data backups. NIST SP 800-82 Rev. 3 specifically identifies configuration management as a foundational OT security control. Without current configuration archives, Tier 1 recovery becomes a re-engineering project, not a restore — and the timeline extends from days into weeks.

Your BIA documentation should explicitly state why each tier’s RTO target is appropriate given your manufacturing process’s MTPD. An RTO longer than the MTPD is indefensible in an audit — it means your recovery plan, even if executed perfectly, would not prevent irreversible business damage.

Manual Fallback Procedures: The Third Layer Most BCPs Skip

Even with well-maintained OT configuration archives and a realistic Tier 1 RTO, there will be incidents where the production process cannot wait 72–120 hours for full SCADA restoration. Manual fallback procedures bridge that gap — and they are absent from most manufacturing BCPs because they are labour-intensive to develop and rarely exercised.

OT continuity practice identifies three operational modes that manufacturing BCPs under NIS2 must document, each with distinct capabilities and limitations:

Manual control mode is the most demanding. Operators run the plant using pre-prepared, step-by-step documented procedures, replacing automated SCADA commands with physical valve actuation, manual sensor readings, and calculated adjustments. The procedures must specify the exact order of operations, maximum allowable process parameters, and which safety interlocks must be manually verified before each step. In complex process or food manufacturing plants, manual mode typically limits production throughput to 20–30% of normal capacity and introduces error risk that SCADA automation eliminates. The BCP must document the manual operating limits for each critical process and the training evidence for the operators authorised to execute them.

Degraded mode exploits a capability that many manufacturers do not fully document: individual PLCs can often operate autonomously in “island mode” when the central SCADA server fails, using their last downloaded control programme. The production line continues at reduced speed or limited to a standard product mix. There is no historian connection during degraded operation — meaning batch records, quality data, and OEE metrics are not captured. Your BCP must document which PLCs support island mode, what their autonomous operating limits are, how to detect when they have entered autonomous operation, and how to reconcile the documentation gap when SCADA connectivity is restored.

Minimal restoration targets the Minimum Viable Factory rather than full system recovery. Rather than sequencing recovery based on technical ease, this approach asks: what is the smallest operational subset that prevents irreversible commercial damage? In practice, that means restoring the process control core and primary visualisation before committing recovery resources to historian, MES, and ERP layers. Research on manufacturing ransomware recovery supports this sequencing: full restoration is the goal, but MVF capability is the first milestone that must be reached.

Under Article 21(2)(c), all three modes must be documented in the BCP with explicit activation criteria: what threshold of system unavailability triggers each mode, who has authority to activate it, and how operators are trained and evaluated on execution. A manual fallback procedure that exists only in the maintenance manager’s knowledge does not satisfy the documentation requirements — and it will not survive a competent authority audit of your crisis management framework.

Testing and Documentation: What NIS2 Auditors Expect

CIR 2024/2690 Annex 4.2.6 mandates “regular testing of the recovery of backup copies and redundancies.” The distinction competent authorities draw is between backup completion logs and verified restoration test results. A log showing that backups run nightly confirms that data exists — not that it can be recovered within your declared RTO. Only a documented restoration test, with timestamps, systems tested, RTO achieved versus target, and sign-off, meets the “regular testing” requirement.

ENISA’s June 2025 Technical Implementation Guidance on NIS2 cybersecurity risk management measures identifies business continuity and crisis management as a distinct testing area. For manufacturing entities, the audit evidence trail should demonstrate three levels of test activity:

• Tabletop exercises (at minimum semi-annually): scenario walkthroughs involving CISO, OT manager, production director, and legal counsel. These test decision-making and role clarity, not technical recovery speed. Required documentation: date, participants, scenario used, decisions made, gaps identified, corrective actions assigned with owners and deadlines.
• Functional tests (at minimum quarterly): actual backup restoration to an isolated environment, verifying that configuration archives produce working system states. For OT specifically, this means verifying that a PLC configuration backup loads onto equivalent hardware and produces the expected control outputs. Required documentation: system tested, backup age, restoration time achieved versus RTO target, data integrity verification method, test sign-off by OT manager or production director.
• Full-scale BCP exercise (annually): activation of the complete recovery sequence including manual fallback procedures, degraded-mode operation, and simulated communication to suppliers and customers. Required documentation: scenario, full timeline, all roles activated, RTO/RPO achieved versus targets, deviations from documented procedure, management sign-off, corrective action log.

OT-specific audit evidence that goes beyond standard IT BCP documentation includes: PLC configuration backup verification logs confirming that the archived version matches the live PLC configuration, cold restart procedure walkthroughs conducted with OT staff and timed against the declared Tier 1 RTO, and manual operation drill records signed by the production director attesting that operators can execute the procedures documented in the BCP.

One common gap: manufacturers test IT recovery frequently and OT recovery never. Auditors have begun asking specifically whether ICS and SCADA recovery has been tested — and the answer “our IT systems were tested” does not satisfy the “regular testing” obligation for a manufacturing entity whose most critical systems are operational technology.

Responsibilities Across the Manufacturing Organisation

Article 21(2)(c) compliance is not a single team’s responsibility. Effective BCP in a manufacturing environment requires documented ownership across five functions:

Role	Article 21(2)(c) Responsibilities
CISO / IT Security Manager	BCP policy ownership; risk assessment governance; IT Tier 3 recovery procedures; testing programme management; NIS2 regulatory reporting
OT / ICS Manager	SCADA and PLC configuration archive maintenance; cold restart runbooks; degraded-mode documentation; Tier 1–2 functional test execution and sign-off
Production Director	BIA input (MTPD, revenue impact, JIT cascade analysis); manual fallback authorisation; full-scale exercise sign-off; MVF threshold definition
Compliance Officer / Legal	Art. 21(2)(c) audit evidence completeness; CIR 4.1/4.2 documentation review; competent authority correspondence; cross-reference to Art. 23 notification obligations
Board / Senior Management	BCP budget approval; crisis management protocol activation; Article 20 personal management accountability oversight; supplier and customer communication during incidents

Frequently Asked Questions

Does NIS2 specify minimum RTO and RPO values for manufacturers?

No. Article 21(2)(c) and CIR 2024/2690 Annex 4 require entities to establish RTO and RPO targets based on their own business impact analysis and risk assessment. The regulation mandates the process and the documentation, not specific numbers. Your targets must be justified by BIA evidence and validated by regular restoration testing — an auditor will challenge both the targets themselves and the evidence that they are achievable.

Are manufacturers required to maintain a warm standby SCADA system?

Not explicitly. CIR Annex 4 requires “sufficient available resources, including facilities, network and information systems” to support recovery — interpreted proportionately based on entity size and risk exposure. For most manufacturers, a documented cold restart procedure with maintained configuration archives and regular testing satisfies the resource requirement, provided the resulting RTO is justified by the BIA. Warm standby is worth considering if the BIA reveals that a cold restart RTO exceeds your MTPD.

What is the difference between important and essential entity classification for NIS2 compliance?

Manufacturers in Annex II are important entities. The Article 21 technical requirements are identical for both classifications. The difference lies in supervisory regime: essential entities face proactive supervision, while important entities are typically subject to reactive oversight triggered by incidents or complaints. Both classifications are subject to the directive’s maximum penalties for non-compliance.

How does Article 21(2)(c) interact with Article 23 incident notification?

They are connected obligations. A significant incident that disrupts operations triggers both the BCP (restore continuity under Art. 21(2)(c)) and the notification obligations under Article 23: a 24-hour early warning, a 72-hour incident notification, and a 30-day final report. Your BCP should explicitly assign responsibility for these notifications during a continuity event and build the timelines into the crisis management component of the plan. For more on Article 23 obligations, see our guide on NIS2 incident notification requirements.

For a broader overview of the business continuity requirements and how they apply across sectors, see our Article 21(2)(c) requirements guide. Manufacturers in adjacent sectors with significant chemical or process components should also review our chemicals manufacturing NIS2 guide, which covers the overlap between NIS2 and SEVESO III reporting obligations. For the risk assessment foundation that informs your BIA, see our NIS2 risk assessment guide.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

[1] NIS 2 Directive, Article 21: Cybersecurity risk-management measures — nis-2-directive.com
[2] Article 21, Cybersecurity risk-management measures — nis2resources.eu
[3] Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex
[4] Business Continuity Plan (BCP) for OT: What if the main control system is unavailable for 24 hours? — nFlo.tech
[5] The Backup Paradox: Why Manufacturing Recovery Readiness Still Lags Behind Investment — Industrial Cyber / Macrium 2026 Benchmark Report
[6] From Backup Restoration to Minimum Viable Factory Recovery: A Systematization of Ransomware Recovery in Manufacturing Systems — arXiv 2605.16167
[7] NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security — NIST CSRC, May 2023
[8] ENISA Technical Implementation Guidance on NIS2 Cybersecurity Risk Management Measures v1.0 — ENISA, June 2025
[9] NIS 2 Directive, Article 3: Essential and important entities — nis-2-directive.com