Data Processing Addendum.
Article 28, written for aviation.

This Data Processing Addendum (the "DPA") is entered into by and between Eaviora Inc. ("eAviora", "Processor") and the customer identified in the Agreement ("Customer" or "Controller"). It forms part of the Agreement. Capitalized terms not defined here have the meanings given in the Agreement.

The parties agree that Customer determines the purposes and essential means of processing Customer Personal Data in the Service, and eAviora processes that data on Customer documented instructions to provide the Service.

• Processor. Eaviora Inc., incorporated under the Canada Business Corporations Act, registered office in Quebec, Canada.
• Privacy contact. privacy@eaviora.com
• Security and breach contact. security@eaviora.com
• Governing law. As stated in the Agreement. The standard eAviora Terms use the laws of Quebec and the applicable federal laws of Canada.

Applicable Data Protection Law means all laws and regulations applicable to the processing of Customer Personal Data under the Agreement, including where applicable the GDPR, the UK GDPR, the Swiss Federal Act on Data Protection, the Personal Information Protection and Electronic Documents Act of Canada, and applicable provincial privacy legislation.

Customer Data means all data, content, records, documents, evidence, configurations, taxonomies, workflow information, and other information submitted to or generated within the Service for Customer.

Customer Personal Data means Personal Data contained in Customer Data that eAviora processes on behalf of Customer.

Aviation Safety Data means safety data, safety information, occurrence reports, hazard reports, witness statements, investigation material, risk assessments, barrier assessments, CAPA information, audit findings, safety governance records, and related information processed in the Service.

Confidential Reporter Data means Personal Data that identifies or may identify a reporter, witness, interviewee, or source whose identity is designated confidential, anonymous, protected, restricted, or subject to a Just Culture or safety-data protection rule.

Personal Data, Controller, Processor, Data Subject, Processing, Personal Data Breach, and Supervisory Authority have the meanings given in Applicable Data Protection Law.

Sub-processor means a third party engaged by eAviora to process Customer Personal Data in connection with the Service.

Standard Contractual Clauses or SCCs means the European Commission standard contractual clauses adopted under Commission Implementing Decision (EU) 2021/914, as amended, replaced, or superseded.

2.1 This DPA applies only to processing of Customer Personal Data by eAviora as Processor or Sub-processor. It does not govern information for which eAviora acts as an independent Controller, such as business contact information used for account administration, contracting, billing, fraud prevention, legal compliance, or direct communications, to the extent eAviora determines the purposes and means of that separate processing. The split is set out below rather than left to inference, because the boundary determines which party answers a Data Subject and which party is accountable to a Supervisory Authority.

2.1.1 Role allocation. eAviora acts as Processor for: tenant user accounts, roles and permissions; authentication, session and sign-in activity within the tenant; tenant security events and audit records; operational telemetry arising from Customer use; Customer support content about the tenant; Customer-configured notifications; and all Customer operational records, evidence and safety data.

eAviora acts as independent Controller for: contract signatory and negotiation contacts; commercial relationship management; corporate billing contacts and invoicing records; its own statutory, accounting and tax records; its own legal claims and enforcement; eAviora-initiated security investigation where eAviora determines the purpose under its own legal obligation; and direct marketing to its own business contacts. Where a single activity engages both roles, the Processor obligations in this DPA apply to the Customer Personal Data element.

2.2 If there is a conflict concerning privacy, data protection, security, or processing of Customer Personal Data, this DPA prevails over the Agreement. The Agreement otherwise remains in effect.

2.3 Customer is the Controller or a Processor acting on behalf of another Controller. Customer is responsible for the lawfulness of its instructions, notices, legal bases, permissions, and use of the Service, including any decision to place special category data, criminal-offence data, health information, or protected aviation safety information in the Service.

2.4 eAviora is the Processor. eAviora will not sell Customer Personal Data, use it for advertising, or use it to train general-purpose artificial intelligence models.

3.1 eAviora will process Customer Personal Data only on Customer documented instructions, including the Agreement, Customer configuration of the Service, actions of authorised users, API and integration instructions, support requests, and other written instructions accepted by eAviora.

3.2 Customer instructs eAviora to process Customer Personal Data as necessary to provide, secure, support, maintain, improve the reliability of, and comply with law in relation to the Service. Any product improvement using Customer Personal Data must be limited to service security, reliability, defect correction, and aggregate or de-identified analytics that do not identify Customer or a Data Subject.

3.3eAviora will immediately inform Customer if, in eAviora's reasonable opinion, an instruction infringes Applicable Data Protection Law. eAviora may suspend the affected processing until the parties resolve the issue. eAviora is not required to perform an instruction that is unlawful, technically impossible, or would materially weaken security for Customer or other tenants.

