PR.DS-11 Backups: requirements and evidence

What PR.DS-11 backups requirements mean for your recovery program

PR.DS-11 asks that backups are created, protected, maintained and tested. If an auditor, a customer questionnaire or a board member asks whether your data can be recovered, this Subcategory is the outcome they are checking against. Having a backup job that reports success is not enough on its own. The outcome covers whether the copy exists, whether an attacker or an error can reach it, whether it stays current, and whether you have proven that it restores. The risks it targets are ransomware that encrypts or deletes reachable copies, accidental or malicious deletion, silent corruption, and loss of an entire site or region. NIST's Implementation Examples describe four practices: near-real-time backup of critical data with scheduled backup of everything else, testing backups and restores for all data sources at least annually, keeping some backups offline and offsite, and enforcing geographic separation for backup storage. PR.DS-11 takes over CSF 1.1 PR.IP-4 under a new identifier, so programs that already mapped that earlier Subcategory will need to update their references.

The hardest part is usually not buying storage. It is proving recoverability. Restores that were never tested tend to fail at the first real attempt because of missing keys, outdated configurations, incomplete catalogs or slow rebuild steps. Backups are also often reachable from the production identity: the same administrator account, service account or directory role that can change production data can often delete or overwrite the backup repository. A practical starting point is to list every critical system and its backup job, record the recovery point each one actually achieves, and confirm which credentials can alter or delete each copy. Then schedule a restore of a representative system and time it. Ask your implementation partner and your own backup owner to confirm how many copies exist, where the offline or immutable copy sits, and who signs off the test results.

Open-source backup tools can produce much of this evidence, but they do not decide the policy. Bareos, for example, schedules backup, restore, verify and archive jobs and keeps a SQL catalog of what was backed up, which gives you job history and restore records to show an assessor. restic offers a check command that verifies snapshot, tree and pack file consistency, and with --read-data or --read-data-subset it reads pack data back to confirm the stored content is unmodified. Those checks support integrity testing but do not replace a full restore exercise of your own systems. Confirm with the tool documentation and your own environment which features meet your retention, immutability and separation requirements, and keep a written record of who approves the restore tests and how often they run. Assessors look for that record as much as for the tooling.

Which systems, data and teams fall inside PR.DS-11 scope

PR.DS-11 asks whether backups are created, protected, maintained and tested, so scope is set by where critical data lives and who can touch the copies. The cards below cover the decisions that change the work most: data classes, environments, SaaS data, backup administrators, third-party providers and copy locations. Each one determines which backups must exist, how they are protected and what evidence an assessor will ask for.

Critical versus non-critical data classes

Start by classifying data by how much its loss or unavailability would hurt the business. NIST's Implementation Examples for PR.DS-11 separate near-real-time backup of critical data from scheduled backup of other data, so the classification sets the backup frequency and the restore priority. Ask the data owners which datasets would stop operations or breach obligations if lost, and record the answer. An unclassified estate forces every dataset into the most expensive tier or leaves critical data under-protected.

Production and non-production systems

Backups are usually designed for production, but development, test and staging systems also hold copies of real data, and their backups are often missed. Decide whether each non-production environment is in scope, and whether its backups follow the same retention and restore-test rules. Systems that receive production extracts inherit the sensitivity of that data. Confirm the inventory of environments with platform owners before scoping restore tests.

SaaS and cloud-hosted data

Email, collaboration suites, code repositories and hosted databases often sit outside the organization's own infrastructure, and the provider's built-in retention is not the same as a backup you can restore from on your own terms. Decide whether to export or replicate this data into systems you control, and confirm what the provider covers, how long deleted items persist and how a restore is requested. Document each service in scope and the mechanism that protects it.

Backup administrators and their identities

Anyone who can run, change or delete backup jobs can also destroy the recovery path, so backup administrators belong inside the access scope. Name the accounts that can start restores, alter schedules, change retention or reach the catalog, and require separate credentials for backup and daily administration. Review these accounts with the same rigor as production privileged access, and record who approved each restore.

Third-party backup providers

When a managed backup service or cloud vendor holds copies, the organization still owns the outcome in PR.DS-11, so the provider's controls become part of the assessment. Determine which party runs the job, which party holds encryption keys, where the data is stored and what the contract requires for restore testing and notification. Obtain the provider's restore test results or reports and confirm the terms that govern deletion at exit.

