Direct answer: Set RPO and RTO for a specific recovery scenario, not for "Microsoft 365" as a whole. Effective RPO is the time between the incident and the latest verified usable recovery point. Effective RTO is the time between the agreed recovery declaration and completion of the business acceptance criteria. A configured schedule, completed API call, or provider status is not either measurement.
Definitions That Can Be Tested
| Term | Operational definition | Common mistake |
|---|---|---|
| Target RPO | Maximum acceptable age of the latest usable recovered data at incident time. | Setting it equal to schedule frequency without checking failed jobs or completion lag. |
| Measured RPO | Incident time - latest verified usable recovery-point time. | Using the newest listed snapshot without proving the required object is present and readable. |
| Target RTO | Maximum acceptable time from defined recovery declaration to agreed business acceptance. | Measuring only provider processing and excluding authorization, search, conflicts, and verification. |
| Measured RTO | Acceptance time - recovery declaration time. | Stopping the clock at API or job completion before users verify the result. |
| Service commitment | A current written provider obligation with scope, conditions, exclusions, and remedy. | Turning an illustrative target or pilot result into an SLA. |
Microsoft's native Microsoft 365 Backup overview publishes workload-specific recovery-point cadence and performance expectations. Those statements apply to the documented native product and conditions; they are not North Brook Vault benchmarks and should not be transferred to another provider. Microsoft Graph collection and restore can also be affected by endpoint-specific limits and throttling, as described in Microsoft's Graph throttling guidance.
Scenario Worksheet
| Field | Required entry |
|---|---|
| Business event | [Accidental deletion, overwrite, corruption, account loss, site incident] |
| Source scope | [Tenant, workload, object type, identity/site, approximate item count or size] |
| Required point | [Latest acceptable date/time and reason] |
| Destination | [Original, alternate identity/site/path, export if independently supported] |
| Acceptance criteria | [Content, hierarchy, metadata, permissions, identifiers, usability] |
| Target RPO/RTO | [Approved values and business owner] |
| Recovery authority | [Requester, approver, operator, security contact] |
| Known constraints | [Unsupported object, throttle, conflict, overwrite risk, dependency] |
Measurement Procedure
- Approve the scenario: Use the backup policy template to record business owner, scope, target, destination, and acceptance criteria.
- Declare the test event: Record the synthetic incident time and recovery-declaration timestamp. State whether authorization time is inside the RTO clock.
- Find the latest usable point: Record all candidate points, item-level failures, and why the selected point contains the required object.
- Calculate measured RPO: Subtract the selected recovery-point timestamp from the incident timestamp.
- Start recovery: Record operator, initiation time, destination, conflict behavior, and provider or API job identifier.
- Track phases: Record search, authorization, queue, processing, retry, throttling, conflict resolution, verification, and user acceptance separately.
- Calculate measured RTO: Subtract the declared start from the final acceptance timestamp defined in the scenario.
- Decide: Pass, remediate, change architecture, narrow the commitment, or obtain explicit risk acceptance. Do not silently change the business target to match a failed test.
Illustrative Calculation
This is arithmetic, not a North Brook Vault result or benchmark. Suppose a test incident is declared at 14:00 and the latest verified usable recovery point is 12:00. The measured RPO is two hours. Recovery is declared at 14:15 after the agreed authorization step and business acceptance is recorded at 15:05. Under that scenario definition, measured RTO is 50 minutes. If the provider job completed at 14:50 but verification failed until 15:05, 14:50 is not the accepted RTO endpoint.
| Measurement | Illustrative value | Evidence required in a real test |
|---|---|---|
| Incident | 14:00 | Test record or incident declaration. |
| Latest usable point | 12:00 | Recovery-point ID, object presence, completion state. |
| Measured RPO | 2 hours | Timestamp calculation and reviewer. |
| Recovery declaration | 14:15 | Authorized request and defined clock start. |
| Business acceptance | 15:05 | Acceptance checklist and owner. |
| Measured RTO | 50 minutes | Timestamp calculation, phases, exceptions. |
Fidelity and Acceptance Checklist
- [ ] Content: Required item or collection opens and matches the selected point.
- [ ] Structure: Folder, library, list, mailbox, or site hierarchy required by the scenario is usable.
- [ ] Metadata: Required sender, recipient, dates, columns, labels, and properties are present or documented as changed.
- [ ] Permissions: Access required after recovery is correct; inherited and direct permissions are checked where applicable.
- [ ] Identifiers and links: Changed IDs, URLs, references, and application dependencies are recorded.
- [ ] Conflicts: Skip, overwrite, rename, merge, or alternate-destination behavior matches approval.
- [ ] Exceptions: Skipped, failed, or unsupported objects have an owner and business decision.
Test Evidence Record
| Test identity | [Ticket, date, operator, approver, business owner] |
|---|---|
| Source and point | [Tenant, workload, object, recovery-point ID/time] |
| Timing phases | [Declaration, search, authorization, queue, processing, verification, acceptance] |
| Measured values | [RPO, RTO, target comparison] |
| Fidelity result | [Checklist outcome, changed fields, failed items] |
| Decision | [Pass, remediation, risk acceptance, owner, due date] |
North Brook Vault Coverage and Limits
North Brook Vault is managed SaaS with provider-managed infrastructure and storage, scheduled full or delta-aware backup where supported, service-side monitoring, retention policies, and selective restore for supported handlers. It does not publish a universal RPO, RTO, or restore-throughput guarantee. Microsoft Graph throttling, object count, source and destination behavior, permission state, conflict handling, and requested fidelity can all affect results.
North Brook Vault does not offer customer-selected S3 or on-premises deployment, native Object Lock enforcement, OneDrive version-history capture, PST/PDF/ZIP export, compliance reports, or a zero-throttling guarantee. Teams messages, channel messages, and channel structures are not restorable. A target involving those unsupported capabilities cannot pass a North Brook Vault recovery pilot and needs another control or an approved exception.
Run this worksheet as part of the operations checklist. Retain the result after material workload, permission, retention, provider, or architecture changes.
Approval Decision
Approve an RPO/RTO only when the scenario, clock boundaries, recovery point, destination, acceptance criteria, measured result, constraints, and accountable owner are documented. Label untested values as targets, not capabilities or service commitments.
Review supported recovery paths Discuss an RTO/RPO consultation Estimate the approved recovery scope