3.4 If law requires eAviora to process Customer Personal Data other than on Customer instructions, eAviora will notify Customer before processing unless the law prohibits notice on important grounds of public interest.

3.5 Customer authorises eAviora to make international transfers only as provided in Section 8 and Annexes III and V.

4.1 The subject matter, duration, nature, purpose, categories of Data Subjects, and types of Personal Data are set out in Annex I.

4.2 eAviora may process Customer Personal Data using shared multi-tenant infrastructure, provided that Customer Personal Data remains logically isolated and is not accessible to another customer. eAviora will not combine identifiable Customer Personal Data with identifiable data belonging to another customer. Cross-customer analytics or benchmarking may use only data that has been aggregated and de-identified in accordance with documented privacy thresholds and, where required, Customer configuration or authorisation.

4.3 eAviora will not access Customer tenant content through human support personnel unless Customer authorises access, access is necessary to investigate a security incident affecting the Service, or access is required by law. Any such access must be limited, logged, and subject to confidentiality obligations.

4.4 Artificial intelligence features process Customer Personal Data only when invoked, configured, or enabled through the Service. AI outputs are decision-support. They do not replace Customer legal, regulatory, safety, quality, security, or operational decision-making. Workflow state changes and governance decisions remain subject to human approval and applicable permissions.

5.1 eAviora will ensure that each person authorised to process Customer Personal Data is bound by a contractual or statutory duty of confidentiality and receives access only on a need-to-know and least-privilege basis.

5.2 Personnel with privileged production access must be specifically authorised, use named accounts, protect credentials with strong authentication, and be subject to logging and periodic access review.

5.3 Confidentiality obligations survive termination of employment, engagement, and this DPA.

5.4 eAviora will provide privacy and security awareness appropriate to the responsibilities of personnel who may process Customer Personal Data.

6.1 Taking into account the state of the art, implementation costs, the nature, scope, context, and purposes of processing, and the risks to Data Subjects, eAviora will implement and maintain appropriate technical and organisational measures designed to protect Customer Personal Data against accidental or unlawful destruction, loss, alteration, unauthorised disclosure, or access.

6.2 The measures in Annex II are the current minimum measures for the Service. eAviora may update them where the update does not materially reduce the overall level of protection.

6.3 eAviora will maintain controls appropriate to aviation safety and regulated operational records, including database-enforced tenant isolation, role and permission controls, sensitivity tiers, record-level access checks for restricted evidence, audit logging, and human approval controls for AI suggestions.

6.4 Customer is responsible for configuring user roles, reporter modes, access grants, retention settings available to Customer, SSO or MFA settings, and integrations consistently with its legal and operational requirements.

7.1 Customer grants eAviora general written authorisation to engage the Sub-processors listed in Annex III and in the current public Sub-processor register.

7.2 eAviora will provide at least thirty (30) days prior notice before appointing a new Sub-processor that will materially process Customer Personal Data, or before materially changing the purpose or country of processing. Notice may be provided by email to Customer administrators, through the Service, or through the public Sub-processor register.

7.3 Customer may object on reasonable data protection grounds by written notice within fifteen (15) days after notice. The parties will work in good faith to address the objection, including by providing additional information, using a reasonable alternative where available, or disabling the affected optional feature. If no reasonable resolution is available, either party may terminate the affected Service without penalty for the unused prepaid portion.

7.4 Where an urgent replacement is reasonably necessary to protect the security or availability of the Service, eAviora will provide as much advance notice as reasonably practicable. No Sub-processor will process Personal Data subject to the SCCs before the notice and authorisation requirements of Clause 9 have been satisfied, unless Applicable Data Protection Law expressly permits otherwise.

7.5 eAviora will enter into a written agreement with each Sub-processor imposing data protection obligations that are no less protective in substance than the obligations applicable to eAviora under this DPA, to the extent relevant to the Sub-processor services.

7.6eAviora remains responsible to Customer for the performance of each Sub-processor's obligations under this DPA, subject to the liability terms of the Agreement.

8.1 The primary production database and object storage for the standard eAviora Service are hosted in Canada. Application compute, edge services, support tooling, AI processing, email delivery, observability, and other approved functions may involve processing in the United States or other countries identified in Annex III.

8.2 For transfers of Personal Data from the European Economic Area to eAviora in Canada, the parties will rely on the European Commission adequacy decision for Canada to the extent eAviora is a recipient covered as a Canadian commercial organisation and the decision remains valid and applicable.

8.3 Canada adequacy does not by itself authorise onward transfers from Canada to a country or recipient not covered by an adequacy decision. eAviora will ensure that each onward transfer is covered by an appropriate mechanism under Applicable Data Protection Law, such as an adequacy decision, the SCCs, binding corporate rules, or another lawful safeguard.

