Draft — pending legal review

Version 0.1

Privacy notice

This page is working draft content for product review. It is not the final AirKo privacy notice and must be completed by South African privacy counsel before production use.

1. Status of this draft

AirKo is being designed with POPIA readiness, data minimisation and role-scoped access in mind. That is a design objective, not a claim of legal compliance. The final notice must identify the relevant AirKo legal entity, information officer, contact details, effective date and the responsible-party/operator allocation for each service relationship.

2. Information in scope

The platform is expected to process categories including:

  • account, identity, contact and organisational details;
  • role, UASOC, Team and resource assignments;
  • pilot qualification, rating, medical-status, training, recency and expiry information, with supporting evidence;
  • aircraft, equipment, maintenance, defect and serviceability records;
  • flight requests, locations, coordinates, operating windows, risk assessments, permissions and flight-pack documents; and
  • authentication, security, audit, notification and support-event data.

Final field-level inventories and classifications must be confirmed before production, particularly for medical and other special or sensitive personal information.

3. Proposed purposes

The intended purposes are to authenticate users; apply tenant and role scope; support pilot, asset and flight workflows; enable human review and authorization; provide expiry and operational notices; generate scoped reports; maintain security and audit history; and respond to service requests.

The final notice must state the lawful basis for each purpose and distinguish purposes determined by a customer UASOC from those determined by AirKo.

4. Access and sharing

Operational access is intended to follow explicit UASOC, Team and user roles. Team users should normally see operational status and expiry, not complete medical source documents. AirKo platform administrators should not have routine access to customer operational or medical documents; any support access should be explicit, time-limited and audited.

The final notice must name or categorise approved infrastructure, authentication, storage, monitoring and communication processors, including their processing locations and contractual safeguards.

5. Storage and security

The intended controls include server-side authorization, database row-level security, private document storage, short-lived signed access, file validation, security logging, session expiry and access revocation. No control eliminates all risk, and final security statements must match the tested production system.

6. Retention and deletion

Retention schedules for account data, operational records, medical evidence, flight packs, audit events, backups and demo requests remain to be approved. The final policy must reconcile operational, contractual, regulatory, limitation-period and data-minimisation requirements, and define secure deletion or de-identification.

7. Data-subject requests

The production notice must explain how a person may request access, correction or deletion; object to or restrict certain processing; raise a complaint; and contact the Information Regulator where applicable. It must also explain when the relevant customer UASOC, rather than AirKo, is responsible for handling the request.

8. Cross-border processing

Hosting locations, support access and any cross-border transfers must be documented after the production vendors and regions are selected. The final notice must describe applicable safeguards and obtain any required approvals before those transfers occur.

9. Contact details

The legal entity, physical address, information-officer contact and privacy-request channel are intentionally not invented in this draft. They must be inserted and verified before publication as a production privacy notice.