Article 15 Conditions for obtaining a certificate

GENERAL

(a)Article 15 of Regulation (EU) 2021/664 contains the conditions for obtaining a certificate. They are inspired from the requirements that apply for ATM/ANS providers (i.e. those contained in Subpart B of Annex III to Regulation (EU) 2017/373) to obtain and maintain their respective certificates, but tailored to the particularities of the U-space.

(b)USSPs and single CIS providers are organisations that directly contribute to safe UAS operations within the U-space airspace, and it is important that they have a risk-based management system in place. It is, therefore, essential that they comply with an appropriate management system established for that purpose. To apply this management system, taking into account the different types of providers and the performance of the services they provide, Regulation (EU) 2021/664 lays down some management system requirements. The elements of this management system are, therefore, harmonised for all the different types of single CIS providers or USSPs, but their application may be different depending on the different services provided, especially for the USSPs. Therefore, the proposed management system provides for a proportionate application of the requirements for both providers.

(c)USSPs and single CIS providers are also required to implement a security management system based on the requirements laid down in point ATM/ANS.OR.D.010 of Subpart D of Annex III to Regulation (EU) 2017/373. It has to be noted that Opinion No 03/2021 ‘Management of information security risks’ proposes amendments, among others, to Subpart D of Annex III to Regulation (EU) 2017/373, which will become applicable to USSPs and single CIS providers once the related regulation is published.

(d)To become a certified USSP, the applicant should demonstrate its capability to provide at least the four mandatory U-space services referred to in Article 3(2) of Regulation (EU) 2021/664. Whenever required by a Member State as per Article 3(3) of Regulation (EU) 2021/664, the applicant should also demonstrate its capability to provide the additional U-space services.

(e)Once an applicant becomes a certified USSP, it may provide services in any U-space airspace across the European Union. However, before the USSP starts providing services, the competent authority of the U-space airspace where the provision of services is intended to take place may need to validate that the USSP satisfies the local conditions (e.g. performance requirements and constraints).

SAFETY SUPPORT ASSESSMENT The applicant should provide the assurance with sufficient confidence that the provision of services that support the conduct of UAS operations will comply with the required level of performance and constraints via a complete, documented and valid argument that the services will be provided and will continue to be provided only as specified in the specified context. The safety support assessment undertaken by the applicant should encompass any contracted activities or specific arrangements. For that purpose, the applicant should define its ‘functional systems’, ‘specification of services’ and ‘safety support requirements’.

VERIFICATION OF THE SAFETY SUPPORT ASSESSMENT PROCESS The applicant should ensure that the verification activities as regards the safety support assessment process ensure the completeness and correctness of the argument and include the verification that:

(a)the risk analysis is complete;

(b)the safety criteria are correct and commensurate with the risk analysis;

(c)all the elements of the ‘functional system’ or environment of operation are identified;

(d)the specification of the operational context is complete and correct;

(e)that the specification of the way the service behaves is complete and correct;

(f)the specification is analysed in the context in which the services are intended to be provided;

(g)the ‘safety support requirements’ are correct and complete in relation to the specification;

(h)the design is complete and correct with reference to the ‘specification of services’ and ‘safety support requirements’, and correctly addresses the safety criteria;

(i)the design is the one analysed;

(j)the implementation, to the intended degree of confidence, corresponds to the design analysed and behaves only as specified in the given operational context; and

(k)the way the service behaves complies with and does not contradict other applicable requirements.

CONCEPT OF OPERATIONS (CONOPS) The applicant should develop its concept of operations, which is meant to:

(a)increase the competent authority’s understanding of the applicant’s use case;

(b)define the scope of the functional system submitted for certification;

(c)establish the depth and boundaries of the certification, and ultimately the scope of the certificate;

(d)capture the assumptions on the U-space performance requirements to be satisfied as per Article 3(4) of Regulation (EU) 2021/664.

COMPLIANCE MATRIX The applicant should develop a compliance matrix for the competent authority to ensure the soundness and completeness of the compliance demonstration. The compliance matrix should:

(a)cover all the layers of items to be satisfied (i.e. requirements of Regulation (EU) 2021/664, the related AMC and GM, and applicable industry standards);

(b)capture how each item is intended to be satisfied; and

(c)link each item with supporting evidence (e.g. documents, tests, engineering documents).

INFORMATION THAT SUPPORTS CERTIFICATION The applicant should provide all necessary information to the competent authority during the certification activities, especially in presenting its strategy for the purpose of certification and seeking agreement on the scope and depth of the assessment of the certification. The applicant should develop evidence, and make it available to the competent authority for investigation, which demonstrates that its ‘functional system’ allows for the safe provision of the services. Additionally, the applicant should report to the competent authority any deficiencies (including those related to information security) and/or errors identified in the functional system, especially those that could lead to an unsafe condition. Such reports should be made in a form and manner acceptable to the competent authority.

