The representatives of the Union within the Joint Committee may agree to technical guidelines to ensure the proper implementation of the Agreement including technical or other matters necessary for the operation of the linking and taking into account the priorities of domestic legislation. To this end, a working group shall be set up pursuant to Article 12(5) of the Agreement that shall assist the Joint Committee in its functions pursuant to Article 13 and in particular Article 13(1) of the Agreement.

Minor changes to the draft Decision may be agreed to by the representatives of the Union within the Joint Committee without a further decision of the Council.

The position to be taken on the Union's behalf in the third meeting of the Joint Committee established by the Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems as regards the adoption of Common Operational Procedures, shall be based on the draft act of the Joint Committee attached to this Decision.

(6)In accordance with Article 13(1) of the Agreement, the Joint Committee may agree on technical guidelines to ensure the proper implementation of the Agreement including technical or other matters necessary for the operation of the linking and taking into account the priorities of domestic legislation. The technical guidelines should be developed by a working group set up pursuant to Article 12(5) of the Agreement. The working group should at least include the Swiss Registry administrator and the Union Registry central administrator and should furthermore assist the Joint Committee in its functions pursuant to Article 13 of the Agreement,

(5)Adoption of the COP represents an important element relating to the implementation of the Agreement, as it determines the operational procedures for the link to work and which both sides have to follow.

(4)It is appropriate to establish the position to be taken on the Union's behalf in the Joint Committee, as the COP will be binding on the Union.

(3)The Joint Committee, during its third meeting, to be held in 2020, is to adopt the developed Common Operational Procedures.

(2)Pursuant to Article 3(6) of the Agreement, the Joint Committee may adopt a decision on Common Operational Procedures (COP) developed by the Swiss registry administrator and the Union central administrator that are related to technical and other matters necessary for the operation of the linking, taking into account the priorities of domestic legislation. The COP are then to take effect following their adoption by decision of the Joint Committee.

(1)The Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems (‘the Agreement’) was concluded by the Union by Council Decision (EU) 2018/219 and entered into force on 1 January 2020.

Having regard to the proposal from the European Commission,

Having regard to the Treaty on the Functioning of the European Union, and in particular Article 192(1), in conjunction with Article 218(9) thereof,

on the position to be taken on behalf of the European Union in the Joint Committee established by the Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems as regards the adoption of Common Operational Procedures

The legal basis of the proposed decision should be Article 192(1) TFEU, in conjunction with Article 218(9) TFEU.

Therefore, the substantive legal basis of the proposed decision is Article 192(1) TFEU.

The main objective and content of the envisaged act relate to environment.

The substantive legal basis for a decision under Article 218(9) TFEU depends primarily on the objective and content of the envisaged act in respect of which a position is taken on the Union's behalf. If the envisaged act pursues two aims or has two components and if one of those aims or components is identifiable as the main one, whereas the other is merely incidental, the decision under Article 218(9) TFEU must be founded on a single substantive legal basis, namely that required by the main or predominant aim or component.

Therefore, the procedural legal basis for the proposed decision is Article 218(9) TFEU.

The envisaged act does not supplement or amend the institutional framework of the Agreement.

The act, which the Joint Committee is called upon to adopt, constitutes an act having legal effects. The envisaged act will be binding under international law in accordance with Article 12(3) of the Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems.

The Joint Committee is a body set up pursuant to Article 12 of the Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems.

The concept of ‘acts having legal effects’ includes acts that have legal effects by virtue of the rules of international law governing the body in question. It also includes instruments that do not have a binding effect under international law, but that are ‘capable of decisively influencing the content of the legislation adopted by the EU legislature’.

Article 218(9) of the Treaty on the Functioning of the European Union (TFEU) provides for decisions establishing ‘the positions to be adopted on the Union’s behalf in a body set up by an agreement, when that body is called upon to adopt acts having legal effects, with the exception of acts supplementing or amending the institutional framework of the agreement.’

The development of a well-functioning international carbon market through bottom-up linking of emissions trading systems is a long-term policy goal of the EU and the international community, notably as a means to achieve the climate objectives of the Paris Agreement. In this respect, Article 25 of the Directive establishing the EU's Emissions Trading System (EU ETS) allows for the EU ETS to be linked with other emissions trading systems provided they are mandatory, have an absolute cap on emissions and are compatible, as it is the case with the Swiss system. Following the entry into force of the Agreement on 1 January 2020, the COP taking effect represents an important step towards the implementation of the Agreement.

