Why backups matter for SOC 2 and ISO 27001 compliance

In short: neither framework names a backup product, and neither one is satisfied by owning one. SOC 2's availability criteria (A1.2 and A1.3) and ISO 27001's Annex A 8.13 ask the same two questions: is backup governed by a written policy, and have you tested a restore? The current editions are the 2017 Trust Services Criteria with revised points of focus (2022) and ISO/IEC 27001:2022 with Amendment 1:2024. Every ISO 27001:2013 certificate expired on 31 October 2025. The backup obligation sits with your organisation, not with your SaaS vendors, and a vendor's SOC 2 report is supporting evidence rather than a substitute for your own.

Reviewed 24 September 2026. General information about two frameworks; how they apply depends on your scope, your auditor and your risk assessment.

What changed, and what did not

Most of what you read about "new SOC 2 requirements" or an "ISO 27001 2026 update" is not a change to the rules. Here is the actual state of both frameworks as of September 2026.

SOC 2: what is current

• What it is. An attestation engagement under AICPA standards. The output is an auditor's report carrying an opinion, not a certificate.
• Current criteria. The 2017 Trust Services Criteria with revised points of focus, published 2022 and posted by the AICPA in September 2023. There is no 2025 or 2026 replacement. AICPA
• Most recent change. The revised points of focus (2022), and the 2018 description criteria with revised implementation guidance (2022). Points of focus are explanatory examples, not criteria, so they do not change the controls you need. Description criteria
• Where backup sits. The availability criteria A1.2 and A1.3, with CC7.5 for recovery from incidents.

ISO 27001: what is current

• What it is. A certifiable management system standard. The output is a certificate issued by an accredited certification body.
• Current edition. ISO/IEC 27001:2022, published 25 October 2022. There is no 2026 edition. ISO
• Most recent change. Amendment 1:2024, published February 2024. It adds a requirement to determine whether climate change is a relevant issue, plus a note that interested parties may have climate-related requirements. ISO/IEC 27001:2022/Amd 1:2024
• A deadline that has already passed. 31 October 2025. All certifications based on ISO/IEC 27001:2013 expired or were withdrawn on that date under IAF MD 26.
• Where backup sits. Annex A 8.13, Information backup, supported by 5.29, 5.30 and 8.14.

Two practical consequences. First, if a vendor sends you an ISO 27001:2013 certificate in 2026, it is out of date and you should ask for the 2022 certificate and the certification body's accreditation. Second, if someone tells you SOC 2 has new backup requirements this year, ask which criterion. The criteria have not moved. What has moved is auditor practice, particularly around supplier scrutiny and how much evidence is expected for cloud services your organisation does not host.

The Annex A restructure from the 2022 edition still trips people up. The old 2013 control for backup was 12.3.1 and continuity lived in clause A.17. In the 2022 edition there are 93 controls in four themes: backup is 8.13, information security during disruption is 5.29, ICT readiness for business continuity is 5.30, and redundancy of information processing facilities is 8.14. Policies and statements of applicability that still quote 12.3.1 need updating.

The question both auditors ask first

Before any control language matters, both frameworks make you answer a scoping question: which systems are in scope, and is the data in your SaaS apps part of that scope?

For ISO 27001, that is the scope of your information security management system and the risk treatment behind your Statement of Applicability. For SOC 2, it is the system boundary described in section 3 of the report, written against the description criteria.

This is where most SaaS backup gaps originate. Teams scope their own product infrastructure carefully, then treat the CRM, the project management tool and the design files as someone else's problem because they run on a vendor's servers. If a business process depends on the records in those apps, and you would have to rebuild them by hand after a bad import, an auditor can reasonably expect the recovery of that data to be addressed somewhere in your control set.

The vendor's own availability commitment does not resolve this. Your SaaS provider protects its platform from its own failures. It generally does not undertake to reverse a deletion, a bad automation or a bulk edit made by your authorised users. That split is worth reading up on separately in our explanation of the shared responsibility model for SaaS data.

What your SaaS vendor's contract says

The clearest answer to "who backs this up?" is often in the vendor's own terms. Two examples, quoted from the current terms of service:

• ClickUp: "we encourage you to maintain your own backup of your Content. In other words, we are not a backup service and you agree that you will not rely on the Service for the purposes of Content backup or storage." (ClickUp Terms of Service)
• monday.com: "It is Customer's sole liability to export the Customer Data prior to such termination or expiration." (monday.com Terms of Service)

This is where ISO 27001 Annex A 5.23 bites. The control expects you to decide which security responsibilities sit with the cloud provider and which sit with you, and to plan how you would exit the service with your data. When the provider's contract puts backup on your side, your Statement of Applicability has to say how you discharge it.