CORRELATION BETWEEN REGULATION (EU) 2017/373 AND THE AMC AND GM TO REGULATION (EU) 2021/664 Subpart B, and some requirements in Subpart A and D of Annex III to Regulation (EU) 2017/373 are also applicable to USSPs and single CIS providers by virtue of the specific applicability references made in Article 15 of Regulation (EU) 2021/664. However, the AMC and GM to Regulation (EU) 2017/373 are naturally not addressed to USSPs or to single CIS providers and are, therefore, not applicable to them. To facilitate the reading and implementation of the relevant requirements, the following table contains the correlation between the applicable requirements of Subparts A, B and D of Annex III to Regulation (EU) 2017/373 and the AMC and GM to Article 15 of Regulation (EU) 2021/664. In this context, the table below contains the acceptable means of compliance and guidance material for USSPs and single CIS providers to ensure compliance with the listed requirements of Regulation (EU) 2017/373. For the applicable requirements in Subparts A, B and D of Annex III to Regulation (EU) 2017/373, listed in the table below, for which no AMC and GM are provided, USSPs and single CIS providers may propose their own means to comply with the applicable requirements.

‘APPLICANT’ IN THE CONTEXT OF THE U-SPACE For the purposes of Articles 14 and 15 of Regulation (EU) 2021/664, ‘applicant’ means the USSP or the designated single CIS provider that seeks the obtention and approval of a certificate as per Article 14 of Regulation (EU) 2021/664.

‘UNSAFE CONDITION’ IN THE CONTEXT OF THE U-SPACE For the purposes of Regulation (EU) 2021/664, ‘unsafe condition’ may be considered a situation which, due to data error or data alteration (e.g. in case of malicious interactions), a procedure error, or a system excessive response time or malfunction may result (but is not limited to) in the following:

(a)insufficient separation/spacing, or air proximity between manned and unmanned aircraft within the U-space airspace, which may result in mid-air collision;

(b)a lack of separation between unmanned aircraft, which may result in mid-air collision leading to an increase of the ground risk;

(c)an unmanned aircraft exiting the boundaries of the U-space airspace;

(d)an unmanned aircraft entering a prohibited (no-fly zone) or a restricted access geographical zone (as per Article 15 of Regulation (EU) 2019/947), which could be established within the Uspace airspace.

‘FUNCTIONAL SYSTEM’ IN THE CONTEXT OF THE U-SPACE For the purposes of Regulation (EU) 2021/664, ‘functional system’ means a combination of procedures, human resources and equipment, including hardware and software, organised to provide services within the context of the U-space airspace.

SAFETY SUPPORT REQUIREMENTS Safety support requirements are the characteristics/items of the functional system to ensure that the service performs as specified. The following non-exhaustive list contains examples of safety support requirements that specify:

(a)for software (and equipment), the complete behaviour in terms of functions, accuracy, timing, order, format, capacity, resource usage, robustness to abnormal conditions, overload tolerance, availability, reliability, confidence and integrity;

(b)for people, their performance in terms of tasks (e.g. accuracy, response times, acceptable workload, resilience to distraction, self-awareness, team-player capacity, adaptability, reliability, confidence, skills, and knowledge in relation to their tasks);

(c)for procedures, the circumstances for their enforcement, the resources needed to perform them (i.e. people and equipment), the sequence of actions to be performed, and the timing and accuracy of the actions; and

(d)interactions between all parts of the system.

SPECIFICATION OF SERVICES As per the AMC and GM to Article 3 of Regulation (EU) 2021/664, the acceptable level of safety (ALS) is determined during the airspace risk assessment and materialised upon the U-space airspace definition and the related performance requirements and constraints. These ‘high-level design characteristics’ of the functional system, complemented with those derived from the applicant’s safety assessment form the ‘specification of services’, which is the baseline applicants should use for their safety support assessments alongside the ‘safety support requirements’. In the absence of established U-space performance requirements and constraints, as per the AMC and GM to Article 3 of Regulation (EU) 2021/664, the applicant should make reasonable assumptions to define a suitable set of performance requirements. The applicant should demonstrate to the competent authority that the specification is complete and correct with regard to its concept of operations (CONOPS) and safety assessment.

CERTIFICATION DATA AND EVIDENCE The data and evidence that support the applicant’s certification cover both procedural and technical aspects, and encompass the following items:

(a)concept of operations (CONOPS);

(b)compliance matrix with Regulation (EU) 2021/664, the related AMC and GM, and applicable industry standards;

(c)description of the engineering processes and procedures (e.g. software assurance);

(d)engineering and design documentation;

(e)safety assessment;

(f)security risk assessment;

(g)operational procedures and instructions to other dependent stakeholders (e.g. USSPs, UAS operators);

(h)analyses and tests;

(i)records (e.g. review, configuration and changes, statement of works, quality, etc.);

(j)residual defects and limitations. Given that certification is a dynamic process, other items may be considered necessary to be documented during the certification activities.

CONCEPT OF OPERATIONS (CONOPS) — CONTENT The content of the CONOPS should be agreed with the competent authority, and may cover the following:

(a)For the USSP and the single CIS provider:

(1)description of the applicant’s business case;

(2)when known, description of the U-space environment where the service(s) is (are) intended to be provided (e.g. identification of the stakeholders);

(3)whether the provision of services is intended in controlled and/or uncontrolled airspace and/or in airspace where both controlled and uncontrolled manned aircraft operations take place;

(4)description of the infrastructure, and how the availability/continuity of the provision of the service(s) is satisfied;

(5)operational capacity (e.g. number of simultaneous operations supported, growth potential/scalability);

(6)specific arrangements (e.g. service acquired from a third party, or through subcontracted activities);

(7)a description of each of the services provided by the applicant, and the operational functions and design principles that drive the implementation of the services delivered to U-space airspace actors;

