A.8.13 Information backup: requirements and evidence

What A.8.13 information backup asks for and why restores fail audits

A.8.13 requires that backup copies of information, software and systems are maintained and regularly tested in line with an agreed topic-specific policy on backup. If your backup policy exists but nobody has restored a system from it in living memory, an assessor will ask for proof that the copies work, and a policy document alone will not answer that question. The control exists because a backup that cannot be restored gives no protection. Ransomware, accidental deletion, failed storage and corrupted databases all reach the point where the organization needs a usable copy, and at that point an untested backup is simply an assumption.

The control is hard to run because ownership is split. Infrastructure teams often run the backup platform, application teams know which databases need consistent snapshots, and business teams decide how far back data must be recoverable. When each group assumes another one owns the restore test, nobody runs it. Confirm who owns the backup schedule, the retention settings, the encryption keys for backup media and the restore test for each system in scope, and record those owners in the policy. Assessors usually look for a named owner and dated test records, not a generic statement that backups are taken.

A.8.13 is separate from A.8.14 (redundancy of information processing facilities) and A.5.30 (ICT readiness for business continuity). A replicated system is not a backup, because a fault or a bad change can replicate to the copy within seconds. A tested failover shows that service can move to another site, but it does not show that the data in a restored state is correct. Plan separate evidence for each: a dated restore of a named dataset into a clean environment, with a checked result, for backups, and a failover exercise record for redundancy.

Which systems, data and backups fall under A.8.13 information backup

A.8.13 applies to backup copies of information, software and systems, so the scope starts with an inventory of what the organization must be able to recover. The cards below cover the decisions that most often change the backup design: which data stores matter, where a third party holds the copy, and how the backup system itself is protected.

Production data stores

Databases, file shares, object storage and message queues that hold the organization's operational information are the core of A.8.13 scope. Recovery objectives and data classification decide how often each store is copied and how long copies are kept. A store holding regulated or customer data usually needs a stricter schedule than an internal reporting database. Confirm with system owners which stores support business processes and what data loss each process can tolerate. Include any store that is updated outside the main application, such as scheduled exports or analytics copies.

Configuration and software images

Server builds, infrastructure as code, container images, configuration files and license-bound software media are needed to rebuild systems, not only to restore their data. A backup of data alone may not allow a system to run again after a loss. Decide which build artifacts are stored in version control and which must be copied to a separate location. Check that restore procedures document the order in which these components are reapplied, and that secrets referenced by configuration are recovered through a controlled route.

SaaS and cloud-hosted data held by providers

When a provider hosts the data, the organization may assume the provider handles backup, but provider backup terms often cover platform recovery rather than a restore of individual customer data. Retention windows, restore granularity, cross-tenant recovery and the cost of a restore request vary by contract. Read the provider's backup terms in your own contracts, and confirm what you can restore, how fast, and whether you can export your own copy. Where the provider's terms fall short, the gap is an A.8.13 risk to record and address.

Endpoints and user data

Laptops, phones and user-created files often hold information that never reaches a central system, such as drafts, local exports and synced folders. Scope decisions here depend on whether data is stored on managed devices or only in synchronized cloud locations. Decide which user data is backed up centrally, which relies on sync services, and how departing staff's data is preserved before device wipe. Document the exceptions and the reasoning, since auditors look for a defined boundary rather than an assumed one.

Backup infrastructure, catalog and keys

The backup system is itself an asset that must be protected and recoverable. Its catalog records what was backed up and where, so losing it can make backups hard to find, and encryption keys that are lost make encrypted copies unreadable. Include the backup server, its database, credentials, repository passwords and key escrow in scope. Confirm that the catalog and keys can be restored independently of the systems they protect, and that access to them is limited to named roles.

Offline and immutable copies