SOC 2 handles the same situation differently. A SaaS tool you use internally is often outside the system your report describes, and where a vendor is in scope, the usual control is vendor management under CC9.2 rather than an independent copy. Backup becomes a SOC 2 question mainly when the SaaS app is part of the service you deliver, for example an agency running client work in ClickUp.

What SOC 2 actually asks of backups

SOC 2 is risk-based. There is no prescribed backup frequency, retention period or technology. The auditor tests the controls you described against the criteria in the categories you selected. Security is always included; availability, confidentiality, processing integrity and privacy are included when relevant to the service.

The criteria that touch backup, described generically:

• A1.2 (Availability). Environmental protections, software, data backup processes and recovery infrastructure are authorised, designed, developed, implemented, operated, monitored and maintained to meet availability objectives. In practice: you decided what needs backing up, the backup actually runs, someone watches whether it runs, and the copy is not sitting in the same failure domain as the original.
• A1.3 (Availability). Recovery plan procedures are tested to meet availability objectives. Having the plan is not the control. Exercising it is the control.
• CC7.5 (Security). The organisation identifies, develops and implements activities to recover from identified security incidents. After ransomware or a compromised integration, can you get back to a known-good state?
• CC9.2 (Security). Vendor and business partner risk management. This is where your review of the backup provider itself lands: their report, their subprocessors, their limitations.
• C1.2 (Confidentiality) and P4 (Privacy), where those categories are in scope, cover retention and disposal. Backups are copies of the same information, so a retention schedule that ignores them is incomplete.

Availability is the category that matters most here, and it is optional. If your report covers security only, an auditor may still reach backup through CC7.5 and your own stated controls, but the depth of testing differs. Decide deliberately whether availability belongs in your next report rather than discovering the gap when a customer's security questionnaire asks for it.

What ISO 27001 actually asks of backups

ISO 27001 splits into management system clauses (4 to 10) and the Annex A reference controls. Backup appears in both places, which is why "we bought a backup tool" never closes the finding on its own.

Annex A 8.13, Information backup expects backup copies of information, software and systems to be maintained and regularly tested in accordance with the agreed topic-specific policy on backup. Two load-bearing phrases: agreed topic-specific policy and regularly tested. The control assumes a written backup policy exists and that restores are exercised against it.

Supporting controls that auditors commonly pull in alongside it:

• 5.23, Information security for use of cloud services. New in the 2022 edition and directly relevant. It covers how cloud services are acquired, used, managed and exited, including what happens to your data.
• 5.29, Information security during disruption and 5.30, ICT readiness for business continuity. The continuity side: recovery objectives, plans and the readiness of the technology to meet them.
• 5.33, Protection of records and 8.10, Information deletion. Retention on one side, defensible deletion on the other.
• 8.14, Redundancy of information processing facilities. Availability of the processing capability itself, distinct from having a copy of the data.

Above Annex A, clause 6.1.3 requires you to justify each control's inclusion or exclusion in the Statement of Applicability, and clause 9 requires monitoring, measurement and internal audit. A backup control that is declared applicable but never measured is a nonconformity waiting to be written up.

On Amendment 1:2024: it is narrow. It adds a requirement under clause 4.1 to determine whether climate change is a relevant issue for your organisation, and a note under 4.2 that interested parties can have climate-related requirements. It does not create a backup requirement. It is reasonable, though, for a regionally concentrated backup strategy to come up when you document that determination, since extreme weather is one of the availability risks a single-region copy carries.

Mapping the obligation to the evidence

The same handful of artefacts satisfies both frameworks. Each line below gives one thing you must be able to show, the criterion or control it answers in each framework, and the evidence that actually holds up. Treat it as a practical starting point rather than a universal audit programme, and agree the specifics with your auditor.

• Backup is governed by a written, approved policy. SOC 2: A1.2, via your described controls. ISO 27001: A 8.13, which names an "agreed topic-specific policy", plus A 5.1. Evidence: the policy itself, with scope, frequency, retention, owner, approval date and review cycle.
• The systems in scope are actually backed up. SOC 2: A1.2. ISO 27001: A 8.13 and clause 6.1.3. Evidence: an app inventory naming each system, whether it is backed up, by what method, since when, and the documented reason for anything excluded.
• Restores are tested, not assumed. SOC 2: A1.3. ISO 27001: A 8.13, which says "regularly tested", plus A 5.30. Evidence: a dated restore-test record covering what was restored, by whom, elapsed time, what did not come back, the corrective action and the retest.
• Recovery objectives are defined and met. SOC 2: A1.2 and A1.3. ISO 27001: A 5.29 and A 5.30. Evidence: approved RPO and RTO per system, plus the measurements from your test compared against them.
• Access to backups is controlled. SOC 2: CC6.1 to CC6.3. ISO 27001: A 5.15 and A 8.2. Evidence: an access review of who can browse, export, restore or delete, MFA status, and the break-glass procedure.
• Backup copies are protected in transit and at rest. SOC 2: CC6.7. ISO 27001: A 8.24. Evidence: encryption configuration, storage region and a description of key management.
• Retention and deletion are deliberate. SOC 2: C1.2 and the P4 privacy criteria. ISO 27001: A 5.33 and A 8.10. Evidence: a retention schedule per data category with its justification, and how deletion requests reach backups, exports and restores.
• The backup vendor has been assessed. SOC 2: CC9.2. ISO 27001: A 5.19 to 5.23. Evidence: the supplier assessment, the vendor's current report, the subprocessor list, the DPA and the documented limitations.
• Incidents can be recovered from. SOC 2: CC7.5. ISO 27001: A 5.29. Evidence: the runbook, the incident record and the post-incident review.