(8)description of the applicant’s ‘functional system’;

(9)if any, the targeted level of integrity or reliability of the functional systems;

(10)the technical measures regarding cybersecurity (e.g. authentication means, encryption);

(11)when relevant, description of previous certification/approval experience;

(12)declaration of any additional features which are not required to comply with Regulation (EU) 2021/664 (and thus outside the scope of the certification);

(13)the assumptions on the U-space performance requirements addressed in the AMC and GM to Article 3(4) of Regulation (EU) 2021/664;

(14)any other considerations that may help the competent authority to gain a good understanding of the applicant’s use case.

(b)For the single CIS provider:

(1)the type of information collected from the CIS, and from which organisation;

(2)interfaces with USSPs, ATSPs and other relevant entities that are entitled to provide information through the CIS;

(3)a description of the service and information provided to the USSPs.

(c)For the USSP:

(1)whether the provision of services is intended in centralised and/or decentralised CIS;

(2)how the information is intended to be exchanged with other USSPs and, when relevant, with the CIS;

(3)the U-space services provided as per Article 3(2) and (3) of Regulation (EU) 2021/664;

(4)the type of supported operations, such as VLOS/BVLOS, over congested environment;

(5)how the services are intended to be delivered to UAS operators (e.g. API or HMI);

(6)the operational limits of their system, e.g. range, altitude, etc.;

(7)the solution implemented to receive the UAS remote identification.

COMPLIANCE MATRIX The applicant is free to select the way of packaging the evidence that supports compliance. The development of the compliance matrix may also be an iterative process, as the evidence may not be fully available or characterised at an initial version of the compliance matrix, and several versions of the compliance matrix may be delivered during the initial certification process and subsequently updated during the continued oversight process. However, even at an initial version of the compliance matrix, the early identification of the documents that support compliance remains necessary in order to provide an overview of the compliance approach.

APPROACH TO CERTIFICATION Based on the presentation of the applicant’s CONOPS, strategy for certification, and the associated set of data and evidence, the competent authority defines the scope and depth of the certification investigations and selects the documents, set of data, and activities (e.g. onboarding process, software development, tests, change management procedures, etc.) to be assessed. The competent authority’s investigation comprises two main types of investigation:

(a)Desktop reviews: mostly dedicated to documentation reviews performed remotely, without visiting the applicant’s facilities.

(b)Audits: to perform an in-depth and comprehensive assessment/inspection of the applicant’s organisation, activities, processes, and evidence. Depending on whether or not a physical inspection is necessary, audits may be performed on-site or remotely considering, for example, the efficiency of the access and the assessment of the items subject to investigation, and access to personnel in charge of the applicant’s activities.

SOFTWARE ASSURANCE The applicant should ensure that a documented software assurance process is established to produce evidence and arguments that demonstrate that the provision of services satisfies the required U-space performance requirements. Accordingly, the applicant should control the development of its software and follow a structured process, including planned and systematic activities (procedures), to substantiate with sufficient confidence that:

(a)development errors (e.g. mistakes made in the determination, design or implementation of the requirements) have been identified, corrected or mitigated, and that the potential residual defects in the implementation are minimised; and

(b)the software behaves as intended in the specified context. When relevant, the applicant should also demonstrate that the implementation of potential additional features, except those required for ensuring the safe provision of services, do not interfere with the safe provision of the required services. When software assurance relies on credit taken from simulated environments and/or automated activities (e.g. automated verification) the applicant should:

(a)identify the scope and the credit taken from those activities and substantiate their relevance for the arguments that demonstrate that the provision of services satisfies the U-space performance requirements; and

(b)demonstrate that the simulated or automated environments:

(1)are representative of, or sufficiency close to, the real operational conditions; and

(2)can be trusted, in producing evidence of their proper behaviour and products.

INFORMATION SECURITY ASSURANCE In conjunction with point B of Annex III to Regulation (EU) 2021/664, the applicant should ensure a level of security consistent with the intended UAS operations by evaluating and mitigating the risks induced by potential intentional unauthorised electronic interaction (IUEI) on the components of the functional systems (e.g. including the hardware and software, interfaces with the other U-space airspace stakeholders, e-conspicuity, or Network R-ID receivers). The applicant should follow a continued risk-based approach as regards the following:

(a)To assess the provision of services against any potential information security threat and vulnerability that could affect the confidentiality, availability and integrity of the provision of services.

(b)The result of this assessment, following the identification of any necessary mitigation means, should be that the provision of services entails no identifiable vulnerabilities, or if any, they cannot be exploited to create a hazard or generate a failure that would have an effect that is considered unacceptable, in particular when they may result in an unsafe condition.

(c)When a risk needs to be mitigated, the applicant should provide evidence that the mitigation means provide sufficient grounds for evaluating that the residual risk is acceptable. Accordingly, the effectiveness and robustness of the mitigation means should be demonstrated through (a potential combination of) security-oriented robustness testing, inspection/analysis, refutation/penetration testing, etc., as agreed with the competent authority.

(d)Once the overall residual risk is considered acceptable, the applicant should develop instructions, for example physical and operational security procedures, auditing and monitoring of the security effectiveness, to ensure a continued and effective protection of the provision of services.

(e)When the mitigation means rely on operational security measures to be fulfilled by a third party (e.g. UAS operator, USSP), they should be properly documented and shared with the relevant stakeholder.

