This guide explains how to deploy and configure the IT Disaster Recovery (DR) solution in Ardoq. It should be read alongside IT Disaster Recovery: Purpose, Scope and Rationale and IT Disaster Recovery: Metamodel Specification.

The DR solution connects your application inventory to recovery plans, impact assessments, and recovery processes in a single, queryable model. The goal is to replace fragmented DR documentation with a live repository that answers the questions regulators, boards, and incident teams need to ask without manual reconciliation.

The solution supports regulatory obligations under DORA Articles 11 and 12, the CBI Cross-Industry Guidance on Operational Resilience (July 2025), APRA CPS 230 (Australia), and BCBS Operational Resilience Principles (2021).

This solution shares the Applications workspace with several other Ardoq solutions. If you have already deployed any of the following, your application inventory is already in place and can be reused.

If none of these solutions are deployed, the DR solution will create the Applications workspace for you when you add it to your organization.

Select IT Disaster Recovery from the Solutions catalogue on the Ardoq Solutions page and click Add solution materials. This deploys the following workspaces to your organization.

Your application inventory is the foundation of the DR solution. Every DR Plan and DR Impact Assessment references an Application component.

If you already have an application inventory in Ardoq, skip to Step 2. The DR solution works with your existing Application components.

If you are starting from scratch, populate your application data first. The quickest approach is to import from your existing sources:

You do not need a complete inventory to start generating value. Begin with your mission-critical and business-critical applications. These are the applications where a DR gap carries the most risk and where regulators will look first.

Tip: Use an Application List Survey and Broadcasts to ask application owners to confirm or fill in missing fields across the portfolio.

A DR Plan is the technical recovery record for a single application. It holds the agreed RTO and RPO, DR tier, test history, and governance status.

One DR Plan per application. The relationship is one-to-one. Create DR Plans in the Disaster Recovery workspace.

Naming convention: <Application Name> DR-PL <Year> Example: Payments Gateway DR-PL 2026

Connect the DR Plan to its Application using the Has Subject reference. This is the primary relationship in the metamodel. Applications with no inbound Has Subject reference have no DR plan. This is your first coverage gap view.

Tip: Use a Table View across the Applications workspace filtered by inbound Has Subject to see coverage at a glance.

A DR Impact Assessment is a structured review of how ready an application is for recovery. It captures the maximum tolerable period of disruption (MTPD), the business-approved impact tolerance, and the service-level RPO.

Create DR Impact Assessments in the DR Assessments workspace.

Naming convention: <Application Name> DR-IA <Year> Example: Payments Gateway DR-IA 2026

Connect the DR Impact Assessment to its Application using the Has Subject reference.

The Service Gap Status field is calculated by comparing the DR Plan RTO and RPO against the Impact Tolerance and Service RPO on the assessment. The three states are:

This calculated field is the primary governance signal for DR readiness reporting and board submissions.

Note: Under CBI Cross-Industry Guidance on Operational Resilience (Guidelines 1, 5, and 15), impact tolerances must be reviewed and approved at least annually or following a disruption. The DR Assessment record in Ardoq provides the structured evidence for this review cycle.

Dependency mapping answers the blast radius question: if this application fails, what else fails with it?

Two types of dependency are modelled in this solution.

Link each application to the infrastructure platform, cloud service, or SaaS it runs on. This extends blast radius analysis from the application layer to the underlying technology. Create Technology Service components in the Applications workspace using the standard Technology component type.

Link business units to the applications they depend on. This supports criticality classification and makes impact visible to business stakeholders, not just IT teams.

Tip: Use the Dependency Map or Block Diagram views to visualize the dependency chain for a specific application and trace cascading failure paths.

Ownership is structural in this solution. Unassigned plans and assessments surface as governance gaps automatically.

Assign owners using the Owns reference:

Use a Survey to ask application owners to confirm their DR Plan and Assessment ownership. This is especially useful for large portfolios where ownership has not been formally recorded.

Broadcasts automate governance reminders so DR Plans and Assessments do not go stale. Two Broadcasts are recommended for this solution.

Notifies DR Plan owners when the Next Review Date on their plan is approaching. This keeps plans current without relying on calendar reminders outside the repository.

Notifies Assessment owners when annual review obligations are approaching. Relevant for regulatory frameworks that require annual tolerance reviews.

To configure a Broadcast, open the Broadcast builder, edit the message text, and replace the placeholder survey URL with the URL for the relevant survey in your organization. Launch the Broadcast to activate the automated process.

DR Recovery Processes are optional. They represent the step-by-step operational procedures executed during a DR event.

If your organization already has business processes in Ardoq via the Business Process Management solution, recovery procedures can be added to the same Process workspace and linked to DR Plans. This keeps recovery procedures visible alongside the business activities they restore.

Populate the DR Plan URL field on the DR Plan component instead. This acts as a document reference, pointing to the runbook or recovery procedure held in your document management system.

Naming convention: <Application Name> DR-RP Example: Payments Gateway DR-RP

Connect the Recovery Process to its DR Plan using the Is Realised By reference from the DR Plan to the DR Recovery Process.