Notice what is missing from the right-hand column: a screenshot of a connected integration. A screenshot proves a connection existed on the day it was taken. It does not evidence a tested recovery.

The four artefacts that do most of the work

If you are starting from nothing, build these four. Between them they answer the majority of backup questions in either audit.

1. A SaaS data backup policy. One document. Which apps are in scope, what is captured, backup frequency, retention per category and why, who owns it, how often restores are tested, who may restore, and what happens when a backup fails. Date it and have it approved. Our walkthrough of what belongs in a SaaS data backup policy covers the sections auditors look for.

2. A scope inventory. A table of every SaaS app the business depends on, its owner, whether it holds personal data, its native recovery options, whether it is independently backed up, and the decision recorded for anything deliberately left out. A documented exclusion is an acceptable audit answer. An undocumented gap is not. Our SaaS stack data protection audit is a five-step way to build this.

3. A restore-test record. The single highest-value artefact, because both A1.3 and A 8.13 name testing explicitly and it is the one most organisations cannot produce. One page per test is enough. See the section below.

4. An access review. Who can see the vault, who can export, who can restore, who can delete, and whether multi-factor authentication is enforced. Re-run it on the same cadence as your other access reviews and keep the output.

Running a restore test that satisfies both frameworks

A restore drill per quarter, documented, satisfies the "tested" element in both SOC 2 A1.3 and ISO 27001 A 8.13. Keep it small and real rather than large and theoretical.

1. Pick a representative scenario, not the easy one. "A project manager bulk-deleted a list of tasks last Thursday" beats "restore one record we deleted five minutes ago."
2. Restore to a safe destination using approved sample data, a test workspace or a supported non-destructive method, so the drill cannot itself cause an incident.
3. Check the things that break quietly. Custom fields, attachments, comments, assignees, relationships between records, permissions, and any automations that fire on record creation.
4. Time the whole workflow, from the moment someone notices to the moment the team can work again. Compare it with your stated RTO. If you have not set RPO and RTO yet, start with our explanation of what RPO and RTO mean for SaaS apps.
5. Write down what did not come back. Every integration has limits. Recording them honestly is stronger evidence than a clean report nobody believes, and it gives you a corrective action to close before the next test.
6. Sign, date and file it, with a named owner for each follow-up.

Our guide on how to test SaaS backups goes through the mechanics in more detail.

Retention, deletion and the awkward overlap with GDPR

Retention is where the two frameworks hand off to privacy law, and where a backup policy written purely for availability tends to fail.

Set retention by data category and purpose, not by whatever the product's maximum happens to be. Longer history is not automatically better: it enlarges the volume of personal data you hold and the blast radius of any compromise. Write down why each period is what it is, which records carry separate legal retention duties, and when old copies expire.

Then handle the harder direction. A validly erased record that a later restore quietly reintroduces into an active workflow is a real finding, and the control that prevents it is procedural. Make checking recovered records against your deletion log part of the restore runbook, and test that too. We cover the mechanics in GDPR and backups: how to handle deletion requests, and the wider legal picture in our guide to SaaS backup requirements under GDPR and NIS2.

If you are an in-scope NIS2 entity, backup management and disaster recovery are named obligations under Article 21(2)(c), assessed through your national implementing law. Start with NIS2 backup requirements.

Where a vendor's SOC 2 report fits, and where it stops

This is the most common misunderstanding in the whole subject, so it is worth stating plainly.

A backup vendor's SOC 2 Type II report evidences that the vendor protects the data it holds. Under GDPR Article 28 that is exactly the kind of assurance you are expected to check before appointing a processor, and under SOC 2 CC9.2 or ISO 27001 A 5.19–5.23 it is the evidence behind your supplier assessment. Read the scope, the period, the opinion and the listed exceptions rather than the badge.

It does not transfer your obligations. Your auditor will still ask you to show which systems are backed up, that retention matches your policy, that restores are tested, and that access is controlled. No vendor report answers those questions on your behalf.