Copies that cannot be changed or deleted by an attacker with administrator access reduce the risk that ransomware or insider action destroys every backup. Decide which datasets need an offline, air-gapped or write-once copy, and how often that copy is refreshed. Immutable storage has its own retention and deletion rules, so the lifecycle must be planned before data is written. Test that the organization can actually reach and restore from these copies, because an unreadable immutable copy provides no recovery.

How an assessor tests A.8.13 information backup

This table sets out each step an assessor typically takes when testing A.8.13, the approach used, the evidence requested and the findings that often appear. Read it as a preparation list: have each piece of evidence ready before fieldwork, and confirm the sampling approach with your auditor, since sample sizes and depth vary by certification body and by the scope of the ISMS.

Test step	Test approach	Evidence requested	Common findings
Review the backup policy	Read the topic-specific backup policy and check that it states what is backed up, how often, how long copies are kept, who owns the process and how restores are approved.	Approved backup policy with version history, owner and review date, plus the link to the Statement of Applicability entry for A.8.13.	Policy exists but names no frequency, retention period or owner, or describes systems that are not in the asset inventory.
Sample systems against scope and frequency	Select systems from the asset register and in-scope cloud accounts, then compare each one with the frequency and scope the policy sets for it.	Asset list cross-referenced to backup schedules, including information, software and system images, and any exclusions with a documented reason.	Backups cover only part of the in-scope estate, or a system added recently was never added to the schedule.
Request backup job logs and failure handling	Select a sample of backup periods and check that jobs ran, that failures were logged, and that someone investigated and reran failed jobs.	Job logs or reports for the sampled periods, alert records for failed jobs and tickets showing how each failure was resolved.	Failed jobs appear in logs with no follow-up, or alerts go to a mailbox nobody monitors.
Request restore test records	Ask for records of restore tests and check the date, the systems or data restored, who performed the test and whether the restored data was validated.	Dated restore test reports with scope, method, results, time taken and corrective actions for any failure.	Restores have never been tested, or tests only confirm that a backup job completed without restoring any data.
Check backup protection	Review who can read, change or delete backups, whether copies are encrypted, and whether backup credentials are separate from production credentials.	Access control lists for backup storage, encryption settings, key management records and a list of accounts with backup administrator rights.	Backup administrators share production admin accounts, or backup copies sit in the same account that a single compromised credential can reach.
Check separation and offline or immutable copies	Confirm that at least some copies are kept apart from the production environment and check how the organization protects them from deletion or alteration.	Architecture diagram of backup locations, retention lock or immutability settings, and records of off-site or logically separated copies.	All copies live in one environment, so an incident affecting production also affects the backups.
Check retention against stated requirements	Compare configured retention periods with the periods in the policy and any legal, contractual or customer requirements.	Retention settings from the backup tool or cloud console, the retention schedule in the policy and any contractual or regulatory source it cites.	Retention is configured by default, not set against requirements, or copies are deleted sooner than the policy states.
Confirm deletion and disposal of backup media	Check how backup copies are removed at the end of retention and how decommissioned media are handled.	Deletion logs or job reports, and disposal records for removed media or storage.	Expired copies are kept indefinitely, or old media is discarded without a record.

Implementing A.8.13 information backup in six steps

This sequence turns A.8.13 from a policy statement into backup jobs, restore evidence and a review loop that an assessor can trace from requirement to result. Each step closes with a record the organization keeps, so the backup program can be shown to work and not only to exist.

