Moving from an on-premises mail server to Microsoft 365 or Google Workspace transfers a genuine and substantial amount of operational risk. The provider runs the physical infrastructure, patches the platform, distributes services across regions and employs a security team larger than most customers’ entire IT departments. For the overwhelming majority of organizations, that is a clear improvement.

It also creates a predictable misunderstanding. Because so much responsibility moved, people assume all of it moved. The provider’s documentation describes the division, but many organizations do not examine it until they need a recovery, investigation or control the standard service was never designed to supply. The resulting gap is not a flaw in cloud productivity. It is an ownership problem.

What the provider takes on

The provider is responsible for physical facilities, hardware, the hypervisor and platform layers, platform availability, platform-level security and the durability of its storage. If a disk fails, your mailbox should not disappear. If a data center has an outage, the service is engineered to recover without each customer rebuilding it. When a platform vulnerability requires a provider-side patch, the provider deploys it.

That represents a standard most organizations could not reach independently at a reasonable cost. It removes server procurement, hardware replacement, much of capacity planning, operating-system maintenance for the service, and the fragile local infrastructure that once sat behind a single power circuit or internet connection. The correct response is not skepticism about the transfer. It is precision about where the transfer ends.

What remains with the customer

Your organization remains responsible for its data, identities, tenant configuration and users’ behavior. The platform will faithfully carry out authorized operations, including actions made by mistake or through a compromised identity. It cannot infer that an authenticated administrator did not really intend to weaken a policy, or that a synchronized deletion should be ignored.

Ownership also includes licensing and service lifecycle. A control visible in documentation may require a particular tier, an add-on or explicit configuration. Logs may exist but be retained for less time than an investigation needs. A feature may be enabled for new tenants and absent in an older one. Exact defaults and retention windows change over time and by service and license, so a defensible review checks the tenant that exists rather than relying on a generic checklist.

Durability is not recoverability

Data is where the misunderstanding becomes most expensive. The platform protects against provider-side hardware failure. That is durability. It does not promise indefinite recovery from every legitimate deletion, malicious action or synchronization error.

If a user deletes a mailbox and the available retention window passes, the data can be gone. If a compromised account deletes a SharePoint library and nobody notices for ninety days, the same problem appears. If a synchronization client corrupts a folder and the service replicates that change, the corruption becomes durable too. Replication works correctly in every one of those scenarios; it preserves the current state across infrastructure.

Typical default deleted-item retention windows across these services can fall in the range of 30 to 93 days, but exact periods vary by workload, license and configured policy. They are an operational grace period, not a backup strategy. Standard business tiers include no separate backup product by default. One hundred percent of the provider’s platform-side durability promise may protect against its hardware failure while providing no answer to a user error after applicable retention has expired. Check the actual service terms and settings rather than treating that range as a guarantee.

A useful recovery requirement starts with business questions. Which records must be recoverable? From what kinds of events? How far back might the organization discover a problem? How quickly must one message, one user or an entire workspace return? Legal retention, operational recovery and preservation holds are related but different objectives; one configuration should not be assumed to satisfy all three.

Identity is now the perimeter

An on-premises firewall created a crude but real boundary. In a cloud tenant, authentication and authorization carry much of that job. An attacker using valid credentials without an effective second factor is not probing from outside in the traditional sense. They are operating inside the tenant and can look like a legitimate user from any network in the world.

MFA should therefore cover every user, with stronger and more phishing-resistant methods prioritized for administrators and other high-impact roles. Disable legacy authentication paths that cannot enforce the intended controls. Keep emergency access accounts narrowly governed and monitored rather than using them for routine work. Separate daily productivity from privileged administration so that opening an email does not occur in the same session that can change tenant-wide policy.

Lifecycle discipline matters as much as login strength. Provision access from approved roles, review privilege on a schedule, and disable accounts promptly when people leave or change responsibilities. Contractors, guests, shared mailboxes, service accounts and application identities need owners and expiry or review dates. An inactive identity with valid access is still an entry point, even if nobody sees it in the employee list.

What identity monitoring should watch

The useful signals are authentication events, consent grants, mailbox rule creation, permission changes and administrative actions. Most are logged in some form by default; far fewer are routed to a human who can decide whether they are legitimate.

At minimum, evaluate alerting for these events

  • New inbox rules that forward or delete mail. Creating one is a classic early step in business email compromise because it hides replies and maintains visibility over a conversation.
  • OAuth application consent grants. A malicious application can receive persistent access to mail or files, and that access can survive a password change and a new MFA challenge.
  • Changes to authentication policy, conditional access rules or MFA enrollment. An attacker with administrative access may weaken the control that would otherwise remove them.
  • Elevation into any administrative role, including temporary or just-in-time assignments.
  • Impossible-travel and anomalous-location sign-ins for privileged accounts, interpreted alongside device and session context rather than treated as proof by themselves.

Also watch mass deletion or download, unusual external sharing, creation of forwarding addresses, addition of new credentials to applications, changes to audit settings and activity from rarely used administrative identities. Tune by impact and response capability. A large alert catalog routed to an unread mailbox creates the appearance of monitoring without its benefit.