8.4 Where a transfer requires a mechanism beyond an adequacy decision, or if the Canada adequacy decision ceases to apply, the instruments in Annex V apply and are incorporated into this DPA: Annex V-A, the European Commission Standard Contractual Clauses (Implementing Decision (EU) 2021/914) with the module selection and required variables completed; Annex V-B, the United Kingdom International Data Transfer Addendum, for a UK restricted transfer, because EU SCCs alone do not cover one; and Annex V-C, the Swiss adaptations recognised by the FDPIC. Annexes I, II and III serve as the corresponding SCC annexes.

8.5 eAviora will assess and implement supplementary measures where required for a transfer, taking into account the nature of the data, destination, recipient, and technical safeguards.

9.1 Taking into account the nature of processing, eAviora will assist Customer by appropriate technical and organisational measures, insofar as possible, to respond to requests to exercise Data Subject rights.

9.2 eAviora will promptly notify Customer if eAviora receives a request relating to Customer Personal Data. eAviora will not respond substantively except on Customer documented instructions, unless required by law.

9.3 Assistance may include locating relevant data, providing tenant exports, anonymising user accounts, erasing survey respondent identity, restricting access, preserving legal holds, and supplying available audit information. Where the Service does not provide a complete self-service Data Subject export or erasure function for a data category, eAviora will provide reasonable manual assistance.

9.4 Customer remains responsible for verifying the requester identity, determining the legal response, applying exemptions or restrictions, and communicating with the Data Subject or Supervisory Authority.

9.5eAviora may charge reasonable fees for assistance that is unusually burdensome, repetitive, or requires custom engineering, provided eAviora informs Customer of the expected cost before performing chargeable work. No fee applies for reasonable assistance required because of eAviora's breach of this DPA.

10.1 The parties recognise that Customer Personal Data may include Confidential Reporter Data and Aviation Safety Data subject to Just Culture commitments, employment protections, collective agreements, safety reporting rules, occurrence investigation restrictions, or laws and policies implementing ICAO Annex 19 principles.

10.2 eAviora will preserve Customer configured reporter mode, confidentiality tier, access restriction, and disclosure instruction. eAviora will not disclose Confidential Reporter Data to a requester, investigator, manager, regulator, or third party except on Customer documented instruction or where legally required.

10.3A Data Subject request does not automatically entitle the requester to unrestricted copies of another reporter's identity, witness statement, safety analysis, risk assessment, investigation material, or information that would adversely affect the rights and freedoms of others. Customer must make the legal determination. eAviora will support proportionate responses such as segregation, redaction, pseudonymisation, restricted disclosure, or provision of a summary where instructed and lawful.

10.4 Nothing in this Section creates a blanket exemption from Applicable Data Protection Law, authorises eAviora to deny a Data Subject request independently, or treats ICAO Annex 19 as automatically overriding the GDPR. The applicable national or sector law, the rights of the requester, the rights of other persons, and the purpose of safety-data protection must be assessed by Customer.

10.5 Where Customer instructs eAviora to preserve protected safety records despite a deletion request, Customer will identify the applicable legal basis, retention period, and access restrictions. eAviora will apply the instruction and maintain the related audit trail.

10.6 Annex IV forms part of this DPA and sets out the operational protocol for protected safety data, reporter identity, DSAR handling, and legal holds.

11.1 Taking into account the nature of processing and information available to eAviora, eAviora will provide reasonable assistance with Customer data protection impact assessments, transfer impact assessments, prior consultations, records of processing, and security questionnaires concerning the Service.

11.2 Assistance may include descriptions of data flows, Sub-processors, hosting regions, AI processing, security controls, retention, access controls, incident procedures, and available compliance evidence.

11.3 Customer remains responsible for determining whether a DPIA or prior consultation is required and for its legal conclusions. eAviora does not provide Customer legal advice through the Service.

11.4 eAviora will cooperate with a competent Supervisory Authority as required by Applicable Data Protection Law, while protecting confidential information, security information, and data belonging to other customers.

12.1 eAviora will notify Customer without undue delay after becoming aware of a Personal Data Breach affecting Customer Personal Data and, where feasible, within twenty-four (24) hours after such awareness. eAviora may provide initial information while investigation and confirmation of scope remain ongoing.

12.2 The initial notice will include, to the extent known: the nature of the breach; affected systems, tenants, data categories, and approximate number of Data Subjects and records; likely consequences; containment and remediation measures; and a contact point for follow-up. eAviora may provide information in phases as the investigation progresses.

