Data Protection and Resilience: Backups, Continuity, and Classification

Attackers do not chase VLAN diagrams—they chase records. Regulators and customers do not care that your firewall had a clever rule if payroll data walks out the door. Outages punish the same institution from another angle: no backups, no continuity plan, no tested restore—and ransomware becomes a business-ending event instead of a bad week.

SY0-701 Domain 3 expects you to protect data in every state, classify it correctly, and keep operations alive when systems fail. This post ties those threads together with scenarios, continuity vocabulary, and exam traps that separate strong answers from plausible distractors.

Data states: rest, transit, and use

Security controls must match how data exists at the moment you apply them. A control that works at rest may do nothing in transit or while an analyst has a spreadsheet open.

Data at rest

Data at rest sits on disk, tape, object storage, databases, mobile devices, or backup targets. Typical controls:

• Full-disk encryption (FDE) and volume/file encryption
• Database encryption (TDE-style concepts) with key separation
• Tokenization and data masking for environments that should not hold live PAN/SSN
• Access control lists, RBAC, and physical security for media

Why it matters: Stolen laptop stems often test FDE plus strong auth—not "change password after theft" alone when the disk is unencrypted.

Data in transit

Data in transit moves across networks—web sessions, API calls, email, VPN tunnels, replication between sites. Controls include TLS 1.2+, IPsec VPN, SSH, secure email gateways, and certificate validation (no blind trust of self-signed certs in production paths).

Exam trap: "We use HTTPS" while internal east-west traffic remains plaintext on a flat network—attackers who pivot internally still read it.

Data in use

Data in use is actively processed—CPU registers, memory, analytics pipelines, shared screens. Controls are harder and appear at medium depth:

• Least privilege so only necessary processes touch sensitive fields
• DLP on endpoints and cloud apps to block paste/export
• Browser isolation for risky web workflows
• Confidential computing concepts (TEE/enclaves)—hardware-assisted isolation for processing sensitive data in untrusted cloud infrastructure

Scenario: A support agent views customer records in a web app. Mitigations: role-based app authorization, session timeout, DLP blocking download to personal device, logging access—not merely VPN to the app.

The table below summarizes; read it as a mapping exercise, not a memorization grid.

Each row should trigger "what breaks if we only encrypt at rest?"—often insider misuse and live session hijack.

Classification drives handling

Data classification labels information by sensitivity and legal requirements—common tiers include public, internal, confidential, and restricted/secret (exact names vary by policy). Classification answers:

• Who may access or store it
• Whether encryption is mandatory
• Whether data may leave a geography
• Retention and secure deletion requirements
• Whether DLP rules apply

Worked example: Public marketing brochures vs employee performance reviews. The latter is confidential/internal—should not live on consumer cloud file sync without CASB/DLP and contractual controls.

Exam scenario: Executives email board decks via personal webmail. Failures: lack of sanctioned tools, missing DLP, weak training, absent classification. Mitigation path: approved collaboration platform, DLP blocking external send of tagged documents, executive coaching—not "block all email."

Privacy and regulatory alignment

GDPR-style objectives appear heavily in Domain 5, but architecture enables compliance: encryption, access logs, retention limits, right-to-erasure workflows, data minimization in design. If you cannot locate personal data across systems, you cannot delete or protect it.

Exam trap: Choosing "encrypt everything" when the stem asks for data minimization or retention reduction—encryption protects confidentiality; it does not reduce unlawful collection.

Continuity vocabulary that exams reuse

Business and IT continuity terms blur in practice; SY0-701 uses them with specific nuance.

RTO (Recovery Time Objective) — maximum acceptable downtime before service must return.

RPO (Recovery Point Objective) — maximum acceptable data loss measured in time (how fresh backups must be).

Scenario: Payroll must run within 24 hours; losing more than 1 hour of payroll edits is unacceptable. RTO = 24h, RPO = 1h. Backup frequency and hot standby design follow from those numbers—not the other way around.

Exam trap: Confusing RTO with RPO. Memory hook: RPO is about points of data (how much you lose); RTO is about time to be online.

Backups as a security control

Backups defend against ransomware, accidental deletion, and corruption—but only when implemented with security properties exams now emphasize:

1. Regular tested restores — untested backups are wishful thinking
2. Offline or immutable copies — ransomware cannot encrypt what it cannot reach
3. Access control on backup infrastructure — backup admins are high-value targets
4. Separate credentials/domain — do not store backups where domain compromise wipes them too
5. Retention aligned with RPO and legal hold requirements

3-2-1 rule (three copies, two media types, one offsite) is study-guide common sense; exams may push immutable object storage, tape air gap, or replication with snapshot isolation.

