Backup, Disaster Recovery and Business Continuity

Why This Topic Matters

Security is often described through the CIA triad: Confidentiality, Integrity and Availability. Backup, Disaster Recovery (DR) and Business Continuity (BC) are the disciplines that protect the Availability leg of that triad. A perfectly secure application that is offline for three days after a ransomware event, a data center fire or a corrupted database is still a security failure. For the CSSLP, this topic matters for three reasons:

1. Software is now the business. When the application is down, the organization cannot sell, ship, bill or serve customers. Resilience is therefore a security requirement, not just an operational nice-to-have.
2. Developers shape recoverability. Decisions made during design and coding, such as how state is stored, whether the application is stateless and horizontally scalable, how secrets and keys are managed, and whether configuration is version-controlled, determine whether recovery is possible at all.
3. Compliance and contracts demand it. Regulations (HIPAA, PCI DSS, GDPR, SOX, FFIEC) and Service Level Agreements (SLAs) explicitly require documented, tested continuity and recovery plans.

The ISC2 CSSLP exam places this material in Domain 7 (Secure Software Deployment, Operations and Maintenance), where the secure software lifecycle moves from building the software to running and sustaining it. Expect questions that test both definitions and judgment about priorities.

What It Is: Three Related but Distinct Concepts

Backup is the process of creating copies of data, code, configuration and other digital assets so they can be restored after loss, corruption or compromise. Backup is a tactical control and is a prerequisite for recovery, but on its own it is not a recovery plan.

Disaster Recovery (DR) is the set of technical procedures and resources used to restore IT systems, applications and data at an alternate location or on alternate infrastructure after a disruptive event. DR is IT-focused and reactive: it answers the question, how do we get the systems running again?

Business Continuity (BC) is the broader, business-focused and strategic discipline that ensures critical business functions continue during and after a disruption. BC includes people, processes, facilities, suppliers and communications, not only technology. DR is a subset of BC. A Business Continuity Plan (BCP) might include a Disaster Recovery Plan (DRP), a Crisis Communication Plan, an Occupant Emergency Plan, and a Continuity of Operations Plan (COOP).

A useful memory aid: Backup protects data, DR restores technology, BC sustains the business.

Key Metrics You Must Know

Business Impact Analysis (BIA) is the foundational activity. It identifies critical business processes, the systems that support them, dependencies, and the financial and operational impact of downtime over time. The BIA produces the metrics below and drives every subsequent decision. On the exam, if a question asks what should be done first when building a BCP or DRP, the answer is almost always the BIA (or obtaining management support and defining scope, which precede the BIA in a full program).

Maximum Tolerable Downtime (MTD), also called Maximum Allowable Downtime (MAD) or Maximum Tolerable Period of Disruption (MTPD): the longest time a business process can be unavailable before the organization suffers unacceptable or irreparable harm.

Recovery Time Objective (RTO): the target time within which a system or application must be restored after an outage. RTO must be less than or equal to MTD. RTO is about time to restore service.

Recovery Point Objective (RPO): the maximum acceptable amount of data loss, measured in time. An RPO of four hours means backups or replication must occur at least every four hours. RPO is about how much data you can afford to lose and directly dictates backup frequency.

Work Recovery Time (WRT): the time needed after systems are restored to verify data integrity, re-enter lost transactions and return the business process to normal. MTD = RTO + WRT.

Mean Time Between Failures (MTBF): average expected time between failures of a component; a reliability metric.

Mean Time To Repair (MTTR): average time required to repair a failed component and return it to service.

Service Level Agreement (SLA): a contractual commitment (often expressed as availability percentages such as 99.9 percent, which equals roughly 8.76 hours of downtime per year) that recovery capabilities must be able to support.

How Backup Works

Backup Types

Full backup: copies all selected data every time. Simplest and fastest to restore (one set), but slowest to perform and uses the most storage. Clears the archive bit.

Incremental backup: copies only data changed since the last backup of any type. Fastest to perform and smallest in size, but restoration requires the last full backup plus every incremental since, in order. Clears the archive bit.

Differential backup: copies all data changed since the last full backup. Each differential grows larger over time, but restoration requires only the last full plus the most recent differential. Does not clear the archive bit.

Exam trick: incremental is fastest to back up but slowest to restore; differential is a middle ground; full is slowest to back up but fastest to restore.

Other approaches include snapshots (point-in-time images of a volume or VM, fast but usually stored on the same system and therefore not a true backup), continuous data protection (CDP) (every change is captured, giving a near-zero RPO), synthetic full backups (a full set constructed from previous full and incrementals), and database-aware backups that capture transaction logs to allow point-in-time recovery.

