EASA 2028 FDM Guidance: Data and Integration Readiness

Executive Summary

EASA 2028 FDM guidance, from the European Union Aviation Safety Agency, concerns evidence of programme performance. European air operator certificate (AOC) holders already need an integrated, non-punitive flight data monitoring (FDM) programme for aeroplanes above 27,000 kg maximum certificated take-off mass, with source safeguards. (Source: eur-lex.europa.eu) EASA Executive Director Decision 2025/020/R applies from 1 January 2028. It revises acceptable means of compliance (AMC) and guidance material (GM); AMC are non-binding standards, not new universal statutory capture minima. (Source: www.easa.europa.eu)

The revised valid-data capture criterion uses 60% of the preceding 12 months’ flights for fewer than 20 in-scope aircraft, or 80% for 20 or more, excluding aeroplanes with fewer than 50 flights from that condition. (Source: www.easa.europa.eu) Individual collection failure should be identified either within 22 calendar days after failure occurs or before 10 more flights, then corrected within 120 days of awareness; at least 80% of collected flights from that period should be processed within 22 calendar days of flight completion or before 10 subsequent flights by the same aircraft. (Source: www.easa.europa.eu) Separate criteria address significant-event validation (80% within 15 calendar days of first software detection) and processable retention (80% for at least two years, with a transition provision). (Source: www.easa.europa.eu)

These are separate populations and clocks. ICAO, the International Civil Aviation Organization, likewise distinguishes completeness, timeliness and accuracy. (Source: ganpportal.icao.int) Integration should connect an independent achieved-flight register to collection, decoding, analysis and the safety management system (SMS). Operational messaging and provenance standards provide useful identification and processing-history conventions without prescribing an EASA implementation. ^{[1] [2]} Demonstrations should include missing-flight states, exports and historical reprocessing. GE Aerospace’s FlightPulse guide illustrates the distinction between absent recorder data and pending processing; it does not establish AMC compliance. ^[3]

Crew protection belongs in the architecture. Pseudonymisation differs from anonymisation, and access should follow purpose and role. (Source: www.edpb.europa.eu) ^[4] The decision is whether the operator and providers can reproduce their assessment from underlying records while controlling identity access. Contracting does not remove the operator’s responsibilities for purchased services. (Source: eur-lex.europa.eu) This report supplies an evidence matrix, an access-control map and a labeled synthetic worksheet. They support readiness assessment, not an individual compliance finding or a substitute for operator procedures and competent-authority acceptance.

Introduction and Background

The question behind “EASA flight data monitoring guidance 2028” is whether the collection pipeline, analysis service and management-system interface can demonstrate a functioning programme. ORO.AOC.130 already connects FDM to the operator’s management system and requires protection of its data sources. (Source: eur-lex.europa.eu) The future AMC adds more explicit ways to assess performance. A software purchase alone cannot supply the underlying flight inventory, crew agreements or accountable decisions.

The dated baseline is EASA’s Easy Access Rules for Air Operations, Revision 24, published 27 March 2026, incorporating the FDM amendment. (Source: www.easa.europa.eu) Research also checked the later July 2026 Part-ORO Amendment 30, whose stated subject is flight simulation training devices; its annex concerns training provisions. That check does not establish that every possible subsequent amendment has been excluded. (Source: www.easa.europa.eu) Operators should preserve the exact regulatory revision used in their assessment.

Three distinctions matter. The regulation supplies binding obligations; AMC provide a non-binding means of demonstrating compliance; GM explains interpretation and implementation. (Source: www.easa.europa.eu) A certificated operator considering an alternative means of compliance must follow the applicable prior-approval process, rather than treating a different vendor metric as an accepted alternative. The Irish Aviation Authority explicitly describes this process and includes Air Operations within its scope. (Source: www.iaa.ie)

LANDING.AERO’s perspective here is limited to the ground-system integration questions: what crosses each interface, who owns an exception and what can be exported for review. Airborne equipment selection, specialist FDM analysis and authority acceptance remain separate decisions.

The report distinguishes European Union (EU) requirements from supporting international and United Kingdom (UK) references. UK Civil Aviation Authority (CAA) CAP 739, dated June 2013, is used for process design, including operator accountability when analysis is outsourced, not as the source of the EU’s future thresholds. ^[5] No United States (US) Flight Operational Quality Assurance (FOQA) voluntary-programme provision is applied to EU AOC holders. The proposed controls and tests below are assessment methods, not operational instructions.

Key Changes

