Why NIS2 turns disaster recovery into a board-level decision
If your organisation still treats disaster recovery as a technical checkbox, the NIS2 Directive has quietly changed the rules. Defining RTO and RPO is no longer an IT department exercise: it is a governance obligation that European regulators can, and increasingly do, verify. Under Article 21, business continuity, backup management and crisis handling sit alongside incident response and supply chain security among the mandatory risk management measures.
The distinction matters more than it sounds. A backup proves you have copies of your data. A business disaster recovery capability proves you can restore operations, in a defined order, within a time your organisation has consciously chosen to accept. Those are entirely different things, and NIS2 audits are built around the second one.
For Italian entities, Determinazione ACN 164179/2025 has translated these principles into specific, verifiable security measures, with implementation deadlines already running through 2026 and 2027. Essential and important entities registered with the Agenzia per la Cybersicurezza Nazionale are expected to document not just that a plan exists, but that it has been tested, updated and approved by management. Directors can be held personally accountable for failures in oversight.
What “resilience” actually means in the directive
NIS2 language is deliberately outcome-oriented. It asks whether the entity can maintain or restore the delivery of its services after a disruptive event, not whether it bought a particular product. That shifts the burden from technology procurement to analysis and decision making.
In practice, an inspector will want to see three things: a documented understanding of which activities matter most, quantified recovery objectives for each of them, and evidence that those objectives have been tested against reality. Missing any one of the three leaves you exposed, regardless of how sophisticated your infrastructure is.
Setting priorities before setting numbers
The most common mistake we see among small and medium businesses is starting with technology. Someone asks the IT provider for “a disaster recovery plan for business continuity”, a replication service gets configured, and nobody ever establishes what the business actually needs back first. When a real incident hits, the recovery team restores in whatever order feels natural, which is rarely the order that limits financial damage.
The correct starting point is a Business Impact Analysis (BIA). It does not need to be a 200-page document. For a 60-person manufacturing company, a structured workshop with department heads and a well-built spreadsheet can produce something genuinely useful in two or three working sessions.
Mapping processes, not servers
List your business processes first: order intake, production scheduling, invoicing, payroll, customer support, warehouse dispatch. For each one, ask a simple question: if this stops, when does it start costing us real money, contracts, or regulatory exposure?
Only after that do you map each process to the systems, data, people and third parties it depends on. This is where most organisations discover uncomfortable surprises. A single legacy application nobody has patched in four years turns out to sit under three critical processes, or a supplier’s SaaS platform is a single point of failure that no internal plan can mitigate.
Supply chain dependencies deserve particular attention, because NIS2 explicitly extends risk management to suppliers and service providers. Your continuity plan is only as strong as the recovery commitments in your vendors’ contracts, and most standard SLAs offer far less than clients assume. Reviewing these alongside your broader NIS2 compliance obligations is time well spent.
Tiering: not everything can be critical
Once processes are mapped, group them into tiers. A workable model for SMBs uses four levels: vital (restore within hours), critical (within one working day), important (within three days), and deferrable (within a week or more).
Discipline is essential here. If every department declares its process vital, the exercise produces nothing and your recovery costs explode. A useful rule of thumb: no more than 15 to 20 percent of processes should sit in the top tier. Forcing that constraint is what turns a wish list into a plan.
Defining RTO and RPO without guesswork
RTO and RPO are the two numbers that make a continuity plan operational. They are frequently confused, so it is worth stating them plainly.
Recovery Time Objective (RTO) is the maximum acceptable time between a disruption and the restoration of a process. It answers: how long can we be down before the damage becomes unacceptable?
Recovery Point Objective (RPO) is the maximum acceptable amount of data loss, measured in time. It answers: how much recent work can we afford to redo or lose permanently?
An accounting system with a four-hour RTO and a 24-hour RPO means the finance team can be offline for half a working day, but would need to re-enter up to a day’s transactions. That may be perfectly acceptable. For a production line control system, the same numbers would be ruinous.
Grounding the numbers in cost
The temptation is to set aggressive targets everywhere. Resist it, because each step down in RTO or RPO increases cost, often steeply. Moving from daily backups to continuous replication can multiply infrastructure spend several times over.
The right method is to plot two curves: the cost of downtime over time, and the cost of the recovery capability required to prevent it. Your target sits near the intersection. Industry estimates put average downtime costs for mid-sized European companies in the range of several thousand euros per hour, but your own figures matter far more than any benchmark. Calculate lost revenue, idle labour, contractual penalties and recovery overtime for your specific operation.
Remember that RTO measures the full restoration of a working process, not just the moment a server boots. Reconnecting users, validating data integrity, restoring integrations and communicating with customers all consume time. Plans that measure only the technical restore routinely underestimate real recovery by a factor of two or three.
Testing is what makes the numbers real
An untested RTO is a hypothesis. NIS2 supervisory authorities are pointedly interested in evidence of testing, and rightly so: research consistently shows that a significant share of organisations discover their backups are unusable only at the moment they need them.
Build a testing calendar with escalating realism. Start with tabletop exercises twice a year, add technical restore tests of individual systems each quarter, and run at least one full failover simulation annually for tier-one processes. Document every test, including the failures, because a record showing you found and fixed a problem is stronger evidence of maturity than a spotless report nobody believes.
Cross-check your architecture against the 3-2-1-1-0 principle: three copies of data, on two different media, one offsite, one immutable or air-gapped, and zero errors on verification. The immutable copy has become non-negotiable given how systematically ransomware operators now target backup repositories before encrypting production systems. Our backup and disaster recovery services are designed around exactly this model.
Turning analysis into a working plan
A business continuity plan for SMEs should be short enough that people actually read it under pressure. Ten to twenty pages, written in plain language, beats an exhaustive manual that lives unopened on a shared drive.
Include the essentials: activation criteria and who has authority to declare an incident, a contact tree that works when email and internal systems are down, recovery procedures per tier in priority order, and communication templates for staff, customers, suppliers and authorities. Add the NIS2 notification timeline explicitly, since the 24-hour early warning and 72-hour incident notification deadlines run in parallel with your technical recovery and will otherwise be forgotten in the chaos.
Assign named roles rather than job titles alone, and always name a deputy. Incidents have an unhelpful habit of occurring during holidays and weekends. Keep an offline copy of the plan, printed or on encrypted USB, in the hands of every person with a recovery role.
Finally, treat the plan as a living document. Review it after every significant infrastructure change, every acquisition, every new critical supplier, and at minimum once a year with formal management sign-off. That sign-off is not bureaucracy: under NIS2 it is part of the governance evidence trail that demonstrates leadership involvement.
For most European SMBs, the honest assessment is that continuity planning has been postponed because it feels abstract until the day it isn’t. The organisations that handle incidents well are not the ones with the largest budgets, but the ones that decided in advance what comes back first. Our team supports companies through this process as part of a broader cybersecurity programme, from initial impact analysis to tested, documented recovery capability.