Every alert needs an owner, severity, expected first action and escalation route. Test the route with a controlled event. Confirm that the alert arrives soon enough, contains the actor, source, target and time, and can be correlated with retained logs. If the team cannot investigate until logs have rolled off, the logging policy and the incident plan disagree.

Configuration is a control you own

A new tenant must work for a wide range of customers, so convenience often shapes initial behavior. Settings with real security consequences are left for the customer to choose. External sharing may allow anyone with a link. Guest access may let ordinary users invite outside parties. Legacy authentication may remain usable. Application consent may be open without administrative review. These are not failures in provider infrastructure; they are tenant decisions waiting for an owner.

For most organizations, anonymous sharing should be disabled or restricted with expiration and sensitivity controls. Guest invitations should be limited to defined roles and reviewed. User consent to applications should require an administrative workflow appropriate to risk. Legacy authentication should be blocked through the platform’s supported access controls. Mailbox and administrative auditing should be enabled, exported where necessary and retained long enough for the organization’s investigation needs. Retention beyond defaults should match legal and recovery requirements.

Do not apply a hardening template blindly. Inventory workflows first: scanners and multifunction devices that send mail, legacy clients, third-party archiving, line-of-business integrations, mobile applications, external collaboration and automated accounts. Then test policy in a limited group, examine sign-in and failure logs, remediate dependencies and expand deliberately. A security policy that is disabled after an unplanned outage produces less protection than a staged policy with an owned exception.

Record every exception with the business reason, affected identities, compensating controls, owner and review date. Exceptions without expiry tend to become invisible defaults. Review configuration on a cadence and after licensing, mergers, major integrations or provider changes. A secure tenant is not a one-time project because both business use and platform capability continue to move.

Backup, specifically

A third-party backup of cloud productivity data should be held outside the tenant and retained for a period the organization chose. It should cover mail, files and collaboration workspaces, and restore at the granularity of one item as well as an entire account. Administrative access to the backup should not depend solely on the production tenant whose compromise may trigger the recovery.

The common objection is that Microsoft or Google already replicates the data across regions. That is true and beside the point. Replication protects the service from infrastructure failure. It faithfully replicates an authenticated deletion, corruption or malicious change because those operations are valid from the platform’s perspective. Retention and recycle features are useful first-response tools, but they share a control plane and fixed conditions with the service they protect.

Cost is the second objection. Third-party productivity backup is typically a small fraction of licensing cost per user, and it changes a bad afternoon from a potential loss of a year of records into a bounded restoration task. The product still has to be operated correctly. Failed jobs need alerting, new users and workspaces must enter scope automatically, protected workloads must be inventoried, retention must be verified, and storage or license exhaustion must not fail silently.

Test restores rather than trusting successful job counts. Recover a single message, a folder with permissions, a user’s files and a representative collaboration workspace. Confirm metadata, versions, sharing and access where those matter. Record the recovery point, elapsed time, manual steps and any data the product could not restore. Periodically simulate recovery when the original account is unavailable, because an account takeover and an accidental deletion create different operational conditions.

An incident playbook for a compromised identity

Preparation should make the first hour unsurprising. When compromise is suspected, preserve the relevant audit and sign-in evidence, then contain active access according to impact. Disable or restrict the identity, revoke sessions and refresh tokens, reset authentication factors through a verified path, and review recent changes before assuming a password reset ended the event.

Inspect inbox rules, forwarding, delegated mailbox access, OAuth consents, application credentials, new authentication methods, role assignments, guest invitations, shared links and affected files. Determine whether the attacker accessed conversations that could support invoice fraud or impersonation, then involve the business owners who can warn customers or payment approvers. Search for other identities showing the same indicators. Restore data only after the destructive route is closed, or recovery may be overwritten again.

Exact steps differ between platforms and licenses, and some containment actions can disrupt evidence or legitimate automation. The playbook should point to current administrative procedures, name who is authorized to act, and state when legal, privacy, insurance or communications teams must be involved. Run a tabletop exercise before needing it.

Four questions for a tenant review

A leadership team does not need to memorize every platform setting. It should be able to get specific answers to four questions:

  • Where is our data backed up outside this tenant, and when did we last prove a restore?
  • Which external sharing, legacy authentication and open application-consent behaviors are still at default or accepted by exception?
  • Which administrative and authentication events create an alert that a human actually reads?
  • If a privileged account were compromised tonight, what evidence and process would tell us tomorrow?

The supporting operational review should also confirm privileged-role inventory, MFA coverage, inactive accounts, guest ownership, log retention, backup coverage and tested recovery times. Findings need owners and due dates; a dashboard without follow-through merely makes the gap visible.

The honest framing

Microsoft 365 and Google Workspace are more secure and reliable than what most organizations ran before, and we recommend them without reservation. The risk did not disappear. It changed shape: from patching servers to configuring tenant policy, from watching a network perimeter to monitoring identity, and from rotating tapes to making an explicit backup decision the standard platform will not make for you.

Those are easier problems than the ones they replaced, but only when somebody owns them. Define the line, assign the customer side, verify it through alerts and restore tests, and revisit it as the platform and organization change. Shared responsibility works well once the shared part stops meaning assumed by someone else.