CISA Business Resilience: BIA, Backup and Restoration, Business Continuity and Disaster Recovery Plans

A business impact analysis (BIA) identifies the organization's critical business processes and measures how the impact of losing each one grows over time, so that recovery priorities and recovery objectives rest on business need rather than on IT's view. It is the foundation of the whole continuity program: criticality rankings, recovery time and recovery point objectives, and therefore every recovery strategy, are derived from it. That is why the BIA comes before strategy selection, site contracts and plan writing.

What a sound BIA captures

• Impact by type: financial loss, but also legal and regulatory breaches, contractual penalties, customer harm, safety and reputation.
• Impact over time: how losses build after one hour, one day, one week. The point at which harm becomes unacceptable is the maximum tolerable downtime.
• Timing and peaks: impact can vary sharply through the business cycle, so it should be measured at the most time-sensitive points, not only as a yearly average.
• Dependencies: the systems, data, people, suppliers and facilities each process relies on.

Business owners, not IT, judge impact

Impact is a business judgement. Lost revenue, penalties and customer consequences are known by the people who run the processes, so criticality must be gathered from or validated by business process owners and approved by senior management. Technical data shows how systems are used, not how much their loss hurts the business. Note also the difference from a risk assessment: the BIA asks what happens if a process stops; a risk assessment asks how likely each threat is.

Keeping it current

Significant changes to the business, its obligations or its systems can create new critical processes or change the impact of existing ones. The BIA is therefore reviewed periodically and after major change, because the strategies, contracts and tests built on it are only as current as its output.

Recovery objectives turn the BIA into measurable targets: the recovery point objective (RPO) limits data loss, the recovery time objective (RTO) limits time to restore, and the maximum tolerable downtime (MTD) is the business limit the RTO must stay within.

Reading the objectives against the facts

An RTO longer than the MTD means the planned recovery arrives after the business has already been harmed beyond tolerance: the recovery target does not support the business requirement.

An RPO is only met for a scenario if a copy that survives that scenario is recent enough. For a disk or application failure, local copies count; for loss of the whole site, only copies held elsewhere do, so the off-site copy frequency is what limits data loss in that scenario. Both objectives are set by business need from the BIA; technical constraints shape how they are met, not what they are.

A recovery strategy should be sized to each system's criticality: the sensible target is where the combined cost of disruption and of recovery is lowest. Downtime cost rises the longer a process is down; recovery capability costs more the shorter the recovery time demanded. Less critical systems therefore get less expensive arrangements, but every system in scope still needs one that meets its own objectives.

What makes an arrangement reliable

Compare each arrangement's realistic time to operate with the RTO: one that is slower fails the objective, and one far faster than needed costs more than the impact justifies. Any arrangement that depends on something arriving or being shared at the time of the disaster (hardware for a cold site, capacity at a commercial or reciprocal site) is only as reliable as the commitment behind it, and a regional event puts many customers in the same queue. Look for contractual delivery or capacity guarantees, test rights and enough geographic separation.

System and operational resilience is the ability of systems and facilities to keep running through component failure, achieved by eliminating single points of failure through redundancy in servers, storage, network paths and power. Clustering (active-active or active-passive), replicated databases, redundant network links and dual power feeds each remove a failure point, but the auditor should trace every path end to end: redundancy is only as strong as the least redundant component that the redundant parts share.

Fault tolerance is not backup

RAID (for example RAID 1 mirroring or RAID 5 parity), hot-swappable drives and redundant power supplies keep a system available when hardware fails. They do not protect data: every write, including an accidental deletion, a corrupting bug or ransomware encryption, goes to all disks at once, and the disks sit in the same server and site. Recovery to a point before an error, or after the site is lost, needs separate point-in-time backups stored elsewhere.

Power resilience is a chain

Each link must cover the outage the BIA expects; resupply arrangements are tested hardest by a regional outage, when demand on suppliers peaks.

Backups are point-in-time copies of data that allow recovery to an earlier state; the backup type chosen trades backup time and size against restore time.

With a weekly full and nightly differentials, a restore to any night needs only the full and that night's differential. With nightly incrementals, a late-week restore chains the full and several incrementals, which lengthens restore time and adds a failure point for each set.

Rotation and labelling

A grandfather-father-son rotation keeps daily (son), weekly (father) and monthly (grandfather) generations on a fixed, reusable media pool: daily media are reused each week, weekly media each month, and monthly media are kept longer. It is independent of the backup type. Media should be labelled, inventoried and tracked in and out of storage, and retention should follow business, legal and regulatory requirements.

Online databases

A database backed up while in use needs a database-aware method, such as the DBMS backup utility, or quiescing the database and capturing transaction logs. A plain file copy of open database files may be internally inconsistent even though the backup job reports success.

Storage: distance, isolation from attack and key availability

Backups protect against disaster only if at least one recoverable copy is kept where the event that destroys production cannot reach it: far enough away to avoid a shared physical event, and isolated enough that an attacker with network access cannot alter it.

