top of page

AeroAccess Data Security Policy

Effective date: 8th September 2026
Review date: 7th September 2027

Version: 1.0

Security contact: admin@aeroaccess.io

Privacy contact: admin@aeroaccess.io

​

1. Purpose

​

AeroAccess is committed to protecting the confidentiality, integrity and availability of the information entrusted to it by pilots, aircraft operators, aerodromes, airports, heliports, landing-site operators, drone operators, service providers, employees, contractors and other users.

This policy establishes the organisational and technical requirements AeroAccess must follow to protect personal data, payment-related information, commercially sensitive information and aviation-related operational data.

​

It supports AeroAccess’s compliance with:

​

  • the UK General Data Protection Regulation;

  • the Data Protection Act 2018;

  • the EU General Data Protection Regulation where it applies;

  • the Privacy and Electronic Communications Regulations;

  • applicable contractual obligations;

  • the Payment Card Industry Data Security Standard;

  • Stripe’s security and platform requirements; and

  • the security and data-protection requirements applicable to services supplied by Wix and other approved processors.

​

This policy must be read alongside the AeroAccess Privacy Policy, Cookie Policy, Terms and Conditions, Data Retention Policy, Incident Response Procedure and Business Continuity Plan.

​

2. Scope

​

This policy applies to:

​

  • all AeroAccess directors, employees, contractors, consultants and authorised administrators;

  • all AeroAccess websites, applications, databases, APIs, integrations and administrative systems;

  • personal and operational data processed through AeroAccess;

  • information held by AeroAccess’s service providers, including Wix and Stripe;

  • development, testing, support, backup and production environments; and

  • all devices and accounts used to access AeroAccess information.

​

Compliance with this policy is mandatory.

​

3. Roles and responsibilities

​

The AeroAccess policy owner is responsible for overseeing this policy, coordinating security reviews and ensuring that material security risks are reported to senior management.

​

System administrators must configure systems securely, maintain appropriate permissions, review activity logs and promptly remove unnecessary access.

Developers and contractors must follow secure-development requirements and must not introduce unapproved services, software libraries, integrations or data-processing activities.

​

All authorised users must:

​

  • protect their login credentials;

  • use multi-factor authentication where available;

  • access information only for legitimate purposes;

  • report suspected security incidents immediately; and

  • comply with AeroAccess’s confidentiality and acceptable-use requirements.

​

Aerodrome and service-provider administrators are responsible for granting appropriate access to their own personnel and notifying AeroAccess promptly when access should be changed or removed.

​

4. Security principles

​

AeroAccess will apply the following principles:

​

  1. Data minimisation: only information reasonably required to operate AeroAccess, process aviation-service requests, support users, comply with legal obligations and protect the platform will be collected.

  2. Least privilege: access will be limited to the minimum information and functionality required for each person’s role.

  3. Security by design and default: security and privacy requirements will be considered before introducing or materially changing any system, product, integration or processing activity.

  4. Separation of duties: where proportionate, sensitive administrative, financial and security functions will not depend on one individual acting without oversight.

  5. Defence in depth: AeroAccess will not rely on a single security control.

  6. Accountability: material decisions, access changes, security incidents and risk assessments will be documented.

  7. Continuous improvement: controls will be reviewed in response to changes in technology, threats, law, platform functionality and the nature of AeroAccess’s services.

5. Information classification

​

AeroAccess information must be classified as follows:

​

Public

​

Information approved for public release, such as published aerodrome details, opening hours, public events and marketing material.

​

Internal

​

Routine business information not intended for public disclosure.

​

Confidential

​

Personal information and commercially sensitive information, including:

​

  • names, contact details and account information;

  • aircraft registrations linked to users or journeys;

  • arrival and departure details;

  • PPR and service requests;

  • provider pricing and financial reports;

  • invoices, payout information and transaction records;

  • user communications;

  • audit records; and

  • aerodrome administration information.

​

Restricted

​

Information requiring the highest level of protection, including:

​

  • passwords and authentication credentials;

  • API keys, webhook secrets and encryption keys;

  • identity-verification documentation;

  • security incident records;

  • vulnerability reports;

  • privileged administrative data;

  • full bank-account details; and

  • any information whose disclosure could create a material security, fraud, legal or safety risk.

​

Access, storage, transmission and disposal controls must be proportionate to the classification.

​

6. Identity and access management

​

AeroAccess will:

​

  • provide each authorised person with an individual account;

  • prohibit shared administrative accounts except where technically unavoidable and formally authorised;

  • apply role-based access control;

  • require strong, unique passwords;

  • enable multi-factor authentication for Wix, Stripe, domain, email, cloud, source-control and other administrative accounts wherever supported;

  • restrict production and payment access to specifically authorised personnel;

  • review privileged access at least quarterly;

  • review other business access at least every six months;

  • remove or disable access promptly when a person leaves, changes role or no longer requires it;

  • maintain secure recovery methods for critical accounts; and

  • investigate suspicious login activity.

​

Provider administrators must see only the records belonging to the locations or organisations they are authorised to manage. Pilots and other requesters must see only their own records unless a separate lawful and authorised role applies.

​

7. Wix security requirements

​

Where AeroAccess uses Wix, it will use Wix’s supported security features and maintain secure configurations.

​

AeroAccess must:

​

  • enable multi-factor authentication on all Wix administrative accounts;

  • grant collaborators only the permissions necessary for their roles;

  • review collaborator and site permissions regularly;

  • use HTTPS for all live pages and integrations;

  • configure CMS collection permissions so confidential records cannot be read, modified or deleted by unauthorised website visitors or members;

  • enforce authorisation in trusted backend code and not rely solely on hidden page elements or client-side controls;

  • keep secrets, API keys and webhook credentials in an approved secrets-management facility;

  • never place secrets in public page code, browser-accessible data, URLs, logs or CMS fields available to ordinary users;

  • validate and sanitise all user-controlled input;

  • restrict administrative and financial pages to properly authenticated and authorised users;

  • keep custom code and dependencies under review;

  • test permission changes before publication; and

  • monitor relevant Wix security notices and apply required changes promptly.

​

Wix security controls do not remove AeroAccess’s responsibility for its own site configuration, custom code, access permissions, content and data-processing decisions.

​

8. Stripe and payment security

​

Stripe will be AeroAccess’s approved payment processor unless another processor is formally authorised following a security and compliance review.

AeroAccess will use Stripe-hosted payment pages, Stripe Checkout, Elements or another Stripe-approved integration that prevents AeroAccess systems from directly collecting or storing full payment-card details.

​

AeroAccess must not store:

​

  • full card numbers;

  • card security codes or CVV/CVC values;

  • magnetic-stripe data;

  • PINs; or

  • other prohibited sensitive authentication data.

​

Only necessary payment references may be retained, such as:

​

  • Stripe customer and transaction identifiers;

  • payment status;

  • payment amount and currency;

  • limited card descriptors supplied by Stripe;

  • refund and dispute information; and

  • provider payout and reconciliation records.

​

Stripe API keys and webhook signing secrets must:

​

  • be stored in an approved secrets-management system;

  • never be exposed in client-side code;

  • be restricted according to purpose where supported;

  • be separated between test and live environments;

  • be rotated immediately following suspected exposure; and

  • be accessible only to authorised personnel.

​

Webhook signatures must be verified before webhook data is trusted or acted upon. Payment operations must be idempotent where appropriate to reduce the risk of duplicate charges, refunds or payouts.

​

AeroAccess will complete the PCI DSS validation applicable to its chosen Stripe integration and business model, including the relevant Self-Assessment Questionnaire where required. The use of Stripe reduces, but does not automatically eliminate, AeroAccess’s PCI DSS responsibilities.

​

9. Secure development and change management

​

Security requirements must form part of the design and acceptance criteria for material changes.

​

AeroAccess will:

​

  • separate live and test payment credentials;

  • avoid using real personal or payment information in testing wherever practicable;

  • perform code and permission reviews before significant releases;

  • validate access controls on both the frontend and backend;

  • protect against common web risks, including injection, broken access control, insecure direct object references and cross-site scripting;

  • apply reasonable rate limiting and abuse controls to exposed functions and APIs;

  • remove debugging information and unnecessary logging from production;

  • maintain an inventory of significant integrations and software dependencies;

  • assess security updates and known vulnerabilities promptly;

  • document and test material changes; and

  • maintain an appropriate rollback or recovery method.

​

No production data may be copied into an unapproved development tool, artificial-intelligence service or personal account.

​

10. Encryption and transmission

​

Personal, confidential and restricted information must be transmitted using secure encrypted connections.

​

AeroAccess will use encryption at rest where supported and proportionate. Portable devices used to access confidential information must use device encryption, screen locking and supported operating systems.

​

Confidential information must not be sent through unapproved messaging, storage or file-sharing services.

​

11. Logging and monitoring

​

AeroAccess will maintain proportionate records of important activity, including:

​

  • authentication and privileged access;

  • material administrative changes;

  • PPR and service-request status changes;

  • provider charges and financial adjustments;

  • refunds, disputes and payouts;

  • permission changes;

  • security-relevant integration events; and

  • suspected or confirmed incidents.

​

Logs must be protected against unauthorised access and alteration. They must not unnecessarily record passwords, payment-card details, authentication tokens or other secrets.

​

Alerts and logs will be reviewed proportionately to the risk and scale of AeroAccess’s operations.

​

12. Data retention and secure deletion

​

AeroAccess will retain personal information only for as long as it is required for the stated purpose, legal obligations, financial record keeping, dispute handling, fraud prevention, aviation-service administration or the establishment and defence of legal claims.

​

Retention periods must be documented in an approved retention schedule.

​

When information is no longer required, it will be securely deleted, anonymised or placed beyond normal use. Deletion requests will also be communicated to relevant processors where required.

​

Backups may retain deleted information for a limited period until they are overwritten in accordance with the backup cycle. Restored backups must be handled so that previously approved deletions are reapplied where necessary.

​

13. Backups, resilience and availability

​

AeroAccess will use proportionate resilience and recovery arrangements for business-critical information.

​

These arrangements must include:

​

  • recovery procedures for critical Wix, Stripe, domain and email accounts;

  • secure backups or exports where technically available and appropriate;

  • documented continuity arrangements for significant platform outages;

  • periodic recovery testing; and

  • protection against accidental deletion or unauthorised changes.

​

AeroAccess must not represent its platform as a substitute for safety-critical aeronautical systems, air traffic control systems, NOTAMs, official aeronautical information or mandatory direct communications unless the relevant service has been specifically designed, authorised and certified for that purpose.

​

14. Suppliers and processors

​

Before appointing a supplier that will process personal or confidential information, AeroAccess will assess:

​

  • the nature and sensitivity of the information;

  • the supplier’s security and privacy assurances;

  • processing locations and international transfers;

  • contractual data-protection terms;

  • subprocessor arrangements;

  • access controls;

  • incident-notification commitments;

  • deletion and return arrangements; and

  • relevant certifications or independent assurance.

​

AeroAccess will maintain appropriate data-processing agreements with Wix, Stripe and other processors.

​

International transfers of personal data must use a valid legal transfer mechanism, such as adequacy regulations or approved contractual safeguards, together with any required risk assessment.

​

Supplier access must be removed when the service or engagement ends.

​

15. Security incident and personal-data breach response

​

A security incident includes any actual or suspected:

​

  • loss, disclosure or alteration of information;

  • unauthorised access;

  • compromised account or credential;

  • malware or ransomware infection;

  • system or website vulnerability;

  • fraudulent transaction;

  • denial of service;

  • inappropriate access by personnel; or

  • loss of a device containing or accessing AeroAccess information.

​

All incidents must be reported immediately to admin@aeroaccess.io​

​

AeroAccess will:

​

  1. record the incident and the time it was discovered;

  2. contain the threat and preserve relevant evidence;

  3. assess the information, people and systems affected;

  4. change or revoke compromised credentials;

  5. involve Wix, Stripe or other processors where appropriate;

  6. assess risks to affected individuals;

  7. document decisions and remedial actions;

  8. notify insurers, contractual partners or authorities where required; and

  9. review the incident to prevent recurrence.

​

Where a personal-data breach is likely to result in a risk to individuals, AeroAccess will notify the Information Commissioner’s Office without undue delay and, where feasible, within 72 hours after becoming aware of it.

​

Where the breach is likely to result in a high risk to individuals, AeroAccess will also inform affected individuals without undue delay unless a lawful exception applies.

​

Incidents involving payment data must also be handled in accordance with Stripe, acquiring-bank and PCI DSS requirements.

​

16. Vulnerability management

​

Suspected vulnerabilities should be reported privately to [security@aeroaccess.io] and must not be exploited beyond what is necessary to demonstrate the issue.

​

AeroAccess will triage reported vulnerabilities according to severity and potential impact. Critical issues involving unauthorised access, exposed secrets, payment functions or confidential information will receive immediate attention.

​

Security testing must be authorised and scoped in advance. AeroAccess will perform proportionate vulnerability assessments and penetration testing following major architectural changes and periodically as the platform develops.

​

17. Staff and contractor security

​

Personnel with access to confidential or restricted information must:

​

  • be subject to appropriate confidentiality obligations;

  • receive data-protection and security training;

  • complete refresher training periodically;

  • use approved devices and services;

  • keep operating systems and applications supported and updated;

  • avoid accessing confidential information over insecure networks;

  • prevent family members or other unauthorised people from using work accounts; and

  • return or securely delete AeroAccess information when their access ends.

​

Relevant personnel may be subject to proportionate screening where justified by their responsibilities.

​

18. Personal devices and remote working

​

Personal devices may access AeroAccess administrative systems only where authorised and appropriately secured.

​

Such devices must use:

​

  • a supported and updated operating system;

  • device encryption;

  • automatic screen locking;

  • strong device authentication;

  • current malware protection where appropriate; and

  • the ability to remove AeroAccess information if access is withdrawn.

​

Restricted information must not be downloaded to shared or unmanaged devices unless specifically authorised.

​

19. Data-protection risk assessments

​

AeroAccess will carry out a Data Protection Impact Assessment before introducing processing that is likely to create a high risk to individuals.

​

A security and privacy review will also be conducted before:

​

  • collecting new categories of personal data;

  • introducing identity verification or automated risk scoring;

  • enabling significant tracking or profiling;

  • processing precise or large-scale location data;

  • integrating a new payment or communication service;

  • materially changing provider access to pilot information; or

  • introducing a new use of aviation movement data.

​

20. Physical security

​

Paper records containing personal or confidential information will be minimised. Where used, they must be kept securely and disposed of using confidential-waste or cross-cut shredding arrangements.

​

Devices must not be left unattended in public places or visible in unattended vehicles.

​

21. Compliance and assurance

​

AeroAccess will periodically review:

​

  • Wix roles, collaborator access and CMS permissions;

  • Stripe roles, live API keys and webhook endpoints;

  • domain and email security;

  • privileged user accounts;

  • active integrations;

  • data-retention compliance;

  • security incidents and near misses;

  • processor terms and subprocessors;

  • PCI DSS validation obligations; and

  • the effectiveness of this policy.

​

Evidence of significant reviews and remedial work will be retained.

​

A breach of this policy may result in access being suspended or withdrawn and may lead to contractual, disciplinary or legal action.

​

22. Exceptions

​

Any exception to this policy must be:

​

  • documented;

  • supported by a risk assessment;

  • approved by the policy owner;

  • limited in scope and duration; and

  • reviewed before it expires.

​

23. Policy review

​

This policy will be reviewed at least annually and sooner following:

​

  • a material security incident;

  • a significant change to AeroAccess;

  • the introduction of a new material supplier or integration;

  • changes to applicable law or regulatory guidance; or

  • changes to relevant Wix, Stripe or PCI DSS requirements.

​

Approved changes will be communicated to relevant personnel.

​

bottom of page