Representative capture becomes measurable

The current AMC describes a representative data-recovery strategy. The revised AMC specifies valid data available for processing over a rolling annual period and differentiates the capture criterion by in-scope fleet size. (Source: www.easa.europa.eu) Receipt cannot establish parameter validity or usable decoding.

The fewer-than-50-flight exclusion belongs to the capture condition. It should not be used to remove a low-utilisation aircraft from the programme or erase its collection-failure history. (Source: www.easa.europa.eu) A readiness assessment should retain the complete aircraft register and record the reason for each denominator adjustment. Fleet-size interpretation at an operational boundary should be documented with the competent authority.

Collection failure and processing use separate clocks

For an individual aeroplane, revised AMC1 describes identifying collection failure either within 22 calendar days after failure occurs or before 10 more flights are performed. Correction is described within 120 days of becoming aware of the failure. (Source: www.easa.europa.eu) The text uses an alternative. It should not be restated as a binding “whichever is earlier” deadline.

For processing, at least 80% of collected flights from the preceding 12 months should be processed within 22 calendar days of flight completion, or before 10 subsequent flights by the same aircraft. (Source: www.easa.europa.eu) This denominator differs from capture. A collection delay can consume processing time because the calendar clock starts with the flight, not the provider’s receipt.

Display both counters and document the chosen compliance procedure. Internal early-warning thresholds are engineering choices.

Validation, retention and risk coverage need explicit evidence

The revised AMC also addresses 80% of significant FDM events validated within 15 calendar days of first software detection. Validation establishes whether an event is genuine and abnormal; it is separate from causal analysis and risk assessment. (Source: www.easa.europa.eu) An event queue should therefore retain detection, validation and subsequent safety-action timestamps separately.

Retention includes keeping raw or decoded data until valid significant events have been analysed. It also describes 80% of the relevant files remaining processable for at least two years, with a lower proportion acceptable until two years after new software installation or the start of a new provider contract. (Source: www.easa.europa.eu) “Stored” should be tested through actual retrieval and reprocessing.

Revised AMC2 connects the core event set to changing procedures and significant risks. For aeroplanes first issued an individual certificate of airworthiness (CofA) on or after 1 January 2016, it identifies precursors concerning runway excursion, airborne collision, aircraft upset and terrain collision, subject to available data and algorithm complexity. Authority-requested documentation maps monitored occurrence types to events or measurements, covering at least the specified parts of Annex I, Sections 1 and 5, of Regulation 2015/1018, with paragraph 1.5(3) excluded. (Source: www.easa.europa.eu)

Aircraft cohorts affect parameter readiness

The 1 January 2029 first individual certificate of airworthiness (CofA) cohort has additional provisions. These include the recorder parameters specified by AMC1.2 CAT.IDE.A.190 collected within 90 calendar days after starting operation, parameter-performance verification, and specified documentation producible on authority request within that startup window. Continuous collection includes movement on the ground under the aircraft’s own power. (Source: www.easa.europa.eu) The fleet inventory therefore needs first-CofA and operational-entry dates, not just aircraft type.

Acceptance should identify the applicable cohort, provision, evidence and unresolved limitations.

Collection, Recovery and Integration Architecture

Reconcile flights before analysing events

Start an FDM data-recovery assessment with an independent operated-flight register and named reconciliation owner. Comparing receipt data only with itself cannot identify unreceived flights. ICAO’s guidance supports explicit business rules and metadata. (Source: ganpportal.icao.int) Outsourcing should preserve operator accountability, consistent with CAP 739. ^[5]

Revised AMC1 anticipates automatic flight identification to facilitate links with occurrence, traffic and weather data. (Source: www.easa.europa.eu)

Aviation Information Data Exchange (AIDX) is IATA’s operational-flight messaging standard, not an FDM analysis format. ^[1] Its implementation guide provides useful identification conventions: a flight-leg identifier combines operational attributes, dates and airports, while the origin date remains static through a flight’s history. ^[6] A diversion does not simply replace the originally scheduled arrival airport in that identifier. ^[6] These conventions illustrate why flight number plus local date is an inadequate integration specification.

For an operator’s canonical flight record, this report recommends:

• Stable identity: preserve the original operational identifier alongside internal identifiers and registration.
• Time basis: normalize timestamps and preserve their meaning; AIDX uses Coordinated Universal Time (UTC). ^[6]
• Operational history: retain corrections, diversions and replacements instead of silently overwriting joins.
• Receipt evidence: record file identity, acquisition method, receipt time and duplicate status.
• Quality status: distinguish received, decodable, valid, processed and rejected records.
• Reconciliation owner: assign unresolved flight matches to a named operational function.