Define the backup policy and its owner
Start by writing a topic-specific backup policy that states what is backed up, why, how often, how long copies are kept and how they are protected. Name one accountable owner, usually someone in IT operations or platform engineering, and get management approval. The policy should cover information, software and system images, since A.8.13 asks for all three. The output is an approved, dated policy with a named owner and a version history that an auditor can read against the control.
Inventory data, software and system images in scope
List every system, dataset, configuration store, application binary and virtual machine or container image that the organization needs to recover. Record where each item lives, who owns it and which backup tool or service covers it today. Gaps usually appear around SaaS data, developer repositories and secrets stores, so check those explicitly. The output is a scope register that maps each asset to a backup job or to a documented reason for exclusion. Ask the owners to confirm the list, because an assessor will sample it against the infrastructure.
Set frequency and retention per class with business owners
Group the inventory into classes by how much data loss and downtime each business owner can accept. For each class, record the backup frequency, retention period, number of copies and whether an offsite or immutable copy is required. Business owners sign off, because recovery targets are a business decision that IT cannot make alone. The output is a retention schedule approved by those owners and referenced from the policy. Confirm the schedule against any contractual or regulatory retention duties the organization already carries.
Configure protected backup jobs and monitor outcomes
Configure backup jobs to match the schedule, and protect the backup system itself with separate credentials, restricted administrative access, encryption in transit and at rest, and copies that ordinary users and compromised production accounts cannot delete. Bareos, for example, uses a Director that schedules backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files, while restic provides snapshot-based repositories with a check command for structural integrity. Alert on failed, missed or partial jobs and review the alerts on a fixed cadence. The output is job configuration exports, access lists and a log of job results. Confirm each tool's capabilities against current vendor documentation before you rely on them.
Define and run restore tests with recorded results
Write restore test procedures for each class of data and system, stating the scenario, the restore target, the person performing the test, the acceptance criteria and the time the restore took. Run the tests on a schedule set in the policy and after significant changes. Integrity checks such as restic check with read-data options can confirm that stored pack files are unmodified, but a restore into a separate environment proves that the recovered service works. Record every result, including failures. The output is a dated test log with evidence of restored files or systems, and a corrective action for each failed test.
Review the policy after each test or incident
Set a review cycle in the policy and trigger an unscheduled review after any failed restore test, backup-related incident or significant change to systems or data. Compare restore results against the recovery targets in the retention schedule, update the scope register and adjust frequency or retention where the evidence shows a gap. Record what changed, who approved it and why. The output is a revision history linking each policy change to a test result, an incident or a review decision, which shows the control is maintained rather than set once and forgotten.

Evidence that passes an A.8.13 information backup audit

An assessor testing A.8.13 Information backup looks for a chain of records: a policy that sets the rules, evidence that backups run under those rules, proof that restores work, and proof that the backup stores are protected. The cards below cover the six artifacts that usually connect those links, and each one needs a routine so it stays current between audits.

Approved backup policy

The topic-specific backup policy states what is backed up, how often, how long copies are kept and who owns each step. Check that scope names information, software and system images, that frequency and retention differ by criticality, and that the owner signed off on a current version. An assessor will compare every later record against this document, so any system added without a policy update is a finding. Review it at least yearly and after major system changes.

Backup inventory mapped to systems

The inventory lists each system, dataset and configuration that has a backup job, with its owner, schedule, retention class and backup target. Assessors use it to test completeness: they pick systems from the asset register and ask where their backups are. Keep the inventory generated from the backup catalog where possible, so it reflects jobs that actually exist rather than what someone remembers configuring.

Job logs and failure follow-up

Export job completion logs on a fixed schedule and keep them in a store the backup administrators cannot edit. Every failed or partial job should have an alert and a ticket showing who investigated, what was fixed and when the job succeeded again. A log with failures and no tickets reads as an unmonitored control. Confirm that your backup platform records verify and archive jobs as well as backup jobs, since assessors often ask about both.

Restore test plans and signed results

A restore test plan names the system, the backup point used, the expected content and the tester. The signed result records what was restored, where, and whether the restored content matched the expected files or checksums. Tie each test to a change record so that a major upgrade triggers a fresh restore test. Integrity checks such as restic's check with read-data options can supply part of the evidence, but the restore itself still needs a human-signed record.

Protection records for backup stores

Keep current access lists for backup servers, repositories and cloud buckets, along with encryption settings, key custody records and immutability or write-once settings where used. Assessors check that only named roles can delete or alter backups and that backup credentials are separate from production credentials. Export these settings on a schedule and compare them with the previous export, so a change without an approved change record is visible.

