Information Systems Operations and Business Resilience (ISACA CISA)

Table of Contents

• Domain Overview
• Module 1: Foundations of Business Resilience Auditing
  • Defining Business Resilience and System Resiliency
  • The Business Continuity Management System
  • Standards and Frameworks for Business Continuity
  • Business Continuity Program Management as a Project
  • Common Causes of BCP Program Failure
• Module 2: Business Impact Analysis and Recovery Requirements
  • Purpose and Scope of the Business Impact Analysis
  • BIA versus Risk Assessment
  • Maximum Tolerable Downtime and the Impact-Over-Time Curve
  • Identifying Critical Business Functions and Resource Requirements
  • Recovery Time Objective, Service Delivery Objective, and Recovery Point Objective
  • Setting Recovery Priorities
• Module 3: Data Backup, Storage, and Restoration
  • Protecting Confidentiality, Integrity, and Availability During a Crisis
  • Backup Location Strategies: On-Site, Near-Site, and Off-Site
  • Full, Differential, and Incremental Backups
  • Backup Media, Technologies, and Testing
• Module 4: System Recovery Site Strategies
  • Hot Sites: Multiple Processing Centers, Mirrored Sites, and Commercial Hot Sites
  • Cloud-Based Recovery
  • Mobile Recovery Sites
  • Warm Sites and Cold Sites
  • Choosing the Right Recovery Site
• Module 5: Auditing Business Continuity and Disaster Recovery Plans
  • Writing Effective BCP/DRP Documentation
  • Roles, Responsibilities, and Cross-Training
  • Elevated Risk During a Crisis: Fraud, Errors, and Reduced Controls
  • Crisis Communication and the Emergency Operations Center
  • Recovery versus Restoration
• Self-Assessment Questions
• Summary

Domain Overview

This course covers the second half of the Information Systems Operations and Business Resilience domain of the CISA exam content outline — the business resilience section. Combined with the companion course on information systems operations, this domain accounts for approximately 26% of the total CISA examination.

As auditors, we are responsible for assessing whether an organization’s preparations for adverse events are legitimate, adequate, and realistic. Key questions we must be able to answer include:

• Is the organization prepared to prevent, detect, and respond to incidents effectively so that business operations can continue, or be resumed, even in the midst of chaos or crisis?
• Do the auditors have the skills necessary to assess business continuity and disaster recovery plans?
• Is IT both resilient and prepared to prioritize and support continued business operations?

The domain is organized into two major auditing skill areas covered in this course:

1. Auditing business resilience — business impact analysis, system resiliency, business continuity planning, and disaster recovery planning.
2. Auditing protection of information and information technology — ensuring confidentiality, integrity, and especially availability of data and systems even when information systems are disabled or compromised during a crisis.

Module 1: Foundations of Business Resilience Auditing

Defining Business Resilience and System Resiliency

Business resilience is the ability of an organization to continue operations even during adverse circumstances. The terminology used to describe this discipline has evolved considerably over time:

System resiliency means building IT systems that support critical business operations to be robust:

• Every system should be built with the expectation that it will be attacked. Robust design aims to prevent that attack from causing an outage.
• Systems should be resistant to failure — resistance must be engineered into every layer: networks, hardware, and databases.
• Systems should be fail-secure, not merely fail-soft:
  • Fail-secure: even when a system fails, it fails in a way that maintains security.
  • Fail-soft (fail-open): the system continues operating through the failure, but potentially in an insecure manner.
• Power resilience matters as well — systems should not be dependent on the availability of commercial power. This is why organizations build Tier 3 and Tier 4 data centers, as defined by the Uptime Institute, where even a momentary loss of power should not cause a data center outage.

flowchart TD
    A[System Resiliency Goals] --> B[Robust Design<br/>Assume attacks will occur]
    A --> C[Resistance to Failure<br/>Networks, hardware, databases]
    A --> D[Fail-Secure vs Fail-Soft<br/>Fail safely, not just fail open]
    A --> E[Power Resilience<br/>Tier 3/Tier 4 data centers]

The Business Continuity Management System

The overall discipline that coordinates preparation for and response to disruptive events is the business continuity management system (BCMS), which is composed of three distinct disciplines:

flowchart LR
    BCMS[Business Continuity<br/>Management System] --> IR[Incident Response]
    BCMS --> BCP[Business Continuity<br/>Planning]
    BCMS --> DRP[Disaster Recovery<br/>Planning]

    IR --> IR1[Life safety]
    IR --> IR2[Containment of incident]
    IR --> IR3[Documentation]
    IR --> IR4[Return to normal]

    BCP --> BCP1[Business impact analysis]
    BCP --> BCP2[Identify critical business functions]
    BCP --> BCP3[Recovery time objective / RTO]
    BCP --> BCP4[Recovery point objective / RPO]
    BCP --> BCP5[Identify recovery resource requirements]

    DRP --> DRP1[Relocation of IT services]
    DRP --> DRP2[Recovery of IT systems<br/>at an alternate location]

Most incidents are handled through normal incident response without escalation. However, when an incident is likely to cause an outage of unacceptable duration, the organization must escalate into business continuity planning to continue critical business services.

Disaster recovery planning (DRP) has a specific, narrower historical meaning that CISA candidates must keep in mind:

• DRP was first introduced in the 1970s in the context of recovering a lost mainframe. It has traditionally referred specifically to recovery of IT services.
• Over the years, the term has become confused with emergency response planning (e.g., “what do I do in case of an earthquake?”).
• On the CISA exam, watch carefully for which meaning is intended: are they referring to emergency/life-safety response, or to the recovery of IT?

Standards and Frameworks for Business Continuity

Several standards and organizations have published guidance on business continuity and disaster recovery:

Auditors can lean heavily on these standards as benchmarks for measuring the competence and completeness of an organization’s business continuity management system.

Business Continuity Program Management as a Project

Most business continuity programs fail because they get stuck in endless discussion without ever producing a workable plan for continuity. For that reason, business continuity planning should be managed as a project, following a defined sequence of steps:

flowchart LR
    A[Project Initiation<br/>Charter + senior management support] --> B[Business Impact<br/>Analysis]
    B --> C[Select Recovery<br/>Strategy]
    C --> D[Write Business<br/>Continuity Plans]
    D --> E[Implement Plans]
    E --> F[Test Plans]
    F --> G[Maintain Plans]
    G -.review/update.-> B

Key considerations at each stage:

• Project initiation requires a management charter granting the team authority to learn how the business works and to develop a recovery plan. Without visible senior management support, department managers may resist providing information or assume they can independently look after their own recovery — undermining the entire program.
• Department managers will frequently (and predictably) claim their own department is the most critical, or may withhold information out of fear that being deemed “not important” could put their jobs at risk. Clear, early communication about the purpose and intent of the exercise is essential.
• Senior management must set actual recovery priorities. Some products or services may deliberately not be recovered at all (end-of-life offerings), while others considered less visible to local managers may be prioritized higher than expected.
• After project initiation, the process proceeds through business impact analysis, recovery strategy selection, writing (often multiple) business continuity plans for different types of incidents, implementation, testing, and ongoing maintenance.

Common Causes of BCP Program Failure

Real-world experience surfaces recurring failure patterns that auditors should specifically look for:

• Undeliverable plans — endless discussion without ever producing a workable, executable plan.
• Plans written for peace, executed in chaos — a BCP is developed during a time of relative calm but must be executed during a time of chaos; if it is not realistic and action-oriented, it will not hold up.
• Lack of support from business units — “everybody’s too busy right now” is a common excuse that undermines both plan development and testing.
• Plans that are out of date — staff changes, IT systems change, and technology changes mean that a BCP/DRP can become stale almost as soon as it is finalized. Ongoing maintenance is a continual challenge.
• Poor leadership — a BCP/DRP program needs to be led by someone with genuine crisis-leadership skills, not merely someone skilled at administrative paperwork.

Case example — poor leadership choice: During an actual crisis, the primary business continuity leader was on vacation, so the team turned to her deputy. The deputy was excellent at maintaining accurate, thorough paperwork but was the wrong personality to lead during a crisis — his response to being told about the emerging problem was simply “keep me informed,” when in fact he was supposed to be the decision-making leader. Because the incident originated in IT, the director of IT then assigned another manager — a well-liked, generally excellent manager — to lead the recovery. Several weeks into the crisis, that manager suffered a full breakdown, unable to handle the constant indecision and pressure; he was simply not suited to that role. When the original leader returned from vacation, her judgment in appointing an unsuitable deputy (chosen mainly because “he really wanted it” and held a certification) had to be seriously questioned. The lesson for auditors: verify that BCP/DRP leadership roles, including designated deputies, are assigned based on demonstrated crisis-leadership capability — not paperwork competence or personal interest alone.