(f)The applicant should dynamically reassess the potential for new vulnerabilities and the level of threat that were not foreseen during previous security risk assessments of the functional systems. If the continued assessment identifies an unacceptable threat condition, the applicant should notify the relevant stakeholders and the competent authority in a timely manner of the need and the means to mitigate the new risk. This risk assessment is referred to as ‘security risk assessment’.

SOFTWARE ASSURANCE — SOFTWARE ASSURANCE PROCESSES The software assurance processes should provide evidence and arguments that they support, as a minimum, the following:

(a)The software requirements correctly state what is required by the software in order to meet the ‘specification of services’ and the ‘safety support requirements’. For that purpose, the software requirements should:

(1)be correct, complete and, when available, compliant with upper-level requirements; and

(2)specify the functional behaviour in nominal and degraded modes, and in terms of timing performance, capacity, accuracy, resource usage, robustness to abnormal operating conditions and overload tolerance, as appropriate, of the implemented software.

(b)The software implementation does not contain functions that could adversely affect the satisfaction of the service specification and/or does not cause undesirable behaviour that may impair the safe provision of services.

(c)Traceability is addressed in respect of all software requirements as follows:

(1)Traceable to the ‘specification of services’ or the ‘safety support requirements’.

(2)Each software requirement allocated to a component should either be traced to an upper-level requirement, or its need should be justified and assessed that it does not affect the satisfaction of the safety support requirements allocated to the component.

(3)Each software requirement is linked to a verification activity (e.g. analysis and/or tests), granular enough to efficiently demonstrate that the requirements are met.

(d)The functional behaviour, timing performance, capacity, accuracy, resource usage (potentially on the target hardware), robustness to abnormal operating conditions and overload tolerance of the implemented software comply with the software requirements.

(e)The software verification:

(1)is correct and completely verifies the software requirements, with a sufficient level of detail demonstrating that the requirements are fully met (e.g. intent of the test; analysis; clear, expected behaviour; and pass–fail criteria);

(2)confirms that the service behaves as specified in an environment representative of the intended operational environment;

(3)allows to verify all the interfaces and the robustness of the implementation;

(4)is performed through review, analysis and/or testing and/or other equivalent means, as agreed with the competent authority; and

(5)generates traceable results, with clear identification of any failed item.

(f)The evidence and arguments produced by the software assurance processes should be traceable to:

(1)a known executable version of the software;

(2)a known range of configuration data; and

(3)a known set of software items and descriptions, including specifications, which have been used in the production of that version, or can be justified as applicable to that version.

(g)The software assurance processes should include the necessary activities to ensure that the software life cycle data can be shown to be under configuration control throughout the software’s life cycle, including the possible evolutions due to changes or correction of problems. The activities should include, as a minimum:

(1)configuration identification, traceability and status-accounting activities, including archiving procedures;

(2)problem reporting, tracking, and management of corrective actions; and

(3)retrieval and release procedures.

(h)Software quality control should be undertaken to assess the conformance of the development of the software with established processes and related procedures, and should be supported by any necessary corrective actions according to the findings. The software quality control should be performed independently from the software development team to ensure impartiality of the control.

SOFTWARE ASSURANCE — USE OF EXISTING INDUSTRY STANDARDS The applicant is responsible for defining the software assurance processes. The applicant may directly develop its own method, provided it allows to properly structure the software activities and addresses the key software engineering principles and associated software life cycle data upon which the software process assurance is built:

(a)software specification (requirements and design information);

(b)software verification;

(c)traceability (between items);

(d)configuration and change management; and

(e)quality assurance. Nevertheless, it is recommended that the applicant consider the guidance material contained in existing industry standards for software assurance considerations. It should be considered that not all standards address all aspects required, and the applicant may need to define additional software assurance processes. Guidance material typically includes:

(f)objectives of the software life cycle processes;

(g)activities to meet the objectives;

(h)description of the evidence, in the form of software life cycle data, which indicates that the objectives have been met; and

(i)particular aspects (e.g. previously developed or COTS software) that may be applicable to certain applications.

SOFTWARE ASSURANCE — TESTING INFRASTRUCTURE The applicant, and especially the USSPs, may set up a testing infrastructure against which authorised users may test their capability to exchange data. Upon agreement on the retrieval of a set of predefined testing data, the applicant may set up an environment to check at regular intervals its capability to conform with the requirements for providing the services. The same infrastructure may then be used by oversight authorities to audit the applicant.

SOFTWARE ASSURANCE — MONITORING The applicant may use feedback of software experience to confirm that the software assurance processes are effective. For that purpose, the effects from software malfunctions (i.e. the inability of a programme to perform a required function correctly) or failures (i.e. the inability of a programme to perform a required function) reported according to the relevant requirements on reporting and assessment of service occurrences should be assessed in comparison with the effects identified for the service concerned as per the service specification demonstration. Additionally, within the safety support assessment process, the applicant may ensure that the monitoring criteria to be used to demonstrate that the safety support case remains valid during the operation of the functional system (i.e. that the service continues to meet its specification) are identified and documented. These criteria should be such that:

(a)they indicate that the assumptions made in the safety support case remain valid; and

(b)if the properties being monitored remain within the bounds set by these criteria, the service will behave as specified.

SECURITY RISK ASSESSMENT The security risk assessment may cover the following steps and security items:

(a)determination of the operational environment of the functional system;

(b)identification of the digital interfaces and assets (i.e. the items contributing to, or sustaining, cybersecurity);

(c)identification of the attack paths;

(d)considering the usual attack (e.g. DoS), assessment of the consequences and severity of the identified threat on the affected items;

(e)evaluation of the potentiality of a successful exploit, or of the difficulty of performing a successful attack that would have an impact on the typical security attributes: confidentiality, availability, integrity;

(f)an iterative approach to converge on an acceptable level of residual risk:

(1)evaluate the severities in conjunction with the potential for attack (or, inversely, the difficulty of attacking);

(2)the outcome of the evaluation is acceptable and does not need additional or strengthened mitigation means;

(3)the outcome of the evaluation is not acceptable and requires an analysis to identify mitigation means to reach an acceptable level of safety;

(4)evaluation of the effectiveness of the mitigation means with respect to the level of risk (combination of the level of threat and severity of the threat condition).

INFORMATION SECURITY — DEFINITIONS For the purposes of Regulation (EU) 2021/664, the following is defined regarding ‘information security’:

(a)‘vulnerability’: a weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source. [Source: NIST SP800-53, Rev 2]

(b)‘threat’: a potential for violation of security, which exists when there is an entity, circumstance, capability, action, or event that could cause harm. [Source: IETF RFC 4949]

(c)‘threat scenario’: the specification of intentional unauthorised electronic interaction (IUEI), consisting of the contributing threat source (attacker and attack vector), vulnerabilities, operational conditions, and resulting threat conditions, and events by which the target was attacked. [Source: ED-202A / DO-326A]

(d)‘severity’: qualitative indication of the magnitude of the adverse effect of a threat condition [Source: ED-202A / DO-326A]

OCCURRENCE REPORTING The applicant should establish procedures for reporting occurrences to the competent authority and to any other organisation necessary, which should include a description of:

(a)the applicable requirements for reporting;

(b)the reporting mechanism, including reporting forms, means, and deadlines;

(c)the personnel responsible for reporting; and

(d)the mechanism for identifying root causes, and the actions to be taken to prevent similar occurrences in the future, as appropriate.

MANAGEMENT SYSTEM — TECHNICAL AND OPERATIONAL CAPACITY The applicant should ensure that it has sufficient technical and operational capacity, that is, adequate and appropriate resources to perform its tasks and discharge its responsibilities.

MANAGEMENT SYSTEM — ISO An ISO 9001 certificate, issued by an appropriately accredited organisation, addressing the quality management elements should be considered a sufficient means of compliance. In this case, the applicant should accept the disclosure of the documentation related to the certification to the competent authority upon its request.

MANAGEMENT SYSTEM — RESPONSIBILITIES AND ACCOUNTABILITIES The applicant should ensure that senior management defines and communicates the responsibilities and accountabilities within the organisation, and documents them within the management system. The appointment of an accountable manager who is given the required authority and responsibilities requires that the individual has the necessary attributes to fulfil that role. The accountable manager may have more than one function in the organisation. Nonetheless, the accountable manager’s role is to ensure that the management system is properly implemented and maintained through the allocation of resources and tasks.

MANAGEMENT SYSTEM — POLICY The applicant should ensure that the management system policy includes a commitment to:

(a)comply with all applicable requirements and standards, and consider best practices;

(b)continually improve the effectiveness of the management system;

(c)provide appropriate resources; and

(d)enforce the performance of the services required to support the achievement of the highest level of safety in the U-space airspace. The policy should be signed by the accountable manager of the organisation.

MANAGEMENT SYSTEM — SAFETY PERFORMANCE MONITORING AND MEASUREMENT The applicant should ensure that the safety performance monitoring and measurement process includes:

(a)safety reporting;

(b)safety reviews including trend reviews, which would be conducted, among others, during the introduction and deployment of new technologies, change or implementation of procedures, or in situations of structural changes in the operations; and

(c)safety surveys, examining elements or procedures of a specific operation, such as problem areas or bottlenecks in daily operations, perceptions and opinions of operational personnel, and areas of dissent or confusion.

MANAGEMENT SYSTEM — SAFETY ASSESSMENT (OF THE APPLICANT’S SYSTEM) As per the AMC and GM to Article 3 of Regulation (EU) 2021/664, the acceptable level of safety is established during the airspace risk assessment by defining safety criteria for the U-space airspace concerned. The results of the airspace risk assessment should be considered when conducting the safety assessment of the applicant’s U-space services that directly contribute to safety. The applicant should ensure that the functional system that supports the provision of U-space services is complete and correct with regard to the acceptable level of safety of the U-space airspace (i.e. safety criteria, and high-level design characteristics of the functional system defined throughout the airspace risk assessment). A streamlined safety assessment should be conducted, and should comprise at least the following elements:

(a)the identification of additional hazards that may be induced by the decision as regards the design of the applicant’s functional system;

(b)the risk analysis and the related effects;

(c)the risk evaluation and, if required, the risk mitigation;

(d)safety criteria and requirements:

(1)complementing as necessary those already defined in the airspace risk assessment; and

(2)compliant with, and not contradicting, the high-level design characteristics of the functional system defined in the airspace risk assessment;

(e)the specification of the monitoring criteria necessary to demonstrate that the service delivered by the functional system will continue to meet the safety criteria.

