There is a long-running pattern in backup vendor pitches: the disaster-recovery scenario, the on-fire data centre, the "ransomware took everything" headline. It plays well in marketing because it makes the cost of backup obvious. It plays badly in operations because the threats most MSPs respond to in any given week are not whole-tenant disasters. They are surgical — a single email, one client folder, a permission grant that should not have happened.
The unit-of-recovery question matters because whole-mailbox restore for a single deleted email is operationally expensive and customer-visible. The MSP has to coordinate user downtime, the restore consumes Microsoft Graph throttling budget, and the user gets a "your mailbox is being restored, please wait" experience for hours. Item-level restore avoids all of that.
Three real scenarios MSPs see weekly
The first scenario is the accidental delete. A user deletes a thread from three months ago, the recycle bin retention has aged out, and the user needs the original back today because a customer escalation references it. Item-level restore retrieves the specific message in under five minutes. Whole-mailbox restore on the same incident takes hours and disrupts the user.
The second is the ransomware overwrite. A laptop synced to OneDrive picks up a strain that encrypts files in place and waits forty-eight hours before triggering the ransom note. Whole-OneDrive restore would set the entire user back to yesterday's state, losing a day of legitimate work. Item-level point-in-time restore, scoped to the affected file paths, recovers only the encrypted files at the right pre-encryption snapshot.
The third is the malicious insider. A departing finance-team member deletes selected emails before handing in their laptop. The deletion is targeted: not a bulk dump, but specific threads with specific clients. Item-level restore recovers those specific messages. Whole-mailbox restore is overkill and signals to the (now suspicious) departing employee that they are under investigation.
The cost of whole-mailbox restore
Quantitatively: a typical 50GB business mailbox restore via Microsoft Graph completes in two to four hours depending on tenant load and throttling. The user mailbox is functionally read-only or unavailable during that time. If the restore is to a recovery folder rather than over the live mailbox, the recovery folder needs manual triage to identify the specific item and copy it back — which can take longer than the restore itself.
Qualitatively: every whole-mailbox restore is a customer-visible event. The user knows it is happening, the help-desk ticket flows, and the MSP is on the hook for explaining what was lost and what was recovered. Compare that with an item-level restore where the user reports a deleted email at 14:00 and has it back in their inbox by 14:05 with no awareness of the underlying mechanism.
Median internal dwell time is nine days; median global dwell time is twenty-five days (Mandiant, 2026). Both numbers fit comfortably inside a 90-day point-in-time restore window — provided the snapshots are there to roll back to.
What item-level looks like in practice
A practical item-level restore flow has four properties. The unit of restore is the item itself — a single message, file, list-item, or permission grant — not the container. The point-in-time selector lets the MSP pick any snapshot in the retention window, not just "yesterday." The destination is configurable: in-place over the current item, side-by-side as a new item, or to a recovery mailbox for triage. And the action is logged to the audit chain so a regulator audit can later reconstruct what was restored, when, and by which operator.
Vendors differ in how cleanly they implement these. Some cap point-in-time granularity at twenty-four hours, which is fine for most cases but inadequate when an attack window is shorter. Some restrict in-place restore to specific workloads and force side-by-side for others, which is operationally noisy. The capability matrix is worth scrutinising before signing.
POPIA implications
POPIA Section 19 requires "appropriate, reasonable technical and organisational measures" for the integrity of personal information (Republic of South Africa, 2013). When personal information is destroyed by an attack, restoration is part of meeting the integrity obligation. The Information Regulator does not require any specific RTO, but a vendor that cannot restore individual items efficiently makes the responsible party's post-incident posture weaker.
Section 22 — security compromise notification — is also affected. A clean, scoped restore reduces the population of affected data subjects, which tightens what has to be disclosed in the notification. A whole-mailbox restore that overwrites legitimate work creates a secondary integrity issue the regulator will ask about.
References
Mandiant (2026) M-Trends 2026 Report. Google Cloud / Mandiant. Available at: https://cloud.google.com/security/resources/m-trends (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.