Easy Access Rules for Information Security (Regulations (EU) 2023/203 and 2022/1645)

ED Decision 2023/009/R

The organisation may choose to document some of the information required under point IS.I.OR.250(a) in separate documents (e.g. procedures). In this case, it should ensure that the manual contains adequate references to any document kept separately. Any such documents are then to be considered an integral part of the organisation’s information security management system manual.

In the event where an entity holds multiple authorisations or declarations, the ISMM may apply to one or more organisations at a time based on a common ISMS. This ISMM should include at least an approval document of each organisation and should formally be approved by each organisation’s accountable manager or responsible person. A common responsible person may be appointed as per IS.I.OR.240(d) and the guidelines of GM1 IS.I.OR.240(e).

To ensure that all parties involved can fulfil their responsibilities, all manuals, procedures, and communication between them are advised to be, at least, in one common language, e.g. English. Those parties involved include the competent authorities with which that common language should be agreed upon.

Regulation (EU) 2025/2293

(a)Changes to the ISMS may be managed and notified to the competent authority in a procedure developed by the organisation. That procedure shall be approved by the competent authority, except for declared organisations.

(b)With regard to changes to the ISMS not covered by the procedure referred to in point (a), the organisation shall apply for and obtain an approval issued by the competent authority, except for declared organisations, for which an approval is not required.

With regard to those changes:

(1)the application shall be submitted before any such change takes place, in order to enable the competent authority to determine continued compliance with this Regulation and to amend, if necessary, the organisation certificate and related terms of approval attached to it;

(2)the organisation shall make available to the competent authority any information it requests to evaluate the change;

(3)the change shall be implemented only upon receipt of a formal approval by the competent authority, except for declared organisations, which may implement the change immediately;

(4)the organisation shall operate under the conditions prescribed by the competent authority during the implementation of such changes.

ED Decision 2023/009/R

Without prejudice to the communication of changes as required for each organisation in the corresponding implementing regulation for the domain as listed in point Article 2(1) of Regulation (EU) 2023/203, the procedure referred to in IS.I.OR.255(a) should take into account the criticality of the changes when proposing how they will be managed. In particular, those changes that could have an impact on the achievement or maintenance of compliance with the provisions under Part-IS, or which could lead to an unacceptable level of risk (e.g. as per the guidance provided in GM1 IS.I.OR.205(c)), should be subjected to scrutiny. Upon establishment of this procedure, any further changes to it should be subject to approval by the competent authority.

Where prior approval is sought from the competent authority for a change not covered by an approved procedure, or where no such approved procedure exists, the organisation should provide at least the following information:

—the nature and purpose of the change;

—the implementation plan of the change;

—the verification plan of the change;

—the potential impact on aviation safety introduced by the change.

A significant deviation from the original implementation plan during the change process is an event that should be reported to the competent authority as this deviation may require reconsidering the change impact.

ED Decision 2023/009/R

Point IS.I.OR.255 is structured as follows:

Point (a) introduces the possibility for the organisation to agree with the competent authority that changes to the ISMS can be implemented without prior approval as long as these changes are covered in a change procedure.

Point (b) introduces an obligation of prior approval (by the competent authority) for changes not covered by the procedure mentioned above, and indicates how those changes should be handled.

The organisation should consider the establishment of a procedure in order to manage and notify changes to the competent authority as provided for under IS.I.OR.255(a). In case of lack of any approved procedure, the organisation will have, for any change, to apply for and obtain an approval as required under IS.I.OR.255(b). In any case, all changes should be notified to the competent authority upon implementation.

ED Decision 2023/009/R

RELATION BETWEEN CHANGES TO THE ISMS AND CONTINUOUS IMPROVEMENT

Changes stemming from the continuous improvement process established by the organisation (see IS.I.OR.260) should be handled as any other change according to the guidelines in AMC1 IS.I.OR.255 and GM1 IS.I.OR.255.

