Business Impact Analysis for ISO 27001, NIS2 and DORA

The audit question that exposes the real continuity gap

It is Monday morning, and the CISO of a fast-growing FinTech, Maria, is preparing for a board risk committee meeting. The subject line is short: “DORA and NIS2 Readiness: BIA Review.”

Her team has built what most executives expect to see. There is a certified ISO/IEC 27001:2022 ISMS, incident response playbooks, backup screenshots, vulnerability reports, supplier questionnaires, cloud architecture diagrams, and a refreshed risk register. Enterprise customers are sending NIS2 questionnaires. Financial-sector clients are pushing DORA clauses into contracts. The ISO/IEC 27001:2022 surveillance audit is only a month away.

Then the external auditor asks the question that changes the room:

“If your customer onboarding platform is unavailable for 18 hours, which regulated services are affected, which suppliers are involved, what is the approved recovery priority, and where is the evidence that the business accepted the RTO and RPO?”

The room goes quiet.

The backup schedule says one thing. The disaster recovery plan says another. The supplier contract includes an availability SLA, but no recovery test evidence. The risk register mentions availability, but does not explain why one service must recover faster than another. Management approved the security policy, but not the business impact of downtime.

That is the Business Impact Analysis problem in 2026.

A Business Impact Analysis, or BIA, is no longer a spreadsheet attached to a continuity plan. It is the evidence bridge between business services, ICT assets, suppliers, recovery priorities, RTO/RPO, incident thresholds, resilience testing, and board accountability. For organizations aligning ISO/IEC 27001:2022 with NIS2 continuity and DORA ICT resilience, the BIA is where compliance becomes operational.

The strongest organizations already have many of the right controls. Their weakness is traceability. The BIA turns scattered evidence into an audit-ready story: what matters, why it matters, how fast it must recover, which dependencies support it, what has been tested, what failed, what was improved, and who approved the residual risk.

Why old BIA spreadsheets are now a liability

NIS2 and DORA changed the tone of continuity compliance. They do not treat business continuity, disaster recovery, incident response, supplier resilience, and governance as separate documents. They expect them to work as one system.

For NIS2 entities, Article 21 requires technical, operational, and organizational measures to manage risks to network and information systems and to prevent or minimize incident impact on service recipients and other services. Its minimum measures include risk analysis, incident handling, business continuity including backup management, disaster recovery and crisis management, supply chain security, vulnerability handling, assessment of control effectiveness, training, cryptography, HR security, access control, asset management, MFA, and secure communications.

NIS2 Article 20 moves the issue into the boardroom. Management bodies must approve cybersecurity risk-management measures, oversee implementation, and may be held liable for infringements. That means an unsupported four-hour RTO is not just a technical inconsistency. It is a governance weakness.

DORA applies from 17 January 2025 and creates a uniform EU framework for ICT risk management, incident reporting, digital operational resilience testing, ICT third-party risk management, contractual requirements, and oversight of critical ICT third-party providers. For financial entities, and for technology providers supporting them through contracts, DORA turns operational resilience into a structured evidence requirement.

DORA Articles 5 and 6 require governance and a documented ICT risk management framework. Articles 7 to 14 cover reliable and resilient ICT systems, asset and dependency identification, protection, detection, ICT business continuity, backup, restoration, recovery, post-incident learning, awareness, training, and crisis communication. Articles 24 to 26 require digital operational resilience testing for non-microenterprise financial entities. Articles 28 to 30 formalize ICT third-party risk, registers of ICT service contracts, exit strategies, service levels, audit rights, and contingency requirements.

ISO/IEC 27001:2022 provides the management system backbone. Its clauses require the organization to define context, interested parties, legal and contractual obligations, scope, leadership, policy, roles, risk assessment, risk treatment, the Statement of Applicability, operational planning, performance evaluation, and continual improvement.

The missing link is often the BIA. Without it, continuity plans are not clearly risk-based, backup targets are not business-approved, suppliers are not mapped to critical services, and management cannot reliably demonstrate that resilience decisions were informed by business impact.

The BIA as the control-plane for resilience evidence

A defensible BIA answers seven questions that auditors, regulators, customers, and boards increasingly ask:

1. Which business services are critical?
2. Which ICT assets, data stores, people, suppliers, and utilities support each service?
3. What is the operational, financial, legal, contractual, customer, safety, and reputational impact of disruption over time?
4. What is the Maximum Tolerable Downtime, or MTD?
5. What are the approved Recovery Time Objective, or RTO, and Recovery Point Objective, or RPO?
6. Do backup, redundancy, cloud, supplier, staffing, and communication arrangements make those targets achievable?
7. Has the organization tested the recovery path and reviewed the results?

Clarysec’s enterprise Business Continuity Policy and Disaster Recovery Policy P32 Business Continuity Policy and Disaster Recovery Policy states the requirement clearly:

