How to Build a NIS2-Compliant BIA in 5 Steps — RTO, RPO, and MTPD Included

When NIS2 auditors review your business continuity documentation, the first question is not “do you have a BC Plan?” — it is “how did you determine what to include in it?” A Business Impact Analysis (BIA) is the answer to that question. Without a BIA, your BC Plan is guesswork dressed as documentation.

Article 21(2)(c) of the NIS2 Directive requires “business continuity, such as backup management and disaster recovery, and crisis management.” Commission Implementing Regulation (EU) 2024/2690, which entered into force in October 2024, is more specific: it requires entities to develop BC and disaster recovery plans based on both a risk assessment and a business impact analysis. The BIA is not optional — it is the analytical evidence that your Recovery Time Objectives are business-driven, not IT-invented.

This guide covers the complete five-step NIS2 BIA methodology, the three metrics you must define (RTO, RPO, MTPD), and how your BIA output feeds directly into your BC Strategy and BC Plan.

What NIS2 Article 21(2)(c) Actually Requires

Article 21(2)(c) of the NIS2 Directive (EU 2022/2555) states: “business continuity, such as backup management and disaster recovery, and crisis management.” Commission Implementing Regulation (EU) 2024/2690 specifies what this means in practice.

The implementing regulation requires that BC and disaster recovery plans:

• Be based on a completed risk assessment and a business impact analysis
• Define Recovery Time Objectives (RTO), Recovery Point Objectives (RPO), and Service Delivery Objectives (SDO) per covered function
• Include backup management with integrity checks and off-site storage with defined retention periods
• Be tested periodically (Annex, point 4.1.4)
• Incorporate a crisis management process with defined roles, responsibilities, and coordination with competent authorities

The “appropriate and proportionate” framing in Art. 21 does not mean you can skip the BIA — it means your BIA scope should reflect your organisation’s size and risk profile. A mid-sized essential entity needs a documented BIA; a large essential entity needs a formally reviewed, annually updated one.

For CISOs and BC Managers: The MTPD methodology in Step 4 and the documentation checklist are the highest-value sections for experienced practitioners. For SME owners: Focus on Steps 1 and 2 to establish your critical function inventory before tackling the recovery metrics in Steps 3 and 4.

Step 1: Identify Your Critical Business Functions

The BIA begins with one question: which business functions, if disrupted, would put your organisation at unacceptable risk? This is a business question, not an IT question — the answer must come from operational and commercial leadership before IT enters the room. Business stakeholders, not IT teams, define what “unacceptable” means.

Start by inventorying every process that supports your organisation’s essential services. For a healthcare network: patient scheduling, medication dispensing, laboratory processing. For a logistics operator: routing systems, customs documentation, warehouse management. For a financial firm: transaction processing, client reporting, regulatory filing.

For each function, apply this two-question filter:

1. If this function was unavailable for four hours, would it trigger a contractual, regulatory, or operational consequence?
2. If this function was unavailable for 24 hours, would it threaten organisational viability?

Functions answering yes to question 1 are Important. Functions answering yes to question 2 are Critical. Under NIS2, pay particular attention to functions that directly support essential services listed in Annex I or II of the directive, feed incident reporting obligations under Art. 23 (compromising your reporting capability is itself a notifiable incident), or depend on third parties covered by the supply chain requirements in Art. 21(2)(d).

Effort estimate: Low–Medium. Established organisations should budget 2–3 workshops over 2–3 days. Organisations without existing process documentation should allow 1–2 weeks with a cross-functional team.

Step 2: Map Dependencies (Systems, Staff, and Suppliers)

Once your critical functions are identified, map everything each function needs to operate. NIS2 places specific weight on supply chain dependencies — a cyber attack on a critical supplier can interrupt your essential service as effectively as a direct attack on your own infrastructure. This is why dependency mapping serves both the BIA and your Art. 21(2)(d) supply chain security obligations at the same time.

Organise dependencies into five categories:

Category	What to document
IT systems & applications	Name, hosting location, vendor, data classification
Data	Location (on-prem/cloud), backup frequency, classification
Personnel	Minimum headcount, skills required, documented backup roles
Facilities	Physical location, utility dependencies, access requirements
Suppliers & third parties	Service provided, contractual SLA, geographic risk, single-source flag