12.3 eAviora will take reasonable steps to contain, investigate, remediate, and document the breach; preserve relevant evidence; provide regular updates; and assist Customer with notifications to Supervisory Authorities and Data Subjects.

12.4eAviora's notice or assistance is not an admission of fault or liability. Customer is responsible for deciding whether notification is legally required and for making any notification, unless law requires eAviora to notify directly.

12.5eAviora will not notify Customer end users, reporters, employees, regulators, the media, or the public about a Customer-specific breach without Customer's prior written approval, unless required by law. Where notice is legally required, eAviora will, where permitted, consult Customer in advance.

13.1 Unless prohibited by law, eAviora will notify Customer before disclosing Customer Personal Data in response to a subpoena, court order, regulator demand, law enforcement request, or other compulsory process.

13.2 eAviora will review the legal validity and scope of the demand, seek clarification or narrowing where reasonable, and disclose only the minimum data legally required.

13.3 eAviora will not voluntarily provide direct, unrestricted, or bulk access to Customer Personal Data to a public authority.

14.1 eAviora will make available information reasonably necessary to demonstrate compliance with this DPA and Article 28 of the GDPR, including relevant policies, security summaries, Sub-processor information, data-flow descriptions, audit evidence, penetration-test summaries where available, and responses to reasonable questionnaires.

14.2 Customer may conduct one audit in any twelve-month period on at least thirty (30) days notice. The audit will first use remote documentation and interviews. An on-site audit or inspection is permitted where remote evidence is insufficient to assess the relevant control; a Supervisory Authority requires or directs it; applicable law requires it; a Personal Data Breach materially affecting Customer has occurred; Customer has reasonable evidence of a material violation of this DPA; a material change has occurred in processing locations, architecture or Sub-processors; or previously supplied evidence reveals a material control failure. The once-yearly limit protects against repetitive routine audits and does not limit an audit triggered by any of those circumstances. Nothing in this Section restricts the rights of a Supervisory Authority.

14.3Audits must occur during normal business hours, be conducted by personnel or an independent auditor bound by confidentiality, avoid disruption, avoid access to other customers' data, and not require disclosure of source code, secrets, vulnerability details that would increase risk, or information prohibited by law or third-party obligations.

14.4Customer bears its audit costs and eAviora's reasonable costs for assistance beyond one standard audit per year, except where an audit identifies a material breach by eAviora or follows a confirmed Personal Data Breach caused by eAviora's failure to comply with this DPA.

14.5 eAviora may satisfy an audit request in whole or in part through current independent certifications, third-party audit reports, penetration-test attestations, or equivalent evidence, when reasonably sufficient for the requested control.

15.1 During the term, Customer may export Customer Data using available Service export functions and APIs. Customer should complete export before termination.

15.2 On termination or expiry, eAviora will revoke Customer user access, API credentials and active sessions, and will make Customer tenant data available for export for thirty (30) days unless the Agreement specifies another period. After that period, at Customer choice and subject to law, eAviora will return or delete Customer Personal Data and existing copies.

15.3Deletion from active production systems will be completed within thirty (30) days after the export period or Customer's earlier written instruction. This covers database records, object storage, generated exports and imports, background job payloads, notification and email delivery records, and AI execution records. eAviora will instruct each Sub-processor holding Customer Personal Data to delete it and will record the outcome for each, including where a Sub-processor retains data only until its own retention period expires. Residual copies in encrypted backups will be isolated from ordinary use and expire under the backup lifecycle, not later than ninety (90) additional days unless a longer period is required by law or the applicable backup architecture is disclosed in the Order Form.

15.4 eAviora may retain limited records required to establish, exercise, or defend legal claims; comply with law; maintain financial records; or preserve security and audit evidence. Retained Customer Personal Data remains protected by this DPA, is not used for another purpose, and is deleted when the legal basis ends.

15.5 Customer may issue a documented legal-hold instruction for specified records. Customer is responsible for the legal basis, scope, and release of the hold. eAviora will not use a general aviation-record retention practice as an independent basis to retain Customer Personal Data after termination where Customer has instructed deletion, unless eAviora is legally required to retain it.

15.6 On written request after completion, eAviora will provide a deletion confirmation identifying the tenant, deletion date, and any remaining legally retained or backup-resident data categories.

16.1 eAviora will maintain records of processing activities required of a Processor under Applicable Data Protection Law.

16.2 Each party will provide accurate contact information and promptly notify the other of changes relevant to privacy, security, or breach response.

16.3 Notices under this DPA must be sent to the contacts in the Agreement. Privacy and data-protection notices to eAviora may also be sent to privacy@eaviora.com, and notices concerning a Personal Data Breach or a security matter to security@eaviora.com. Customer will provide and keep current a designated privacy or security contact to receive notification under Section 12.