Exam trap: "We replicate to a hot site" when replication mirrors encrypted files in real time—you replicated the ransomware too. Need point-in-time recovery and isolated snapshots.

Backup scenario walkthrough

Stem: Ransomware encrypts file servers Friday 6 p.m. Backups run nightly to NAS on the same AD domain; snapshots are visible from file admin accounts.

Failures: Shared domain trust, no offline/immutable tier, backups not isolated from compromise path.

Strong response: Isolate infected systems, preserve evidence if required, restore from clean immutable/offline backup predating infection, rebuild identity if domain is untrusted, test sample restore before mass recovery, communicate via BCP tree.

Weak response: "Pay ransom immediately" or "Reboot servers."

Resilience patterns beyond backups

Resilience keeps services available through component failure—not only full disaster.

• Redundancy — dual power, NIC teaming, RAID (know RAID is not backup)
• Clustering — active/active or active/passive app tiers
• Load balancing — distribute traffic; health checks remove bad nodes
• Geographic diversity — survive site loss (earthquake, regional cloud outage)
• Failover ordering — restore dependencies first (DNS, identity, databases before apps)

High availability without security discipline duplicates vulnerabilities—patch both nodes, harden both, monitor both.

Scenario: Hospital imaging must stay online. Clustering for app tier, geo-redundant storage, documented manual downtime procedures if automatic failover fails—all align with availability as CIA pillar.

Secure techniques for computing resources

Domain 3 also expects secure deployment and hardening themes applied to servers, virtual machines, containers, and applications:

• Remove default accounts and passwords
• Disable unnecessary services and ports
• Apply vendor benchmarks (CIS-style baselines)
• Patch on cadence with change control
• Use secure protocols; retire TLS 1.0/1.1 and weak ciphers
• Secrets management—not environment variables in images
• Secure SDLC touches: input validation, code review, dependency scanning

For applications, architecture meets development: parameterized queries, output encoding, security testing before production, separation of dev/test/prod data (no real PII in dev).

Exam trap: "Air-gap dev environment" when the issue is production data in dev—minimization and masking beat physical drama.

Mini scenarios with full answer paths

1. Legacy systems with slow patching

Stem: OT network cannot patch monthly; vendor certifies firmware once per year.

Answer thread: Segment OT from IT, monitor protocol anomalies, virtual patching/IPS at boundaries, jump host access with MFA, contractual vendor SLAs, document compensating controls in risk register—not mandatory immediate patch.

2. Shadow cloud storage

Stem: Sales stores customer contracts in personal cloud sync.

Answer thread: CASB discovery, sanctioned SaaS, DLP blocking upload of classified docs, MDM on corporate devices, training, classification policy—not only "fire the rep" without preventive controls.

3. Regulatory audit of personal data

Stem: Auditor asks how you delete user data on request across CRM, data warehouse, and backups.

Answer thread: Data inventory/map, retention schedules, crypto-shredding or deletion workflows, legal hold exceptions documented, backup expiry aligned with policy—shows privacy by design, not ad hoc SQL deletes.

4. Site loss

Stem: Flood destroys primary datacenter.

Answer thread: Execute DRP, fail over to warm/hot site per RTO/RPO, activate BCP comms, validate integrity of restored data, post-incident review—BIA priorities guide restore order (customer-facing payment portal before internal wiki).

Media sanitization and end of life

Secure disposal appears in operations objectives but belongs architecturally: where data rests on hardware determines wipe methods.

• Clear — logical overwrite (risky for high sensitivity alone)
• Purge — stronger logical or degauss
• Destroy — physical destruction for top tiers

Lost laptops with unencrypted drives combine data at rest failure with disposal/loss scenario—FDE and remote wipe reduce impact.

Putting the triad together

When a stem mentions "architecture" and data, ask three questions:

1. Where does sensitive data live (including backups and SaaS)?
2. Who can reach it (identity, network path, admin roles)?
3. How do we survive losing a site, a platform, or a weekend of systems?

That triad carries most Domain 3 data and resilience questions. Classification tells you how serious the data is. Encryption and DLP enforce confidentiality. Backups, RTO/RPO, and DRP/BCP enforce availability and recovery. Least privilege and logging support integrity and accountability.

Exam traps recap

Study drill

For each asset you imagine (email, ERP, customer PII database, IoT sensor logs), write:

• Classification tier
• Controls at rest, in transit, in use
• RTO/RPO if business-critical
• Backup type (offline/immutable? tested?)

Five minutes per asset beats re-reading glossary lists. Data protection and resilience are not separate topics—they are how your architecture proves it deserved the name "secure."