The 3-2-1 Rule: keep at least 3 copies of data, on 2 different media types, with 1 copy offsite. Modern variants add an extra 1 for an offline or immutable copy (3-2-1-1-0, where 0 means zero errors verified by restore testing). Immutable or air-gapped backups are the primary defense against ransomware that deliberately encrypts or deletes backups.

Backup Storage and Rotation

Rotation schemes such as Grandfather-Father-Son (daily, weekly, monthly sets) and Tower of Hanoi balance retention depth against media cost. Offsite storage can be a vault, a secondary data center or cloud object storage. Electronic vaulting transfers batches of backup data to a remote site; remote journaling transfers transaction logs in near real time; remote mirroring maintains a live duplicate of the data.

Security of Backups

Backups are copies of your most sensitive data and must be protected at the same or higher level than production. This means: encryption at rest and in transit; strict access control and separation of duties for backup administrators; secure, tracked transport of physical media; key management that ensures encryption keys are themselves backed up separately (an encrypted backup with a lost key is simply lost data); logging of all backup and restore operations; and secure destruction (degaussing, shredding, cryptographic erasure) at end of life. Retention must honor legal holds and data retention policies, and must also enforce deletion where privacy law requires data to be erased.

What Software Teams Must Back Up

The CSSLP perspective extends beyond user data. A complete recovery requires: source code and version history; build scripts and CI/CD pipeline definitions; infrastructure-as-code templates; application and environment configuration; database schemas, data and transaction logs; container images and dependency artifacts; cryptographic keys, certificates and secrets (stored in a hardware security module or secrets vault with its own backup procedure); documentation and runbooks; and identity and access management configuration. If any one of these is missing, the application cannot be rebuilt identically.

Testing Restores

The most important principle: a backup that has never been restored is an assumption, not a control. Organizations must regularly perform test restores, verify integrity (checksums, application-level validation) and measure actual restore time against the RTO.

How Disaster Recovery Works

Recovery Site Options (ordered from fastest and most expensive to slowest and cheapest):

Hot site: fully equipped, powered, networked, with current data replicated. Recovery in minutes to hours. Highest cost.

Warm site: equipment and connectivity in place but data and some systems must be loaded or updated. Recovery in hours to a day or more. Moderate cost.

Cold site: basic facility with power, HVAC and space but no equipment or data. Recovery takes days to weeks. Lowest cost.

Mobile site: a transportable facility (trailer or container) that can be deployed where needed.

Mirrored or redundant site: a fully active duplicate running in parallel (active-active). Near-zero RTO and RPO. Most expensive; often implemented for high availability rather than classic DR.

Reciprocal agreement (mutual aid): two organizations agree to host each other during a disaster. Cheap but unreliable and raises confidentiality and capacity concerns; rarely the best exam answer unless cost is the overriding constraint.

Cloud DR and DRaaS: cloud providers allow pilot-light (minimal core running, scaled up on demand), warm standby, and multi-region active-active patterns. Cloud shifts capital cost to operational cost and makes geographic diversity far easier, but the shared responsibility model still leaves the customer responsible for backing up their own data, configurations and application layer. The cloud provider protects the infrastructure; it does not protect you from deleting your own database.

High Availability vs Disaster Recovery

High Availability (HA) prevents or minimizes downtime from component failures through redundancy inside a site or region: RAID, clustering, load balancing, redundant power and network paths, and automatic failover. DR addresses site-level or regional disasters. Both are needed. Data replication can be synchronous (the write is confirmed only after both sites have it, giving zero data loss but limited by distance and latency) or asynchronous (the write is confirmed locally and copied later, allowing greater distance but introducing some potential data loss). Synchronous replication supports an RPO near zero; asynchronous supports a small but non-zero RPO.

Designing Software for Recoverability

Secure software professionals contribute by designing applications that are stateless where possible so any instance can be replaced; externalizing state to replicated data stores; using idempotent operations so replayed transactions do not cause duplicates; implementing graceful degradation and circuit breakers; supporting health checks for automated failover; avoiding hard-coded hostnames, IP addresses and secrets that break when the environment changes; and defining data migration and schema versioning so a restored database matches the deployed code version. Infrastructure-as-code and automated deployment pipelines turn a multi-day manual rebuild into a repeatable, auditable process.

How Business Continuity Works: The Lifecycle

A typical BCP/DRP program follows these phases (NIST SP 800-34 is the classic reference):

1. Project initiation and management support: obtain executive sponsorship, define scope, assign roles.
2. Business Impact Analysis: identify critical functions, dependencies, MTD, RTO, RPO.
3. Risk assessment: identify threats (natural, human, technical), likelihood and impact.
4. Recovery strategy selection: choose backup methods, site types, replication and staffing approaches that meet the BIA requirements at acceptable cost.
5. Plan development: document procedures, call trees, roles, activation criteria, recovery steps, and return-to-normal (reconstitution) steps.
6. Testing and exercises: validate the plan (see below).
7. Training and awareness: ensure people know their roles.
8. Maintenance: review and update after every significant change, incident, test or at least annually. Change management must feed into plan updates.

