Security+ Data Protection, Backups, and Disaster Recovery

Introduction

This lesson completes Domain 3, Security Architecture (18% of SY0-701), with objective 3.3, comparing and contrasting concepts and strategies to protect data, and objective 3.4, explaining the importance of resilience and recovery in security architecture. Data is what attackers want and what the business cannot lose, so the exam tests whether you can classify it, choose the right protection for each state, and design systems that keep running and recover after a failure.

Security+ data protection and disaster recovery scenarios hinge on terms such as RTO, RPO, MTTR, MTBF, full versus incremental backups, hot versus cold sites. Learn those precisely and the scenarios become straightforward.

Learning objectives

After this lesson you will be able to:

• Classify data and explain types, states, and sovereignty considerations.
• Select methods to protect data: encryption, masking, tokenization, obfuscation, segmentation, and permission restrictions.
• Explain data states: at rest, in transit, in use.
• Design high availability with load balancing, clustering, redundancy, and multi-site approaches.
• Choose a backup strategy and calculate restore requirements from RTO and RPO.
• Describe site considerations, platform diversity, continuity of operations, and recovery testing.

1. Data types and classification

Regulated data is subject to applicable laws, regulations, or industry requirements. Examples include personal data within GDPR’s scope, health information covered by HIPAA, and payment account data addressed by PCI DSS, an industry standard rather than a law. Applicability depends on the organization, data, and jurisdiction. Trade secrets, intellectual property, legal information, and financial information are also sensitive. Human-readable data can be read directly; non-human-readable data (databases, binary formats) needs tools.

Organizations apply classification levels so each level has a handling rule. Common commercial levels: public, internal (private), confidential, restricted. Government schemes add levels such as unclassified, confidential, secret, and top secret. Classification drives who may access data, how it is stored and transmitted, and how it is destroyed.

Roles you must know:

Data sovereignty and geolocation

Data sovereignty concerns applicable jurisdiction and legal authority over data. Storage location matters, but is not the only factor; provider arrangements and cross-border access can matter too. Data residency specifies where data is stored or processed. GDPR transfers outside the EEA require an applicable transfer mechanism, such as an adequacy decision or appropriate safeguards, with limited derogations in specific cases. An overseas region is not automatically unlawful, and selecting a region alone does not establish compliance.

2. Data states and protection methods

Methods to protect the data itself:

• Encryption: converts data so only holders of the key can read it. Key management is as important as the algorithm.
• Hashing: a digest can reveal changes when compared with a trusted reference. An attacker who can replace both data and its reference hash can defeat that comparison.
• Masking: hides parts of a value, for example showing only the last four digits of a card, while keeping the format.
• Tokenization: replaces a sensitive value with a substitute token. Vault-based designs keep the mapping in a protected service; other designs exist. Scope reduction depends on isolation, detokenization rights, and the complete data flow, not merely the presence of tokens.
• Obfuscation: makes data harder to interpret but is not a confidentiality guarantee. Pseudonymized data can still relate to identifiable people and remain personal data; do not equate it with effective anonymization.
• Segmentation: separating sensitive data into restricted networks or databases.
• Permission restrictions: least privilege on files, shares, and applications.
• Data loss prevention (DLP): policy tools that detect and block sensitive data leaving through email, uploads, or removable media.

Example 1: tokenization versus encryption

Scenario. An online store keeps card numbers for repeat purchases. The auditors want to reduce the number of systems in PCI DSS scope.

Reasoning. Encrypting card numbers keeps the systems in scope because the data can be decrypted. A suitable tokenization service lets the order database store payment tokens instead of card numbers. The vault, tokenization/detokenization components, and other systems that can affect payment-data security can remain in scope. A segmented token-only system may qualify for scope reduction after assessment. Do not assume the vault is the only in-scope component.

For trust, key handling, and integrity checks, see cryptography and public key infrastructure.

3. Data retention and disposal

A retention policy sets justified retention periods, applicable holds, and disposal rules. Select a sanitization method for the medium, sensitivity, and intended reuse. Degaussing applies to magnetic media, not SSDs. Overwriting addressable blocks may leave inaccessible flash regions. Cryptographic erase requires suitable encryption and sanitization of all relevant keys and copies; it does not remove separate plaintext exports. For cloud services, confirm provider deletion, backup, and key-lifecycle behavior. Record verification and custody evidence, including third-party certificates where applicable. NIST SP 800-88 Rev. 2 supersedes Rev. 1.

4. Resilience concepts

Resilience is the ability to keep operating, or return to operation quickly, after a failure or attack. Key terms:

• High availability (HA): design that minimizes downtime, often expressed as a percentage ("five nines" is 99.999%, about 5 minutes of downtime per year).
• Redundancy: duplicate components so that no single point of failure exists (power supplies, disks, network paths, servers).
• Load balancing: distributes requests across servers; failed nodes are removed from the pool.
• Clustering: servers work together; active-active shares load, active-passive keeps a standby that takes over on failure.
• Multipath networking, NIC teaming, and RAID: redundancy at the network and disk levels.
• UPS and generators: bridge short and long power outages.

RAID levels you may see

RAID protects against disk failure, not against deletion, ransomware, or corruption, so it is not a backup.

5. Backups

Backup types:

Best practices:

• Follow the 3-2-1 rule: three copies, on two different media types, with one off-site. Many now add 1 immutable or offline copy (3-2-1-1-0 with zero restore errors) to resist ransomware.
• Keep protected immutable or offline copies, with separate access controls. Verify who can change retention, delete keys, or access the backup plane; “immutable” is not a universal guarantee against every administrator or failure.
• Encrypt backups and protect their keys separately.
• Test restores regularly; an untested backup is a hope, not a control.
• Consider replication and journaling for point-in-time recovery. Synchronous replication waits for the required acknowledgments and can target zero loss of acknowledged writes within its failure model; latency and common dependencies matter. Asynchronous replication has a lag that must be monitored. Neither replaces historical, protected backups.
• Choose onsite for fast restore and offsite or cloud for disaster protection.

Example 2: choosing a backup scheme

Scenario. A file server has a Sunday full backup of 2,000 GB. Each of five weekdays adds 40 GB of distinct changed data, and a failure occurs after Friday’s backup completes. Restoring a set has 15 minutes of overhead; data restores at 800 GB/hour, with another 30 minutes for preparation and service checks. The RTO is 4 hours. These are illustrative measured-capacity assumptions.

Options.

• Incremental: each nightly backup copies 40 GB. Friday recovery needs Sunday’s full plus five incrementals: six sets and 2,200 GB total. Estimated recovery: 2,200 / 800 + 6 × 0.25 + 0.5 = 4.75 hours.
• Differential: Monday copies 40 GB; Friday copies 200 GB. Recovery needs the full plus Friday’s differential: two sets and 2,200 GB. Estimated recovery: 2,200 / 800 + 2 × 0.25 + 0.5 = 3.75 hours.

Decision. Under these assumptions, differentials meet the RTO and the traditional incremental chain does not. Confirm that the 200 GB Friday differential fits the backup window. Backup products with synthetic fulls, deduplication, parallel restore, or instant recovery may behave differently; choose using a measured end-to-end restore test.

6. Recovery objectives

The RPO constrains the age of the latest usable recovery point, including backup completion delays and replication lag. A 15-minute schedule alone does not prove a 15-minute RPO. The RTO constrains the complete restoration process: detection/activation as defined by the plan, recovery, dependencies, and service checks. Measure the design; labels such as “hot site” do not guarantee a time.

Worked example: matching objectives to design

Problem. An e-commerce platform has an RTO of 30 minutes and an RPO of 5 minutes. The current design takes nightly backups to tape and would need roughly 12 hours to rebuild.

Step 1. The RPO of 5 minutes means nightly backups lose up to 24 hours of data. Replication (or continuous journaling) at intervals under 5 minutes is needed.

Step 2. The RTO of 30 minutes rules out rebuilding from tape. An adequately provisioned standby or equivalent rapid-recovery design is needed; prove the 30-minute result in testing.

Step 3. Choose an active-passive cluster in a second availability zone or region with replication configured and monitored to preserve a usable recovery point no older than five minutes. Test promotion, routing, capacity, dependency recovery, and data consistency; health checks alone do not promote a database.

Step 4. Keep backups as a second layer for corruption or ransomware, because replication copies bad data too.

Why other choices are worse. More frequent tapes would still not meet the 30-minute RTO. A cold site cannot be brought up within 30 minutes. Replication alone can copy destructive changes or encrypted data; propagation speed depends on the configuration.

Relate these targets to the business impact analysis and risk register so recovery spending follows business priorities.

7. Site considerations

Also consider platform diversity (using different operating systems, vendors, or technologies so that a single flaw does not affect everything), multi-cloud, and capacity planning for people, technology, and infrastructure so that a failover site can carry the load.

8. Continuity of operations and testing

Business continuity planning (BCP) keeps essential functions running during disruption. A disaster recovery plan (DRP) restores IT after a disaster. A continuity of operations plan (COOP) keeps critical government or organizational functions available, including alternate facilities, communication, and succession of leadership.

Recovery is validated by testing, in increasing realism:

1. Tabletop exercise: discussion of a scenario, no systems touched.
2. Walkthrough: step-by-step review of procedures.
3. Simulation: scripted exercise of response with limited technical action.
4. Parallel processing: the recovery system runs alongside production to verify results.
5. Failover test: production is moved to the alternate system, the most realistic and riskiest.

After each test, record lessons learned and update the plan. Failover transfers service to a standby, and failback returns it once the primary is fixed.

Coordinate recovery with incident response and forensic evidence preservation before reconnecting affected systems.

9. Comparison: choosing the right protection

10. Common pitfalls

• Treating RAID or a current replica as a historical backup. Logical deletion and corruption can affect both copies.
• Confusing RTO (time to restore) with RPO (data loss tolerance).
• Choosing a hot site for a system whose RTO is a week; it is more expensive than needed.
• Encrypting backups but storing the key on the same system.
• Forgetting data sovereignty when picking a cloud region.
• Never testing restores, then discovering a corrupted backup during an incident.
• Confusing the data owner (accountable) with the custodian (implements).

11. Exam tips

• "Maximum acceptable data loss" is RPO; "maximum acceptable downtime" is RTO.
• "Reduce PCI scope" points to tokenization.
• "Partially hide" a value is masking; "reversible with a key" is encryption.
• "Ransomware resilience" points to offline, immutable, or air-gapped backups, plus tested restores.
• "Fast restore" means full backups; "short backup window" means incremental.
• Hot, warm, and cold are about readiness, and cost rises with readiness.
• Choose sanitization based on media and verified capabilities. Cryptographic erase is appropriate only when its encryption and key-sanitization prerequisites are met.

12. Mini case study

Case. Tailspin Legal has 80 staff and holds client case files (confidential), billing data, and personal data on EU clients. Backups run nightly to a NAS in the same room, with no encryption and no restore tests. A ransomware incident encrypts the file server and the NAS. The partners want a plan with an RTO of 4 hours for case files and an RPO of 1 hour.

Tasks. Recommend improvements.

Solution.

1. Classify data: case files and EU personal data as confidential/regulated; assign data owners (partners) and a custodian (IT).
2. Protect data: encrypt data at rest and backups, TLS in transit, DLP for email attachments, least-privilege access to case folders.
3. Backups: select backup/journaling intervals and monitor completion/lag so the latest usable point is no older than one hour. Combine a weekly full with the required incrementals and a protected offsite/offline or immutable copy. Test access separation and retention rather than assuming ransomware cannot reach it.
4. Keep key management separate from the backup system.
5. Recovery architecture: a warm standby or cloud-based restore environment sized for 4-hour RTO, with documented runbooks.
6. Sovereignty: choose a cloud region compliant with EU transfer requirements.
7. Test: set a risk-based schedule; a proposed starting plan is a quarterly tabletop and twice-yearly restore tests, plus testing after material changes. Measure the one-hour RPO and four-hour RTO; these frequencies are example policy choices, not universal requirements.
8. Remove single points of failure: add redundant power and disk (RAID plus UPS), while remembering RAID is not backup.

Key terms

• Data owner / custodian / steward: accountable, implementing, and quality roles.
• Data sovereignty / residency: applicable jurisdiction / specified storage or processing location.
• Masking / tokenization / obfuscation: ways to hide or replace sensitive values.
• DLP: detects and blocks unauthorized data exfiltration.
• HA, redundancy, clustering: designs that avoid single points of failure.
• RAID: disk redundancy and performance schemes.
• 3-2-1 rule: three copies, two media types, one off-site.
• RTO / RPO / MTTR / MTBF: recovery and reliability metrics.
• Hot / warm / cold site: alternate facility readiness levels.
• BCP / DRP / COOP: continuity and recovery plans.
• Failover / failback: switching to a standby and returning.

Summary checklist

• I can classify data and name the owner, custodian, and steward roles.
• I can protect data at rest, in transit, and in use and distinguish masking from tokenization.
• I can design HA with redundancy, load balancing, and clustering.
• I can compare full, incremental, differential, and snapshot backups.
• I can derive backup frequency from RPO and architecture from RTO.
• I can compare hot, warm, and cold sites.
• I can list recovery tests from tabletop to failover.

Sources

• CompTIA Security+ V7 objectives summary (opens in a new tab) — objectives 3.3–3.4.

• NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems: https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final (opens in a new tab)

• NIST SP 800-88 Rev. 2: media sanitization (opens in a new tab)

• CISA, Ransomware Guide: https://www.cisa.gov/stopransomware/ransomware-guide (opens in a new tab)

• PCI SSC: tokenization guidance and scoping considerations (opens in a new tab) — supplemental guidance; assess against applicable PCI DSS requirements.

• EDPB: international data transfers (opens in a new tab)