A 2026 Sophos survey of 2,158 organizations hit by ransomware shows that 66% of those whose data was encrypted recovered it from backup, the highest rate in years, while the share that paid the ransom dropped to 48%. Yet the average recovery bill now sits at $1.7 million, highlighting the critical need for must-have security features for a Microsoft 365 and Google Workspace Backup.
Having a secure backup to fall back onto (pun intended) is a must-have in 2026. What makes one worth relying on is a specific set of controls: encryption that holds up in an audit, storage that a compromised admin account can't reach, and alerting that tells you something broke before a client does. That is why we've composed this guide of the critical features your backup should have. Use it when you're comparing vendors for your Microsoft 365 and Google Workspace data, and the more of this list a solution covers, the more confident you can be in it. Table of Contents
Microsoft 365 and Google Workspace Backup: Data Security and Encryption
Any serious backup solution encrypts data twice: in transit and at rest. What differs between products is where they apply encryption and who controls the encryption key.
AES-256 at Rest
AES-256 covers your data once it lands in storage, and it satisfies every compliance framework you're likely to run into. The part that differs is timing. Some products encrypt at the source, so the objects arriving in your bucket are already unreadable. Others hand the job to the storage provider and let server-side encryption handle it on arrival. Source-side encryption provides stronger protection because the backup solution encrypts data before transmission and keeps it encrypted in the storage bucket, regardless of how you configure the bucket.
Tip: Choose a backup solution that encrypts data at the source.
HTTPS in Transit
Cloud-to-cloud backup moves data twice: out of Microsoft's or Google's servers via API, then into your storage bucket. Both legs run over TLS.
The part worth checking is the credential authorizing that second hop. Scope it to a single bucket and a leak stays contained. Give it broad account permissions, which plenty of setup guides quietly do, and the key that writes your backups can reach everything else in that cloud account.
Tip: Limit backup credentials to a single storage bucket.
Customer-Controlled Encryption Keys
Some contracts require that the backup vendor be technically incapable of reading the data. BYOK handles that by keeping the keys in your own AWS KMS or Azure Key Vault. Two things you should keep in mind: losing the key loses the backup, permanently; you need to confirm restores still work if your KMS is unreachable during an incident. Worth pursuing when a client contract or a regulator demands customer-held keys. Otherwise it adds a failure mode you have to manage.
Tip: Use customer-controlled keys when compliance requires them.
Backup Resilience and Isolation
Encryption stops someone from reading your backup. It does nothing to stop them from deleting it. This section decides whether a compromised Global Admin account is an incident or an extinction event.
Object Lock and Immutability
Immutability means a backup copy cannot be changed or deleted until its retention period runs out, and it's enforced by the storage platform rather than the backup software. On S3-compatible storage, it’s Object Lock, and it works the same way on Amazon S3, Wasabi, and Backblaze B2.
Object Lock has two modes. Governance mode has an override built in, so the root account or anyone holding the bypass permission can delete locked data early, which is exactly the permission an attacker with admin access goes hunting for. Compliance mode removes the override. Nobody deletes that data before the clock expires, including you, or the provider's own support team.
MSP360 Backup for Microsoft 365 as well as Backup Google Workspace supports immutability on Amazon S3, Wasabi, and Backblaze B2, and there are two ways to apply it. Default Object Lock is set on the storage side and locks everything written to the bucket. Object Lock for GFS Backups works through retention policies instead, which are assigned per user and per service, so a client's mailboxes and their Drive data can carry different lock periods.
Tip: Enable immutability and apply a retention policy.
Air Gap and Isolation
Object Lock protects a copy an attacker can still reach. Isolation creates that distance instead, and you determine it by choosing where to store the backup. Keep it in the vendor's own cloud, and your production data and your recovery data depend on the same supplier’s infrastructure.
BYOC (Bring Your Own Cloud) is a different route. The backup writes into a storage account you own, under credentials you issue and rotate, on a platform with no connection to your Microsoft or Google admin accounts.
Air gap is stricter and worth keeping separate in your head. It originally meant something physical: tape in a vault, a drive on a shelf, a machine with no network path to anything. Nothing running on a schedule over an API qualifies. Isolation plus Object Lock is the workable substitute, where the copy stays reachable but can't be destroyed while the lock holds.
Our comparison of air-gap versus immutable backups goes further into where each one gives way.
Redundancy and Replication
Redundancy is what the storage class gives you for free: S3 Standard writes every object across at least three availability zones in a region, and you configure nothing to get it. Replication is a rule you write and pay for, and it's the only one of the two that can cross an account boundary, which is where it stops being durability and starts being isolation.
One default worth knowing. When you delete an object in a replicated bucket, S3 adds a delete marker at the source and doesn't copy it to the destination. AWS built it that way to keep the destination intact when something goes wrong upstream.
Tip: Replicate backups across separate locations or accounts.
Data Residency
The region that decides your compliance position is the one on the bucket, set when the bucket is created. It isn't the region your backup console runs in, and the two sit in different jurisdictions more often than you'd expect.
Metadata is the part that catches people out, since it doesn't always follow the data it describes. Ask a vendor where both land, and where support staff are sitting when they touch either.
Tip: Verify where your backup data and metadata are stored.
Three Layers, Three Different Jobs
Immutability prevents attackers from destroying the data but leaves it in a single account that could disappear. Redundancy fixes that by keeping copies in more than one place, and does nothing about credentials, since a valid key works the same for an attacker as it does for you. Isolation answers that one, and only holds if the copy it protects can't be overwritten. Each layer fails where the next one holds, which is why air gap and immutability get argued about as alternatives when they were never competing for the same job.
MSP360 offers a SaaS backup solution that covers all three, with the configuration in your hands rather than ours. Backups land in storage you own, so isolation is structural and redundancy comes from the provider and storage class you pick. Immutability runs on Amazon S3, Wasabi, and Backblaze B2, applied through the retention policy.
Tip: Combine immutability, redundancy, and isolation.
Identity and Access Security
Backup failures often stay invisible until a restore is needed. Alerts reveal operational problems early, while audit logs provide the trail needed to investigate them.
Two-Factor Authentication
Enforce it across every account rather than leaving it to individual admins to switch on. Then check the side doors, because API tokens, CLI access, and long-lived session cookies often authenticate without the second factor and reopen the door you just closed.
Tip: Enforce MFA for all backup accounts.
Role-Based Access Control
Not everyone who manages a backup needs to read what's inside it. MSP360 Backup for M365/Google splits this by sign-in: the provider role configures backups and retention with no visibility into content, while Global Admin or Super Admin gets the data and the restores. Keep routine work in the provider role. The roles and permissions guide covers the narrower roles underneath.
Tip: Grant users only the permissions they need.
OAuth and Least-Privilege API Access
Cloud-to-cloud backup should use OAuth-based application authorization instead of stored user passwords. Map each requested API permission to a backup or restore operation. Restores may require write access, but you should document it, limit it to the required workloads, and make it revocable.
Tip: Use OAuth with least-privilege API access.
Tightening Access Further
Three additional controls address different access paths.
Single sign-on
Brings console access under central identity management and simplifies offboarding. Disabling a user should end console access, but confirm how the product handles active sessions, fallback accounts, and service identities.
IP allowlisting
Limits console access to approved networks and works best with stable egress addresses. Because it can block emergency access, define and test a controlled exception path.
Separation of duties
Keeps production and backup administration under different identities. If one account controls both environments, compromising it may expose source data and recovery copies. Where supported, reserve deletion and retention changes for another role.
Tip: Use SSO, IP allowlisting, and separate admin roles.
Monitoring, Alerts, and Auditability
You may not notice backup failures until you need the data. Alerts expose unsuccessful or missed jobs, while audit logs show who changed the backup environment and when.
Email Alerts
Alert on failed or partially completed jobs, missed schedules, and missing completion signals. A daily success report can serve as a heartbeat, but only if someone notices when it stops.
Route alerts to a monitored address or ticketing system with defined ownership and escalation. Keep them separate from bulk automated mail so they remain visible.
Tip: Send backup alerts to a monitored channel.
Audit Logs
Confirm which events are recorded, how long logs are retained, and whether they can be exported by file or API. Retention should cover investigation and compliance needs; otherwise, forward the logs to a SIEM or archive them.
Record sign-ins, configuration and permission changes, restores, and deletions, together with the acting identity, target, timestamp, and outcome.
Tip: Log and retain all critical backup events.
Anomaly and Ransomware Detection
Some platforms compare each backup run against the user's normal rate of change and flag the outliers. Ransomware encrypting a OneDrive rewrites every file it touches, so the volume of changed data spikes well past baseline, and that spike is what gets caught. The limitation is timing, since the check only happens when the next backup runs. Treat this as an additional signal alongside Microsoft 365 or Google Workspace security alerts and endpoint detection, not a replacement.
Tip: Use anomaly detection as an additional security layer.
Secure Recovery and Backup Integrity
A backup provides value only when you can restore it completely and safely. Malware screening, integrity checks, and recovery testing validate different parts of that process.
Malware scanning before restore matters because ransomware crews sit in an environment for weeks before detonation, which puts the payload inside your recent restore points. Where the feature isn't available, restore into an isolated location and scan there before anything touches the live tenant.
Backup integrity verification checks whether stored data still matches what was written, usually through checksums or similar validation. It does not prove the backup captured everything. A job can finish with warnings while users or items fail because of licensing, authorization, or permission changes. Review per-user and skipped-item results, not only the overall status.
Recovery testing is the "0" in 3-2-1-1-0, and it's proven by restoring rather than assumed from a green dashboard. If your platform doesn't automate it, put a quarterly test in the calendar, time it, and write down what happened. Insurers and auditors have both started asking for that record.
Further reading Microsoft 365 Ransomware Recovery Guide
Further reading Google Workspace Ransomware Recovery Guide
The Security Features List for M365 and Google Workspace Backup
Score a product against it. Deliberate gaps are fine when your processes or storage configuration address them, but gaps become dangerous when you discover them during a restore.
If you enforce only three things, make them immutability with a retention policy that applies, backup data in storage you control, and backup administration separated from tenant administration. Those cover the failures that turn a bad week into a closed business.
MSP360 Backup for Microsoft 365 and Google Workspace runs on the BYOC model, with AES-256 at rest, HTTPS in transit, role-based access control, multi-factor authentication, audit logging, and immutable backups on Amazon S3, Wasabi, and Backblaze B2. The managed version adds multi-tenant management, white-labeling, and advanced alerting for MSPs running client domains at scale.
