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

ED Decision 2023/009/R

The organisation should define and document the scope of the ISMS, by determining activities, processes, supporting systems, and identifying those which may have an impact on aviation safety.

The information security policy should be endorsed by the accountable manager and reviewed at planned intervals or if significant changes occur. Moreover, the policy should cover at least the following aspects with a potential impact on aviation safety by:

(a)committing to comply with applicable legislation, consider relevant standards and best practices;

(b)setting objectives and performance measures for managing information security;

(c)defining general principles, activities, processes for the organisation to appropriately secure information and communication technology systems and data;

(d)committing to apply ISMS requirements into the processes of the organisation;

(e)committing to continually improve towards higher levels of information security process maturity as per IS.I.OR.260;

(f)committing to satisfy applicable requirements regarding information security and its proactive and systematic management and to the provision of appropriate resources for its implementation and operation;

(g)assigning information security as one of the essential responsibilities for all managers;

(h)committing to promote the information security policy through training or awareness sessions within the organisation to all personnel on a regular basis or upon modifications;

(i)encouraging the implementation of a ‘just-culture’ and the reporting of vulnerabilities, suspicious/anomalous events and/or information security incidents;

(j)committing to communicate the information security policy to all relevant parties, as appropriate.

Note: A significant change is a notable alteration or modification that has a meaningful impact on the organisation’s operations, such as a structural change within the organisation due to reorganisations, a change in the business processes (e.g. working from home, use of personal devices), a technological evolution (e.g. distributed computing resources, artificial intelligence/machine learning) or an evolution in the threat landscape.

ED Decision 2023/009/R

INFORMATION SECURITY POLICY AND OBJECTIVES

The information security policy should suit the organisation’s purpose and direct its own information security activities. Such policy should contain the needs for information security in the organisation’s context, a high-level statement of direction and intent of the information security activities, the principles and most important strategic and tactical objectives to be achieved by the ISMS, as well as the general information security objectives or a specification of a framework (who, how) for setting information security objectives. The information security policy should also contain a description of the established ISMS, including roles, responsibilities and references to topic-specific policies and standards.

The information security objectives should be:

—consistent and aligned with the information security policy and consider the applicable information security requirements, derived from the overarching organisation’s objectives, and the results from the risk assessment and treatment (which, in turn, supports the implementation of the organisation’s strategic goals and information security policy);

—regularly reviewed to ensure that they are up to date and still appropriate;

—measurable if practicable (to be able to determine whether the objective has been met), aimed to be SMART (specific, measurable, attainable, realistic, timely) and aligned with all affected responsible persons.

When defining information security objectives, e.g., based on the overarching organisation’s objectives, the information security requirements or the results of risk assessments, it should be determined how these objectives will be achieved. The degree to which information security objectives are achieved must be measurable. If possible, it should be measured by key performance indicators (KPIs) which have been defined in advance (refer to resources such as COBIT 5 for Information Security). It is recommended to start with the definition of a limited number of information security objectives which are relevant for the organisation, more of a long-term nature and measurable with a reasonable effort relative to the delivered benefits.

ED Decision 2023/009/R

COMPLIANCE MONITORING

When establishing compliance with the provisions under point IS.I.OR.200(a)(12), the organisation should implement a function to periodically monitor compliance of the management system with the relevant requirements and adequacy of the procedures including the establishment of an internal audit process and an information security risk management process. When the organisation has already established a compliance monitoring function under the implementing regulation for its domain, such function should include the monitoring of the management system with the relevant requirements within the scope of its activities. Compliance monitoring should include a feedback mechanism of audit findings to the accountable manager or delegated person(s) to ensure implementation of corrective actions as necessary.

ED Decision 2023/009/R

COMPLIANCE MONITORING

For the purpose of compliance monitoring, internal audits should be conducted at planned intervals to provide assurance on the status of the ISMS to the management and to provide information on the following:

—conformity of the ISMS to the requirements of this Regulation and the organisation’s own requirements either stated in the information security policy, procedures and contracts or derived from information security objectives or outcomes of the risk treatment process;

—effective implementation and maintenance of the ISMS.

Internal audits should follow an independent approach and a decision-making process based on evidence. Moreover, when setting up an audit programme, the importance of the processes concerned, and definitions of the audit criteria and scope should be considered. Documented information should be retained evidencing the audit results, their reporting to the relevant management and the audit programme.

ED Decision 2023/009/R

When establishing compliance with the provisions under points IS.I.OR.200(a)(13), the organisation should implement and maintain information security controls that are sufficiently robust and effective to protect information and ensure the need-to-know principle (i.e. limiting access to information to only those who need it to perform their duties). It should protect the source of information in accordance with the relevant provisions established in Regulation (EU) 2018/1139. It should also comply with Regulation (EU) No 376/2014.

ED Decision 2023/009/R

When establishing compliance with the provisions under point IS.I.OR.200(c), the organisation should:

(a)provide an outline of the structure of the specific information security personnel (internal and external), including their roles and responsibilities. This outline of the structure will be used to manage and maintain the elements included within the scope of the ISMS and will be approved by the accountable manager. The organisation should review the outline of the structure at planned intervals or if significant changes occur (see the Note in AMC1 IS.I.OR.200(a)(1));

(b)identify and categorise all relevant contracted organisations used to implement the ISMS. The organisation should define and document procedures for the management of interfaces and coordination between the organisation and other organisations, including contracted organisations;

(c)identify and define all key processes and procedures, and internal and external reporting schemes, that will be used to maintain compliance with the objectives of this Regulation over the life cycle of the ISMS. The organisation may adjust existing processes or procedures for compliance;

(d)identify and document any other information that will be used to maintain compliance with the objectives of this Regulation;

(e)when creating and updating documented information, ensure appropriate identification and description (e.g. a title, date, author, or reference number) as well as a review and an approval for suitability and adequacy;

(f)control the documented information required by the ISMS to ensure that it is:

(1)available and suitable for use, where and when it is needed;

(2)adequately protected (e.g. from loss of confidentiality, improper use, or loss of integrity).

ED Decision 2023/009/R

The amount of information that should be documented to maintain compliance with the objectives of this Regulation may vary between organisations due to various factors, such as size and complexity, or the need for harmonisation with other management processes already in place. As general guidance, taking into account the documents required to comply with point IS.I.OR.200(a), the record-keeping requirements referred to in IS.I.OR.245 and the information security management manual requirements referred to in IS.I.OR.250, the following is a non-exhaustive list of information that should be documented:

(a)information security policy that should include the organisation’s information security objectives — see IS.I.OR.200(a)(1);

(b)responsibilities and accountabilities for roles relevant to information security — see IS.I.OR.250(a)(2), (3), (6) and (7) and the personnel requirements referred to in points IS.I.OR.240(a), (b), (c), (d) and (f) and the related AMC and GM;

(c)scope of the ISMS and the interfaces with, and dependencies on, other parties — see IS.I.OR.200(a)(2) and the information security requirements referred to in points IS.I.OR.205(a) and (b);

(d)information security risk management process — see the information security requirements referred to in points IS.I.OR.205 and IS.I.OR.210;

(e)archive of the risks identified in the information security risk assessment along with the associated risk treatment measures (often referred to as ‘risk register’ or ‘risk ledger’) — see IS.I.OR.245;

(f)evidence of the competencies necessary for the personnel performing the activities required under this Regulation — see IS.I.OR.240(g) and the related AMC and GM;

(g)evidence of the current competencies of the personnel performing the activities required under this Regulation — see IS.I.OR.245(b)(1);

(h)(key) performance indicators derived from evidence of the monitoring and measurement of the ISMS processes.

ED Decision 2025/014/R

PROPORTIONALITY IN ISMS IMPLEMENTATION

When implementing the processes and procedures, as well as establishing the roles and responsibilities required under point IS.I.OR.200(d), the organisation should primarily consider the risks that it may be posing to other organisations, as well as its own risk exposure. Other aspects that may be relevant include the organisation’s needs and objectives, information security requirements, its own processes and the size, complexity and structure of the organisation, all of which may change over time.

As a general guide, the following aspects of the degree of safety relevance and organisational complexity could be taken into account when defining the ISMS. Each of these influences the implementation of the ISMS in certain areas:

(a)The organisation’s position in the functional chain and the number and degree of safety relevance of the interfacing organisations/stakeholders.

(b)The complexity of the organisational structure and hierarchies (e.g. number of staff, departments, hierarchical layers, external location, subsidiaries, etc.)

(c)The complexity of the information and communication technology systems and data used by the organisation and their connection to external parties.

More details on the influence on the proportionate implementation of Part-IS for each aspect of safety relevance and organisational complexity are provided in Appendix V.

SUPPORTED IMPLEMENTATION OF THE ISMS

In the context of Part-IS, all organisations initiate the implementation of an ISMS with determining its scope, which in turn is based upon at least an assessment of aviation safety impacts for which information security incidents are a cause or a contributing factor. Organisations, irrespective of their size, may not have yet sufficient knowledge about their information security risks, and may consider seeking support by a service provider that can also provide additional personnel and expertise during this implementation phase of the ISMS. The same may apply to later phases of the ISMS implementation, and to this end organisations may want to consider the provision of IS.I.OR.235 and related AMC. Outsourcing specific ISMS functions, such as information security monitoring or incident response to service providers, may help ensure that the organisation has access to experienced personnel and expertise. Similarly, organisations may want to be supported by a service provider in performing risk assessments.

Regarding the establishment of the appropriate personnel to implement and comply with the provisions of this Regulation, organisations should always refer to AMC1 IS.I.OR.240(f) and GM1 IS.I.OR.240(f), by considering that multiple responsibilities may be assigned to one person, while always ensuring the independence of the compliance monitoring.

As an introduction to the nature of information security risks and their management, organisations may use, as initial guidance, the NIST Interagency Report (NISTIR 7621 Rev.1) ‘Small Business Information Security: The Fundamentals’.

INTEGRATION OF ISMS UNDER THIS REGULATION WITH EXISTING MANAGEMENT SYSTEMS

An organisation may take advantage of existing management systems when implementing an ISMS by integrating it with those existing systems.

By integrating the ISMS with existing management systems, the organisation may reduce the effort and costs required to implement and maintain the ISMS, while also ensuring consistency and alignment with the organisation’s overall management approach. Below is a non-exhaustive list of potential synergies that can be exploited when integrating the ISMS with an existing management system:

—Leverage existing policies and procedures: an organisation may use its existing policies and procedures as a foundation for its ISMS. This may help to ensure consistency and minimise the need for additional documentation.

—Align the ISMS with other management systems: an organisation may align the ISMS with other management systems, such as safety management systems (SMSs), to ensure that the ISMS is consistent with the organisation’s overall management approach.

—Use existing risk management processes: an organisation may use their existing risk management processes to identify and assess the information security risks potentially leading to aviation safety risks.

—Reuse existing controls: an organisation may reuse existing controls, such as access controls or incident management process, to implement the information security controls required by the ISMS.

—Continuous improvement process: an organisation may use the continuous improvement process of existing management systems to improve the ISMS over time.

ED Decision 2023/009/R

DEROGATION

Organisations should follow the directions provided in AMC1 IS.I.OR.205(a) and AMC1 IS.I.OR.205(b) to perform a documented information security risk assessment to seek the approval by the competent authority of a derogation under point IS.I.OR.200(e). In order to justify the grounds for a derogation, the risk assessment is expected to provide explanations for the exclusion of all elements from the scope of the ISMS. It is up to the authority to determine whether this assessment is deemed satisfactory for a derogation to be granted.

Organisations that would like to have the risk assessment performed by a third party should consider the requirements of IS.I.OR.235 and the related AMC.

ED Decision 2025/014/R

Any organisation that believes that it does not pose any information security risk with a potential impact on aviation safety, either to itself or to other organisations, may consider requesting an approval for a derogation by the competent authority following the procedure outlined in AMC1 IS.I.OR.200(e).

Existing safety risk assessments, such as those carried out as part of the SMS, can form the basis of enhanced assessments considering safety risks arising from information security threats.

It should be noted that applications for partial exemption from individual articles are not possible.

APPLICATION FOR A DEROGATION