For each dependency, record three things: the owner (internal team or external supplier), current redundancy level (None / Partial / Full), and failure impact on the parent function (Minor / Significant / Catastrophic). This matrix simultaneously populates Step 5 (single points of failure) and satisfies the documentation requirements for NIS2 supply chain security — Art. 21(2)(d) requires security requirements to flow down into supplier agreements, which you cannot do without knowing which suppliers are critical.

Effort estimate: Medium. Allow 2–4 hours per critical function for structured interviews with process owners, IT architects, and procurement.

Step 3: Assess Impact Across Five Time Horizons

For each critical function, quantify what happens if it is unavailable — not vaguely, but across five specific time intervals: 1 hour, 4 hours, 24 hours, 72 hours, and 1 week. Each interval triggers progressively worse consequences. The time horizon at which impact becomes unacceptable is your Maximum Tolerable Period of Disruption, which you will formalise in Step 4.

Assess four impact dimensions at each time interval:

Dimension	What to measure
Financial	Revenue loss, contractual damages, NIS2 penalty exposure
Operational	Service degradation, feasibility of manual workarounds
Regulatory	NIS2 Art. 23 reporting obligations triggered, supervisory notification required
Reputational	Customer churn risk, media exposure, partner confidence

Rate each dimension: Low (tolerable, no material consequence), Medium (significant but recoverable), High (unacceptable, recovery uncertain). The first time horizon at which any dimension reaches “High” is your MTPD boundary for that function.

The heat map above illustrates a typical assessment for an authentication service at a financial-sector essential entity. The 4-hour column is where overall impact first reaches “High” — making MTPD = 4 hours. The RTO set in Step 4 must therefore be below 4 hours. At the 24-hour mark all dimensions reach “Critical,” confirming this is not a function that can tolerate a typical IT incident response timeline.

Effort estimate: Medium. Allow 1–2 hours per critical function with process owner and financial controller input. A typical BIA covers 8–15 critical functions, so the full assessment takes 1–2 weeks including scheduling and sign-off.

Step 4: Define RTO, RPO, and MTPD per Function

Commission Implementing Regulation (EU) 2024/2690 requires you to define three recovery metrics per covered function. The sequence matters: establish MTPD first, then set RTO inside it, then derive RPO from your RTO and data criticality. Reversing this order produces recovery targets that look clean on paper but cannot actually be met — or, worse, met by IT while business operations remain effectively paralysed.

Maximum Tolerable Period of Disruption (MTPD) is the outer boundary: the point beyond which disruption threatens organisational viability. ISO 22301 defines it as “the time after which the organisation’s viability will be irrevocably threatened if the activity is not resumed.” Derive MTPD from your Step 3 impact matrix — it is the first time horizon at which any impact dimension first reaches “High.” MTPD is a business decision, signed off by management, not an IT estimate.

Recovery Time Objective (RTO) is the operational target — how quickly the function must be restored after an incident. RTO must always be shorter than MTPD, with a margin for restoration testing, reprocessing backlogs, and the sequencing constraints that real recovery imposes (a database must be online before the application server can start). If MTPD = 4 hours, a defensible RTO is 2–3 hours, not 3.5 hours. That margin is what your plan is tested against.

Recovery Point Objective (RPO) is the maximum acceptable data loss, measured in time. An RPO of 1 hour means your most recent backup can be no more than 1 hour old at the point of failure. RPO directly determines backup and replication strategy: a 15-minute RPO requires continuous replication; a 4-hour RPO can be satisfied with scheduled snapshots.

ENISA’s Technical Implementation Guidance (June 2025) adds a fourth metric worth documenting: Service Delivery Objective (SDO) — the minimum acceptable service level during the recovery window. Example: “During the recovery period, the authentication service must process at least 20% of normal transaction volume.” SDO prevents the scenario where IT declares systems restored while the business function remains operationally useless.

Metric	Definition	Set by	Key constraint
MTPD	Outer boundary — beyond this, viability threatened	Business leadership	Derived from Step 3 impact matrix
RTO	Maximum acceptable restoration time	Business + IT jointly	RTO < MTPD (with margin)
RPO	Maximum acceptable data loss in time	Business + IT jointly	Backup frequency must cover RPO
SDO	Minimum service level during recovery period	Business leadership	Defined per critical function