Business Impact Analysis (BIA) shall be performed at least annually for all critical business units and reviewed upon significant changes to systems, processes, or dependencies. BIA outputs shall define: 5.2.1. Maximum Tolerable Downtime (MTD) 5.2.2. Recovery Time Objectives (RTOs) 5.2.3. Recovery Point Objectives (RPOs) 5.2.4. Critical dependencies (systems, suppliers, personnel)

That clause gives auditors a practical starting point. It also prevents the common failure where the business continuity plan, disaster recovery plan, backup schedule, supplier register, and incident response process each use a different definition of “critical.”

The same policy requires an integrated management approach:

The organization shall maintain an integrated Business Continuity Management System (BCMS) aligned with ISO 22301 and ISO/IEC 27001, ensuring integration of: 5.1.1. Business Impact Analysis (BIA) 5.1.2. Security risk assessment for continuity threats 5.1.3. Business Continuity Plans (BCPs) 5.1.4. ICT Disaster Recovery Plans (DRPs) 5.1.5. Testing and exercise programs 5.1.6. Documentation and continual improvement

This is the distinction between checklist compliance and audit-ready resilience. The BIA is not a one-off document. It becomes part of the ISMS and BCMS evidence chain.

How ISO/IEC 27001:2022 turns BIA into auditable evidence

ISO/IEC 27001:2022 does not require every organization to use the phrase “Business Impact Analysis” in every clause, but its requirements make BIA evidence extremely valuable.

Clauses 4.1 to 4.4 require the organization to understand internal and external issues, interested parties, legal and regulatory obligations, contractual requirements, interfaces, dependencies, and ISMS scope. A BIA is often the most practical evidence for those interfaces and dependencies. It shows which cloud service, payment processor, identity provider, telecom provider, managed security service, data center, or outsourced support team enables a critical service.

Clauses 5.1 to 5.3 require top management leadership, resourcing, communication, assignment of roles, and reporting. A BIA gives leadership a business basis for continuity investments. Without it, RTO and RPO targets are technical wishes, not approved business requirements.

Clauses 6.1.1 to 6.1.3 require repeatable information security risk assessment and treatment. The organization must identify risks to confidentiality, integrity, and availability, analyze consequences and likelihood, determine risk levels, prioritize treatment, select controls, compare selected controls with Annex A, produce a Statement of Applicability, create a risk treatment plan, and obtain risk-owner approval. A BIA strengthens the “consequence” side of risk assessment. It explains why a two-hour outage of one system is tolerable, while a two-hour outage of another creates customer harm, regulatory exposure, contractual breach, or severe revenue impact.

Annex A provides the control catalogue. For BIA and continuity, the most relevant ISO/IEC 27001:2022 Annex A controls include:

In Zenith Controls: The Cross-Compliance Guide Zenith Controls, Clarysec profiles ISO/IEC 27002:2022 control 5.30, ICT readiness for business continuity, as a corrective control focused on availability, mapped to the Respond cybersecurity concept, the continuity operational capability, and the resilience security domain. Control 5.29, information security during disruption, is profiled as preventive and corrective, protecting confidentiality, integrity, and availability. Control 8.13, information backup, is profiled as corrective, supporting integrity and availability through recovery.

That distinction matters. A BIA must not only ask, “Can we restore?” It must also ask, “Can we remain secure while disrupted?” During a ransomware event, cloud outage, supplier failure, or data center incident, the organization still needs access control, logging, monitoring, evidence preservation, secure communications, and privacy safeguards.

The practical BIA evidence model

A strong BIA connects business language to technical proof. Clarysec typically structures the evidence model in five layers.

This evidence model works because it follows the way auditors think. First, they ask what is critical. Then they ask what supports it. Then they ask who approved the recovery target. Then they ask whether technical and supplier arrangements can meet the target. Finally, they ask whether the organization has tested and improved the capability.

NIST CSF 2.0 is useful as a communication layer. Its CSF Profiles method encourages organizations to define scope, gather inputs such as policies, enterprise risk priorities, BIA registers, cybersecurity requirements, standards, procedures, safeguards, and work roles, create current and target profiles, analyze gaps, produce a prioritized action plan, implement that plan, and update the profile. That is almost exactly how a BIA should feed a cross-compliance roadmap.

A one-week BIA exercise that creates real evidence

Assume a SaaS provider supports financial services customers. Its platform supports client onboarding, document verification, and customer notifications. It is not itself a bank, but its customers are sending DORA-driven contractual requests and NIS2 supplier questionnaires.

A focused one-week exercise can create useful evidence quickly.

Day 1: Identify critical services and impact windows

Start with services, not servers. Involve business owners, IT, security, legal, support, privacy, and supplier management.

This framing is important. Regulators and customers recognize services and functions. Applications matter because they support those services.