In order to ensure a consistent approach by organisations when submitting a derogation request, the competent authority may establish an official derogation request application form.

The application for a derogation, based on the application form where one exists or in a format decided by the organisation, will need to be signed by the accountable manager of the applicant organisation and submitted to the appropriate competent authority for review and consideration.

The application for a derogation should contain preliminary information used for a pre-assessment by the competent authority, including:

—Company information and contact information;

—Affected approval(s);

—Detailed justification for the exclusion of the provisions;

—Overview of services that the organisation provides and receives;

—Architecture overview of information systems used for business operation;

—Summary of the high-level information security risk assessment aligned with the above architecture;

—Methodology used to perform the information security risk assessment;

—List of people and roles involved in the information security risk assessment process;

—Date and signature.

Note: At this stage, the high-level risk assessment needs to properly document the absence of information security risks that may impact safety. To do so, it should at least cover the identification of the scope and boundaries, as required under points IS.I.OR.205 (a) and (b), and the analysis of safety impact, as required under point IS.I.OR.205(c).

EVALUATION OF THE REQUEST FOR A DEROGATION

The competent authority reviews the information security risk assessment and other supporting documentation, normally assessing whether:

—the documentation is sufficient for a proper analysis and assessment;

—the repository or asset inventory of digital systems, data flows and processes is comprehensive;

—the high-level information security risk assessment has been conducted in accordance with the organisation’s methodology and with the appropriate diligence;

—the relevant stakeholders have been involved in the assessment process;

—the assessment has been performed by people with sufficient expertise in information security and aviation safety;

—the organisation has assigned and indicated a point of contact for enquiries.

Figure 1 below depicts the process, including the pre-assessment. If the pre-assessment provides the competent authority with sufficient evidence that the derogation request is legitimate and that the organisation meets the expected criteria, the process will proceed to the exchange of more detailed information.

Figure 1: Representation of the derogation process

Note 1 to Figure 1: The objective of this step is to obtain preliminary information about the organisation risk profile by using suitable means (e.g. questionnaire, self-assessment template, request tool, etc.)

Note 2 to Figure 1: The objective of this step is to conduct a pre-evaluation to check whether the organisation has the possibility to be granted a derogation. The pre-assessment allows to avoid a detailed assessment if the prerequisites for a derogation are not met.

EXPECTATIONS AND RECOMMENDATION AFTER DEROGATION APPROVAL

Once a derogation approval has been granted, the organisation is expected to undertake the following on a continuous basis:

—Comply with all provisions of the regulation which are not exempted, in particular point IS.I.OR.200(a)(13) which should not be limited to only protection of the received information. When transmitting information with confidential nature, the organisation needs to have secure means in place as well;

—Comply with Regulation (EU) No 376/2014 to take into account the obligation to comply with the reporting requirements.

—Monitor any changes in the organisation’s scope of work and identify those which may have a potential impact on the documented information, which supports the derogation approval. Where such changes are identified, the organisation should ensure that they are brought to the attention of the competent authority without delay and notified in accordance with the applicable implementing rule.

—Monitor the risk picture for any variation due to changes in the safety and security environment over time. To this end, point IS.I.OR.205(d) should be considered.

—Ensure that the accountable manager can demonstrate an understanding of the derogation process and the terms on which the approval has been granted. This means that at least one person in the organisation needs to have a basic understanding of the Regulation. To this end, point IS.I.OR.240(a)(3) and the related AMC and GM should be considered.

—Implement basic protection against information security risks according to industry best practices.

—Remain up to date with the latest information security threat landscape and consult the respective national authority for additional guidance.

EXAMPLES

Some examples of organisations that may consider asking for a derogation might include:

—An air operator that performs non-high-risk commercial specialised operations (SPO) with noncomplex aircraft, if the nature of the operations justifies the grounds for a derogation.

—An air operator that operates ELA2 aircraft as defined in Article 1(2)(j) of Regulation (EU) No 748/2012 with the exception of one aircraft that is operated in predefined operational conditions or under certain operational limitations.

—A maintenance organisation approved under Part-145 dealing only with maintenance of components or maintenance activities that do not contribute to ensuring the structural integrity of the aircraft nor any major safety-related functionalities — for instance, undertaking activities such as washing, removing coatings, painting, etc.

The aforementioned examples are not exhaustive and are only indicative of potential scenarios that might provide an initial basis for the preparation of an information security risk assessment that justifies the exclusion of all elements of an organisation from the scope of the ISMS.

Regulation (EU) 2023/203

(a)The organisation shall identify all its elements which could be exposed to information security risks. That shall include:

(1)the organisation’s activities, facilities and resources, as well as the services the organisation operates, provides, receives or maintains;

(2)the equipment, systems, data and information that contribute to the functioning of the elements listed in point (1).

(b)The organisation shall identify the interfaces that it has with other organisations, and which could result in the mutual exposure to information security risks.

(c)With regard to the elements and interfaces referred to in points (a) and (b), the organisation shall identify the information security risks which may have a potential impact on aviation safety. For each identified risk, the organisation shall:

(1)assign a risk level according to a predefined classification established by the organisation;

(2)associate each risk and its level with the corresponding element or interface identified in accordance with points (a) and (b).

The predefined classification referred to in point (1) shall take into account the potential of occurrence of the threat scenario and the severity of its safety consequences. Based on that classification, and taking into account whether the organisation has a structured and repeatable risk management process for operations, the organisation shall be able to establish whether the risk is acceptable or needs to be treated in accordance with point IS.I.OR.210.

In order to facilitate the mutual comparability of risks assessments, the assignment of the risk level pursuant to point (1) shall take into account relevant information acquired in coordination with the organisations referred to in point (b).

(d)The organisation shall review and update the risk assessment carried out in accordance with points (a), (b) and, as applicable, points (c) or (e), in any of the following situations:

(1)there is a change in the elements subject to information security risks;

(2)there is a change in the interfaces between the organisation and other organisations, or in the risks communicated by the other organisations;

(3)there is a change in the information or knowledge used for the identification, analysis and classification of risks;

(4)there are lessons learnt from the analysis of information security incidents.

(e)By derogation from point (c), organisations required to comply with Subpart C of Annex III (Part-ATM/ANS.OR) to Regulation (EU) 2017/373 shall replace the analysis of the impact on aviation safety by an analysis of the impact on their services as per the safety support assessment required by point ATM/ANS.OR.C.005. This safety support assessment shall be made available to the air traffic service providers to whom they provide services and those air traffic service providers shall be responsible for evaluating the impact on aviation safety.

ED Decision 2023/009/R

Part-IS does not require the use of any specific information security framework, such as ISO, NIST or others to develop the risk assessment or in general to implement risk management. Each framework offers different benefits and none of these frameworks is perfect for an individual organisation, and should be customised and tailored to meet the overall needs of an organisation as well as the specific need to consider aviation safety aspects.

Organisations whose information security frameworks have achieved industry certifications can provide this information as supporting artefacts; however, these organisations should show the applicability of the industry certification to the scope of this Regulation (see GM1 IS.I.OR.200).

General guidance on risk management, including risk assessment, can be found in ISO/IEC 27005 and ISO/IEC 31000 as well as NIST SP 800-30. Aviation organisations may also wish to consider aviation-specific guidance as defined in the risk management chapter of the latest version of EUROCAE ED-201A and, as appropriate to the specific operating environment, in the chapters of EUROCAE ED-204A, EUROCAE ED-205A and EUROCAE ED-206 covering risk management.

ED Decision 2023/009/R

When conducting an information security risk assessment, the organisation should ensure that all relevant aviation safety elements are identified and included in the ISMS scope as per IS.I.OR.200 and related AMC.

A means to comply with the requirement in point IS.I.OR.205(a) is to perform a preliminary high-level risk assessment or impact assessment, carried out in accordance with a documented methodology and following precise criteria for the inclusion in and exclusion from the ISMS scope of the elements listed in IS.I.OR.205(a).

ED Decision 2023/009/R

SCOPE AND BOUNDARIES IDENTIFICATION

The organisation should develop clear and comprehensive understanding of its aviation activities and services, the related processes and associated information systems, and the relevant data flows and information exchanges that define the scope of the ISMS and the boundaries for risk assessment. Therefore, the organisation should develop corresponding documentation on resources and dependencies related to computing, networking and contracted services which have the potential to affect the information security and safety of the functions, services or capabilities within the scope of the risk assessment.

The following non-exhaustive list provides examples of items that may be considered for the identification of the aforementioned scope and boundaries. The level of detail of the analysis can be an iterative process, with the effort commensurate with the expected level of risk. As stated above, the purpose is to establish understanding of all relevant assets, resources and dependencies that are directly a part of the functions, services and capabilities through the following activities:

(a)Identification of operational inputs and outputs relevant to the functions, services and capabilities of the organisation; these can be related to:

—internal or external sources;

—internal or external leased or managed services, or other dependencies;

(b)Identification of all relevant assets (i.e. hardware, software, network and computing resources) used to create, process, transmit, store or receive the aforementioned operational inputs and outputs;

(c)Identification of the operating environments (e.g. office, public access area, access-controlled room, etc.) and locations for all relevant assets;

(d)For each asset included in the scope, identification of the specific methods, processes and resources that will be used to manage, operate and maintain each asset throughout its life cycle, including:

—internal or contracted resources;

—contracted companies remotely managing the assets (i.e. provider of managed services).

ED Decision 2023/009/R

The organisation should, as part of the information security risk assessment, identify the interfaces it has with other parties such as service providers, supply chains and other third parties, based on the exchange of data and information and the assets used for that exchange, which could lead to a situation where information security risks, as a result of mutual exposure, may either:

—increase aviation safety risks faced by other parties; and/or

—increase aviation safety risks faced by the organisation.

ED Decision 2023/009/R

RISK INFORMATION SHARING

Interfacing organisations should share information with each other about the potential exposure to information security risks by following, for instance, the approach detailed in EUROCAE ED-201A, Appendix B — B.1, B.2 and B.3. The purpose of this exchange of information is to enable organisations to establish a matching mapping for the services identified under IS.I.OR.205(a), including all information and data flows, in order to:

(a)illustrate (e.g. through a functional diagram) the relationships of logical and physical paths connecting the different parts involved;

(b)clearly identify all assets (i.e. hardware, software, network and computing resources) that will be used in the exchange;

(c)identify all functions, activities and processes, including their respective information and data, which will be created, transmitted, processed, received and stored, and associate those with the responsible party which provides or performs those functions, activities and processes;

(d)determine for these paths, constituting the so-called functional chains, the role of the interfacing party as a producer, processor, dispatcher or consumer of the information or data involved;

(e)determine whether one interfacing party acts as an originator or receiver of a flow across such path.

TWO CATEGORIES OF INTERFACING ORGANISATIONS

There are two categories of interfacing organisations: those that are subject to Regulation (EU) 2023/203 or Regulation (EU) 2022/1645, and those that are not.

Where the organisation has interfaces with an organisation that is subject to Regulation (EU) 2023/203 or Regulation (EU) 2022/1645, each entity:

—is responsible for the identification of the interfaces that its own organisation has with other organisations, and which could result in the mutual exposure to information security risks. The entity may benefit from the sharing of risk information as this exchange allows for a more accurate assessment of those risks;

—remains accountable for the proper management of the information security risks within the scope of its own ISMS.

In all other cases, the organisation is accountable for the proper management of the information security risks that may arise from its exposure to the interfacing entity. Where these risks need to be treated, the organisation always has the option of implementing mitigating measures and controls within its own boundaries. In the specific case where the interfacing entity is a supplier, the organisation may decide to manage the risks through contractual arrangements and require the supplier to implement mitigating measures and controls within its own organisation.

ED Decision 2023/009/R

EXAMPLES OF AVIATION SERVICES

Examples of aviation services that may be considered when determining the ISMS scope and interfaces are provided in Appendix III.

ED Decision 2023/009/R

The organisation should use a risk management framework that includes a methodology for assigning risks with a risk level and establishing criteria for determining risk acceptance or further treatment.