As auditors, our core assessment question is: will the business continuity plan protect and sustain business operations even in a crisis? We measure this against recognized standards (ISO 22301, DRII, BCI guidance) and evaluate the effectiveness of both incident response and business continuity plans.

Module 2: Business Impact Analysis and Recovery Requirements

Purpose and Scope of the Business Impact Analysis

The business impact analysis (BIA) is arguably the single most important step in the entire business continuity process — the “heartbeat” of the BCP effort. Through the BIA we determine:

• The critical business functions/processes that must be kept operating.
• The dependencies those processes have (a process cannot be recovered without also recovering the underlying infrastructure it depends on).
• The required resources needed to facilitate recovery of each process.
• Recovery timelines and priorities necessary to satisfy senior management’s expectations.

Critically, BIA is a business impact analysis — not an IT impact analysis. It measures how a crisis would affect the organization’s ability to meet its business mission and business goals, not merely its technology.

Case example — proportional recovery priority: When asked to update a stale business continuity plan for an internal audit department, the task was completed within days rather than the expected weeks. The reasoning: internal audit is not a critical business function — in the eyes of most of the company, operations would arguably run fine without it in the short term. The only reason a plan existed at all was a regulatory requirement tied to being listed on a stock exchange. With roughly 30 days of tolerance for recovery, the appropriate recovery strategy was simply outsourcing — engaging an external accounting firm temporarily. Contrast this with a hospital’s life-support equipment, where impact is measured in minutes, not weeks. This illustrates that BIA outcomes must be proportional to actual business criticality, not applied uniformly across the organization.

BIA versus Risk Assessment

BIA and risk assessment are related but distinct:

Maximum Tolerable Downtime and the Impact-Over-Time Curve

BIA measures the amount of business impact accumulated over the duration of an outage. Conceptually:

flowchart LR
    subgraph Timeline["Impact Over Time After a Crisis"]
    direction LR
    N[Normal Operations] --> O[Outage Begins<br/>Business drops to zero service]
    O --> RTO[Recovery Time Objective<br/>Acceptable service restored]
    RTO --> MTD[Maximum Tolerable Downtime<br/>Business fails if not recovered]
    end

Every business — and every department within a business — has a different impact curve; it can rise slowly and linearly or exponentially depending on the nature of the operation.

The point at which accumulated impact becomes so severe that the business itself fails is called the maximum tolerable downtime (MTD). This term has been renamed multiple times over the years but always refers to the same concept:

Impact can be measured both quantitatively (financial loss) and qualitatively (e.g., reputational damage — “what good is a 10-year warranty from a company that’s going out of business?”).

Identifying Critical Business Functions and Resource Requirements

Critical business functions/processes are the things that define the organization to its customers — the elements customers actually see and depend on. These must be recovered first. For each critical process, the BIA must identify five categories of resource requirements:

(Note: some formulations list six items by splitting workspace and supply chain separately from the traditional “five” — the key exam takeaway is that all of these categories must be captured.)

Dependencies can be hidden and multi-layered. A visible service (e.g., buying gas at a filling station) depends on an entire chain of dependencies (transportation of fuel, refining, extraction) — a disruption anywhere in that chain can halt the visible service. Auditors must probe for critical supporting processes, including dependencies on cloud services and networks.

Customer interface priorities also evolve over time, and BIA priorities must reflect the current primary channel of customer interaction:

flowchart LR
    A["1990s:<br/>Phone System"] --> B["Later:<br/>Email"] --> C["Later still:<br/>Text Messaging / Website"] --> D["Today:<br/>Social Media"]

A process cannot be recovered without recovering its supporting infrastructure — recovering a call center, for example, requires also recovering the systems holding customer profile data.

Recovery Time Objective, Service Delivery Objective, and Recovery Point Objective

For each critical business process, we must define the point at which we want to recover — not necessarily to full normal operations, but to an acceptable level of service.

• Cost of recovery is generally inversely proportional to speed of recovery: recovering instantly requires redundant sites and systems (expensive); recovering to an empty building takes longer but costs less to maintain in the interim — while the impact of the outage rises the longer recovery takes.
• The point where these two curves intersect gives a reasonable estimate for the recovery time objective (RTO) — the desired time by which at least an acceptable level of service must be restored.
• As a general (not absolute) rule of thumb, RTO is often roughly half of the MTD.
• The level of service restored at the RTO — not full normal operations — is called the service delivery objective (SDO), usually expressed as a percentage of normal operational capability.
• Data recovery introduces another constraint: the recovery point objective (RPO) defines the point to which data must be recovered so that data loss remains acceptable. RPO is driven by backup frequency — if backups run every 8 hours and failure occurs 6 hours after the last backup, up to 6 hours of data may be lost. Whether that is acceptable depends on the value and volatility of the data.