Locations where copies are held

The Implementation Examples call for some backups to be offline and offsite and for geographic separation of backup storage. Each location, whether a secondary data center, cloud region, tape vault or air-gapped network, is a separate scope decision. Record the physical or logical distance between copies, the network path that connects them and who can reach each one. A copy in the same facility or the same administrative domain as production may fail when a single incident strikes both.

How an assessor tests PR.DS-11 backups

This table lists the tests an assessor is likely to run against PR.DS-11 and the evidence each one asks for. Read each row as a question the assessor will put to the backup program, and use the common findings column to check your own records before the assessment starts.

Test area	Test approach	Evidence requested	Common findings
Schedule against critical data	Compare the backup schedule with the inventory of critical data and confirm near-real-time or scheduled coverage for each dataset (illustrative: a database absent from the job list)	Current critical data inventory, backup job definitions, schedule exports and coverage reports	Critical systems added after the last inventory update have no backup job
Sample restore tests	Select a sample of systems, restore them to a test environment and compare results with expected data, noting the date of each test	Dated restore test records, sign-off, restored data checks and the list of systems tested	Restore tests run once at deployment and never repeated, or only file-level restores tested
Restore testing cadence	Confirm that restore tests cover all data sources at least annually, as the CSF Implementation Examples describe	Annual test plan, calendar of completed tests and remediation tickets for failed restores	Some data sources are excluded from the test plan without a documented reason
Offline or immutable copies	Check whether at least some backups are offline or protected against change and deletion, and test whether an administrator account can alter them	Storage configuration, immutability or air-gap settings, retention policy and access logs	Backup repository is writable from production credentials, so an attacker can delete copies
Geographic separation	Verify that backup storage sits in a location separate from production and is not affected by the same local event	Storage locations, data center or cloud region records and replication configuration	Primary and secondary copies share a building, site or single cloud region
Access control on backup systems	Review who can log in to backup servers, change schedules, delete backups or restore data, and whether those rights are reviewed	Access lists, role definitions, privileged access approvals and review records	Backup administrators share accounts or retain access after role changes
Failed job handling	Sample failed or partial backup jobs and trace each to an alert, a ticket and a rerun or documented acceptance	Job failure reports, alert records, tickets and rerun logs	Failures appear in logs but nobody is notified, so gaps go unnoticed for weeks
Integrity verification	Check whether stored backup data is verified by periodic reads or checksums, not only by job completion status	Verification job reports, checksum records and verification schedules	Jobs report success but no one has checked whether the stored data can be read back

Implementing PR.DS-11 backups in five steps

This sequence turns the PR.DS-11 outcome into a working backup program: it starts from a list of critical data, sets how often each class is backed up and how long copies are kept, protects and separates the copies, and ends with restore tests whose results are recorded for an assessor.