In accordance with Decision No 2/2019 of the Joint Committee of 5 December 2019, the COP relate to a provisional solution for operationalising the link between the EU ETS and the ETS of Switzerland. The provisional solution should be available as from May 2020 or as soon as possible thereafter.

Article 3(6) of the Linking Agreement requires the development of Common Operational Procedures that will take effect following their adoption by the Joint Committee. The COP determine the operational procedures with which both sides have to comply to make the link between the EUTL the SSTL operational. For this reason, they are necessary for the link to work.

The Council Decision based on this proposal from the Commission determines the position of the European Union concerning the Decision of the Joint Committee to be taken on the adoption of Common Operational Procedures (COP) for the operation of the link between the EUTL and the SSTL.

3.Position to be taken on the Union's behalf

The envisaged act will become binding on the parties in accordance with Article 3(6) of the Agreement, which requires that the COP will take effect when adopted by decision of the Joint Committee. In accordance with Article 12(3) of the Agreement, decisions taken by the Joint Committee in the cases provided for in this Agreement will, upon their entry into force, be binding on the Parties.

The purpose of the envisaged act is to determine operational procedures to be applied by both sides and relate to technical and other matters necessary for the operation of the link between the EUTL and the SSTL and taking into account the priorities of domestic legislation. To this end, it outlines procedural requirements in terms of operation. With a view to minimising the risk of fraud, misuse or criminal activities involving the registries and to protecting the integrity of the link, details of the necessary procedures as well as their underlying considerations and agreements, should be treated confidentially. Therefore, the envisaged act addresses the necessary elements at a rather high level without revealing procedures and information related to the security and safety of the link. Those should be laid down in further technical guidelines to be developed by a working group in accordance with Article 12(5) of the Agreement. The working group should at least include the Swiss registry administrator and the Union central administrator, both of which should ensure the continued, effective and efficient operation of the link as well as its adaptation to technical progress and new requirements relating to the safety and security of the link. Due to both the technical and sensitive nature of such guidelines and the need to adapt them to maintain an appropriate level of safety and security of the link, representatives of the Union in the Joint Committee should be informed and, where appropriate, able to agree such guidelines without a further decision of the Council.

During its third meeting, which will be held in 2020, the Joint Committee is to adopt a decision pursuant to Article 3(6) of the Agreement regarding the adoption of Common Operational Procedures (‘the envisaged act’).

Pursuant to Article 3(6) of the Agreement, the Swiss registry administrator and the Union central administrator shall determine common operational procedures (COP) related to technical or other matters necessary for the operation of the link between the European Union Transaction Log (EUTL) of the Union Registry and the Swiss Supplementary Transaction Log (SSTL) of the Swiss registry and taking into account the priorities of domestic legislation. The COP will take effect, when adopted by decision of the Joint Committee.

The Joint Committee is a bilateral body composed of representatives of the Parties (the EU and Switzerland). Decisions taken by the Joint Committee shall be agreed by both Parties.

The Joint Committee, established by Article 12 of the Agreement, is responsible for administering the Agreement and ensuring its implementation. It can decide to adopt new annexes to the Agreement or amend existing ones. It can also discuss amendments to the Articles of the Agreement, facilitate the exchange of views on the Parties' legislation and conduct reviews of the Agreement.

The Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems (‘the Agreement’) aims to connect the EU Emissions Trading System (EU ETS) with the Swiss one by allowing that allowances issued in one system can be traded and used for compliance in the other one, thus expanding the opportunities for climate change mitigation. The Agreement entered into force on 1 January 2020.

2.1.The Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems

This proposal concerns the decision establishing the position to be taken on the Union's behalf in the Joint Committee established by the Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems in connection with the envisaged adoption of a decision regarding the adoption of Common Operational Procedures.

on the position to be taken on behalf of the European Union in the Joint Committee established by the Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems as regards the adoption of Common Operational Procedures

EUROPEAN COMMISSION Brussels, 23.6.2020 COM(2020) 255 final ANNEX to the Proposal for a Council Decision on the position to be taken on behalf of the European Union in the Joint Committee established by the Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems as regards the adoption of Common Operational Procedures



DECISION No 1/2020 OF THE JOINT COMMITTEE ESTABLISHED BY THE AGREEMENT BETWEEN THE EUROPEAN UNION AND THE SWISS CONFEDERATION ON THE LINKING OF THEIR GREENHOUSE GAS EMISSIONS TRADING SYSTEMS