These figures, documented per function, are the direct input to your BC Strategy. Without them, you cannot choose between recovery options — hot standby, warm standby, manual workaround, or alternative supplier — on any basis other than cost. With them, the strategy decision becomes defensible.

Effort estimate: Low, once Step 3 is complete. The numbers emerge from the impact matrix; this step formalises them and obtains management sign-off.

Step 5: Identify Single Points of Failure

A single point of failure (SPOF) is any dependency from Step 2 whose failure alone would prevent a critical function from meeting its RTO. SPOFs represent the gap between your current infrastructure and the recovery capability your BIA requires — they must be documented here and addressed in your BC Strategy.

Work through your dependency matrix systematically. For each entry, ask: “If this fails with no notice, can the parent function still meet its RTO?” If no, it is a SPOF. Record: dependency name, function affected, current mitigation (if any), and residual risk level (Low / Medium / High).

The three most common SPOF categories under NIS2:

Infrastructure SPOFs: A single data centre with no disaster recovery site; a network uplink with no redundant path; on-premises hardware with no cloud failover for any function with an RTO below 24 hours. These are the most straightforward to identify and the most expensive to remediate.

Supplier SPOFs: A single-source critical supplier with no qualified alternative and no contractual continuity obligation; a cloud provider hosting functions with an RTO below 4 hours without multi-region or multi-AZ configuration; an outsourced IT support provider whose response SLA exceeds your RTO window. Art. 21(2)(d) requires that security requirements — including recovery commitments — flow into supplier agreements. If a supplier cannot meet your RTO, that is a documented SPOF requiring a BC Strategy decision.

Personnel SPOFs: A function where only one person holds the technical knowledge or system credentials to execute recovery. Art. 21(2)(i) (human resources security, access control, and asset management) requires this risk to be addressed through cross-training, documented runbooks, and access management that does not create single-person bottlenecks at critical recovery steps.

A BIA that identifies no SPOFs is almost always a BIA that has not been completed honestly. Every organisation has at least one — the audit question is whether it has been documented and whether the BC Strategy shows how it is being addressed.

Effort estimate: Low–Medium. SPOFs emerge directly from the dependency matrix; structured review with IT and operational leadership takes 4–8 hours for a mid-sized organisation.

How BIA Output Feeds Your BC Strategy and BC Plan

The BIA is not an end in itself — it is the foundation of a three-stage documentation pipeline that together constitutes your Art. 21(2)(c) compliance evidence.

Stage 1: BIA → BC Strategy. The MTPD, RTO, RPO, and SPOF register from your BIA define which recovery options are viable. A function with RTO = 1 hour and a current infrastructure SPOF (single data centre) requires a hot-standby or active-active strategy. A function with RTO = 72 hours and full redundancy can rely on warm standby. The BC Strategy documents the option selected and the rationale — this decision record is what an auditor needs, not just the plan that results from it.

Stage 2: BC Strategy → BC Plan. The BC Plan translates strategy into operational procedures: who does what, in what sequence, with what resources, and within what timeframe. It incorporates the crisis management process required by the implementing regulation — activation criteria, command structure, communication channels, and escalation to competent authorities under Art. 23.

Stage 3: Testing and review. The implementing regulation requires periodic testing (Annex, point 4.1.4). The BIA is the baseline — post-test results must be compared against BIA assumptions. When actual recovery times exceed RTO targets, the BIA is updated to reflect either improved recovery capability or revised (honest) recovery objectives. A plan that is never tested is not a BC Plan; it is a document.

Your business continuity documentation hub covers the full pipeline from BIA through BC Strategy to BC Plan and testing requirements. For the risk assessment that scopes the BIA, see the NIS2 risk assessment guide — risk assessment identifies which assets face the highest threat; the BIA translates those threats into business-function impact.

Who Owns the BIA: Role and Responsibility Table