Identify critical data from the asset inventory
Start from the asset inventory maintained under ID.AM, which should list systems, data stores and the data flows between them. The asset owner and the business owner of each system confirm which data is critical, meaning data whose loss or corruption would stop operations, breach obligations or cause material harm. Record each data class with its owner, location and the systems that depend on it. The output is a signed-off backup scope list. You know this step is done when every critical data store in the inventory maps to a named owner and a data class, and anything excluded from backup has a documented reason.
Set backup frequency and retention per data class
For each data class, decide how close to real time backups must run and how long copies are kept. NIST's Implementation Examples for PR.DS-11 call for near-real-time backup of critical data and scheduled backup of other data, so the frequency for critical classes is set by the business's tolerance for data loss, while other classes can run on a schedule. Retention periods should reflect legal, contractual and operational needs and be confirmed with legal and compliance owners, since no general retention figure applies to every organization. The output is a backup policy table listing frequency, retention and owner for each class. You know this step is done when every class in the scope list has both values and an approver.
Design protected, offline and offsite copies
Design the backup architecture so that backups are protected from the systems they protect. This includes separate credentials for backup servers, restricted network paths, encryption of backup data, and at least some copies kept offline or offsite, as the Implementation Examples describe. Enforce geographic separation for backup storage so that a single site event cannot destroy all copies. Open-source platforms such as Bareos, whose Director schedules and supervises backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files, or restic, which stores encrypted repositories, can support these patterns, but the team should confirm each capability against its own version and environment. The output is an architecture diagram and a configuration baseline. You know this step is done when a reviewer can trace each critical data class to at least one protected copy outside the primary failure domain.
Schedule and run restore tests
Schedule restore tests so that backups are tested for all data sources at least once a year, which is the annual cadence in the PR.DS-11 Implementation Examples. Each test should restore a defined sample from each data class to an isolated environment and compare the result with the expected state. Integrity checks support this step: restic's check command verifies the structural consistency of snapshots, trees and pack files, and with --read-data or --read-data-subset it reads pack files back to confirm the stored data is unmodified. Bareos verify jobs and file restores from a chosen date serve a similar purpose. The team should assign an owner for each test and keep the test calendar in the change system. The output is a test plan and a completed first test run. You know this step is done when every data source has a scheduled test and the first run has been completed.
Record results and retain evidence for audit
Record each backup job outcome, each restore test result and each exception in a location the assessor can access. For every restore test, keep the date, scope, operator, restored data sample, comparison method, duration observed, pass or fail result and the corrective action for any failure. Keep the backup policy, scope list and architecture records under version control so the assessor can see what was approved and when. Open-source platforms can produce job logs and catalog reports that support this evidence, but the organization decides what is retained and for how long. The output is an evidence pack for each test cycle. You know this step is done when an independent reviewer, given only the evidence pack, can confirm that a named restore test ran, what it covered and what happened afterward. Independent auditors or certification bodies decide whether the evidence meets any framework requirement.

Backup architectures that meet the requirement

This model copies backups to tape or removable disk, then physically moves some of that media off the network so an attacker with domain access cannot reach it. PR.DS-11 expects some backups to be offline and offsite, so the rotation schedule and the transport log are central evidence. Geographic separation depends on where the vault or secondary site sits relative to the primary data center.

Offline copies: Media is disconnected from the network between backup windows, and the rotation register records when each cartridge or disk left and returned.
Offsite storage: A contracted vault or a second company site holds the rotated media, with access logs and environmental controls documented.
Geographic separation: Confirm the distance and independent failure domains with your own risk team, since the Implementation Examples describe separation without a fixed distance.
Operating cost: Recurring costs include media refresh, vault fees, courier services and staff time for rotation and label checks. Ask vendors and vaults for quotes that separate one-time hardware from recurring handling.
Restore testing: Physical media can degrade, so schedule restores from rotated copies and record results.

Before relying on this model, confirm with your auditor how they will sample rotation logs and whether the vault agreement meets your separation expectations.

Why a restore test matters more than a successful backup job

A green backup log proves that a job ran and wrote data somewhere. It does not prove that the data can be read back, that the application can start from it, or that the restored system matches what the business needs. PR.DS-11 asks whether backups are tested, and a restore test is the only step that answers that question directly. The organization should treat the backup job report as the start of evidence, not the end of it. The CSF Implementation Examples for PR.DS-11 call for testing backups and restores for all data sources at least annually, and the first decision is which systems that test must cover.

Scope the restore test to critical systems first. Start from the recovery priorities already set for the organization, such as the systems that must return first after an outage or ransomware event, and pick a sample that includes a database, a file share, a configuration store and at least one system whose backup is handled by a different team or tool. For each, record the recovery point achieved, the time taken, the person who ran the restore, and whether the application passed a functional check afterward. Restores into an isolated network are preferable to restores over production paths, so the test does not reintroduce malware or overwrite live data. Confirm with the backup platform owner how restores are performed and logged in your environment.

An integrity check and a restore answer different questions. An integrity check confirms that the backup repository is internally consistent, while a restore confirms that a usable system or file comes back. In Bareos, the Director schedules verify jobs alongside backup and restore jobs, and restores can select files from the current backup or from one before a given date and time, which lets the team test point-in-time recovery. In restic, restic check verifies the structure of snapshots, trees and pack files, and adding --read-data or --read-data-subset reads pack files back to confirm the stored data is unmodified. These are useful evidence, but the organization must confirm in its own environment which options run, how often, and how long they take on its data volumes.

Evidence that passes a PR.DS-11 backups review