Testing Types (from least to most disruptive and realistic):

Checklist or read-through: individuals review their sections of the plan for completeness.

Structured walkthrough or tabletop: team members meet and talk through a scenario step by step.

Simulation: a scenario is role-played with some actions taken, but production is not affected.

Parallel test: recovery systems are activated and processed alongside production, which continues running. Validates the alternate site without risk.

Full interruption test: production is actually shut down and operations move to the recovery site. Most realistic and most risky; requires senior management approval and is often scheduled during low-activity windows.

Returning to Normal

After a disaster, the least critical functions should be moved back to the primary site first to validate that it is stable, with the most critical functions moved last. This is a classic exam point: critical systems are recovered first at the alternate site, but restored last to the original site.

Common Pitfalls

Backups stored only on the same network as production and encrypted by ransomware; encryption keys not backed up or stored alongside the data they protect; never testing restores; plans that exist only as documents on a server that is itself unavailable during a disaster; failing to back up configuration and pipeline definitions; single points of failure in people (only one administrator knows the procedure); outdated contact lists; and assuming the cloud provider is responsible for customer data backups.

Exam Tips: Answering Questions on Backup, Disaster Recovery and Business Continuity

1. Separate the layers. If the question is about copying data, it is backup. If it is about restoring IT systems at another location, it is DR. If it is about keeping the business functioning, including people and processes, it is BC. BC is the umbrella; DR is a technical subset.

2. RTO is time to recover; RPO is data loss tolerance. If a question mentions how often backups must occur or how much data can be lost, the answer involves RPO. If it mentions how quickly service must be back, it is RTO. Remember RTO must not exceed MTD.

3. The BIA comes first. When asked what drives RTO, RPO, site selection or backup frequency, or what the first step in developing a plan is, think Business Impact Analysis. Technology choices follow business requirements, never the reverse.

4. Know the backup trade-offs cold. Incremental: fastest backup, slowest restore, needs full plus all incrementals. Differential: needs full plus latest differential. Full: slowest backup, fastest restore. Only full and incremental clear the archive bit.

5. Site types scale with cost and speed. Hot is fastest and most expensive, cold is slowest and cheapest, warm is in between. If the question says the organization needs recovery within minutes and cost is not the primary concern, choose hot or mirrored. If it emphasizes the lowest cost and tolerates days of downtime, choose cold.

6. Untested equals unreliable. Any answer that involves regularly testing restores or exercising the plan is strong. Any scenario where a backup exists but has never been restored should make you suspicious. Full interruption tests are the most realistic but require management approval because they carry real risk.

7. Protect the backups themselves. Backups must be encrypted, access-controlled, stored offsite, and ideally kept immutable or offline to resist ransomware. Keys must be backed up separately from the data. Backups contain the same sensitive data as production and deserve equal or greater protection.

8. Cloud does not remove your responsibility. Under the shared responsibility model, the customer remains responsible for backing up its own data and application configuration. Do not select answers that assume the provider handles customer-level backup automatically.

9. Think like a software professional, not only an operations engineer. CSSLP questions may ask what developers can do to improve recoverability: design stateless services, externalize configuration and secrets, use infrastructure-as-code, implement idempotent transactions, and ensure code, build artifacts and schemas are versioned and backed up alongside data.

10. Order of restoration. Recover the most critical systems first at the alternate site. When returning to the primary site, move the least critical first and the most critical last.

11. Plans must be living documents. Changes in software, infrastructure, personnel or business processes must trigger plan updates through change management. A correct answer often involves reviewing and updating the plan after an incident, test or significant change.

12. Watch for the best versus the only answer. ISC2 questions frequently offer several technically valid options. Prefer the answer that is risk-based, aligned with business requirements from the BIA, cost-justified, and approved by management. Avoid answers that are purely technical fixes with no reference to business priority, and avoid answers that are absolute (always, never, eliminate all risk).

13. Remember the big formulas and rules. MTD = RTO + WRT. 3-2-1 rule (three copies, two media, one offsite). 99.9 percent availability is about 8.76 hours of downtime per year; 99.99 percent is about 52.6 minutes.

Summary

Backup, Disaster Recovery and Business Continuity together ensure that secure software remains available and recoverable when things go wrong. Backup preserves the data and artifacts, DR restores the technology, and BC keeps the business operating. The Business Impact Analysis defines the requirements (MTD, RTO, RPO), the recovery strategies and site choices satisfy those requirements at acceptable cost, and regular testing proves the plan actually works. For the CSSLP exam, master the definitions, the metrics, the backup and site trade-offs, the lifecycle order, and the principle that business requirements and management support drive every technical decision.