For my previous article about RTO and RPO, click here.

Revisiting DRP: Understanding RTO and RPO

1. The foundation: RTO and RPO

Before discussing backup products, replication, AI or recovery automation, we need to establish what the organization is trying to achieve.

RTO and RPO are not technical settings that an infrastructure administrator should choose independently. They are recovery objectives derived from business requirements, operational dependencies and the consequences of service interruption or data loss.

NIST SP 800-34 Rev. 1 provides the relevant contingency-planning definitions. It also distinguishes RTO from Maximum Tolerable Downtime (MTD). RTO should normally be shorter than MTD, leaving room for the business to resume its operations before the maximum tolerable period is exceeded.

1.1 Recovery Time Objective (RTO)

RTO defines the maximum acceptable time for restoring a system or business service after a disruption.

For example, suppose an organization determines that its customer-management application must be available again within four hours.

Its RTO is four hours.

However, this does not mean that the organization has four hours to copy files back onto a server. Recovery may involve several activities:

• Detecting and assessing the incident.
• Declaring a recovery event.
• Isolating affected systems.
• Preparing trusted infrastructure.
• Restoring applications and databases.
• Reconnecting dependencies.
• Validating data integrity.
• Testing application functionality.
• Obtaining authorization to resume normal operations.

All these activities can consume recovery time.

I would therefore measure RTO against the restoration of the actual business service, not merely the completion of a backup restoration job.

1.2 Recovery Point Objective (RPO)

RPO defines how far back in time the organization can accept recovering its data after a disruption.

For example, suppose a database has an RPO of 15 minutes.

This means the recovery strategy must be capable of restoring the required data to a sufficiently trustworthy point no more than 15 minutes before the relevant disruption or data-loss event.

It does not necessarily mean that running a backup every 15 minutes guarantees a 15-minute RPO.

We also need to consider:

• Whether each backup completed successfully.
• Whether database transactions were captured consistently.
• Whether replication was delayed.
• Whether the latest recovery point contains corrupted data.
• Whether the backup repository becomes inaccessible.
• Whether the recovery process can identify a trustworthy version.

This last point deserves particular attention.

The latest backup may not be the latest trustworthy backup.

1.3 RTO and RPO are different objectives

Illustrative recovery timeline

• 08:00: Disruption occurs.
• 12:00: Service is restored.
• Example RTO: 4 hours.
• Example RPO: 15 minutes.

These are illustrative objectives, not universal requirements. The time of disruption and the recovery-point timestamp must be defined consistently in the recovery plan.

An organization can meet its RPO and still fail its RTO. For example, it may have a recent, clean backup but lack enough infrastructure capacity to restore the service quickly.

Likewise, it can meet its RTO while failing its RPO. A service may return quickly using an older backup, but the organization may lose more data than it agreed to tolerate.

Successful recovery means meeting both objectives, while also restoring trustworthy data.

2. RTO: Planning for Service Recovery

RTO should be determined by the business process, not simply by the hardware or software specifications.

A server may take 20 minutes to rebuild, but the application running on it may depend on a database, authentication service, DNS, network routing, storage, and external APIs.

Even after the server is available, the actual business service may not be ready.

2.1 Start with a Business Impact Analysis (BIA)

Before defining RTO, we need to understand the impact of losing each service.

A Business Impact Analysis helps identify which business activities depend on each system and what happens when those activities become unavailable.

Consider the following:

The same infrastructure component may support several business activities.

For example, a database server may support patient information, reporting, and administrative applications. Recovering the server therefore has consequences beyond simply restoring one database instance.

I would consider the following questions when conducting a BIA:

• Which business activities depend on this system?
• How long can each activity remain unavailable?
• Are there alternative procedures?
• Can employees continue using manual processes?
• Are there external services or vendors involved?
• Does interruption create financial, legal, operational, or safety consequences?
• Does the system process information that cannot easily be reconstructed?

The answers should come from the people responsible for those business activities, not only from the infrastructure team.

AI Operator’s role

AI can assist with gathering information from asset inventories, service catalogues, application configurations, monitoring systems, and dependency records.

It can help identify systems that share common infrastructure and highlight services that may have been overlooked during the BIA.

For example, it may identify that several applications depend on the same identity provider or storage platform.

However, the AI should propose dependencies and potential impacts, while business owners confirm their importance.

2.2 Establish recovery tiers

Not every system requires the same RTO.

A practical approach is to divide infrastructure into recovery tiers.

The following is an illustrative classification, not a universal set of recovery requirements.