This separates a recommended data model from the compliance criterion. ICAO’s general data-quality guidance supports defining standards, business rules and metadata, but does not prescribe an FDM schema. (Source: ganpportal.icao.int)

Treat decoding and analysis as controlled transformations

Acquisition, download, distribution and analytics are distinct stages in Teledyne’s GroundLink description. ^[7] Its documented onboard compression and encryption address transport, which is different from proving correct decoding or successful event analysis. ^[7] A transport-success flag should therefore remain separate from a valid-flight flag.

Products also expose different layers. CEFA describes software that can read raw recorder binary data or interface with analysis systems. ^[8] Safran describes centralised access to flight-data insights. ^[9] These are vendor-described capabilities, not interchangeable export specifications. The relevant procurement question is what information crosses the operator’s actual boundary.

Provenance records entities, activities and people involved in producing data. ^[2] The World Wide Web Consortium’s (W3C) provenance framework expressly includes processing steps and interchange representations. ^[2] A practical FDM lineage record should connect the source file, decoder definition, parameter conversion, algorithm release, event result and any analyst correction. Configuration-change control, in US National Institute of Standards and Technology (NIST) terminology, changes a documented baseline through defined processes and approval stages. ^[10]

Recommended acceptance evidence includes:

• Decoder applicability: aircraft configuration and time period for which a definition applies.
• Parameter meaning: source, units, scaling, rate, resolution and missing-value treatment.
• Algorithm identity: release identifier, trigger logic, thresholds and required parameters.
• Reprocessing history: original result, revised result, release used and reason for rerun.
• Decision linkage: validated event and associated safety-action reference.

Acceptance should verify the applicable aircraft, time period and documentation release. Test whether a reviewer can reconstruct changed results after an update. ^[10]

Implementation Considerations and Process Changes

A dated rule-to-evidence matrix

Table 1 translates the regulatory distinctions into a proposed FDM data-recovery readiness matrix. The owners, exports and tests are recommendations. The dates and criteria belong to the cited provisions; an export column does not imply a mandated file format.

The matrix reveals shared responsibilities. A vendor can supply processing logs, but the operator still needs flight records and a decision on the applicable aircraft population. Finnish authority Traficom likewise assigns operators responsibility for the safety of their own operations. (Source: www.traficom.fi) CAP 739’s outsourcing discussion retains overall responsibility with the operator’s accountable manager; that is supporting UK practice, not a replacement EU rule. ^[5]

Supplier Responsibilities and Acceptance Tests

Contract around evidence and transitions

Service scope should distinguish acquisition, decoding, automatic event generation, analyst validation and SMS transfer. Request a written schedule of deliverables for each boundary. Report availability should be tested separately from export: can identifiers, units and configuration information be interpreted after the data leave the portal? CNIL’s architecture guidance identifies structured portability as a consideration for externally hosted systems. ^[11] Neither a screenshot nor the word “integration” establishes the scope of an operator’s contract.

Before procurement or renewal, request:

• Export coverage: raw or decoded files, flight-level status, events, validation history and configuration metadata.
• Clock definitions: flight completion, failure onset evidence, awareness, first detection and completed processing.
• Interface ownership: responsible party for every input, rejected record and changed schema.
• Historical portability: a structured export that can be interpreted outside the live portal.
• Transition arrangements: archive custody, decoder access and event-history continuity during provider change.
• Privacy instructions: permitted purposes, access routes and procedures for return or deletion.

France’s data protection authority, CNIL, recommends mapping data flows when designing architecture and considering portability in structured, commonly used formats. ^[11] Its processor guide calls for documented client instructions and arrangements for returning or deleting data at service completion. ^[12] These recommendations support the contract review; they do not establish that any named vendor offers every requested export.

Phase acceptance around observable outcomes

Start with a documented baseline, then test collection, processing, access and recovery separately. ICAO’s data-quality guidance assigns quality responsibility to designated positions; a checklist without ownership is incomplete. (Source: ganpportal.icao.int) Use the following proposed acceptance sequence:

• Inventory: establish the aircraft population and achieved-flight reconciliation.
• Collection: replay missing, duplicated and delayed file arrivals.
• Analysis: verify decoder applicability and processing-job status.
• Event workflow: distinguish automatic detection from analyst validation.
• Protection: test permitted joins and denied identity access.
• Exit and restore: export a representative package and reprocess a retained flight.