EXAMPLE OF CHANGES THAT MAY HAVE AN IMPACT ON THE ISMS

Below are some examples of changes that may have an impact on the ISMS, or which could lead to an unacceptable level of risk and therefore should be subject to scrutiny by the competent authority according to the provisions established under IS.I.OR.255:

(a)Changes to the scope of the ISMS, interfaces or related policies:

—The organisation expands its business functions, and integrates another company within its organisational structure.

—The organisation has identified non-conformities indicating an incorrect scope.

—The organisation amends its information security policy and/or information security objectives with a potential impact on aviation safety.

—Changes to the interfaces of the organisation resulting e.g. from modification in the insourced or outsourced activities.

(b)Changes in responsibilities and accountability as well as in the organisational structure involving the implementation and continuing monitoring of compliance with this Regulation:

—The accountable manager has delegated certain responsibilities under Part-IS to a person or a group of persons.

—The organisation contracts information security management activities as per IS.I.OR.235.

(c)Changes to the methodology used for risk management:

—The organisation changes the classification for likelihood or impact in their risk management methodology e.g. to obtain more granularity.

—The organisation implements changes to their risk treatment methodology.

—The organisation integrates its information security risk management into existing management systems.

(d)Changes to the security event management process:

—The organisation decides to contract security event management activities.

—The organisation changes the process to notify security events and the criteria to escalate to higher management for a quicker resolution.

—The organisation changes its policy for mitigating vulnerabilities.

—The organisation changes its incident recovery procedure.

EXAMPLE OF CHANGES THAT DO NOT HAVE AN IMPACT ON THE ISMS

Not all operational changes related to information security have an impact on the ISMS, therefore not all changes are required to be reported to the competent authority, following the provisions established under IS.I.OR.255. The following scenarios may be representative of such changes:

—After a successfully detected security event which could have easily evolved to an incident, the organisation decides to roll out an extensive cyber security awareness campaign for all employees.

—Update in the staff training programme and/or training content as a result of the continuous improvement processes established within the organisation.

—The organisation replaces the software tool that it uses for encrypting sensitive files with another software solution.

—The organisation has decided to make an internal restructuring for business reasons, changing the names of departments or sections, without making any changes in the responsibilities and accountability (e.g. accountable manager) involving the ISMS of the organisation.

—The organisation decides to update an existing preventive control e.g. configuring a new firewall in its internal network.

Regulation (EU) 2023/203

(a)The organisation shall assess, using adequate performance indicators, the effectiveness and maturity of the ISMS. That assessment shall be carried out on a calendar basis predefined by the organisation or following an information security incident.

(b)If deficiencies are found following the assessment carried out in accordance with point (a), the organisation shall take the necessary improvement measures to ensure that the ISMS continues to comply with the applicable requirements and maintains the information security risks at an acceptable level. In addition, the organisation shall reassess those elements of the ISMS affected by the adopted measures.

ED Decision 2023/009/R

The continuous improvement process (CIP), as required by IS.I.OR.200(b), should aim to continuously improve the effectiveness, suitability and adequacy of the ISMS. This should be achieved by a proactive and systematic assessment of the ISMS and all its elements — including its maturity. The assessment should take into account the outcomes and conclusions of other information security and assurance processes including audits, management reviews, evaluation of performance, effectiveness and maturity, as well as the outcomes of the derived corrective actions and corrections.

The steps to be performed should be at least the following:

(a)Identification of improvement opportunities based on the outcomes of the assessment of the ISMS with respect to its suitability, effectiveness, adequacy and, if deemed necessary, efficiency, as well as on any other suggestion for improvement. The assessment should consider performance indicators which reflect its processes and elements and the defined objectives for effectiveness and maturity.

(b)Evaluation of the identified opportunities regarding cost benefit, absence or reduction of undesired effects and achievement of the targeted objectives and intended outcomes.

(c)Proposal on the evaluated improvement opportunities to the management, and recommendation of actions to support their review and decision-making.

