After a ransomware attack, a major outage, or a user error, IT teams often receive the same question: “When will the service be available again, and how far back will the data be restored?” Behind this question lie two distinct objectives: the IT RTO and RPO. Confusing the two leads to unrealistic recovery plans, misdirected investments, and, above all, discrepancies between stated commitments and actual recovery capabilities.

For an organization subject to requirements regarding availability, compliance, or operational resilience, these indicators are not merely technical parameters. They reflect governance decisions: which activities must be restored as a priority, which data can be lost, what resources are justified, and what level of residual risk is acceptable.

IT RTO or RPO: Two Complementary Objectives

RTO, which stands for Recovery Time Objective, refers to the maximum acceptable time required to restore a service, application, or IT capability after an outage. It answers the question: How long can the business operate without this resource before the consequences become unacceptable?

A four-hour RTO means that the affected service must be restored within that specified timeframe. This does not necessarily mean that every technical component must be restored within four hours. The expected outcome must be specified: user access, transaction processing, availability of an interface, the ability to perform a critical operation, or a return to normal service levels.

The RPO, or Recovery Point Objective, expresses the maximum tolerable data loss, measured in terms of time. It answers another question: in the event of a restore, how far back in time—prior to the incident—is it acceptable to go?

A 15-minute RPO means that the organization will accept, at most, the loss of data created or modified during the 15 minutes preceding the incident. An RPO of twenty-four hours may be suitable for certain reference data that is updated nightly, but would generally be unsuitable for payments, market orders, patient records, or e-commerce transactions.

These two objectives are related but not interchangeable. An application can be restored to service very quickly while restoring older data. Conversely, a very recent copy of the data may be available, but the environment needed to run it may take several hours to rebuild. A credible recovery strategy must therefore address both the time to restore service and the data recovery point simultaneously.

The RTO is determined based on business impact

The RTO should not be chosen simply because a technical solution theoretically allows a virtual machine to be restored within one hour. It should first be determined based on an analysis of the impact on business operations.

The process involves identifying priority processes, their critical periods, their dependencies, and the effects of a prolonged outage. The impacts can be financial, regulatory, contractual, operational, or reputational. For a claims processing chain, downtime may be tolerable for a few hours outside of peak periods, but much less so during a major weather event. For a production platform, the threshold may depend on available inventory, safety constraints, and commitments made to customers.

The Business Impact Analysis(BIA) provides the necessary framework. In particular, it helps align the IT RTO with the maximum acceptable downtime for the business activity. The technical RTO must remain below the threshold beyond which the business would suffer unacceptable damage. It must also account for the time required for verification, data reconciliation, and the actual resumption of work—a factor that is frequently underestimated.

The starting point of the timer deserves special attention. Is the incident timed from the moment of detection, classification, the decision to activate the PRA, or the actual service interruption? Without a documented agreement, test results may appear to be in compliance, even though the delay experienced by business units far exceeds the stated target.

The RPO reflects a tolerance for data loss

Defining an RPO involves determining what data needs to be recovered and how much re-entry, reconciliation, or correction the organization is capable of handling. This decision is not the sole responsibility of the IT department. Business unit managers, compliance, internal audit, security, and—depending on the context—the legal department must all be involved in the decision-making process.

The RPO often varies within a single application. Transactional data may require near-real-time replication, while attachments, technical logs, or reference data may require a different backup frequency. A one-size-fits-all approach risks overprotecting secondary data while leaving critical data inadequately protected.

It is also important to distinguish between the freshness of a copy and its restorability. Synchronous replication significantly reduces data loss resulting from a local failure, but it can replicate logical corruption, mass deletion, or malicious encryption to the disaster recovery environment. In a cyberattack scenario, the RPO must therefore be supplemented by a version retention policy, isolated or immutable backups, and controls to identify a healthy restore point.

Technical and financial trade-offs are inseparable

A short RTO and an RPO close to zero generally require more expensive and complex architectures: component redundancy, data replication, automated failover, secondary infrastructure, enhanced monitoring, and frequent testing. These measures provide high recovery capacity but also create additional requirements in terms of operations, security, and change management.

Conversely, a daily off-site backup can meet an RPO of twenty-four hours, but it does not guarantee a rapid recovery or the immediate availability of all dependencies. The time required for data transfer, restoration, network reconfiguration, identity management, and functional validation can make an RTO of a few hours unrealistic.