The actual targets should be determined through the BIA and approved by the business.

For example, a healthcare monitoring service may require a shorter recovery target than an internal reporting dashboard.

However, we should not assume that every healthcare application has identical recovery requirements. Clinical service owners need to assess the consequences of interruption and approve the applicable objectives.

AI Operator’s role

AI can help classify systems using existing asset information, operational dependencies, and recorded business priorities.

It can also compare the proposed RTO against historical recovery exercises.

If a system has an approved RTO of four hours but the last three restoration exercises required six hours, AI can highlight the mismatch.

The organization must then decide whether to improve the recovery architecture or revise the objective through an appropriate business decision.

2.3 RTO is a complete recovery process

One common mistake is measuring RTO only from the moment the administrator starts restoring a backup.

The actual recovery process involves much more.

I would divide it into the following activities:

The organization should establish exactly when its RTO clock starts and what constitutes successful recovery.

Detection and decision delays should never be ignored simply because the technical restoration process has not started.

AI Operator’s role

AI can coordinate these activities by collecting incident information, identifying affected systems, notifying the correct teams, preparing relevant recovery procedures, and tracking recovery milestones.

It can also identify bottlenecks.

For example, if an organization consistently spends 45 minutes identifying the affected systems before beginning restoration, AI-assisted asset correlation could help reduce that delay.

The AI should not independently declare a healthcare service safe to resume or override the recovery authority.

3. RPO: Planning for Data Recovery

RPO is particularly important when dealing with databases, transaction systems, patient information, and other continuously changing data.

Unlike RTO, which is concerned with service availability, RPO is concerned with the amount of data that an organization can afford to lose.

3.1 RPO is not simply backup frequency

Suppose an organization creates a backup every 15 minutes.

It may appear that the organization has a 15-minute RPO.

However, several situations can affect the actual result:

• A scheduled backup fails.
• A backup takes longer than expected.
• Transaction logs are not captured.
• Database replication falls behind.
• The latest backup contains corrupted records.
• The backup repository becomes inaccessible.
• A security incident affects multiple recovery copies.

Consequently, a 15-minute backup schedule does not automatically guarantee a 15-minute RPO.

We need to verify that the organization can actually recover a consistent and trustworthy version of its data within that interval.

3.2 Different data requires different RPOs

Not every dataset changes at the same rate or has the same importance.

Consider the following examples:

These are illustrative values only. The appropriate target depends on the business requirements, technology, data-generation rate, and recovery architecture.

For example, a healthcare monitoring system may require very frequent data capture because losing recent patient measurements could affect clinical workflows.

An internal reporting warehouse may tolerate a longer recovery interval if the underlying information can be reconstructed from other trusted sources.

AI Operator’s role

AI can help identify data that requires a more frequent protection schedule.

By examining transaction volumes, change rates, application dependencies, and historical data loss, it can help identify whether existing backup intervals are appropriate.

It can also alert administrators when actual backup performance no longer supports the approved RPO.

3.3 The latest backup may not be the latest good backup

This is where your earlier idea about data integrity becomes particularly important.

Suppose an organization creates backups every 15 minutes.

At 08:00, its production database is compromised.

The scheduled backup at 08:15 completes successfully.

The backup system reports:

• Job completed.
• Files copied.
• Storage available.
• Checksum verified.

However, the database already contains unauthorized modifications.

The backup is technically complete, but the information is not trustworthy.

The organization may need to recover from the 07:45 backup instead of the 08:15 backup.

This introduces an important distinction:

Latest backup versus latest verified recovery point.

The latest recovery point should not automatically be considered the correct recovery point.

NIST SP 1800-11 specifically addresses recovering data integrity after destructive events, while SP 1800-25 discusses protecting information against corruption, unauthorized modification and destruction.

AI Operator’s role

AI can compare historical backup information, detect unusual modifications, correlate security events, and identify recovery points that require further investigation.

It can help answer:

• When did abnormal changes begin?
• Which datasets were affected?
• Which backup versions contain similar changes?
• Which recovery point appears to be the last known-good version?
• What evidence is available to support that conclusion?

However, an AI-generated conclusion is not proof that a dataset is clean.

It must be supported by deterministic integrity checks, application validation, security analysis and, when necessary, human investigation.

4. RTO and RPO Must Follow the Dependency Chain

One of the most overlooked areas in DRP is system dependency.

An application may have an excellent backup strategy, but restoring it without its dependencies will not restore the business service.

Consider a typical application environment:

Business Application
        |
        +-- Database
        |
        +-- Authentication / IAM
        |
        +-- DNS
        |
        +-- Network Gateway
        |
        +-- Storage / NAS / SAN
        |
        +-- External API
        |
        +-- Monitoring and Logging

If the application depends on an authentication service that is unavailable, restoring the application alone may not help.

Likewise, a restored database may be unusable if the encryption keys, configuration files, certificates, or required software versions are missing.

4.1 Recovery order

A recovery plan should establish the order in which systems need to be restored.

An example sequence might be:

1. Confirm the recovery environment and administrative access.
2. Restore essential network and infrastructure services.
3. Re-establish trusted identity and access services.
4. Restore storage and database infrastructure.
5. Restore core applications.
6. Reconnect supporting integrations.
7. Verify monitoring, logging and security controls.
8. Validate the business service.

This sequence is an example rather than a universal runbook. Actual dependencies may require a different order.

For example, a backup system may depend on a separate identity provider, but the identity provider itself may require infrastructure that must be restored first.

These relationships need to be documented before a disaster occurs.

AI Operator’s role

This is an area where AI-assisted orchestration can be particularly useful.

AI can maintain a dependency map by correlating:

• Infrastructure inventories.
• IaC definitions.
• Service configurations.
• Application dependency files.
• Network information.
• Monitoring data.
• Historical recovery procedures.

When a system becomes unavailable, it can identify which other services may be affected and suggest a recovery sequence.

It can also monitor whether the required dependencies have become available before the next restoration stage begins.

The final sequence should still follow approved recovery procedures. AI should not invent new production dependencies or assume that a system is safe simply because it responds to a network request.

5. Data Separation: Protecting the Recovery Environment

I think this should be one of the most important sections of the DRP article.

A conventional backup strategy might use the 3-2-1 rule:

• Keep three copies of data, including production.
• Use two different storage types.
• Keep one copy off-site.

However, the existence of multiple copies does not automatically mean that they are independent.

If all copies depend on the same identity provider, administrative account, network or management platform, an incident affecting those shared components may affect the entire backup environment.

5.1 Separate production and backup environments

Production and backup environments should have different security boundaries.

For example:

The objective is to prevent the compromise of ordinary production credentials from automatically providing unrestricted control over recovery copies.

5.2 Separate credentials and permissions

Backup administration should not depend entirely on the same accounts used for ordinary production operations.

Consider the following:

• Separate backup service accounts.
• MFA for backup administration.
• Privileged access management.
• Restricted deletion permissions.
• Time-limited administrative access.
• Independent backup audit logs.
• Separate protection for encryption keys.

Production applications should generally have only the permissions required to send data to the backup service.

They should not have unrestricted permission to delete historical backup copies or modify retention policies.

5.3 Offline and immutable copies

Online backups are useful because they are readily accessible.

However, they may also be exposed to incidents affecting the production network.

An offline copy is disconnected when not being used.

An immutable backup is protected against modification or deletion during its defined retention period.

These are different properties.

Immutability does not automatically mean that the data is correct. It only helps protect the stored copy against unauthorized changes within the relevant protection mechanism.

An immutable backup can preserve corrupted data just as effectively as it preserves healthy data.

The Canadian Centre for Cyber Security recommends offline backups, encryption, multiple storage locations and routine recovery testing.

5.4 Replication is not the same as backup

This distinction is especially important for NAS and SAN environments.

Replication helps maintain another copy of current data.

However, if unauthorized modifications or destructive changes occur in the source environment, those changes may also be replicated.

For example:

• Production database records are modified.
• Storage replication transfers the modifications.
• The secondary storage now contains the same modified records.

The secondary copy may be available, but it is not necessarily a suitable recovery point.

Replication should therefore complement historical backups, snapshots and other recovery controls rather than replace them.

AI Operator’s role

AI can continuously monitor the backup architecture for shared risks.

For example, it can identify:

• Production and backup systems using the same administrative identity.
• Backup repositories accessible from ordinary application networks.
• Unusual deletion or retention-policy changes.
• Replication delays.
• Backup destinations that have stopped receiving data.
• Missing offline backup verification records.

This is an important opportunity to use AI as an operational coordinator rather than as another backup product.

It can help identify weaknesses across the entire recovery architecture, even when the individual backup jobs report success.

6. Data Integrity: Is the Information Worth Recovering?

Having a technically valid backup is not the same as having accurate business information.

We should distinguish three different questions:

1. Can we retrieve the backup?
2. Has the stored backup changed unexpectedly?
3. Was the original information trustworthy when it was backed up?

These questions require different forms of validation.

6.1 File integrity

For files and backup archives, cryptographic hashes can help detect unexpected changes.

A hash calculated during backup creation can be compared with a hash calculated later.

If the values differ, the stored content may have changed.

However, matching hashes only demonstrate that the data matches the reference used for comparison.

They do not establish that the original data was accurate or free from compromise.

6.2 Database integrity

Databases require additional checks.

Depending on the database platform, we may need to examine:

• Database consistency.
• Transaction logs.
• Referential integrity.
• Record counts.
• Schema versions.
• Transaction sequencing.
• Unexpected modifications.
• Application-level validation rules.

For example, a database may pass its internal consistency checks while containing unauthorized changes to valid records.

The database structure is healthy, but the information is wrong.

6.3 Business data integrity

This is where application-specific validation becomes important.

Consider a healthcare database.

A record may be structurally valid and contain all required fields, but its contents may have been modified without authorization.

We may need to compare historical records, audit logs, timestamps, approved changes and other trusted sources.

Similarly, a financial system may require reconciliation against transaction records and external statements.

The checks must reflect the purpose and meaning of the data.

AI Operator’s role

AI can assist by identifying unusual patterns across historical data.

Examples include:

• Sudden changes in record volumes.
• Unexpected modification of old records.
• Unusual deletion patterns.
• Changes outside normal business hours.
• Unusual relationships between records.
• Unexpected changes in file structures.
• Differences between historical and current datasets.

AI may also help correlate suspicious activity with user accounts, services and backup events.

However, statistical anomalies are not necessarily security incidents. Normal business activity can create unusual patterns.

AI should identify findings for investigation, not automatically decide which information is correct.

7. AI Operator: Coordinating the DRP Lifecycle

I would introduce the AI Operator as a supporting layer that works across the entire recovery process.

It is not intended to replace the backup platform, storage system, monitoring solution or recovery team.

Its role is to connect information from these systems and help coordinate their activities.

Think of the existing infrastructure as the individual components responsible for performing their tasks.

The AI Operator acts more like an orchestrator, helping those components work together according to the organization’s recovery requirements.

7.1 Preparation and planning

Before an incident occurs, AI can help maintain the recovery inventory.

It can examine asset records, configurations, deployment templates, application dependencies and historical changes.

It can help answer:

• Which systems are essential?
• Which services depend on each other?
• Which datasets require frequent backup?
• Which systems have no verified recovery procedure?
• Which components have outdated recovery documentation?
• Which services may not meet their approved RTO?

It can also identify differences between documented infrastructure and the actual running environment.

This is particularly useful when infrastructure changes frequently through IaC and self-service provisioning.

7.2 Backup monitoring

AI can continuously examine backup operations.

Rather than checking only whether a job reports success, it can correlate:

• Backup duration.
• Data volume.
• Change rate.
• Replication delay.
• Storage availability.
• Previous job results.
• Backup destination health.

For example, a database that normally generates 10 GB of incremental backup data every day may suddenly generate 300 GB.

There may be a legitimate reason, such as a database migration or large batch operation.

However, the change should be investigated.

AI can identify the deviation and help correlate it with infrastructure events.

7.3 Integrity monitoring

AI can help monitor changes in the original production data and compare them with historical behaviour.

It may detect suspicious patterns before the next scheduled backup completes.

This is particularly important because backups often preserve whatever data exists at the time of the backup.

The earlier a corruption event is detected, the greater the opportunity to preserve a clean recovery point.

However, the underlying validation should still use reliable integrity mechanisms such as checksums, transaction validation, audit records and application-specific consistency tests.

7.4 Incident analysis

When an incident occurs, AI can assist in building a timeline.

It can correlate:

• Security alerts.
• Application logs.
• Database changes.
• Authentication events.
• Backup records.
• Network activity.
• Configuration modifications.

This can help establish which systems and datasets may have been affected.

It can also identify which recovery points need further investigation.

This is important because the first system reporting a problem may not be the original source of the incident.

7.5 Recovery orchestration

Once the recovery plan is activated, AI can assist with coordinating the approved recovery sequence.

For example:

1. Confirm the affected services.
2. Identify the approved recovery environment.
3. Check the availability of required infrastructure.
4. Identify candidate recovery points.
5. Coordinate the restoration tasks.
6. Track dependencies and completion status.
7. Collect validation results.
8. Prepare a recovery report.

