Know what comes back, and how long it takes.

• Administrative separation

  Backup operators do not automatically control every destructive safeguard.

  • Client-created identities with MFA and recorded expiry
  • Least-privilege access at the smallest practical scope
  • Independent ownership of Azure Resource Guard where used
  • No credentials, tenant exports, recovery codes, or keys through the public form

• Deletion and retention protection

  The page only calls a copy immutable after the actual platform state is verified.

  • Azure vault state distinguished as enabled or enabled and locked
  • WORM availability checked for the workload, vault type, and region
  • Microsoft 365 Backup append-only behaviour described separately from full immutability
  • Retention reduction, Microsoft 365 Backup offboarding (backup deletion after its grace period), soft delete, and approval paths recorded

• Isolated recovery validation

  A test proves the service path without treating production as a laboratory.

  • Approved recovery target matched to data classification and residency
  • Outbound access restricted where the platform supports it
  • Integrity, application, identity, and dependency checks
  • Recovery environment removed or retained under an agreed control after acceptance

• Measured evidence and handover

  The record captures what happened, including failures and residual risk.

  • Exact recovery point and timestamped drill timeline
  • Observed RTO and RPO compared with approved targets
  • Exceptions with owner, due date, and review date
  • Access-removal record and Exit Kit stored in the client repository

Retention, legal hold, version history, platform resiliency and a backup solve different recovery problems. The engagement checks whether the chosen mechanism covers the workload state, the retention, the storage separation and the restore path you need.

These references support the control decisions and the language on this page. Regulatory mapping remains implementation evidence, not legal advice or certification.

• Azure Backup immutable vaultMicrosoft Learn

  Locked immutability, WORM support, restricted destructive operations, and workload or region considerations.

• Azure Backup multi-user authorizationMicrosoft Learn

  Resource Guard, separate ownership, protected operations, and stronger isolation options.

• Microsoft 365 Backup overviewMicrosoft Learn

  Supported workloads, restore behaviour, append-only storage, and the limits of full immutability.

• AvePoint Cloud BackupAvePoint Learn

  The vendor's own list of backed-up workloads, with Exchange Online, SharePoint Online, OneDrive and Teams, and where the data is stored: with the default Azure Blob Storage, the data center you signed up for in AvePoint Online Services. Read 2026-10-29; the page carries no date of its own.

• DORA Regulation 2022/2554EUR-Lex

  Articles 11 and 12 cover continuity testing, backup policies, restoration, recovery, and segregated restore systems.

• NIS2 Directive 2022/2555EUR-Lex

  Article 21(2)(c) includes business continuity, backup management, disaster recovery, and crisis management.

• #StopRansomware GuideCISA

  Offline encrypted backups, regular availability and integrity testing, and infrastructure-as-code recovery guidance.

• SP 800-34 Rev. 1NIST

  Business impact analysis, recovery strategy, contingency planning, exercises, and plan maintenance.

Microsoft protects the availability and resilience of its services. Your organisation still chooses what data and workloads are protected, which recovery points are acceptable, who can alter the protection, how dependencies return, and how the business validates the restored service. Microsoft 365 Backup or Azure Backup can be part of the design. Neither replaces the recovery plan or the drill.

It proves that the job reached a successful state. Recovery proof also needs a selected recovery point, an approved target, integrity checks, application checks, dependency checks, observed timing, business acceptance, and a record of exceptions.

I start with the platform already in place. Replacement is recommended only when the existing recovery path cannot meet an agreed target, cannot provide the required separation, or cannot pass the drill.

The default is a controlled restore into an approved recovery target. Production failover, failback, or any action with production impact requires an explicit change window, separate acceptance criteria, and a reversal plan where the platform supports one.

The workload is not marked recoverable. The failure becomes an owned issue with evidence, residual risk, a due date, and a re-test condition. Finding that gap before an incident is what the drill is for.

No. The standard service designs, corrects, drills, and documents recovery. Live ransomware response, forensics, malware containment, and round-the-clock incident command remain with your retained SOC or IR provider. RUNBOOK-10 defines and rehearses that handoff.

Yes, as implementation evidence mapped to agreed control objectives. DORA Articles 11 and 12 and NIS2 Article 21(2)(c) are common references. This is not legal advice, certification, regulatory approval, or an assurance attestation.

I perform the engineering directly, with no subcontractors. Only I use the access you grant me. Your business and technical workload owners approve targets and acceptance. There is no account-manager handoff.

Yes. Ask to inspect any file from the ten-runbook set during discovery. The working versions live in your repository during delivery, not in a private ITSailor portal.

The Exit Kit exists from the start. It records the architecture, recovery targets, runbooks, evidence locations, open exceptions, ownership, and access removal. Cloud resources stay in your accounts. A licence bought through us can be moved to another provider or ended under the vendor's and Pax8's rules; the SoW records how and when before the licence is ordered.