Policy review log after findings

The review log shows when the backup policy was reviewed, what triggered the review and what changed. Useful triggers include a failed restore test, a missed backup, a new system with unclear requirements or an audit finding. An assessor expects to see that findings led to a real change in the policy or the job configuration, not only a closed ticket. Store each review entry with the date, the reviewer and a link to the affected records.

What A.8.13 information backup costs to meet

This table breaks down the cost of meeting A.8.13 into its components, showing who is paid, whether each cost is one-time or recurring, what drives it up, and how to reduce it. Use it to frame a quote request, since no price or duration is stated here and the real figures depend on the scope agreed in writing.

Cost component	One-time or recurring, and who is paid	Main cost driver and how to reduce it
Backup tooling or licenses	Recurring for commercial suites (per-host, per-capacity or support fees paid to the vendor). Open-source options such as Bareos (AGPL-3.0-only) and restic (BSD-2-Clause) remove license spend but not operating labor.	Number of protected systems and data volume. Ask the vendor or partner to price licenses separately from support, and confirm what the open-source option's support model would cost you.
Engineering time to configure jobs and inventories	One-time for initial setup of schedules, retention and asset inventory, paid to internal staff or an implementation partner. Some re-work recurs when systems change.	Scope size, number of providers (on-premises, cloud, SaaS) and how many systems have a documented recovery objective. Keep the inventory in version-controlled configuration so changes are small.
Restore test effort, including staff time and test environment	Recurring, because restore tests must be repeated under the backup policy. Staff time is internal or contracted. A separate test environment may be needed for realistic restores.	Recovery objectives, system complexity and how many restores are sampled. Scope a representative set of restores, automate integrity checks where the tool supports them, and document each test's result.
Storage for backup copies and off-site or immutable copies	Recurring, paid to your cloud or data center provider or hardware owner. Off-site and offline copies add cost per copy.	Storage volume and retention length. Shorten retention to what the policy requires, deduplicate where the tool supports it, and confirm the number of copies the policy calls for.
Evidence upkeep	Recurring, as internal effort to keep job logs, test records, policy approvals and exception records current and retrievable.	Number of systems, frequency of tests and whether evidence is collected automatically. Centralize logs and use fixed evidence templates to limit manual work.
External review of the backup policy and test design	Periodic, paid to an independent reviewer or consultant. Only an independent auditor issues assessment conclusions.	Breadth of scope, number of sites or providers and the reviewer's rate basis. Ask for a fixed-scope review with defined deliverables.
Auditor sampling time	Recurring with each certification or surveillance audit, paid to the certification body. The auditor selects samples, so the cost depends on what they test.	Number of backup jobs, restore records and exceptions the auditor samples. Ask the certification body to confirm its sampling approach and the audit days it plans before work starts.

Bareos and restic as self-hosted backup evidence sources

Two self-hosted open-source tools can generate much of the evidence an assessor asks for under A.8.13 Information backup. Bareos records what was backed up, when and whether jobs succeeded, while restic proves that stored backup data has not been altered. Neither tool decides the backup policy, so the organization still defines what is backed up, how often, how long copies are kept and how restores are tested.

Bareos job and catalog records

Bareos (AGPL-3.0-only) runs a Director that schedules and supervises backup, restore, verify and archive jobs. It keeps a SQL catalog of backed-up files, so the job history and catalog entries show what was protected, when, and whether each run completed. Assessors often ask for this record to confirm that backups run on the frequency the policy states. Check the AGPL-3.0-only license terms against your own distribution and internal use before deployment, and confirm with counsel where modified versions or hosted services are involved.

Bareos restore jobs as test evidence

Bareos can restore files from the current backup or from one taken before a given date and time. Those restore jobs and their logs are the raw material for restore test records. A job log alone does not prove that restored data is usable, so the organization must define which systems are tested, who signs off the result and how often tests run. Record the test scope, the restored sample and the outcome in the test plan, and keep the restore job IDs next to those records.

