PR.DS-11: Backups of data are created, protected, maintained, and tested

PR.DS-11 sits in the “Protect” function and is one of the fastest ways an assessor will evaluate operational maturity: can you recover business operations and critical data after failure, ransomware, accidental deletion, or a third-party outage? The requirement is short, but it covers four distinct control outcomes: backups must be created, protected, maintained, and tested. If any one of those is weak, you still have material exposure.

For a Compliance Officer, CCO, or GRC lead, operationalizing PR.DS-11 means turning backup work (often treated as “IT’s job”) into a governed control with clear scope, ownership, minimum standards, and recurring evidence. You are not trying to perfect backup engineering. You are trying to make the program defensible: defined coverage, known restore objectives, strong protection against common failure modes (including ransomware), and repeatable testing with artifacts.

This page gives you requirement-level implementation guidance you can assign, track, and audit against. It maps PR.DS-11 into practical steps, evidence checklists, and common exam questions so you can move from intent to execution without guesswork. ¹

Regulatory text

Requirement excerpt: “Backups of data are created, protected, maintained, and tested.” ²

Operator interpretation (what you must do):

• Created: You define what data/systems require backup, how often backups run, and what backup types you use (full, incremental, snapshots). You then run those backups reliably.
• Protected: You prevent unauthorized access, deletion, encryption, or alteration of backup data and backup configurations. This includes designing for ransomware and insider risk.
• Maintained: You manage retention, storage health, key management (if encrypted), backup job monitoring, and lifecycle rules so backups remain usable over time.
• Tested: You prove you can restore. Testing must be planned, executed, documented, and tied to real recovery scenarios (system restore, file restore, database point-in-time restore, and bare-metal or image restore where relevant).

PR.DS-11 is satisfied only when you can demonstrate that backups exist for in-scope assets and that restores are feasible within your business requirements. ¹

Plain-English interpretation of the requirement

You need a backup program that survives real incidents. Backups that are “successful” in a dashboard but cannot restore critical applications, cannot meet recovery expectations, or are exposed to the same ransomware event do not meet the intent. Your program must cover:

• Scope: the right assets and data.
• Integrity and isolation: backups cannot be quietly corrupted or destroyed.
• Operational discipline: failures are detected and corrected.
• Recoverability: you can restore under time pressure.

A mature PR.DS-11 implementation treats backups as part of resilience, not an administrative task.

Who it applies to (entity and operational context)

Applies to: any organization operating a cybersecurity program, including regulated and non-regulated entities that align to NIST CSF 2.0. ¹

Operational contexts where PR.DS-11 is examinable:

• Production systems supporting revenue, client delivery, or safety.
• Regulated or sensitive data environments (PII, PHI, payment data, trade secrets).
• Cloud-first environments using SaaS/PaaS/IaaS (where shared responsibility can hide gaps).
• Organizations relying on third parties for hosting, managed services, data processing, or endpoint management (backup responsibilities must be explicitly assigned).

Control owners you should assign:

• Primary: Infrastructure/IT Operations or SRE (backup execution).
• Secondary: Information Security (backup protection standards, ransomware resilience).
• Accountable: System/data owners (scope and recovery expectations).
• Oversight: GRC/Compliance (control definition, evidence, audit readiness).

What you actually need to do (step-by-step)

Step 1: Define backup scope based on “crown jewels”

Create an inventory of what must be recoverable:

• Critical applications and their dependencies (identity, DNS, secrets vaults, configuration stores).
• Databases and file stores (including object storage buckets).
• End-user endpoints if business requires it (executive devices, engineering laptops, etc.).
• SaaS data you assume is “backed up by the provider” (confirm responsibilities).

Deliverable: “Backup Scope Register” that ties systems to data types, owners, and backup method.

Step 2: Set minimum backup and restore requirements per tier

Define expectations by tier (critical, important, standard). Keep it simple and enforceable:

• Recovery objectives (what “good” looks like for each tier).
• Restore methods required (file-level, VM/image, database PITR, configuration restore).
• Retention expectations aligned to legal, operational, and security needs.

Decision point: If business requirements demand rapid recovery, confirm your backup architecture supports it (snapshots, replication, immutable storage, warm standby). PR.DS-11 does not mandate a specific architecture, but your design must support your stated recovery outcomes. ¹

Step 3: Implement protection controls that survive ransomware

Protection is where many programs fail. Require, at minimum:

• Access control: separate roles for backup administration vs. system administration; MFA for backup consoles.
• Isolation: backups stored in an environment not reachable with the same credentials as production.
• Immutability or write-once controls: prevent deletion/encryption of recent backups by compromised accounts.
• Encryption: protect backup data at rest and in transit; manage keys with controlled access.
• Configuration protection: version control or secure change management for backup policies and scripts.

Practical check: If a domain admin account is compromised, can the attacker delete or encrypt your backups? If yes, you have a PR.DS-11 gap under “protected.”

Step 4: Operationalize “maintained” with monitoring and hygiene

Build daily/weekly operating routines:

• Monitor backup job success/failure and storage capacity.
• Track missed backups and enforce remediation SLAs.
• Periodically review retention rules and storage lifecycle policies.
• Validate encryption keys and restore credentials remain available during an incident.
• Manage backup agent versions and compatibility (especially across OS upgrades).

Evidence mindset: Maintenance must be visible. A backup platform with alerting but no tracked ticketing and closure often fails audits.

Step 5: Build a restore testing program that produces proof

Testing must be repeatable and scoped. Define:

• Test scenarios by asset tier (file restore, full system restore, database restore, application recovery runbook).
• Test frequency based on risk (critical assets more often).
• Success criteria (data integrity checks, application health checks, access validation).
• Documentation requirements (who ran it, what was restored, where, results, issues, remediation).

