What is Business Resilience in CISA Domain 4

A Practical, Audit-Focused Revision Guide for CISA Aspirants

CISA Domain 4 · Business Resilience · Updated September 2026

For a CISA auditor, the question is not simply: “Does the organization have a Business Continuity Plan?” The more important questions are:

• Has the organization identified what is actually critical?
• Has it assessed the impact of disruption?
• Are recovery objectives based on business requirements?
• Are backup and recovery mechanisms adequate?
• Are alternative processing arrangements available where required?
• Has the BCP/DRP actually been tested?
• Can the organization demonstrate that it can recover within its defined objectives?
• Are identified weaknesses corrected and followed up?

Business Impact Analysis (BIA)

What Is a BIA?

A Business Impact Analysis (BIA) identifies the organization’s critical business processes and determines the consequences of their disruption. The BIA answers questions such as:

• Which business processes are critical?
• What happens if a process becomes unavailable?
• How long can the organization tolerate the disruption?
• What systems, applications, data, people and facilities are required to operate the process?
• What is the financial, operational, legal, regulatory or reputational impact?
• What recovery priority should be assigned?

The BIA is therefore a business-oriented analysis, rather than simply a technical analysis.

BIA and Risk Assessment Are Different

These concepts are frequently confused.

Classification of Business Operations – Business Resilience in CISA Domain 4

Not every business process has the same recovery priority. A BIA normally classifies processes according to their criticality. For example:

The exact classification terminology varies between organizations.

Dependencies in a BIA

A business process rarely operates independently. For example, an online sales process may depend on:

Customer → Website → Application → Database → Network → Cloud provider → Internet → Payment gateway → Staff

If one critical dependency is ignored, the recovery plan may fail even though the primary application has been restored. The BIA should therefore consider dependencies such as:

applications databases network infrastructure telecommunications cloud services third-party providers facilities power personnel suppliers data authentication services

Recovery Objectives: RPO, RTO and MTTR

Several terms are especially important for the CISA examination.

Recovery Point Objective (RPO)

RPO defines the maximum acceptable amount of data loss measured in time. For example, RPO = 4 hours means that, following a disruption, the organization is prepared to potentially lose up to four hours of data. RPO therefore influences:

backup frequency replication frequency synchronization mechanisms recovery architecture

Recovery Time Objective (RTO)

RTO defines the target time within which a business process or system should be restored after disruption. For example, RTO = 2 hours means the organization has established a requirement to restore the service within two hours.

Mean Time to Repair (MTTR)

MTTR is the average time required to repair or restore a failed system or component. It is primarily an operational/performance measure. RTO is a business recovery requirement, whereas MTTR is generally a performance/operational measure.

System and Operational Resilience

Resilience is broader than disaster recovery. Resilience is the ability of systems and operations to continue delivering required services despite disruption or failure. A resilient environment attempts to prevent or minimize interruption, rather than simply recovering after failure.

Resilience vs Recovery

A resilient system may automatically fail over to another server when one server fails. A DR process may be required when an entire data center is unavailable.

Recovery Strategies and Alternatives

The recovery strategy should be consistent with:

business criticality RTO RPO cost risk regulatory requirements technical dependencies

Common recovery alternatives include:

Reciprocal Agreement

Two organizations may agree to provide facilities/resources to each other during a disaster. Such arrangements can introduce concerns about:

capacity compatibility security availability contractual enforceability simultaneous disasters

Cloud-Based Recovery

Cloud infrastructure may be used to provide replicated systems, backup storage, virtual infrastructure, disaster recovery environments and geographically distributed recovery capabilities.

The auditor should not assume that “cloud” automatically means resilient. The organization still needs to assess:

provider availability geographic redundancy contractual commitments security data recovery RTO/RPO achievement provider dependency

Data Backup, Storage and Restoration

Backups are one of the fundamental components of recoverability. A backup strategy should address:

• what is backed up, when, and how frequently;
• where it is stored and how long it is retained;
• how it is protected and who can access it;
• how restoration is performed and how restoration is tested.

The existence of backups alone does not prove recoverability. The organization must demonstrate that backups can actually be restored.

Backup Types: Full vs Incremental vs Differential

Backup Schemes and Rotation