restic check for structural integrity

The restic check command verifies the structural consistency of snapshots, trees and pack files in a repository. It shows that the backup repository's index and metadata are coherent, which supports the claim that copies are still restorable. Run it on a schedule and keep the output with the timestamp and repository identifier. Structural checks do not prove the stored content matches the source, so pair them with the data-level check below.

restic data reads for integrity proof

With --read-data or --read-data-subset, restic check reads pack files back and confirms that the stored backup data is unmodified. This is the stronger integrity evidence, because it tests the bytes themselves rather than only the metadata. Reading all data costs time and I/O on large repositories, so many teams use the subset option on a rotation and document the schedule. The organization should decide the subset strategy, the frequency and the response to any failed check.

restic licensing and repository ownership

restic is released under BSD-2-Clause, a permissive license that generally allows internal use and modification with notice retained. Confirm this against the version and packaging you deploy. Ownership of the repository, its encryption keys and access credentials stays with the organization, and those keys must be protected and recoverable. Losing the repository keys makes the backup unreadable, which no check output can repair.

Policy, scope and restore tests stay with you

Neither Bareos nor restic defines what information is in scope, how often it is backed up or how long copies are retained. The organization must write the topic-specific backup policy, set restore test objectives and approve the results. An implementation partner can configure the jobs, checks and log retention, but the policy decisions and their acceptance remain the organization's responsibility, and an independent auditor will test whether they were followed.

Who owns backup restore testing and what to outsource

Your organization owns the backup policy and every decision that defines what protection means for the business. The policy sets which information, software and systems are in scope, how often copies are made, how long they are kept and who may restore them. Business leaders accept the recovery objectives that follow from those choices, because they carry the consequences if data is lost or restored late. The same team decides when a restore test counts as passed and what happens after a failed test.

Recovery objectives: Agree the recovery time and recovery point each system must meet, and record who accepted the residual risk where a target cannot be met.
Scope and retention: Sign off which systems, data sets and cloud services are covered, and set retention periods that reflect legal, contractual and operational needs.
Restore test decisions: Choose which systems are restore tested, how often, and which samples show that recovered data is complete and usable.
Backup protection: Decide who may access backup repositories and encryption keys, and require that backups are not writable through the everyday production administrator account.

Confirm that every backup decision has a named owner and a dated approval record, because an assessor will ask for those records before reviewing any technical evidence.

An implementation partner prepares the backup system and the evidence that shows it works. Under a fixed-scope engagement, the partner configures backup tooling inside your cloud accounts, data centers or air-gapped network, builds the inventory the policy depends on and sets up monitoring for failed and missed jobs. The partner can also write restore test scripts, evidence templates and runbooks, and run a first restore test cycle within the agreed scope. Throughout, the partner works to the policy your organization approved and does not set it.

Configuration: Deploy the scheduler and catalog, such as the Bareos Director with its SQL catalog, and set schedules and retention to match the approved policy.
Inventory and monitoring: Maintain a list of protected systems and alert on jobs that fail, do not run or cover fewer hosts than the inventory expects.
Integrity checks: Use verification features, such as restic check with --read-data or --read-data-subset, to confirm that stored backup data can be read back unmodified.
Restore test cycle: Run an initial restore test within scope, record timings and results, and hand over templates so your staff can repeat the test.

Ask for the deliverables in writing, including who owns the scripts, where the evidence is stored and whether the partner will ever approve the control on your behalf, which it should not.

Where information backup controls usually fall short

Most backup programs fail an assessment not because jobs stop running but because the backups cannot be trusted, cover the wrong things, or sit too close to what they protect. The cards below describe six gaps that recur under A.8.13 Information backup, each paired with a closing action an assessor can see in the evidence.

Backups that run but are never restored