The appropriate level of protection therefore depends on the business risk, the cost of an outage, and the organization’s ability to temporarily operate in degraded mode. One process may be able to tolerate manual re-entry for one day. Another cannot continue without data that is consistent and continuously available. The goal is not to aim for minimum values across the board, but to justify consistent, proportionate, and verifiable objectives.

Integrating RTO and RPO into a Workable Disaster Recovery Plan

A disaster recovery plan is not limited to listing RTO and RPO values in a table. It must describe the measures needed to meet those targets: activation roles, prerequisites, recovery sequence, dependencies, communication procedures, success criteria, and procedures for returning to normal operations.

Mapping dependencies is crucial. A critical application often depends on a directory service, a DNS service, a network connection, an authentication mechanism, a monitoring tool, third-party interfaces, and teams authorized to intervene. An RTO specified for the application is meaningless if these components are not restored in an order consistent with the business objective.

Contracts with suppliers must also be reviewed. Availability commitments, response times, data recovery procedures, and shared responsibilities in the cloud directly impact the feasibility of the objectives. Using a service provider does not transfer the responsibility for defining continuity requirements or for demonstrating that recovery capabilities meet the established requirements.

Ultimately, only by putting things to the test can an objective be transformed into a demonstrated capability. Exercises must measure the actual time elapsed, the data point actually retrieved, the quality of the restored data, and the business units’ ability to resume operations. A test that restarts an infrastructure without validating transactions, interfaces, and access rights proves only part of the expected capability.

Mistakes That Undermine Recovery Goals

The first mistake is to apply the same RTO and RPO to all applications. While this simplification can sometimes make communication easier, it obscures differences in criticality and unnecessarily drives up costs.

The second mistake is to confuse backup with disaster recovery. A backup is a means of protecting data. It does not, on its own, constitute a disaster recovery strategy capable of meeting a given time frame for restoring operations.

The third is to treat these values as set in stone. Changes in processes, cloud migrations, new interconnections, regulatory requirements, and the emergence of new threats all alter needs and capabilities. Objectives must be reviewed as part of business continuity governance after every significant change and following lessons learned from drills or incidents.

For those responsible for business continuity planning (BCP), disaster recovery planning (DRP), information security (IS), and risk management, the topics of IT RTO and RPO become truly useful when they are framed in a common language shared by business units and IT. Structured training for stakeholders—particularly on business continuity practices and recognized standards—helps ensure that these decisions are traceable and defensible. The right question isn’t just “what number should we report?”, but “what level of downtime and data loss is our organization truly prepared to accept, and can we prove it?”

A business continuity plan (BCP) that has never been tested against a credible disruption remains merely a working hypothesis. The best BCP test scenarios do not seek to prove that the system exists; rather, they verify that priority activities can actually be maintained or resumed within the timeframes set by the organization. This distinction is critical when teams, service providers, technical resources, and decision-makers must act under pressure.

A good test, therefore, is not merely a matter of following a procedure. It highlights poorly understood dependencies, unprepared decisions, and gaps between the business continuity objectives approved by governance and the available operational capabilities. The scenario must be realistic enough to yield insights, without creating a disproportionate risk to the business.

Why the choice of scenario determines the value of the test

The test scenario must be based onthe business impact analysis, the risk assessment, and the actual architecture of dependencies. Conducting an annual building evacuation drill—when the business relies primarily on a critical SaaS platform and a small number of experts—can provide a false sense of security. Conversely, simulating a sophisticated cyberattack without being able to verify recovery decisions or the necessary data may generate a lot of excitement but yield few actionable results.

The ISO 22301 standard does not prescribe a universal list of scenarios. It expects the organization to exercise and assess its business continuity capabilities using a planned approach tailored to its context, objectives, and risks. The level of maturity also matters. An organization formalizing its business continuity plan (BCP) will often begin with tabletop exercises and structured document reviews. A mature organization will need to go further, conducting technical switchover tests, large-scale remote work trials, or cross-entity crisis exercises.

The question we should ask is not just “What kind of event could occur?” It is also: What capabilities must we demonstrate, with whom, within what timeframe, and according to what criteria for success?

The Best BCP Test Scenarios to Prioritize

Unavailability of a website or workspace