MANAGEMENT SYSTEM — ASSESSMENT OF THE MANAGEMENT SYSTEM The applicant should ensure that:

(a)senior management assesses the service provider’s management system, at planned intervals, to ensure its continuous suitability, adequacy, and effectiveness;

(b)the assessment includes evaluating opportunities for improvement and the need for changes to the management system, including the policy and the objectives; and

(c)records of senior management assessments are maintained.

MANAGEMENT SYSTEM — PERSONNEL TRAINING AND COMPETENCIES The applicant should:

(a)determine the necessary competencies for personnel that perform activities which support the provision of services;

(b)where applicable, provide training or take other actions to achieve the necessary competencies;

(c)evaluate the effectiveness of the training or the actions taken;

(d)ensure that personnel are aware of the relevance and importance of their activities and how they contribute to the achievement of the objectives; and

(e)maintain appropriate records of education, training, skills, and experience.

MANAGEMENT SYSTEM — COMMUNICATION RESPONSIBILITIES The applicant should ensure that appropriate communication processes are established, and that communication takes place regarding the effectiveness of the management system.

MANAGEMENT SYSTEM — DOCUMENTATION The applicant should include in its documentation:

(a)a statement signed by the accountable manager confirming that the organisation will continuously work in accordance with the applicable requirements;

(b)the scope of the activities;

(c)the titles and names of the nominated postholders;

(d)the chart showing the lines of responsibility between the nominated postholders;

(e)a general description and location of the facilities;

(f)procedures describing the function and specifying how the organisation monitors and ensures compliance with the applicable requirements; and

(g)the amendment procedure for the management system documentation.

MANAGEMENT SYSTEM — COMPLIANCE MONITORING The applicant should:

(a)specify the basic structure of the compliance monitoring function, structured according to the size of the service provider and the complexity of the activities to be monitored, including those which have been subcontracted;

(b)monitor compliance with the procedures they have designed to ensure that services are provided with the required level of safety and quality, as applicable; in doing so, they should as a minimum, and where appropriate, monitor:

(1)manuals, logs, and records;

(2)training standards; and

(3)management system procedures;

(c)ensure that a staff member is responsible for compliance monitoring to ensure that the organisation continues to meet the applicable requirements; the accountable manager should ensure that adequate resources are allocated for compliance monitoring;

(d)ensure that the personnel involved in compliance monitoring have access to all parts of the applicant’s management system documentation and, as necessary, of any subcontracted organisation; in the case the person responsible for compliance monitoring also acts as safety manager, the accountable manager, with regard to their direct accountability for safety, should ensure that sufficient resources are allocated to both functions, taking into account the size of the applicant, and the nature and complexity of its activities; the independence of the compliance monitoring function should be established by ensuring that audits and inspections are carried out by personnel not directly involved in the activity being audited;

(e)ensure that the relevant documentation includes relevant part(s) of the applicant’s management system documentation; the relevant documentation should also include:

(1)terminology;

(2)a description of the service provider;

(3)allocation of duties and responsibilities;

(4)procedures for ensuring compliance; and

(5)the compliance monitoring programme, reflecting:

(i)the schedule of the monitoring programme;

(ii)audit procedures;

(iii)reporting procedures;

(iv)follow-up and corrective action procedures;

(v)the record-keeping system; and

(vi)document control;

(f)ensure that the personnel responsible for managing the compliance monitoring function receive training in this task; such training should cover compliance monitoring requirements, manuals and procedures related to the task, audit techniques, reporting and recording; the allocation of time and resources should be governed by the volume and complexity of the activities concerned.

MANAGEMENT SYSTEM — FUNCTIONAL CHANGE MANAGEMENT PROCEDURE The applicant should ensure that:

(a)the procedures for managing changes cover the complete life cycle of a change from definition to operations, including transition into service;

(b)the roles and responsibilities for the change management processes are identified;

(c)a notification process for changes includes:

(1)the point of contact in charge of the notification of changes; and

(2)the means used for the notification;

(d)the change management procedure includes a change identification procedure; this procedure should seek out potential changes, confirm that there is a real intent to implement them and, if so, initiate the notification process; and

(e)as part of the change management procedure, they keep a register of the records of all notified changes, including:

(1)the status of the implementation of the change;

(2)the notification;

(3)a link to the location of the actual record, including a reference to all information passed on to the competent authority; and

(4)the review decision from the competent authority and the records of the change approval, when the changes are selected for review.

MANAGEMENT SYSTEM — CHANGE MANAGEMENT PROCEDURE

(a)The applicant should seek prior approval by the competent authority for any changes that affect the scope of its certificate or the terms of approval of its service.

(b)The applicant should:

(1)notify the competent authority before any such changes are implemented; and

(2)provide the competent authority with any relevant documentation.

(c)Changes that require prior approval may only be implemented upon receipt of the formal approval by the competent authority.

(d)The applicant should operate under the conditions prescribed by the competent authority during the implementation of such changes, as applicable.

(e)In order for an applicant to implement changes without prior approval, it should submit a procedure and obtain approval for it by the competent authority, defining the scope of such changes and describing how such changes will be managed and notified.

MANAGEMENT SYSTEM — CONTRACTED ACTIVITIES The applicant should ensure that:

(a)a contract exists with the contracted organisation that defines clearly the contracted activities and the applicable requirements;