of …

on Common Operational Procedures (COP) THE JOINT COMMITTEE Having regard to the Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems (hereinafter ‘the Agreement’) and in particular Article 3 thereof, Whereas: (1)Decision No 2/2019 of the Joint Committee of 5 December 2019 amended Annexes I and II to the Agreement thus fulfilling the conditions for linking set out in the Agreement. (2)Following adoption of Decision No 2/2019 of the Joint Committee and pursuant to Article 21(3) of the Agreement, the Parties exchanged their instruments of ratification or approval, since they consider all conditions for linking as set out in the Agreement to have been fulfilled. (3)In accordance with Article 21(4) of the Agreement, the Agreement entered into force on 1 January 2020. (4)Pursuant to Article 3(6) of the Agreement, the Swiss registry administrator and the Union central administrator should determine common operational procedures (COP) related to technical or other matters necessary for the operation of the link between the European Union Transaction Log (EUTL) of the Union registry and the Swiss Supplementary Transaction Log (SSTL) of the Swiss registry and taking into account the priorities of domestic legislation. The COP should take effect when adopted by decision of the Joint Committee. (5)In accordance with Article 13(1) of the Agreement, the Joint Committee should agree on technical guidelines to ensure the proper implementation of the Agreement including on technical or other matters necessary for the operation of the linking and taking into account the priorities of domestic legislation. Technical guidelines may be developed by a working group set up pursuant to Article 12(5) of the Agreement. The working group should at least include the Swiss Registry administrator and the Union Registry central administrator and should assist the Joint Committee in its functions pursuant to Article 13 of the Agreement. (6)In view of the technical nature of the guidelines and the need to adapt them to ongoing developments, the technical guidelines developed by the Swiss registry administrator and the Union central administrator should be submitted to the Joint Committee for information or, where appropriate, approval, HAS ADOPTED THIS DECISION: Article 1 The Common Operational Procedures (COP), as annexed to this Decision, are hereby adopted. Article 2 Herewith, a working group shall be set up pursuant to Article 12(5) of the Agreement. It shall assist the Joint Committee to ensure the proper implementation of the Agreement including the development of technical guidelines for the implementation of the COP. The working group shall at least include the Swiss Registry administrator and the Union Registry central administrator. Article 3 This Decision shall enter into force on the date of its adoption. Done in English at Brussels, on XX 2020.

For the Joint Committee Secretary for the European Union The Chair Secretary for Switzerland



APPENDIX ANNEX COMMON OPERATIONAL PROCEDURES (COP) pursuant to Article 3(6) of the Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems

- Procedures for Provisional Solution - 1.Glossary Table 1-1 Acronyms and Definitions Acronym/Term Definition Certificate Authority (CA) Entity that issues digital certificates CH Swiss Confederation ETS Emissions Trading System EU European Union IMT Incident Management Team Information Asset A piece of information that is valuable to a company or organization IT Information Technology ITIL Information Technology Infrastructure Library ITSM IT Service Management LTS Linking Technical Standards Registry An accounting system for allowances issued under the ETS, which keeps track of the ownership of allowances held in electronic accounts. RFC Request For Change SIL Sensitive Information List SR Service Request Wiki Website that allows users to exchange information and knowledge by adding or adapting content directly via a web browser. 2.Introduction The Agreement between the European Union and the Swiss Confederation on the linking of their greenhouse gas emissions trading systems of 23 November 2017 (“Agreement”) provides for the mutual recognition of emission allowances that can be used for compliance under the Emissions Trading System of the European Union (“EU ETS”) or the Emissions Trading System of Switzerland (“ETS of Switzerland”). To operationalise the link between the EU ETS and the ETS of Switzerland, a direct link between the European Union Transaction Log (EUTL) of the Union Registry and the Swiss Supplementary Transaction Log (SSTL) of the Swiss registry shall be established, which will enable the registry-to-registry transfer of emission allowances issued under either ETS (Article 3(2) of the Agreement). To operationalise the link between the EU ETS and the ETS of Switzerland, a provisional solution shall be in place by May 2020 or as soon as possible thereafter. Parties shall cooperate to replace the provisional solution with a permanent registry link as soon as possible (Annex II of the Agreement). Pursuant to Article 3(6) of the Agreement, the Swiss registry administrator and the Union central administrator shall determine common operational procedures (COP) related to technical or other matters necessary for the operation of the linking and taking into account the priorities of domestic legislation. The COP developed by the administrators shall take effect when adopted by decision of the Joint Committee. The COP, as recorded in this document is to be adopted by the Joint Committee by its Decision No 1/2020. In accordance with this Decision, the Joint Committee shall request the Swiss registry administrator and the Union central administrator to develop further technical guidelines to operationalise the link and to ensure that these are continuously adapted to technical progress and new requirements relating to the safety and security of the link and to its effective and efficient operation. 2.1.Scope This document represents the common understanding between the Parties to the Agreement regarding the establishment of the procedural foundations of the link between the registries of the EU ETS and the ETS of Switzerland. While it outlines the overall procedural requirements in terms of operations, some further technical guidelines will be needed to operationalise the link. For the proper functioning, the link will require technical specifications in order to further operationalise the link. Pursuant to Article 3(7) of the Agreement, those matters are detailed in the Linking Technical Standards (LTS) document to be adopted separately by decision of the Joint Committee. The objective of the COP is to make sure that IT services related to the operation of the link between the registries of the EU ETS and the ETS of Switzerland are delivered effectively and efficiently, especially for the fulfilling of service requests, resolving service failures, fixing problems, as well as carrying out routine operational tasks according to international standards for IT service management. For the agreed provisional solution, only the following COP will be needed, which are part of this document:

