Updated – Oct 16, 2026
Key takeaways
Before choosing a business cloud backup provider, verify that it can:
- Protect backup copies from ransomware, deletion, and tampering.
- Control access through MFA, SSO, role-based permissions, and administrative controls.
- Encrypt backup data in transit and at rest, with clearly defined encryption-key management.
- Restore historical versions from recovery points your organization can validate as trustworthy.
- Manage retention, reporting, audit logs, backup health, and preservation requirements centrally where applicable.
A backup platform needs to do more than create copies of data. It needs to give your organization reliable recovery options when production data becomes unavailable, corrupted, or untrustworthy.
Ransomware remains a significant source of data-loss and recovery risk. Verizon’s 2026 Data Breach Investigations Report found that ransomware was involved in 48% of breaches.
Sophos’s 2026 State of Ransomware research, based on 2,158 IT and cybersecurity leaders from organizations with 100 to 5,000 employees across 17 countries that experienced ransomware attacks, found that 56% of attacks resulted in data encryption. Among organizations whose data was encrypted, 66% used backups to recover data.
encryption. Among organizations whose data was encrypted, 66% used backups to recover data.
Five security checks for evaluating a cloud backup provider
A cloud backup platform should protect backup data from tampering, restrict access, encrypt protected data, support reliable recovery, and give IT enough visibility and control to manage protection at scale.
Validate these capabilities before purchase. Product terminology alone does not establish how a control works in practice.
| Security check | What to verify | Why it matters |
| 1. Backup isolation and immutability | Whether users, ransomware, compromised credentials, or unauthorized administrators can modify or destroy protected backup copies | Recovery depends on having protected copies that remain intact and available after an incident. |
| 2. Identity and access controls | MFA, SSO, RBAC, delegated administration, privileged-access boundaries, and auditability | Compromised credentials should not provide unrestricted access to backup data or policies |
| 3. Encryption and key management | Where encryption occurs, encryption in transit and at rest, and how keys are generated, stored, accessed, and recovered | Encryption protects confidentiality and key management affects both security and recoverability |
| 4. Recovery capability | Version history, recovery-point selection, restore workflows, alternate restore locations, and recovery testing | Backup has business value only when data can be restored within required recovery objectives |
| 5. Governance and administration | Policies, retention, alerts, audit logs, reporting, and preservation capabilities where required | Security and recovery controls need to remain enforceable as the environment grows |
1. Verify backup isolation and immutability
A secure cloud backup service should preserve recovery copies independently from changes to the source system or workload. Ransomware, accidental deletion, user activity, or unauthorized changes should not be able to alter protected historical versions.
Encryption and immutability address different risks. Encryption protects confidentiality. Immutability protects recovery copies from modification for the period they are intended to remain protected.
IT teams should also understand the provider’s deletion controls. Source-side ransomware resistance, administrator deletion protection, retention lock, WORM storage, and logical or physical isolation are related controls, but they are not interchangeable.
Confirm whether immutability protects existing backup data from modification, deletion, or both. Evaluate how retention policies, administrative permissions, and archive-deletion procedures affect that protection.
CISA recommends maintaining offline, encrypted backups and regularly testing their availability and integrity. Its ransomware guidance also warns that attackers may attempt to locate and compromise accessible backups.
Questions to ask the provider
- Are protected backup copies immutable?
- What does “immutable” mean in the provider’s architecture?
- Can source users alter or delete stored backup data?
- Can ransomware modify existing backup versions?
- Can administrators delete backup data before its retention period expires?
- What controls govern archive deletion?
- How are historical versions preserved?
- What happens if an administrator account is compromised?
- Are destructive administrative actions logged or subject to additional controls?
Ask the provider to demonstrate what happens to existing backup versions when source files are encrypted, modified, or deleted.
2. Evaluate identity and access controls
A backup platform should support strong authentication and least-privilege access.
MFA provides an important baseline. IT teams should also evaluate SSO, identity-provider integration, role-based access control, delegated administration, separation of administrative duties, and auditing of privileged administrative actions.
A help desk technician, for example, may need permission to assist with file recovery without receiving permission to change organization-wide backup, security, or retention policies.
Access controls to compare
Look for:
- Multi-factor authentication
- Single sign-on
- Identity-provider integration
- Role-based access control
- Delegated administration
- Separation of administrative duties
- Audit logging for privileged administrative actions
- Controls over who can restore another user’s data
- Controls over archive deletion and other destructive operations
- Authentication and privilege controls for service accounts, API clients, and emergency administrative access
Backup administration should receive the same access-control scrutiny as other critical business systems.
3. Review encryption and key-management controls
A cloud backup provider should clearly document how it encrypts protected data and how it generates, stores, accesses, rotates, recovers, and protects encryption keys.
Encryption terminology alone does not provide enough information for a security assessment. IT teams need to understand where encryption occurs and which parties have access to the keys required for decryption.
Encryption questions to ask
- At what point is data first encrypted?
- Which encryption standard protects stored data?
- Which protocol protects data in transit?
- How are encryption keys isolated?
- Where are keys stored?
- Who can access the keys?
- Can customers control their own keys?
- Can provider administrators access protected data?
- Where does decryption occur during restore?
- What recovery options exist if a key or required credential is lost?
- Can the provider decrypt customer data during any backup, recovery, or administrative workflow, and under what conditions?
Key management affects recoverability and confidentiality. Customer-controlled encryption configurations may provide stronger key isolation, while some configurations can make backup data permanently unrecoverable if required credentials or keys are lost.
The provider should document these tradeoffs before deployment.
4. Test the ability to recover trustworthy data
Evaluate a cloud backup provider on recovery performance and recovery quality.
NIST guidance on ransomware recovery emphasizes restoring data quickly while maintaining confidence in its accuracy and integrity. Recovery testing should therefore be part of the vendor evaluation process.
In a ransomware scenario, IT teams should be able to determine:
- Which files or objects changed
- Which recovery point should be used
- Whether individual files or objects can be recovered
- Whether data can be restored to another location or device
- How long recovery takes
- Whether the restore process can be monitored and audited
Selecting a trustworthy recovery point may require information from security monitoring, incident-response tools, application owners, and malware analysis. Backup history provides the available recovery points, while the broader incident-response process helps determine which recovery point is appropriate.
What a recovery test should include:
Test:
- Recovery of a deleted file or object.
- Recovery of an older version.
- Recovery after a simulated ransomware event.
- Administrator-initiated recovery.
- End-user recovery, if supported.
- Recovery to an alternate location or device.
- Recovery of a larger dataset.
- Post-restore validation of data integrity and malware status.
Use the test to validate both recovery objectives.
Available, usable recovery points should be recent enough to satisfy the organization’s recovery point objective, or RPO. Recovery testing should also measure the time required to restore data, validate its integrity, and resume affected operations within the recovery time objective, or RTO.
A successful backup job does not demonstrate that recovery will meet business requirements.
5. Confirm IT can manage security and governance at scale
A cloud backup platform should allow IT teams to centrally manage policies, monitor backup health, investigate administrative activity, and control retention.
These capabilities become increasingly important as users, devices, workloads, storage requirements, and compliance obligations change.
Administrative capabilities to compare
Depending on your organization’s operational and regulatory requirements, evaluate:
- Centralized backup policies
- Configurable backup schedules
- Retention and version policies
- User and device visibility
- Backup-health reporting
- Alerts for missed or failed backups
- Role-based administration
- Audit-log event coverage, retention periods, and export capabilities
- API access
- Legal-hold or preservation capabilities
- Storage-location controls
- Network or resource throttling
- Centralized restore monitoring
Audit logs are especially valuable during security investigations and compliance reviews because they help establish which administrative actions occurred, who performed them, and when.
How cloud backup fits into the 3-2-1 backup strategy
The traditional 3-2-1 backup strategy calls for:
- Three copies of your data, including the production copy
- Two different storage media or storage types
- One copy stored offsite
Cloud backup can form part of that strategy. When using cloud storage, evaluate whether backup copies are separated across appropriate administrative and infrastructure boundaries. Multiple copies in the same environment may still share vulnerabilities or points of failure.
Modern ransomware threats have also increased the importance of isolation, immutability, access controls, and recovery testing. Some organizations extend the traditional model with an additional offline or immutable copy and verification that backups can be restored successfully.
Copy count alone does not determine whether data is recoverable.
For each recovery copy, determine whether it is:
- Protected from tampering
- Appropriately isolated
- Encrypted
- Access-controlled
- Recent enough to satisfy recovery requirements
- Covered by appropriate retention policies
- Regularly tested through recovery
Multiple backup copies provide more value when the organization has also verified that those copies can support its recovery process.
A practical backup-provider validation checklist
A provider evaluation should include evidence, not just feature claims.
| Provider claim | Evidence to request |
| Backups are immutable | Demonstration of protection against modification and deletion, including retention-policy enforcement and permitted user and administrator deletion workflows |
| MFA and RBAC are supported | Role matrix, authentication configuration, and a demonstration using representative IT roles |
| Data is encrypted | Encryption architecture, protocols, algorithms, and key-management documentation |
| Recovery is fast | A timed restore test using a representative dataset and the organization’s recovery objectives |
| Historical versions are retained | Retention-policy documentation and demonstration of version recovery |
| Administrative activity is auditable | Sample audit records showing privileged and destructive actions |
| Ransomware recovery is supported | Demonstration of restoring data from a historical recovery point after simulated source encryption |
| Backup supports compliance requirements | Documentation covering retention, preservation, data residency, and administrative controls relevant to your environment |
This type of validation helps IT teams distinguish a documented control from a marketing claim.
How CrashPlan maps to these five security checks
CrashPlan provides backup and recovery capabilities for data stored on endpoints, servers, and SaaS applications such as Microsoft 365 and Google Workspace. Organizations should evaluate the applicable CrashPlan product and plan against the same security and recovery requirements used for any backup provider.
The capabilities below apply specifically to CrashPlan’s endpoint backup offering. Security controls, recovery workflows, and feature availability may differ for server, Microsoft 365, and Google Workspace backup..
| Security check | CrashPlan capability | What buyers should verify for their environment |
| Backup isolation and immutability | CrashPlan documentation describes immutable backup copies for endpoint backup | Confirm how immutable backup copies are protected, how retention policies govern historical versions, and which user or administrator actions can permanently remove backup data. |
| Identity and access | Microsoft Entra ID integration, SSO, RBAC, delegated administration, and CrashPlan 2FA for locally authenticated users | Confirm identity-provider configuration, required administrative roles, and the MFA enforcement model |
| Encryption | AES-256 encryption at rest and TLS 1.2 or later in transit | Confirm where encryption occurs and how data is encrypted and decrypted for the restore methods your organization plans to use |
| Encryption-key management | Configurable encryption-key options, including customer-controlled configurations | Determine the appropriate balance between administrative recovery capabilities and key isolation |
| Recovery | Employee self-service and administrator restore, historical versions, and alternate restore locations | Test representative recovery scenarios against internal RPO and RTO requirements |
| Administration | Central policy management, configurable reports and alerts, RBAC, and delegated administration | Validate administrative workflows using representative IT roles |
| Auditability | Searchable audit logs and API access for audit events where supported by the applicable subscription | Determine which events security and compliance teams need to monitor and retain |
| Retention and legal hold | Configurable version aging and retention; legal hold is available with CrashPlan Enterprise | Confirm Enterprise licensing, preservation-policy scope, encryption-key requirements, and the handling of data when legal holds are released. |
CrashPlan’s endpoint documentation states that endpoint backup uses AES-256 encryption at rest and TLS 1.2 or later in transit and supports role-based access, policy-based retention, audit trails, configurable encryption-key management, and immutable backup copies.
Organizations evaluating immutability should confirm exactly how retention and deletion controls operate within the product, including which administrative actions remain possible and how those actions are recorded.
For users who authenticate with a CrashPlan password, organizations can enable CrashPlan two-factor authentication. Users authenticating through SSO receive their MFA requirements from the organization’s identity provider.
CrashPlan also documents multiple archive encryption-key security options. Its standard configuration retains administrative recovery capabilities. Advanced archive-password and custom-key configurations can restrict administrator access and may increase the risk of permanent data loss if required credentials or keys are lost.
Audit Log records provide information about administrative activity. Audit events can be searched in the console, exported to CSV, or accessed through the CrashPlan API when API access is included and appropriately configured. CrashPlan’s endpoint Audit Log retains events for 90 days. Organizations requiring longer retention can export events to external systems, subject to the applicable API access and configuration.
Legal hold is available with CrashPlan Enterprise. It uses preservation policies, matters, and custodians to preserve covered backup data according to the organization’s legal-hold requirements. The scope of preserved data and the ability to collect it depend on preservation-policy exclusions and encryption-key configuration.
Common questions about business cloud backup security
What security features should a cloud backup provider have?
A cloud backup provider should support encryption in transit and at rest, strong authentication, role-based access, protected recovery copies, historical versions, retention controls, administrative audit logs, and tested recovery workflows.
Additional requirements may include customer-controlled encryption keys, data-residency controls, legal hold, APIs, or advanced administrative controls.
The appropriate combination depends on the organization’s security, compliance, and recovery requirements.
Why are immutable backups important for ransomware recovery?
Immutability helps prevent protected backup data from being changed during the period in which it is intended to remain protected.
This matters for ransomware recovery because attackers may try to delete, encrypt, or otherwise compromise accessible backups before demanding payment.
Organizations should confirm exactly what a provider means by “immutable,” including whether source users, ransomware, administrators, or compromised privileged accounts can alter or delete backup data. Evaluate whether the provider’s immutability controls prevent modification, deletion, or both, and whether privileged administrators can override those protections.
Is encryption enough to secure cloud backup?
Encryption protects backup data confidentiality.
A complete backup-security strategy also needs to address authentication, administrator privileges, backup isolation, immutability, key management, retention, auditing, monitoring, and recovery testing.
Should cloud backup use MFA?
MFA should be required for interactive administrative access to backup systems and enforced for other user accounts according to the organization’s security policies.
Organizations using SSO should determine whether the backup provider enforces MFA directly or whether the organization’s identity provider does. They should also verify how emergency, service, and locally authenticated administrative accounts are protected.
Should businesses test cloud backup restores?
Yes.
Recovery testing should include actual restoration rather than relying solely on successful backup-job status. Testing helps verify that recovery points are available, backup data is usable, administrators understand the recovery process, and restore performance can satisfy business requirements.
CISA recommends regularly testing backup procedures and verifying the availability and integrity of protected data as part of disaster recovery planning.
What is the difference between backup retention and backup immutability?
Retention determines how long backup data or historical versions are kept.
Immutability determines whether protected backup data can be changed during the period in which it is intended to remain protected.
A backup strategy may require both. A long retention period does not automatically make a backup immutable.
Is Microsoft 365 retention the same as independent backup?
Microsoft 365 includes native retention, versioning, recycle bin, and recovery capabilities. Microsoft also offers a separate Microsoft 365 Backup service for SharePoint, OneDrive, and Exchange Online.
These capabilities and independent backup platforms may address different recovery, operational, security, and governance requirements.
Organizations should compare recovery-point availability, retention periods, restore granularity, administrative and storage independence, cost, compliance requirements, and recovery objectives before deciding whether independent backup is necessary.
Read: How Long Should You Retain Microsoft 365 Data?
What does CrashPlan provide?
CrashPlan provides backup and recovery capabilities for endpoints, servers, Microsoft 365, and Google Workspace.
Available capabilities vary by product, plan, workload, and storage configuration. Organizations should verify workload coverage, storage options, retention, recovery features, security controls, encryption-key management, auditability, and preservation requirements as part of their evaluation.
Choose a provider based on recovery evidence
Security features matter because they protect the organization’s ability to recover.
A strong vendor evaluation should establish how backup copies are protected, who can access or delete them, how encryption keys are managed, which recovery points are available, and whether representative restores can meet business requirements.
Testing these controls before an incident gives IT teams a more reliable measure of resilience than feature lists alone.
About the Author