The organisation should provide documented evidence of assessment of risks which have a potential impact on aviation safety including the level of risks. The organisation should associate each risk with the relevant elements and interfaces identified under IS.I.OR.205 (a) and (b), and document whether the risk is acceptable or requires further treatment.

The organisation should provide the assurance that the risk assessment process is carried out with the necessary rigour and discipline by documenting the process and its robustness. By doing so, the organisation should consider:

(a)reproducibility of the assessment’s results for similar inputs;

(b)repeatability of the assessment over time in a way that the results of the different prior assessments can be compared to determine the changes;

(c)the gathering of inputs that are relevant and valid, in particular:

(1)the information that allows the determination of the safety consequences;

(2)the information that allows the determination of the potential of occurrence of the threat scenario;

(d)iterative refinement over time allowing for more fine-grained threat scenarios as inputs to become available, with the aim of reducing uncertainty regarding threats, vulnerabilities, effectiveness of existing controls, and dependencies on external entities, in particular by:

(1)refining initial high-level threat scenarios with greater detail and specificity as more data is gathered;

(2)refining data on known vulnerabilities by continuously updating information about their exploitability and the associated consequences;

(3)reviewing the effectiveness of existing controls, and consider newly available controls;

(4)refining the understanding of the dependencies on external entities and their implications for the organisation’s risk profile.

ED Decision 2023/009/R

RISK ASSESSMENT

The risk classification levels for the potential of occurrence of the threat scenario and severity of the safety consequences listed below may be applied; however, this does not prevent the organisation from developing additional intermediate categories if it deems this necessary for risk assessments. The organisation should specify and document the applied, organisation-specific classification levels with an accurate qualitative or quantitative definition in terms of a range or interval of numerical values in order to enable a sufficiently calibrated, consistent estimation, evaluation and communication within the organisation or with the interfacing entities. The potential of occurrence of the threat scenario may be expressed as an interval of likelihoods including the duration of the observation. Supporting documentation and methods can be found in EUROCAE ED-203A, Chapter 3.6 which references the evaluation of the potential of occurrence of the threat scenario in the Security Risk Assessment of EUROCAE ED-202A.

Note 1: The phrase ‘duration of the observation’ refers to the time period during which a threat scenario is observed or monitored. It is essential in determining the likelihood of the threat scenario occurring, since the probability of occurrence may vary depending on the length of the observation period.

Note 2: EUROCAE ED-202A and EUROCAE ED-203A were originally developed for aircraft information security risk assessment, but the generic principles developed in those documents can be adapted to other frameworks when deemed useful by the organisation.

In order to facilitate the mutual comparability of risk assessment methodologies between interfacing organisations, the organisation may associate the assessment of the potential of occurrence of the threat scenario with one of the following categories:

—High potential of occurrence: the threat scenario is likely to occur. The attack related to the threat scenario is feasible and similar threat scenarios have occurred many times in the past.

—Medium potential of occurrence: the threat scenario is unlikely to occur. The attack related to the threat scenario is possible and a similar threat scenario may have occurred in the past.

—Low potential of occurrence: the threat scenario is very unlikely to occur. The materialisation of the threat scenario is theoretically possible; however, it is not known to have occurred.

The evaluation of the potential of occurrence of the threat scenario may be based on the following aspects:

Protection (as defined in EUROCAE ED-203A)

—Security measures and architecture that deny access to assets: the degree to which an asset is open to access from compromised systems

—Access to security measures: the degree to which a security measure prevents access/attack to itself from compromised systems

—Failure of mechanism: the degree to which the known implementation of a security measure will fail to prevent an attack

—Detection methods or procedures to recognise the attack and appropriately respond to reduce the potential of occurrence of the threat scenario

Exposure reduction (as defined in EUROCAE ED-203A)

—Conditions under which an external access connection can be used by a user or attacker

—Limits on the functionality of an external access connection

—Organisational policies that control the time-to-feasibility for developing attack tools specific to the product

—Vulnerability management including intelligence, scanning, treatment and retesting aimed to discover, detect and treat reported or detected vulnerabilities in a fast, risk-prioritised manner with high assurance in order to reduce the attack surface

—Reduction of the severity of a successful attack (i.e. through a redundant system that can maintain the continuity of service in case of a denial of service of a system critical for aviation safety)

Attack attempt (as defined in EUROCAE ED-203A)

—The capability of the attackers which is determined by the resources and expertise required for their attack

The capability of the attackers can be assessed through several ways, for instance:

—information from computer emergency response teams (CERTs) / computer security incident response teams (CSIRTs), information sharing and analysis centres (ISACs);

—analyses of past activities, techniques and procedures (TTPs) and success rate of attacks.

For the same reason the organisation may associate the outcome of the evaluation of the severity of the safety consequences with one of the following categories:

—High severity: those immediate or delayed scenarios that can cause or contribute to an unsafe condition where an unsafe condition means an occurrence associated with the operation of an aircraft in which:

—a person is fatally or seriously injured;

—the aircraft sustains damage or structural failure;

—the aircraft is either missing or completely inaccessible;

—Moderate severity: those immediate or delayed scenarios that can cause or contribute to safety incidents where an incident means any occurrence other than an accident, associated with the operation of an aircraft, which affects or could affect the safety of operations;

—Low severity: those immediate or delayed scenarios that can cause or contribute to negligible safety consequences.

Examples for high, moderate, and low severity can be found in EUROCAE ED-201A, Appendix B for products, ATM systems and airspace.

If the organisation cannot determine the safety effect, the assessment should identify assumptions from the risk-sharing information at interfaces with other organisations along the functional chain, leading up to the safety effect.

Some of those assumptions can be granted with the certification of products: where assets are subject to product certification from other aviation regulations addressing product information security, the organisation performing the risk assessment may consider the perimeter of the product certification as already covered. This should be acceptable under the condition that this certification is valid and that the instructions provided by the OEM to maintain the certification validity are implemented by the organisation.

Additional information can also be found in Regulation (EU) 2015/1018 on mandatory reporting of occurrences in civil aviation. Further examples of impact severity classifications for aviation domains can be found in EUROCAE ED-201A, Appendix B — Tables B-5, B-6 and B-7.

Risk acceptance criteria

Risk acceptance criteria are critical and should be developed, specified and documented. The criteria may define multiple thresholds, with a desired target risk level, but allowing also for the accountable manager or delegated person(s) to accept risks above this level under defined circumstances and conditions.

In order to facilitate the mutual comparability of risk assessments between interfacing entities, the organisation should classify the risks in the following categories:

—unacceptable risk;

—conditionally acceptable risk;

—acceptable risk.

For what concerns the conditional acceptance of risks, the criteria for acceptance should take into account how long a risk is expected to exist (temporary or short-term activity or exposure), or may include requirements for the commitment of future treatments to reduce the risk at an acceptable level within a defined time duration and show how the risk will be managed over time through the organisation’s risk governance processes.

Moreover, risks should be conditionally accepted only under the condition that the organisation demonstrates the presence of a comprehensive risk management structure that includes risk assessment, risk treatment and risk monitoring processes for operations. The risk management should consider the variability and consistency of threat likelihood, vulnerability, existing controls, external dependencies and safety impact. This is typically achieved when the organisation reaches a higher level of maturity that is representative of functionality and repeatability of information security risk management — see GM1 IS.I.OR.260(a).

The following Figure 1 depicts a risk acceptance matrix based on the aforementioned categories that can be used by interfacing organisations for mutual comparability.

Figure 1: Example of a risk acceptance matrix for comparison purposes

* The potential of occurrence of the threat scenario is reassessed in a timely manner (refer to IS.I.OR.205(d)) and monitored to ensure that it remains low and that if the risk materialises, it is early detected and dealt with.

A comprehensive risk management structure typically entails the following aspects and processes:

—a repeatable and reproduceable risk assessment. If the risk factors are considered fairly uncertain and within some wide value range or not sufficiently precise, further iterations of the risk assessment are performed involving additionally gathered or detailed information and a more in-depth assessment in order to reduce uncertainty and increase precision;

—a thorough review of those risks proposed to be conditionally acceptable that is performed by the accountable manager or delegated person(s) who may impose additional conditions for the risk retention, including risk treatment measure and the timeline for its implementation;

—strict monitoring of the key risk indicators that includes a defined, reliable detection of the potentially evolving risk materialisation;

—an incident response scheme is in place with reactive measures that are triggered by detection mechanisms in order to immediately contain the consequences, in particular, for risk scenarios involving a high severity level.

Note: As detailed in NIST SP-800 Rev.1, repeatability refers to the ability to repeat the assessment in the future, in a manner that is consistent with and hence comparable to prior assessments — enabling the organisation to identify trends. Therefore, a risk assessment process can be classified as ‘repeatable’ when under similar conditions an entity or a person delivers consistent results.

As detailed in NIST SP-800 Rev.1, reproducibility refers to the ability of different experts to produce the same results from the same data. Therefore, a risk assessment process can be classified as ‘reproducible’ when another entity or person, given the same inputs, assumptions, information security context and threat environment can replicate the same steps and reach the same conclusions.

Threat scenario identification

A threat scenario is one of the possible ways a threat could materialise. Typically, a threat scenario describes a potential attack targeting one or more vulnerabilities of assets, as well as processes.

The purpose of the threat scenario identification under this Regulation is to develop a list of scenarios that may lead to an information security threat having an impact on aviation safety.

A threat scenario, in general, is characterised by the following:

—a threat source of the information security attack;

—an attack vector and a path through the organisation up to the asset;

—the information security controls that would mitigate the attack;

—the consequence of the attack including the affected safety aspects.

Threat scenario identification guidance can be found in EUROCAE ED-202A, Chapter 3.4. This is not the only source where guidance can be found, and the organisation may refer to different guidance more appropriate for their application.

Additional methods to identify relevant threat scenarios

When conducting this analysis, both information security and safety aspects should be coordinated throughout the process to ensure mutual understanding of the threat preventive measures and mitigating measures being applied. In the following Figure 2 the interactions between information security and aviation safety are depicted through a ‘bow-tie’ diagram that highlights the links between risk controls and the underlying management system.

Figure 2: Interactions between information security and aviation safety risk management areas

Note: A preventive barrier or measure is a proactive action or control implemented to reduce the likelihood of a risk, hazard, or threat materialising, while a mitigating measure is an action or control designed to reduce the severity or impact of an undesired event, would it occur.

Examples of threat scenarios

Threat catalogues may provide guidance and elements for the elaboration of threat scenarios that are relevant for the organisation. References can be found in ARINC 811 – Att. 3 – Tables 3-7 and 3-8 for the threat catalogues examples and other threat catalogue examples as they are provided by EU institutions — for example, the ENISA threat taxonomy. However, this is not an exhaustive list of examples, and the identification of threat scenarios should therefore not be limited to those examples only. In addition, other relevant resources containing information on information security threats and the information security threat landscape should be consulted to support the risk assessment process with relevant inputs.

A set of examples of threat scenarios can be found in Appendix I.

ED Decision 2023/009/R

The organisation should take into account the following criteria when establishing compliance with the objectives contained in point IS.I.OR.205(d):

(a)The risk assessment performed under points IS.I.OR.205 (a), (b) and (c) should be reviewed at regular intervals to identify and account for relevant changes. The periodicity at which potential changes have to be evaluated should be determined by the organisation performing the assessment considering the criticality of the assets within the scope of the risk assessment, levels of residual risk of the assets within the scope of the risk assessment and any contractual or regulatory requirements. A higher criticality or level of risk will require more frequent review.

(b)The periodicity of risk assessment reviews should be documented by the organisation and include the justification, date of approval and information about the risk owner.

ED Decision 2023/009/R

The criteria to consider for the frequency of the risk assessment review may be the risk level as well as the criticality and complexity of the assets concerned. The objective of a risk assessment review is to trigger the revaluation of risks, their likelihood and impact in case of relevant changes. One possible way is to have a tiered approach to risk assessment, with a higher-level risk assessment being used for the identification of changes. The higher-level risk assessment could allow the identification of the detailed risks that should be reviewed in a next step. Risk assessments should be subject to regular reviews to:

(a)allow for continuous improvement of the quality of risk assessment;

(b)ensure efficiency and effectiveness of risk controls and mitigating measures in both their design and operation;