16.4 The parties will cooperate in good faith to amend this DPA where reasonably necessary to comply with a binding change in Applicable Data Protection Law, an adequacy decision, or an approved transfer mechanism.

16.5 Quebec.Where Quebec privacy law applies, eAviora will notify Customer's person in charge of the protection of personal information without delay of any violation or attempted violation of an obligation concerning the confidentiality of Customer Personal Data, and will permit reasonable verification relating to applicable confidentiality requirements. Customer Personal Data is used only to perform the Service, is protected by the confidentiality measures in Annex II, and is not retained after the end of the Agreement except as Section 15 permits.

17.1 The liability limitations, exclusions, indemnities, governing law, dispute resolution, and termination provisions in the Agreement apply to this DPA unless prohibited by Applicable Data Protection Law.

17.2Nothing in this DPA limits a Data Subject's statutory rights or the powers of a Supervisory Authority.

17.3 If Customer is a Processor, Customer confirms that its instructions, including appointment of eAviora as Sub-processor, are authorised by the relevant Controller. eAviora will provide Customer the assistance required for Customer to meet its corresponding processor obligations.

17.4 This DPA may be executed electronically and in counterparts. A Customer acceptance of the Agreement that expressly incorporates this DPA constitutes execution of the DPA.

17.5 Sections that by their nature should survive termination, including confidentiality, security, audit, deletion, government requests, liability, and protected safety-data obligations, survive until the relevant Customer Personal Data is deleted or returned.

Subject matter. Provision of the eAviora aviation intelligence and oversight platform, including modules and shared capabilities for safety management, quality and audit, security management, compliance and regulatory intelligence, document control, emergency response, training and competency, outsourcing oversight, occurrence reporting, hazards, actions and CAPA, evidence, risk, SPI, SRP, SAG, SRB, notifications, integrations, APIs, AI-assisted analysis, reporting, and benchmarking.

Duration. For the term of the Agreement, any agreed export or transition period, and the deletion and backup-expiry periods in Section 15. Processing may continue for specific data under a documented legal hold or legal retention obligation.

Nature of processing. Collection, receipt, recording, organisation, structuring, classification, storage, retrieval, consultation, use, restriction, redaction, pseudonymisation, anonymisation, linkage, analysis, aggregation, transmission to approved Sub-processors, generation of AI suggestions and reports, export, return, deletion, and destruction. Also authentication, authorisation, tenant isolation, workflow enforcement, audit logging, notifications, background jobs, system monitoring, support, backup, recovery, and security operations.

Categories of data subjects.

• Customer workforce and users. Employees, crew, managers, safety, quality, audit, compliance, security, investigation, training and administrative personnel, executives, contractors, and authorised representatives.
• Reporters and sources. Identified, confidential, anonymous or pseudonymous reporters; witnesses; interviewees; survey respondents; whistleblowers; and persons providing safety or quality information.
• Operational persons. Flight crew, cabin crew, dispatchers, maintenance personnel, ground handlers, station personnel, contractors, and other operational participants.
• Passengers and third parties. Passengers, visitors, members of the public, injured persons, complainants, emergency contacts, and individuals mentioned in records or evidence.
• Suppliers and oversight subjects. Supplier personnel, outsourced service providers, audit contacts, regulators, inspectors, and persons associated with findings, actions, contracts or controls.
• Applicants and trainees. Persons whose qualifications, training, competency, acknowledgements or expiry information is managed in the Service.

Types of personal data.

• Identity and contact. Name, work email, personal email if submitted, phone, job title, employee or contractor identifier, signature, avatar, organisation, department, station, and manager relationships.
• Account and authentication. User ID, authentication ID, SSO subject, roles, permissions, MFA and passkey status, login history, session information, IP address, user agent, API key metadata, and provisioning data.
• Operational and aviation safety. Occurrence and hazard reports, reporter mode, narrative, flight or operation context, aircraft or asset identifiers, dates, locations, classifications, risk and barrier assessments, investigation information, witness statements, contributing factors, causal analysis, actions, CAPA, effectiveness, residual risk, and governance decisions.
• Quality, audit, and compliance. Audit plans, checklists, findings, observations, nonconformities, evidence, controls, requirements, applicability, regulatory changes, deadlines, responses, approvals, and attestations.
• Security and emergency. Security occurrences, threats, controls, crisis logs, emergency roles, response actions, exercise participation, emergency contacts, and readiness information.
• Training and competency. Training assignments, completion, qualifications, competency evidence, licences or certificates, acknowledgements, and expiry dates.
• Documents and communications. Controlled documents, revisions, comments, approvals, acknowledgements, email notifications, attachments, photos, audio or other evidence files, and free-text content.
• Survey and analytics. Survey responses, anonymity mode, pseudonymous deduplication hashes, result access logs, aggregate metrics, trends, and de-identified benchmark bands.
• Support and security telemetry. Support correspondence, request IDs, error metadata, redacted logs, security events, audit logs, and system usage metadata.
• Billing-related data. Subscription and invoice contact data. Payment card data is processed by Stripe and is not stored by eAviora.