An assessor testing PR.DS-11 looks for a chain of records: the policy sets the rules, the mapping shows what is covered, the logs prove jobs ran, and restore tests prove the data comes back. Each artifact below answers one link in that chain, and the gaps usually appear where the links do not match.

Backup policy and schedule

The written policy states which data is backed up, how often, how long copies are retained and who approves changes. It should separate near-real-time backup of critical data from scheduled backup of other data, which mirrors the Implementation Examples NIST publishes for PR.DS-11. Check that the schedule in the policy matches the schedules configured in the backup tool, and that the policy carries an owner, a version and a review date. A policy that describes a schedule nobody runs is a common finding.

Data-to-job mapping

A mapping table links each critical data source, such as databases, file shares, configuration stores and SaaS exports, to the backup job that protects it. Assessors use it to find data that has no job, which is the gap that surfaces during an incident. Keep the mapping tied to the asset inventory so new systems trigger a backup decision. Ask for the mapping as a current export, not a diagram drawn for the audit.

Job logs and failure alerts

Job logs show when each backup started, finished and failed, with the data volume and the catalog entry it produced. Failure alerts show that someone was told when a job did not run and what happened next. Retain the logs for the period the assessor samples, and include a sample of failed jobs with their tickets and resolution dates. In Bareos, the Director keeps a catalog of backed-up files, which gives assessors a queryable record of what each job captured.

Restore test records with date and scope

A restore test record names the system restored, the backup set and point in time used, the person who ran the test, the date and whether the restored data matched the source. NIST's Implementation Example calls for backup and restore testing for all data sources at least annually, so assessors check both the frequency and the coverage. A test that restored one file from one server does not show that a full system can be rebuilt. Record failures and the corrective action as well.

Offline and immutable copy evidence

Evidence of offline or immutable copies shows that at least some backups cannot be altered or deleted by a compromised production account. This can be a tape rotation log, a write-once storage configuration, or an object lock setting with its retention period. Ask for the configuration export and a record of who can change it. Restic's check command can read pack files back to confirm stored data is unmodified, and its output is useful evidence that copies were verified, not just written.

Offsite location and access records

Location records name where each backup copy is stored, including its region or facility, and show that the copy is separated from the primary site as the geographic separation Implementation Example requires. Access records list who can read, restore or delete backup storage, with recent access reviews. Confirm that backup administrators are not the same accounts that administer production without oversight. Update the location register whenever a storage provider or region changes.

What meeting PR.DS-11 backups costs in money and effort

This table lists each cost component of a PR.DS-11 backup program, who is paid for it, whether it is one-time or recurring, what drives it up, and how to keep it down. Use it to build a quote request, since no price or duration is published for this work and every figure depends on your data volumes, recovery targets and environment.

Cost component	One-time or recurring	What drives it	How to keep it down
Backup software or licenses	Recurring if commercial, none for open source	Commercial licensing often scales with protected capacity, hosts or agents. Self-hosted open source such as Bareos (AGPL-3.0-only) and restic (BSD-2-Clause) removes license spend, but confirm that your use of AGPL-3.0-only code meets your legal review.	Compare total cost of ownership, including support contracts, and check license terms with counsel before choosing open source.
Storage hardware or cloud capacity	One-time for on-premises hardware, recurring for cloud capacity	Volume of critical data, backup frequency, retention periods and the number of retained restore points.	Set retention by data criticality, deduplicate where the tool supports it and review capacity against actual growth.
Offsite and geographic copies	Recurring	Number of separate sites or regions, transfer volume, egress charges and the need to keep copies outside the primary geographic zone.	Limit offsite copies to critical data sets, and confirm with the business owner which regions are acceptable.
Offline or immutable copies	One-time setup, recurring media or storage	Choice of tape, detached disk or immutable storage, and how often copies are rotated and checked.	Automate rotation and document the procedure so it does not depend on one person.
Engineering time for design	One-time	Number of data sources, recovery point and recovery time objectives set by the business, and integration with existing platforms.	Define scope in writing before work starts, and reuse one backup standard across systems.
Annual restore test effort	Recurring, at least annually	Number of data sources and systems tested, whether tests are full or sampled, and whether application owners must validate results.	Script restore tests where possible, and use restic check with read-data options or Bareos verify jobs to reduce manual checking.
Evidence upkeep	Recurring	Frequency of backup job reports, restore test records, change records and the number of systems in scope.	Export job logs and test records automatically into a single evidence location with consistent naming.
External review	Recurring or one-time, depending on engagement	Whether an outside party reviews design, scope or test results before an assessment. This is advisory work, since NIST does not offer certifications for CSF implementations.	Ask for a fixed-scope review with written deliverables rather than an open-ended retainer.
Auditor sampling	Recurring, per assessment cycle	Number of backup jobs, restore tests and periods the auditor samples. Confirm sampling expectations with your independent assessor before testing begins.	Keep one consistent record per backup job and restore test so samples can be pulled quickly.