·Incident Management ·Problem Management ·Request Fulfilment ·Change Management ·Release Management ·Security Incident Management ·Information Security Management With the deployment of the permanent registry link at a later date, the COP must be adapted and supplemented where necessary. 2.2.Addressees The target audience of these COP are the EU and Swiss registry support teams. 3.Approach and Standards The following principle applies to all COP: ·The EU and CH agree to define the COP on the basis of ITIL (Information Technology Infrastructure Library, version 3). Practices from this standard are reused and adapted to the specific needs related to the provisional solution. ·The communication and coordination necessary for the processing of the COP between the two Parties takes place via the Registry Service Desks of the CH and EU. Tasks are always assigned within one Party. ·If there is disagreement about the handling of a COP, this will be analysed and resolved between both Service Desks. If no agreement can be reached, the finding of a joint solution is escalated to the next level. ·Escalation levels ·EU ·CH ·1st level ·EU Service Desk ·CH Service Desk ·2nd level ·EU Operations Manager ·CH Registry Application Manager ·3rd level Joint Committee (which might delegate this responsibility considering Article 12(5) of the Agreement) ·4th level Joint Committee, if 3rd level is delegated ·Each Party can determine the procedures for the operation of its own registry system, taking into account the requirements and interfaces related to these COP. ·An IT Service Management (ITSM) tool is used to support the COP, in particular Incident Management, Problem Management and Request Fulfilment, and communication between both Parties. ·In addition, the exchange of information via e-mail is allowed. ·Both Parties ensure that the information security requirements are met in accordance with the Handling Instructions.

4.Incident management The objective of the Incident Management process is to return IT services to a normal service level as quickly as possible and with minimum disruption to the business. Incident Management should also keep a record of incidents for reporting purposes and integrate with other processes to drive continuous improvement. ·From a global perspective, Incident Management comprises the following activities: ·Incident detection and recording ·Classification and initial support ·Investigation and diagnosis ·Resolution and recovery ·Incident closure Throughout the lifecycle of an incident, the Incident Management process is responsible for the constant handling of the ownership, monitoring, tracking and communication. 4.1.Incident detection and recording An incident can be detected by a support group, by automated monitoring tools or by technical staff performing routine surveillance. Once detected, an incident must be recorded and assigned a unique identifier allowing for proper incident tracking and monitoring. The unique identifier of an incident is the identifier assigned in the common ticketing system by the Service Desk of the Party (either EU or CH) that raised the incident, and it has to be used in every communication related to this incident. For all incidents, the contact point should be the Service Desk of the Party that logged the ticket. 4.2.Classification and initial support The incident classification aims at understanding and identifying what system and/or service are affected, and to what degree. To be effective, the classification should route the incident to the correct resource on the first try, in order to speed up the incident resolution. The classification phase should categorize and prioritize the incident according to its impact and urgency, for it to be treated according to the priority relevant time frame. If the incident has a potential impact on the confidentiality or integrity of sensitive data, and/or an impact on the system availability, the incident shall be also declared as a security incident and then managed according to the process defined in the ‘Security Incident Management’ chapter of this document. If possible, the Service Desk that logged the ticket performs an initial diagnosis. For this, the Service Desk will see if the incident is a known error. If so, then the resolution path or workaround is already known and documented. If the Service Desk is successful in solving the incident, then it will actually close the incident at this point, as the primary purpose of Incident Management has been fulfilled (namely the fast restoration of service for the end user). If not, then the Service Desk will escalate the incident to the appropriate resolver group for further investigation and diagnosis.