(d)According to the decision taken under point (c), planning, development and implementation of actions and changes to the ISMS, its processes or elements to achieve the improvements.

(e)Evaluation the effectiveness of the implemented actions and ISMS changes, and, as applicable, verification that the root cause of identified deficiencies has been eliminated.

The management should assess and review the outcomes of the CIP at planned intervals to ensure the continuing effectiveness, adequacy and suitability of the ISMS, to decide on the prioritisation of the implementation of actions and changes, as well as to revise or set new objectives or targets for continuous improvement.

ED Decision 2025/014/R

Point IS.I.OR.260 covers assurance processes for the ISMS in a manner that can be considered equivalent to the safety assurance in ICAO Doc 9859 ‘Safety Management Manual (SMM)’, which includes performance monitoring and measurement, management of change and continuous improvement of the SMS.

In this Regulation:

—IS.I.OR.260(a) addresses, using adequate performance indicators, the effectiveness and maturity assessment of the ISMS;

—IS.I.OR.260(b) addresses the improvement measures, i.e. corrections and corrective actions, for the deficiencies detected in IS.I.OR.260(a) and the continuous improvement process.

Similar provisions for continuous improvement are provided for in other information management systems such as ISO/IEC 27001 (see Appendix IV to this document).

The context and risk environment of organisations are never static and therefore require a dynamic adaptation, evolution and change of the organisation’s objectives, architectures, organisational structures and processes to maintain the information security risks at an acceptable level. Consequently, the ISMS should be considered as an evolving and learning part/element of the organisation which needs to be continuously monitored and improved to ensure alignment with the organisation’s safety objectives and effectiveness.

The CIP aims to continuously improve the effectiveness, suitability, adequacy and, if deemed necessary, the efficiency of the ISMS. An organisation may integrate the Part-IS CIP in some other already operated CIP and may apply methods such as Plan-Do-Check-Act (PDCA) Cycle or Define-Measure-Analyse-Improve-Control (DMAIC) (see also GM1 IS.I.OR.200).

The CIP is based on a proactive and systematic assessment of the ISMS and all its elements including the information security processes and controls driven by the ISMS. The assessment should be carried out against organisational targets for desired levels of performance, effectiveness and maturity. These targets, besides ensuring the achievement of compliance with the requirements under this Regulation, may also aim to include objectives established by the organisation’s policy or standards and by management decisions.

The above-mentioned assessment is based on the outcome of performance evaluations, audits, risk and incident processes, as well as already applied corrections and corrective actions. Some factors that should be considered when performing the assessment are the following:

—Adequacy refers to whether the system establishes the disciplines needed to manage information security, e.g. by using broadly accepted industry standards, in a sufficient manner with regard to compliance with the requirements of this Regulation.

—Effectiveness of the ISMS and the effective implementation of processes and controls driven by the ISMS is assessed by analysing whether:

—the information security risks are managed to achieve the safety objectives;

—the intended outcomes of the ISMS are achieved, and the requirements or objectives are met;

—all types of deficiencies are managed including failures to fulfil or correctly implement a requirement or control.

—Efficiency of the ISMS refers to the implementation of streamlined processes; however, efficiency improvements should not adversely impact effectiveness.

Identification of improvement opportunities

Improvement opportunities may be identified from the results of the CIP assessment or may be introduced as suggestions from other sources. The identification often involves deviations or corrective actions as well as ineffective processes or controls which are not remediated.

Suggestions for improvements stem from sources including:

—Risk management: the results of regular risk analysis and subsequent risk treatment are a primary factor in improving the ISMS, where the risk treatment process involves monitoring of the implemented security measures and evaluating their effectiveness.

—Performance & effectiveness evaluation: conclusions from (key) performance indicators, their measurement, analysis and continued monitoring as well as the result of the assessment of the effectiveness including the outcomes of the subsequently applied corrections and corrective actions

—Evaluation of maturity including the results of the subsequent corrections and corrective actions