The unavailability of an office, a branch, a customer service center, or a production facility remains a key scenario. This can result from a fire, water damage, a security alert, a prolonged power outage, or an administrative decision prohibiting access. Its significance extends beyond real estate alone: it allows for testing the alert system, conducting an employee headcount, making activation decisions, implementing remote work arrangements, and ensuring access to essential tools.

The pitfall lies in assuming that remote work alone ensures business continuity. The test must verify the availability of equipment, secure access, licenses, up-to-date contact information, telephone service, and operational oversight. For activities subject to confidentiality, supervision, or physical presence requirements, it must also confirm the feasibility of a fallback location or a reorganization of teams.

Unavailability of a critical application or infrastructure

This scenario is critical when priority processes depend on an ERP system, a payment tool, a business management platform, an identity directory, or a cloud infrastructure. The exercise may simulate a total outage, a significant performance degradation, the inability to access certain data, or a failure to switch over to the backup environment.

It is not enough to simply ask IT whether recovery is possible. The CMO must assess the business’s ability to operate during the outage and after recovery. Are the teams familiar with fallback procedures? Can manually entered data be reconciled? Are the technical recovery times compatible with the defined MTPD, RTO, and RPO? These questions form the essential link between the disaster recovery plan and business continuity.

Cyberattack resulting in system downtime or data compromise

Ransomware is a particularly useful scenario because it combines system downtime, uncertainty about data integrity, media pressure, and high coordination demands. The exercise should not be limited to the cybersecurity team. It must involve senior management, business unit leaders, IT, legal, communications, human resources, and—depending on the context—relations with authorities or customers.

The key point to watch is the decision-making process. Who classifies the incident? Who decides to suspend services to contain the spread? Based on what criteria is a backup considered valid? Under what conditions are manual processes permitted? A useful exercise puts these trade-offs to the test, including when the available information is incomplete or contradictory.

Simultaneous absence of key staff members

A crisis can render several key employees unavailable without directly affecting the facilities or systems. Whether it’s a transportation strike, a public health crisis, a severe weather event, a local labor protest, or the unavailability of a sole expert, this scenario often reveals an underestimated organizational vulnerability.

The test should identify critical competencies rather than just specific job holders. It verifies the existence of designated substitutes, formal delegations of authority, accessible operating procedures, and a realistic capacity to scale up operations. In certain sectors, it is also necessary to incorporate requirements for segregation of duties, authorizations, on-call duties, and minimum thresholds for qualified staff presence.

Failure of a critical supplier or service provider

Outsourced service chains make this scenario unavoidable. An outage affecting a cloud, telecommunications, logistics, data processing, maintenance, or call center provider can disrupt business operations even if internal facilities remain operational.

The exercise makes it possible to verify not only whether contractual commitments align with actual business continuity needs, but also whether the organization is familiar with its contingency plans. Can it reroute workflows? Use an alternative supplier? Temporarily revert to manual operations? Communicate consistently with customers? The test must focus equally on supplier coordination and internal decision-making, because a contract is no substitute for operational capability.

Combined Scenario: The Maturity Test

Combined scenarios are particularly relevant for organizations that have already undergone training. For example: a cyberattack takes the production environment offline at the same time that a telecommunications provider is experiencing an outage and the primary business manager cannot be reached. This scenario more accurately reflects the reality of a crisis, in which challenges rarely occur in an orderly sequence.

However, this level of exercise must be prepared with care. A scenario that is too complex may make it difficult to identify the source of discrepancies and discourage participants. It should be used only after the fundamental mechanisms—alerting, crisis response team, degraded procedures, recovery, and communication—have already been tested separately.

Designing an exercise that yields evidence

Each test must begin with a specific objective. “Testing the BCP” is too vague. It is better to focus, for example, on the ability to activate the crisis response team in less than thirty minutes, to handle priority operations in degraded mode for four hours, or to restore an application with data that meets the defined RPO.

The scope must then be clearly defined: entities involved, activities, service providers, schedules, assumptions, and limitations of the exercise. This preparation safeguards day-to-day operations and prevents participants from interpreting the rules of the exercise differently. A scenario facilitator, or crisis moderator, advances the scenario by providing successive pieces of information: confirmed unavailability, a call from a customer, failure of a communication channel, or a question from senior management. The facilitator observes without resolving the difficulties on the teams’ behalf.