(c)review plans and actions for risk treatment;

(d)identify any organisational change which may require a review of the priorities as well as of the treatment of risks;

(e)maintain an overview of the complete risk picture; and

(f)identify any emerging risks.

Risk assessment reviews should involve the risk owners, project teams and other stakeholders as applicable. Evidence of risk assessment review should be documented and should include:

—evidence of approval of the review by the designated risk owner; and

—the rationale behind or basis for the risk owner’s approval of the review.

Such evidence may comprise, but is not limited to:

—reports which constitute a form of documentation to track information security risks potentially impacting an organisation;

—the documentation of the information security risk assessment;

—exerts from a business or security risk register.

The periodicity of risk assessment reviews should also be documented by the organisation in information security manuals, processes or procedures and should align with wider change management activities and management reviews of information security. Further guidance on criteria and frequency of risk assessment review can be found in EUROCAE ED-201A, Chapter 4, as well as in EUROCAE ED-205A, Chapter 3.2 (for ATMS/ANS).

ED Decision 2023/009/R

The following are examples of changes that should be identified during the risk assessment review as they may trigger an update of the risk assessments:

(a)there is a change in the elements subject to information security risks as identified in IS.I.OR.205(a); a change in the elements will include:

—additions to, or removals from, the scope of the risk assessment of individual elements;

—changes to design or configuration of elements within the scope of the risk assessment that have the potential to alter the risk assessment outcomes; or

—changes to values, which would potentially trigger changes to impact levels, of elements within the scope of the risk assessment;

(b)there is a change in the interfaces between the organisation and other organisations with which the organisation shares information security risks or relies upon to mitigate information security risks (e.g. supply chains, service providers, cloud providers and customers), as identified in IS.I.OR.205(b), or between the system within the scope of the risk assessment and any other interconnected systems, or in the risks notified to the organisation by other organisations, as identified in IS.I.OR.205(b), or owners or managers of the other systems including:

—establishment of new interfaces;

—removal of existing interfaces;

—changes to existing interfaces that would have the potential to alter the risk assessment outcomes.

Note: Some organisational or system interconnections may be with organisations that are not within the scope of this Regulation as defined in Article 2 and therefore are not subject to the requirements of Part-IS. Where this is the case, these organisations should be informed of their responsibility to report such changes as listed above through contractual arrangements and reporting requirements between the affected organisations on a case-by-case basis and where applicable;

(c)there is a change in the information or knowledge used for the identification, analysis and classification of risks including:

—changes to threats and their values or addition of new threats that have not previously been assessed;

—changes to vulnerabilities or addition of new vulnerabilities that have not previously been assessed;

—changes in impacts or consequences of assessed threats or vulnerabilities;

—changes in aggregation of risks that may result in unacceptable levels of risks;

—changes or improvements in the risk management process, risk assessment approach and related activities;

—changes or improvements in the treatments of risks;

—changes in the criteria used to determine acceptance and treatments of risks;

(d)there are lessons learned from the analysis of information security incidents including:

—understanding why and how incidents have occurred; and

—reviewing all types of incidents including those due to external factors, technical reasons, human errors (inadvertent behaviour). For human intentional acts, a distinction can be made between malign and benign actions.

ED Decision 2023/009/R

SAFETY SUPPORT ASSESSMENT

Non-ATS providers should conduct a safety support assessment as it is described in Regulation
(EU) 2017/373 to assess the information security risk on their assets in regard to the service specification, e.g. integrity and availability, and to identify the residual risk.

The non-ATS provider should share with the ATS provider, in an appropriate form, information on the residual risk and the impact on the services it provides to that ATS provider.

The residual risk should be used to assess the potential impact on services and products that a non-ATS provider offers to an ATS provider.

The ATS provider can use this as an input for its security risk assessment and, more importantly, to evaluate the potential impacts of these residual risks on safety.

ED Decision 2023/009/R

SAFETY SUPPORT ASSESSMENT

Table 1 below shows the non-ATS providers which shall comply with Subpart C of Annex III to Regulation (EU) 2017/373. These are the organisations having to conduct the safety support assessment in order to provide the required information to ATS providers.

The information on the impact on products and services could be shared between non-ATS providers and ATS providers through agreed means, e.g. service level agreement, external agreement (in line with EUROCAE ED-201A), etc.

Shared information should enable ATS providers to perform an accurate assessment of the residual risk for their services. For instance, if the non-ATS providers identified a risk which could affect the availability of data provided to an ATS provider, the impact on the availability should be described in a way that allows the ATS provider to assess whether the resulting latency or delay in data transmissions could have a safety impact. This is relevant because only the ATS provider through its assessment can either accept or decline a residual risk.

Table 1: Non-ATS providers which shall comply with Subpart C of Annex III to Regulation (EU) 2017/373

Regulation (EU) 2023/203

(a)The organisation shall develop measures to address unacceptable risks identified in accordance with point IS.I.OR.205, implement them in a timely manner and check their continued effectiveness. Those measures shall enable the organisation to:

(1)control the circumstances that contribute to the effective occurrence of the threat scenario;

(2)reduce the consequences on aviation safety associated with the materialisation of the threat scenario;

(3)avoid the risks.

Those measures shall not introduce any new potential unacceptable risks to aviation safety.

(b)The person referred to in point IS.I.OR.240(a) and (b) and other affected personnel of the organisation shall be informed of the outcome of the risk assessment carried out in accordance with point IS.I.OR.205, the corresponding threat scenarios and the measures to be implemented.

The organisation shall also inform organisations with which it has an interface in accordance with point IS.I.OR.205(b) of any risk shared between both organisations.

ED Decision 2025/014/R

Unacceptable risks identified in accordance with point IS.I.OR.205 require a risk treatment process that may lead to the introduction of information security measures, often referred to as information security controls.

For each identified risk, the organisation defines the specific risk treatment measures, methods or resources that will be used over the life cycle of each asset to:

—manage risk reduction;

—monitor and maintain each asset;

—update and fulfil activities for configuration management;

—manage supply chain;

—manage contracted services or service provider.

The review of risk treatment measures includes life cycle considerations which are introduced by equipment, procedures and personnel.

A risk treatment plan as an outcome of the risk management process includes a prioritisation of risks, the corresponding information on the objectives and means for risk treatment to reach an acceptable level of risk, as well as agreed timelines specifying when responsible personnel should have implemented the risk treatment measures. The timelines for the implementation of a risk treatment measure are subject to agreement by the personnel responsible for the implementation and are communicated to and accepted by the accountable manager of the organisation or delegated person(s).

Any subsequent implementation delay, together with its cause, reason, rationale or necessity, is documented in the risk treatment plan, for risks that may lead to an unsafe condition. The delay is also subject to the acceptance by the accountable manager of the organisation or delegated person(s). This person may condition such acceptance on the implementation or availability of compensating controls or reactive measures to monitor, early detect and timely respond to the materialisation of the risk in treatment. In order to timely respond, the incident response team may be informed to trigger their preparedness.

The risk treatment plan can act as a means of communication with the competent authority to demonstrate effective treatment of unacceptable risks. Similarly, this plan can be utilised to communicate to interfacing organisations how shared risks are controlled.

In accordance with IS.I.OR.205(d), a regular or conditional review of the risk assessment is necessary, and this includes the review of the risk treatment measures developed under IS.I.OR.210(a) to identify whether they are still effective or they require adaptations.

In addition, the organisation should also consider the potential impact on the effectiveness of risk treatment measures where a shared information security risk may arise as a result of the interaction between interfacing entities (see IS.I.OR.235 and related AMC).

ED Decision 2023/009/R

(a)The risk treatment process should reach at least one of the objectives listed under IS.I.OR.210(a).

(b)When establishing compliance with the objectives under points IS.I.OR.210(a)(1) and IS.I.OR.210(a)(2), the organisation should take into account that:

(1)the measures developed under these points should be implemented according to a risk treatment plan with defined, risk-based priorities, objectives and agreed timelines and owners;

(2)life cycle considerations should be identified and associated to ensure continuous effectiveness of the information security measures including exchange of data with other entities;

(3)it should review and update the risk assessment, according to IS.I.OR.205(d), to evaluate whether the measures developed under these points introduce new unacceptable risks or modify existing risks in a way that they become unacceptable.

(c)Risk treatment should be documented and recorded, for example, in a risk registry, even if the risk has been avoided.

Regulation (EU) 2023/203

(a)The organisation shall establish an internal reporting scheme to enable the collection and evaluation of information security events, including those to be reported pursuant to point IS.I.OR.230.

(b)That scheme and the process referred to in point IS.I.OR.220 shall enable the organisation to:

(1)identify which of the events reported pursuant to point (a) are considered information security incidents or vulnerabilities with a potential impact on aviation safety;

(2)identify the causes of, and contributing factors to, the information security incidents and vulnerabilities identified in accordance with point (1), and address them as part of the information security risk management process in accordance with points IS.I.OR.205 and IS.I.OR.220;

(3)ensure an evaluation of all known, relevant information relating to the information security incidents and vulnerabilities identified in accordance with point (1);

(4)ensure the implementation of a method to distribute internally the information as necessary.

(c)Any contracted organisation which may expose the organisation to information security risks with a potential impact on aviation safety shall be required to report information security events to the organisation. Those reports shall be submitted using the procedures established in the specific contractual arrangements and shall be evaluated in accordance with point (b).

(d)The organisation shall cooperate on investigations with any other organisation that has a significant contribution to the information security of its own activities.

(e)The organisation may integrate that reporting scheme with other reporting schemes it has already implemented.

ED Decision 2023/009/R

Organisations should use as a source the incidents detected during activities performed to show compliance with IS.I.OR.220(a). Organisations should have a mechanism to collect notifications of events by personnel and by sources outside the company including suppliers, partners, customers, open-source software, and information security researchers. The mechanism for collecting information by personnel and external sources should be easily accessible and communicated.

The organisation should collect all events gathered through the detection means for internal analysis. Each event should be analysed to identify whether it is reportable and if so, what potential or actual impact on aviation safety has occurred. Information security events should be considered in combination with other events to provide correlation to identify incidents or vulnerabilities with a potential impact on aviation safety.

The organisation should consider the outcome of the risk assessment and the exploitability of new vulnerabilities discovered during the detection activities conducted according to the measures required in IS.I.OR.220(a).

The organisation should identify all internal stakeholders that require notification of a specific incident or vulnerability and ensure that these stakeholders receive all necessary information on the incident or vulnerability in order to act effectively and in a timely manner to support the required detection and response periods.

ED Decision 2023/009/R

RELATIONSHIP BETWEEN INTERNAL AND EXTERNAL REPORTING

Organisations should collect and report internally incidents and vulnerabilities aiming at covering all items within the scope of this Regulation. Both internal and external reporting are necessary for a complete and effective reporting system. Internal reports should be assessed in a timely manner and where the potential impact on safety is an unsafe condition, organisations should initiate reporting of these internal reports according to IS.I.OR.230.

ED Decision 2023/009/R

ORGANISATION OF COLLECTION AND EVALUATION OF INFORMATION SECURITY EVENTS

It is a common practice in large organisations to centralise information security operations in a security operations centre (SOC) and make use of an information security information and event management (SIEM) system. A SIEM system collects all events from sources such as log files in a common database and allows the analysts and responders in a joint SOC to review and act on these events. Organisations may choose to use a SOC for events relevant to Part-IS in isolation or in combination with events not subject to Part-IS but of interest to the organisation, such as events relating to business interests. Events can be automatically aggregated, correlated and analysed in order to detect abnormal behaviour leading to information security incidents.

Organisations that do not have a SOC capability and do not use a SIEM system need to consider how to establish processes to meet the required collection and evaluation capabilities as well as detection and response times.

ED Decision 2023/009/R

RELEVANT INFORMATION FOR INCIDENTS AND VULNERABILITIES

