What NIS2 point 4.2 requires for backups and redundancy
Point 4.2 of the Annex to Implementing Regulation (EU) 2024/2690 asks an entity to keep backup copies of its data and to hold enough resources, including facilities, systems and staff, for an appropriate level of redundancy. In practice, an essential or important entity must be able to show a supervisor that it can recover its data and services after a ransomware attack, the loss of a site or a corrupted copy, and that it has tested this rather than assumed it. The owner of this obligation is the entity's management, which must approve the backup plan and the risk assessment behind it. An implementation partner can configure the backup systems and collect the evidence, but only the entity can decide its recovery targets and accept the residual risk.
The backup plan has to set recovery times, cover complete and accurate copies (including configuration data and data held in cloud environments), store copies in safe locations off the system's network and far enough from the main site, control access to them, and define restoration and retention periods. Many backup programs fail in practice for a simple reason: copies are written every night, but no one has restored a full system from them. Corrupted or incomplete copies, missing configuration files and backup credentials stored on the same domain as production usually surface only during an incident. Ask your team to name the last date a complete system was restored from backup and where the record of that test is kept.
Two checks follow from that. First, run integrity checks on backup copies on a regular schedule. Tools such as restic can verify repository structure and, with --read-data or --read-data-subset, read pack files back to confirm stored data is unmodified. Second, run recovery tests and record the results and any corrective actions, because ENISA's June 2025 guidance expects restore test records, checksum or hash settings and a backup plan review that refers to the 3-2-1 rule as examples of evidence. Redundancy under the same point also covers partial spare capacity for systems, facilities, supplies, competent staff and communication channels, sized from the risk assessment and business continuity plan, so confirm that each of these has a named alternative.
Which systems, data and facilities fall under the backup requirement
Point 4.2 applies to more than the main database. The scope follows from the risk assessment and business continuity plan, which decide which systems, data, configuration, third-party holdings and facilities must survive a failure and how quickly they must come back.
Production data and business-critical records
Start with the data the organization cannot rebuild: customer records, transaction logs, operational databases and document stores that the services in scope depend on. Point 4.2.2 requires complete and accurate copies, so the inventory should record each data set, its owner, its recovery time and its retention period. Check that every production system in the asset inventory has a named backup job, and that a restore has been tested against it.
Configuration data and system state
Backups of data alone do not rebuild a service. Firewall rules, identity settings, container definitions, infrastructure-as-code and application configuration files are needed to restore systems to a working state. Point 4.2.2 names configuration data explicitly. Confirm that configuration repositories and appliance settings are captured on a schedule that matches the recovery times set in the business continuity plan.
Cloud-hosted and SaaS-held data
Point 4.2.2 extends the backup plan to data in cloud environments. Virtual machines, object storage, managed databases and snapshots often sit outside the organization's own data center, and the provider's default retention may not match the plan. Confirm which copies the organization controls, where they are stored, and whether a restore can run without the provider's console being available.
Third-party and supplier-held data
Data held by managed service providers, SaaS vendors and outsourced processors still falls within the organization's continuity obligations. Contracts should state what the provider copies, where copies are stored, how long they are kept and how a restore is requested and tested. Ask suppliers for their most recent restore test results and confirm that the organization holds an independent copy of any data it cannot afford to lose.
Facilities, staff and communication channels
Point 4.2.4 requires at least partial redundancy of systems, facilities, supplies, competent personnel and communication channels, based on the risk assessment and business continuity plan. Identify the sites, key roles and communication paths that would stop a restore if they failed, such as a single operator who alone knows the recovery procedure. Document the fallback for each, and test that the backup site and alternate contacts work.
Risk assessment and business continuity plan as inputs
The risk assessment and business continuity plan set how much redundancy each system needs. A service that the continuity plan marks as having a short tolerable outage needs warm or hot redundancy, while a low-impact archive may need only a tested restore from off-site copies. Record the criticality rating and recovery target for each system so that the scope, the backup frequency and the redundancy level can be traced back to a documented decision.
How an assessor tests backup and redundancy
The assessor starts with the written backup plan and checks whether it answers the questions point 4.2.2 of the Annex to Implementing Regulation 2024/2690 raises. The test is a document review followed by a walkthrough with the owner: does the plan state recovery times, which systems and data it covers, where copies go, who can access them and how long they are kept? The assessor then compares the plan with the business continuity plan and the risk assessment, since the backup scope should follow what the organization has classified as critical. Typical gaps include plans that list systems the environment no longer runs, recovery times that were never agreed with the business owners, and no mention of configuration data or cloud-hosted data.
- Recovery objectives: Each in-scope system has a stated recovery time and an owner who accepted it.
- Scope completeness: Configuration data, identity stores and cloud-hosted data appear in the plan, not only file servers.
- Retention and access: Retention periods and the people allowed to restore or delete copies are written down.
- Review record: The plan shows a dated review that refers back to the 3-2-1 approach or an equivalent rule.
Check that the plan matches the systems in the current asset inventory and that the owner can explain every scope exclusion.
The assessor then checks what the backup tooling actually does. This test compares the job schedules, retention settings, storage targets and access controls in the running system with the plan. Backup software logs and job reports are the primary evidence, and the assessor usually asks for a sample of jobs over a period rather than a single successful run. Open-source tools such as Bareos keep a catalog of job history, and restic repositories hold snapshot metadata, so both can show which copies exist and where. Gaps tend to be jobs that silently fail, copies that never leave the primary network, and backup administrators who hold unrestricted rights to the repository.
- Job history: Logs cover a sample period with failures, reruns and their causes recorded.
- Off-network copies: Storage targets are shown to sit outside the production network and at a distance from the main site.
- Administrative access: Backup administrators are separate from production administrators, and deletion rights are limited.
- Coverage matching: Every host or data source in the asset inventory has an active backup job.
Check that the configuration export and the plan describe the same schedules, retention periods and locations.
Point 4.2.3 expects regular integrity checks on backup copies, so the assessor looks for proof that stored data can still be read and has not been altered. The test asks which checks run, how often, what they cover and what happens when one fails. Checksums or hashes recorded at write time and verification jobs are the usual evidence. restic can check structural consistency of repositories and, with its read-data options, read pack files back to confirm the stored data is unmodified. Gaps include checks that only confirm a file exists, checks that run on a subset of data without a stated rationale, and no record of what happened after a failed check.
- Check scope: The check type, such as structural or full data read, is named for each repository.
- Frequency: The check schedule is documented and the run history is available.
- Hash evidence: Checksum or hash settings are shown for the copies in scope.
- Failure handling: Failed checks create alerts, tickets and a documented corrective action.
Confirm with the tool vendor which verification options the installed version supports before the assessment.
Point 4.2.6 requires regular recovery tests, and this is the area where assessors most often find the largest gap. The test asks for dated restore records that show a real restoration was performed, from which copy, to which target, how long it took and whether the result matched the recovery objective. The assessor compares these records with the recovery times in the plan and checks whether the systems tested are the critical ones. Bareos can restore files from the current backup or from one selected by date and time, which gives a traceable restore record when the job is logged. Typical gaps are tests that only restore a single test file, no corrective actions after a slow or failed restore, and tests limited to systems that are easy to recover.
- Test records: Each restore has a date, source copy, target, operator and outcome.
- Critical systems: Tests include the systems with the shortest recovery objectives.
- Measured times: Actual recovery durations are compared against the stated objectives.
- Corrective actions: Shortfalls lead to documented fixes and a retest.
Ask for the last full set of restore records and the actions that followed each finding.
Point 4.2.4 asks for at least partial redundancy of systems, facilities, supplies, competent personnel and communication channels, based on the risk assessment and business continuity plan. The assessor reviews architecture diagrams and the business continuity plan, then asks how each redundant element is kept working. Monitoring evidence matters here, so the assessor may ask for alerting on backup and replication health. Prometheus collects metrics over HTTP and Grafana Alerting can combine metrics and logs in alert rules, which can show whether a secondary component is up. Gaps include a standby site that has never been tested, single points of failure for staff or communication channels, and redundancy that the risk assessment did not justify.
- Design traceability: Each redundant component links to a risk or business continuity requirement.
- Partial coverage: The scope of redundancy is stated, including what is not duplicated and why.
- People and channels: Named alternates and backup communication routes are documented.
- Health monitoring: Alert rules show whether secondary systems and replicas are functioning.
Check that the redundancy design, the business continuity plan and the risk assessment reference the same components.
How to implement point 4.2 in sequence
The sequence turns the business continuity plan into recovery objectives, a written backup plan, protected copies, verified backups and tested restores. Each step leaves a record that an assessor can trace back to point 4.2 of the Annex to Implementing Regulation 2024/2690.
Derive recovery objectives from the business continuity plan
Start from the business continuity plan and the risk assessment, and identify which services, data sets and configurations matter most. For each one, record the recovery time the business needs and the maximum data loss it can tolerate. Agree these figures with the system owners, not only the IT team, because they drive every later decision. Output: a signed recovery objectives register that maps each critical system to its recovery time and acceptable data loss, with the approving owner named.
Write the backup plan
Document what is backed up, how often, by which tool, and where copies go. The plan must cover complete and accurate copies, including configuration data and data held in cloud environments, along with access controls and retention periods. Name the people responsible for running and reviewing backups. Output: a versioned backup plan, approved by management, that a supervisor can read without a walkthrough. Confirm that the plan refers to the 3-2-1 rule if you adopt it, since ENISA lists a review against that rule as evidence.
Set up off-site and off-network copies
Configure at least one copy stored in a safe location outside the system's network and far enough from the main site to survive the event that affects production. Restrict access to these copies with separate credentials and keep them outside the production administrative domain. Tools such as Bareos keep a catalog of backed-up files, and restic stores encrypted repositories that can be placed in a separate location. Output: a storage configuration record, network diagram showing the copy location, and access logs proving that only authorized accounts can reach it.
Configure integrity checks on backup copies
Enable checks that confirm backup copies have not been corrupted or altered. For restic, the check command verifies structural consistency, and the read-data option reads pack files back to confirm stored data is unmodified. Set checksum or hash settings in the backup software and schedule these checks on a regular basis. Route failures to an alert channel so they are investigated. Output: the job configuration files, a schedule record, and sample check logs showing both passing runs and any failure handled.
Schedule regular restore tests
Define a test calendar that restores representative data and full configurations to an isolated environment, not the production system. Cover each critical system in the recovery objectives register at least on the schedule the risk assessment sets. Measure the actual restore time and compare it with the recovery time objective. Output: restore test records that state the system tested, the date, the restore point used, the measured duration, the person who ran the test, and the pass or fail result.
Monitor backup jobs and alert on failures
Use monitoring to show that backup, verify and archive jobs complete as scheduled. Prometheus can collect job metrics over HTTP, and Grafana Alerting can build rules from those metrics and from logs in one view. Set alerts for missed jobs, failed checks and storage that is filling. Output: alert rule definitions, a dashboard export, and a record of each alert with the action taken, which later supports the corrective action evidence.
Document corrective actions and review the plan
Record every failed integrity check, failed restore test or missed recovery time, along with the root cause and the fix. Assign an owner and a closure date for each corrective action, then verify the fix with a follow-up test. Review the backup plan and recovery objectives after significant changes or test failures, and record the review. Output: a corrective action log linked to the test records, and a dated plan review with the approver named. Confirm with your assessor how often they expect the review to occur.
Evidence that satisfies point 4.2 and how to keep it current
ENISA's June 2025 guidance lists the records an assessor will ask for under point 4.2. Each artifact below proves a different part of the backup and redundancy duty, and each needs a dated history rather than a one-time snapshot. The cards cover what to keep, how to refresh it between audits, and how to link failures to corrective actions.
Backup software job logs
Export the job logs from the backup scheduler for every system in scope, covering backup, verify and restore jobs. Confirm that logs show which systems were backed up, when, whether the job succeeded, and which failures were investigated. In Bareos, the Director and its SQL catalog hold this history, so check that catalog retention is long enough to cover the audit period. Review failed jobs weekly and record the ticket that closed each one.
Proof of off-site copies
Keep records showing that copies sit outside the system's network and far enough from the main site. Document the storage location, the access path, and the account model that protects the copy from the production domain. Re-check the record whenever a storage target, region or provider changes. Ask whether the copy would survive loss of the primary site and of the production identity provider, since point 4.2.2 requires both separation and distance.
Checksum and hash settings
Capture the integrity mechanisms in use and their configuration. For restic, record the output of restic check and whether scheduled runs include --read-data or --read-data-subset, since structural checks alone do not prove the stored data is unmodified. For other tools, record the checksum algorithm and where digests are stored. Store the configuration in version control so every change has an author and a date.
Restore test records
Maintain a dated log of restore tests that names the system, the backup used, the recovery time measured against the target in the business continuity plan, and the person who verified the result. Include tests of configuration data and cloud-hosted data, which point 4.2.2 explicitly covers. When a test fails or misses the recovery time, link a corrective action with an owner and a closure date. Tests of partial redundancy, such as failover of a single node, belong in the same log.
Backup plan review and 3-2-1 rule
Review the backup plan on a set schedule and after any major change to systems or facilities. Record the review date, the approver, and changes made. The plan should state how many copies exist, on how many media types, and how many are off-site, which is the basis of the 3-2-1 rule that ENISA cites as evidence. Ask whether the plan also covers recovery times, retention periods and access controls, since assessors test each of those elements.
Alerts and corrective action tracking
Evidence of current backup health depends on alerting that reaches people who act. Build alert rules that fire on missed backup jobs, failed verifications and stale off-site copies, using Grafana Alerting across the backup and monitoring data sources. Prometheus can supply metrics on job age and duration. Link each alert to the ticket that resolved it, so the audit trail shows detection, response and closure. Confirm alert routing and escalation paths before relying on them as evidence.
What meeting point 4.2 costs in money and effort
This table breaks down the cost components of meeting point 4.2 of the Annex to Implementing Regulation 2024/2690, showing who is paid for each, whether it is one-time or recurring, and what drives it up. Read it as a checklist for requesting a quote, because no supplied figures exist for these costs and every amount depends on your own data volumes, sites and recovery targets.
| Cost component | One-time or recurring | Who is paid or who carries it | What drives the cost |
|---|---|---|---|
| Off-network and off-site storage capacity | Recurring | Cloud or data center provider, or internal storage team | Total retained data, retention periods, number of copies and distance to the main site |
| Backup software, licenses or self-hosted operation | Mostly recurring if licensed, one-time for deployment | Software vendor for licenses; your team or an implementation partner for self-hosted operation | Number of protected systems, cloud workloads and whether support contracts are required |
| Engineering time for initial setup | One-time | Internal platform engineers or a fixed-scope implementation partner | Number of systems in scope, configuration data coverage and cloud environments to integrate |
| Integrity checks and monitoring setup | One-time setup, recurring operation | Internal operations staff, with alert tooling if self-hosted | Frequency of checks, volume of backup data read back and alert routing to on-call staff |
| Recurring restore testing staff time | Recurring | Internal operations and system owners | Number of systems tested, test frequency set by your risk assessment and recovery time targets |
| Redundancy resources (facilities, systems, staff) | Largely recurring | Your organization, including standby capacity and trained personnel | Criticality of services, required level of partial redundancy and communication channel alternatives |
| Evidence upkeep and backup plan review | Recurring | Compliance lead, system owners and, if engaged, a readiness consultant | Number of backup plans, frequency of review and how logs and test records are retained |
| External review and readiness support | Usually one-time, sometimes repeated | Independent consultant or implementation partner; the organization keeps ownership | Current maturity, gaps found in review and whether a pre-assessment is requested |
| Auditor or authority sampling | Recurring per assessment cycle | Independent auditor or national competent authority | Number of systems sampled, depth of evidence requested and quality of records on hand |
Who owns backup controls and who can prepare the evidence
The organization owns point 4.2. Its management body approves the risk-based backup and redundancy decisions, its named staff set recovery objectives, and its operators run restore tests and sign off the results. Outsourcing can cover building and operating the tooling, but not the accountability for whether backups can be restored when needed. Under the Article 21 framework, the organization must be able to show who decided what and when.
- Recovery objectives: Management and business owners set recovery times and acceptable data loss, based on the risk assessment and business continuity plan.
- Backup plan ownership: An accountable named role approves the backup plan, retention periods and access controls, and reviews them on a set cycle.
- Restore testing: Internal staff schedule and witness recovery tests, and record results and corrective actions.
- Evidence custody: The organization keeps backup software logs, off-site copy records, hash or checksum settings and test records in its own retained evidence store.
- Redundancy decisions: Staff decide which systems, facilities, supplies, skills and communication channels need partial redundancy.
Check that each of these items has a named internal owner, not only a vendor contact.
An implementation partner can design, build, configure and document the backup and monitoring stack inside the organization's own infrastructure, then prepare the evidence that point 4.2 expects. Typical work includes writing scripts, configuring schedules, setting up off-network copies, wiring integrity checks into alerting, and executing restore tests under a written runbook. The partner prepares systems and evidence. It does not decide the organization's risk acceptance, and it does not certify the outcome.
- Build and configuration: Installing and configuring backup directors, storage targets and repositories, such as Bareos or restic, according to the agreed design.
- Scripting and automation: Writing scheduled verification jobs and alert rules, for example in Prometheus and Grafana, that surface failed checks.
- Restore test execution: Running documented recovery exercises on request and capturing logs, timings and outcomes for the organization to review.
- Documentation: Drafting the backup plan, runbooks and evidence index for the organization to approve.
- Handover: Transferring operational knowledge so the organization can run checks without the partner.
In the statement of work, confirm which deliverables are one-time build work and which are recurring operation or retainer support.
An independent auditor, assessor or national competent authority tests whether point 4.2 is implemented and effective. NIS2 creates no certificate for this, so the outcome is a supervisory finding, an audit opinion or a certification body result, depending on the scheme the organization is using. The assessor needs to be separate from the people who built the backup system, and the organization should not expect a partner to act as its assessor.
- Sampling and walkthroughs: Assessors select backup jobs and restore records, then trace them to logs and off-site copy evidence.
- Integrity verification: Assessors may ask how checksum or hash settings are applied and whether integrity failures were investigated.
- Independence limits: An implementation partner that built or ran the restore tests should not also rate their effectiveness in the assessor's report.
- Authority requests: National competent authorities can request information, run inspections or security audits under the NIS2 supervision framework.
- Report issuance: Only the independent party issues the formal audit report, attestation or certification.
Before engaging any assessor, confirm its accreditation or competence for the scheme in question, and confirm what it will test directly.
Where organizations fall short on backup and redundancy
Most backup programs look complete on paper and fail in the first real recovery. The gaps below recur across sectors, and each one maps to a specific expectation in point 4.2 of the Annex to Implementing Regulation (EU) 2024/2690. Each card ends with the check to run before an assessor asks.
Backups that were never restored
Many teams can show a job log reporting success but cannot show a restore. Point 4.2 expects regular recovery tests of backups and redundancies, with results documented. Ask for the date of the last full restore of a production system, who ran it, how long it took against the recovery time in the plan, and what failed. If no restore record exists, run one on a non-production copy and file the result.
Copies on the same network or site
A backup stored on the same network segment as the systems it protects can be encrypted or deleted by the same attack. Point 4.2.2 requires storage in safe locations off the system's network and far enough from the main site. Confirm where each copy physically and logically sits, which credentials can delete it, and whether at least one copy is isolated from the production administrative domain.
Configuration and cloud data left out
Backup scopes often cover application data but skip device configurations, firewall rules, identity settings and SaaS or cloud-hosted data. Point 4.2.2 expects complete and accurate copies that include configuration data and data in cloud environments. Compare the backup scope against the asset inventory and check that a restore rebuilds a working service, not only its files.
Integrity checks that never run
Teams often assume that a backup that completed is usable. Point 4.2.3 requires regular integrity checks on backup copies. Confirm that checksum or hash settings are enabled, that verification jobs run on a schedule, and that failures generate alerts rather than silent log entries. Keep the verification output, since it is evidence an assessor will ask to see.
No documented corrective actions
Organizations often find restore failures during tests and fix them informally, leaving no trace. Points 4.2.3 and 4.2.6 require results and corrective actions to be documented. Maintain a simple register with the test date, the finding, the owner, the fix and the retest date. A closed finding without a retest is a weak record, so require both.
Redundancy for people and channels
Redundancy planning usually covers servers and storage but ignores the staff who run recovery and the channels used to coordinate it. Point 4.2.4 requires at least partial redundancy of competent personnel and communication channels, based on the risk assessment and business continuity plan. Check that at least two trained people can execute each restore, and that the team can reach each other and suppliers if the primary messaging system is down.
Questions buyers ask about backup and redundancy under NIS2
How much does it cost to meet backup and redundancy requirements under NIS2?
No supplied source gives a price for this work, so the cost depends on the scope you agree in writing. The main components are the backup and restore tooling (much of it open source), the storage and facilities you add for off-network and off-site copies, the hours of staff time to design, test and document the process, and any outside help you buy. One-time costs include the initial design, the first restore tests and the documented backup plan. Recurring costs include storage, monitoring, periodic restore tests and plan reviews. Ask any provider for a quote that separates these components, states which systems and data sets are in scope, and names who performs each restore test. Confirm with your national competent authority or auditor which evidence they expect before you size the storage.
How long does it take to implement NIS2 backup and redundancy controls?
The timeline depends on how many systems, data stores and cloud environments fall within scope, how much of the backup design already exists, and whether off-site or off-network copies need new infrastructure. Work usually runs in sequence: a review of the risk assessment and business continuity plan, the backup plan, the first full restore test, and then the recurring checks. Fixed-scope engagements have their deliverables and dates agreed in writing before work starts, so ask for that schedule rather than a generic estimate. Your own recovery time objectives will also set how quickly restores must be proven. Confirm with your auditor how much operating history they expect before they accept your restore test records as evidence.
What does backup and redundancy work need from our internal staff?
Your staff must own the decisions that NIS2 makes management responsible for. These include the recovery times for each critical service, the retention periods, who may access backups, which locations count as safe and far enough from the main site, and how much redundancy the business continuity plan requires. Engineers must be available to confirm which systems hold data, to provide access for configuration backups, and to take part in restore tests. Expect a named owner for the backup plan and a named reviewer who signs off on test results and corrective actions. An implementation partner can prepare the systems and draft the documents, but the organization approves them and keeps them current.
Can we run NIS2 backup and redundancy controls in-house?
Yes, an in-house team can meet point 4.2 if it has the skills to design backups, run restores and keep records, and if management accepts ownership of the outcome. Open-source tools such as Bareos, restic and the Grafana and Prometheus monitoring stack can produce the logs, catalog entries, check results and alerts that auditors ask for. Outside help is most useful for the initial design, for an independent review before an assessment, or for documenting the process in a form an assessor can follow. Whichever route you choose, agree the scope and deliverables in writing and confirm that the staff who run restore tests can show their records.
How often should we run restore tests under NIS2?
The implementing regulation requires regular recovery tests of backups and redundancies, with results and corrective actions documented, but it does not set a single fixed interval in the facts supplied for this page. Set the frequency in your own documented policy, based on your risk assessment, the criticality of each system and your recovery time objectives. Test more often for critical systems and after major changes, and record each test, its outcome and any fix. Confirm the interval your national competent authority or auditor expects, because some will ask to see a history of tests rather than a single success.
What does an assessor ask first about our backups?
Assessors usually start with the documents that show what you intend to do, then ask for proof that you do it. Expect requests for the backup plan, including recovery times, retention periods and access controls, and for the business continuity plan that sets the redundancy you need. They will then ask for backup software logs, evidence of off-site copies, checksum or hash settings, restore test records and a review of the backup plan. ENISA's June 2025 guidance lists these as examples of evidence, and it refers to the 3-2-1 rule as a reference point. Confirm with your auditor how they want the evidence packaged before the assessment begins.
How do open-source tools help us prove backups work?
Open-source tools produce the raw evidence, but they do not decide whether your controls are adequate. Bareos keeps a SQL catalog of backed-up files and supervises backup, restore and verify jobs, which gives you job logs and restore records. restic's check command verifies the structural consistency of snapshots and, with the read-data options, reads pack files back to confirm that stored data is unmodified, which supports integrity checks. Grafana Alerting and Prometheus can raise alerts when backup jobs fail or stall, and the alert history becomes part of your evidence. Confirm each tool's current behavior and licence terms in your own environment before you rely on them in an assessment.
How DeployOpen scopes and prepares backup evidence
DeployOpen scopes a backup and redundancy engagement in writing before any work starts, and the scope begins with the systems a supervisor would expect to see covered: the systems in scope of the risk assessment and business continuity plan, the cloud environments that hold data, and the configuration data needed to rebuild each service. The client confirms recovery time objectives and retention periods for each system, and states where copies must sit off the system's network and far enough from the main site. Those decisions belong to the organization. DeployOpen's role is to turn them into a documented design, a deliverables list and a timeline that the client can check against its own requirements before signing. Ask for the scope to name each backup target, each restore scenario that will be tested, and who on the client side approves the retention and access choices.
Implementation runs inside the client's own cloud accounts, data centers or air-gapped networks. For example, a team might deploy Bareos on infrastructure it controls, with the Director scheduling backup, verify and restore jobs and its SQL catalog recording what was backed up, while a separate repository such as restic holds encrypted copies that can be checked with its check command, including --read-data-subset for periodic sampling. Access controls on the backup server and repository, and the separation of backup administrators from the systems they protect, are configured and documented as part of the delivery. Alerting on failed or missing jobs can be built with Grafana Alerting on metrics from Prometheus. Confirm with the vendor and your own environment which storage targets, encryption settings and retention features your chosen tools support.
Restore tests are scheduled and run against the documented recovery objectives, with results, timings, failures and corrective actions recorded in the same evidence set. DeployOpen then assembles that evidence for your own assessor: backup software logs, off-site copy records, checksum or hash verification output, restore test records and a review of the backup plan. DeployOpen prepares systems, controls and evidence only. It does not issue audit reports, attestations or certifications. Those come from independent auditors or certification bodies, and the organization remains accountable for its controls and for what it tells its national competent authority. Ask any partner, DeployOpen included, to state in writing which parts of the evidence it produces and which parts the organization or its auditor must review.
