Outcome · Always-on operations
Always-on operations. Documented, tested, regulator-ready.
When your core systems can't go down, when your regulator wants evidence of recovery, when an unplanned outage is measured in millions — you don't need a plan on a shelf. You need a tested, evidenced posture that says: we know exactly how this recovers.
The problem we solve.
Your last failover test was probably more than a year ago.
Your last failover test was probably more than a year ago. Your runbooks reference servers that have been replaced. Your regulator is asking for evidence, not intention.
Across the region, business-critical platforms run on DR plans drafted years ago and rarely tested end-to-end. The team that wrote them has moved on. The infrastructure has changed. And the gap between what the document says and what the system can actually do widens every quarter.
At the same time, SAMA SCF and NCA-ECC are tightening expectations on RPO/RTO targets, evidence retention, and proof of test cycles. The regulator's question is no longer "do you have a DR plan?", it's "show me when you last recovered, and show me how."
A posture you can prove.
Not just a plan. A tested, evidenced operating posture for every workload that matters.
PILLAR.01
100%
Workloads with RPO/RTO targets
Every production workload classified, mapped, and assigned a target — signed off by the business owner.
PILLAR.02
Annual
Failover validated
End-to-end failover triggered under controlled, audit-witnessed conditions — at least once a year.
PILLAR.03
0
Manual recovery procedures
Site-by-site improvisation retired. Recovery runs from a single, versioned, tested set of runbooks.
PILLAR.04
Hours
Auditor evidence ready
Not weeks of scrambling. Control mapping, test results, and runbooks ready for submission.
What this looks like delivered.
The architecture spans four layers, with every layer evidenced by the time we hand over.
Source to recovery, in four evidenced layers.
A typical engagement runs 10–14 weeks across discovery, architecture, replication build-out, validated failover, and warranty. We embed alongside your platform team, never throw work over the wall, and the cutover is rehearsed before it is real.
01
Source
Branch & HQ production, Core ERP / banking, Legacy on-prem
02
Replication
CDC streams, Block-level snapshots, Encrypted transit
03
Cloud DR
Compliant cloud region, RPO/RTO policy engine, Tamper-evident audit log
04
Recovery
Validated failover runbooks, Auditor evidence pack, Branch service resumption
10–14 weeks. Five rehearsed phases.
Embedded with your platform team, not thrown over the wall. The cutover is rehearsed before it is real.
01
Discovery
Portfolio map, workload classification, current-state recovery posture.
02
Architecture
Target architecture, residency, RPO/RTO per workload, signed off.
03
Replication build-out
CDC streams, encrypted transit, policy engine, tamper-evident audit log.
04
Validated failover
End-to-end test under controlled, audit-witnessed conditions. Evidence captured.
05
Warranty
Embedded support window. Handover into managed-service tier.
// 05 · Audit evidence pack
What's in the evidence pack.
The regulator's question is no longer "do you have a DR plan?", it's "show me when you last recovered, and show me how." The evidence pack is the answer, packaged before they ask.
Request a sample packControl mapping
Workload → NCA ECC + SAMA SCF clause references.Failover test results
Witnessed run, observed RTO/RPO, captured deviations.Versioned runbooks
One source of truth, Git-tracked, signed-off, restorable.Tamper-evident audit log
Append-only, signed, retained per regulator window.NAS did not just design a plan — they built it, tested it, and handed us the evidence. We can now stand in front of an auditor and show them exactly how we recover.
IT Director
· Shaker Group
Read the case study
Three services. One delivered outcome.
This outcome is composed from our services. Each does one thing well, together they ship the posture above.
// service.01
DR Services
Architecture, runbooks, validated failover, and the warranty period. The delivery spine of this outcome.
Open DR Services // service.02Cloud Services
Compliant cloud region, residency, encryption, and the platform that the recovery posture sits on.
Open Cloud Services // service.03Migration
Workload migration, cutover orchestration, and the no-business-hour-downtime window engineering.
Open MigrationHonest questions.
Q.01What are the typical RPO and RTO targets we should expect?
For tier-1 workloads we routinely deliver RPO under 15 minutes and validated RTO under 1 hour. Targets are set per workload after the discovery phase, signed off by the business owner, and tested before handover, not just declared.
Q.02How long does a typical engagement run?
A typical engagement runs 10–14 weeks across discovery, architecture, replication build-out, validated failover, and warranty. We embed alongside your platform team rather than throwing work over the wall.
Q.03What goes into the audit evidence pack?
Control mapping against NCA ECC and SAMA SCF, versioned recovery runbooks, the witnessed failover test results, and the tamper-evident audit log from the cloud DR region. Submission-ready in hours, not weeks.
Q.04Do you keep data inside Saudi Arabia?
Yes. The recovery posture is built in a compliant cloud region inside KSA, with encrypted transit and tamper-evident audit logging, meeting residency expectations under NCA ECC and the Personal Data Protection Law.
Q.05What happens after the cutover, do you stay involved?
Yes. The managed-service tier of the engagement covers ongoing operations, the annual witnessed failover test, runbook refresh cycles, and continuous control evidence, so the posture stays current as the estate evolves.
// 08 · Engage
Book a 30-min outcome briefing.
We walk through your current posture, where the gap is, and what closing it looks like. No deck, no pitch, and an honest assessment of fit before you commit.