Understanding the causes of, and contributing factors to, information security incidents and vulnerabilities relevant to Part-IS allows lessons learned to be gained and to introduce corrections to processes and asset design. However, understanding causes and contributing factors may not always be possible or may not aid in continuous improvement of aviation safety. Where vulnerabilities arise from assets developed solely or primarily for aviation, it is expected to be possible to perform the necessary investigation on the root causes. These root causes will inform the affected organisation(s) to improve processes and asset design to remediate vulnerability and to ensure that such vulnerabilities are not introduced in other assets. Understanding the root causes of vulnerabilities also allows the aviation community to learn and thus avoid similar vulnerabilities in the future.

ED Decision 2023/009/R

If contracted organisations are also subject to this Regulation, the exchange of information and reporting should be covered under the management of shared risks and through the establishment of an external agreement between the organisations. Guidance regarding the development of external agreements can be found in EUROCAE ED-201A, Chapter 4.4 External agreements.

More in general, and in all other cases, any service contract should include standard clauses concerning obligations for the contracted organisation to:

—report within an agreed time information security incidents that may have an impact on the contracting organisation. Incidents and vulnerabilities which could lead to unsafe conditions should be reported as soon as possible and in such a manner that the external reporting obligation under IS.I.OR.230 can be ensured;

—designate a point of contact for the incident management and possible crisis management.

In some cases contracted organisations, such as service providers with distributed resources, may not be able to offer any ad hoc reporting. In these cases the internal reporting requirement may be fulfilled through other means that satisfy the objective of this provision. For instance, the contracted organisations may provide an up-to-date list of vulnerabilities affecting the systems within the scope of the contracted services. This list should be monitored by the contracting organisation as part of the internal reporting of information security events.

ED Decision 2023/009/R

The cooperation under point IS.I.OR.215(d) can be substantiated by sharing elements from incident records that can support other organisations’ information security activities. In case the organisations are bound by contractual obligations, this contract may also include commitment to cooperate. Organisations may consider developing formal agreements (e.g. a memorandum of understanding) outlining roles and responsibilities for information security collaboration such as governance meetings, joint development activities, and real-time indicators of compromise (IoC) sharing.

Moreover, commitment to cooperate may also be achieved through the active participation of the organisation in information security sharing initiatives; for instance, ISAC(s). Additionally, for their own awareness, organisations may also subscribe to receive vulnerability and threat alerts, like those distributed by CERTs.

Regulation (EU) 2023/203

(a)Based on the outcome of the risk assessment carried out in accordance with point IS.I.OR.205 and the outcome of the risk treatment performed in accordance with point IS.I.OR.210, the organisation shall implement measures to detect incidents and vulnerabilities that indicate the potential materialisation of unacceptable risks and which may have a potential impact on aviation safety. Those detection measures shall enable the organisation to:

(1)identify deviations from predetermined functional performance baselines;

(2)trigger warnings to activate proper response measures, in case of any deviation.

(b)The organisation shall implement measures to respond to any event conditions identified in accordance with point (a) that may develop or have developed into an information security incident. Those response measures shall enable the organisation to:

(1)initiate the reaction to the warnings referred to in point (a)(2) by activating predefined resources and course of actions;

(2)contain the spread of an attack and avoid the full materialisation of a threat scenario;

(3)control the failure mode of the affected elements defined in point IS.I.OR.205(a).

(c)The organisation shall implement measures aimed at recovering from information security incidents, including emergency measures, if needed. Those recovery measures shall enable the organisation to:

(1)remove the condition that caused the incident, or constrain it to a tolerable level;

(2)reach a safe state of the affected elements defined in point IS.I.OR.205(a) within a recovery time previously defined by the organisation.

ED Decision 2023/009/R

Without prejudice to the definition of ‘information security event’ in Article 3 of Regulation (EU) 2023/203, those events that indicate the potential materialisation of unacceptable risks include both occurrences (i.e. anything that causes harm or have the potential to cause harm) and discovery of vulnerabilities. In fact, information security risks are associated with the potential that threats will exploit vulnerabilities, therefore the discovery of an exploitable vulnerability is an information security event.

In light of this, in the context of this Regulation:

—detection activities required under IS.I.OR.220(a) include vulnerability discovery;

—response activities under IS.I.OR.220(b) include vulnerability management.

ED Decision 2023/009/R

DETECTION

When complying with the requirement in IS.I.OR.220(a), the organisation should define and implement a strategy to detect information security incidents which may have a potential impact on safety.

This should be done in a way to ensure that at least the detection strategy is able to cover all known information security threats to their assets that may materialise in a safety hazard having unacceptable consequences.

DETECTION STRATEGY

In order to determine the scope of the event detection, the organisation should:

(a)identify a list of threat scenarios from the risks identified under IS.I.OR.205;

(b)identify, as a minimum, those assets that, if compromised, contribute to the scenario(s) that may materialise in an unsafe condition. For this identification of the assets, the measures introduced under IS.I.OR.210 should also be considered.

Note: The contribution of an asset to the threat scenario and the materialisation of an unsafe condition should be assessed by considering also the whole functional chain. In some cases, the asset may be at the end of a functional chain and if it is compromised, the effect on safety is direct and may be immediate; conversely, if the asset is far from the end of a functional chain and it is compromised, the effect should propagate and may be delayed.

ED Decision 2023/009/R

DETECTION STRATEGY

When developing the detection strategy, for those items within the scope of event detection, the organisation should define the conditions that trigger a process that, for example, would require personnel intervention and further analysis. These conditions on the items may be defined using elements from the:

(a)expected functional baseline: engage in the identification of deviations from the expected functional operation of the system (excluding information security functions/controls);

(b)expected information security baseline: engage in the identification of deviations from the expected information security operation of information security controls.

These conditions should consider both abnormal behaviour and substantial deviations from the baselines and relevant correlation of multiple independent events.

Further guidance on the objectives for the establishment of a detection strategy can be found in EUROCAE ED-206, Chapter 4.

ED Decision 2023/009/R

(a)INCIDENTS

The organisation should take into account the following aspects when establishing compliance with the objectives contained in point IS.I.OR.220(b) relative to incidents:

(1)Preparation of procedures and delineation of roles and responsibilities to respond in a timely, effective and orderly manner to any relevant information security incidents.

(2)The response procedure should:

(i)consider the warnings, unitary or combined, from IS.I.OR.220(a)(2), and in collaboration with appropriate personnel assess their potential impact on aviationsafety;

(ii)establish, in accordance with IS.I.OR.220(b)(2), a containment strategy for each asset category considering the potential worst-case effect and the mission constraints, and provide criteria indicating when the incident is contained;

(iii)define, in accordance with IS.I.OR.220(b)(3), the acceptable impact on safety and information security of each asset within the scope when they fail due to the materialisation of a threat scenario.

(3)The response time should be commensurate with the impact level assessed in (2)(iii).

(4)The response measures implemented under IS.I.OR.220(b) should be based on the response procedure referred to in the point (a)(2) and they should, in particular, consider the following:

(i)the maximum acceptable safety level degradation of the assets within the scope of incident;

(ii)the actions, such as resistance, containment, deception and control of the possible ways systems can fail, which will contribute to achieving the acceptable safety level degradation identified in point (i) while minimising the impact on operations;

(iii)the resources required to implement the actions specified in point (ii).

(5)The response time and the measures should take into account the potential immediate negative impact on safety if the measure is taken before it has been fully verified that it would not cause additional immediate safety impacts.

(b)VULNERABILITIES

The organisation should take into account the following aspects when establishing compliance with the objectives contained in point IS.I.OR.220(b) relative to vulnerabilities:

(1)Establishment of a vulnerability management strategy defining procedures, roles and responsibilities to respond in a timely, effective and orderly manner to any detected relevant vulnerabilities.

(2)The response measures implemented under point IS.I.OR.220(b) should be based on the maximum acceptable risk of the items within the scope of the vulnerability, considering the worst-case scenario of the vulnerability being exploited.

(3)The response time should be commensurate with the pre-triage done on the warnings and the assessment of the potential impact of the vulnerability, if it is exploited.

ED Decision 2023/009/R

An attack is considered contained (i.e. it is not spreading any further) when the boundaries of the incident have been identified and the threat does not propagate beyond these boundaries. Further guidance can be found in EUROCAE ED-206, Chapter 5.

The term ‘warning’ as used in IS.I.OR.220 should be understood as an alert that would require timely awareness and response from the information security events management team.

In the context of information security response, ‘deception’ refers to a range of techniques that aim to mislead potential attackers or malicious users, thereby protecting the system and its data. Deception techniques, such as honeypots or breadcrumb trails, are designed to confuse, slow down or divert attackers, increasing their cost and risk while providing defenders with valuable time and intelligence.

Guidance regarding the vulnerability management strategy can be found in EUROCAE ED-206, Chapter 3.4 — Vulnerability management considerations. This is not the only source where guidance can be found, and the organisation may refer to different guidance more appropriate for their application.

ED Decision 2023/009/R

When complying with the requirement in IS.I.OR.220(c), the organisation should develop an incident recovery procedure including at least the following:

(a)a list of those assets that enable safe operations, as well as the dependencies among them, constituting the scope of the recovery;

(b)a description of the process with the necessary priority actions to be executed for a return to a safe and secure state for the assets within the scope of the recovery;

(c)the resources required to execute the actions defined in point (b) to ensure that these resources are readily available after an incident has occurred;

(d)the objectives for recovery time that should be set in relation to the safety criticality of the assets within the scope of the recovery.

ED Decision 2023/009/R

RECOVERY OBJECTIVES AND TIMING

Point IS.I.OR.220(b) addresses event conditions which may develop or have developed into information security incidents, that may have a potential impact on aviation safety, and require response and recovery measures to be in place to ensure that operational safety remains above a minimum acceptable level.

The level of operations and safety may be interrelated, so in some cases when the level of operations is compromised by an information security incident and drops, the level of safety does the same. This is, for instance, the case of air traffic control; if air traffic services are reduced or become unreliable, the safety of flights is reduced too.

However, in other cases the relation between the level of operations and safety may be the inverse, or they may be decoupled, so when an incident occurs and the level of operations drops, the level of safety is preserved. One example is the compromise of the software loading process on board the aircraft. In this case, a detected incident followed by the decision to interrupt the software loading operations would preserve the existing level of safety.

The following Figure 1 depicts a conceptual framework that may be considered for the definition of the response and recovery objectives, including the recovery time. It represents, in the worst-case scenario, how the expected level of operational safety (safety level) for a process or an activity may vary over time when an information security incident occurs. In this scenario, the safety level is first reduced by the incident and then it degrades as long as the time passes. The figure also shows the expected effect that mitigating measures and controls should have, respectively: in containing the operational safety drop as soon as an incident occurs, and in improving the recovery, i.e. the return to the expected safety level.

Figure 1: Conceptual framework for the definition of the response and recovery objectives

As mentioned, there might be different relations between the level of operations and safety that would lead to a different representation of the above figure. In certain cases, an incident may have a delayed effect on the safety level (e.g. a compromised development environment) as depicted in Figure 2, or it may have no impact if properly controlled, as in the case of the compromised software loading process mentioned before, which is depicted in Figure 3.

Moreover, it should be noticed that there might be different ways the same incident can be dealt with, since there are several factors that may affect safety.

In practical terms, the objectives for recovery time referred to in AMC1 IS.I.OR.220(c) may be expressed as a list of resources and services to be restored by order of priority, within the scope of the recovery. Guidance about objectives for recovery time can be found in EUROCAE ED-206, Chapter 7.3.5.

ED Decision 2023/009/R

A recovery procedure or recovery plan should describe incident recovery actions and the internal or external resources that are involved (e.g. staff, IT, buildings, providers). Guidance about incident recovery plan can be found in EUROCAE ED-206, Chapter 7 – Recover.

The resources required to apply the recovery measures should be available in order to implement the recovery actions in a timely manner after an incident has occurred. Those resources may be internally available or provided by contracted organisations as provided for in IS.I.OR.235. The contracting of recovery activities should be established before an incident occurs (proactive), and the contract should include provisions for the contracted party to react in a timely manner.

The return to a safe and secure state may initially require emergency measures, which are actions that are initiated based on the best information available at the time, before complete understanding of the situation is achieved and these measures can potentially degrade the level of service or functionalities. The return to a safe and secure state should be evaluated against the initial risk assessment and may only temporarily differ from the normal operational conditions. However, any increase of the residual risk and the duration of this risk increase, i.e. due to the implementation of emergency measures, should be documented and accepted at the right level of accountability.