(b)the contracted activities, performed by an organisation that is not itself certified in accordance with Regulation (EU) 2021/664 to carry out such activities, are included in its oversight process;

(c)when the contracted organisation is itself certified in accordance with Regulation (EU) 2021/664 to carry out the contracted activities, its compliance monitoring should at least check that the approval effectively covers the contracted activities and that it is still valid; and

(d)when not certified to provide the service / carry out the activities itself, it should only contract or purchase the services from a certified organisation when so required by Regulation (EU) 2021/664.

MANAGEMENT SYSTEM — RECORD-KEEPING — GENERAL The applicant should ensure that:

(a)all records are accessible whenever needed; the records should be organised in a way that ensures traceability and retrieval throughout their retention period;

(b)records are kept in paper or in electronic format, or a combination of the two, and should remain legible throughout the required retention period;

(c)paper record-keeping systems use robust material which can withstand normal handling and filing;

(d)computer record-keeping systems have at least one backup system which should be updated within 24 hours of any new entry made; computer record-keeping systems should include safeguards against the probability of unauthorised personnel altering the data;

(e)all computer hardware used to ensure data backup is stored in a different location from that containing the working data and in an environment that ensures it remains in a good condition; and

(f)the records are kept for a minimum period of 5 years unless otherwise specified by the competent authority.

MANAGEMENT SYSTEM — OPERATIONS MANUAL The applicant should ensure that the operations manual contains the instructions and information required for the intended operation. The operations manual should:

(a)be signed by the accountable manager;

(b)be printed or available in electronic format and is easy to revise;

(c)have a system for version control management; and

(d)include a description of its amendment and revision process specifying:

(1)the person(s) who may approve amendments or revisions;

(2)the conditions for temporary revisions and/or immediate amendments, or revisions required in the interest of safety; and

(3)the methods and means by which all personnel and organisations are advised on changes to the operations manual.

MANAGEMENT SYSTEM — ISO CERTIFICATE An ISO 9001 certificate covers the quality management elements of the management system. Other elements required, which are not covered by the ISO 9001 certificate issued by an appropriately accredited organisation, should be subject to complementary evaluation by the competent authority.

MANAGEMENT SYSTEM — SAFETY PERFORMANCE MONITORING AND MEASUREMENT Safety performance monitoring and measurement is the process by which the safety performance is verified in relation to the safety policy and the safety objectives established by the applicant. A performance indicator (PI) is a type of performance measurement. An organisation may use PIs to evaluate its success, or to evaluate the success of a particular activity in which it is engaged. Sometimes success is defined in terms of making progress towards strategic goals, but often success is simply the repeated, periodic achievement of some level of operational goal (e.g. zero defects). Accordingly, choosing the right PIs relies upon a good understanding of what is important to the organisation. Since there is a need to ensure a relevant assessment, various techniques to assess the present state of the business, and its key activities, are associated with the selection of appropriate PIs. These assessments often lead to the identification of potential improvements, so PIs are routinely associated with performance improvement initiatives. When PIs have performance targets associated with them, they are known as key performance indicators (KPIs).

MANAGEMENT SYSTEM — SAFETY ASSESSMENT

(a)A safety assessment is conducted when an applicant initiates the process to be issued with a certificate, and when a change affects a part of the functional system used in the provision of its services.

(b)The safety assessment is usually conducted by the applicant itself. It may also be conducted by another organisation, on its behalf, provided the responsibility with regard to the acceptability of the outcome remains with the applicant.

MANAGEMENT SYSTEM — COMPLIANCE MONITORING

(a)Compliance monitoring is performed by the compliance monitoring manager who should ensure that the activities of the organisation are monitored for compliance with the applicable regulatory requirements, and that these activities are carried out properly under the supervision of other relevant nominated postholders and line managers.

(b)The compliance monitoring manager is responsible for ensuring that the compliance monitoring programme is properly implemented, maintained, and continually reviewed and improved; to that end, they should be able to demonstrate relevant knowledge of the U-space framework and experience in the services provided, as well as in compliance monitoring.

(c)The compliance monitoring manager may perform all audits and inspections themselves or appoint one or more auditors by choosing personnel that have the related competencies, either from within or outside the service provider. Regardless of the option chosen, the independence of the audit function should not be affected in the case where those that perform the audit or inspection are also responsible for other activities within the organisation.

(d)In the case where compliance audits and inspection tasks are assigned to external personnel, compliance monitoring is performed under the responsibility of the compliance monitoring manager who remains responsible for ensuring that the external personnel have the relevant knowledge, background and experience as appropriate to the activities being audited or inspected, including knowledge of and experience in compliance monitoring.

(e)The organisation retains the ultimate responsibility for the effectiveness of the compliance monitoring function, as well as for the effective implementation of and follow-up to all corrective actions.

MANAGEMENT SYSTEM — CONTRACTED ACTIVITIES

(a)‘Contracted activities’ means those activities within the service provision conditions attached to the certificate that are performed by other organisations either themselves certified to perform such activities or, if not certified, working under the service provider’s oversight. The scope of the oversight covers the contracted activities performed by the external organisation that is not itself certified in accordance with Regulation (EU) 2021/664.

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

(c)To ensure that the contracted organisation can perform the contracted activities, the applicant should first audit the contracted party. For the purpose of verifying the suitability of contracted organisations, the applicant may refer to appropriate consensus-based industry standards and possible related industry-awarded certifications.