AI can help prevent steps from being forgotten or performed out of sequence.

However, destructive operations, production cutover, deletion of evidence, changes to backup retention and other high-impact actions should require explicit authorization.

7.6 Post-recovery validation

After restoring a service, AI can compare the recovered environment against known configurations and expected operational patterns.

It can help detect:

• Missing dependencies.
• Unexpected configuration differences.
• Unusual application behaviour.
• Missing records.
• Backup restoration discrepancies.
• Services that have not resumed normal operation.

The responsible application and business owners still need to validate that the restored service is suitable for normal operation.

7.7 Continuous improvement

After each recovery exercise or real incident, AI can help organize the results.

It can identify:

• Which recovery steps consumed the most time.
• Which dependencies caused delays.
• Which backup jobs failed.
• Which integrity checks generated repeated alerts.
• Which RTO targets were missed.
• Which systems require architectural changes.

This provides information for improving the recovery plan rather than waiting for the next disaster to reveal the same weaknesses.

8. The AI Operator Must Also Be Protected

There is one consideration that I would not overlook.

If an organization depends on AI for recovery orchestration, the AI environment itself becomes part of the operational infrastructure.

We should not create a situation where the recovery process depends entirely on an AI service that becomes unavailable during the incident.

The AI Operator needs its own security and availability considerations.

I would consider the following:

Another important point is that AI can make mistakes.

It can misinterpret historical records, generate incorrect recommendations, or overlook unusual situations.

If an AI system receives maliciously manipulated log information, its analysis may also be influenced by that information.

Therefore, AI-generated instructions should not automatically become privileged infrastructure commands.

My preferred arrangement is:

• AI monitors and correlates.
• Automated systems perform predefined checks.
• AI recommends recovery actions.
• Responsible professionals authorize sensitive operations.
• Approved automation executes the recovery procedures.
• AI monitors the results and reports deviations.

This allows us to benefit from automation without making AI the single authority responsible for the recovery environment.

9. Practical Case Study: Healthcare at Home

I would use Healthcare at Home as an example because it demonstrates why RTO, RPO and data integrity must be considered together.

Assume an organization operates a remote patient monitoring service.

The environment includes:

• Patient monitoring devices.
• A home automation gateway.
• A central healthcare application.
• A patient database.
• A healthcare professional dashboard.
• An external communication service.

The organization has approved the following illustrative recovery objectives:

These objectives must be approved by the responsible healthcare and business owners. They are not clinical or regulatory recommendations.

9.1 An integrity incident

At 07:50, unauthorized modifications begin affecting records in the patient database.

The normal backup process continues.

At 08:00, AI-assisted monitoring identifies unusual changes in historical records and reports the findings to the technical team.

The team investigates the event and determines that the affected service cannot be trusted to continue processing information.

The recovery process is activated.

9.2 Identifying a trustworthy recovery point

The backup system contains several versions:

The 08:00 backup may be technically successful, but it was created after unauthorized changes began.

The recovery team therefore investigates the 07:45 backup.

They use database consistency checks, historical audit records, application validation and other available evidence to establish whether it is suitable for recovery.

AI assists with comparing the changes and identifying relevant anomalies.

The technical team validates the selected recovery point before restoration.

For this example, the data loss interval is five minutes, from the last known-good point at 07:45 to the beginning of the unauthorized modifications at 07:50.

The example therefore meets the organization’s 15-minute RPO, assuming the remaining data and transaction history have been properly validated.

9.3 Restoring the service

The organization defines 08:00, when the business service is formally withdrawn from operation, as the start of its RTO measurement in this scenario.

The recovery team follows the approved sequence:

• Isolate the affected environment.
• Preserve investigation records.
• Prepare trusted infrastructure.
• Verify identity and access controls.
• Restore the selected database recovery point.
• Validate the records and application behaviour.
• Reconnect approved services.
• Obtain operational approval.

At 11:30, the application has passed its validation and is approved to resume service.

The measured recovery interval is 3 hours and 30 minutes.

The four-hour RTO has been met.

However, the team should also record the time from the original unauthorized modification at 07:50 to detection at 08:00. This provides a separate measure of detection performance.

It is important to define the RTO clock consistently. Organizations should not manipulate the starting time to make an unsuccessful recovery appear successful.

9.4 Where AI helped

In this example, AI contributed at several points:

The AI did not independently decide that patient records were safe or authorize the healthcare service to resume.

That responsibility remained with the appropriate professionals.