4.3.Investigation and diagnosis Incident investigation and diagnosis is applied when an incident cannot be resolved by the Service Desk as part of the initial diagnosis, and is therefore escalated appropriately. Incident escalation is a full part of the investigation and diagnosis process. A common practice in the investigation and diagnosis phase is the attempt to recreate the incident under controlled conditions. It is important when performing incident investigation and diagnosis that the proper order of events that led up to the incident be understood. Escalation is the recognition that an incident cannot be resolved at the current support level, and must be passed to a higher level support group or to the other Party. Escalation can follow two paths: horizontal (functional) or vertical (hierarchical). The Service Desk that recorded and triggered the incident is responsible for escalating the incident to the appropriate resource and for tracking the overall status and assignment of the incident. The Party to which the incident has been assigned is responsible for ensuring the requested actions are performed in a timely fashion, and for providing feedback to the Service Desk of its own Party. 4.4.Resolution and recovery Incident resolution and recovery is performed once the incident is fully understood. Finding a resolution to an incident means that a way of rectifying the issue has been identified. The act of applying the resolution is the recovery phase. Once the appropriate resources resolve the service failure, the incident is routed back to the relevant Service Desk, which logged the incident and confirms with the initiator of the incident that the error has been rectified and that the incident can be closed. Findings from the processing of the incident are to be recorded for future use. Recovery can be performed by IT support staff or by providing the end user with a set of instructions to follow. 4.5.Incident closure Closure is the final step in the Incident Management process and takes place shortly after incident resolution. Amongst the checklist of activities that need to be performed during the closure phase, the following is highlighted: ·The verification of the initial categorization that was assigned to the incident; ·The proper capture of all information surrounding the incident; ·The proper documentation of the incident and update of the knowledge base; ·The adequate communication to every stakeholder directly or indirectly affected by the incident. An incident is formally closed once the incident closure phase has been executed by the Service Desk and communicated to the other Party. Once an incident is closed, it is not reopened. If an incident re-occurs within a short time period then, the original incident is not re-opened, a new incident must be logged instead. If the incident is tracked by both the EU and CH Service Desks, the final closure is the responsibility of the Service Desk that logged the ticket.

5.Problem Management This procedure should be followed whenever a problem is identified and therefore triggers the Problem Management process. The Problem Management focuses on enhancing quality and reducing the volume of raised incidents. A problem can be the cause of one or more incidents. When an incident is reported, the objective of the Incident Management is to restore the service as quickly as possible, possibly involving workarounds. When a problem is created, the objective is to investigate the root cause of the issue in order to identify a change that will ensure the problem and related incidents will not occur anymore. 5.1.Problem identification an recording Depending on which Party initiated the ticket, either the EU or CH Service Desk will be the contact point for problem related matters. The unique identifier of a problem is the identifier assigned by the IT Service Management (ITSM). It has to be used in every communication related to this problem. A problem can be triggered by an incident or can be opened as self-initiative act to fix issues discovered in the system at any phase. 5.2.Problem Prioritization Problems may be categorized according to their severity and priority in the same way as incidents in order to facilitate their tracking, taking the impact of the associated incidents and their frequency of occurrence into account. 5.3.Problem investigation and diagnosis Each Party can raise a problem and the Service Desk of the initiating Party will be responsible for logging the problem, assigning it to the appropriate resource and tracking the overall status. The resolver group whom the problem was escalated to is responsible for handling the problem in a timely fashion and communicating with the Service Desk. Upon request, both Parties are responsible for ensuring the assigned actions are performed, and for providing feedback to the Service Desk of its own Party. 5.4.Resolution The resolver group to whom the problem is assigned is responsible for resolving the problem and providing relevant information to the Service Desk of its own Party. Findings from the processing of the problem are to be recorded for future use. 5.5.Problem closure A problem is formally closed once the problem is fixed by implementing the change. The problem closure phase will be carried out by the Service Desk that logged the problem and informed the Service Desk of the other Party. 6.Request Fulfilment The Request Fulfilment Process is the end-to-end management of a request for a new or existing service from the moment it is registered and approved through to closure. Service Requests are usually small, predefined, repeatable, frequent, pre-approved, and procedural requests. The main steps that have to be followed are outlined below:

6.1.Initiate Request The information related to a Service Request is submitted to the EU or CH Service Desk by email, phone, or through the IT Service Management (ITSM) tool or any other agreed channel of communication. 6.2.Request Logging and Analysis For all Service Requests, the contact point should be the EU or CH Service Desk, depending on which Party raised the Service Request. This Service Desk will be responsible for logging and analysing the Service Request with the appropriate diligence. 6.3.Request Approval The Service Desk Agent of the Party that raised the Service Request checks if any approvals are required from the other Party and if so proceed to obtaining them. If the Service Request is not approved, the Service Desk updates and closes the ticket. 6.4.Request fulfilment This step caters for the effective and efficient handling of the Service Requests. A distinction must be made between the following cases: ·The fulfilment of the Service Request only affects one Party. In this case, this Party issues the work orders and coordinates the execution. ·The implementation of the Service Request affects both the EU and CH. In this case, the Service Desks issue the work orders in their area of responsibility. The processing of the Service Request fulfilment is coordinated between both Service Desks. The overall responsibility lies with the Service Desk that received and initiated the Service Request. When the Service Request has been resolved, it must be placed into Resolved State. 6.5.Request Escalation The Service Desk can escalate the outstanding Service Request to the appropriate resource (third Party) if needed. Escalations are done to the respective third Parties, i.e. the EU Service Desk will have to go through the CH Service Desk for escalation to a CH third Party, and vice versa. The third Party whom the Service Request was escalated to is responsible for handling the Service Request in a timely fashion and communicating with the Service Desk who escalated the Service Request. The Service Desk that logged the Service Request is responsible for tracking the overall status and assignment of a Service Request. 6.6.Request Fulfilment Review The responsible Service Desk submits the Service Request Record to a final quality control before it is closed. The aim is to make sure that the Service Request is actually processed and that all information required to describe the request's life-cycle is supplied in sufficient detail. In addition to this, findings from the processing of the request are to be recorded for future use. 6.7.Request Closure If the assigned Parties agree that the Service Request has been fulfilled and the requestor considers the case resolved, the next status to be set is “Closed”.

A Service Request is formally closed once the Service Desk that logged the Service Request has executed the request closure phase and informed the Service Desk of the other Party. 7.Change Management The objective is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to control IT infrastructure, in order to minimize the number and impact of any related incidents upon service. Changes in the IT infrastructure may arise reactively in response to problems or externally imposed requirements, e.g. legislative changes, or proactively from seeking improved efficiency and effectiveness or to enable or reflect business initiatives. The Change Management process includes different steps that capture every detail about a Change Request for future tracking. These processes ensure that the change is validated and tested before it moves to deployment. Release Management process is responsible for successful deployment. 7.1.Request for Change A Request For Change (RFC) is submitted to the Change Management team for validation and approval. For all Change Requests, the contact point should be the EU or CH Service Desk, depending on which Party raised the request. This Service Desk will be responsible for logging and analysing the request with the appropriate diligence. Change Requests may originate from: ·An incident that causes a change; ·An existing problem that results in a change; ·An end user requesting for a new change; ·Change as a result of an ongoing maintenance; ·Legislative change. 7.2.Change Evaluation and Planning This stage handles change assessment and planning activities. It includes prioritization and planning activities to minimize risk and impact. If the implementation of the RFC affects both the EU and CH, the Party that logged the RFC verifies the change evaluation and planning with the other Party. 7.3.Change approvals Any registered change request needs to be approved by the relevant escalation level. 7.4.Change implementation Change implementation is handled in the Release Management. The Release Management teams of both Parties follow their own processes that involve planning and testing. Change review happens once the implementation is completed. To ensure that everything has gone according to the plan the existing Change Management process is constantly reviewed and updated wherever necessary. 8.Release Management