The recovery activities mentioned here may also be the outcome of the response to incidents for which the organisation has received information that requires the implementation of adequate measures in order to react to information security incidents or vulnerabilities with a potential impact on aviation safety.

In such context the organisation may not have a process or a recovery plan covering the specific occurrence. Therefore, the definition from the organisation of a specific recovery plan and its approval by the competent authority is usually required.

Regulation (EU) 2023/203

(a)After receipt of the notification of findings submitted by the competent authority, the organisation shall:

(1)identify the root cause or causes of, and contributing factors to, the non-compliance;

(2)define a corrective action plan;

(3)demonstrate the correction of the non-compliance to the satisfaction of the competent authority.

(b)The actions referred to in point (a) shall be carried out within the period agreed with the competent authority.

ED Decision 2023/009/R

The compliance with IS.I.OR.225 should be managed as required for each organisation in the corresponding implementing regulation for the domain as identified in point Article 2(1) of Regulation (EU) 2023/203 concerning the response to findings notified by the competent authority. The domain regulation may require the organisation to respond to the findings in accordance with their categorisation.

ED Decision 2023/009/R

The requirement for the categorisation of findings and the period within which the actions in IS.I.OR.225(a) should be performed can be found in the corresponding implementing regulation for the domain, under the authority requirements. For the opening of findings related to this Regulation, the competent authority will follow the above-mentioned requirement.

Regulation (EU) 2023/203

(a)The organisation shall implement an information security reporting system that complies with the requirements laid down in Regulation (EU) No 376/2014 and its delegated and implementing acts if that Regulation is applicable to the organisation.

(b)Without prejudice to the obligations of Regulation (EU) 376/2014, the organisation shall ensure that any information security incident or vulnerability, which may represent a significant risk to aviation safety, is reported to their competent authority. Furthermore:

(1)Where such an incident or vulnerability affects an aircraft or associated system or component, the organisation shall also report it to the design approval holder;

(2)Where such an incident or vulnerability affects a system or constituent used by the organisation, the organisation shall report it to the organisation responsible for the design of the system or constituent.

(c)The organisation shall report the conditions referred to in point (b) as follows:

(1)a notification shall be submitted to the competent authority and, if applicable, to the design approval holder or to the organisation responsible for the design of the system or constituent, as soon as the condition has been known to the organisation;

(2)a report shall be submitted to the competent authority and, if applicable, to the design approval holder or to the organisation responsible for the design of the system or constituent, as soon as possible, but not exceeding 72 hours from the time the condition has been known to the organisation, unless exceptional circumstances prevent this.

The report shall be made in the form defined by the competent authority and shall contain all relevant information about the condition known to the organisation;

(3)a follow-up report shall be submitted to the competent authority and, if applicable, to the design approval holder or to the organisation responsible for the design of the system or constituent, providing details of the actions the organisation has taken or intends to take to recover from the incident and the actions it intends to take to prevent similar information security incidents in the future.

The follow-up report shall be submitted as soon as those actions have been identified, and shall be produced in the form defined by the competent authority.

ED Decision 2023/009/R

Organisations are required to report occurrences to their competent authority.

EXAMPLES

Design organisations approved by EASA: EASA is the competent authority.

Air operators certified by the competent authority of a Member State: the competent authority of the Member State is the competent authority.

SPECIAL CASES

In a situation where an organisation has two air operator certificates (AOCs) under two different EU Member States (State A and B), the occurrences involving aircraft operating under the State A AOC have to be reported to the State A competent authority; instead, the occurrences involving aircraft operating under the State B AOC have to be reported to the State B competent authority.

For organisations holding multiple approvals, the reporting will be done to the competent authority of the approved part of the organisation where the incident has occurred, or the vulnerability has been discovered. In case the incident/vulnerability affects multiple approvals, the reporting will be done to all the competent authorities.

For organisations holding an approval but operating outside the EU (e.g. Part-145), EASA is the competent authority and they have to report to the Agency.

Dual-use aircraft — a vulnerability may need to be reported through both the military and civil reporting systems if it affects a dual-use function/system. Information reported through the civil reporting system should be sanitised (i.e. all sensitive information should be properly removed).

ED Decision 2023/009/R

In order to comply with the provisions under IS.I.OR.230 (a) and (b), the organisation should report:

(a)any occurrence covered by Regulation (EU) No 376/2014 that originated from intentional unauthorised electronic interactions;

(b)information security incidents having a potential significant risk to aviation safety not covered under Regulation (EU) No 376/2014;

(c)vulnerabilities that pose a significant risk to aviation safety and are not yet adequately mitigated in accordance with an approved vulnerability management strategy (see AMC1 IS.I.OR.220(b)).

From the aforementioned reports, it is the responsibility of the competent authorities under Part-IS to ensure compliance with Article 7 of this Regulation and to submit any relevant information that needs to be shared with the information security competent authorities designated under Article 8 of Directive (EU) 2016/1148.

ED Decision 2023/009/R

RELATION BETWEEN IS.I.OR.230(b) AND REGULATION (EU) No 376/2014

Regulation (EU) No 376/2014 of the European Parliament and of the Council lays down requirements on the reporting, analysis and follow-up of occurrences in civil aviation. Compliance with point IS.I.OR.230(b) does not exempt organisations from compliance with Regulation (EU) No 376/2014.

For each category of reporter, Regulation (EU) 2015/1018 defines the nature of items to be mandatorily reported. Regulation (EU) No 376/2014 also considers voluntary reporting of other items that are perceived by the reporter as a threat to aviation safety.

Furthermore, compliance with Regulation (EU) No 376/2014 does not exempt organisations from compliance with point IS.I.OR.230(b). However, this should not give rise to two parallel reporting systems, and point IS.I.OR.230(b) and Regulation (EU) No 376/2014 should be seen as complementary in that respect.

In practice, this means that reporting obligations under point IS.I.OR.230(b) on the one hand and reporting obligations under Regulation (EU) No 376/2014 on the other hand are compatible. These reporting obligations may be discharged using one reporting channel. In addition, any natural or legal person that has more than one role subject to the obligation to report may discharge all those obligations through a single report. Organisations are encouraged to properly describe this in their organisation manual, to address cases in which the responsibilities are discharged on behalf of the organisation.

FOLLOW-UP ANALYSIS

When the analysis of an occurrence reported under Regulation (EU) No 376/2014 later identifies that the root cause of, or the contributing factor to, the occurrence was an intentional unauthorised electronic interaction, the organisation should update its notification to the competent authority.

SIGNIFICANT RISK TO AVIATION SAFETY

In line with the definition of occurrence under Article 2(7) of Regulation (EU) No 376/2014, any information security incident or vulnerability, which may represent a significant risk to aviation safety, should be considered a reportable occurrence. Significant risk to aviation means unsafe condition, i.e. one that can result in an accident or a serious incident (as defined in ICAO Annex 13).

Note: When assessing the possibility that the effects of an information security incident could lead to an unsafe condition, the organisation should consider the combination of effects if the incident involves multiple systems; indeed, some assumptions about system independence that may be valid for fortuitous occurrences may be violated by deliberate acts.

RELATION BETWEEN IS.I.OR.230(b)(1) AND OTHER REPORTING REQUIREMENTS OF INFORMATION SECURITY OCCURRENCES RELATED TO AVIATION PRODUCTS OR PARTS

For organisations subject to reporting requirements of information security occurrences related to aviation products or parts, compliance with the specific provisions in the implementing regulation for their domain is considered sufficient to achieve compliance with the requirement in point IS.I.OR.230(b)(1). For example, for organisations subject to Regulation (EU) No 748/2012, the reporting can be done in accordance with point 21.A.3A of Annex I (Part 21) to that Regulation.

ED Decision 2023/009/R

Within the overall limit of 72 hours the degree of urgency for submission of a report should be determined by the level of the safety impact judged to have resulted from the information security incident or discovered vulnerability. Where an occurrence is judged by the person identifying the possible unsafe condition to have resulted in an immediate and particularly significant hazard, the competent authority expects to be advised immediately and by the fastest possible means (telephone, fax, email, telex, etc.) of whatever details are available at that time.

ED Decision 2023/009/R

Guidance regarding the reporting of information security incidents and vulnerabilities can be found in EUROCAE ED-206, Chapter 6.4.2.2 — Reporting timeline and Chapter 6.4.5 — Reporting information content. This is not the only source where guidance can be found, and the organisation may refer to different guidance more appropriate for their application.

Note: The person reporting an occurrence under Regulation (EU) No 376/2014 may not have the capability to determine the nature of the occurrence. This is particularly true for information security and the result can come from forensic analysis that determines the information security nature of the occurrence. The evaluation will be done as part of the initial internal reporting process (see IS.I.OR.215 and related AMC). The evaluation of the occurrence can demonstrate the possibility that it materialises into an unsafe condition taking into account the likelihood of realisation.

Regulation (EU) 2023/203

(a)The organisation shall ensure that when contracting any part of the activities referred to in point IS.I.OR.200 to other organisations, the contracted activities comply with the requirements of this Regulation and the contracted organisation works under its oversight. The organisation shall ensure that the risks associated with the contracted activities are appropriately managed.

(b)The organisation shall ensure that the competent authority can have access upon request to the contracted organisation to determine continued compliance with the applicable requirements laid down in this Regulation.

ED Decision 2023/009/R

Organisations may decide to outsource certain activities to suppliers, both for their own operational needs and for the purpose of complying with this Regulation (information security management activities). Activities contracted for operational needs may fall within the scope of Part-IS and therefore the relevant information security risks have to be managed in accordance with the requirements in points IS.I.OR.205 and IS.I.OR.210. Instead, information security management activities are subject to the specific provisions of IS.OR.235 because matters relating to these activities can have a major impact on the organisation.

Therefore the objectives of point IS.I.OR.235 are:

(a)to protect critical and sensitive information and assets when being handled by organisations contracted for the provision of information security management activities (including organisations in the supply chain) at either their facilities or the organisation facilities, or when being transmitted between the organisation and contracted organisations, or being remotely accessed by contracted organisations;

(b)to prevent information security risks from being introduced through products and services developed or provided by the contracted organisations to the organisation, in the frame of the provision of information security management activities;

(c)to ensure that information security risks are managed throughout all the stages of the relation with the contracted organisations.

ED Decision 2023/009/R

(a)The contracting of information security management activities is a means to allocate tasks from the contracting organisation to third parties (contracted organisations). The contracting organisation remains responsible for the oversight of the contracted organisation(s) and accountable for compliance with this Regulation.

(b)A contract could take the form of a written agreement, letter of agreement, service letter agreement, memorandum of understanding, etc. as appropriate for the contracted activities.

ED Decision 2023/009/R

EXAMPLES

The following Table 1 provides some examples of information security management activities that may be contracted in relation to the provisions referred to as in IS.I.OR.200.

Table 1: Examples of information security management activities that may be contracted

ED Decision 2023/009/R

(a)OVERSIGHT OF THE CONTRACTED ORGANISATION

In order to exercise oversight of the contracted organisation, the organisation under Part-IS should have:

(1)a process to ensure compliance with the provisions regarding contracted activities contained in this Regulation;

(2)a structured process to follow the expected execution of the contract that includes:

(i)definition and agreement of the scope of the activities;

(ii)definition of the roles and responsibilities of the parties (i.e. contracting and contracted organisation);

(iii)definition and review of KPIs;

(iv)reaction to deviation from contractual obligations;

(v)performance of compliance audits, according to the predefined scope and objectives, with the aim of evaluating operational and associated assurance activities;

(vi)provision of feedback on the result of the compliance audits both within the organisation and to the contracted organisation, and response to findings. The feedback on the outcome of the compliance audits within the contracting organisation should reach the accountable manager or delegated person(s) to ensure proper monitoring of the response to findings (i.e. implementation of corrective actions) or, if deemed necessary, termination of the contract.

Note: The right of the organisation to conduct compliance audits of the contracted organisation should be included in the contract between the parties.