—Lessons learned from the security incident detection, handling and response process and from a potential treatment of a root cause

—Results of (internal) audits may be used to verify whether the ISMS and controls within the audit scope meet the organisation’s requirements, and to determine where there are potential areas for improvement.

—Review and evaluation by management of the current action plan, setting or revision of the objectives or decision on improvement opportunities and actions

—Organisation’s suggestion programme (suggestions for improvement), reviews, surveys or assessments with employees or feedback from suppliers or interfacing parties

Any outcome of this process should be documented. The resulting actions may be integrated into an overarching action plan which is centrally consolidated and periodically reviewed according to the relevant policies. The resulting action plan may be further divided into a tactical, short-/mid-term action plan and a strategic, long-term action plan.

ED Decision 2023/009/R

(a)ISMS EFFECTIVENESS EVALUATION

When complying with IS.I.OR.260(a), the organisation should have a process in place to monitor, measure, evaluate and review the effectiveness of its ISMS that defines:

(1)who monitors, measures, analyses and evaluates the results and takes accountable decisions;

(2)when the above steps should be performed;

(3)which methods for monitoring, measurement, analysis and evaluation are applied to ensure comparable and reproducible results.

The calendar basis of the assessments should be commensurate with the maximum level of risk established under IS.I.OR.205.

The process to monitor, measure, evaluate and review the effectiveness of the organisation’s ISMS referred to under AMC1 IS.I.OR.260(a) should include as a minimum:

(1)the gathering and retention of metrics of the activities, and additional information that could be useful for monitoring purposes;

(2)the analysis of the metrics in order to identify trends and deviations from predefined performance targets.

(b)ISMS MATURITY ASSESSMENT

The organisation should assess the maturity of its ISMS using a suitable maturity model in order to identify areas for improvement to the ISMS. To do so, the organisation should:

(1)define or adopt a maturity model which represents a set of important and relevant processes and capabilities that are expected to be implemented and maintained;

(2)for each assessed process or capability, ensure that the model defines criteria against which specific aspects, characteristics and effectiveness should be assessed and evaluated when determining a maturity level;

(3)define for each assessed process or capability its desired target maturity level.

(c)For each assessed information security process or capability contained in the maturity model, the organisation should:

(1)evaluate and justify the current maturity level;

(2)identify any area for improvement it should make to reach the targeted maturity level;

(3)collect and record the evidence regarding strengths and weaknesses of the implemented ISMS and its evaluated maturity.

ED Decision 2023/009/R

(a)As general guidance, the elements of the ISMS that should be monitored, measured and evaluated should be, as a minimum:

(1)the risk assessment and treatment process (including risks at the interfaces with other organisations);

(2)the management of non-conformities and corrective actions;

(3)the incident and vulnerability management;

(4)the personnel competence management.

(b)Existing maturity models for ISMS maturity evaluation

As general guidance, for the definition or the adoption of a maturity model (MM), the following existing models may be considered:

—Cybersecurity Capability Maturity Model (C2M2), version 1.1: this model was published by the US Department of Energy in 2014. It introduces the notion of Maturity Indicator Levels (MIL) ranging from 0 to 3 and addresses not only performance levels but also performance practices (under Approach Objectives and approach progression) as well as assurance practices (under Management Objectives and institutionalization progression).

—Systems Security Engineering – Capability Maturity Model (SSE-CMM): published by ISO as ISO 21827 in 2008. It focuses on engineering practices, much less on operational practices that are split in 11 ‘Security Base Practices’, and 11 ‘Project and Organizational Base Practices’. It introduces the notion of five Capability Levels, from ‘Performed Informally’ to ‘Continuously Improving’.

—NIST Cybersecurity Framework (NIST CSF), version 1.1: published by NIST in April 2018. Although it is not proposed as a MM, the framework defines four ‘Implementation Tiers’, from ‘Partial’ to ‘Adaptive’, which are a qualitative measure of organisational cybersecurity risk management practices. It focuses on the functionality and repeatability of cybersecurity risk management.