Memory aid used throughout the course: write the word “data” in front of RPO — Recovery Point Objective is about data recovery, specifically.

Setting Recovery Priorities

Recovery priorities must be:

• Feasible and suitable, taking into account legal/regulatory requirements mandating recovery of certain services within specific time periods.
• Set with senior management support before a crisis occurs — setting priorities during an actual crisis (e.g., deciding which of only 10 available laptops goes to which department) is far more contentious and error-prone than deciding in advance.
• Based on both quantitative (financial cost of recovery and of the outage) and qualitative (reputational) factors.

Senior executives must play a key leadership role to ensure recovery activities actually follow the pre-agreed plan rather than being renegotiated mid-crisis.

As auditors, reviewing the BIA requires a thorough understanding of how the business actually works, identification of all business dependencies (including external dependencies such as cloud providers and the supply chain), and verification that any cloud service providers relied upon also maintain their own adequate business continuity and disaster recovery plans.

Module 3: Data Backup, Storage, and Restoration

Protecting Confidentiality, Integrity, and Availability During a Crisis

Information must remain protected even when things go wrong — including confidentiality, integrity, and (especially in the business resilience context) availability of information and information systems. A certain amount of data loss should be expected even with an excellent recovery capability (e.g., in-flight transactions at the moment of the crisis may be lost even with multiple processing centers) — the goal is to keep that loss within the acceptable bound defined by the RPO.

Backup Location Strategies: On-Site, Near-Site, and Off-Site

Historical guidance on off-site distance has evolved considerably and is a useful illustration of how “rule of thumb” distances can be misleading:

The 200-mile guidance proved impractical for many countries (at that distance, an organization might cross into a different language/jurisdiction). The modern, more useful principle is: the off-site location should be far enough away that it would not be affected by the same disaster — the appropriate distance depends on the specific hazard:

• A tornado has a narrow, largely unidirectional damage path — being just 10 miles/16 kilometers off that path (perpendicular to its direction of travel) may be sufficient.
• A hurricane has a much wider area of effect — at least 50 miles/80 kilometers of separation is more appropriate.

The backup frequency is driven directly by the RPO: if the RPO says “do not lose more than 8 hours of data,” backups must run at least every 8 hours.

Backup and replication technologies commonly referenced:

Caution on cloud recovery: the cloud is a cost-effective storage option, but it is not always ideal for disaster recovery, because uploading or downloading very large volumes of data (e.g., a terabyte) can take days — far too slow if the RTO requires systems back online within hours. If RTO is short (e.g., 4 hours), an on-site solution or mirroring is far more appropriate than reliance on vaulting or cloud-only recovery.

Full, Differential, and Incremental Backups

Backing up everything constantly is costly in time, storage, network performance, and CPU load on production systems — most organizations use a mixed strategy:

flowchart TB
    subgraph Differential["Differential Backup Strategy"]
    direction LR
    Sat1[Saturday: Full Backup] --> Mon1[Monday: Changes since Saturday]
    Mon1 --> Tue1[Tuesday: Changes since Saturday]
    Tue1 --> Wed1[Wednesday: Changes since Saturday]
    end
    subgraph Incremental["Incremental Backup Strategy"]
    direction LR
    Sat2[Saturday: Full Backup] --> Mon2[Monday: Changes since Saturday]
    Mon2 --> Tue2[Tuesday: Changes since Monday]
    Tue2 --> Wed2[Wednesday: Changes since Tuesday]
    end

Note that on the first day after a full backup (Monday in the example), differential and incremental backups are identical — they diverge starting the second day.

Backup Media, Technologies, and Testing

Numerous real-world incidents involve organizations discovering — only at the moment of a real crisis — that their backups were corrupted or never wrote properly. As part of auditing operations, verify:

• Are backups actually being tested? This includes periodically retrieving an off-site backup copy and confirming it can be read/restored, not merely confirming the backup job “completed.”
• Is the backup write process itself validated? Transportation, storage, and even the backup device itself can silently fail.

Backup storage location considerations:

• Must be far enough away to avoid the same disaster (see distance discussion above).
• Must be accessible when needed.