Minimum viable proof: a restore test that recreates the data/system from backups in a controlled environment and validates it functions as intended. PR.DS-11 explicitly includes “tested.” ¹

Step 6: Map PR.DS-11 to governance and recurring evidence

Turn technical activity into a control:

• Policy statement that commits to created/protected/maintained/tested.
• Procedure/runbook for backup operations and restore testing.
• Named control owner and backups “service owner.”
• Evidence calendar (what you collect and how often).
• Exceptions process (approved compensating controls, expiry dates, risk acceptance).

Daydream fits here as the system of record for control mapping, ownership, and recurring evidence collection, so audits do not depend on tribal knowledge.

Required evidence and artifacts to retain

Keep evidence that proves design and operation. A practical audit pack includes:

Governance

• Backup and Restore Policy mapped to PR.DS-11 ¹
• Backup Standard (scope, tiers, retention, protection requirements)
• RACI / named control owner and operators
• Exception register with approvals and expiry

Operational records

• Backup Scope Register (systems/data, owners, methods)
• Backup job reports (success/failure history) and alert/ticket trail
• Storage and retention configuration exports or screenshots
• Access reviews for backup admin roles (who has access, approvals)

Testing

• Restore test plan and schedule
• Completed restore test reports (steps, artifacts restored, validation results)
• Issues and remediation tickets with closure evidence
• Post-incident restore evidence if a real event occurred (what was restored, time to restore, gaps found)

Common exam/audit questions and hangups

Assessors tend to ask questions that expose weak scope and weak testing:

1. “Show me your backup scope.” If you cannot list systems and owners, you will argue from memory.
2. “How do you protect backups from ransomware?” Expect follow-ups on immutability, separation of duties, and privileged access.
3. “Prove restores work.” Screenshots of a backup console are rarely enough; they want restore outcomes and validation.
4. “What happens when backups fail?” They will look for monitoring, escalation, and tracked remediation.
5. “Who owns this control?” “IT does it” is not an ownership model.

Frequent implementation mistakes and how to avoid them

• Mistake: Backing up servers but not SaaS data. Fix: document SaaS responsibilities and add third-party backup or export processes where needed.
• Mistake: One set of credentials can destroy both prod and backups. Fix: isolate backup admin roles, require MFA, and implement immutability.
• Mistake: Tests restore files but never restore applications. Fix: define tier-based scenarios; require at least one end-to-end application recovery test for critical services.
• Mistake: Retention is undefined or inconsistent. Fix: set retention by tier and data class; enforce via policy in the backup platform.
• Mistake: Evidence is scattered across tools and inboxes. Fix: centralize evidence collection and ownership tracking in your GRC workflow (Daydream can automate reminders and evidence requests).

Enforcement context and risk implications

No public enforcement sources were provided for this requirement in the materials you supplied, so this page does not list specific cases. Practically, weak backups drive high-impact outcomes: prolonged outages, permanent data loss, inability to recover from ransomware without paying, and breach notification complications if you cannot determine what data was affected. PR.DS-11 is often indirectly tested during incident response readiness reviews because restore capability determines containment and recovery options. ¹

A practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Assign control owner and technical service owner for backups.
• Build the Backup Scope Register for critical systems first.
• Document minimum backup standards: protection requirements, retention by tier, and restore expectations.
• Identify single points of failure (shared admin credentials, no immutability, no monitoring) and open remediation work.

Next 60 days (Operationalize and harden)

• Implement or validate isolation, MFA, and immutability controls for backup repositories.
• Turn monitoring into action: alerts create tickets; tickets close with root cause.
• Run restore tests for critical systems and capture full evidence packages.
• Create an exceptions workflow with approvals and expiry dates.

By 90 days (Audit-ready control)

• Expand scope to remaining systems and SaaS data sources.
• Establish a recurring restore testing cadence tied to asset tiers.
• Complete an access review for backup administrative roles and document approvals.
• Publish a PR.DS-11 control narrative: scope, architecture summary, operating procedures, and evidence locations.

(These phases are sequencing guidance, not source-quoted time requirements.)

Frequently Asked Questions

Do SaaS providers “count” as my backups for PR.DS-11?

Sometimes, but you must confirm what the provider backs up and what they will restore for you. Document shared responsibility and make sure your recovery needs are met with either provider capabilities or your own exports/third-party backups. ¹

What’s the minimum acceptable restore test?

A test that restores a representative in-scope system or dataset from backup media into a controlled environment and verifies integrity and usability. Keep a signed test record with results and remediation actions. ¹

How do I show backups are “protected” in an audit?

Provide evidence of access controls (role assignments, MFA), isolation or separate administrative domains, immutability/write-once settings where applicable, and encryption settings with controlled key access. Pair configuration evidence with access review artifacts.

Can I meet PR.DS-11 if I only back up databases and not servers?

Possibly, if your recovery design can rebuild servers from code and configuration (IaC) and restore the databases and required state. Document the recovery approach and test it as an end-to-end restore scenario. ¹

How should third parties be handled in backup scope?

Treat third parties as part of your system boundary where they store or process your data. Contractually define backup, retention, restore timelines, and evidence you can request, then test your ability to recover from a third-party failure scenario.

What evidence is most often missing during audits?

Restore test records and proof of remediation after failed backups or failed restores. GRC teams also get flagged when ownership and scope are unclear, even if backups technically exist.

Footnotes

1. NIST CSWP 29

2. NIST CSWP 29; NIST CSF 1.1 to 2.0 Core Transition Changes