(d)The ultimate responsibility for the services provided by contracted organisations always remains with the contracting organisation.

MANAGEMENT SYSTEM — OPERATIONS MANUAL

(a)The operations manual is a key document for the applicant as well as for the competent authority. It describes how the infrastructure, facilities, and operational procedures will perform safely.

(b)The principal objective of an operations manual is to show how management will fulfil its safety responsibilities. It sets out the policy and expected standards of performance, and the procedures by which they will be achieved.

(c)The competent authority expects the operations manual to be an accurate reflection of the dayto-day functioning of the management system. It shows how the organisation intends to measure its performance against safety targets and objectives. The operations manual should give a clear statement of how safety is developed, managed, and maintained. All safety policies, operational procedures and instructions should be described.

(d)For many small organisations, the operations manual may be both simple and brief if it covers procedures that are essential for the satisfactory performance of day-to-day operations.

(e)The operations manual is one of the means by which all relevant operating staff can be informed about their duties and responsibilities with regard to safety. It describes the infrastructure, services and facilities, all operating procedures, and any restrictions on service availability.

(f)The operations manual describes how the safety of operations is to be managed. There should never be any doubt in terms of safety accountability for each domain or activity described. It defines who is accountable, who is responsible, who has the authority, who has the expertise, and who performs the tasks described.

(g)The operations manual may vary in detail according to the complexity of the operation, and the type of services provided. It may be presented in any form, including electronic form. In all cases, its accessibility, usability, and reliability should be assured.

SECURITY MANAGEMENT SYSTEM Regarding the security management requirements, reference is made to point ATM/ANS.OR.A.D.010 of Subpart D of Annex III to Regulation (EU) 2017/373. Nevertheless, it has to be noted that Opinion No 03/2021 ‘Management of information security risks’ proposes amendments to both Subpart B and D of Annex III to Regulation (EU) 2017/373. Therefore, once the related regulation is published, the provisions as regards the management of information security risks (Part-IS) will be applicable to the applicant.

INFORMATION SECURITY THREAT A threat to information security may be any circumstance or event with the (accidental, casual or purposeful, intentional or unintentional, mistaken) potential to adversely impact the operation and the functional systems and/or constituents, which results from unauthorised access, use, disclosure, denial, disruption, modification, or destruction of information and/or information system interfaces. This includes usual cyber-related threats (e.g. malware), including those that could come from external systems, but does not include physical threats.

RETENTION OF OPERATIONAL DATA AND INFORMATION

(a)The applicant should retain operational data and information, as applicable, which consists, as a minimum, of the following:

(1)exchange with the UAS operators on UAS flight authorisation request acceptance/rejection;

(2)requested and granted/rejected UAS flight authorisations;

(3)traffic information, as well as conformance monitoring information, provided to UAS operators;

(4)coordination exchange with ATC units and among USSPs;

(5)flown trajectory by the UAS operators; and

(6)status and level of service of the infrastructure used for the provision of the service.

(b)The retention of operational data and information should ensure that all records are accessible whenever needed, and in particular when so required by the competent authority, subject to privacy requirements. The records should be organised in a way that ensures operational data and information traceability and retrieval throughout the retention period.

BUSINESS PLAN

(a)The applicant should present a robust business plan that shows that the service provision costs can be covered with the prices that can be achieved on the market.

(b)The business plan should cover:

(1)market analysis;

(2)information on the implementation of new infrastructure or other developments, and a statement on how they will contribute to improving the performance of their services, including level and quality of services;

(3)the expected short-term financial position and any changes to or impacts on the business plan; and

(4)planning showing how the business will be financially sustainable.

BUSINESS PLAN — SERVICE CONTINUITY The business plan is required to show that an applicant is financially able to ensure the provision of services but not necessarily that it will provide such services. Indeed, it is recognised that due to certain operational circumstances (e.g. winter conditions) under which UAS operators would not make use of the U-space services for a certain period of time, the capability of providing services in a continuous manner for a period of 12 months from the start of operations might not be possible. Therefore, the applicant is expected to ensure that its services are available for 12 months in a continuous manner even if it would not necessarily provide the services during the 12-month period.

LIABILITY COVER — INSURANCE The method employed to provide the insurance cover should be appropriate to the potential loss and damage in question, taking into account the level of commercial insurance cover available.

CONTINGENCY PLAN The contingency plan should include the definition and specification of the measures, the coordination with other actors, and the alternative services needed in case of degradation or interruption of the Uspace services or the CIS.

EMERGENCY MANAGEMENT PLAN — USSPs

(a)USSPs should develop and maintain an emergency response plan (ERP) that ensures:

(1)an orderly and safe transition from normal to emergency operations;

(2)the safe continuation of operations, return to normal operations as soon as practicable, and the modification or cancellation of some or all the operations; and

(3)coordination with the ERPs of other organisations, where appropriate.

(b)The ERP should determine the actions to be taken by USSPs and reflect the nature and complexity of the activities performed by them.

(c)USSPs should ensure that communication systems:

(1)are established to provide rapid response of the emergency equipment to accidents and incidents; and

(2)are tested regularly to verify their operability.

(d)A complete and current list of telephone numbers should be available to all authorities and to personnel responsible for the ERP, to ensure the rapid notification of all those concerned in case of emergency.