Case example — inaccessible backup vault: An organization stored backups in a bank vault in a small mountain town with few other secure storage options. After an earthquake, the team called the bank to retrieve the backups and begin recovery — only to learn the vault had a time-lock that would not open until 8:30 the following morning. The backups were secure, but not accessible when needed, converting a manageable inconvenience into a prolonged crisis. Auditors must verify not just the security of backup storage, but genuine 24/7 (or crisis-appropriate) accessibility.

Additional storage considerations: protection from magnetism, humidity, and high temperatures, as well as overall cost.

Key takeaway: losing some data because a hard drive failed is an inconvenience. Discovering that backups were never actually valid turns that inconvenience into a crisis — rigorous, periodic backup testing is essential to trust the recovery capability.

Module 4: System Recovery Site Strategies

Hot Sites: Multiple Processing Centers, Mirrored Sites, and Commercial Hot Sites

Site selection is driven primarily by the RTO: faster required recovery generally costs more. All of the options below satisfy the formal definition of a hot site — a site that is fully equipped and ready to go — but they differ in ownership model and cost:

flowchart TD
    Hot[Hot Site<br/>Fully equipped and ready to operate] --> MPC[Multiple Processing<br/>Center]
    Hot --> Mirror[Mirrored/Dark<br/>Site]
    Hot --> Comm[Commercial<br/>Hot Site]

    MPC --> MPC1[Owned by the organization]
    MPC --> MPC2[100% equipment + data + staff at both sites]
    MPC --> MPC3[Full failover capability<br/>No data loss, no downtime]
    MPC --> MPC4[Most expensive option]

    Mirror --> Mirror1[Vendor-provided or organization-owned]
    Mirror --> Mirror2[Data continuously updated<br/>can run dark]
    Mirror --> Mirror3[Outage: minutes to a few hours]

    Comm --> Comm1[Syndicated across many client companies]
    Comm --> Comm2[Equipment + employee support + infrastructure provided]
    Comm --> Comm3[Client adds data at time of activation]
    Comm --> Comm4[Outage: typically 4-6 hours to load data]
    Comm --> Comm5[Lower cost than dedicated sites -<br/>cost is shared]

Cloud-Based Recovery

The cloud can serve as a flexible, cost-effective recovery option:

• Pay-for-use storage cost model.
• In some cases, processing itself can be shifted to the cloud, but this depends heavily on whether the specific applications support that model.
• Highly available and flexible.
• Legal/jurisdictional considerations must be evaluated (is the data still within the required legal jurisdiction?).
• For many organizations, cloud effectively functions as an accessible, always-available “hot site” alternative for data storage, though it is not a universal substitute for full production failover.

Mobile Recovery Sites

Mobile sites / mobile trailers — essentially trucks equipped with server racks and workspace — were historically deployed to a parking lot near a damaged facility (e.g., after a server room flood):

• Fairly quick to deploy (deployment time depends primarily on distance/logistics).
• Limited space; not designed for extended long-term operations — intended as a bridge while the permanent facility is repaired.
• More cost-effective than a commercial hot site, but with a somewhat longer outage (often a day or two).
• Poorly suited to remote locations or areas of extreme temperature.

Warm Sites and Cold Sites

There is significant and persistent confusion around the term warm site — it is not simply “a hot site that isn’t quite operational.” The formal, exam-relevant definitions are:

Even a cold site has non-negotiable minimum requirements, because these specific elements are outside the organization’s direct control and cannot be arranged on short notice:

• Adequate power (a utility cannot install new high-voltage 3-phase power on short notice — this can take many months).
• Heating, ventilation, and air conditioning (HVAC).
• Network/fiber connectivity.
• Physical security.

Choosing the Right Recovery Site

Selection among all of these options depends on:

• Available budget.
• The RTO the organization must meet.
• Proximity risk — is the alternate site close enough to be affected by the same threat?
• General security of the location (avoiding, for example, high-crime areas for continuous 24/7 operations).
• Logistics — can employees actually get there (public transportation, distance, travel time)?
• Support requirements at the alternate site — food, water, and other logistics necessary for sustained operations.

flowchart TD
    Start[Determine RTO Requirement] --> Q1{RTO measured in<br/>minutes?}
    Q1 -- Yes --> MPC[Multiple Processing Center<br/>or Mirrored Hot Site]
    Q1 -- No --> Q2{RTO measured in<br/>hours?}
    Q2 -- Yes --> Comm[Commercial Hot Site<br/>or Cloud]
    Q2 -- No --> Q3{RTO measured in<br/>about a week?}
    Q3 -- Yes --> Warm[Warm Site]
    Q3 -- No --> Cold[Cold Site]