Evaluation criteria must combine quantitative and qualitative elements. The timeframes for escalation, activation, recovery, and communication are measurable. The quality of decisions, understanding of roles, traceability, and the relevance of communications require a structured assessment. Event logs, crisis team minutes, and evidence of recovery must be retained: they serve to demonstrate the authenticity of the exercise to governance bodies, auditors, or supervisory authorities.

Turning Gaps into an Improvement Plan

The test report should not merely be a list of incidents. Each deviation must be documented with details: cause, affected activity, residual risk level, corrective action, person responsible, and deadline. A missing procedure does not require the same response as an existing but inaccessible procedure, or as a delayed decision due to a lack of clear delegation.

It is helpful to distinguish between immediate fixes and structural improvements. Updating a contact list can be done quickly. Reducing reliance on a single vendor, improving data recovery, or training alternates often requires budgetary trade-offs and governance decisions. Without this follow-through, the exercise becomes a mere compliance ritual and loses its purpose of driving progress.

Training for PCA leaders, crisis response team members, and business unit managers helps in designing appropriate exercises and correctly interpreting the results. In this context, DRI France approaches skills development as part of a professionalization strategy based on recognized standards that are directly applicable within organizations.

Ultimately, the best scenario is one that tests a real dependency, yields observable decisions, and leads to sustained improvement. Rather than seeking out the most spectacular exercise, choose the next test that will tangibly reduce uncertainty about your ability to protect priority operations.

A major disruption cannot be managed only when it occurs. It requires preparation through governance decisions, impact analyses, realistic strategies, and exercises designed to identify gaps. This guide to ISO 22301 certification is intended for professionals who need to translate these requirements into a business continuity framework that is manageable, verifiable, and useful to the business units.

ISO 22301 is the international standard for business continuity management systems (BCMS). It provides a framework for identifying priority activities, setting continuity objectives, organizing the response to incidents, and ensuring continuous improvement over the long term. However, certification can refer to two different things: the certification of an organization by a certification body, or the certification of a professional’s competencies. Confusing the two often leads to choosing an inappropriate path.

Understanding What the ISO 22301 Certification Covers

For an organization, ISO 22301 certification attests that a management system has been assessed against the standard’s requirements. The audit focuses, in particular, on the organization’s context, leadership, planning, support, operations, performance evaluation, and improvement. It does not guarantee that no incidents will occur or that every scenario will be handled without consequences. Rather, it demonstrates that the organization applies a consistent framework to anticipate, manage, and improve its business continuity.

For a professional, certification validates the ability to perform a role in this field: conducting a business impact analysis, formalizing strategies, developing plans, preparing exercises, coordinating crisis management, or auditing a system. This individual certification is particularly relevant for Business Continuity Plan (BCP) and Recovery Plan (RP) managers, Information Security (IS) managers, risk managers, consultants, internal auditors, and managers responsible for operational resilience.

In regulated environments, these two dimensions reinforce each other without being interchangeable. A company seeking certification of its Business Continuity Management System (BCMS) needs personnel trained in the practical application of the standard. Conversely, a certified professional must be able to adapt the principles of ISO 22301 to the maturity level, operational model, and constraints of their organization.

Why Pursue a Professional Certification?

Business continuity is sometimes reduced to a set of documents that are filed away until the next audit or crisis. A structured approach changes this mindset. It links business continuity priorities to the company’s objectives, technological dependencies, critical service providers, contractual obligations, and the human resources that are actually available.

A professional certification provides a methodological framework and a common language. It facilitates communication among business units, IT, cybersecurity, compliance, security, and senior management. It also enables the presentation of well-supported business continuity decisions, including the minimum acceptable service level, recovery time objective, necessary resources, trigger criteria, and crisis responsibilities.

Its value, however, depends on the context. For someone who participates in exercises on an occasional basis, targeted training may be sufficient. For a professional tasked with leading a program, reviewing impact analyses, or preparing a compliance assessment, an in-depth course with an exam is a more appropriate investment. The right choice depends less on the specific certification sought than on the scope of responsibility expected after the training.

Skills to Master in an ISO 22301 Program

A thorough approach goes beyond simply commenting on the clauses of the standard. It must enable the transition from requirements to an operational system. The first skill is understanding the context: stakeholders, legal and contractual requirements, the scope of the SMCA, critical services, and internal and external dependencies.