—ATM Cybersecurity Maturity Model, edition 1: published in February 2019 by the EUROCONTROL NM for organisations in the ATM domain. Whilst not being designed for wider application, it can be adapted as necessary. It defines five maturity levels, ranging from ‘Non-existent’ to ‘Adaptive’ inspired by the ‘Tier’ terminology from the NIST CSF. In fact, the model is founded on NIST CSF, together with some elements of ISO/IEC 27001.

The following Table 1 maps the MM mentioned above to a hypothetical five-level MM.

Table 1: Mapping matrix of an existing MM to a hypothetical five-level MM

No specific maturity level is required. However, if and when compliance is achieved, organisations will determine which requirements of which models have already been met (mandatory) and can opt to reach a level that is beneficial to the organisation (voluntary). In the longer term, achieving higher maturity levels may increase the confidence of oversight authorities, which can have an impact upon the level of oversight activities regarding such organisation.

ED Decision 2023/009/R

When a deficiency is identified, the organisation should react in a timely manner following a defined process leading to a managed status regarding the deficiency, its associated consequences and, if needed, the prevention of its future recurrence or occurrence elsewhere.

Based on an evaluation of the impact and extent of the deficiency and the potential consequences for the ISMS, the process should include as criteria for compliance:

(a)deciding on corrections and their implementation without undue delay in order to limit the impact of the deficiency and deal with its consequences as well as, as applicable, to control or eliminate it;

(b)deciding on the need for, and the implementation of, corrective actions to eliminate the cause(s) of, and contributing factors to, the deficiency based on a root cause analysis and an evaluation of actions remediating the cause aimed at being proportionate to the consequences and impact of the deficiency;

(c)verifying the implemented actions:

(1)to be effective and to result in acceptable residual risks,

(2)not to have unintended side effects leading to other deficiencies, new risks, or an ISMS not aligned with the applicable requirements, as well as

(3)for corrective actions, to effectively remediate or eliminate the root cause;

(d)reporting to and reviewing the identified deficiencies, action plan and results of the action taken with the accountable manager of the organisation or delegated person(s) and, as necessary, with other involved or affected roles and parties;

(e)documenting as evidence the detected deficiencies, the planned and implemented corrections and/or corrective actions with deadlines and responsible persons, the management feedback, the outcomes of the process step under point (c) above and, if necessary, the change decisions made for the ISMS itself.

ED Decision 2023/009/R

The ‘necessary improvement measures’ referred to in IS.I.OR.260(b) refer to correction or corrective actions to eliminate deficiencies or actions aimed at improving the effectiveness as well as the maturity of the ISMS.

A process satisfying the criteria defined in AMC1 IS.I.OR.260 should include the following aspects:

(a)identifying the extent, impact, context and triggers of the deficiency, evaluating it according to some established criteria, analysing potential consequences for the ISMS including a potential existence in other areas;

(b)deciding on corrections and their implementation to immediately limit the impact and manage the consequences of the deficiency as well as, as applicable, to control or eliminate it;

(c)deciding on corrective actions required to eliminate the (root) cause(s) of the deficiency that are proportionate to the consequences;

(d)reassessing the elements of the ISMS which may be affected by the implemented actions to ensure that no further risk is introduced;

(e)verifying the implemented actions referred to in point (c) of AMC1 IS.I.OR.260(b);

(f)reporting to and reviewing the outcomes of the process steps with the management (see point (d) of AMC1 IS.I.OR.260(b));

(g)documenting and evidencing the result of the process steps above (see point (e) of AMC1 IS.I.OR.260(b)).

ED Decision 2023/009/R

The following is a non-exhaustive list of examples of information security threat scenarios with a potential harmful impact on safety that may be considered by authorities and organisations.

Example 1: Aircraft to ATC digital communications

—Threat vector assets/domain

—ATC voice and ground automation systems

—ground communications providers

