Every Microsoft 365 buyer, at some point, asks the same question: "if Microsoft already retains my mail and files, why do I need a third-party backup?" The short answer is the Shared Responsibility Model (Microsoft, 2024) — Microsoft is responsible for the platform; the customer is responsible for the data. The longer answer is more interesting because it lives in the gap between Microsoft's default retention windows and the events an MSP actually has to defend against in 2026.
In South Africa specifically, the cost of getting that gap wrong is now well-quantified. The IBM Cost of a Data Breach Report 2025 puts the average South African breach at R44.1 million, with a 241-day lifecycle from initial compromise to containment (IBM, 2025). The bulk of that cost is recovery and remediation — exactly the work that turns into a different conversation when there is, or is not, a recoverable backup.
What Microsoft retains by default
Microsoft 365 ships with three retention windows that cover different surfaces. Exchange Online retains deleted items in a recoverable folder for fourteen days by default, configurable up to thirty. OneDrive and SharePoint hold deleted files in the recycle bin for ninety-three days, then permanently purge. Teams chat retention is governed by the tenant's broader retention policy, with no default user-recoverable window for hard-deleted messages (Microsoft, 2024).
Litigation Hold and Retention Policies extend these windows in defined ways. A user mailbox under Litigation Hold cannot be permanently deleted by the user — items moved to "purged" go to the Recoverable Items folder and stay there until the hold lifts. Retention Policies enforce minimum retention or maximum retention or both, depending on configuration. Both mechanisms are useful and neither is a backup.
The distinction matters because retention is about meeting a regulatory or legal obligation to keep data available; backup is about being able to restore a known-good state after a disruptive event. The two overlap but the failure modes are different. Retention assumes the system is intact; backup assumes the system is not.
Retention answers "can we produce this data if asked?" Backup answers "can we get back to a clean state if everything is on fire?" An MSP needs both, and Microsoft's native tools only cover the first.
Where native retention stops working
Four common scenarios sit outside the native retention envelope. The first is a SharePoint site deleted on day 93 — the recycle bin empties on the dot, and the data is gone even from Microsoft's perspective. The second is a misconfigured Retention Policy that auto-purges a finance mailbox under a "delete after one year" rule the admin set in 2022 and forgot about. The third is ransomware that encrypts and overwrites OneDrive files in place, then waits for the version history to age out. The fourth is a malicious insider who hard-deletes selectively across mailboxes and document libraries, then leaves before anyone notices.
Each of these has played out at scale in 2024 and 2025. The Mandiant M-Trends 2026 report puts global median dwell time — the time between initial compromise and detection — at twenty-five days, with internal-detection medians at nine days (Mandiant, 2026). For a SharePoint deletion that purges at ninety-three days, a twenty-five-day dwell leaves sixty-eight days of recovery window. For an in-place ransomware overwrite that ages version history out, the window depends on configuration and is sometimes hours, not days.
The point is not that Microsoft's retention is bad — it is well-engineered for the common case. The point is that the common case is not the case that puts an MSP in front of a regulator.
The audit-grade gap
A second kind of gap is forensic rather than recovery. An MSP responding to a Section 22 event under POPIA (Republic of South Africa, 2013) — security compromise notification — needs to demonstrate to the Information Regulator what data was accessed, when, and by whom. The regulator does not accept "we believe nothing was taken" as an answer; they ask for evidence.
Microsoft's native audit logs are useful here but they are operational logs, not forensic-grade evidence. They are not tamper-evident — an admin with sufficient privileges can modify them. They have a default retention window of ninety days for most tenants (longer with E5 / Defender / Purview Audit Premium licensing). And they do not chain-of-custody the data they describe.
An evidence-grade backup posture adds three properties that the regulator typically asks for: tamper-evident audit (a hash chain that breaks if any historical record is modified), chain-of-custody documentation (who saw what, when, with cryptographic proof), and destruction certificates (proof of when data was destroyed and how, satisfying POPIA Section 109).
RPO and RTO targets the industry actually meets
Recovery Point Objective (RPO) and Recovery Time Objective (RTO) are the two numbers an MSP should pin down before evaluating any backup vendor. RPO is the maximum tolerable data loss measured in time; RTO is the maximum tolerable downtime. The industry-standard RPO baseline for M365 backup is four hours — that is, six snapshots per workload per day. Anything weaker than that risks losing a full business morning of work between snapshots.
RTO splits between item-level restore (a single email, file, or list-item) and full-mailbox restore. Item-level RTO targets are typically under five minutes; full-mailbox RTOs measure in hours and depend on tenant size and Microsoft Graph throttling behaviour. Both numbers should be in the signed subscription agreement, not the marketing site.
POPIA Section 19, 22, 109 implications
Three POPIA sections drive the day-to-day backup posture for South African MSPs. Section 19 requires the responsible party to secure the integrity and confidentiality of personal information through "appropriate, reasonable technical and organisational measures." This is the section a regulator opens during an incident review. Encryption at rest, per-tenant key separation, and tamper-evident audit are how a vendor demonstrates Section 19 compliance operationally.
Section 22 is the security-compromise notification rule — when the responsible party reasonably believes personal information has been accessed or acquired by unauthorised parties, the Information Regulator and affected data subjects must be notified. The clock is not strictly defined in the Act but Information Regulator guidance treats "as soon as reasonably possible" as a tight window in practice. Backup-derived forensic evidence is what makes a Section 22 notification defensible.
Section 109 governs personal-information destruction once the lawful retention period ends. A regulator audit will sometimes ask for proof that data was destroyed, not just that it is no longer accessible. SHA-256 destruction certificates issued at purge time, and chained into the audit log, provide cryptographic proof that satisfies this requirement.
What evidence-grade backup adds on top
A vendor that takes the Section 19 / 22 / 109 obligations seriously typically ships five things. First, snapshot frequency that meets the four-hour RPO baseline across all four workloads — Exchange, OneDrive, SharePoint, Teams. Second, item-level point-in-time restore so the unit of recovery matches the unit of loss. Third, per-tenant cryptographic isolation so a misrouted restore fails at the storage layer rather than at an application policy check. Fourth, hash-chained audit so any tampering is mathematically detectable. Fifth, destruction certificates issued automatically at purge time, with the certificate hash chained into the audit.
None of these are exotic capabilities. They are the operational floor for any vendor that takes evidence-grade seriously. They are also the difference between a Section 22 notification that the regulator accepts and one that opens a deeper investigation.
References
IBM (2025) Cost of a Data Breach Report 2025. IBM Security. Available at: https://www.ibm.com/reports/data-breach (Accessed: 8 May 2026).
Mandiant (2026) M-Trends 2026 Report. Google Cloud / Mandiant. Available at: https://cloud.google.com/security/resources/m-trends (Accessed: 8 May 2026).
Microsoft (2024) Microsoft 365 Shared Responsibility Model. Microsoft Learn. Available at: https://learn.microsoft.com/microsoft-365 (Accessed: 8 May 2026).
Republic of South Africa (2013) Protection of Personal Information Act, No. 4 of 2013. Government Gazette of the Republic of South Africa.