Special category and Article 10 data. Customer Personal Data may include health or injury information, disability information, allegations of misconduct, criminal-offence information and other sensitive information, particularly within occurrence, investigation, emergency, security and employee-related workflows. These categories are foreseeable in this Service rather than incidental. Customer must have a lawful basis and apply appropriate access restrictions. eAviora will process such data only to provide the Service and under Customer instructions.

Current default retention posture.

• Core operational records, controlled documents, audit log, stage transitions. Retained during active service to preserve regulated history and workflow integrity, subject to Customer instructions, applicable law, legal holds, and end-of-contract deletion under Section 15.
• Occurrence report drafts. Expiry plus a 14-day grace period, then deletion with staged attachments.
• Email outbox. 90 days for terminal delivery records, subject to legal hold. Non-linkable confidential receipts are scrubbed after sending.
• Notifications. 365 days.
• Sessions. 90 days after revocation and garbage collection.
• AI execution logs. 365 days, subject to record legal hold.
• Rate-limit counters. Approximately 48 hours.
• Survey data. Customer-configured where available, default retain. Erasure is by identity redaction for supported respondent records.
• Backups. According to the backup lifecycle described in Annex II and the applicable Service plan.

Processing locations.

• Primary database, authentication, object storage. Canada, AWS ca-central-1 through Supabase.
• Application runtime and edge delivery. United States East and global edge through Vercel, as configured.
• AI model processing. United States through the Anthropic commercial API, where Customer uses AI features.
• Email, jobs, monitoring, DNS and WAF, billing. Canada, United States, Ireland, or global infrastructure as specified in Annex III and the current public Sub-processor register.

Security governance and accountability.

• Security and privacy controls are documented in maintained evidence artefacts, configuration manifests, runbooks, and test suites.
• Access to production is limited to authorised personnel and logged.
• Changes are managed through version control, pull requests, automated checks, and deployment controls.
• Security claims are classified as verified, vendor-attested, or not supported, to avoid unsupported representations.

Tenant isolation and access control.

• Customer tenant isolation is enforced at the database layer using organisation context and row-level security patterns, not only by user interface filtering.
• Role-based access, module entitlements, record permissions, sensitivity tiers, explicit clearances, and record-level evidence checks are applied according to the relevant surface.
• Privileged actions are attributed to named identities. API and automated-agent activity is scoped and audit logged.
• WebAuthn passkeys, TOTP multi-factor authentication, SAML 2.0 SSO, and SCIM provisioning are supported where enabled and included in the applicable plan.

Encryption and key management.

• HTTPS and TLS are used for data in transit, with HSTS and security headers at the application edge.
• Primary database, object storage, and backups use provider-managed AES-256 encryption at rest.
• Third-party integration credentials stored by eAviora are encrypted at the application layer using AES-256-GCM with authenticated encryption and unique salt and IV values.
• Application secrets are classified in a secret manifest and subject to defined ownership and rotation practices.
• Customer-managed encryption keys and BYOK are not included in the standard Service unless expressly agreed.

Confidential reporting and minimisation.

• Occurrence reporting supports identified, confidential, and anonymous modes subject to Customer configuration.
• For confidential and anonymous postures, direct reporter linkage is withheld from the operational record at write time, and reporter metadata is stripped based on mode and viewer privilege.
• Anonymous reports do not persist the reporter address beside the record, and network identifiers are not retained with the anonymous record audit entry.
• Confidential communications are designed to avoid reconstructable linkage between the recipient address and the operational record.
• Survey anonymity supports attributed, pseudonymous, and severed modes, with one-way hashes and k-anonymity controls for aggregate results.

Auditability and integrity.

• Operational changes are recorded in a tenant-scoped audit trail under the acting identity.
• Audit entries are created with the related transaction where applicable, supporting a tamper-evident history of record changes and workflow transitions.
• AI suggestions and human decisions are logged, including whether a suggestion was accepted, modified, or rejected.
• Downloads and destructive actions for protected evidence are subject to authorisation checks and audit logging.

AI safeguards.