Open-source backup tools that produce PR.DS-11 evidence

Two open-source tools cover different parts of the PR.DS-11 outcome. Bareos runs scheduled backup and restore jobs and records what was backed up, while restic checks that stored backup data can still be read and has not changed. Both are candidates to confirm against your own environment, not drop-in answers.

Bareos Director scheduling and supervision

The Bareos Director schedules and supervises backup, restore, verify and archive jobs. For PR.DS-11, the schedule is the record of whether critical data is backed up as often as your recovery requirements demand. Export job history and failure logs to show that backups ran on time and that failures were investigated. Confirm that the Director's job definitions match the backup frequencies your organization has approved, including the near-real-time tier for critical data.

SQL catalog of backed-up files

Bareos keeps a SQL catalog of the files it has backed up. An assessor who asks which systems were covered, and when, can be shown this catalog rather than a reconstructed spreadsheet. Protect the catalog itself as a critical asset: it should be backed up, access-restricted and stored where a single incident cannot destroy both the data and the record of it. Confirm the catalog's database backup and retention settings in your environment.

Point-in-time restore selection

Bareos can restore files selected from the current backup or from a backup taken before a given date and time. This supports the restore side of PR.DS-11, where a team must recover data as it stood before a ransomware event or accidental deletion. Restore tests should select an earlier point in time on purpose, record what was restored, and compare the results with known-good data. Confirm that retention periods allow the earliest recovery point your business requires.

restic check for structural integrity

The restic check command verifies the structural consistency of snapshots, trees and pack files. It shows that the repository's index and metadata agree, which is useful evidence of repository health between restore tests. Run it on a schedule, keep the output, and treat any reported error as an incident to investigate. Check does not by itself prove that file contents are recoverable, so it should be paired with the read-data option below.

restic read-data verification

With --read-data or --read-data-subset, restic reads pack files back to confirm the stored backup data is unmodified. A full read-data run is the strongest direct check that backed-up bytes can still be retrieved, but it takes time and bandwidth on large repositories. A common approach is a subset check on a rotating schedule, with a full run at a defined interval. Confirm the interval against your storage costs and the restore-test cadence you have committed to.

restic licensing and fit

restic is licensed under BSD-2-Clause, which permits use in commercial environments without the copyleft obligations that apply to AGPL-3.0 software such as Bareos. Licensing is not the same as fitness for purpose. Confirm that restic's supported storage back ends, encryption choices and repository key management meet your offsite and geographic separation requirements, and that your team has a documented procedure for handling repository passwords and keys.

Who owns PR.DS-11 and what a partner can take on

PR.DS-11 is an outcome your organization must achieve, so your team keeps the accountable decisions even when an outside partner builds the backup systems. The decisions that cannot be delegated are the ones that define what the backups are for: which data is critical, how long each data set must be retained, and who approves a restore when production data is at stake. Your auditor will ask who made these decisions and whether they are written down.

Data classification: Decide which systems and data sets are critical, which need near-real-time backup, and which can follow a scheduled cycle.
Retention decisions: Set how long each backup set is kept, based on legal, contractual and business requirements.
Restore approvals: Name the people authorized to approve a restore, and define what they must check before approving.
Control ownership: Assign a named owner for the backup control, the restore test schedule and the evidence trail.
Review of results: Review restore test outcomes and decide on remediation when a test fails.

Before engaging anyone, confirm that these decisions exist in writing and that a named person can answer for each one.