A release represents one or more changes to an IT service, collected in a release plan that will have to be authorized, prepared, built, tested, and deployed together. A single release may represent a bug fix, a change to hardware or other components, changes to software, upgrades of application versions, changes to documentation and/or processes. The contents of each release are managed, tested and deployed as a single entity. Release Management aims to plan, build, test and validate, and deliver capability to provide the designed services, which will accomplish the stakeholders’ requirements and deliver the intended objectives. Acceptance criteria for all changes to the service will be defined and documented during design coordination and provided to Release Management teams. The release will typically consist of a number of problem fixes and enhancements to a service. It contains the new or changed software required and any new or changed hardware needed to implement the approved changes. 8.1.Plan the release The first step of the process assigns authorized changes to release packages and defines the scope and content of releases. Based on this information, the Release Planning sub-process develops a schedule for building, testing and deploying the release. Planning should define: ·Scope and content of the release; ·Risk assessment and risk profile for the release; ·Customer/users affected by the release; ·Team responsible for the release; ·Delivery and deployment strategy; ·Resources for the release and deployment. Both Parties inform each other about their release planning and maintenance windows. If a release affects both the EU and CH, they coordinate the planning and define a common maintenance window. 8.2.Build and Test Release Package The build and test step of the Release Management process establishes the approach of executing the release or release package and of maintaining the controlled environments prior to changing production, as well as testing all changes in all environments released. If a release affects both the EU and CH, they coordinate the delivery plans and tests. This includes the following aspects: ·How and when release units and service components will be delivered; ·What the typical lead times are; what happens if there is a delay; ·How to track the progress of the delivery and obtain confirmation; ·Metrics for monitoring and determining the success of the release deployment effort;

·Common test cases for relevant functionalities and changes. At the end of this sub-process, all required release components are ready to enter the live deployment phase. 8.3.Prepare deployment The preparation sub-process ensures that communication plans are defined correctly and notifications are ready to be sent to all stakeholders and end users impacted, and that the release is integrated with the Change Management process to ensure that all changes are performed in a controlled manner and approved by the required forums. If a release affects both the EU and CH, they shall coordinate the following activities: ·Change Request record for scheduling and preparing deployment to Production environment; ·Create implementation plan; ·Rollback approach, so that, in case of deployment failure, the previous state can be placed back; ·Notifications sent to all necessary Parties; ·Require approval for the implementation of the release from the relevant escalation level. 8.4.Roll back the release In case deployment has failed or testing has identified that deployment was unsuccessful or has not met the agreed acceptance/quality criteria, the Release Management teams of both Parties will need to roll back to the previous state. All necessary stakeholders will need to be informed, including impacted/targeted end users. Pending approval, the process can restart at any of the previous stages. 8.5.Review and close release When reviewing a deployment, the following activities should be included: ·Capture feedback on customer, user and service delivery satisfaction with the deployment (collect the feedback and consider for continuously improving the service); ·Review any quality criteria that were not met; ·Check that any actions, necessary fixes and changes are complete; ·Make sure there are no capability, resource, capacity or performance issues at the end of the deployment; ·Check that any problems, known errors and workarounds are documented and accepted by the customer, end users, operational support, and other Parties impacted; ·Monitor incidents and problems caused by the deployment (provide early life support to operational teams in case the release has caused an increase in volumes of work);

·Update the support documentation (i.e. technical information documents); ·Formally hand over the release deployment to service operations; ·Document lessons learnt; ·Collect the release summary document from implementation teams; ·Formally close the release after verifying the Change Request record. 9.Security Incident Management Security Incident Management is a process for handling security incidents in order to enable incident communication to potentially impacted stakeholders; incident evaluation and prioritisation; and incident response to settle any actual, suspected or potential breach of confidentiality, availability or integrity of sensitive information assets. 9.1.Information Security Incident Categorization All incidents impacting the link between the Union Registry and the Swiss registry shall be analysed to determine possible breach in the confidentiality, the integrity or the availability of any sensitive information recorded in the Sensitive Information List (SIL). If so, the incident shall be characterized as an information security incident, immediately registered in the IT Service Management (ITSM) tool and managed as such. 9.2.Information Security Incident Handling Security Incidents are placed under the responsibility of the 3rd escalation level and resolution of the incidents will be dealt with by a dedicated Incident Management Team (IMT). The IMT is responsible for: ·Carrying out a first analysis, categorize and rate the severity of the incident; ·Coordinating actions between all the stakeholders including the full documentation of the incident analysis, the decisions taken to tackle the incident and the possible identified weaknesses; ·Depending on security incident severity, escalate timely to the appropriate level for information and/or decision. In the Information Security Management process, all information regarding incidents is classified at the highest level of sensitivity of the information, but in any case not lower than ETS SENSITIVE. For an on-going investigation and/or a weakness that could be exploited and until its remediation, the information is classified as ETS CRITICAL. 9.3.Security Incident Identification Based on the security event type, the information security officer determines appropriate organizations to be involved and to be part of the IMT.