• Distance: storage close to the primary site shares its fire, flood, power and access risks. Off-site storage should be far enough to avoid a shared event yet reachable within the recovery time.
• Offline or immutable copies: ransomware that gains administrative access can encrypt network-attached backup storage along with servers. At least one copy should be offline, air-gapped or held in immutable storage that blocks change or deletion for a retention period.
• Encryption keys: encrypted backups are only recoverable if the keys are. If the only key copy sits in the backup server at the primary data center, a site disaster makes every off-site copy unreadable. Keys, or a key escrow arrangement, must be protected and retrievable from a location separate from the primary site.
• Plan and procedure copies belong off-site too (see the continuity plan section).

This is the reasoning behind the widely used 3-2-1 guideline: three copies, on at least two types of storage, with at least one off-site; many organizations now add a requirement that one copy be offline or immutable.

Replication keeps a second copy of data continuously current to limit data loss when a site fails; point-in-time backup keeps older versions so data can be returned to a state before an error. One does not replace the other.

What the auditor checks

Synchronous replication over long distances adds latency that can make it impractical for transactional systems, which is why distant secondary sites usually rely on asynchronous replication. With asynchronous replication, compare the observed lag with the RPO for site loss; only copies held outside the affected site count toward that RPO. And an organization that stops taking point-in-time backups because it replicates has no clean copy to return to after a bad batch update or a malicious deletion.

The most reliable evidence that backups will support recovery is a periodic, documented restore to a test environment whose result is checked, because it exercises the whole chain of media, software, procedures and data. Job-completion reports, approved backup policies and off-site media inventories are indirect evidence: they show that backups were scheduled, written and stored, not that they can be restored.

Making restore tests meaningful

• Restore what matters, the way it would be needed: test full system and database recoveries over time, not only individual files, so consistency of the restored data is proven too.
• Validate the data, not just the job: a restore that finishes without errors may still produce incomplete or unusable data. Reconcile record counts and control totals, and have business owners confirm the application works with the restored data.
• Time it: compare restore duration with the RTO, including the time to retrieve media from off-site storage.
• Cover different backup sets and generations over time, and record results and follow-up actions.

When evaluating the organization's storage, backup and restoration policies and processes, the auditor looks at all of these together: whether backup frequency and storage location meet each RPO, whether retention meets requirements, whether copies are protected from the threats in scope, and whether restoration has actually been demonstrated.

A business continuity plan (BCP) sets out how the organization keeps or resumes its critical business processes during and after a disruption; a disaster recovery plan (DRP) is the IT-focused part that restores systems, data and infrastructure to meet the recovery objectives. Both rest on the BIA, and ISO 22301 is the international standard for a business continuity management system.

Governance

• Senior management sponsorship: a continuity policy approved at the top, with funding and accountability.
• One coordinated, enterprise-wide plan: departmental plans are useful only as parts of a whole. Written and tested in isolation, they may all count on the same recovery seats, equipment, IT staff and restoration slots, and the conflicts surface only when a site-wide disaster invokes them all at once.
• Maintenance triggered by change: a plan that still describes systems that were migrated months ago shows that change management does not trigger a plan review. Testing may catch drift, but only after the fact; the control is a change-driven update process plus periodic review.

What the plan must contain

• Life safety first: evacuation, accounting for all personnel and emergency services come before any business or IT activity.
• Declaration and escalation: clear criteria for declaring a disaster and a named person, with alternates, authorized to declare it and commit the cost of moving to the recovery site. "Declare when appropriate" invites delay, and that delay comes straight out of the RTO.
• Roles and teams with alternates, a call tree and contact lists, and communication plans for staff, customers, regulators and the media.
• Recovery order: systems restored in BIA priority, but including the technical components critical systems depend on, such as directory services, DNS, interfaces and middleware. An application restored on time cannot work if a dependency ranked low in the BIA returns a day later, so the plan needs a dependency map.
• Procedures, resources and vendor contacts, including how to return to the primary site.
• Plan copies off-site and with key team members, under version control, so the recovery can be directed when the primary site is inaccessible.

Plans are tested in a progression from low risk and low realism to high, so that each test builds confidence before the next one risks real operations. A newly written plan starts with paper-based tests.

How the auditor evaluates a test

• Before the test: check that it has defined scope and measurable objectives and success criteria (which systems, which RTO and RPO each must meet). Without them, any outcome can be called a pass.
• Were conditions realistic? Timings prove the RTO only if the test included every step a real event would need. Pre-staged data or equipment, extra notice and unusual staff availability all make the result unrepresentative.
• Were the documented procedures used? Tests should follow the written procedures, carried out by the staff who would use them, so the procedures themselves are proven and recovery does not depend on one person.
• Is there follow-up? Each finding needs an owner, a fix and a date, and the next test confirms closure.

When a critical process runs on a third party's service, the organization keeps the continuity risk, so it needs independent evidence that the provider can recover within the organization's own RTO and RPO.

Contracts should state recovery commitments (RTO, RPO, notification, test participation or results, and the right to audit), and the organization's own plan must cover what it does if the provider fails, including where its data copies are and how it would reach them. In general, independently tested evidence is stronger than the provider's own statements, and evidence about a management system or normal uptime is not evidence that a specific recovery objective can be met. When the evidence does not cover the requirement, the auditor reports the gap and looks for other evidence rather than assuming the risk is covered.