Role	BIA Responsibility	NIS2 Article
BC Manager / CISO	Owns the BIA process; defines scope, methodology, and signs off final output	Art. 21(2)(c)
Process Owners (department heads)	Provide impact data and validate MTPD assumptions for their functions	Art. 21(2)(a)
IT / Infrastructure	Map technical dependencies, confirm current redundancy levels, identify infrastructure SPOFs	Art. 21(2)(c)
Legal / Compliance	Validate the regulatory impact dimension — Art. 23 reporting obligations, penalty exposure	Art. 21(2)(a)
Procurement / Supply Chain	Document supplier dependencies, contractual SLAs, geographic risk, single-source flags	Art. 21(2)(d)
Management Board	Approve MTPD thresholds and RTO targets; their sign-off is the audit evidence that recovery objectives are business-driven	Art. 20(1)

Board approval of MTPD and RTO targets matters specifically under NIS2 because Art. 20(1) requires management bodies to approve cybersecurity risk-management measures and oversee their implementation. Signing off on recovery objectives is part of that obligation, not a formality. When an auditor asks “who authorised these RTO figures?” your answer needs a name and a date, not a reference to an IT team decision.

BIA Documentation Checklist for NIS2 Audit

An auditor reviewing your Art. 21(2)(c) compliance will look for the following evidence:

• BIA scope statement and methodology, linked to your NIS2 risk assessment
• Critical function inventory with classification (Critical / Important / Standard)
• Dependency matrix per critical function — systems, staff, and suppliers
• Impact assessment across at least five time horizons (1h, 4h, 24h, 72h, 1 week)
• MTPD established and documented per function, with business sign-off
• RTO, RPO, and SDO defined per function, with RTO < MTPD confirmed
• SPOF register with residual risk classification and mitigation approach
• Stakeholder validation sign-off from process owners and management board
• Date of last BIA review (aligned with annual risk assessment cycle)
• Link to BC Strategy and BC Plan showing BIA inputs were used in strategy selection

The Business Continuity Pack provides structured templates covering every item on this checklist: the BIA Methodology (document 35), BIA Questionnaire (document 36), BC Strategy (document 37), BC Plan (document 38), and Crisis Management Plan (document 39).

Frequently Asked Questions

Is a BIA legally required under NIS2?

Commission Implementing Regulation (EU) 2024/2690 requires BC/DR plans to be based on “risk assessment and business impact analysis.” For entities in scope of the implementing regulation — DNS providers, cloud services, managed service providers, and data centres — a BIA is a direct compliance requirement. For other essential and important entities, a BIA is the standard method for demonstrating “appropriate and proportionate” business continuity measures under Art. 21. Skipping it leaves your proportionality case unsupported if you face a supervisory review.

How often must the BIA be updated?

ENISA’s Technical Implementation Guidance (June 2025) requires regular testing and updating of crisis management plans. Most organisations update their BIA annually and after any significant change to business processes, critical systems, or the supplier landscape. A material incident that reveals gaps in RTO assumptions should trigger an immediate review — waiting for the annual cycle in that situation would be difficult to justify to a regulator.

What is the difference between MTPD and RTO?

MTPD is the business-defined outer limit — the maximum outage duration before organisational viability is threatened. RTO is the operational target — how quickly functions must be restored. RTO must always be shorter than MTPD to provide a recovery margin. Setting RTO equal to MTPD leaves no room for the reprocessing, sequencing, and validation steps that real recovery always requires.

Does the BIA need to cover physical disruptions, or only cyber incidents?

Both. Art. 21(1) requires an all-hazards approach, meaning business continuity measures must address all incidents — ransomware, infrastructure compromise, facility loss, supply chain failure, and personnel unavailability. A function with an MTPD of 4 hours has that constraint regardless of whether the disruption is a cyberattack or a building fire. The BIA does not separate scenarios; it establishes the tolerance thresholds that apply to all of them.

Sources

• NIS2 Directive, Article 21: Cybersecurity risk-management measures
• ENISA Technical Implementation Guidance (NIS2) — ComplianceHub.Wiki
• Business Impact Analysis per ISO 22301 — Glocert International
• Complete Guide to BIA for Contingency Planning — NIST SP 800-34
• Business Impact Analysis Guide — Riskilience
• Business Impact Analysis Guide 2026 — Advisori
• NIS2 Emergency Planning: Building Business Continuity — Kertos.io
• NIS2 and Business Continuity: Standards and Requirements — DRI Italy
• NIS2 Requirements for Operational Continuity — DRI France

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.