Backup rotation determines how backup media or backup sets are reused and retained. A rotation strategy may include daily backups, weekly full backups, monthly archival backups, offsite copies and long-term retention. The purpose is to ensure that:

• historical recovery points are available;
• media is not unnecessarily reused;
• backups survive local disasters;
• retention requirements are satisfied.

The auditor should evaluate whether the rotation schedule is consistent with RPO, retention requirements, legal/regulatory requirements, business needs and available storage.

Backup Security

Backups contain valuable organizational information and must be protected like production data.

Offsite Backup

Keeping backup copies at the same location as production systems creates a major risk. For example: fire destroys the primary data center and all backup media stored inside it. Therefore, critical backups should generally have geographically separate copies. The auditor should examine:

physical location environmental protection access controls transportation controls encryption media inventory chain of custody retention restoration capability

Cloud Backup

Cloud backup involves storing backup data with a cloud service provider. Potential benefits include geographic separation, scalable storage, automation, reduced infrastructure requirements and potentially faster deployment. However, the auditor should consider:

provider availability data location encryption access management contractual requirements retention recovery costs bandwidth limitations restoration time provider lock-in security of backup credentials testing of restoration

The auditor should verify that the cloud backup arrangement can actually satisfy the organization’s RTO and RPO.

Backup Devices and Media

Backup technologies may include magnetic tape, disk-based backup, removable media, network-attached storage, cloud storage, object storage and replication to another data center.

The technology itself is less important than whether it satisfies business requirements. The auditor should consider reliability, capacity, performance, security, compatibility, retention, recoverability and environmental protection. For removable media, physical security and media degradation are particularly important.

Business Continuity Planning (BCP)

A Business Continuity Plan (BCP) defines how an organization will continue or resume critical business activities when a disruptive event occurs. BCP is broader than IT disaster recovery.

BCP vs DRP

A DRP should support the BCP rather than operate independently.

Typical BCP Process

A logical BCP lifecycle can be represented as:

Business requirements → Risk assessment → BIA → Recovery objectives → Recovery strategies → Plan development → Testing → Maintenance → Continuous improvement

1. Establish planning scope. Determine organizational scope, critical functions, stakeholders, responsibilities and assumptions.
2. Perform risk assessment. Identify threats and vulnerabilities that could disrupt operations.
3. Perform BIA. Determine critical processes, impact, dependencies, recovery priorities, RTO and RPO.
4. Develop recovery strategies. Select appropriate alternatives based on business requirements.
5. Develop the BCP. Document roles, responsibilities, communication procedures, recovery procedures, escalation, emergency contacts, alternate facilities and supplier arrangements.
6. Test the plan. Testing determines whether the documented plan actually works.
7. Maintain and update. Plans must be updated when there are changes to systems, applications, business processes, personnel, suppliers, facilities, regulations or organizational structure.

A BCP policy establishes management’s commitment and direction for business continuity. The policy should be approved by appropriate management.

Crisis Communication

A disaster may create reputational damage even when systems are eventually restored. BCP should therefore consider:

crisis communication customer notification media communication regulatory notification stakeholder communication designated spokespersons escalation procedures

The organization should avoid having different departments provide contradictory information during a crisis.

BCP Testing

Testing is essential because documentation alone does not demonstrate preparedness. A BCP test can identify outdated contact information, missing responsibilities, unrealistic recovery times, unavailable resources, communication problems, dependency failures and inadequate backup arrangements.

BCP Testing Methods

Good BCP Practices

management sponsorship clearly defined responsibilities current contact information documented critical processes BIA-driven priorities defined RTO/RPO documented dependencies alternate processing arrangements tested communication procedures tested backup restoration periodic testing lessons learned plan maintenance staff awareness and training integration with incident management

BCP should not be treated as a one-time project. It is a continuous lifecycle.

Auditing Business Continuity

A CISA auditor should assess whether business continuity controls are properly designed, implemented, maintained, tested, monitored and aligned with business requirements. The audit should start with the organization’s business requirements rather than simply reviewing the BCP document.

Key Audit Questions

Interviews and Corroborating Evidence

Interviews are an important audit evidence-gathering technique. The auditor should interview representatives from relevant areas, such as business process owners, IT management, infrastructure teams, information security, facilities, HR, communications, procurement, legal/compliance and third-party providers.

