Operational Resilience

Platform resilience is treated as an extension of your operational risk management — not as a standalone IT programme. Hazards are identified, assessed, and mitigated through layered controls so that no single failure removes assurance over your data or service.

For airline-scale deployments we emphasise controls that stand up to internal audit, regulatory scrutiny, and enterprise third-party risk assessment:

• Access and authority — role-based permissions aligned to nominated posts and operational responsibilities; least-privilege assignment; segregation between production and non-production environments where agreed.
• Data integrity — strict tenant segregation; controlled change and release management; immutable audit trails on security-relevant and compliance-critical actions.
• Service continuity — redundant hosting patterns where contractually required; continuous health monitoring; documented escalation and response procedures.
• Supply chain assurance — assessed infrastructure and service partners; contractual safeguards; documented recovery paths that avoid sole-source dependency.
• Organisational resilience — documented runbooks, delegated authority, and break-glass access with mandatory post-use review so continuity does not depend on one individual.
• Assurance evidence — security and resilience documentation available to support your due diligence, vendor risk review, and safety or quality audit packs.

Operational, airworthiness, and safety records held in AirOS are protected through encryption in transit and at rest. Protection copies are taken on an agreed schedule, retained in geographically separate storage, and access-controlled to the same standard as production data.

Backups are designed to support restoration of fleet records, work packages, controlled documentation, occurrence reports, and attachments. We do not treat backup as a checkbox exercise — restore capability is validated through periodic exercises, with outcomes recorded for assurance review.

Recovery time and recovery point objectives are planning parameters agreed with you at contract stage. They reflect your deployment model, fleet scale, data residency requirements, and operational criticality. Published planning defaults for managed service deployments are indicative only until confirmed in your agreement.

• Service restoration — return to agreed operational use following major failure, scoped to modules in your entitlement and subject to validated recovery procedures.
• Maximum tolerable data loss — recovery point aligned to your operational criticality and backup frequency; agreed explicitly rather than assumed.
• Controlled documentation and attachments — restoration procedures account for large evidence files and controlled manual libraries.
• Derived data — where analytical or search outputs can be regenerated from source records, recovery prioritises source record integrity and traceability over speed of auxiliary function restoration.
• Data residency — hosting geography and cross-border transfer controls can be agreed for operators with sovereignty or regulatory placement requirements.

AirOS is designed to fail in a controlled manner. Where a component is impaired, the platform must not accept changes that could compromise airworthiness or safety records. Integrity takes precedence over convenience.

Under normal conditions the platform operates at full capability within your agreed entitlement. When partial impairment occurs, service may continue in a degraded mode that prioritises read access to fleet status, released documentation, open defects, and compliance evidence over non-essential functions. Where read-only operation is activated during recovery, edits are blocked rather than queued into an inconsistent state.

Safety-critical and compliance-affecting decisions remain with your accountable personnel at all times. Assisted capabilities — including AI-supported drafting or analysis — are decision-support tools only. They may be suspended during impairment or assurance review so that established manual procedures and nominated postholder authority remain definitive.

For managed and dedicated hosting, redundant capacity and failover patterns are employed to reduce the likelihood of full outage, within the architecture agreed for your deployment. For on-premise releases, continuity rests on your approved infrastructure and disaster recovery plan; AirOS provides release packages, deployment guidance, and can support joint validation of your local resilience design.

• Full service — all entitled modules and integrations available within agreed performance parameters.
• Degraded service — essential records and operational dashboards prioritised; non-critical functions may be temporarily unavailable with clear operator notification.
• Contingency — coordinated recovery with defined customer communication, restoration sequence, and post-event review suitable for your internal investigation and safety reporting processes.

The same assurance principles apply across deployment options. Responsibility boundaries are defined explicitly in your agreement and supporting documentation — particularly important where AirOS interfaces with engineering, maintenance control, flight operations, and safety departments across multiple sites.

• Managed service — AirOS operates the environment, applies platform protection measures, monitoring, and incident response, and maintains recovery procedures on your behalf within agreed scope.
• Dedicated hosting — logically isolated environment with customer-specific configuration, access controls, and resilience parameters agreed to your enterprise standards.
• On-premise release — your organisation hosts AirOS within approved infrastructure; you retain responsibility for physical security, network resilience, backup media, and local recovery, with AirOS providing controlled release packages, update guidance, and optional joint assurance activity.
• Hybrid arrangements — where operational policy requires certain data classes or functions to remain on-premise while others are hosted, architecture and responsibility can be scoped accordingly.

Airline operators require predictable change. Platform updates are released through controlled processes with advance notification for material changes affecting availability, integrations, or data handling.

Where your assurance programme requires it, we can agree maintenance windows, staged rollouts, or validation periods before changes affect your production environment. Configuration affecting compliance workflows, permissions, or record retention is subject to the same discipline.

When a security or service event may affect customer data or availability, AirOS follows a defined incident response process: detect, assess severity, contain, restore service, and conduct post-incident review.

Affected customers are notified in accordance with contractual terms and applicable regulatory obligations. Communications are structured to support your own continuity planning, safety reporting, and internal escalation — with a single coordinated message to avoid conflicting instructions to operational staff.

Post-incident reports can be provided to support your quality, safety, or security review, subject to confidentiality and the scope agreed in your contract.

Beyond technical recovery, we maintain organisational measures so that AirOS can continue to serve customers if key personnel or suppliers are unavailable — including documented procedures, delegated authority, break-glass access controls with post-use review, and credential or source-code escrow arrangements for enterprise customers who require vendor-failure continuity assurance.

We expect large operators to align AirOS configuration with their business continuity plan and to exercise recovery scenarios relevant to their approval basis — particularly where AirOS holds records referenced in your manual of compliance, MOE, MOC, or safety management system. We will support reasonable joint test activity where contractually agreed.

• Due diligence packs — security, resilience, and subprocessors documentation available for vendor risk assessment.
• Airline assurance annex — concise procurement Q&A at air-os.app/operational-resilience/airline-assurance.
• Audit cooperation — reasonable assistance for your internal audit, regulatory preparation, or appointed representative review, within agreed scope.
• Subprocessor transparency — infrastructure and service partners disclosed for your third-party risk review.

Resilience is a joint obligation and must be validated for your specific operation. AirOS provides the platform controls described here; your organisation remains responsible for user access governance, endpoint and network security at your sites, integration with existing OCC and engineering systems, validation that deployment choices meet your AOC and internal standards, and operational procedures when service is degraded.

We do not recommend reliance on any platform capability — including assisted features — without the review gates and nominated postholder authority your approval basis requires.

For further detail on data handling and security controls, see our Security & Privacy policy. For AI-specific assurance, see our AI Policy.

For resilience, continuity, vendor assurance, or security due diligence — including questionnaire response and nominated-post review — contact [email protected].

AirOS Operations Ltd · Rose Chapel, Main Road, Gloucestershire, GL13 9JN