Record the expected result before each test. Keep the evidence and defects against the controlled baseline rather than relying on a demonstration environment. NIST’s configuration-control terminology provides a useful model for documenting approved changes between acceptance runs. ^[10]

Crew Safeguards and the SMS Interface

Link safety information without exposing crew identity

An SMS interface needs decision context and controlled identity access. Poland’s aviation authority describes FDM as part of the SMS and comparison with mandatory and voluntary occurrence reports. (Source: ulc.gov.pl) CAP 739 supports read-across between FDM and safety-report information. ^[5]

Pseudonymisation differs from anonymisation; genuinely anonymised information is not personal data. (Source: www.edpb.europa.eu) Removing names does not necessarily anonymise flight records: route, time and operational information can remain linkable.

The revised AMC also calls for a written crew-identity protection procedure signed by management and flight crew representatives. Access roles should implement that agreed procedure, including controlled follow-up and disclosure. (Source: www.easa.europa.eu)

For EU personal-data processing, the General Data Protection Regulation (GDPR) requires minimisation and purpose-based retention. (Source: eur-lex.europa.eu) Proposed SMS profiles should restrict case information to what each role requires, following CNIL’s access guidance. ^[4]

Table 2 maps a proposed data flow and access model. The role assignments are recommendations, not a prescribed organisational chart or claims about a named product.

Separating identity lookup from analytics permits controlled linkage. GE’s FlightPulse guide illustrates a product-specific model: individual-flight visibility depends on operating-crew participation. ^[3] Delegating processing does not remove the controller’s lawfulness responsibility, as the European Data Protection Supervisor explains. (Source: www.edps.europa.eu)

Recommended controls include:

• Purpose: specify what each occurrence, weather and personnel join supports.
• Roles: separate reconciliation, analysis, identity lookup and general reporting.
• Accounts: attribute access to individuals and avoid routine shared credentials. ^[4]
• Disclosure: record the reason, authorisation and information released.
• Retention: distinguish active use, controlled archive and authorised deletion. ^[13]

For outsourced processing, define instructions and contractual safeguards. (Source: eur-lex.europa.eu) Transfers outside the EU or European Economic Area have specific safeguards. (Source: www.edps.europa.eu) Test the written crew-protection agreement against actual permissions, including support access. ^[4]

Data Analysis and Evidence

A transparent annual denominator worksheet (Hypothetical Example)

This synthetic example demonstrates arithmetic, not observed airline performance or an industry benchmark. Counts are analyst-selected; thresholds and exclusions come from the revised AMC. (Source: www.easa.europa.eu) Received, valid and timely records represent separate quality dimensions. (Source: ganpportal.icao.int)

Assume 18 in-scope aeroplanes: two each operated 40 flights and the others 10,000, totalling 10,080. The worksheet excludes their 80 flights from capture but retains both aircraft in the fleet-size count.

Table 3 shows the calculations. Collected means distinct operated flights with received data, not total uploads. The processing denominator retains low-utilisation flights; these assumptions must remain visible for review.

The synthetic results exceed the applicable capture and 80% collected-flight processing criterion. (Source: www.easa.europa.eu) They do not demonstrate individual-aircraft failure detection, significant-event validation, processable archives or representative coverage of routes and risks.

Keep rejection separate from successful processing. GE’s guide illustrates absent-data and pending-processing states, ^[3] and a data-update timestamp. ^[3] Neither delivery nor an interface refresh proves completeness.

Audit the calculations and the blind spots

The proposed worksheet should be reproducible through the following checks:

• Population: reconcile the operated-flight total with an independent operational register.
• Uniqueness: count distinct flights, not retransmissions or file fragments.
• Exclusions: retain aircraft, flight totals, reason and applicable assessment period.
• Validity: apply documented parameter-quality rules before incrementing the capture numerator.
• Timeliness: preserve the evidence behind calendar and subsequent-flight classifications.
• State balance: show that timely, late, pending and unusable categories reconcile to collection.

The independent register needs an explicit custodian and a correction process. ICAO’s general performance-data guidance assigns quality responsibility to designated positions. (Source: ganpportal.icao.int) For this proposed FDM assessment, the operator should also record who can change a flight’s eligibility or quality status and preserve the previous value.