Next comesthe business impact analysis, often referred to by the acronym BIA. It helps determine the consequences of a disruption and prioritize business processes. Its quality depends less on the number of questionnaires administered than on the ability to obtain credible business trade-offs. Recovery times and service levels must be consistent with the organization’s commitments—not just its stated goals.

Defining business continuity strategies is another critical step. Fallback sites, organized remote work, IT redundancy, manual procedures, alternative suppliers, or substitute capabilities: no single solution is universal. A costly strategy may be justified for a mission-critical activity, but disproportionate for a process where an interruption of several days is tolerable. Certification bodies must learn to evaluate this balance between criticality, cost, time, and residual risk.

Finally, the competencies focus on documentation and implementation: business continuity plans, crisis management procedures, communication, contact management, drills, and lessons learned. A useful plan is easy to understand even under pressure. It specifies who makes decisions, what information is needed, what actions must be taken, and how stakeholders are informed. Its value is proven during a realistic exercise, not just during its formal approval.

Choose the certification level that best suits your role

Choosing a path should start with a simple question: What decisions will you need to be able to make or influence? A manager responsible for developing a business continuity plan does not have the same needs as an auditor tasked with assessing compliance. Similarly, an IT recovery specialist must understandthe relationship between the Disaster Recovery Plan (DRP) and the Business Continuity Plan (BCP), without necessarily being solely responsible for the overall governance of the Business Continuity Management System (BCMS).

Professionals who design or lead the process should seek training that covers the entire lifecycle: scoping, BIA, strategies, plans, exercises, maintenance, and improvement. Those involved in assurance, monitoring, or auditing would benefit from gaining a deeper understanding of interpreting requirements, gathering evidence, and evaluating nonconformities.

The format also warrants careful consideration. An intensive session is appropriate when participants already have a solid grasp of the fundamentals and the goal is to quickly reinforce practical skills. A more in-depth program is better suited for someone starting a new role, an organizational certification initiative, or a program involving complex interdependencies. In-house training, on the other hand, can accelerate alignment among teams when participants need to apply a common method within the same scope.

Finally, the exam serves as a useful benchmark. It does not replace the experience of handling an incident or professional knowledge, but it does validate mastery of a structured body of knowledge. To be truly valuable, it must be based on a recognized framework and supplemented by regular practice with real-world cases.

Preparing to Apply What You’ve Learned in the Workplace After Training

Training yields results when it quickly leads to a specific action. This could involve reviewing the scope of the SMCA, updating an outdated BIA, formalizing a business continuity policy, clarifying crisis governance, or developing an exercise program. Waiting until the end of an overall project to take action risks losing the momentum that has been built up.

A pragmatic approach involves selecting a priority area and then demonstrating the method. This area must be critical enough to engage decision-makers, yet manageable enough to yield results within a reasonable timeframe. The lessons learned can then be extended to other activities, using consistent governance rules and documentation templates.

Management must be involved from the outset. Business continuity requires trade-offs regarding budgets, acceptable risk levels, recovery priorities, and decision-making authority. Without a sponsor capable of making decisions, the plan risks remaining purely technical and failing to reflect the organization’s actual needs.

Indicators also play an important role. The implementation rate of business continuity plans (BCPs), coverage of critical activities, adherence to the exercise schedule, the turnaround time for corrective actions, and the availability of crisis contacts provide a more useful overview than a simple inventory of plans. They make it possible to assess whether the SMCA is making progress and where persistent vulnerabilities lie.

Using Certification as a Tool for Resilience

ISO 22301 certification should not become an end in itself. It is meaningful when it helps make better decisions before, during, and after a disruption. This requires keeping analyses up to date, incorporating organizational changes, testing assumptions, and addressing feedback without complacency.

For French-speaking professionals, a structured program such as those offered by DRI France makes it possible to align international standards with local operational realities. The challenge is not merely to pass an exam: it is to have a methodology that can be defended before auditors, understood by business units, and applied when a crisis situation requires swift action.

The best next step is to align the target certification level with a specific need within your organization. A clearly defined role, a priority scope, and an initial planned exercise will ensure that the acquired competency has the greatest practical impact.

An outage lasting a few hours may be tolerable for a support function, but it becomes unacceptable for a payment service, a supply chain, or a healthcare platform. This enterprise RTO/RPO guide helps translate this operational reality into measurable, governed, and defensible recovery objectives that can be presented to business units, senior management, and regulatory bodies.