9.5 Lessons from the case

This example highlights several important points.

First, backup frequency alone cannot guarantee a successful RPO.

Second, a successful backup does not necessarily contain trustworthy information.

Third, detecting corruption early can help preserve an earlier recovery point.

Fourth, recovery requires more than restoring a database. The infrastructure, identities, applications and supporting services must also be trusted.

Finally, AI can help coordinate these activities and reduce the time required to identify and investigate problems.

10. Measuring Actual RTO and RPO Performance

A recovery plan should not be evaluated only by whether the backup jobs completed.

We need measurable results from actual restoration exercises.

I would introduce a recovery performance report containing the following:

We should compare actual results with approved objectives.

For example:

These figures are illustrative.

A successful test should also confirm that the restored environment is secure and that the business owner accepts the recovery.

AI Operator’s role

AI can automatically collect timestamps from monitoring systems, backup records, restoration logs and service health checks.

It can prepare performance reports and identify which recovery activities caused delays.

It can also compare results across multiple exercises to help establish whether recovery capability is improving.

However, the accuracy of the measurements depends on consistent event definitions and reliable timestamps.

11. Recovery Testing: The Only Way to Validate the Plan

A backup that has never been restored is an unverified recovery assumption.

We need to test whether the organization can actually recover its infrastructure and data within the approved objectives.

I would consider several types of testing:

Backup restoration test

Restore selected backup files and verify that they are readable and complete.

Database recovery test

Restore a database into an isolated environment and verify consistency, transaction history and application-level integrity.

Infrastructure rebuilding test

Use approved IaC templates to rebuild a test environment and confirm that the required services work correctly.

Dependency recovery test

Verify that authentication, DNS, network, storage and supporting services can be restored in the correct order.

Cyber recovery test

Simulate a compromised environment and verify that recovery can take place without reintroducing corrupted data or insecure configurations.

Full recovery exercise

Test the complete recovery process, including communication, business approval, infrastructure restoration, data validation and return to service.

NIST SP 800-184 emphasizes periodic validation and continuous improvement of recovery capabilities.

AI Operator’s role

AI can help prepare scenarios, coordinate test activities, collect results and compare actual performance against the documented objectives.

It can also identify procedures that were skipped or performed in an unexpected order.

However, AI should not be allowed to report a successful recovery merely because all automated tasks returned a successful status.

The final result must reflect actual service availability and data integrity.

12. Common DRP Mistakes Worth Reconsidering

I would finish the technical discussion with several assumptions that organizations should revisit.

Conclusion

I think we need to reconsider how we define and evaluate Disaster Recovery Planning.

Having multiple backup copies is important, but it does not automatically guarantee that we can recover our services or information.

We need to understand how much downtime the organization can tolerate, how much data it can afford to lose, and whether the recovery environment is sufficiently independent from production.

RTO and RPO should remain the foundation of the recovery strategy.

They determine the recovery capability that an organization needs to establish, the infrastructure it must prepare, and the results it needs to validate.

However, we should also recognize that modern recovery is becoming more complicated.

Production environments are interconnected. Data changes continuously. Backups can inherit corrupted information. Replication can reproduce unwanted changes. Recovery environments can share the same identity and administrative boundaries as production.

This is where I see an important role for AI.

AI should not become the backup platform or replace the recovery team. Instead, it should act as an operational orchestrator that helps monitor data, correlate events, identify anomalies, coordinate recovery activities and measure actual performance.

It can help us understand what is happening across the infrastructure before, during and after an incident.

It can also help us identify whether our recovery objectives remain achievable as systems and dependencies change.

But the final decision must still be supported by trustworthy technical evidence and responsible human authorization.

Ultimately, I would describe successful disaster recovery as three connected achievements:

1. Restoring business services within the approved RTO.
2. Recovering data within the approved RPO.
3. Ensuring that the restored infrastructure and information can be trusted.

A backup is not necessarily a recovery point. A recovered system is not necessarily a recovered business service.

The real objective of DRP is not simply to restore what we had. It is to restore the services and information that we can trust.

References and Resources

• NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems
• NIST SP 800-184: Guide for Cybersecurity Event Recovery
• NIST SP 1800-11: Data Integrity, Recovering from Ransomware and Other Destructive Events
• NIST SP 1800-25: Identifying and Protecting Assets Against Ransomware
• NIST AI Risk Management Framework
• Canadian Centre for Cyber Security: Ransomware Playbook
• Canadian Centre for Cyber Security: Tips for Backing Up Your Information