We map each workload to an agreed RPO and RTO, separate recovery controls from production access, then restore into an approved recovery environment and record what happened. You leave with measured evidence, named runbooks, and an Exit Kit your team can operate.
Do not send credentials, tenant IDs, backup exports, recovery codes, or keys through the public contact form. Scoped access is arranged after approval, with MFA and recorded expiry.
Connected recovery surface
Recoverability
Measured
Data
Recovery points, retention, integrity
Identity
Operators, approvals, emergency access
Dependencies
DNS, network, secrets, upstream systems
Operations
Declaration, acceptance, communication, failback
Protected workload
Data, configuration, dependencies, and business owner identified.
Recovery point
Coverage, retention, access separation, and deletion controls verified.
Isolated target
Restore lands in an approved recovery environment, not over production.
Service validation
Integrity, application behavior, identity, DNS, secrets, and dependencies tested.
Evidence record
Observed RTO and RPO, exceptions, owners, and sign-off filed.
Single workload
One recovery path, one approved target, one measured drill, one runbook.
Recovery portfolio
Shared controls, local overlays, pilot waves, and evidence per workload.
10
Recovery runbooks already written and inspectable
RTO + RPO
Targets agreed first, observations recorded during the drill
Read-only
Coverage and configuration are assessed before change
Client-owned
Runbooks, evidence, decisions, and the Exit Kit stay with you
Two different controls
A restored database does not recover a service when identity, DNS, secrets, certificates, or upstream dependencies are missing. The engagement tests the full agreed path.
Backup
Quality depends on scope, frequency, retention, access separation, deletion protection, monitoring, and whether the selected point can actually be restored.
Disaster recovery
It names who declares the event, which dependencies return first, where the workload runs, how integrity is checked, when users can return, and how failback is approved.
Failure paths
Backup, identity, dependencies, validation, and operational authority often belong to different teams. The drill makes those joins visible.
An RTO in a contract is only a target. The BIA records who owns the impact and what event ends the recovery clock.
A compromised operator can reach both the workload and its recovery path. We inspect identity separation, least privilege, MFA, and destructive-operation approval.
Identity, DNS, certificates, secrets, queues, and upstream services can keep a restored database unusable. The dependency map travels with the runbook.
A successful backup job proves that a job completed. The drill measures the time from declared impact to the agreed business acceptance point.
Checksums and row counts matter, but users need a working service. Smoke tests and business-owner acceptance are recorded separately.
A technically valid recovery path can still stall. The runbook names the approver, operator, witness, communication owner, and escalation route.
The operating method
Inspect the sequence, switch between a single workload and a portfolio control model, then open the real delivery-kit structure. Motion pauses automatically for reduced-motion preferences.
Recovery control stack
We verify the actual platform state before using words such as immutable, isolated, or independently recoverable.
Backup operators do not automatically control every destructive safeguard.
The page only calls a copy immutable after the actual platform state is verified.
A test proves the service path without treating production as a laboratory.
The record captures what happened, including failures and residual risk.
Microsoft 365 is handled separately: retention, legal hold, version history, platform resiliency, and Microsoft 365 Backup solve different recovery problems. The engagement verifies whether the selected mechanism covers the required workload state, retention, storage separation, and restore path.
Measured evidence
The recovery evidence record links the approved target to the exact recovery point, the execution timeline, technical validation, business acceptance, exceptions, and re-test conditions.
Recovery evidence record
Approved targets
Workload-specific RTO and RPO
Named owner, business impact, acceptance point
Observed results
Populated during the drill
No pre-filled duration and no assumed pass
Protection state
Recorded from the actual platform
Retention, deletion controls, approvals, keys
Validation
Technical plus business acceptance
Integrity, application, identity, dependencies
Verdict logic stays explicit.
Both observed RTO and observed RPO must meet the approved target. Open issues can produce a pass with issues. A missed target remains a fail until remediation and re-test.
This record is operational evidence.
It is not an accredited certificate, legal opinion, regulator approval, or warranty. The control mapping helps an auditor trace implementation evidence back to the agreed objective.
Evidence chain
Scope and authority
Workload, owners, data classification, change window, access, abort criteria
Recovery-point decision
Exact point selected, reason, retention state, protection state, known gaps
Execution timeline
Timestamped actions, platform logs, manual dependencies, deviations
Validation and acceptance
Checksums, row counts, smoke tests, dependency checks, business-owner sign-off
Exceptions and re-test
Residual risk, owner, due date, review date, and the condition for a clean pass
Control references
DORA Articles 11 and 12
Continuity testing, backup policy, restoration method, segregation, and observed recovery results
NIS2 Article 21(2)(c)
Backup management, disaster recovery, business continuity, and crisis-management evidence
NIST SP 800-34 Rev. 1
BIA, recovery strategy, contingency plan, exercise record, and maintenance actions
The evidence pack
Every target, decision, owner, test result, and exception remains traceable without access to an ITSailor system. Human-readable artifact names lead; filenames stay visible as the inspectable source.
Ask to inspect a runbookRUNBOOK-07-bia-workshop.md
Business owner, criticality, dependencies, data classification, target RPO, target RTO, and the basis for each decision.
backup-and-dr-baseline-checklist.md
Coverage across data, configuration, identity, DNS, network, certificates, secrets, and upstream services.
immutable-backup-policy.md
Actual vault or platform state, retention, approval controls, key ownership, residency, and exceptions.
RUNBOOK-01 through RUNBOOK-10
Drill, failover, ransomware recovery, RPO/RTO validation, coverage audit, tabletop, restore from protected copy, and SOC/IR handoff.
dr-drill-report-template.md
Recovery point, timeline, observed results, integrity checks, business acceptance, exceptions, and follow-up owners.
control-mapping-matrix.md
Implementation evidence mapped to agreed DORA, NIS2, ISO 22301, and ISO 27001 control objectives where applicable.
EXIT-KIT-backup-and-dr.md
Final architecture, runbooks, ownership, evidence locations, open exceptions, and confirmation that ITSailor access was removed.
Delivery options
Pricing is scoped after the workload, platform, current protection, test target, and acceptance effort are understood. Licences and cloud consumption remain separate.
One workload or a focused platform slice
Establish what must recover, what protects it today, and which assumptions need testing.
Scoped to you
Outcome
A decision-ready recovery backlog and a safe plan for the first proof.
A selected critical workload
Correct the agreed recovery path and prove it in an isolated environment.
Scoped to you
Outcome
One workload with an observed result, signed exceptions, and a runbook your team can repeat.
A workload portfolio or multi-environment estate
Keep evidence current through controlled waves, rotating drills, and documented remediation.
Scoped to you
Outcome
A governed recovery programme without universal cross-portfolio credentials or hidden operational dependency.
Boundaries
The SoW names the workload, owners, access, recovery target, validation, platform costs, and operational handoffs before the drill is scheduled.
Public guidance
These references support the control decisions and the language on this page. Regulatory mapping remains implementation evidence, not legal advice or certification.
Current trust signals
Microsoft AI Cloud Partner. CSP Indirect Reseller active. PLA 7113951. Founder-led from Malta. Read-only discovery first. Runbooks and evidence remain in the client repository.
Microsoft Learn
Azure Backup immutable vault
Locked immutability, WORM support, restricted destructive operations, and workload or region considerations.
Microsoft Learn
Azure Backup multi-user authorization
Resource Guard, separate ownership, protected operations, and stronger isolation options.
Microsoft Learn
Microsoft 365 Backup overview
Supported workloads, restore behavior, append-only storage, and the limits of full immutability.
EUR-Lex
DORA Regulation 2022/2554
Articles 11 and 12 cover continuity testing, backup policies, restoration, recovery, and segregated restore systems.
EUR-Lex
NIS2 Directive 2022/2555
Article 21(2)(c) includes business continuity, backup management, disaster recovery, and crisis management.
CISA
#StopRansomware Guide
Offline encrypted backups, regular availability and integrity testing, and infrastructure-as-code recovery guidance.
NIST
SP 800-34 Rev. 1
Business impact analysis, recovery strategy, contingency planning, exercises, and plan maintenance.
FAQ
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.
We 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 useful work, not a cosmetic failure.
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.
The founder performs the engineering directly, with specialist agent review for architecture, security, evidence, and testing. 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. Licences and cloud resources remain in your accounts or are transferable through the agreed marketplace path.
Start with the workload whose loss would stop revenue, operations or a regulatory obligation. We define the target, inspect the current path and scope the safest way to prove it.
Recovery control room
Procedure view. No customer result or pre-filled performance claim.
One drill exposes every assumption.
The sequence follows RUNBOOK-01. Actual timings populate only while an approved drill is running.