An implementation partner such as DeployOpen can prepare and operate the technical side of backups inside your own infrastructure, under a written scope agreed before work starts. The partner does not decide what data is critical or who may approve a restore, and it does not issue any assurance statement about your controls. Its output is working systems, documentation and evidence that your team and your auditor can examine.

Backup configuration: Prepare backup jobs, schedules and catalogs in self-hosted tools, for example Bareos, which schedules backup, restore and verify jobs and keeps a SQL catalog of backed-up files.
Restore test support: Run restore tests against your decisions and record the results, including integrity checks such as those in restic's check command with --read-data or --read-data-subset.
Offline and offsite copies: Set up storage separation and geographic placement as scoped, and document where each copy lives.
Runbooks: Write restore and backup runbooks that your staff can follow without the partner present.
Evidence assembly: Collect job logs, test records and configuration exports into an organized evidence set.

Ask for the written scope to list each deliverable, the environments covered and who signs off on the evidence.

Where PR.DS-11 backup programs usually fall short

Most backup programs have copies of data, but fail when an assessor asks whether those copies can be restored, whether an attacker could destroy them, and whether the proof survives outside the tool. The cards below cover six gaps that recur across PR.DS-11 reviews, each with a closing action the organization can take before an assessment starts.

Restore tests never run or never written down

Backup jobs report success, so teams assume recoverability. PR.DS-11 expects backups and restores to be tested for all data sources at least annually, and an assessor will ask for the most recent restore test, what was restored, how long it took and who signed off. A job log showing a green status is not a restore test. Schedule a restore of a representative system into an isolated environment, record the result, and keep the record with the date and the approver.

Backup admin credentials reachable from production

When the same directory accounts that administer production can delete or alter backup repositories, a single compromise can destroy both the live data and its recovery path. This is a common route in ransomware incidents. Check whether backup administrators use separate accounts, whether the backup server is joined to the production identity domain, and whether deletion requires a second approver. Document the answers, because an assessor will test them.

No offline or immutable copy

A backup that can be overwritten or deleted by the account that wrote it does not protect against an attacker who has that account. PR.DS-11 Implementation Examples call for keeping some backups offline and offsite. Confirm that at least one copy sits on media or storage that production credentials cannot modify within the retention window, such as tape held off site or repository storage with write-once retention. Record the retention setting and test that a deletion attempt fails.

Copies in the same region or account

Replicating backups to a second bucket in the same cloud account, or to a second rack in the same data center, protects against hardware loss but not against account compromise, regional outage or a site event. PR.DS-11 calls for geographic separation of backup storage. Map where each copy lives, including the cloud account, region, and physical site. If every copy shares one administrative boundary, the program has one point of failure.

Critical data missing from backup scope

Backup scope is usually defined by the systems the infrastructure team manages, while critical data often lives in places nobody lists: SaaS exports, developer databases, configuration repositories, endpoints used by finance, or file shares created by a business unit. Reconcile the backup job list against the asset inventory and the data classification. Near-real-time backup is expected for critical data, so any critical dataset on a nightly or weekly schedule needs a documented reason.

Evidence that exists only in tool dashboards

A backup console can show job history, retention and restore logs, but those screens are rarely retained in a form an auditor can sample. Assessors need evidence they can keep: exported job reports for the period, restore test records, change records for schedule and retention changes, and access reviews for backup administrators. Decide which exports are produced on a fixed schedule and where they are stored, and confirm with the independent assessor which format they accept.

PR.DS-11 backups questions buyers ask

How much effort does it take to meet PR.DS-11?

Effort depends mainly on how many systems hold critical data, how often that data changes, and how much of the backup chain already exists. PR.DS-11 asks that backups be created, protected, maintained and tested, and NIST's Implementation Examples describe near-real-time backup of critical data, scheduled backup of other data, at least annual testing of backups and restores for all data sources, some offline and offsite copies, and geographic separation. The first pass is usually the heaviest: you inventory data sources, set recovery expectations, configure jobs, and document them. After that, the recurring work is monitoring job results, running restore tests, and reviewing storage locations. Ask any partner to split its estimate into one-time setup and recurring operation so you can compare it with your own staffing.

How long does a first restore test cycle take?