A green job report shows that data was written, not that it can be recovered. Under A.8.13, the requirement to regularly test backups is where many programs stall, because restore tests feel expensive and are postponed. Check whether the organization has performed a full or partial restore of each critical system within the review period, and whether the result was recorded. Closing action: schedule a documented restore test for one critical system, record the time taken and the data checked, and file the result with the backup policy.

Scope that omits SaaS, endpoints or configuration

Backup scope is usually defined by the servers the infrastructure team remembers. Cloud-hosted SaaS data, laptops, and the configuration of firewalls, identity providers and infrastructure as code often fall outside the job list, even though they hold information the organization must be able to recover. Compare the backup scope against the asset inventory and the list of information and software the organization has classified. Closing action: record each asset class as in scope, out of scope with a reason, or covered by a provider, and assign an owner to each decision.

Backup stores that share credentials with production

When the backup server uses the same administrator accounts as production, a compromised domain or hypervisor can delete the backups along with the systems. Ransomware operators target backup catalogs and repositories for exactly this reason. Review which identities can write to, modify or delete backup repositories and whether they can also administer the protected systems. Closing action: give the backup service its own identities, restrict deletion rights, and keep at least one copy that production credentials cannot alter.

Retention that is undefined or inconsistent with contracts

Retention is often set by the default of the backup tool rather than by the policy. The result is that backups are kept longer than contracts and privacy duties allow, or deleted before a customer's recovery period or a legal hold ends. Compare retention settings for each system with the policy, the contractual recovery commitments and any deletion rules that apply to the same data. Closing action: write a retention table that lists each data class, its retention period, its owner and the source that sets it, then configure jobs to match the table.

Failures that are logged but not followed up

Backup software records failed, partial and warning jobs every night, yet the failures are rarely reviewed or tracked to closure. An assessor will look for the log entries and then for evidence that someone investigated and fixed each exception. Check whether failed jobs generate tickets, whether an owner reviews them on a set cadence, and whether repeated failures are escalated. Closing action: route backup failures to the ticketing system, assign a named reviewer, and keep a record of each exception from detection to resolution.

Redundancy or replication presented as backup

Replicated storage, high availability clusters and mirrored sites protect against hardware failure and site outages, but they copy mistakes and malicious changes as faithfully as good data. A deleted file or encrypted volume is replicated within minutes. A.8.13 asks for backup copies that can be restored to an earlier state, which is a separate requirement from the redundancy covered by A.8.14. Closing action: document which mechanisms provide point-in-time recovery, confirm that at least one of them keeps history beyond the replication window, and cross-reference the design in the business continuity plan.

Questions buyers ask about A.8.13 information backup

How much effort does meeting A.8.13 information backup take, and what drives it?

The effort depends on how many systems, data stores and software images fall inside the backup scope, how often they change, and how many restore paths must be proven. No researched figure is available for a typical duration, so ask any implementer for a written estimate tied to your asset list. The main cost drivers are the number of systems in scope, the recovery expectations set by the business, the number of sites or cloud accounts involved, and whether backups already exist but are undocumented. One-time work covers writing the backup policy, mapping systems to protection levels, configuring jobs and running the first restore tests. Recurring work covers monitoring job results, rotating restore tests, reviewing retention and keeping the evidence current. Ask for the scope of each in the quote so you can compare proposals on like terms.

Can a small team run information backup controls in-house?

Yes, a small team can run A.8.13 in-house if it has clear ownership, a written backup policy and enough time for routine checks. The standard asks that backups are maintained and regularly tested in line with that policy, so the work is repeatable operations plus evidence rather than a large project. Success usually depends on named owners for each system, a schedule for restore tests, and someone who reviews failed jobs quickly. Open-source tools such as Bareos and restic can schedule jobs, keep catalogs and verify stored data, but they still need an operator who understands retention settings, encryption keys and recovery steps. If the team lacks that capacity, an implementation partner can build and document the setup while the organization keeps ownership of the policy and the restore decisions.