RTO and RPO are not technical parameters to be selected from an infrastructure catalog. They represent a level of risk accepted by the organization. Their definition is therefore part of a business continuity process involving business units, the IT department, cybersecurity, risk management, and crisis response leaders.

RTO and RPO: Two Different Objectives, One Continuity Plan

The Recovery Time Objective (RTO) is the maximum acceptable downtime for an activity, service, or resource following an incident. It answers a simple question: How long can we remain unavailable before the consequences become unacceptable?

The Recovery Point Objective, or RPO, refers to the maximum amount of data that an organization is willing to lose, expressed in terms of time. An RPO of four hours means that, in the scenario covered, a restore can return the data to a state no more than four hours prior to the incident.

These two concepts are related, but not interchangeable. An application may need to be back online within two hours while tolerating a data loss of thirty minutes. Conversely, a regulatory process may allow for recovery the next day but require virtually no data loss. The first scenario primarily requires rapid recovery or failover; the second demands more stringent data protection and replication.

It is also important to distinguish between the RTO and the actual recovery time observed. The RTO is a formally approved target. The recovery time observed during an exercise or incident is a performance metric. When the two repeatedly diverge, the business continuity plan must be reviewed, or the objective reassessed with decision-makers.

RTO/RPO Guide for Businesses: Starting with the Business Impact

The quality of the objectives depends first and foremost on the quality ofthe business impact analysis(BIA). Setting an RTO simply because a competitor has an active-active architecture—or because a vendor offers it—often leads to overprotecting secondary resources and underprotecting a critical process.

The analysis must identify the incremental consequences of an outage: lost revenue, contractual penalties, service disruption, risk of non-compliance, threats to personal safety, inability to inform customers, or lasting damage to reputation. Time is of the essence here. The impact of a two-hour outage is not necessarily twice that of a one-hour outage: it can cross a critical threshold at market opening, on a reporting deadline, or during a seasonal peak.

Formulate a goal at the appropriate level

A recovery objective must be defined at the level where the decision makes sense. The starting point is generally the critical business process, followed by the business unit, the application, the data, the infrastructure, and the suppliers necessary for its implementation.

A four-hour RTO applied uniformly to all applications within a scope is rarely credible. A single platform can support very different use cases, each with distinct tolerance windows. In this case, it is necessary to either distinguish between the services provided or clearly explain the arbitration rule that was chosen.

The wording must also specify the scope of recovery. Powering up a server does not mean restoring service. Recovery may require network access, identities, certificates, interfaces, data flows, workstations, manual procedures, and business validation. The RTO must cover the return to a defined service level, not just the availability of a single component.

Define the RPO Based on the Data Value

RPO warrants specific analysis. Not all data is equally sensitive to loss. Customer orders, accounting entries, security logs, and production data may require very short recovery time objectives. Reference documents or archives that are not updated daily may be subject to a less frequent backup schedule.

However, a low RPO entails certain operational and financial decisions: frequent replication, log retention, transactional consistency mechanisms, network capacity, additional storage, and enhanced monitoring. In an environment vulnerable to ransomware, replication alone is no guarantee. It can quickly replicate corruption or encryption. Isolated copies—immutable where appropriate—and controlled restore points remain necessary.

Making Objectives Achievable in Architecture

Once the business requirements have been validated, the IT department and the security teams evaluate the means necessary to meet them. This step often reveals the gap between the system’s ambitions and its actual capabilities.

For a short RTO, the strategy may rely on local high availability, a switchover to a disaster recovery site, a pre-provisioned disaster recovery infrastructure, or automated recovery. The best choice depends on the system’s criticality, the budget, available expertise, sovereignty constraints, and the nature of the feared scenarios. A solution that is effective against a hardware failure may be insufficient in the face of an identity compromise or widespread unavailability of a provider.

The RPO, on the other hand, depends on the frequency and method of protection. Daily backups, asynchronous replication, synchronous replication, application logging, or periodic exports do not result in the same cost or the same level of assurance. Consistency must be evaluated beyond just the volume of data: is it possible to restore a consistent set of databases, files, messages, and interfaces?

Dependencies are a major area of concern. An ambitious goal for an application is meaningless if the authentication service, DNS, connectivity, payment provider, or telecommunications services cannot be restored within a reasonable timeframe. Mapping must highlight these technical, human, and external dependencies, and then identify which ones actually determine the recovery time.

Substantiate with evidence, not just statements