As auditors, we must confirm the organization can actually recover IT processing — grounded in verified data recovery (backup frequency, media type, and storage location) sufficient to rebuild IT systems and support ongoing business resilience and continuity.

Module 5: Auditing Business Continuity and Disaster Recovery Plans

Writing Effective BCP/DRP Documentation

When auditing the writing of BCP/DRP documentation, verify that:

• The plan was developed by a combined team of business representatives and technical staff — not IT alone.
• Plans are action-oriented: concise, step-by-step (“do this, then this, then this”) rather than verbose reference material.
• Plans are written to be good enough to function in a worst-case scenario — a plan built only for an average/best-case scenario may fail when conditions are worse than expected. A worst-case-capable plan inherently covers all lesser scenarios; it is easier to use only part of a comprehensive plan than to lack a plan altogether for the situation actually encountered.
• Plans are organized into separate modules for different types of crises, are easy to follow, and easy to update.
• A training strategy exists so every participant understands their role during a crisis.
• All dependencies are documented — both between sections of the same plan and links out to other, related plans.
• The plan carries documented senior management approval and support, so that leadership does not attempt to renegotiate the plan mid-crisis.

Roles, Responsibilities, and Cross-Training

• Teams are assigned clear roles and responsibilities, and every leadership role should have a designated deputy who can step in if the primary lead is unavailable.
• Cross-training ensures that if one person is unavailable, someone else can perform their function.
• Reporting relationships must be explicit — who sits on the business continuity team, the disaster recovery team, and the incident response team — so decision-making authority is unambiguous during a crisis.
• Proper training and tools should be provided in advance, such as a pre-assembled “battle box” containing everything needed to respond, ready to be picked up and taken to the site immediately.

Elevated Risk During a Crisis: Fraud, Errors, and Reduced Controls

A crisis is inherently a period of elevated risk because normal controls — such as separation of duties — are frequently absent (a single person may be forced to perform multiple roles at once). This creates conditions for:

• Increased costs from inefficient, ad-hoc operations.
• More errors, since personnel are frequently under pressure, fatigued, and operating without the normal checks and balances.
• Increased opportunity for fraud and theft, including looting in the case of physical damage to a site.
• Employee stress and burnout — auditors and management alike should watch for team members becoming unable to continue functioning effectively.

Crisis Communication and the Emergency Operations Center

Good communication must continue throughout a crisis with all stakeholders who could be affected:

Organizations should have trained spokespeople and a defined communication strategy in advance. Crisis coordination is typically centralized through an Emergency Operations Center (EOC) — a single point where information is gathered and from which management communicates the evolving status: progress made, milestones reached in the recovery strategy, and next steps.

sequenceDiagram
    participant Ops as Field/Recovery Teams
    participant EOC as Emergency Operations Center
    participant Mgmt as Senior Management
    participant Ext as External Stakeholders<br/>(customers, regulators, suppliers, shareholders)

    Ops->>EOC: Report status and progress
    EOC->>Mgmt: Consolidated situation report
    Mgmt->>EOC: Decisions and priorities
    EOC->>Ops: Direction and resource allocation
    EOC->>Ext: Trained spokesperson communication
    Note over EOC,Ext: Ongoing updates as milestones are reached

Recovery versus Restoration

Recovery and restoration are distinct phases with opposite prioritization order:

flowchart LR
    subgraph Recovery["Recovery (during the crisis)"]
    direction LR
    R1[Most critical<br/>business processes] --> R2[...] --> R3[Least critical<br/>business processes]
    end
    subgraph Restoration["Restoration (returning to normal)"]
    direction LR
    S1[Least critical<br/>business processes] --> S2[...] --> S3[Most critical<br/>business processes]
    end
    Recovery -.crisis stabilizes.-> Restoration

• Recovery happens during the crisis at the temporary/alternate location, prioritizing the most critical business processes first.
• Restoration is the process of moving back to normal operations. It proceeds in the opposite order: less-critical functions (e.g., internal audit) are moved and tested first at the new/normal location, validating that networks and systems work correctly, before the most critical business processes are cut over and put at risk during the final transition back to normal.

As auditors, our responsibility across this entire module is to confirm that plans adequately protect data and information systems during a crisis, include controls to prevent fraud, and maintain control over all crisis communications.