—air-ground/ground-air RF communications service providers

—aircraft and the assets used for voice and datalink communications

—Non-exhaustive summary of potential threats

—threat (availability): exceeding system performance, saturation of communication channel

—threat (integrity): man-in-the-middle or injection attacks

—threat (confidentiality): passive listening to communication, spying on hardware device

—Summary of threats scenarios and their potential harmful impacts on safety

—Disruption of services prevents ATC communication with a single or multiple aircraft and/or ATC ground system.

—Manipulation of data through a man-in-the-middle attack would present false information to the pilot and/or ATC system with the potential of creating a safety hazard or injection of data to the aircraft or ground systems to disrupt the service and capability.

—There are no specific regulatory requirements for encryption of data or voice for datalink communications; however, for confidentiality purposes, the assets used to provide and deliver the services should be controlled and limited to only those resources that require access to ensure that the services cannot be disrupted and manipulated in any way.

Example 2: Tampered air traffic data

—Threat vector assets/domain

—Internet service provider (ISP)

—ATM services network(s)

—surveillance data

—ATC systems

—Non-exhaustive summary of potential threats

—ISP compromise (confidentiality): An attacker gains unauthorised access to the systems or infrastructure of the ISP providing network services to ATM system.

—data tampering (integrity): Once the ISP is compromised, an attacker could manipulate data in transit. This could involve injecting false data or removing/modifying legitimate data.

—denial of service (availability): an attacker could also potentially disrupt the communication of data entirely, resulting in a denial of service (DoS) to the ATM system.

—malware injection (integrity/availability): An attacker could potentially use the compromised ISP as a launching pad to inject malware into the systems, causing further disruptions or enabling additional attacks.

—Summary of threats scenarios and their potential harmful impacts on safety

—ISP compromise: interception and/or manipulation of sensitive data, impacting the safe management of air traffic.

—data tampering: incorrect situational awareness, potentially resulting in reduced separation between aircrafts, and incorrect air traffic control decisions.

—denial of service: reduction of the ATC’s ability to ensure separation leading to the activation of contingency procedures, including capacity reduction, with the eventual possibility of large areas of airspace being closed.

Example 3: Aircraft operators’, CAMOs’ and aircraft maintenance organisations’ software supply chain and ground infrastructure, including equipment used to support aircraft management, operations and maintenance

—Threat vector assets/domain

—aircraft operators’, CAMOs’ and maintenance organisations’ supply chain

—aircraft operator or maintenance internal ground infrastructure used to manage aircraft and operations (hardware/software) and other information technology assets

—information technology assets used to update systems on an aircraft (software and hardware) used for maintenance activities

—Non-exhaustive summary of potential threats

—threat (availability): hardware/software/system disruption

—threat (integrity): compromised hardware/software/system

—threat (confidentiality): compromised hardware/software/system

—Summary of threats scenarios and their potential harmful impacts on safety

—Disruption to the dissemination of meteorological information while the aircraft is airborne, may reduce the ability of the flight crew to avoid potentially hazardous meteorological conditions (e.g. severe storms/fog at night).

—Manipulation of navigation data/database will have the effect that flight plans and navigation displays cannot be trusted.

—Lack of control and access to information such as fleet maintenance programme or flight crew planning affects the ability of organisations to maintain safe operations.

Application of bow-tie analysis to this example

Two coordinated bow-tie analyses of different risk dimensions are combined, as the ultimate interest lies only in the aviation safety consequence.

Example 4: Design and production organisations’ software, supply chain, design and manufacturing ground infrastructure

—Threat vector assets/domain

—design and production organisations’ supply chain for parts, hardware and software

—design and production organisations’ ground internal infrastructure used to manage software/hardware used in the manufacturing and development of products that will be used by aircraft manufacturers, operators or ATM/ANS ground automation systems (hardware/software) information technology assets

—design and production organisations’ information technology assets used by their customers to update systems on an aircraft (software/hardware) used for maintenance operations or ATM/ANS ground automation systems