An RTO or RPO specified in a plan is considered reliable only after tests designed to provide evidence have been conducted. The tests must verify the time elapsed between the decision to resume operations and the expected actual return to service, as well as the data point that was actually restored.

The most useful exercises simulate realistic conditions: the unavailability of a key administrator, overwhelmed communication channels, configuration errors, degraded vendor reliability, or a suspected cyberattack. They also help test the crisis response team’s decision-making capabilities. In some scenarios, the challenge is not only to resume operations quickly, but to decide when it is safe to do so.

The results must be accurately documented: the intended objective, scenario, scope, time of initiation, steps taken, actual time taken, data lost or restored, difficulties encountered, and corrective actions. This traceability supports governance, auditing, and the continuous improvement expected in an approach aligned with ISO 22301.

Establishing Sustainable Governance for RTOs and RPOs

Recovery objectives evolve in response to business activities, regulatory requirements, contracts, architectures, and threats. An RTO that is appropriate at the time of deployment may become insufficient after a process is automated or a new sales channel is opened.

Governance must therefore assign clear responsibilities. Business units validate the acceptable level of impact. The IT and cybersecurity teams confirm feasibility, assumptions, and residual risks. Senior management decides on investments when the required level of resilience exceeds existing capabilities. The business continuity function ensures overall consistency and monitors supporting documentation.

A structured review is particularly necessary following a major incident, a significant application change, a cloud migration, the onboarding of a critical service provider, or an unsatisfactory test result. Training stakeholders in a common language and established methods facilitates these decision-making processes. With this in mind, DRI France supports professionals who must align business requirements, business continuity, IT disaster recovery, and crisis management.

The right RTO and RPO are not the lowest possible values. They are the ones that the company understands, funds, tests, and maintains over the long term, because they truly protect what needs to be protected when operating conditions are no longer normal.

An outage lasting a few hours does not have the same impact on a payment service, a production platform, a call center, or a support function. Knowing how to conduct a BIA allows you to objectively assess these differences and translate them into business continuity decisions. The goal is not to produce yet another inventory, but to determine what the organization must preserve, within what timeframe, and with what resources.

Business Impact Analysis is a key component of a business continuity management system. It informs continuity strategies, business continuity plans, IT recovery plans, and crisis management procedures. Within a framework aligned with ISO 22301, it primarily provides a defensible governance foundation for senior management, auditors, and, where applicable, regulatory authorities.

What the BIA Analysis Actually Measures

A BIA assesses the consequences of a service outage over time. It therefore does not primarily seek to identify the possible causes of an incident. That task falls under risk analysis. The two approaches are complementary: risk analysis helps understand threat scenarios and preventive measures; the BIA determines which business consequences are acceptable or unacceptable if an activity can no longer be performed.

The impacts to be considered go beyond immediate revenue loss. Depending on the sector and the scope of the analysis, the assessment may include regulatory, contractual, financial, operational, reputational, social, environmental, or personal safety-related consequences. A business activity can thus be critical even if it does not generate direct revenue—for example, when it ensures compliance, site security, or fulfillment of a legal obligation.

The central concept is that of change over time. A two-hour outage may be tolerable, whereas after twenty-four hours it results in penalties, a disruption of regulated service, or a backlog of cases that is impossible to clear. The BIA must make this progression clear, rather than assigning a criticality label without justification.

Define the scope and governance before collecting data

The quality of the results depends largely on the initial scope of the analysis. It is important to specify the entities involved, the processes being analyzed, the sites, the products and services, as well as the working assumptions. An analysis covering the entire group does not have the same level of detail or involve the same stakeholders as a BIA conducted within a regulated scope, at an industrial site, or across a digital services chain.

Management must approve this scope and appoint a sponsor capable of resolving priority conflicts. The business continuity team leads the process, but it cannot determine on its own what is critical. Process managers, application owners, IT teams, and the security, finance, legal, and human resources departments, as well as key service providers, each hold a portion of the necessary information.

Before the interviews, it is helpful to adopt a common impact scale. It could, for example, consist of five levels ranging from negligible to major. Each level should be described using specific criteria: amount of loss, breach of a contractual obligation, notification timeframe, number of affected customers, or consequences for individuals. Without this framework, two departments may assess the same consequence using incompatible standards.

How to Conduct a BIA Analysis in Operational Steps

