10.3 Backup, Redundancy, Testing, and Drills

Backup versus redundancy

The SSCP outline pairs Backup and redundancy implementation with Testing and drills (playbook, tabletop, disaster recovery exercises, scheduling). Backups are how you hit RPO. Tests are how you prove RTO. Mixing backup with redundancy is the trap that fails both the exam and the ransom note.

Backup is a copy you can restore after data is destroyed, encrypted, corrupted, or deleted — preferably a copy the threat cannot also destroy. Redundancy (a second power supply, Redundant Array of Independent Disks (RAID), a clustered node, a second network path) keeps a service available through a component failure.

RAID is not a backup. RAID-5 or RAID-6 can survive one or two disk failures. It does not survive ransomware that encrypts every disk in the array, an administrator who deletes a volume, a fire in the same rack, or silent corruption that is then rebuilt onto the parity disks. If the only copy is another disk in the same server, you have redundancy, not a restore path.

Use redundancy and backups. A stem that treats RAID-6 plus a hot spare as offsite backup is wrong even if the array is healthy.

Replication is not automatically a backup either. A mirrored volume in the same site is still one fire. A synchronous replica that instantly copies encrypted files gives you two encrypted copies and an excellent RPO of malware. Delayed or versioned replication, plus an offline generation, is how you keep a clean point in time.

Backup types and how you actually restore them

Restore math. Full on Sunday. Incrementals Monday through Thursday. Thursday-night ransomware. Restore = Sunday full + Monday + Tuesday + Wednesday + Thursday incrementals — unless Thursday's job ran after encryption. Then you stop at the last known-clean incremental and accept the RPO miss. Differentials: Sunday full + Thursday's differential only.

Rotation schemes (grandfather-father-son and similar) keep multiple generations so you can reach back past last night. That matters for ransomware with dwell time: the encryptor may already have been inside last night's successful job. A single overwrite-every-night disk is an RPO of 24 hours and a single point of failure.

Implementation details that show up in stems:

• Encrypt backup media; store keys where destroying the tape does not destroy the only key, and where stealing the key does not unlock every vault.
• Document what is not in the job (temp, scratch, a shadow database an app owner added without telling IT).
• Databases and domain controllers need application-consistent backups (quiesce, Volume Shadow Copy, vendor agent). A crash-consistent snapshot may not replay cleanly.
• Cloud snapshots in the same account are not offsite. Copy to another account or region with a separate identity.
• The backup service account must not be ordinary domain admin. MFA, monitored use, and a unique vault identity make ransomware's favorite second victim harder to take.
• Protect the catalog. A perfect tape you cannot index is a box of rust.

A widely taught operations pattern is 3-2-1: at least three copies of data, on two different media types, with one offsite. Ransomware-era practice adds an immutable or air-gapped generation and a verified restore (sometimes marketed as 3-2-1-1-0). ISC2 does not publish a branded slogan you must name. Knowledge area 4.3 is testing whether you know that online-only backups get encrypted too.

Online backup servers on the same VLAN as the file server are a second victim. Knowledge area 4.1 already taught you not to recover from an infected generation. This section is the design so a clean generation exists: immutable copies, delayed replication so corruption does not land instantly, and isolation of the backup control plane.

Restoring from last night's infected backup

Scenario. Last night's backup of FILESERVER01 finished at 02:00. Encryption started at 01:10. The job is marked successful because files were copied — including the encryptor and the encrypted share. Restoring that job meets a 24-hour RPO on paper and re-infects production.

An immutable Saturday copy from before initial access still exists in object storage with retention lock. The SSCP restores Saturday, to an isolated network, scans it, rotates any secrets baked into the image, and only then reconnects a share. If no such copy exists, the backup program failed before the incident. Meeting RPO with malware is not meeting RPO.

Select the restore point before initial access, not before the ransom note. Dwell time of days is common. The last successful job is a status icon, not a cleanliness certificate. After restore, watch endpoint detection longer than it feels necessary; then record actual data loss against RPO for the lessons-learned meeting.

Testing and drills

The outline's last 4.3 bullet is Testing and drills (e.g., playbook, tabletop, disaster recovery exercises, scheduling). An untested BCP or DRP is a hypothesis. Tests find missing DNS, expired certificates, backup catalogs that do not restore, and a hot site whose switch still has last year's VLAN list.

Playbooks are the technical scripts: commands, ticket queues, who has break-glass, in which order you restore identity before payroll. Tabletops exercise decisions: who declares, who talks to contractors, whether you isolate the backup VLAN. Disaster recovery exercises exercise systems. You need all three. A PDF nobody has opened is not support for 4.3.

Tabletop versus full failover is an exam favorite.

Scenario. The CISO wants proof we can meet the 8-hour payroll RTO. The team runs a two-hour tabletop. Everyone agrees the warm site should work. A tabletop cannot measure RTO. It can prove that the payroll director knows who declares a disaster, that the out-of-band bridge number is current, and that legal knows when to call the processor. Measuring eight hours requires a disaster recovery exercise that actually restores payroll — preferably a parallel test first, then a scheduled cutover. Skipping to a surprise full interruption on a Friday payday is how you create a disaster in order to test for one.

Scheduling

Scheduling is on the outline because a test at the wrong time is either theater or an outage.

• Do not schedule a full payroll failover on the Thursday before Friday contractor pay unless the BIA and leadership accept that risk in writing.
• Do schedule some tests during business-like hours. A 02:00 Sunday restore with the A-team on the bridge does not prove a Tuesday 14:00 disaster with the B-team and a stuck MFA vendor.
• Announce tabletop and parallel tests. Surprise belongs to detection drills, not to dropping production DNS.
• After-action: update the playbook, update the BIA if MTDs changed, and put the next test on the calendar. A test with no findings is usually a test that was not trying.
• Test after major changes (new identity provider, datacenter move, backup-product swap), not only once a year. ISC2 does not publish a universal SSCP-required interval. Follow policy, contracts, and regulators that actually apply to that organization.

Scope tests the way you scoped the BIA. Restoring a wiki proves nothing about payroll. Restoring payroll without DNS, certificates, and the time-clock interface proves a server boots, not that contractors get paid.

Restore sequence that ties 4.3 together

1. Life safety and occupant emergency if the site is unsafe.
2. Declare using BIA criteria; activate crisis management and communications.
3. Start BCP interim processing (paper payroll, sister warehouse).
4. Select a known-clean backup generation that meets RPO as closely as possible without restoring malware.
5. Restore at the site whose design meets RTO, on an isolated network if this is also an incident.
6. Validate at the application level — a test pay cycle, not a ping.
7. Complete WRT (clerks catch up; reconcile paper).
8. Record actual time against RTO, RPO, and MTD; feed lessons into the next drill.

When a CAT stem offers RAID as the offsite copy, refuse it. When it offers last night's successful job taken during encryption, refuse it. When it offers a tabletop as proof of an 8-hour RTO, name the test that actually restores.