However, interview responses should be corroborated with evidence. For example, if management says “Backups are tested every month,” the auditor should seek supporting evidence such as:

backup logs restoration test reports test results incident records management review corrective action records

Reviewing Alternative Processing Contracts

Organizations may rely on third parties for alternate processing facilities, cloud recovery, backup storage, telecommunications, managed infrastructure and disaster recovery services. The auditor should review contracts and service agreements to determine whether they address:

availability recovery requirements RTO/RPO security confidentiality data location responsibilities testing service levels termination audit rights contingency arrangements

The existence of a contract does not prove that the service will meet recovery requirements. Testing and evidence are still important.

Insurance Coverage

Organizations may purchase insurance related to business interruption, property damage or cyber incidents. The auditor may review whether coverage is consistent with identified risks. Insurance does not replace business continuity controls: it primarily transfers some financial risk; it does not restore systems or operations.

Disaster Recovery Plan (DRP)

A Disaster Recovery Plan provides procedures for recovering IT systems, infrastructure, applications and data after a disruptive event. A DRP may address:

disaster declaration recovery team activation communication infrastructure recovery network recovery application recovery database recovery data restoration system validation return to normal operations

The DRP should be aligned with the BIA and BCP.

DRP Recovery Priorities

Recovery should normally follow business priorities established through the BIA. For example:

Critical application → Supporting database → Authentication → Network → Dependent services

The exact sequence depends on system dependencies. A common audit issue is restoring an application before restoring one of its critical dependencies. Therefore, recovery plans should document technical dependencies and recovery sequencing.

Invoking the Disaster Recovery Plan

The DRP should define:

• who has authority to declare a disaster;
• what conditions trigger invocation;
• who activates recovery teams;
• communication procedures and escalation;
• alternate facility activation;
• supplier and management notification;
• regulatory notification where applicable.

The decision to invoke a DRP should not depend on an undefined “common sense” decision. Clearly defined authority and criteria reduce confusion during a crisis.

Disaster Recovery Testing

DRP testing should verify whether systems and infrastructure can actually be recovered within defined requirements. Testing should produce evidence such as test objectives, scenarios, participants, results, deviations, issues, lessons learned and corrective actions.

Recovery Testing: What Should the Auditor Look For?

The auditor should identify the discrepancy rather than simply recording “DR test completed successfully.” The important question is: Did the organization demonstrate that it can meet its defined recovery requirement?

End-to-End Business Resilience Model

For CISA examination purposes, it is useful to understand the relationship between all the concepts:

The auditor should be able to follow this chain. If the BIA says a process has an RTO of two hours, the recovery strategy, technology, backup arrangements and DR procedures should collectively support that requirement.

12 High-Value CISA Exam Reminders

1. A BIA is business-driven. Do not confuse it with a technical disaster recovery assessment.
2. RPO concerns data loss. RPO answers: How much data can we afford to lose?
3. RTO concerns recovery time. RTO answers: How quickly must the service be restored?
4. MTTR is not RTO. MTTR describes actual/operational repair performance; RTO is a business recovery requirement.
5. Incremental and differential backups are different. Incremental = changes since the previous backup. Differential = changes since the last full backup.
6. Backup does not equal recoverability. Restoration must be tested.
7. BCP is broader than DRP. BCP focuses on continuing business operations; DRP primarily addresses technology recovery.
8. Resilience is broader than disaster recovery. Resilience seeks to maintain service despite failures; DR focuses on recovery when disruption occurs.
9. A plan that is not tested provides limited assurance.
10. Recovery requirements should drive recovery solutions. Do not select a recovery technology first and then attempt to justify it.
11. The auditor should verify evidence, not simply accept management statements.
12. A successful test is not necessarily an effective test. The important question is whether the test demonstrated that defined business requirements, particularly RTO/RPO, can actually be achieved.

The Big Picture

The central idea behind Domain 4 is not disaster recovery technology. It is the relationship between business requirements, risk, recovery objectives, controls and evidence.

This mindset helps connect BIA, resilience, backups, BCP and DRP into one coherent audit perspective. The strongest CISA answers generally follow the same logic:

Business requirement → Risk/impact → Recovery objective → Appropriate control → Testing → Evidence → Continuous improvement