Day 2: Map dependencies

For each service, map applications, databases, infrastructure, cloud services, identity providers, monitoring, backup tooling, people, suppliers, and supporting utilities.

This is where the BIA starts producing value. It reveals the invisible recovery path, including the dependencies that are often missed in a technical DR plan.

Day 3: Approve MTD, RTO, and RPO

The business owner proposes MTD. IT and security validate whether the proposed RTO and RPO are technically achievable. Management approves the final targets.

For smaller organizations, Clarysec’s Business Continuity Policy and Disaster Recovery Policy - SME P32S Business Continuity Policy and Disaster Recovery Policy - SME gives the same discipline in simpler language. It requires BCP/DR plans that set out the approach to restoring essential functions:

The General Manager (GM) must approve and maintain Business Continuity and Disaster Recovery Plans (BCP/DRP) that clearly set out the organization’s approach to restoring essential functions.

It also requires the plan to include:

prioritized services and systems (critical business functions)

And:

Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) for each system

The key is not excessive documentation. The key is traceability, approval, and evidence that recovery objectives are based on real business impact.

Day 4: Reconcile backup with business impact

Many organizations fail here. The BIA may set a four-hour RPO, while backups run every 24 hours. Or the backup tool protects production databases, but not configuration, secrets, infrastructure-as-code repositories, object storage, DNS records, identity settings, or API gateway configuration.

Clarysec’s Backup and Restore Policy P15 Backup and Restore Policy requires a Master Backup Schedule tied to BIA outcomes:

A Master Backup Schedule shall be maintained and reviewed annually. It must specify: 5.1.1 Backup frequency (for example, daily incremental backups and weekly full backups) 5.1.2 Retention periods by system or data type 5.1.3 Encryption requirements and storage location details 5.1.4 RTO/RPO targets linked to business impact assessment outcomes

This clause is audit gold. It forces backup design to reflect business impact, not storage convenience.

Day 5: Test one recovery path and open corrective actions

Do not test everything at once. Pick one critical service and run a focused recovery test. Restore the database. Rebuild the application configuration. Validate authentication. Confirm logs are available. Check customer notification capability. Record time taken, data loss, defects, decisions, and corrective actions.

In Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, the Controls in Action phase, Step 23, addresses organizational controls including ICT readiness for business continuity. It asks the question every audit team should ask:

Can your systems support your business continuity objectives when the lights flicker, when networks go down, when disaster strikes?

The same step gives a practical instruction:

Verify that recovery time objectives (RTO) and recovery point objectives (RPO) for critical systems align with business continuity expectations (5.30). Conduct at least one technical recovery test or failover simulation and document the results.

That is the difference between having a BIA and having defensible BIA evidence. The target is not only documented. It is tested.

Mapping BIA evidence to NIS2, DORA, GDPR, NIST, and COBIT 2019

A well-built BIA becomes a cross-compliance asset. One set of evidence can answer many questions.

GDPR is often overlooked in BIA discussions. Yet GDPR Article 5 requires personal data to be processed with integrity and confidentiality, including protection against accidental loss, destruction, or damage using appropriate technical or organizational measures. Accountability requires the controller to demonstrate compliance. If a personal data platform cannot be restored within an approved and tested timeframe, the privacy risk affects availability, integrity, breach assessment, and customer trust.

NIS2 incident reporting adds another dimension. Article 23 requires significant incidents to be notified without undue delay, including an early warning within 24 hours, incident notification within 72 hours, and final reporting within one month. A BIA helps classify severity because it defines affected services, service recipients, operational disruption, and potential cross-border impact.

DORA incident classification also considers affected clients or transactions, duration, geographic spread, data losses, criticality of services affected, and economic impact. These are BIA fields. If the BIA is weak, incident classification becomes subjective during the worst possible moment.

Supplier continuity is where the BIA meets contract reality

For NIS2 and DORA, supplier continuity is no longer optional. NIS2 Article 21 includes supply chain security and requires attention to supplier vulnerabilities, product quality and resilience, supplier cybersecurity practices, and secure development procedures. DORA requires ICT third-party risk to be managed within the ICT risk framework, including registers of ICT service contracts, due diligence, concentration risk, exit strategies, audit and access rights, incident assistance, service levels, and contingency requirements.

The enterprise Business Continuity Policy and Disaster Recovery Policy requires:

Third-Party and Supply Chain Dependencies 6.5.1. Contracts with critical vendors shall include continuity obligations and recovery time commitments. 6.5.2. Key service providers shall, upon request, demonstrate periodic continuity testing and participation in incident drills.

The SME version also requires:

supplier continuity contact points

That small field can be decisive in a real incident. If your recovery plan says “contact cloud provider support,” but no one knows the escalation route, contract reference, severity process, or out-of-hours contact, the RTO is fiction.