What does restore testing need from the business?

Restore testing needs the business to define what must come back, how quickly, and which people can confirm that the restored data is usable. A technical restore proves that files return; a business test proves that an application, record set or service works afterward. Before a test, the business should agree which systems are sampled, who signs off the result, and what counts as a failure. It also needs a window where production-adjacent work can pause, and it must approve restores into non-production targets so live data is not disturbed. Tools can help: Bareos can restore files from the current backup or from one before a given date and time, and restic can read pack files back to confirm stored data is unmodified. Record every test with date, scope, result and follow-up actions, because those records are the evidence an assessor will ask for.

How long should backup evidence be kept, and why match the audit cycle?

Keep backup evidence for at least the period an assessor will sample, and align that period with your certification cycle. Under ISO/IEC 17021-1, a management system certification cycle lasts three years, with at least one audit in every calendar year, so an auditor may ask to see backup logs, policy versions and restore test records covering several surveillance points. Retaining evidence for the full cycle, plus the time needed to close any findings, avoids gaps during recertification. Your own policy should set the exact period, the storage location and the access rules for those records, and it should align with legal retention requirements that apply to your data. Store evidence in a way that protects it from alteration, since backup records that can be edited will carry little weight with an assessor.

Can the implementation partner also be our ISO 27001 auditor?

No. An implementation partner prepares systems, controls and evidence, while an independent accredited certification body performs the audit and issues the certificate. ISO does not certify organizations, and accredited certification bodies work to ISO/IEC 17021-1 together with ISO/IEC 27006-1, which exists to keep the audit independent of the work that prepared the organization. If the same firm designed your backup controls and then audited them, the certification body could not give an independent opinion on that design. DeployOpen plans, configures, documents and tests the backup setup in your environment and prepares the evidence, but it does not issue audit reports, attestations or certificates. Choose a separate certification body for the audit, and confirm its accreditation before signing.

How do we check a certification body's accreditation in IAF CertSearch?

Search the IAF CertSearch database for the certification body and the certificate, and confirm that the certificate is listed as accredited for ISO/IEC 27001 with the scope you expect. Since 1 January 2026, Global ACI has assumed the roles of the IAF and ILAC, but ISO still points to the IAF CertSearch database for checking accredited certificates, so use that route for verification. Check the certification body's name, the accreditation body that granted its status, the standard edition and the scope of sites covered. Ask the certification body to confirm in writing that it applies ISO/IEC 27006-1, which IAF MD 29:2024 required all clients to apply by 31 March 2026. Also confirm that the audit team has no role in designing your controls, since that independence is central to the result you are buying.

How DeployOpen scopes and evidences A.8.13 backups

DeployOpen plans and implements self-hosted open-source backup platforms inside your own cloud accounts, data centers or air-gapped networks. The work follows a written scope for A.8.13 Information backup, and the organization keeps ownership of its backup policy, controls and evidence.

How we scope

Agree in writing which information, software and systems fall under the backup policy and which are excluded.
Record backup frequency, retention periods and protection requirements for each system class before any build starts.
Confirm who in your organization approves the backup policy and who receives restore test results.

How we build

Deploy backup components such as Bareos or restic within your environment, with encryption and access restricted to named roles.
Configure scheduled backup jobs, catalogs and verification jobs so that each backup has a recorded outcome.
Set up backup copies that are separated from production credentials, so a compromised production account cannot delete them.

How we hand over

Document the backup configuration, schedules, retention settings and restore procedures in a form your auditor can follow.
Run and record restore tests against the agreed scope, with results, failures and corrective actions kept as evidence.
Deliver the evidence set your organization needs for its own ISMS, and state clearly that an independent auditor decides conformity.

How we support

Offer ongoing support, upgrades and periodic restore testing as a retainer after handover.
Review backup job reports and verification results on the cadence set in the written scope.
Update procedures and documentation when systems, retention rules or the backup policy change.