(b)MANAGEMENT OF THE RISKS ASSOCIATED WITH THE CONTRACTED ACTIVITIES

In order to properly manage the risks associated with the contracted activities, the organisation should meet the following criteria:

(1)A prior assessment of the suppliers is conducted before outsourcing any information security management activities. The assessment should evaluate suppliers’ competencies, sustainability as well as qualifications in relation to the activities to be contracted.

(2)There is an assessment of the risks associated with the provision of the contracted activities that has been agreed between the organisation under Part-IS and the contracted organisation.

(3)The organisation establishes and maintains appropriate information security communication channels with the contracted organisation.

ED Decision 2023/009/R

PRIOR ASSESSMENT

The purpose of the prior assessment is to evaluate suppliers’ competencies, sustainability as well as qualifications in relation to the information security activities to be contracted. This prior assessment may need to be carried out taking into account other legal requirements or procurement procedures that apply to the organisation, and may therefore be carried out in different ways, such as:

(a)in case of public bids, inclusion of eligibility requirements in the procurement documents for the potential suppliers;

(b)review of the information security certifications granted by external and impartial auditors to the potential suppliers;

(c)review of self-assessment questionnaires compiled by the potential suppliers.

RISK ASSESSMENT ASSOCIATED WITH THE PROVISION OF THE CONTRACTED ACTIVITIES

The risk assessment should take into account the maturity level of the contracted organisation, and should consider the following:

(a)identification and assessment of critical and sensitive information and assets that may be shared with, or provided by, external suppliers;

(b)identification of the information security requirements of the organisation that are applicable to the contracted organisation;

(c)evaluation, by means of a supplier assessment, of the ability of the contracted organisation (both existing and new contracted organisations) to meet the information security requirements of the contracting organisation;

(d)assessment of risks that may be introduced by the contracted organisation.

This agreed risk assessment should also consider the roles and responsibilities of the contracting and contracted organisation as well as their interfaces.

ED Decision 2023/009/R

AUDIT OF CONTRACTED ORGANISATIONS

The following aspects should be considered by the organisation when auditing a supplier contracted to perform information security management activities:

—the scope of the audit as well as the objective should be limited to processes, resources (i.e. contracted organisation personnel, systems/equipment, networks) and data used for the execution of Part-IS contracted activities;

—compliance and/or implementation audits should be done at the contracting organisation’s discretion;

—findings identified during an audit should be addressed through a remediation plan within a time frame to be validated by the contracting organisation.

ED Decision 2023/009/R

In order to ensure access by the competent authority to the contracted organisation upon request, the organisation under Part-IS should ensure that such a requirement or clause is included in the contractual documentation.

The competent authority’s access to the contracted organisations should be at least equivalent to that granted to the contracting organisation and, in any case, sufficient to ensure the assessment of continued compliance of the contracted activities with the applicable requirements.

ED Decision 2023/009/R

Access to the contracted organisation means to have visibility of evidence for compliance of the contracted activities (such as artefacts, documents, independent certifications).

Evidence of compliance could be achieved either by transfer of documents and/or access to information at the premises in accordance with the ‘audit scope’ as defined in the contract.

In those cases where the organisation would use commercial off-the-shelf services with standard contractual clauses as part of the contracted information security management activities, the organisation should consider whether these clauses provide sufficient access to the required information.

The opportunity to visit the premises should be evaluated considering different aspects such as the sensitivity of the related information or the practical accessibility to the contracted organisation (e.g. the contracted organisation is a service provider with distributed resources).

Regulation (EU) 2023/203

(a)The accountable manager of the organisation designated in accordance with Regulations
(EU) No 1321/2014, (EU) No 965/2012, (EU) No 1178/2011, (EU) 2015/340, Implementing Regulation (EU) 2017/373 or Implementing Regulation (EU) 2021/664 as applicable referred to in Article 2(1) of this Regulation shall have corporate authority to ensure that all activities required by this Regulation can be financed and carried out. That person shall:

(1)ensure that all necessary resources are available to comply with the requirements of this Regulation;

(2)establish and promote the information security policy referred to in point IS.I.OR.200(a)(1);

(3)demonstrate a basic understanding of this Regulation.

(b)The accountable manager shall appoint a person or group of persons to ensure that the organisation complies with the requirements of this Regulation, and shall define the extent of their authority. That person or group of persons shall report directly to the accountable manager, and shall have the appropriate knowledge, background and experience to discharge their responsibilities. It shall be determined in the procedures who deputises for a particular person in the case of lengthy absence of that person.

(c)The accountable manager shall appoint a person or group of persons with the responsibility to manage the compliance monitoring function referred to in point IS.I.OR.200(a)(12).

(d)Where the organisation shares information security organisational structures, policies, processes and procedures with other organisations or with areas of their own organisation which are not part of the approval or declaration, the accountable manager may delegate its activities to a common responsible person.

In such a case, coordination measures shall be established between the accountable manager of the organisation and the common responsible person to ensure adequate integration of the information security management within the organisation.

(e)The accountable manager or the common responsible person referred to in (d) shall have corporate authority to establish and maintain the organisational structures, policies, processes and procedures necessary to implement point IS.I.OR.200.

(f)The organisation shall have a process in place to ensure that they have sufficient personnel on duty to carry out the activities covered by this Annex.

(g)The organisation shall have a process in place to ensure that the personnel referred to in point (f) have the necessary competence to perform their tasks.

(h)The organisation shall have a process in place to ensure that personnel acknowledge the responsibilities associated with the assigned roles and tasks.

(i)The organisation shall ensure that the identity and trustworthiness of the personnel who have access to information systems and data subject to the requirements of this Regulation are appropriately established.

ED Decision 2023/009/R

The objectives of the requirements contained in points (a) through (e) are:

(a)to ensure that an effective organisational structure is in place in order to comply with the requirements of this Regulation;

(b)to provide trust to other organisations with whom they share risks.

ED Decision 2023/009/R

PROMOTION OF INFORMATION SECURITY POLICY

The accountable manager of the organisation should make sure that the information security policy is known and easily accessible for staff members as appropriate to their duties.

ED Decision 2023/009/R

BASIC UNDERSTANDING OF THE REGULATION

In order to demonstrate a basic understanding of this Regulation, the accountable manager of the organisation should have the ability to explain the overarching objectives of the Regulation and its implications for the organisation.

ED Decision 2023/009/R

BASIC UNDERSTANDING OF THE REGULATION

In the event that the accountable manager has no previous experience in the areas of activity pertinent to Part-IS, he or she may gain the necessary understanding by attending a training covering the content the Regulation and the technical basis for compliance. In particular, the training material should cover the overarching objectives of Part-IS, and the assessment should evaluate the understanding of these regulatory objectives.

ED Decision 2023/009/R

APPOINTMENT OF A PERSON OR GROUP OF PERSONS

The person or group of persons appointed under point IS.I.OR.240(b) with the responsibility to ensure compliance with the requirements of this Regulation should represent the management structure of the organisation.

The person or group of persons has direct access to the accountable manager (or the common responsible person, if appointed) to provide guidance, direction and support for the planning, implementation and operation of the process and standards to comply with the Regulation. They should have direct access to keep the accountable manager (or the common responsible person) properly informed on compliance and information security matters (for instance, through meetings organised on a regular basis).

Appointments should take into account the possibility that a person may not be able to carry out the organisational tasks assigned to them for a period of time, and thus also identify the necessary deputies.

These appointed persons should demonstrate a complete understanding of the requirements of this Regulation, to be able to ensure that the organisation’s processes and standards accurately reflect the applicable requirements. It is their role to ensure that compliance is proactively managed, and that any early warning signs of non-compliance are documented and acted upon.

A description of the functions and the responsibilities of the appointed persons and deputies, including their names, should be contained in the ISMM (see point IS.I.OR.250(a)(2)).

ED Decision 2023/009/R

A condition of a lengthy absence of an appointed person occurs when that person is unable to perform the assigned organisational duties. For example, if an information security management activity is required to be carried out by appointed persons at a specified interval, an absence is considered lengthy when it exceeds this interval and therefore a vulnerability in the management activity may arise.

ED Decision 2023/009/R

Appointments may be made by email, organisational chart, roles & responsibilities table, etc. usually in use by the organisation. The organisation may adopt any titles for the foregoing information security management positions, but it should identify to the competent authority the titles and the persons chosen to carry out these functions.

ED Decision 2023/009/R

COMPLIANCE MONITORING FUNCTION

The person appointed under point IS.I.OR.240(c) with the responsibility to manage the compliance monitoring function required under point IS.I.OR.200(a)(12) may be the same person as, or report to, the person responsible for the compliance monitoring function required under the implementing regulation for the domain.

ED Decision 2023/009/R

COORDINATION

The criteria to establish coordination that ensures adequate integration of the information security management within the organisation are the following:

(a)the scope and boundaries of the organisations have been established and communicated to the common responsible person;

(b)the requirements of this Regulation have been communicated to and shared with the common responsible person;

(c)the common responsible person has direct access to the accountable manager;

(d)issues are proactively managed and any early warning signs of non-compliance are documented and acted upon.

ED Decision 2023/009/R

COMMON RESPONSIBLE PERSON

If a common responsible person (CRP) is delegated by the accountable manager for the activities under this Regulation, this person should also be given the appropriate delegation that is necessary to implement the provisions of IS.I.OR.200, including the authority and the financial means to mobilise and control the resources across the organisations, or parts of the organisation involved. This delegation may also include the appointment of the person or group of persons referred to in IS.I.OR.240(b) and (c) and, in general, the CRP may be assisted in the performance of his or her duties by additional personnel.

The possibility of delegating a CRP applies to an organisation that shares information security organisational structures, policies, processes and procedures with other organisations or with parts of its own organisation that are not part of the authorisation or declaration, and therefore this CRP is expected to have information security responsibilities and competencies. In particular, the CRP should be capable of managing the organisation’s information security strategy and its implementation to ensure the achievement of the objectives described in Article 1. According to the European Cybersecurity Skills Framework (ECSF) published by ENISA in September 2022, this person may be described, for instance, as (Chief) Information Security Officer, Cybersecurity Programme Director or Information Security Manager. However, it should be noticed that these descriptions and the related skills do not consider the aviation safety perspective that is required in Article 1.

Where an entity holds multiple authorisations or declarations, the relevant accountable managers may delegate to the same CRP, who will therefore be responsible for implementing the provisions of IS.I.OR.200 for a functional cluster sharing information security structures, policies, processes and procedures.

ED Decision 2023/009/R

SUFFICIENT PERSONNEL

To determine the sufficiency of the personnel, the following elements should be taken into consideration:

(a)the organisational structures, policies, processes and procedures subject to information security management;

(b)the amount of coordination required with other organisations, contractors and suppliers;

(c)the level of risk associated with the activities performed by the organisation.

ED Decision 2023/009/R

SUFFICIENT PERSONNEL

For the purpose of this Regulation, personnel refers to the combination of the personnel directly employed by the organisation, as well as the personnel contracted as specified in IS.I.OR.235.

The activities reported in Appendix II, on the main tasks stemming from the implementation of Part-IS, should be considered when establishing the organisational structure necessary to comply with the requirements of this Regulation.

ED Decision 2023/009/R

NECESSARY COMPETENCE

(a)To determine the competence needed by the personnel performing the activities, the following elements should be taken into consideration:

(1)work roles and the associated tasks;

(2)required knowledge, skills and abilities.

(b)As part of the process to ensure that personnel maintain the necessary competence, the organisation should:

(1)assess the personnel qualifications and experience with respect to the competence required for the assigned work roles to identify gaps;

(2)align the personnel qualifications and experience with the competence expected to fulfil their roles by organising adequate learning programmes for existing members of personnel, by recruiting new resources, or by a combination thereof;

(3)maintain the personnel competence during the time they are assigned to the work role.

ED Decision 2025/014/R

NECESSARY COMPETENCE AND TRAINING PROGRAMME

A training programme should start with the identification of the competence required by the personnel for each role, followed by the identification of the gaps between the existing competence and the required one.