The process begins with mapping activities and processes. It is important to distinguish between activities that are actually performed and mere organizational charts or application names. A claims management process, for example, may include receiving claims, assessing them, making a decision, notifying the customer, making a payment, and reporting. These steps do not necessarily have the same level of criticality or the same dependencies.

Next comes the collection of information, typically through a preliminary questionnaire followed by workshops or interviews. The questionnaire alone is rarely sufficient: it sometimes yields cautious, overly general responses, or answers influenced by the perceptions of the team being surveyed. The discussion allows us to test hypotheses, identify seasonal variations, and distinguish between actual needs and preferences for operational convenience.

For each activity, the people in charge must specify, in particular:

• the products, services, or obligations it supports;
• the impacts of an outage over various time horizons;
• business volume, peak periods, and non-negotiable deadlines;
• the minimum resources required for a degraded recovery;
• internal, external, human, real estate, technological, and informational dependencies.

Dependency analysis deserves special attention. An activity deemed a priority may depend on an application, a data flow, a supplier, a rare skill, or a specific location. If these elements are not identified, the business continuity plan risks outlining a theoretical recovery scenario. Conversely, an overly detailed inventory quickly becomes unworkable. The appropriate level of granularity depends on the organization’s maturity and the decisions that the data is intended to support.

Set recovery goals without making false commitments

Based on the impacts, the organization determines the maximum acceptable downtime, often referred to as MTPD or MTD depending on the terminology used. It represents the point at which the consequences become unacceptable. This duration should not be confused with the recovery time objective (RTO). The RTO represents an operational target: operations must be restored before reaching the maximum downtime threshold.

This distinction is essential. If a business unit specifies that a service cannot be unavailable for more than twenty-four hours, setting an RTO of twenty-four hours leaves no margin for the incident itself, crisis response, unforeseen events, or recovery verification. A shorter recovery target may be appropriate, but it must be compatible with technical capabilities, available resources, and the cost of the solution.

For data-driven operations, the RPO complements the analysis. It indicates the maximum amount of data that could be lost between the last usable backup and the incident. An ambitious RTO with an RPO of twenty-four hours may be suitable for certain batch processes, but not for a critical transaction or an operation subject to strict traceability requirements.

It is also necessary to define the minimum acceptable level of service. Resuming operations does not necessarily mean immediately restoring all functions, volumes, and channels. A temporary manual procedure, prioritized processing of urgent cases, or reduced capacity can all constitute a valid business continuity solution. However, this strategy must be realistic, testable, and validated by the business unit.

Consolidate, reconcile, and validate the results

BIA often reveal inconsistencies. Several processes may require immediate recovery, even though available resources allow only a limited number of them to be restarted. Some requirements may also rely on shared technical dependencies, which alters the actual order of recovery.

The consolidation phase therefore translates interview findings into organizational priorities. It must align business objectives with IT constraints, supplier capabilities, contractual requirements, and fallback options. The goal is not to mechanically scale back expectations, but to make the necessary trade-offs explicit.

A useful BIA report outlines, for each priority activity, the impacts, the maximum tolerable downtime, the target RTO, the RPO (if applicable), the minimum service level, critical dependencies, and expected decisions. It must also highlight any gaps: lack of a recovery solution, unaddressed vendor dependencies, insufficient human resources, or objectives that are incompatible with the existing architecture.

Approval by process owners and the appropriate governance body is essential. Without formal approval, objectives remain mere statements of intent. With it, they become requirements against which strategies and plans can be measured.

Making BIA a dynamic process

A BIA is not a static document produced for an audit. It must be reviewed whenever significant changes occur, such as an acquisition, outsourcing, the launch of a new service, digital transformation, regulatory changes, developments involving a critical supplier, or lessons learned from an incident. A scheduled review is also necessary, even in the absence of visible changes, because dependencies often evolve faster than procedures.

Maturity is measured less by the length of the questionnaire than by the ability to use the results. An effective BIA enables organizations to prioritize investments, design proportionate strategies, prepare credible exercises, and justify decisions to governance bodies. For professionals responsible for structuring this process, specialized training—such as that offered by DRI France—helps them apply a consistent methodology and align the analysis with the requirements of a comprehensive business continuity plan.

The litmus test is simple: when a major incident occurs, teams must be able to explain without hesitation which activities to resume first, to what extent, and with what dependencies. It is this decision-making capability that defines a truly actionable BIA analysis.