Data volume also differs from contextual completeness. The US National Weather Service’s Aviation Weather Center provides a machine-to-machine application programming interface (API) for weather access and worldwide METAR formats. ^[14] Its documentation describes access to the previous 30 days and a 100-requests-per-minute rate limit. ^[14] A retrospective programme using that interface would need an appropriate archive and controlled retrieval strategy; the live API is not evidence of indefinite historical availability.

CEFA’s documented weather integration and external-media synchronization show possible contextual capabilities, while GE’s guide documents takeoff and landing weather views. ^{[8] [3]} These are vendor examples, not independent accuracy benchmarks. Every join should preserve observation time, source and matching method so reviewers can distinguish recorded flight parameters from added context.

Implications and Future Directions

Buy an evidence path, not an assurance label

The procurement decision should compare what the operator can reconstruct from each proposed configuration. Acquisition, centralised analysis, animation and shared benchmarking serve different purposes. Teledyne documents raw-data delivery, Safran centralised analysis access, and CEFA raw-binary visualization. ^{[7] [9] [8]} None of those descriptions alone demonstrates the operator’s end-to-end readiness.

IATA’s Flight Data eXchange (FDX) is an aggregated, de-identified database whose processing uses a predefined event set and supports global, regional and airport benchmarking. ^[15] Such comparison is a different output from an operator’s own missing-flight ledger or configuration-controlled event history. A broader dataset should not replace evidence of the local collection and safety-action process.

Recommended selection criteria are:

• Reproducibility: can the operator export the population and recreate the calculation?
• Portability: do structured exports preserve interpretation as well as values? ^[11]
• Configuration: can a historical event be linked to its documented baseline? ^[10]
• Protection: can useful analysis proceed without routine identity disclosure? (Source: www.edpb.europa.eu)
• Accountability: are residual actions assigned within the operator’s safety system? (Source: www.traficom.fi)

CNIL’s architecture guidance supports designing data flows before deployment, and W3C provenance supports expressing processing history independently of a particular dashboard. ^{[11] [2]} These are useful reference frameworks, not prescribed technologies. A suitable existing service may already supply the evidence; custom integration is justified only where a specific gap remains.

Preserve a living assessment

The implementation record should retain source revisions, scope decisions, test results and unresolved questions. ICAO’s general data-management guidance emphasises standardisation and designated quality responsibility; Traficom also describes monitoring progress against safety objectives. (Source: ganpportal.icao.int) (Source: www.traficom.fi) The assessment should therefore be reviewed after material fleet, decoder, algorithm, provider or interface changes.

Retention and portability deserve particular attention during transitions. CNIL describes return or deletion according to the client’s instructions, while the GDPR limits identifiable retention by purpose. ^[12] (Source: eur-lex.europa.eu) Historical processing evidence and crew-identity information may require different access and retention arrangements. The answer should be documented, not inferred from a provider’s default storage setting.

An operator proposing an alternative compliance approach should use the competent-authority process rather than let a contractual service level stand in for acceptance. (Source: eur-lex.europa.eu) No operator-specific fleet records, accepted alternatives, vendor agreements or privacy arrangements were available for this report. Its conclusions concern the evidence to request and the tests to perform, not the compliance status of a particular organisation.

Conclusion

EASA 2028 FDM implementation readiness should be assessed as a connected evidence chain. The binding rule already requires an integrated and protected programme; the revised AMC supplies a more explicit compliance path. (Source: eur-lex.europa.eu) The relevant management decision is whether the operator can explain its population, reconcile missing flights, establish usable data, distinguish processing from validation and reproduce the history behind a safety conclusion.

The proposed matrices make that decision reviewable. Each boundary needs an owner, a defined record and an export that remains meaningful outside a dashboard. ICAO’s distinction between quality dimensions and W3C’s description of provenance are useful foundations for that assessment. (Source: ganpportal.icao.int) ^[2] The synthetic worksheet demonstrates the arithmetic only. An operational assessment needs the operator’s own records, documented exclusions and evidence behind every status.

Procurement should test those records before relying on a general capability statement. Structured portability, controlled configuration changes and purpose-limited access are practical acceptance criteria supported by the cited architecture, configuration and privacy guidance. ^{[11] [10]} (Source: eur-lex.europa.eu) They apply whether the operator uses an established service, an internal analysis environment or an integration layer between existing systems.

The resulting readiness decision should identify what is demonstrated, what remains unresolved and who must act. Provider involvement can supply specialist processing and technical evidence, but the operator retains responsibility for contracted activities. (Source: eur-lex.europa.eu) Keeping that accountability visible, alongside usable data and protected identities, is the practical basis for a defensible transition.