• AI reads inherit applicable tenant, module, record, and sensitivity restrictions.
• Only data reasonably required for the requested analysis is sent to the AI provider.
• Customer operational data is not used to train general-purpose models under the commercial API terms used by eAviora.
• AI provides suggestions. Safety, quality, compliance, security, governance, and workflow decisions remain human controlled.
• Low-confidence or write-capable AI actions are subject to human review and approval controls.

Logging, monitoring, and data leakage prevention.

• Structured logging and observability apply shared scrubbing patterns for email addresses, API keys, tokens, credentials, and other sensitive values before serialisation.
• Error monitoring is designed to receive stack traces and metadata rather than Customer operational records.
• Security headers, CSP reporting, rate limiting, abuse prevention, and health monitoring protect public and authenticated surfaces.
• Security events and system activity are retained according to defined schedules and legal holds.

Availability, backup, and recovery.

• The standard production posture uses managed database and object storage in Canada.
• Daily physical backups are maintained through the managed database provider, with a rolling recovery set appropriate to the current Service plan.
• As of the version date, the standard posture supports approximately a 24-hour recovery point objective through daily backups. Point-in-time recovery or a tighter RPO applies only if expressly enabled and committed in the applicable SLA or Order Form.
• Application runtime is stateless. Durable Customer Data is stored in managed database and object-storage services.

Secure development and testing.

• Automated type checking, linting, unit tests, contract tests, workflow doctrine tests, seed alignment tests, taxonomy drift checks, and security-focused regression tests are used according to the development pipeline.
• Database-bound tests verify high-risk controls such as confidential reporting, anonymous PII absence, storage-object authorisation, and selected workflow and tenant-boundary behaviour.
• Dependencies and infrastructure configurations are maintained through controlled source repositories and deployment processes.

Incident response.

• eAviora maintains operational procedures to identify, contain, investigate, remediate, and document security incidents and Personal Data Breaches.
• Relevant evidence is preserved, access is restricted, and Customer communications are coordinated under Section 12.
• Post-incident corrective actions are tracked to closure according to severity and risk.

Retention, deletion, and portability.

• Self-service organisation exports are available in formats including JSON, CSV, Parquet, and PDF, with signed download links where applicable.
• Supported user and survey erasure functions anonymise identity while preserving required audit and operational integrity.
• Scheduled retention jobs purge defined transient data categories.
• End-of-contract tenant return and deletion are completed under Section 15, including deletion confirmation and backup expiry.

Sub-processor and supplier management.

• Sub-processors are maintained in a single legal register with purpose, location, and contract information.
• New Sub-processors are subject to review, written data protection obligations, transfer mechanisms where required, and Customer notice under Section 7.
• eAviora remains responsible for Sub-processor performance as described in this DPA.

Accuracy note. The standard Service does not currently include customer-managed encryption keys. Backup RPO, point-in-time recovery, dedicated region, single-tenant deployment, or enhanced log retention must be expressly stated in the applicable Order Form or SLA before they become contractual commitments.

Customer grants general written authorisation to the following Sub-processors under Section 7. This list is rendered from the same register published at eaviora.com/privacy (section 09), so the two can never disagree.

• Supabase, Managed Postgres, authentication, file storage. Data-processing terms.
• Vercel, Application hosting, edge functions, build pipeline. Data-processing terms.
• Cloudflare, Authoritative DNS, DDoS mitigation, web application firewall. Data-processing terms.
• Anthropic, AI model API for classification, risk and analyst agents. Operator data is NOT used to train models. Data-processing terms.
• Inngest, Durable background job runtime for notifications, retention and webhook delivery. Data-processing terms.
• Resend, Transactional email delivery (notifications, magic-links, digests). Data-processing terms.
• Stripe, Subscription billing for paid plans. eAviora never stores card data; Stripe is the cardholder data processor. Data-processing terms.
• Sentry, Error tracking and observability. Stack traces + metadata only, operator records are never sent. Data-processing terms.

Where a conflict exists between this Annex and the public register, the version most recently notified under Section 7 controls for future processing, while processing already performed remains governed by the version effective at that time.

Purpose. This Protocol governs processing of Confidential Reporter Data and Aviation Safety Data where ordinary privacy workflows could undermine Just Culture, reporter protection, investigation integrity, or the rights of another person. It is intended to support lawful, proportionate decisions by Customer, not to create an automatic exemption from privacy law.

Protected data. Reporter identity and contact details where a confidential or anonymous mode applies, witness and interviewee information, investigation working material, safety analyses and risk assessments, and any record Customer has designated protected, restricted, or confidential.

Reporter modes and disclosure posture. Identified reports carry the reporter identity in the record under normal access control. Confidential reports withhold direct reporter linkage from the operational record and restrict identity to an authorised role with explicit clearance. Anonymous reports do not persist reporter identity or network identifiers beside the record and cannot be reversed by eAviora.

