Adopting a SaaS platform simplifies infrastructure, updates and access. However, it can create a dangerous assumption: if the service runs in the cloud, the data is automatically safe. With SaaS platform backups, availability, redundancy and backup are related, but they are not the same thing.
A provider can keep the application available when a component fails and still not offer the client granular restoration of a deleted document. Similarly, it can replicate data between locations and quickly spread corruption or a deletion. It can also keep technical copies to recover the entire platform, yet not give the client an individual recovery point.
That is why the question “do you make backups?” is too vague. A useful answer must identify what the provider copies, which incidents it covers, how much data you could lose, how long recovery takes, who decides and what proof exists.
Backup is not the same as synchronisation, version history or high availability
Backup: A separate copy that lets you recover data from an earlier point after loss, corruption or an incident.
Synchronisation: Keeps information consistent between locations or systems; it can spread a deletion or an error.
Version history: Lets you recover earlier versions within the application, according to its own rules and time limits.
Replication: Copies changes to another environment for availability; it does not always preserve earlier states.
Export: Delivers data to the client in a defined format; it can support portability, but it does not replace operational recovery.
High availability: Reduces service interruptions when failures occur; it does not necessarily solve logical data loss.
Practical rule: If the mechanism does not let you return to an earlier state, isolated from the incident, and restore usable data, do not treat it as a backup just because several copies exist.
Before the 12 questions: Turn answers into commitments
Sales answers such as “daily backup”, “geographic redundancy” or “we follow best practice” are not enough to manage risk. Therefore, look for four qualities: contractual language, measurable metrics, assigned responsibilities and verifiable evidence.
Contractual: the answer should appear in the contract, SLA, security annex or other applicable binding documentation.
Measurable: frequency, retention, RPO, RTO, coverage and deadlines should not depend on interpretation.
Operational: the process should specify the request, approval, escalation, communication, cost and completion criteria.
Demonstrable: reports, tests, logs, certifications or equivalent evidence should support the claim.
12 questions about SaaS platform backups
1. Which data, metadata and settings does the backup include?
Check whether the copy covers documents, versions, metadata, comments, validation decisions, attachments, users, permissions, audit logs, rules, workflows and the settings you need to rebuild the process. Indeed, recovering only the files can leave the information without context, ownership or evidential value.
Ask for a list of inclusions and exclusions. For example, integrations, temporary files, data from connected applications and keys may follow different policies.
2. Which loss scenarios does the backup really cover?
Test the answer against specific situations: accidental deletion by a user, unauthorised changes, silent corruption, a compromised admin account, ransomware, a regional outage, prolonged provider unavailability and a faulty update. This matters because the same backup design may not address all these scenarios.
3. Are the copies separate from the production environment?
Ask whether credentials, accounts, tenancies, regions or environments remain separate, and whether a compromised production account could delete or encrypt the copies. CISA recommends offline or cloud-to-cloud backups with encryption, regular testing and protection against changes or deletion. It also recommends reviewing the shared responsibility model in the cloud.
“It is in another data centre” does not answer whether the same privileges, keys or commands can reach both environments.
Recovering SaaS platform backups
4. What is the RPO for each category of information?
The Recovery Point Objective indicates the maximum tolerable data loss, expressed in time. If the RPO is four hours, a recovery can take the organisation back by up to four hours. So compare that interval with the real pace of submissions, validations, access requests and document changes.
In addition, data with different impacts may justify different objectives. NIST recommends defining an RPO for each asset and aligning backup frequency and technology with that objective.
5. What is the RTO and when does the clock start?
The Recovery Time Objective represents the expected time to restore the service or the data. Clarify whether the clock starts at the incident, at detection, when the request opens or when the provider confirms it. Also check whether the deadline covers only the delivery of files or the full functional restoration of the application, including settings, permissions and dependencies.
An RTO is only credible when a comparable test has measured it and it includes components such as data, application, configuration and keys.
6. What restore granularity is available?
Check whether you can recover a single document, a version, a record, a logical folder, a contractor, a business unit, a database or the entire environment. However, the broader the restore, the greater the possible impact on legitimate changes made after the chosen point.
Also ask how the provider reconciles recovered data with the current state and how it avoids reintroducing corrupted information or compromised code.
Retention, protection and testing
7. How long do recovery points remain available?
Retention should be long enough to detect late incidents, but you should not confuse it with indefinite storage. Ask for the actual sequence of available points (daily, weekly, monthly or another model) and confirm what happens when the client deletes data because of an obligation or policy.
Distinguishing backup retention, document retention and archiving prevents anyone from using a technical copy as a substitute for an approved retention policy.
8. How does the provider protect access, keys and locations?
Confirm encryption in transit and at rest, key management and recovery, strong authentication, least privilege, segregation of duties, access logging and protection against deletion. In addition, ask where the provider processes and stores the data, which sub-processors take part and how it controls international transfers.
An encrypted copy is useless if the organisation cannot access the key during recovery. It is also insecure if an attacker can compromise the key through the same path as production.
9. When was the last test and what evidence exists?
Ask for the date, scope, scenario, volume, result, observed RPO and RTO, failures found and corrective actions. A test on a small file does not prove that you can recover a whole database, history or environment within the business deadline.
The GDPR includes the ability to restore availability and access in a timely manner, as well as a process for regularly testing and evaluating security measures. The competent person in charge should validate how this applies in practice.
Responsibilities and exit in SaaS platform backups
10. Who can request, approve and carry out a restore?
Define contacts, request authentication, decision authority, priorities, communication, escalation, execution windows and costs. A technically feasible process can fail because nobody knows who authorises the recovery or because the contact is unavailable outside normal hours.
Finally, include the client’s responsibility for classifying data, setting objectives, keeping contacts up to date and validating the result. Likewise, include the provider’s responsibility for executing, communicating and preserving evidence, in line with the contracted service.
11. How can you export the data and prepare your exit?
Backup and portability are not the same, but an exit strategy reduces dependency. Confirm the exportable categories, structured formats, metadata, attachments, logs, technical documentation, frequency, duration, cost and the ability to import into another environment.
The European Union Data Act contains rules on switching between data processing services, information on formats, continuity and recovery periods. Legal professionals should review its applicability and the contract clauses, considering the type of service and any exceptions.
12. What happens to the copies when the contract ends?
The contract should explain how long you can still recover the data, when deletion takes place, how the provider treats residual copies and confirms deletion, which cases require mandatory retention and what impact litigation or legal hold has. Therefore, the client should complete and validate the export before losing access.
When processing personal data, the instructions, the return or deletion of data at the end of the service and the security measures must align with the roles and obligations of the controller and the processor.
Quick provider assessment grid
Coverage
Expected evidence: Inventory of the data, metadata, logs and settings included.
Warning sign: “We back up everything” with no list of exclusions.
Recovery
Expected evidence: RPO/RTO per service, granularity and procedure.
Warning sign: Indicative deadlines only, or deadlines counted from internal acceptance.
Resilience
Expected evidence: Separate environments, immutability and deletion control.
Warning sign: The same admin credentials for production and backup.
Testing
Expected evidence: A recent report, a comparable scenario and corrective actions.
Warning sign: A test limited to one file, with no time measurement.
Security
Expected evidence: Encryption, keys, access, logs, locations and sub-processors.
Warning sign: Generic answers with no named owners or evidence.
Operations
Expected evidence: Contacts, approval, escalation, communication and costs.
Warning sign: A process that depends on one person or an informal channel.
Exit
Expected evidence: Formats, scope, recovery period, support and deletion.
Warning sign: An export with no metadata or no reuse test.
Set objectives based on business impact
Do not choose an RPO and RTO just because the provider already offers them. On the contrary, they should stem from the impact of downtime and of losing changes. Thus, a simple analysis for each document process helps you avoid the same service level for everything.
Access authorisations
Main impact: Blocked or unauthorised entries.
Backup implication: Low tolerance; priority recovery.
Validations and rejections
Main impact: Lost decisions and rework.
Backup implication: Preserve history, comments and owners.
Legal/contractual documents
Main impact: Missing evidence and audit risk.
Backup implication: Retention and recovery aligned with validated requirements.
Configuration and permissions
Main impact: A process restored with the wrong rules.
Backup implication: Include it in scope or keep a documented rebuild procedure.
Informational content
Main impact: Limited operational impact.
Backup implication: Objectives proportionate to value and cost.
Shared responsibility: Four decisions you should not delegate
Classify how critical the information is and identify process dependencies.
Approve RPO, RTO, retention and recovery priorities with business owners.
Maintain contacts, internal procedures and the authority to request and validate a restore.
Test full continuity, including people, integrations, access and communication, not just the technical copy.
The provider controls the technology and delivers the contracted service. However, the organisation still decides what is critical, how much loss it tolerates and when the result is acceptable. For this reason, a simple, up-to-date responsibility matrix should record this boundary.
30-day review plan
Week 1
List your SaaS platforms and identify owners, critical data, integrations and contracts.
Week 2
Send the 12 questions and gather SLAs, security annexes, test reports and exit documentation.
Week 3
Compare needs with RPO/RTO, coverage and retention; record gaps, owners and accepted risk.
Week 4
Run or observe a representative test; update procedures, contacts, clauses and the improvement plan.
Frequently asked questions about SaaS platform backups
Is the SaaS provider always responsible for backup?
You should not assume so. The contract and the shared responsibility model determine the service provided, while the organisation keeps responsibility for classification, objectives, access, instructions and continuity. Confirm it in writing.
Does a periodic export replace a backup?
Not necessarily. It can support data sovereignty and exit, but it may not preserve versions, relationships, permissions, logs or the ability to restore quickly. Therefore, you should test it as part of a broader strategy.
What is a good RPO or RTO?
There is no universal value. The right objective depends on the impact of losing changes and on the maximum tolerable downtime for each process.
Does an immutable backup solve the ransomware risk?
It reduces the chance of someone changing or deleting the copy. However, it does not guarantee that the copy is clean, complete or recoverable, nor does it replace access control, detection, response and testing.
Do you need to test if the provider already has certifications?
Yes. Certifications can increase confidence in the management system and in the assessed controls. However, they do not show, on their own, that the provider has recovered your data and dependencies within your specific business deadline.
Which departments should take part in the assessment?
IT and security, the process owner, procurement, legal, data protection, continuity and document management. In this way, you avoid a decision that is purely technical or purely contractual.
From assessment to document operations
Backup quality also depends on how you administer the platform: identified owners, up-to-date access, documented settings, controlled changes and well-known procedures. In fact, a technically robust platform can remain vulnerable to informal processes or ambiguous responsibilities.
GEDOC Service covers the digitisation, configuration, technical administration and user support of document management platforms, based on the processes the client defines. As a result, this structured operation can help keep configuration information, responsibilities and procedures under control. It does not replace the definition of legal, security or continuity requirements by the organisation and the competent providers.
Next step: Choose a critical document platform and ask for documented answers to the 12 questions. If the provider cannot demonstrate the RPO, RTO, granularity, testing or exit, record the gap as a risk and assign an action with a deadline and an owner.
Discover GEDOC Service and see the related content on recovery validation and 3-2-1-1-0 backups.
Related articles
Backups, an AISP-GEDOC service
Recovery validation (Proof of Restore)
The importance of backups in document management
GEDOC Service, technical platform administration
Document history management policy
Editorial note and sources consulted
This article is for information only and targets organisations that assess SaaS services in Portugal and the European Union. It does not constitute legal, cybersecurity or continuity advice, nor does it confirm the features of any provider. Competent professionals should validate requirements, contracts, risks and measures.
Sources consulted on 4 August 2026:
EUR-Lex, GDPR, Articles 28 and 32
NIST SP 800-209, Security Guidelines for Storage Infrastructure
ENISA, Procure Secure: cloud security service levels
GEDOC, Backups, GEDOC Service and related articles
Further reading: How to choose a document management platform.