AirOS Airline Assurance Annex

This annex provides concise responses to questions commonly raised during airline vendor assurance, third-party risk review, and safety or quality audit preparation. Answers describe AirOS design intent and standard enterprise arrangements; specific commitments, evidence packs, and recovery parameters are confirmed in your contract and supporting schedules. For questionnaire completion or nominated-post sessions, contact [email protected].

Governance and enterprise assurance

How does AirOS support our internal audit and vendor risk programme?

We provide structured assurance documentation covering security controls, resilience design, subprocessors, and shared responsibility boundaries. Reasonable cooperation with your internal audit, information security review, or appointed representative examination can be agreed contractually, including access to evidence summaries and nominated technical contacts.

Can you support our safety management system and quality assurance expectations?

AirOS is designed to complement your approved manuals, MOE, MOC, and SMS — not to substitute nominated postholder authority. Audit trails, controlled documentation, and traceable change history support quality and safety oversight. Platform use within your approval basis remains your responsibility to validate and govern.

Do you offer source-code or credential escrow for vendor-failure continuity?

Yes, for enterprise airline agreements where required. Escrow arrangements — including release triggers, update cadence, and verification dry-runs — are scoped in a separate schedule. Escrow is a continuity-of-assurance measure; it does not transfer operational accountability for day-to-day airworthiness or dispatch decisions.

How is operational accountability divided between AirOS and the operator?

You retain ownership of operational data and accountability for regulated decisions. AirOS provides the platform, agreed hosting or release support, and documented controls. Your organisation governs user access, integration with existing systems, validation against your AOC, and procedures when service is degraded.

Security controls and testing

How do your controls align with recognised security frameworks?

AirOS security design is mapped to widely used assurance frameworks — including ISO/IEC 27001 control themes and SOC 2 trust service criteria — to support your assessment. Formal certification or attestation status, where applicable, is disclosed during due diligence rather than implied in marketing materials.

What is your penetration testing cadence?

Independent security testing is performed on a defined cycle — typically at least annually for production-facing environments, with additional testing after material architectural change. Executive summaries and remediation status can be shared under confidentiality for enterprise review. Customer-specific or joint testing may be agreed where scope and rules of engagement are defined in advance.

How do you manage vulnerabilities and security patches?

Vulnerabilities are triaged by severity and exploitability. Critical issues affecting customer data or platform integrity are prioritised for remediation within agreed timeframes. Patch and release activity for material changes is communicated in advance where it may affect availability or integrations.

How is access to production environments controlled?

Production access is limited by role, logged, and subject to least privilege. Administrative access uses strong authentication and is restricted to personnel with a documented need. Break-glass access for emergency recovery is controlled, alerted, and subject to mandatory post-use review.

Data protection, residency, and records integrity

Where is our data stored and can we require a specific geography?

Hosting geography depends on your deployment model. Managed and dedicated arrangements can include agreed data residency or sovereignty constraints. Cross-border transfer mechanisms and subprocessors are disclosed for your third-party risk review. On-premise release places primary data location under your infrastructure control.

How is tenant data segregated in multi-organisation environments?

Operational data is scoped by organisation with logical segregation enforced in application access controls and data queries. Security-relevant actions are logged. Your assurance review should validate that configuration, integrations, and user permissions match your intended operational boundaries.

What audit trail is available for compliance-critical actions?

Authentication events, permission changes, administrative actions, and relevant record amendments are logged to support investigation and audit. Retention periods and export formats can be aligned to your internal standards within agreed limits. Logs are designed to support traceability without unnecessary exposure of personal data.

How are backups protected and validated?

Protection copies are encrypted, retained in geographically separate storage, and access-controlled. Restore capability is validated through periodic exercises with outcomes recorded for assurance review. Recovery point and recovery time objectives are agreed to your operational criticality — not assumed from generic defaults.

Continuity, recovery, and fail-operational behaviour

What happens to airworthiness records during a partial outage?

Integrity takes precedence over convenience. During impairment, the platform is designed to prioritise read access to fleet status, released documentation, and open defects. Where recovery requires it, edits may be blocked rather than accepted into an inconsistent state. Your established manual procedures and nominated postholders remain authoritative.

Can we participate in joint recovery or business continuity exercises?

Yes, where contractually agreed. Joint exercises help validate that AirOS recovery procedures align with your business continuity plan and departmental escalation paths — particularly where records support dispatch, engineering release, or safety reporting.

What assurance exists if a key supplier or hosting partner fails?

We maintain documented recovery paths that avoid sole-source dependency for critical platform functions. Infrastructure partners are assessed under our supplier assurance process. Enterprise customers may require escrow, architectural portability review, or dedicated hosting as additional mitigations.

Operations centre and engineering integration

How does AirOS integrate with our Operations Control Centre workflows?

Command Centre, scheduling, fleet status, flight logging, crew compliance, and disruption tooling are designed to present a coherent operational picture for OCC-style roles. Integrations with existing OCC, movement messaging, or fleet systems are scoped per deployment — via supported connectors, APIs, or agreed custom interfaces. We recommend a joint operational design review before production cutover.

How does AirOS interface with engineering, maintenance control, and stores?

Maintenance planning, work packages, defect tracking, parts traceability, and airworthiness records share a common data model to reduce reconciliation between engineering, MRO, and logistics. ADX supports structured CAMO–MRO exchange where applicable. Interface boundaries, data ownership, and approval gates should be defined in your implementation assurance plan.

Can AirOS coexist with legacy systems during phased migration?

Yes. Modular deployment allows phased adoption — for example, document control or fleet records first — while legacy systems remain authoritative for other functions until you validate cutover. Parallel operation periods should be governed by your change management and data reconciliation procedures.

What performance and availability expectations apply at airline scale?

Scale, peak load, and availability parameters are agreed against your fleet size, user population, and module entitlement. We do not publish one-size-fits-all availability claims; enterprise schedules define service expectations, maintenance windows, and reporting suitable for your operations.

Change management, AI, and incidents

How are platform changes communicated and controlled?

Material changes affecting availability, security, data handling, or integrations are notified in advance. Enterprise agreements may include maintenance windows, staged rollouts, or validation periods before production impact. Configuration affecting compliance workflows or retention is subject to the same discipline.

How is AI governed for safety-critical airline use?

AI-assisted capabilities are decision-support tools only. They do not certify maintenance, approve airworthiness, close safety investigations, or authorise dispatch. Outputs may be labelled and logged; human review and nominated postholder authority remain required for regulated actions. AI may be suspended during impairment or assurance review. See our AI Policy for full detail.

How and when will we be notified of a security or service incident?

Incidents are assessed, contained, and remediated under a defined response process. Customer notification follows contractual terms and applicable legal obligations, with information structured to support your internal escalation and safety reporting. Post-incident summaries can be provided for quality or security review within agreed confidentiality.

Who are your subprocessors and how are they assessed?

A current subprocessor list — covering hosting, monitoring, communications, and other core service dependencies — is available for enterprise due diligence. Partners are assessed for security and privacy posture before engagement and subject to contractual safeguards. Optional integrations you enable remain under your control and the third party's terms.

This annex is intended as a starting point for assurance dialogue. Binding commitments, evidence artefacts, and recovery schedules are set out in your agreement and associated security or resilience appendices.

Airline Assurance Annex