In order to develop the list of competencies, an organisation may use, as initial guidance, an existing cybersecurity competence framework such as the European e-Competence Framework (e-CF) or the NICE (National Initiative for Cybersecurity Education) based on the NIST Cybersecurity Framework (NIST CSF).

In Appendix II, the main tasks of this Regulation are listed and mapped to the competencies derived from the EU e-CF or, for ease of mapping, to the functions and categories of the NIST CSF. This mapping may be used to establish a baseline to identify the aforementioned competence gaps. However, it should be noticed that existing cybersecurity/information security competence frameworks typically focus primarily on the protection of standard information technologies; therefore, the proposed list of competencies may need to be adapted to the technologies or integrated with processes used in the organisation.

The bridging of the identified gaps should be seen as the objective of the training programme, which should further include the scope, content, methods of delivery (e.g. classroom training, e-learning, notifications, on-the-job training) and frequency of training that best meet the organisation’s needs considering the size, scope, required competencies, and complexity of the organisation.

Finally, as information security/cybersecurity evolves due to the rise of new threats, the organisation should periodically review the adequacy of the training programme.

ROLE-BASED COMPETENCE FRAMEWORK

Although under this Regulation there are no provisions for specific roles, besides the optional nomination of a CRP, for organisations characterised by a large number of staff members and hierarchical layers, it may be convenient to identify some roles and the related required competencies. To this end, EASA has developed an adaptation of the European Cybersecurity Skills Framework (ECSF) published by ENISA in September 2022 that can be found in Appendix VI.

ED Decision 2023/009/R

ACKNOWLEDGEMENT OF RESPONSIBILITIES

Regarding any assigned role and task, the organisation should specify all information security responsibilities an employee has in a clear and transparent manner.

As part of this, all personnel performing the activities required under this Regulation should acknowledge, in a traceable and verifiable manner, understanding of the assigned roles and the associated information security responsibilities.

ED Decision 2023/009/R

ACKNOWLEDGEMENT OF RESPONSIBILITIES

Acknowledgement of receipt such as a valid electronic or wet signature, confirmation email, etc., is a traceable proof of acknowledgement.

ED Decision 2023/009/R

IDENTITY AND TRUSTWORTHINESS

For the personnel who have access to information systems and data subject to the requirements of Part-IS, the identity should be determined on the basis of documentary evidence.

To establish the trustworthiness of such personnel, the organisation should have a documented process and appropriate criteria to ensure that individuals can be trusted to perform their role.

ED Decision 2023/009/R

IDENTITY AND TRUSTWORTHINESS

(a)Trustworthiness may be established, for example, by:

(1)prior to employment, a background check carried out in accordance with the applicable rules of Union and national law. This check may include verification of:

(i)education, previous employment and any gaps in the previous years;

(ii)absence of criminal record;

(iii)any other relevant information or intelligence considered relevant to the suitability of a person to work in the expected role;

(2)during employment, monitoring the employee’s commitment and conduct.

Note: The absence of criminal record may be verified by means of a certificate issued by the responsible authority in the Member State in accordance with Regulation (EU) 2016/1191. In the case of prospective foreign employees, the above checks may be carried out on the basis of equivalent certificates issued by the country of origin, such as a ‘certificate of good conduct’.

(b)Furthermore, the process and criteria to establish personnel’s trustworthiness may have to consider whether:

(1)the information systems and data to be accessed have been associated with a high severity of the safety consequences with the risk assessment process under IS.I.OR.205;

(2)controls or mitigating measures for risk treatment identified during the risk analysis rely on organisational/operational procedures — for instance, correct configuration and administration of information technologies, database operations, information security monitoring, etc.

In such cases, the personnel who have administrator rights or unsupervised and unlimited access to the systems and data mentioned in (a)(1), or the personnel who applies the measures under above point (b)(2), may be subject to more stringent criteria.

(c)Intelligence and any other relevant information may be gathered by screening and analysing public sources such as social media and websites, within the limits set by relevant national laws and regulations.

(d)Some organisations subject to Part-IS may also be subject to Regulation (EU) 2015/1998 that requires successful completion of background checks for personnel in certain roles, as well as a mechanism for the ongoing review of these checks. In such cases the organisation may consider suitable for the establishment of the personnel’s identity and trustworthiness required under Part-IS, in relation to their role, the process and the relevant criteria defined in Regulation (EU) 2015/1998 for standard and enhanced background checks. However, it should be noted that compliance with the provisions for the establishment of identity and trustworthiness under Part-IS does not constitute compliance with the provisions on background checks as defined in Regulation (EU) 2015/1998.

Regulation (EU) 2023/203

(a)The organisation shall keep records of its information security management activities

(1)The organisation shall ensure that the following records are archived and traceable:

(i)any approval received and any associated information security risk assessment in accordance with point IS.I.OR.200(e;)

(ii)contracts for activities referred to in point IS.I.OR.200(a)(9);

(iii)records of the key processes referred to in point IS.I.OR.200(d);

(iv)records of the risks identified in the risk assessment referred to in point IS.I.OR.205 along with the associated risk treatment measures referred to in point IS.I.OR.210;

(v)records of information security incidents and vulnerabilities reported in accordance with the reporting schemes referred to in points IS.I.OR.215 and IS.I.OR.230;

(vi)records of those information security events which may need to be reassessed to reveal undetected information security incidents or vulnerabilities.

(2)The records referred to in point (1)(i) shall be retained at least until 5 years after the approval has lost its validity.

(3)The records referred to in point (1)(ii) shall be retained at least until 5 years after the contract has been amended or terminated.

(4)The records referred to point (1)(iii), (iv) and (v) shall be retained at least for a period of 5 years.

(5)The records referred to in point (1)(vi) shall be retained until those information security events have been reassessed in accordance with a periodicity defined in a procedure established by the organisation.

(b)The organisation shall keep records of qualification and experience of its own staff involved in information security management activities

(1)The personnel’s qualification and experience records shall be retained for as long as the person works for the organisation, and for at least 3 years after the person has left the organisation.

(2)Members of the staff shall, upon their request, be given access to their individual records. In addition, upon their request, the organisation shall provide them with a copy of their individual records on leaving the organisation.

(c)The format of the records shall be specified in the organisation’s procedures.

(d)Records shall be stored in a manner that ensures protection from damage, alteration and theft, with information being identified, when required, according to its security classification level. The organisation shall ensure that the records are stored using means to ensure integrity, authenticity and authorised access.

ED Decision 2023/009/R

Records are required to document results achieved or to provide evidence of activities performed. Records become factual when recorded and cannot be modified. Therefore, they are not subject to version control. Even when a new record is produced covering the same issue, the previous record remains valid.

The ‘approval received’ referred to in point (a)(1)(i) includes any ‘certificate’ received by the organisation when it is provided for by the implementing rule for its domain.

ED Decision 2023/009/R

When complying with the requirements under points (a)(1)(vi) and (a)(5), the organisation should establish a data retention policy defining procedures to:

(a)manage relevant security data files;

(b)establish the periodical assessment of their content; and

(c)define the criteria to allow deletion of records of information security events when the objective of the requirement under (a)(5) has been met.

ED Decision 2023/009/R

The objective of the requirement under (a)(1)(vi) is to ensure detection of possible indication of information security incidents or vulnerabilities which are not obvious by normal operation (e.g. previously unknown situations), while the objective of the requirement under (a)(5) is to allow the necessary flexibility to control the volume of the stored information security events.

Records of information security events include those events identified to be within the scope of the detection activities under IS.I.OR.220(a), as well as other information security data produced by assets that have been identified under IS.I.OR.205.

A data retention policy clarifies what information should be stored or archived and for how long. Some guidance about data retention can be found in EUROCAE ED-206, Chapter 2.6.

Once a data set completes its retention period, it can be deleted or moved as permanent historical data to a secondary or tertiary storage.

ED Decision 2023/009/R

When complying with the requirements under points (c) and (d) for all the records required by points IS.I.OR.245 (a) and (b), the organisation should consider the following:

(a)Records should be kept in paper form or in electronic format or a combination of both media. The records should remain accessible whenever needed within a reasonable time and usable throughout the required retention period. The retention period starts when the record has been created.

(b)Records data integrity, availability and authenticity should be protected in consistency with protection of corresponding operational data, and as such, should be within the scope of the ISMS.

(c)Storage systems should be protected against unauthorised access (i.e. data leakage attempts against personal data/modification of records) and thus should have information security measures implemented in consistency with the level of information security risk associated with them.

(d)Once records are not required to be retained anymore, the destruction of records and decommissioning of assets used for their storage should be implemented appropriately.

ED Decision 2023/009/R

RECORDS ACCESSIBILITY THROUGHOUT THE RETENTION PERIOD

It is recommended to follow best practices for data retention and, for data that may need to be restored, backup strategies, such as the use of automated backup tools, segregation or geographic separation of backup storage location(s), and to consider offline backups to prevent ransomware risks. These practices should be considered also when record-keeping is contracted to service providers with distributed resources.

Special attention should be paid to significant hardware and software changes, ensuring that stored digital records remain accessible and readable (e.g. file system, application file format, forward compatible database versions, etc.). Paper-based information needs to be archived in an adequate environment, in which records are protected against degradation factors (e.g. excessive heat, light or humidity).

RECORDS DATA INTEGRITY AND PROTECTION FROM UNAUTHORISED ACCESS

A commonly used method to achieve authenticity and integrity protection is the use of digital signatures at document level. Digital signatures can be added to the document’s file (e.g. PDF) to ensure that a record has not been modified by someone other than its author (integrity) and that the author is who is expected to be (authenticity).

Moreover, to prevent unauthorised access, records can be protected, for example, by implementing a role-based access control (RBAC) approach, or certain records can be password protected at the file level. Commercial applications feature built-in basic password protection functions for their file formats. Access protection can also be achieved by protecting the environment where the individual records are stored (e.g. access protection on databases, file shares, directories, etc.).

Regulation (EU) 2025/2293

(a)The organisation shall make available to the competent authority an information security management manual (ISMM) and, where applicable, any referenced associated manuals and procedures, containing:

(1)a statement signed by the accountable manager confirming that the organisation will at all times work in accordance with this Annex and with the ISMM. If the accountable manager is not the chief executive officer (CEO) of the organisation, then the CEO shall countersign the statement;

(2)the title(s), name(s), duties, accountabilities, responsibilities and authorities of the person or persons defined in point IS.I.OR.240(b) and (c);

(3)the title, name, duties, accountabilities, responsibilities and authority of the common responsible person defined in point IS.I.OR.240(d), if applicable;

(4)the information security policy of the organisation as referred to in point IS.I.OR.200(a)(1);

(5)a general description of the number and categories of staff and of the system in place to plan the availability of staff as required by point IS.I.OR.240;

(6)the title(s), name(s), duties, accountabilities, responsibilities and authorities of the key persons responsible for the implementation of point IS.I.OR.200, including the person or persons responsible for the compliance monitoring function referred to in point IS.I.OR.200(a)(12);

(7)an organisation chart showing the associated chains of accountability and responsibility for the persons referred to in points (2) and (6);

(8)the description of the internal reporting scheme referred to in point IS.I.OR.215;

(9)the procedures that specify how the organisation ensures compliance with this Part, and in particular:

(i)the documentation referred to in point IS.I.OR.200(c;)

(ii)the procedures that define how the organisation controls any contracted activities as referred to in point IS.I.OR.200(a)(9);

(iii)the ISMM amendment procedure referred to in in point (c);

(10)the details of currently approved alternative means of compliance.

(b)The initial issue of the ISMM shall be approved and a copy shall be retained by the competent authority. An approval shall not be required for declared organisations. The ISMM shall be amended as necessary to remain an up-to-date description of the ISMS of the organisation. A copy of any amendments to the ISMM shall be provided to the competent authority;

(c)Amendments to the ISMM shall be managed in a procedure established by the organisation. Any amendments that are not included within the scope of that procedure and any amendments related to the changes referred to in point IS.I.OR.255(b), shall be approved by the competent authority. An approval shall not be required for declared organisations.

(d)The organisation may integrate the ISMM with other management expositions or manuals it holds, provided there is a clear cross reference that indicates which portions of the management exposition or manual correspond to the different requirements contained in this Annex.