No duration is fixed by NIST for a first restore test cycle, so the answer depends on your environment. The length is driven by the volume of data to restore, the number of data sources in scope, whether restores can run in an isolated environment, and whether staff must rebuild dependent systems before a test is meaningful. NIST's Implementation Examples call for testing backups and restores for all data sources at least annually, which sets the minimum frequency rather than the duration. Before you commit to a schedule, confirm with your team how long a restore of your most critical system has taken in practice, and ask any implementation partner to state in writing what the test covers and what it produces.

Can a small team meet PR.DS-11 without outside help?

Often yes, if the environment is small and the team has backup administration skills. NIST's Small Business Quick-Start Guide (SP 1300, February 2024) cites PR.DS-11 when it suggests that small businesses back up data regularly and test the backups, which shows the outcome is meant to be reachable at small scale. The harder parts are usually the ones people skip: keeping an offline or offsite copy current, separating backup storage geographically, and proving that restores actually work. Open-source tools such as Bareos, which schedules backup, restore and verify jobs and keeps a SQL catalog of backed-up files, and restic, whose check command can read pack files back to confirm stored data is unmodified, can support these tasks. Confirm your team can own job monitoring and restore testing before deciding.

What should I ask a partner to include in a quote?

Ask for a written, fixed scope that names each system, data source and backup target in scope, the recovery behavior expected for each (near-real-time for critical data, scheduled for the rest), the restore test method and frequency, and the offline, offsite and geographic separation design. A credible quote also states who operates each part after handover. Request separate line items for one-time setup, documentation, and any recurring support or testing retainer, and ask what is excluded. DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables agreed in writing before work starts. DeployOpen does not publish a price list, so the quote follows from the written scope.

Does NIST certify that we comply with PR.DS-11?

No. NIST does not certify organizations, products, implementations or services against the Cybersecurity Framework, and it has no plans to develop a conformity assessment program, according to its CSF FAQs. NIST is also not a regulatory agency, and most organizations use the CSF voluntarily, though some customers or suppliers require it. In practice, you show alignment through your own documented evidence, such as backup policies, job reports and restore test records, and a customer may ask for an independent assessment of that evidence. Only an independent assessor or certification body issues a formal report or certificate for a particular standard, and DeployOpen prepares systems and evidence for assessments without issuing them. Check with your customer which independent assessment, if any, they accept.

How does PR.DS-11 relate to ISO 27001 Annex A control 8.13?

The CSF 2.0 Reference Tool lists ISO/IEC 27001:2022 Annex A control 8.13 as an informative reference for PR.DS-11, so the two point at closely related backup expectations. Annex A control 8.13 is titled information backup, and its control ID and title are the reliable reference points for your ISO 27001 work. PR.DS-11 is a Subcategory of the CSF, which is a voluntary framework without certification, while ISO/IEC 27001 is a certifiable management system standard that an accredited certification body can audit. One body of evidence can often serve both, but the mapping is a reference, not an equivalence, so confirm with your certification body how it will assess backups. Also check the CSF 2.0 Reference Tool, which NIST publishes, for the current mapping.

How DeployOpen works on this

DeployOpen plans and implements self-hosted open-source backup platforms inside your own infrastructure, then prepares the backup configuration, restore testing and records that PR.DS-11 evidence depends on. We do not issue attestations or certifications; an independent auditor or certification body makes that determination.

How we scope

Engagements are fixed-scope, with the systems, data sources and backup targets agreed in writing before work starts.
The written scope names which critical data gets near-real-time backup and which data gets scheduled backup.
Scope also records offline, offsite and geographically separated copy locations, and who owns each one.

How we build

We configure backup schedulers and catalogs, such as Bareos, to run and supervise backup and restore jobs.
We set up repository verification, such as restic check with read-data options, to confirm stored backups are unmodified.
We document retention, encryption and access controls for backup storage so the configuration can be reviewed by an assessor.

How we hand over

Deliverables include the backup configuration, job schedules and a documented restore test procedure for each data source.
We record restore test results and verification output so you hold evidence of the annual testing NIST describes.
Handover covers operator runbooks and a mapping from each control artifact to the PR.DS-11 Implementation Examples.

How we support

Ongoing support, upgrades and continuous testing of backup systems are available as retainers.
Retainers can cover recurring restore tests and review of backup logs and verification reports.
Confirm with us in the quote which assessment cycle, evidence owners and review dates the support will follow.