—Non-exhaustive summary of potential threats

—threat (availability): systems used to store, transmit and exchange information are rendered unavailable for essential operations through DoS attacks

—threat (integrity): systems used to store, transmit and exchange information are compromised through man-in-the middle attacks

—threat (confidentiality): systems used to store, transmit and exchange information are accessed by insider or external threats

—Summary of threats scenarios and their potential harmful impacts on safety

—Disruption of systems used to store, transmit and exchange information in a manner that would prevent the proper management of the aircraft and its systems and adversely affect the operations of the aircraft

—Systems used to store, transmit and exchange information can no longer be considered trusted. If they are not maintained at a level to ensure that all information exchange, data and software can be considered trusted, both ground and aircraft operations are disrupted.

—Uncontrolled access to systems used to store, transmit and exchange information (including information that is received and exchanged with the supply chain) can provide technical details that could be used to craft more sophisticated attacks targeting safety-critical systems.

Example 5: Training system

—Threat vector assets/domain

—supply chain of all software and hardware that will be used in the training systems or training devices (including flight simulators) used to train pilot or ATM/ANS ground systems personnel

—internal infrastructure used in of all software and hardware that will be used in the design, manufacturing or production of products (hardware or software) that will be used in aircraft or ATM/ANS ground systems

—management of internal operating domains and system of all software and hardware that will be used in the design, manufacturing or production of products (hardware or software) that will be used in aircraft or ATM/ANS ground systems

—Non-exhaustive summary of potential threats

—threat (availability): training systems or training devices are rendered unavailable by means of DoS attacks when they are needed to be used

—threat (integrity): training systems or training devices are compromised through man-in-the middle attacks

—threat (confidentiality): functional models, information and data that are embedded in training systems or training devices are accessed by insider or external threats

—Summary of threats scenarios and their potential harmful impacts on safety

—Disruption of training systems (hardware and software) will have an impact on the organisations’ ability to maintain qualified staff. It would also prevent the aircraft and its systems from being properly operated and affect maintenance operations for ATM/ANS ground systems.

—The training model or the failure modes and associated emergency conditions differ from the real aviation system behaviour and therefore induce inappropriate responses. If the training systems cannot be trusted, this will affect the ability of organisations to maintain sufficiently qualified staff for their operations (pilots, maintenance or ATM/ANS ground personnel who have been exposed to improper training should be re-qualified).

—Lack of control and access to training systems affects the ability of organisations to maintain a training system that is known to be in a trusted state. In addition, uncontrolled access to training systems that embed functional models, information and data can provide technical details that could be used to craft more sophisticated attacks on the training system itself or on the real-world safety-critical system.

Example 6: Airport’s fuel delivery system and associated infrastructure

—Threat vector assets/domain

—ground fuel storage and distribution infrastructure

—digital systems used to control fuel pumping and metering

—supply chain for fuel delivery, including third-party fuel suppliers

—airport information technology assets used for fuel inventory management and scheduling deliveries

—Non-exhaustive summary of potential threats

—threat (availability): disruption of fuel supply or delivery systems

—threat (integrity): tampering with fuel control systems or measurement devices

—threat (confidentiality): unauthorised access to fuel supply and delivery data

—Summary of threats scenarios and their potential harmful impacts on safety

—Disruption to fuel delivery can lead to flight delays or cancellations, causing operational disruptions and potential safety issues if fuel reserves become critically low.

—Tampering with fuel control systems or measurement devices could lead to incorrect fuel loads being delivered to aircraft, impacting aircraft weight and balance calculations, and potentially causing fuel exhaustion incidents.

—Unauthorised access to fuel supply data could allow threat actors to manipulate fuel scheduling or inventory data, potentially causing disruptions to airport operations and fuel availability for aircraft.

Example 7: National competent authority’s NOTAM system and associated infrastructure

—Threat vector assets/domain

—National NOTAM system infrastructure and digital interface