For our own position: ProBackup has held a SOC 2 Type II report since May 2025, available under NDA through the trust centre and listed on our audit reports page. ProBackup does not hold ISO 27001 certification and does not claim it; if your policy requires ISO 27001 from every processor, that is a line item we do not meet today. The full detail is in what our SOC 2 Type II report covers.

If you run your compliance programme on Vanta, the ProBackup integration tests your ProBackup account continuously for deprovisioning, named accounts and MFA, which automates part of the access-review artefact above.

Five findings auditors actually write up

1. A policy with no evidence behind it. The document says quarterly restore tests. There are no test records. The policy becomes the finding.
2. Scope that stops at your own infrastructure. Production databases are covered in detail; the CRM holding every customer relationship is not mentioned anywhere in the Statement of Applicability or the system description.
3. "Version history" counted as backup. Native trash and version history are recovery features of the same platform, with their own retention windows and their own failure modes. They are worth having, and they are not an independent copy. See version history and trash retention across SaaS apps.
4. Nobody watches for failures. Backups silently stopped when an OAuth token expired three months ago. A1.2 expects monitoring, not just execution.
5. Retention set by accident. The plan's default was adopted because nobody chose a number, and it does not match the retention the policy claims.

Manual exports deserve a note of their own. A scheduled CSV export to a controlled location can form part of a compliant control set, and the old version of this article was too casual in implying that any copy will do. What auditors challenge is the surrounding evidence: is the export scheduled and monitored, is failure detected, is the destination access-controlled and encrypted, is retention enforced, and has a restore from it been tested? A manual process that depends on one person remembering usually fails the monitoring and testing tests rather than the copy test.

Your checklist

1. Confirm which framework and which categories apply. For SOC 2, decide whether availability is in scope. For ISO 27001, confirm your certificate is against the 2022 edition.
2. Put SaaS data inside the boundary. Name the apps in your Statement of Applicability or system description, with a documented reason for anything excluded.
3. Write or refresh the backup policy. Scope, frequency, retention, ownership, testing cadence, failure handling, approval date.
4. Set RPO and RTO per system, and check that the actual capture times and measured recovery times support them.
5. Choose the recovery method per app on the basis of the risk, then document the limits of what it can and cannot recover.
6. Run and document a restore test. Then schedule the next one.
7. Review access to backups and enforce MFA.
8. Reconcile retention and deletion across live data, backups, exports and restores.
9. Assess the vendor. Current report, scope, exceptions, subprocessors, DPA, storage region.
10. Update the Annex A references if your documentation still cites the 2013 control numbers.

FAQ

Does SOC 2 require backups?

Not by name, and not as a fixed rule. SOC 2 tests the controls you describe against the Trust Services Criteria you selected. If availability is in scope, criteria A1.2 and A1.3 cover data backup processes, recovery infrastructure and the testing of recovery procedures, so a backup control set is normally how organisations meet them.

Does ISO 27001 require backups?

Annex A 8.13, Information backup, expects backup copies of information, software and systems to be maintained and regularly tested in line with an agreed topic-specific policy on backup. Annex A controls are applied through your risk assessment and justified in the Statement of Applicability, so the depth is risk-based, but excluding backup entirely is difficult to defend.

Is ISO 27001:2013 still acceptable in 2026?

No. Under IAF MD 26, all certifications based on ISO/IEC 27001:2013 expired or were withdrawn on 31 October 2025. Current certificates are against ISO/IEC 27001:2022.

Did SOC 2 or ISO 27001 change in 2026?

Neither framework was rewritten. SOC 2 still uses the 2017 Trust Services Criteria with revised points of focus from 2022. ISO/IEC 27001:2022 remains the current edition, supplemented by the February 2024 climate-action amendment. There is no ISO 27001:2026 edition.

Does my SaaS provider's compliance cover my backups?

No. Your provider's certification covers its platform. It does not usually undertake to reverse deletions, bad imports or automation errors made by your own authorised users, and your auditor will ask about your controls, not only your vendors'.

Does using a SOC 2 certified backup vendor make my company compliant?

No. A vendor's report evidences how the vendor protects the data it holds, which supports your supplier assessment under CC9.2 or ISO 27001 A 5.19–5.23. Your own audit still requires your scope inventory, your policy, your tested restores and your access controls.

Are manual exports enough?

They can be part of a compliant control set, but they are judged on the same evidence as anything else: monitored execution, detected failures, controlled and encrypted storage, enforced retention, and a documented restore test. Processes that rely on someone remembering usually fail on monitoring and testing.

Pick one app that matters, confirm exactly what is backed up, and run a documented restore test this quarter. That single artefact answers more audit questions than any purchase does.

Start your ProBackup trial

Still comparing options? Review our data security documentation, plans and the Help Center to check coverage and recovery options for your apps.