Trust centre · For operational resilience and continuity reviewers
What happens on the worst day, written down before it arrives.
Continuity questions are asked late in procurement and answered badly under pressure. Ours are answered here: what is backed up, how it is restored, how quickly, and what has actually been exercised.
How to read the evidence status on this page
- Verified in product
- Implemented in the platform and covered by automated tests or recorded verification evidence.
- Controlled document
- Maintained as a version-controlled internal artefact, issued under agreement rather than published.
- In external assurance
- Scheduled with, or in progress with, an independent party. No external opinion is claimed until the report exists.
- Not claimed
- Deliberately not asserted. Stated openly so a reviewer never has to infer whether it exists.
| Claim | Status | What evidences it |
|---|---|---|
| Documented backup and recovery objectives | Controlled document | Recovery point and recovery time objectives are stated in the controlled backup and disaster-recovery document and reflected in the service schedule. |
| Scripted database and storage export, restore and verification | Verified in product | Export, restore and post-restore verification are scripted and version-controlled rather than performed by hand under pressure. |
| Rebuild from source control without vendor assistance | Verified in product | The full application, database migrations, configuration and runbooks are held in the customer-visible repository, and a documented recovery runbook covers a clean rebuild. |
| Incident severity model and notification commitments | Controlled document | Severity definitions, response targets and customer notification commitments are set out in the support policy and the applicable agreement. |
| Verified full restore drill against a clean environment | In external assurance | Scheduled. The restore procedure is scripted and internally exercised; the date of the last verified end-to-end drill is recorded and disclosed rather than assumed. |
| A published uptime percentage or availability history | Not claimed | Availability commitments are contractual and set out in the service level schedule. We do not publish a headline uptime figure we cannot yet evidence over a meaningful period. |
Exit and portability
Governance records, assessments, decisions and evidence metadata are exportable in structured form throughout the term, not only on exit. The application itself is held in source control, so the platform is not a route to lock-in.
Concentration risk and dependencies
AIRAS Cloud runs on a small, deliberately conventional set of managed services: an edge application runtime, a managed relational database with object storage, and transactional email. Each dependency is listed in the sub-processor register with its purpose and processing location.
We describe this to reviewers as concentration risk rather than resilience by default. It is mitigated by portable data formats, migrations held in source control and a scripted restore path, and it is disclosed so a DORA or NIS2 assessment can weigh it properly.
Incident handling
Incidents are triaged against defined severity levels with named internal ownership. Security incidents follow the same route as availability incidents, with an additional evidence-preservation step so the audit history of the affected period stays intact and reviewable.
Need the continuity and recovery documentation?
We will issue the backup and disaster-recovery position, the recovery runbook and the service level schedule under agreement, with the current exercise status stated.
No commercial commitment. No confidential information required.