Data subject request workflow. eAviora notifies Customer, locates responsive data, and supports segregation, redaction, pseudonymisation, or summary provision as instructed. eAviora does not independently decide whether an exemption or restriction applies. Confidential and anonymous information will not be reconstructed merely to answer a request.

Legal holds and retention. Customer may instruct preservation of specified records, identifying the legal basis, scope, and review date. eAviora applies the hold and maintains the audit trail. A hold overrides deletion for its scope and duration.

Regulatory and investigation requests. Requests from a regulator, accident investigation authority, or law enforcement body are handled under Section 13. eAviora notifies Customer where permitted and discloses only the minimum legally required.

AI processing of protected safety data. AI reads inherit the record confidentiality tier. A record a user is not cleared to see is not available to that user through an AI feature. AI output remains a suggestion subject to human decision.

These schedules complete the instruments referenced in Section 8.4. They are configuration, not restatement: the approved instruments are incorporated by reference and their full text is not reproduced here.

Annex V-A. European Commission Standard Contractual Clauses, Implementing Decision (EU) 2021/914.

• Module. Module Two (Controller to Processor) where Customer is a Controller. Module Three (Processor to Processor) where Customer is itself a Processor acting for another Controller.
• Clause 7 (docking). Not used.
• Clause 9 (Sub-processors). Option 2, general written authorisation. Notice period 30 days, per Section 7.2.
• Clause 11 (redress). Optional independent dispute-resolution paragraph not selected.
• Clause 17 (governing law). The law of Ireland, unless the Order Form names another EU Member State whose law allows third-party beneficiary rights.
• Clause 18 (forum). The courts of Ireland, unless varied under Clause 17.
• Competent Supervisory Authority. (a) The authority of the Member State in which the data exporter is established. (b) Where the exporter is not established in the EEA but has appointed an Article 27 representative, the authority of the Member State in which that representative is established. (c) Where the exporter is not established in the EEA and is exempt from appointing a representative under Article 27(2), the authority of a Member State in which the Data Subjects whose Personal Data is transferred are located.
• Parties. Data exporter is Customer, being the legal entity, registered address, contact person name, position and contact details, and Controller or Processor role stated in the Order Form, which supplies these SCC party particulars. Data importer is Eaviora Inc., a corporation incorporated under the Canada Business Corporations Act, registered office in the Province of Quebec, Canada, as stated in the Order Form; contact person: the person in charge of the protection of personal information, privacy@eaviora.com; role: Processor. Signature and date are supplied by execution of the Agreement and this DPA.
• Appendix information. Annex I of this DPA is the description of transfer, Annex II the technical measures, Annex III the Sub-processors. Frequency is continuous for the term; retention is as set out in Annex I and Section 15.

Annex V-B. United Kingdom International Data Transfer Addendum. For any UK restricted transfer the parties incorporate Part 2: Mandatory Clauses of the Approved Addendum, being the template Addendum B.1.0 issued by the ICO and laid before Parliament in accordance with s119A of the Data Protection Act 2018 on 2 February 2022, as it is revised under Section 18 of those Mandatory Clauses. The EU SCCs alone are not a valid transfer mechanism for a UK restricted transfer. Part 1 tables are completed as follows.

• Table 1, parties. Exporter is Customer, importer is Eaviora Inc., with contact details and roles as in Annex V-A.
• Table 2, selected SCCs. The EU SCCs configured in Annex V-A, including module selection, appendix information and optional-clause choices.
• Table 3, appendix information. Annexes I, II and III of this DPA.
• Table 4, ending the Addendum. Neither party may end the Addendum when the Approved Addendum changes, save as required by the ICO.

Where the Addendum and the EU SCCs conflict for a UK restricted transfer, the Addendum prevails.

Annex V-C. Swiss adaptations. For a transfer subject to the Swiss Federal Act on Data Protection, the EU SCCs apply with the adaptations recognised by the Federal Data Protection and Information Commissioner:

• Swiss-only transfer, governed by the FADP alone: the competent supervisory authority is the FDPIC; references to the GDPR are read as references to the FADP; references to EU Member State law are read as references to Swiss law, in place of the Irish law selected in Annex V-A.
• Dual transfer, governed by both the FADP and the GDPR: the FDPIC is competent for the Swiss portion and the authority identified in Annex V-A for the EEA portion. The Annex V-A governing law and forum continue to apply to the EEA portion; Swiss law applies to the Swiss portion. The two regimes operate in parallel rather than one displacing the other.
• In either case the term Member State is not read so as to prevent a Data Subject in Switzerland from bringing proceedings in Switzerland, in accordance with Clause 18(c).