9.4.Security Incident Analysis The IMT liaises with all involved organizations and the relevant members of their teams, as appropriate, to review the incident. During the analysis, the extent of an asset’s confidentiality, integrity or availability loss is identified and consequences for all affected organizations are assessed. Next, initial and follow-up actions to resolve the incident and manage its impact, including the resource impact of these actions, are defined. 9.5.Security Incident Severity assessment, Escalation and Reporting The IMT shall assess the severity of any new security incident after their characterization and starts immediate required action according to the severity of the incident. 9.6.Security Response Reporting The IMT includes incident containment and recovery results in the information security incident response report. The report is provided to the 3rd escalation level using secure email or other mutually accepted means of secure communication. The responsible Party reviews the containment and recovery results and: ·Reconnects the registry in case of the prior disconnection; ·Provides incident communications to the registry teams; ·Closes the incident. The IMT should include – in a secure manner - relevant details in the information security incident report in order to ensure consistent recording and communication and to enable a prompt and appropriate action to contain the incident. Following its completion, the IMT provides the information security incident final report in due time. 9.7.Monitoring, Capacity Building and Continuous Improvement The IMT will provide reports for all security incidents to the 3rd escalation level. The reports will be used by this escalation level to determine the following: ·Weak points in security controls and or the operation that need to be strengthened; ·Possible needs to enhance this procedure to improve its effectiveness of the response to incidents; ·Training and capacity building opportunities to further strengthen information security resilience of registry systems, reduce the risk of future incidents and minimize their impact. 10.Information Security Management Information Security Management aims to ensure the confidentiality, integrity and availability of an organization's classified information, data and IT services. In addition to the technical components including their design and testing (see LTS), the following common operational procedures are necessary to fulfil the security requirements for the provisional solution. 10.1.Sensitive information identification The sensitivity of an information is assessed by determining the level of Impact on the Business (e.g. financial losses, image degradation, law infringement…) of a security breach related to this information could have.

The sensitive information assets shall be identified on the basis of their impact on the linking. The level of sensitivity of this information shall be assessed according to the sensitivity scale applicable for this linking and detailed in the ‘Information Security Incident Handling’ section of this document. 10.2.Sensitivity levels of Information Assets Upon its identification, the information asset is classified by applying the following rules: ·The identification of at least a single HIGH confidentiality, integrity or availability level classifies the asset as ETS CRITICAL; ·The identification of at least a single MEDIUM confidentiality, integrity or availability level classifies the asset as ETS SENSITIVE; ·The identification of only LOW confidentiality, integrity or availability levels classifies the asset as ETS LIMITED. 10.3.Assignment of Information Assets Owner All information assets should have an assigned owner. Information assets of the ETS, belonging to or in conjunction with the link between the EUTL and the SSTL should be included in a joint asset inventory list, maintained by both Parties. Information assets of the ETS outside the link between the EUTL and the SSTL should be included in an asset inventory list, maintained by the respective Party. Ownership of each information asset belonging to or in conjunction with the link between the EUTL and the SSTL is to be agreed to by the Parties. The owner of an information asset is responsible for assessing its sensitivity. The owner should have seniority appropriate for the value of the assigned asset(s). The owner’s responsibility for the asset(s) and obligation for maintaining the required confidentiality, integrity and availability level should be agreed and formalized. 10.4.Registration of sensitive Information All sensitive information shall be registered in the Sensitive Information List (SIL). Where relevant, the aggregation of sensitive information that could lead to a higher impact than the impact of one single information shall be taken into account and registered in the SIL (e.g. set of information stored in the system database). The SIL is not static. Threats, vulnerabilities, likelihood or consequences of security incidents related to the assets may change without any indication and new assets might be introduced into the operation of registry systems. Therefore, the SIL shall be reviewed regularly and any new information identified as sensitive shall be immediately registered into the SIL. The SIL shall contain at least the following information for each entry: ·Description of the information ·Information owner ·Sensitivity level