Self-Assessment Questions

The following practice questions (adapted from the course study guide) reflect the style and reasoning expected on the CISA exam for this domain. Each includes the recommended answer and the reasoning behind it.

1. An auditor uncovers activity that may be related to some criminal activity. What should the auditor do first?

   • A) Call law enforcement B) Follow the escalation procedures C) Seize all evidence D) Withdraw from the audit
   • Answer: B. Always follow defined procedures — the more serious the situation, the more important it is to follow procedure rather than improvise. The other actions (contacting law enforcement, evidence handling) should already be embedded within those escalation procedures. When a “management” answer effectively encompasses the other options, it is generally the best choice.

2. The organization has a legal requirement to provide high availability of services with a maximum outage of 96 hours. Which type of recovery site would meet that requirement and yet be cost effective?

   • A) Multiple Processing Center B) Cold Site C) Warm Site D) Commercial Hot Site
   • Answer: D. A multiple processing center would meet the requirement but at much higher cost. A warm site (commonly requiring up to about a week to become operational) would likely not meet a 96-hour requirement — a common misconception is that a “warm site” is a hot standby, but formally it is only partially equipped. A cold site would take even longer. A commercial hot site balances cost and speed (typically 4–6 hours to become operational).

3. An auditor is reviewing the input data used in the BIA calculations. From which perspective should the BIA be conducted?

   • A) The user perspective B) The business perspective C) The IT perspective D) The regulatory perspective
   • Answer: B. A BIA is a business impact analysis; it should incorporate the other perspectives, but its lens is fundamentally the business mission.

4. What is the advantage of reviewing the lessons learned from an incident a few days after the incident instead of only reviewing immediately?

   • A) Better analysis without the emotion of the moment B) Fewer people are involved C) More data can be remembered D) Incident documentation is available
   • Answer: A. Immediately following an incident, people may be tired and emotionally exhausted, increasing the risk of anger or unkind exchanges. Waiting allows more thoughtful, higher-quality analysis, though some participants may no longer be available. Documentation should be available in either case.

5. The auditor is invited to observe a test where all key team members meet in a boardroom and describe their role in the event of a crisis. Which type of test is this?

   • A) Desktop B) Simulation C) Walkthrough D) Parallel
   • Answer: C. This is a walkthrough, because the key team members participate together, as a team. A desktop (read-through) test is not performed as a full team. A simulation involves actually executing parts of the plan. A parallel test operates the recovery plan while normal operations continue simultaneously.

6. The auditor is reviewing patch management as part of a change control audit. IT states a critical vendor patch is available, but normal change control requires ten days for approval and scheduling. What should IT do?

   • A) Deploy the change and obtain approval later B) Submit the request as normal C) Validate whether the change is applicable and required D) Subscribe to a third-party monitoring service
   • Answer: C. Under pressure, the correct first step is always to gather more data before acting: is the patch actually applicable? Are compensating controls already in place? While emergency change procedures would ideally apply, that specific option wasn’t offered — the best answer from those given is to validate the change first, not act unilaterally nor blindly follow the standard ten-day process.

7. The organization wants to strictly control traffic from their DMZ into their internal networks. What approach should be used to create the firewall rules?

   • A) Deny all B) Whitelisting C) VPN D) Blacklisting
   • Answer: B. Whitelisting only allows explicitly recognized, approved traffic and blocks everything else — a stricter and more defensible control than blacklisting known-bad traffic.

8. An organization wants to be aware of newly developing risk so it can proactively implement risk responses. What resource assists with this?

   • A) Risk treatment B) Vulnerability assessment C) Threat intelligence D) Log analysis
   • Answer: C. Threat intelligence monitors for newly emerging risk, often via global traffic/trend monitoring. Log analysis addresses events that have already occurred (though it can reveal probing activity). Vulnerability assessments identify already-known weaknesses. Risk treatment addresses already-identified risk.

9. The risk of collusion increases when teams work together for many years. How can this risk be mitigated effectively?

   • A) Hire new staff B) Increase audit frequency C) Job rotation D) Cross-training
   • Answer: C. Job rotation is the most effective way to disrupt collusion that circumvents separation of duties. Hiring new staff is expensive and most fraud is actually committed by long-tenured staff. Increasing audit frequency helps somewhat but is less effective. Cross-training can actually increase collusion risk since it broadens what any one individual is capable of doing alone.

