Defined implementation
Know how fast you could get the business running again.
The agreed restore scenarios are actually run. Recovery time is measured, the restored data is checked, anything that fails gets a named owner, and the recovery runbook is updated to match.
PricePrice fixed after a short scope call.
Delivery4 to 6 weeks
What you receive · illustrative sample
Know exactly what the recovery test proves.
Illustrative Microsoft 365 recovery record. The scope names the workload, backup source, safe restore target and agreed checks.
| Workload | Controlled validation | Recorded limits |
|---|---|---|
| Sample mailbox item | Restore to approved target; verify content | Selected item only |
| Sample SharePoint file | Restore and check permissions/version | Agreed file and version |
| Recovery ownership | Record timings, exceptions and next steps | Broader coverage scoped separately |
Meet the person responsible for delivery.
Alwatheq Zboun leads the agreed work. A sample shows the format; the statement of work defines your deliverable and acceptance checks.
Engagement context
When this engagement applies.
Backups exist, but nobody has completed and accepted a useful restore scenario.
Scope considerations
- One existing backup platform
- Microsoft 365 workloads only
- Client provides approved test targets
The defined work
Engagement scope.
- 01
The restore scenarios that matter are agreed first: which mailboxes, sites, and data sets, restored to where, accepted by whom.
- 02
Each agreed scenario is executed against approved test targets, and the recovery time is measured rather than estimated.
- 03
Restored data is checked against the original by someone who can tell whether it is actually useful.
- 04
Every failed or degraded restore is assigned a corrective action with an owner and a date.
- 05
The recovery runbook is updated to match what the tests actually showed.
Acceptance
Completion has an agreed standard.
Done when every agreed scenario passes, or a named corrective action has an owner and a date.
Backup coverage is verified system by system
Each agreed restore scenario has been executed and timed
Restored data is checked against the original
Anything that fails the test is written up with a fixed price to put it right
Commercial basis
Price, scope and timing are considered together.
Engagement price
Price fixed after a short scope call.
The price is agreed in writing before any work starts and before anyone is given access. The call itself costs nothing. What moves the number:
What determines the scope
- Number of systems in scope
- Number and complexity of restore scenarios
- Whether the detection and escalation path is included
- Volume of data to check after restore
Scope & responsibilities
The full engagement boundary.
Review the exclusions, required client participation, change controls and operational handover for this engagement.
Exclusions
- Live incident response or forensics
- Production failover or destructive testing
- On-premises, immutable-storage, or cross-platform recovery engineering
- SOC monitoring
- Building a backup platform where none exists — that is a separately scoped Recovery Foundation engagement
Client responsibilities
- Provide approved test users, sites, and data
- Approve the restore scenarios before testing begins
- Provide access to the backup platform
Change and rollback method
- Restores run against approved test users, sites, and locations inside agreed windows; production data is not overwritten.
- Nothing destructive: the tests read from backup and write to agreed test targets only.
- Failures stop the affected scenario and are recorded rather than retried silently.
Operational record and handover
- The restore test log, scenario by scenario, with measured recovery times
- Validation results for each restored data set
- The failure register, with a named corrective action, owner, and date per entry
- The updated recovery runbook
Before you commit
A clear first step.
You stay in control.
Start with the problem and the result you need. The initial fit conversation is free and does not require access to your systems.
Check client feedback on Upwork ↗Prefer to contract through Upwork? Contact Alwatheq there. Existing Upwork engagements continue through Upwork.
Who will actually do the work?
Alwatheq Zboun leads the scope, technical work and handover. If a specialist collaborator is needed, their role is agreed with you before work starts. Your proposal names the responsibilities and delivery windows.
What happens before you get access?
We agree the scope, fee and completion checks in writing. Access uses named accounts and only the permissions the work requires. Approved access is reviewed and removed at handover.
How do we know the change worked?
Your scope defines the pilot, test cases and acceptance checks. Results and exceptions are recorded. Recovery options and their limits are agreed before production changes; a failed check is addressed before the next approved stage.
Will we need an ongoing retainer?
A defined project can end at handover. Your team receives the agreed configuration records, runbook and walkthrough. Any limited support period is written into the proposal; ongoing support or additional work is a separate agreement.
Discuss this engagement
Put the scope in context.
Describe the problem, systems and deadline. Alwatheq will review the fit and the scope questions before preparing a written proposal.
Plan the Recovery Test