This table does not replace supplier risk management. It makes supplier risk operational.

How auditors will test your BIA

An ISO/IEC 27001:2022 auditor will usually start with scope, context, risk assessment, risk treatment, Statement of Applicability, Annex A controls, documented information, operational planning, performance evaluation, and improvement. They will compare the BIA to the risk assessment and SoA. If A.5.30, A.5.29, or A.8.13 are included, they will ask for evidence of implementation and testing.

A DORA reviewer will focus on critical or important functions, ICT assets, ICT third-party dependencies, resilience testing, incident classification, contractual requirements, exit strategies, and management body oversight. They will expect the BIA to align with the ICT risk management framework, digital operational resilience strategy, ICT business continuity plans, response and recovery plans, and testing program.

A NIS2 supervisor will ask for business continuity measures, backup management, disaster recovery, crisis management, supply chain security, governance approval, and significant incident reporting capability. The BIA should prove that these measures are based on service impact and approved priorities.

A NIST CSF 2.0 assessor will ask how the BIA informs the Current Profile, Target Profile, gap analysis, and action plan. They will look at Govern outcomes for legal, regulatory, contractual, risk, role, policy, oversight, and supplier risk decisions. They will also examine Identify, Protect, Detect, Respond, and Recover outcomes.

A COBIT 2019 or ISACA-style auditor will usually focus on governance. Who owns the service? Who accepted the risk? Are objectives aligned with enterprise goals? Are suppliers monitored? Are benefits, risk, and resources balanced? Are corrective actions tracked to closure?

Clarysec’s Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy makes the BIA part of the audit planning cycle:

A risk-based Audit Plan shall be developed and approved annually, taking into account: 5.2.1 The results of the most recent risk assessments and Business Impact Analysis (BIA) 5.2.2 Previous audit findings and corrective action status 5.2.3 Changes in processes, IT infrastructure, systems, or vendors 5.2.4 External obligations such as DORA Article 25 or customer contracts

This is a maturity step many organizations miss. The BIA should not sit outside assurance. It should drive the audit plan.

Common BIA failures found in real assessments

The same weaknesses appear repeatedly.

First, the BIA lists applications, not services. Customers and regulators care about service disruption. Applications matter because they support those services.

Second, RTO and RPO targets are copied from templates. A four-hour RTO may sound reasonable until a restore test shows it takes nine hours to rebuild identity integration, recover configuration, restore data, validate integrity, and re-enable monitoring.

Third, backups are not linked to business impact. Frequency, retention, encryption, storage location, restoration priority, and testing must reflect approved recovery objectives.

Fourth, suppliers are treated as questionnaire items, not recovery dependencies. Supplier continuity commitments, escalation contacts, recovery evidence, and incident drill participation should be tied to critical services.

Fifth, management approval is missing. Under NIS2 and DORA, management accountability is explicit. Under ISO/IEC 27001:2022, leadership, roles, risk-owner approval, and performance reporting are core requirements.

Sixth, testing is too narrow. Restoring one file is useful, but it does not prove service recovery. A critical service recovery path may include DNS, identity, secrets, infrastructure-as-code, API gateways, monitoring, logging, supplier escalation, customer communication, and privacy review.

The Zenith Blueprint, in the Controls in Action phase, Step 19, captures the audit expectation for backups:

Do you test your backups?

The answer must be “yes, with evidence,” and that evidence must connect back to the BIA.

The audit-ready BIA evidence pack

A practical BIA program should produce a concise evidence pack that can be used for audits, customer due diligence, board reporting, and resilience improvement.

This package tells a coherent story. It also makes resilience measurable.

Next step: turn your BIA into compliance evidence

Maria does not need a bigger spreadsheet. She needs a living evidence chain.

Start with one critical service. Map its ICT assets, data, people, suppliers, and utilities. Approve MTD, RTO, and RPO. Reconcile the backup schedule. Check supplier recovery commitments. Run one recovery test. Record gaps. Update the risk treatment plan. Present the result to management.

Then repeat.

Clarysec can help accelerate that process using the Business Continuity Policy and Disaster Recovery Policy, Business Continuity Policy and Disaster Recovery Policy - SME, Backup and Restore Policy, Audit and Compliance Monitoring Policy, Zenith Blueprint, and Zenith Controls.

Your BIA should not be shelfware created for an audit. It should be the operational proof that your most important services can survive disruption, meet customer and regulatory expectations, and recover within limits your leadership has actually approved.

If your organization is preparing for ISO/IEC 27001:2022 surveillance, NIS2 customer assurance, DORA ICT third-party reviews, or board-level resilience reporting, start by making the BIA defensible. Download the Clarysec continuity and audit policies, review the Zenith implementation roadmap, or request a resilience evidence assessment to turn scattered controls into one audit-ready story.