10. What is a risk associated with re-using storage media?

    • A) Presence of residual data B) Loss of encryption keys C) Incorrect labels on media D) Failure to inventory media
    • Answer: A. While age/number of uses might seem the obvious answer, the primary risk with media re-use specifically is that residual data from the previous use may remain accessible/recoverable — a greater exposure than mislabeling or inventory gaps.

11. The security manager receives an email claiming the organization is the source of an attack on another organization. What should the manager do?

    • A) Call legal counsel B) Refer to law enforcement C) Ignore the email as spam D) Review egress monitoring
    • Answer: D. First verify whether outbound traffic is actually communicating with known command-and-control infrastructure or targeting the alleged victim’s IP address. Egress monitoring is just as important as ingress monitoring. The other actions may follow, but gathering supporting information first enables an informed conversation with other parties.

12. What tool can be used to prevent unauthorized changes on a host?

    • A) Intrusion Detection System (IDS) B) Intrusion Prevention System (IPS) C) Virtual Private Network (VPN) D) Web Application Firewall (WAF)
    • Answer: B. An IPS can actively prevent a change; an IDS only detects changes already made. A VPN provides trusted remote access, not host-level change prevention. A WAF only protects web-hosting servers specifically.

13. What is the most serious problem related to anti-malware tools?

    • A) Vendors are slow to create new signature files B) Social engineering can bypass most malware tools C) Malware tools may disable other systems D) Malware tools are expensive to maintain
    • Answer: B is the best answer, though all options have some validity. Vendors do roll out signatures as quickly as possible, but new/novel attacks may still go undetected; cost varies by tool; instances of anti-malware software disabling systems have occurred but are rare. Social engineering bypassing technical malware controls entirely is the more fundamental and serious weakness.

14. What can be done to protect cables from damage?

    • A) Maintain good cabling records B) Only route cable through secure areas C) Maintain separation between electrical and data cables D) Place cables in conduit
    • Answer: D. Conduit physically protects cabling even when routed through secure areas or near electrical cabling. Poor cabling records are a documented cause of many network interruptions, but recordkeeping alone does not prevent physical damage.

15. An organization has installed a honeypot in their externally facing network segment. What is its purpose?

    • A) To gather information on types of attacks B) To stop attacks early in the attack lifecycle C) To provide a secure interface for external communications D) To attract potential employees
    • Answer: A. A honeypot distracts an attacker from assets of real value while providing intelligence on the tools and techniques being used against the organization.

Summary

This domain — information systems operations and business resilience — is worth 26% of the CISA examination when combined with its companion operations-focused course. The business-resilience half covered here centers on auditing business resilience, business impact analysis, system resiliency, data backup/storage/restoration, business continuity plans, and disaster recovery plans.

Golden Rules to Remember

• BIA is exactly what its name says — analysis of impact on the business, not just on IT.
• RPO measures loss of data. Always mentally insert the word “data” in front of RPO.
• DRP is about relocation/recovery of IT services — not simply emergency response — though the exam may test either meaning depending on context; read the question carefully.
• A plan cannot be trusted until it has been tested.
• BCP and DRP go stale quickly and must be tied to the change control process so they are updated whenever relevant changes occur.

Quick-Reference: Key Terminology

Exam Essentials Checklist

• Understand investigations: chain of custody, gathering and preserving evidence, analysis and reporting.
• Understand monitoring: log management, firewall types, host/network-based IDS and IPS, egress monitoring, anti-virus.
• Understand configuration management: change control, baselines, patch management.
• Understand media protection: number of uses, age, environmental protection.
• Understand incident management: the response process and using lessons learned to improve future response.
• Understand BCP/DRP: the overall process, types of tests, and terminology (BIA, RPO, SDO, RTO, MTD).
• Understand personnel security: awareness and safety considerations during a crisis.
• Know the five (or six) resource-requirement categories for critical business functions: people, equipment, IT systems/networks, data, workspace, and supply chain.
• Be able to distinguish recovery (most-critical-first) from restoration (least-critical-first).
• Be able to compare hot, warm, and cold sites, plus multiple processing centers, mirrored sites, commercial hot sites, cloud, and mobile trailers, by cost and time-to-operational.
• Be able to compare full, differential, and incremental backup strategies and their restore implications.

Proceed next to the companion domain course, Protection of Information Assets, which focuses on information asset security and control.

Search Terms

information · systems · operations · business · resilience · isaca · cisa · governance · risk · compliance · networking · security · recovery · continuity · backup · crisis · sites · system · analysis · auditing · bcp · impact · management · program