—Supply chain for NOTAM system maintenance and updates

—National competent authority’s IT assets used for NOTAM creation, distribution, and storage

—Non-exhaustive summary of potential threats

—threat (availability): disruption of the NOTAM system or its access

—threat (integrity): tampering with NOTAM data or unauthorised NOTAM creation

—threat (confidentiality): unauthorised access to NOTAM data

—Summary of threats scenarios and their potential harmful impacts on safety

—Disruption to the NOTAM system could prevent the dissemination of critical aeronautical information to pilots and air traffic controllers, potentially leading to safety issues.

—Tampering with NOTAM data or unauthorised creation of NOTAMs could lead to incorrect information being disseminated, potentially resulting in pilots making decisions based on false or misleading data.

—Unauthorised access to NOTAM data could lead to information leakage, potentially revealing sensitive operational information.

Example 8: Aviation authority’s airworthiness directive (AD) system and associated infrastructure

—Threat vector assets/domain

—EASA AD system infrastructure and digital interface

—supply chain for AD system maintenance and updates

—EASA IT assets used for AD creation, distribution, and storage

—Non-exhaustive summary of potential threats

—threat (availability): Disruption of the AD system or its access

—threat (integrity): tampering with AD data or unauthorised AD creation

—threat (confidentiality): unauthorised access to AD data

—Summary of threats and their potential harmful impacts on safety

—Disruption to the AD system could prevent the dissemination of critical airworthiness information to aircraft operators and maintenance organisations, potentially leading to safety issues.

—Tampering with AD data or unauthorised creation of ADs could lead to incorrect information being disseminated, potentially resulting in aircraft operators and maintenance organisations making decisions based on false or misleading data.

—Unauthorised access to AD data could lead to information leakage, potentially revealing sensitive operational information.

ED Decision 2025/014/R

ED Decision 2025/014/R

AVIATION SERVICES

The following is a non-exhaustive and non-complete list of aviation services that can be used as a basis to identify the scope of the risk assessment for the organisation.

—aerodrome & ATM-MET service providers

—aeronautical digital mapping services

—aeronautical information management (AIM) – external, national, regional

—airports

—air traffic control (ATC) – external, superior

—air traffic management (ATM)

—approach (APP) & area control (ACC) Services – ER ACC, APP ACC

—cargo and passenger loading

—civil & state airspace user (AU) operations centres

—communication infrastructure

—flight information services / traffic information services (FIS/TIS) data integrator

—fuel calculation

—navigation infrastructure – ground-based, satellite-based

—non-ATM meteorological (MET) service providers

—mass & balance calculation

—non-aviation users (external)

—regional & sub-regional airspace management (ASM) and air traffic flow & capacity management (ATFCM)

—static aeronautical data services

—sub-regional demand & capacity balancing (DCB) common service providers

—surveillance infrastructure – airport, en-route, terminal manoeuvring area (TMA)

—route planning

—time reference services (external)

—tower (TWR) services

INTERFACES

Below are some examples of data exchange at the interfaces between organisations interacting in different functional chains, which can be used as a basis for identifying the scope of the risk assessment for the organisation.

Note 1: These examples are graphical representations based on the ‘Examples of ecosystem data exchange’ provided in EUROCAE ED-201A, Appendix B - Tables B-14, which can be consulted for further information.

Note 2: Although it is not an organisation, an aircraft has been included in all these examples for the sake of completeness of the description of the data exchange. The aircraft should be considered as an element within the scope of the ISMS of the organisation to which it belongs (typically the airline). Any data exchange between aircraft and other systems within the organisation should take into account existing security measures that may have been evaluated as part of aircraft certification (see also GM1 IS.I.OR.205(c)).

Figure 1: Interfaces of other organisations with an airline operator

Figure 2: Interfaces of an airline operator with other organisations

Figure 3: Interfaces of other organisations with a maintenance service provider

Figure 4: Interfaces of a maintenance service provider with other organisations