Europaudvalget 2024
KOM (2024) 0125
Offentligt
2841386_0001.png
EUROPA-
KOMMISSIONEN
Bruxelles, den 20.3.2024
COM(2024) 125 final
ANNEX
BILAG
til
Forslag til Rådets afgørelse
om den holdning, der skal indtages på Den Europæiske Unions vegne i det fælles udvalg,
der er nedsat ved aftalen mellem Den Europæiske Union og Det Schweiziske Forbund
om sammenkobling af deres systemer for handel med drivhusgasemissioner, for så vidt
angår ændring af bilag II til aftalen, fælles driftsprocedurer og tekniske standarder for
sammenkobling
DA
DA
 kom (2024) 0125 - Ingen titel
2841386_0002.png
AFGØRELSE NR. 1/2024 TRUFFET AF DET FÆLLES UDVALG, DER ER NEDSAT
VED SAMARBEJDSAFTALEN MELLEM DEN EUROPÆISKE UNION OG DET
SCHWEIZISKE FORBUND OM SAMMENKOBLING AF DERES SYSTEMER FOR
HANDEL MED DRIVHUSGASEMISSIONER
af …
for så vidt angår ændring af bilag II til aftalen, de fælles driftsprocedurer og de tekniske
standarder for sammenkobling
DET FÆLLES UDVALG HAR —
under henvisning til aftalen mellem Den Europæiske Union og Det Schweiziske Forbund om
sammenkobling af deres systemer for handel med drivhusgasemissioner
1
(herefter "aftalen"),
særlig artikel 9 og artikel 13, stk. 2, og
ud fra følgende betragtninger:
(1)
(2)
Det fælles udvalgs afgørelse nr. 2/2019
2
indeholdt en foreløbig løsning med henblik på
at gøre sammenkoblingen mellem EU ETS og Schweiz' ETS operationel.
På sit tredje møde nåede det fælles udvalg til enighed om behovet for at analysere
omkostningseffektiviteten af en permanent forbindelse mellem EU-registret og
Schweiz' register.
På sit 5. møde nåede det fælles udvalg til enighed om rapporten fra den arbejdsgruppe,
der blev nedsat ved det fælles udvalgs afgørelse 1/2020
3
og 2/2020
4
, og hvori denne
arbejdsgruppe analyserede og anbefalede en tilgang for at gennemføre den permanente
forbindelse mellem EU-registret og Schweiz' register.
For at afspejle de tekniske krav til den permanente forbindelse mellem EU-registret og
Schweiz' register og for at strømline bestemmelserne i bilag II til aftalen i lyset af den
teknologiske udvikling bør bilag II til aftalen ændres.
For at sikre sammenhæng mellem de fælles driftsprocedurer og de tekniske standarder
for sammenkobling og bilag II bør de pågældende dokumenter også ændres —
(3)
(4)
(5)
VEDTAGET DENNE AFGØRELSE:
Artikel 1
1.
2.
3.
Bilag II til aftalen erstattes af teksten i bilag I til denne afgørelse.
De fælles driftsprocedurer, der er omhandlet i aftalens artikel 3, stk. 6, er fastlagt i
bilag II til denne afgørelse.
De tekniske standarder for sammenkobling, der er omhandlet i aftalens artikel 3,
stk. 7, er fastsat i bilag III til denne afgørelse.
Artikel 2
Denne afgørelse træder i kraft på dagen for vedtagelsen.
Udfærdiget på engelsk i [Bruxelles][Bern], den [XX 2024].
1
2
3
4
EUT L 322 af 7.12.2017, s. 3.
EUT L 314 af 29.9.2020, s. 68.
EUT L 226 af 25.6.2021, s. 2.
EUT L 226 af 25.6.2021, s. 16.
DA
1
DA
 kom (2024) 0125 - Ingen titel
På det fælles udvalgs vegne
Sekretær for Den Europæiske Union
Formand
Sekretær for Schweiz
DA
2
DA
 kom (2024) 0125 - Ingen titel
BILAG I
DA
3
DA
 kom (2024) 0125 - Ingen titel
2841386_0005.png
"BILAG II
TEKNISKE STANDARDER FOR SAMMENKOBLING
For at gennemføre sammenkoblingen af EU ETS og Schweiz' ETS blev der gennemført en foreløbig
løsning i maj 2020. Fra og med 2023 vil registerforbindelsen mellem de to ETS'er gradvis blive
udviklet hen imod en permanent registerforbindelse, der forventes at blive gennemført senest i 2024,
og som gør det muligt for de forbundne markeder at fungere, for så vidt angår fordelene ved
markedslikviditet og gennemførelse af transaktioner mellem de to forbundne systemer på en måde,
der svarer til et marked bestående af to systemer, og som gør det muligt for markedsdeltagerne at
handle, som om de befandt sig på ét marked, kun med det forbehold, at de er underlagt parternes
individuelle forskrifter. I de tekniske standarder for sammenkobling beskrives:
–
–
–
–
–
–
–
–
–
kommunikationsforbindelsens arkitektur
kommunikationen mellem SSTL og EUTL
sikkerheden ved dataoverførsel
listen over funktioner (transaktioner, afstemning osv.)
definitionen af transportlaget
kravene til journalføring af data
de operationelle arrangementer (calldesk og support)
planen for aktivering af kommunikation og testproceduren
proceduren for sikkerhedstest.
I de tekniske standarder for sammenkobling angives det, at administratorerne skal træffe rimelige
foranstaltninger for at sikre, at SSTL og EUTL samt forbindelsen er i drift 24 timer om dagen, syv
dage om ugen, og at eventuelle driftsafbrydelser for SSTL og EUTL samt forbindelsen holdes på et
minimum.
I de tekniske standarder for sammenkobling angives yderligere sikkerhedskrav for det schweiziske
register, SSTL, EU-registret og EUTL, som dokumenteres i en plan for sikkerhedsstyring. I de
tekniske standarder for sammenkobling angives det navnlig, at:
–
begge parter, hvis der er mistanke om, at sikkerheden for det schweiziske register, SSTL,
EU-registret eller EUTL er blevet kompromitteret, straks skal underrette den anden part og
suspendere forbindelsen mellem SSTL og EUTL
parterne, i tilfælde af et brud på sikkerheden, forpligter sig til omgående at dele
oplysningerne med hinanden. Hvis de tekniske oplysninger foreligger, deles en rapport, der
beskriver hændelsen (dato, årsag, virkning og afhjælpning), mellem administratoren af det
schweiziske register og Unionens centrale administrator senest 24 timer, efter at en
sikkerhedshændelse er identificeret som et sikkerhedsbrud.
–
DA
4
DA
 kom (2024) 0125 - Ingen titel
Den procedure for sikkerhedstest, der er beskrevet i de tekniske standarder for sammenkobling,
udføres, inden kommunikationsforbindelsen mellem SSTL og EUTL etableres, og når en ny version
eller frigivelse af SSTL eller EUTL er påkrævet.
De tekniske standarder for sammenkobling skal omhandle to testmiljøer ud over produktionsmiljøet:
et testmiljø for udviklere og et godkendelsesmiljø.
Parterne dokumenterer gennem administratoren af det schweiziske register og Unionens centrale
administrator, at der er udført en uafhængig sikkerhedsvurdering af deres systemer inden for de
foregående 12 måneder i overensstemmelse med de sikkerhedskrav, der er anført i de tekniske
standarder for sammenkobling. Sikkerhedstest og navnlig penetrationstest gennemføres for alle nye
og større softwarefrigivelser i overensstemmelse med de sikkerhedskrav, der er anført i de tekniske
standarder for sammenkobling. Penetrationstesten udføres ikke af softwareudvikleren eller af
softwareudviklerens underkontrahent."
DA
5
DA
 kom (2024) 0125 - Ingen titel
BILAG II
DA
6
DA
 kom (2024) 0125 - Ingen titel
FÆLLES DRIFTSPROCEDURER (FDP)
i henhold til artikel 3, stk. 6, i aftalen mellem Den Europæiske Union og Det Schweiziske
Forbund om sammenkobling af deres systemer for handel med drivhusgasemissioner
Procedurer for permanent registerforbindelse
Indhold
1.
2.
2.1.
2.2.
3.
4.
4.1.
4.2.
4.3.
4.4.
4.5.
5.
5.1.
5.2.
5.3.
5.4.
5.5.
6.
6.1.
6.2.
6.3.
6.4.
6.5.
6.6.
6.7.
7.
7.1.
Ordliste ....................................................................................................................... 10
Indledning ................................................................................................................... 11
Anvendelsesområde .................................................................................................... 11
Adressater ................................................................................................................... 12
Fremgangsmåde og standarder ................................................................................... 12
Hændelsesstyring ........................................................................................................ 13
Opdagelse og registrering af hændelser ...................................................................... 13
Klassificering og indledende support ......................................................................... 13
Undersøgelse og diagnosticering ................................................................................ 14
Løsning og genopretning ............................................................................................ 14
Lukning af hændelser ................................................................................................. 14
Problemstyring ............................................................................................................ 16
Problemidentifikation og -løsning .............................................................................. 16
Prioritering af problemer ............................................................................................ 16
Undersøgelse og diagnosticering af problemer .......................................................... 16
Løsning ....................................................................................................................... 16
Lukning af problemer ................................................................................................. 16
Opfyldelse af anmodninger ......................................................................................... 17
Oprettelse af anmodning ............................................................................................. 17
Registrering og analyse af anmodning ....................................................................... 17
Godkendelse af anmodning ........................................................................................ 17
Opfyldelse af anmodninger ......................................................................................... 17
Eskalering af anmodning ............................................................................................ 17
Gennemgang af opfyldelsen af anmodning ................................................................ 18
Lukning af anmodning ................................................................................................ 18
Ændringsstyring .......................................................................................................... 19
Ændringsanmodning ................................................................................................... 19
DA
7
DA
 kom (2024) 0125 - Ingen titel
7.2.
7.3.
7.4.
8.
8.1.
8.2.
8.3.
8.4.
8.5.
9.
9.1.
9.2.
9.3.
9.4.
9.5.
9.6.
9.7.
10.
10.1.
10.2.
10.3.
10.4.
10.5.
10.6.
10.7.
1.
2.
2.1.
2.2.
3.
3.1.
3.1.1.
3.1.2.
Evaluering og planlægning af ændring ....................................................................... 19
Godkendelse af ændring ............................................................................................. 19
Gennemførelse af ændring .......................................................................................... 19
Frigivelsesstyring ........................................................................................................ 19
Planlægning af frigivelse ............................................................................................ 20
Udvikling og test af frigivelsespakke ......................................................................... 20
Forberedelse af ibrugtagning ...................................................................................... 20
Rollback af frigivelsen ................................................................................................ 21
Gennemgang og lukning af frigivelsen ....................................................................... 21
Styring af sikkerhedshændelser .................................................................................. 21
Kategorisering af informationssikkerhedshændelser .................................................. 21
Håndtering af informationssikkerhedshændelser ....................................................... 22
Identifikation af sikkerhedshændelser ........................................................................ 22
Analyse af sikkerhedshændelser ................................................................................. 22
Vurdering, eskalering og rapportering af sikkerhedshændelser ................................. 22
Rapportering om håndteringen af sikkerhedshændelsen ............................................ 22
Overvågning, kapacitetsopbygning og løbende forbedringer ..................................... 23
Informationssikkerhedsstyring ................................................................................... 23
Identifikation af følsomme oplysninger...................................................................... 23
Følsomhedsniveauer for informationsaktiver ............................................................. 23
Tildeling af ejer af informationsaktiver ...................................................................... 23
Registrering af følsomme oplysninger........................................................................ 24
Håndtering af følsomme oplysninger ......................................................................... 24
Adgangsstyring ........................................................................................................... 24
Certifikat-/nøglestyring............................................................................................... 25
Ordliste ....................................................................................................................... 28
Indledning ................................................................................................................... 31
Anvendelsesområde .................................................................................................... 31
Adressater ................................................................................................................... 31
Almindelige bestemmelser ......................................................................................... 32
Kommunikationsforbindelsens arkitektur .................................................................. 32
Udveksling af meddelelser ......................................................................................... 32
XML-meddelelse – beskrivelse på højt plan .............................................................. 32
DA
8
DA
 kom (2024) 0125 - Ingen titel
3.1.3.
3.1.4.
3.2.
3.2.1.
3.2.2.
3.2.3.
3.2.4.
3.2.5.
3.2.6.
3.3.
3.3.1.
3.3.2.
3.3.3.
3.4.
3.5.
4.
4.1.
4.2.
4.2.1.
4.2.2.
4.2.3.
4.2.4.
4.3.
5.
5.1.
5.2.
5.3.
5.4.
5.4.1.
5.4.2.
5.5.
Datafangstvinduer ....................................................................................................... 32
Transaktionsmeddelelsesstrømme .............................................................................. 33
Sikker dataoverførsel .................................................................................................. 35
Sammenkobling mellem firewall og netværk ............................................................. 36
Virtuelt privat netværk (VPN) .................................................................................... 36
IPSec-implementering ................................................................................................ 36
Sikker overførselsprotokol til udveksling af meddelelser .......................................... 36
XML-kryptering og -signatur ..................................................................................... 36
Krypteringsnøgler ....................................................................................................... 37
Liste over funktioner under sammenkoblingen .......................................................... 37
Forretningstransaktioner ............................................................................................. 37
Afstemningsprotokol .................................................................................................. 38
Testmeddelelse ........................................................................................................... 38
Krav til journalføring af data ...................................................................................... 38
Driftskrav .................................................................................................................... 39
Bestemmelser om tilgængelighed ............................................................................... 40
Opbygning af kommunikationens tilgængelighed ...................................................... 40
Initialiserings-, kommunikations-, genaktiverings- og testplan ................................. 40
Interne IKT-infrastrukturtest ...................................................................................... 41
Kommunikationstest ................................................................................................... 41
Fulde systemtest (ende til ende) ................................................................................. 41
Sikkerhedstest ............................................................................................................. 41
Godkendelses-/testmiljøer .......................................................................................... 42
Bestemmelser om fortrolighed og integritet ............................................................... 42
Sikkerhedstestinfrastruktur ......................................................................................... 42
Bestemmelser om suspension og genaktivering af sammenkoblingen ....................... 43
Bestemmelser om sikkerhedsbrud .............................................................................. 43
Retningslinjer for sikkerhedstest ................................................................................ 44
Software ...................................................................................................................... 44
Infrastruktur ................................................................................................................ 44
Bestemmelser om risikovurdering .............................................................................. 44
DA
9
DA
 kom (2024) 0125 - Ingen titel
2841386_0011.png
1.
O
RDLISTE
Tabel 1-1 Akronymer og definitioner
Akronym/begreb
Certifikatmyndighed
CH
ETS
EU
IMT
Informationsaktiv
IT
ITIL
ITSM
LTS
Register
Definition
Enhed, der udsteder digitale certifikater
Det Schweiziske Forbund
Emissionshandelssystem
Den Europæiske Union
Hændelsesstyringsteam
En oplysning, der er værdifuld for en virksomhed eller organisation
Informationsteknologi
IT-infrastrukturbibliotek
IT-servicemanagement
Tekniske standarder for sammenkobling
Et regnskabssystem for kvoter udstedt under det ETS, som holder styr
på ejerskabet af kvoter, der opbevares på elektroniske konti
Ændringsanmodning
Liste over følsomme oplysninger
Serviceanmodning
Websted, hvor brugerne kan udveksle information og viden ved at
tilføje eller tilpasse indhold direkte via en webbrowser
RFC
SIL
SR
Wiki
DA
10
DA
 kom (2024) 0125 - Ingen titel
2.
I
NDLEDNING
Aftalen mellem Den Europæiske Union og Det Schweiziske Forbund om sammenkobling af deres
systemer for handel med drivhusgasemissioner af 23. november 2017 ("aftalen") indeholder
bestemmelser om gensidig anerkendelse af emissionskvoter, der kan anvendes til at opfylde kravene i
Den
Europæiske
Unions
emissionshandelssystem
("EU
ETS")
eller
Schweiz'
emissionshandelssystem ("Schweiz' ETS"). Med henblik på at gennemføre sammenkoblingen af EU
ETS og Schweiz' ETS vil der blive etableret en direkte forbindelse mellem EU-registrets EU-
transaktionsjournal (EUTL) og det schweiziske registers supplerende transaktionsjournal (SSTL),
som vil muliggøre overdragelse af emissionskvoter udstedt i et af ETS'erne mellem registrene
(aftalens artikel 3, stk. 2). For at gennemføre sammenkoblingen af EU ETS og Schweiz' ETS blev der
gennemført en foreløbig løsning i maj 2020. Fra og med 2023 vil registerforbindelsen mellem de to
ETS'er gradvis blive udviklet hen imod en permanent registerforbindelse, der forventes at blive
gennemført senest i 2024, og som gør det muligt for de forbundne markeder at fungere, for så vidt
angår fordelene ved markedslikviditet og gennemførelse af transaktioner mellem de to forbundne
systemer på en måde, der svarer til et marked bestående af to systemer, og som gør det muligt for
markedsdeltagerne at handle, som om de befandt sig på ét marked, kun med det forbehold, at de er
underlagt parternes individuelle forskrifter. (Bilag II til aftalen)
I henhold til aftalens artikel 3, stk. 6, fastlægger administratoren af det schweiziske register og
Unionens centrale administrator fælles driftsprocedurer (FDP) for tekniske og andre forhold, som er
nødvendige for driften af forbindelsen, under hensyntagen til prioriteter i den nationale lovgivning.
De FDP'er, der udvikles af administratorerne, træder i kraft, når de er vedtaget ved afgørelse i det
fælles udvalg.
FDP'erne blev vedtaget af det fælles udvalg ved afgørelse nr. 1/2020. De opdaterede FDP, der
fremgår af dette dokument, vil blive vedtaget af det fælles udvalg ved afgørelse nr. 1/2024. I
overensstemmelse med denne afgørelse og efter anmodninger fra det fælles udvalg har
administratoren af det schweiziske register og Unionens centrale administrator udviklet yderligere
tekniske retningslinjer for at gennemføre sammenkoblingen og sikre, at disse løbende tilpasses til den
tekniske udvikling og nye krav til sammenkoblingens sikkerhed og sikring og dens effektive drift.
2.1.
Anvendelsesområde
Dette dokument repræsenterer den fælles forståelse mellem aftalens parter om oprettelse af det
proceduremæssige grundlag for forbindelse mellem registrene i EU ETS og Schweiz' ETS. Det
skitserer de overordnede proceduremæssige krav med hensyn til driften, men der vil være behov for
yderligere tekniske retningslinjer for at gennemføre forbindelsen.
For at sikre, at forbindelsen fungerer korrekt, vil det kræve tekniske specifikationer for yderligere at
gennemføre sammenkoblingen. I henhold til aftalens artikel 3, stk. 7, er disse spørgsmål beskrevet i
de tekniske standarder for sammenkobling, der skal vedtages separat ved afgørelse i det fælles
udvalg.
Formålet med FDP er at sikre, at de IT-tjenester, der er knyttet til driften af forbindelsen mellem
registrene i EU ETS og Schweiz' ETS, leveres effektivt, navnlig for at kunne imødekomme
serviceanmodninger, løse servicefejl, løse problemer og udføre rutinemæssige operationelle opgaver i
overensstemmelse med internationale standarder for IT-servicemanagement.
DA
11
DA
 kom (2024) 0125 - Ingen titel
2841386_0013.png
For den permanente registerforbindelse vil der kun være behov for følgende FDP, som indgår i dette
dokument:
•
•
•
•
•
•
•
2.2.
Hændelsesstyring
Problemstyring
Opfyldelse af anmodninger
Ændringsstyring
Frigivelsesstyring
Styring af sikkerhedshændelser
Informationssikkerhedsstyring.
Adressater
Målgrupperne for disse FDP er EU's og de schweiziske supportteams for registrene.
3.
•
•
•
F
REMGANGSMÅDE OG STANDARDER
Følgende princip gælder for alle FDP:
EU og CH er enige om at definere FDP på grundlag af ITIL (IT-infrastrukturbibliotek, version 4).
Praksis fra denne standard genbruges og tilpasses de særlige behov i relation til den permanente
registerforbindelse.
Den kommunikation og koordinering, der er nødvendig for behandlingen af FDP mellem de to
parter, foregår via servicedeskene under CH's og EU's registre. Opgaverne tildeles altid inden for
den ene part.
Hvis der er uenighed om håndteringen af en fælles driftsprocedure, vil dette blive analyseret og
løst mellem de to servicedeske. Hvis det ikke er muligt at nå til enighed, eskaleres
problemstillingen til det næste niveau.
Eskaleringsniveauer
•
•
•
•
1. niveau
2. niveau
3. niveau
4. niveau
•
•
EU
EU's servicedesk
EU's driftsleder
•
•
CH
CH's servicedesk
Den ansvarlige for CH's
registerapplikation
Det fælles udvalg (som kan uddelegere dette ansvar under hensyntagen til
sammenkoblingsaftalens artikel 12, stk. 5)
Det fælles udvalg, hvis 3. niveau uddelegeres
•
•
•
Hver part kan fastsætte procedurer for driften af sit eget registersystem under hensyntagen til krav
og grænseflader i forbindelse med disse FDP'er.
Der anvendes et værktøj til ITSM (IT-servicemanagement) til støtte for FDP'en, herunder navnlig
hændelsesstyring, problemstyring og opfyldelse af anmodninger, samt kommunikation mellem
parterne.
Desuden tillades udveksling af oplysninger via e-mail.
DA
12
DA
 kom (2024) 0125 - Ingen titel
•
Begge parter sikrer, at kravene til informationssikkerhed opfyldes i overensstemmelse med
håndteringsinstrukserne.
H
ÆNDELSESSTYRING
4.
Formålet med hændelsesstyringsprocessen er at sikre, at IT-tjenester efter en hændelse kan vende
tilbage til det normale serviceniveau så hurtigt som muligt og med minimale afbrydelser af driften.
Hændelsesstyringen bør også omfatte et register over hændelser med henblik på indberetning og
integration med andre processer for at sikre løbende forbedringer.
Fra et overordnet perspektiv omfatter hændelsesstyring følgende aktiviteter:
•
•
•
•
•
Opdagelse og registrering af hændelser
Klassificering og indledende support
Undersøgelse og diagnosticering
Løsning og genopretning
Lukning af hændelser.
I løbet af en hændelses livscyklus sikrer hændelsesstyringsprocessen den løbende håndtering af
ejerskab, overvågning, sporing og kommunikation.
4.1.
Opdagelse og registrering af hændelser
En hændelse kan opdages af en supportgruppe, af automatiserede overvågningsværktøjer eller af
teknisk personale, der udfører rutinemæssig overvågning.
Når en hændelse opdages, skal den registreres og tildeles en entydig identifikator, der muliggør
korrekt sporing og overvågning. Den entydige identifikator for en hændelse er den identifikator, der
er tildelt i det fælles sagsstyringssystem i servicedesken for den part (enten EU eller CH), der
konstaterede hændelsen, og den skal anvendes i alle meddelelser vedrørende denne hændelse.
For alle hændelser bør kontaktpunktet være servicedesken for den part, der har åbnet sagen.
4.2.
Klassificering og indledende support
Klassificeringen af hændelser har til formål at forstå og identificere, hvilket system og/eller hvilke
tjenester, der er berørt af en hændelse, og i hvilket omfang. For at være effektiv bør klassificeringen
sikre, at hændelsen henvises til den korrekte ressource i første forsøg for at fremskynde løsningen af
hændelsen.
I klassificeringsfasen kategoriseres og prioriteres hændelsen afhængigt af, hvilken virkning den har,
og hvor meget den haster, så den kan behandles inden for den tidshorisont, der er relevant i forhold til
prioriteringen.
Hvis hændelsen har en potentiel indvirkning på følsomme datas fortrolighed eller integritet og/eller
på systemets tilgængelighed, skal hændelsen også angives som en sikkerhedshændelse og derefter
håndteres i henhold til den proces, der er defineret i kapitlet "Styring af sikkerhedshændelser" i dette
dokument.
Om muligt udfører den servicedesk, der åbnede sagen, en indledende diagnose. Her vil servicedesken
undersøge, om hændelsen er en kendt fejl. Hvis dette er tilfældet, er det allerede kendt og
dokumenteret, hvordan man løser problemet eller laver en workaround.
DA
13
DA
 kom (2024) 0125 - Ingen titel
Hvis servicedesken løser hændelsen, vil den rent faktisk lukke hændelsen på dette tidspunkt, da det
primære formål med hændelsesstyring er blevet opfyldt (dvs. hurtig genoptagelse af service for
slutbrugeren). Hvis dette ikke er tilfældet, vil servicedesken eskalere hændelsen til et relevant team,
der kan undersøge og diagnosticere problemet nærmere.
4.3.
Undersøgelse og diagnosticering
Undersøgelse og diagnosticering af hændelser bruges, når en hændelse ikke kan afhjælpes af
servicedesken som en del af den indledende diagnose og derfor er blevet eskaleret. Eskalering af
hændelser er en del af undersøgelses- og diagnosticeringsprocessen.
En almindelig praksis i undersøgelses- og diagnosticeringsfasen er at forsøge at genskabe hændelsen
under kontrollerede forhold. Det er i forbindelse med undersøgelse og diagnosticering af hændelser
vigtigt, at man forstår rækkefølgen af de handlinger, der førte til hændelsen.
Eskalering er en anerkendelse af, at en hændelse ikke kan afhjælpes på det nuværende supportniveau
og skal overdrages til en supportgruppe på et højere plan eller til den anden part. Eskaleringen kan
følge to veje: horisontalt (funktionelt) eller vertikalt (hierarkisk).
Den servicedesk, der registrerede og udløste hændelsen, er ansvarlig for at eskalere hændelsen til den
relevante ressource og for at følge den overordnede status for og placering af hændelsen.
Den part, som har fået tildelt hændelsen, er ansvarlig for at sikre, at de ønskede handlinger udføres
rettidigt, samt for at give feedback til sin egen parts servicedesk.
4.4.
Løsning og genopretning
Løsning af hændelser og genopretning foretages, når man ved, hvad der forårsagede hændelsen. At
finde en løsning på en hændelse betyder, at man har fundet en metode til afhjælpning af problemet.
Det at gennemføre løsningen er genopretningsfasen.
Når de passende ressourcer har løst problemet, henvises hændelsen tilbage til den relevante
servicedesk, som har registreret hændelsen, og samme servicedesk bekræfter over for den, der
konstaterede hændelsen, at fejlen er rettet, og at hændelsen kan lukkes. Resultaterne af behandlingen
af hændelsen skal registreres til fremtidig brug.
Genopretning kan foretages af IT-supportere eller ved at give slutbrugeren en række instrukser, der
skal følges.
4.5.
Lukning af hændelser
Lukning er det sidste trin i hændelsesstyringsprocessen lige efter, at der er fundet en løsning.
Tjeklisten over handlinger, der skal foretages i denne fase, omfatter bl.a.:
•
•
•
•
Kontrol af den oprindelige kategorisering, der blev tildelt hændelsen
Korrekt indsamling af alle oplysninger om hændelsen
Behørig dokumentation af hændelsen og opdatering af videnbasen
Passende kommunikation til alle interessenter, der er direkte eller indirekte berørt af hændelsen.
En hændelse lukkes formelt, når servicedesken har afsluttet lukningen af hændelsen og meddelt det
til den anden part.
Når en hændelse er lukket, genåbnes den ikke. Hvis en hændelse sker igen inden for kort tid, skal den
oprindelige hændelse ikke genåbnes, men der skal åbnes en ny hændelse.
DA
14
DA
 kom (2024) 0125 - Ingen titel
Hvis hændelsen behandles af både EU's og CH's servicedesk, ligger ansvaret for lukning af sagen hos
den servicedesk, der åbnede sagen.
DA
15
DA
 kom (2024) 0125 - Ingen titel
5.
P
ROBLEMSTYRING
Denne procedure bør følges, hver gang der konstateres et problem, som udløser
problemstyringsprocessen. Problemstyring fokuserer på at forbedre kvaliteten og reducere antallet af
hændelser, der rettes til servicedesken. Et problem kan være årsagen til en eller flere hændelser. Når
en hændelse rapporteres, er formålet med hændelsesstyring at genoprette tjenesten så hurtigt som
muligt, eventuelt gennem en workaround. Når et problem oprettes, er formålet at undersøge den
grundlæggende årsag til problemet for at finde frem til en ændring, der vil sikre, at problemet og de
dermed forbundne hændelser ikke vil ske igen.
5.1.
Problemidentifikation og -løsning
Afhængigt af hvilken part, der har åbnet sagen, vil enten EU's eller CH's servicedesk være
kontaktpunkt for spørgsmål vedrørende problemet.
Den entydige identifikator for et problem er den identifikator, der er tildelt af IT-servicemanagement
(ITSM). Den skal fremgå af alle meddelelser vedrørende dette problem.
Et problem kan udløses af en hændelse eller kan åbnes på eget initiativ for at løse problemer, der
opdages i systemet på et hvilket som helst tidspunkt.
5.2.
Prioritering af problemer
Problemer kan ligesom hændelser kategoriseres efter alvorsgrad og prioritering for at gøre det
nemmere at spore dem, hvor konsekvenserne af de tilknyttede hændelser og deres hyppighed tages i
betragtning.
5.3.
Undersøgelse og diagnosticering af problemer
Hver part kan gøre opmærksom på et problem, og den pågældende parts servicedesk vil være
ansvarlig for at registrere problemet, tildele passende ressourcer og følge den overordnede status for
problemet.
Den gruppe, som problemet blev eskaleret til, er ansvarlig for at løse problemet hurtigt og
kommunikere med servicedesken.
Efter anmodning er begge parter ansvarlige for at sikre, at de anviste foranstaltninger gennemføres,
og for at give feedback til sin egen parts servicedesk.
5.4.
Løsning
Den gruppe, som problemet er blevet henvist til, er ansvarlig for at løse problemet og give relevante
oplysninger til sin egen parts servicedesk.
Resultaterne af behandlingen af problemet skal registreres til fremtidig brug.
5.5.
Lukning af problemer
Et problem lukkes formelt, når problemet er blevet løst ved at gennemføre ændringen. Denne fase
gennemføres af den servicedesk, der registrerede problemet og informerede den anden parts
servicedesk.
DA
16
DA
 kom (2024) 0125 - Ingen titel
6.
O
PFYLDELSE AF ANMODNINGER
Opfyldelse af anmodninger er håndtering fra start til slut af en anmodning om en ny eller
eksisterende tjeneste fra det øjeblik, hvor den registreres og godkendes, og indtil den lukkes.
Serviceanmodninger er normalt små, foruddefinerede, repeterbare, hyppige, forhåndsgodkendte og
proceduremæssige anmodninger.
De vigtigste trin, der skal følges, er beskrevet nedenfor:
6.1.
Oprettelse af anmodning
Oplysningerne vedrørende en serviceanmodning gives til EU's eller CH's servicedesk pr. e-mail,
telefon eller via ITSM-værktøjet eller en anden aftalt kommunikationskanal.
6.2.
Registrering og analyse af anmodning
For alle serviceanmodninger bør kontaktpunktet være EU's eller CH's servicedesk, afhængigt af
hvilken part serviceanmodningen kommer fra. Denne servicedesk vil være ansvarlig for at registrere
og analysere serviceanmodningen med den fornødne omhu.
6.3.
Godkendelse af anmodning
Medarbejderen i servicedesken for den part, serviceanmodningen kom fra, kontrollerer, om der
kræves godkendelser fra den anden part, og indhenter dem i så fald. Hvis serviceanmodningen ikke
godkendes, ajourfører og lukker servicedesken sagen.
6.4.
Opfyldelse af anmodninger
I dette trin sikres effektiv og virkningsfuld behandling af serviceanmodninger. Der skal skelnes
mellem følgende tilfælde:
•
•
Opfyldelsen af serviceanmodningen berører kun den ene part. I dette tilfælde udsteder denne part
arbejdsordrerne og koordinerer udførelsen.
Opfyldelsen af serviceanmodningen berører både EU og CH. I dette tilfælde udsteder begge
servicedeske arbejdsordrerne inden for deres ansvarsområde. Behandlingen af
serviceanmodningen koordineres mellem de to servicedeske. Det overordnede ansvar ligger hos
den servicedesk, som modtog og igangsatte serviceanmodningen.
Når serviceanmodningen er blevet opfyldt, skal den have status som "løst" ("Resolved").
6.5.
Eskalering af anmodning
Servicedesken kan om nødvendigt eskalere den udestående serviceanmodning til den relevante
ressource (tredjepart).
Eskalering sker til de respektive tredjeparter, dvs. at EU's servicedesk skal gå gennem CH's
servicedesk for at eskalere til en tredjepart i CH og omvendt.
Den tredjepart, som serviceanmodningen blev eskaleret til, er ansvarlig for at behandle
serviceanmodningen rettidigt og kommunikere med den servicedesk, der har eskaleret anmodningen.
Den servicedesk, der registrerede serviceanmodningen, er ansvarlig for at følge den overordnede
status og placering af en serviceanmodning.
DA
17
DA
 kom (2024) 0125 - Ingen titel
6.6.
Gennemgang af opfyldelsen af anmodning
Den ansvarlige servicedesk fremsender serviceanmodningen til en endelig kvalitetskontrol, inden den
lukkes. Formålet er at sikre, at serviceanmodningen faktisk behandles, og at alle de oplysninger, der
er nødvendige for at beskrive anmodningens livscyklus, leveres med tilstrækkelige detaljer.
Derudover skal resultaterne af behandlingen af anmodningen registreres til fremtidig brug.
6.7.
Lukning af anmodning
Hvis de deltagende parter er enige om, at serviceanmodningen er blevet opfyldt, og rekvirenten
mener, at sagen er løst, er den næste status, der skal angives, "lukket" ("Closed").
En serviceanmodning lukkes formelt, når den servicedesk, der registrerede serviceanmodningen, har
gennemført lukningen og underrettet den anden parts servicedesk.
DA
18
DA
 kom (2024) 0125 - Ingen titel
7.
Æ
NDRINGSSTYRING
Formålet er at sikre, at der anvendes standardiserede metoder og procedurer til effektiv og hurtig
håndtering af alle ændringer i kontrolinfrastrukturen for at minimere antallet og virkningen af
relaterede hændelser ved service. Ændringer i IT-infrastruktur kan ske som reaktion på problemer
eller krav udefra, f.eks. lovgivningsmæssige ændringer, eller som et proaktivt forsøg på at opnå større
effektivitet eller virkningsfuldhed eller for at kunne gennemføre eller afspejle forretningsmæssige
initiativer.
Ændringsstyringsprocessen omfatter forskellige trin, der omfatter alle detaljer af en
ændringsanmodning med henblik på fremtidig sporing. Disse processer sikrer, at ændringen valideres
og testes, før den tages i brug. Ibrugtagningen gennemføres under frigivelsesstyringens ansvar.
7.1.
Ændringsanmodning
En ændringsanmodning indgives til ændringsstyringsteamet med henblik på validering og
godkendelse. For alle ændringsanmodninger bør kontaktpunktet være EU's eller CH's servicedesk,
afhængigt af hvilken part der har fremsat anmodningen. Denne servicedesk vil være ansvarlig for at
registrere og analysere anmodningen med fornøden omhu.
Ændringsanmodninger kan stamme fra:
•
•
•
•
•
7.2.
En hændelse, der medfører en ændring
Et eksisterende problem, der medfører en ændring
En slutbruger, der anmoder om en ny ændring
Ændring som følge af løbende vedligeholdelse
Lovgivningsmæssig ændring.
Evaluering og planlægning af ændring
På dette trin sker vurderingen og planlægningen af ændringer. Det omfatter prioritering og
planlægning af aktiviteter med henblik på at minimere risici og virkninger.
Hvis gennemførelsen af ændringsanmodningen berører både EU og CH, verificerer den part, der har
registreret ændringsanmodningen, evalueringen og planlægningen med den anden part.
7.3.
Godkendelse af ændring
Alle registrerede ændringsanmodninger skal godkendes af det relevante eskaleringsniveau.
7.4.
Gennemførelse af ændring
Gennemførelsen af ændringer sker i forbindelse med frigivelsesstyringsprocessen. Parternes teams
følger deres egne processer, der omfatter planlægning og test. Ændringen vurderes derefter, når den
er gennemført. For at sikre, at alt er forløbet efter planen, gennemgås den eksisterende
ændringsstyringsproces hele tiden og ajourføres, hvis det er nødvendigt.
8.
F
RIGIVELSESSTYRING
En frigivelse er en eller flere ændringer i en IT-tjeneste, der er samlet i en frigivelsesplan, og som
skal godkendes, forberedes, udvikles, testes og anvendes sammen. En frigivelse kan f.eks. være en
fejlrettelse, en ændring af hardware eller andre komponenter, ændringer i software, opgradering af
DA
19
DA
 kom (2024) 0125 - Ingen titel
applikationsversioner, ændringer af dokumentation og/eller processer. Indholdet af hver enkelt
frigivelse styres, testes og anvendes som én enkelt enhed.
Frigivelsesstyring har til formål at planlægge, udvikle, teste og validere og levere kapacitet til at
udføre den ønskede service, som vil opfylde de berørte parters behov samt de tilsigtede mål.
Acceptkriterier for alle serviceændringer vil blive fastlagt og dokumenteret i forbindelse med
designkoordinering og leveres til de relevante teams.
Frigivelsen vil typisk bestå af en række problemrettelser og forbedringer af en service. Den
indeholder det nye eller ændrede software, der kræves, og det nye eller ændrede hardware, der er
nødvendigt for at gennemføre de godkendte ændringer.
8.1.
Planlægning af frigivelse
I det første trin i processen fordeles godkendte ændringer på frigivelsespakker, og frigivelsens
omfang og indhold bestemmes. På grundlag af disse oplysninger vil der i planlægningen af
frigivelsen blive udarbejdet en tidsplan for udvikling, test og ibrugtagning af frigivelsen.
Planlægningen bør omfatte:
•
•
•
•
•
•
Frigivelsens omfang og indhold
Risikovurdering og risikoprofil for frigivelsen
Kunder/brugere, der berøres af frigivelsen
Det team, der er ansvarligt for frigivelsen
Strategi for levering og ibrugtagning
Ressourcer til frigivelsen og dens ibrugtagning.
Begge parter informerer hinanden om deres vinduer for planlægning og vedligeholdelse af
frigivelser. Hvis en frigivelse berører både EU og CH, koordinerer de planlægningen og definerer et
fælles vindue for vedligeholdelse.
8.2.
Udvikling og test af frigivelsespakke
I udviklings- og testfasen fastlægges det, hvordan frigivelsen eller pakken skal behandles, og hvordan
de kontrollerede miljøer, inden produktionen ændres, kan opretholdes, samt test af alle ændringer i
alle miljøer.
Hvis en frigivelse berører både EU og CH, koordinerer de leveringsplaner og test. Dette omfatter
følgende aspekter:
•
•
•
•
•
8.3.
Hvordan og hvornår de enkelte dele af en frigivelse og servicekomponenter vil blive leveret
Hvad produktionstiden normalt er, og hvad der sker i tilfælde af en forsinkelse
Hvordan man kan følge med i, hvordan leveringen skrider frem, og få det bekræftet
Parametre for overvågning og bestemmelse af, om ibrugtagningen af frigivelsen sker korrekt
Fælles testcases for relevante funktioner og ændringer.
Forberedelse af ibrugtagning
Ved afslutningen af denne delproces er alle de krævede frigivelseskomponenter klar til ibrugtagning.
Forberedelsesprocessen sikrer, at kommunikationsplanerne defineres korrekt, at meddelelser er klar
til at blive sendt til alle berørte interessenter og slutbrugere, og at frigivelsen integreres i
ændringsstyringsprocessen for at sikre, at alle ændringer udføres på en kontrolleret måde og
godkendes i de krævede fora.
DA
20
DA
 kom (2024) 0125 - Ingen titel
Hvis en frigivelse berører både EU og CH, skal de koordinere følgende aktiviteter:
•
•
•
•
•
8.4.
Registrering af ændringsanmodning og forberedelse af ibrugtagning i produktionsmiljø
Udarbejdelse af en gennemførelsesplan
Rollback-metode, så det er muligt at vende tilbage til den tidligere tilstand, hvis ibrugtagning af
frigivelsen mislykkes
Meddelelser til alle de nødvendige parter
Krav om godkendelse af gennemførelsen af frigivelsen fra det relevante eskaleringsniveau.
Rollback af frigivelsen
Hvis der har været fejl i ibrugtagningen, eller det viste sig i testen, at ibrugtagningen ikke lykkedes,
eller ikke opfyldte de aftalte godkendelses-/kvalitetskriterier, vil begge parters teams skulle rulle
tilbage til den tidligere tilstand. Alle berørte interessenter skal informeres, herunder berørte og
tilsigtede slutbrugere. Mens der afventes godkendelse, kan processen genoptages på ethvert af de
foregående trin.
8.5.
•
•
•
•
•
•
•
•
•
•
•
9.
Gennemgang og lukning af frigivelsen
Ved gennemgangen af en ibrugtagning bør følgende aktiviteter være omfattet:
Indhente feedback om kundens, brugerens og de pågældende medarbejderes tilfredshed med
ibrugtagningen (indsamle feedback og overveje løbende at forbedre servicen)
Gennemgå alle kvalitetskriterier, der ikke er opfyldt
Kontrollere, at eventuelle handlinger, nødvendige rettelser og ændringer er fuldstændige
Sikre, at der ikke er nogen problemer med hensyn til funktioner, ressourcer, kapacitet eller
resultater efter ibrugtagningen af frigivelsen
Kontrollere, at eventuelle problemer, kendte fejl og workarounds er dokumenteret og accepteret
af kunden, slutbrugerne, driftssupport og andre berørte parter
Overvåge hændelser og problemer som følge af ibrugtagning (yde tidlig support til driftsteams,
hvis frigivelsen har medført en forøgelse af arbejdsmængden)
Ajourføre supportdokumentation (dvs. tekniske dokumenter)
Formelt overdrage den ibrugtagede frigivelse til driften
Dokumentere de indhøstede erfaringer
Indhente en oversigt over frigivelsen fra de teams, der har gennemført den
Formelt lukke frigivelsen efter kontrol af ændringsanmodninger.
S
TYRING AF SIKKERHEDSHÆNDELSER
Styring af sikkerhedshændelser er en proces for håndtering af sikkerhedshændelser med henblik på at
muliggøre kommunikation om hændelser til potentielt berørte interessenter, evaluering og
prioritering af hændelser samt håndtering af hændelser med henblik på at løse eventuelle faktiske,
formodede eller potentielle brud på fortroligheden, tilgængeligheden eller integriteten af følsomme
informationsaktiver.
9.1.
Kategorisering af informationssikkerhedshændelser
Alle hændelser, der påvirker forbindelsen mellem EU-registret og det schweiziske register,
analyseres for at fastslå et eventuelt brud på fortroligheden, integriteten eller tilgængeligheden af
følsomme oplysninger, der er registreret på listen over følsomme oplysninger (SIL).
DA
21
DA
 kom (2024) 0125 - Ingen titel
Hvis dette er tilfældet, skal hændelsen kategoriseres som en informationssikkerhedshændelse, straks
registreres i ITSM-værktøjet og behandles som sådan.
9.2.
Håndtering af informationssikkerhedshændelser
Sikkerhedshændelser placeres under det 3. eskaleringsniveau, og løsningen af hændelser vil blive
varetaget af et særligt team til styring af hændelser (Incident Management Team (IMT)).
Teamet er ansvarligt for:
•
•
•
Den første analyse, kategorisering og vurdering af hændelsens alvor
Koordinering af foranstaltninger mellem alle interessenter, herunder den fulde dokumentation af
analysen af hændelsen, de beslutninger, der træffes for at håndtere hændelsen, og mulige
identificerede svagheder
Rettidig eskalering af hændelsen til rette niveau til orientering og/eller afgørelse, afhængigt af
hvor alvorlig sikkerhedshændelsen er.
I informationsstyringsprocessen klassificeres alle oplysninger vedrørende hændelser på det højeste
følsomhedsniveau, men under ingen omstændigheder lavere end SENSITIVE:
ETS.
I forbindelse med en igangværende undersøgelse og/eller en svaghed, der kan udnyttes, og indtil den
afhjælpes, klassificeres oplysningerne som SPECIAL HANDLING:
ETS Critical.
9.3.
Identifikation af sikkerhedshændelser
Afhængigt af typen af sikkerhedshændelse fastsætter den informationssikkerhedsansvarlige de
relevante organisationer, der skal inddrages, og som skal indgå i IMT.
9.4.
Analyse af sikkerhedshændelser
IMT samarbejder med alle involverede organisationer og de relevante medlemmer af deres teams, alt
efter hvad der er relevant, for at gennemgå hændelsen. Under analysen afdækkes det, i hvilket
omfang et aktivs fortrolighed, integritet eller tilgængelighed er berørt, og konsekvenserne for alle
berørte organisationer vurderes. Dernæst defineres indledende og opfølgende foranstaltninger til at
afhjælpe hændelsen og styre dens virkninger, herunder de ressourcemæssige konsekvenser af disse
foranstaltninger.
9.5.
Vurdering, eskalering og rapportering af sikkerhedshændelser
IMT vurderer, hvor alvorlig en ny sikkerhedshændelse er, efter at den er blevet konstateret, og
begynder omgående at træffe de nødvendige foranstaltninger afhængigt af hændelsens alvor.
9.6.
Rapportering om håndteringen af sikkerhedshændelsen
IMT udarbejder en rapport om håndteringen af sikkerhedshændelsen med oplysninger om, hvordan
den er blevet inddæmmet, og den efterfølgende genopretning. Rapporten sendes til det 3.
eskaleringsniveau pr. sikker e-mail eller andre gensidigt accepterede sikre kommunikationsmidler.
Den ansvarlige part gennemgår resultaterne af inddæmningen og genopretningen og:
•
•
•
Tilkobler registret igen, hvis det er blevet afkoblet
Oplyser registerteams om hændelsen
Lukker hændelsen.
DA
22
DA
 kom (2024) 0125 - Ingen titel
IMT bør — på en sikker måde — medtage relevante oplysninger i rapporten om
sikkerhedshændelsen for at sikre konsekvent registrering og kommunikation og gøre det muligt at
træffe hurtige og hensigtsmæssige foranstaltninger til at inddæmme hændelsen. Efter færdiggørelsen
forelægger IMT den endelige rapport om sikkerhedshændelsen inden for rimelig tid.
9.7.
Overvågning, kapacitetsopbygning og løbende forbedringer
IMT leverer rapporter om alle sikkerhedshændelser til det 3. eskaleringsniveau. Rapporterne vil blive
anvendt af dette eskaleringsniveau til at fastslå følgende:
•
•
•
Svage punkter i sikkerhedskontrollen og/eller driften, der skal styrkes
Eventuelle behov for at forbedre denne procedure for at forbedre effektiviteten af reaktionen på
hændelser
Uddannelses- og kapacitetsopbygningsmuligheder for yderligere at styrke registersystemers
modstandsdygtighed over for informationssikkerhedshændelser, mindske risikoen for fremtidige
hændelser og minimere deres virkning.
I
NFORMATIONSSIKKERHEDSSTYRING
10.
Informationssikkerhedsstyring har til formål at sikre fortrolighed, integritet og tilgængelighed af en
organisations fortrolige oplysninger, data og IT-tjenester. Ud over de tekniske komponenter,
herunder design og test (se de tekniske standarder for sammenkobling), er følgende fælles
driftsprocedurer nødvendige for at opfylde sikkerhedskravene til den permanente registerforbindelse.
10.1.
Identifikation af følsomme oplysninger
En oplysnings følsomhed vurderes ved at bestemme virkningerne for virksomheden (f.eks.
økonomiske tab, skade på image, overtrædelse af lovgivningen osv.) af et brud på sikkerheden i
forbindelse med disse oplysninger.
De følsomme informationsaktiver skal identificeres på grundlag af deres indvirkning på forbindelsen.
Disses følsomhed vurderes i henhold til den følsomhedsskala, der gælder for denne forbindelse, og
som er beskrevet i afsnittet "Håndtering af informationssikkerhedshændelser" i dette dokument.
10.2.
•
•
•
Følsomhedsniveauer for informationsaktiver
Når et informationsaktiv er identificeret, klassificeres det efter følgende regler:
Ved mindst ét højt niveau med hensyn til fortrolighed, integritet eller tilgængelighed klassificeres
aktivet som SPECIAL HANDLING:
ETS Critical.
Ved mindst ét mellemhøjt niveau med hensyn til fortrolighed, integritet eller tilgængelighed
klassificeres aktivet som SENSITIVE:
ETS.
Ved kun lave niveauer med hensyn til fortrolighed, integritet eller tilgængelighed klassificeres
aktivet som EU: SENSITIVE:
Fælles indkøb under ETS.
Klassificering Schweiz: LIMITED:
ETS.
Tildeling af ejer af informationsaktiver
10.3.
Alle informationsaktiver bør få tildelt en ejer. Informationsaktiver i ETS, som tilhører eller er
forbundet med forbindelsen mellem EUTL og SSTL, bør medtages i en fælles liste over aktiver, der
DA
23
DA
 kom (2024) 0125 - Ingen titel
føres af begge parter. Informationsaktiver i ETS, som er uden for forbindelsen mellem EUTL og
SSTL, bør medtages i en fælles liste over aktiver, der føres af den respektive part.
Parterne skal aftale, hvem der ejer hvert enkelt informationsaktiv, der tilhører eller er forbundet med
forbindelsen mellem EUTL og SSTL. Ejeren af et informationsaktiv er ansvarlig for at vurdere dets
følsomhed.
Ejeren bør have de beføjelser, der passer til værdien af de tildelte aktiver. Ejerens ansvar for
aktivet/aktiverne og vedkommendes forpligtelse til at opretholde den nødvendige fortrolighed,
integritet og tilgængelighed bør aftales og formaliseres.
10.4.
Registrering af følsomme oplysninger
Alle følsomme oplysninger registreres i listen over følsomme oplysninger (SIL).
Hvis det er relevant, skal der tages højde for, at flere følsomme oplysninger tilsammen kan have en
større virkning end virkningen af én enkelt oplysning, og dette skal registreres i listen (f.eks.
oplysninger lagret i systemdatabasen).
Listen er ikke statisk. Trusler, sårbarheder, sandsynlighed eller konsekvenser af sikkerhedshændelser
i forbindelse med aktiverne kan ændre sig uden forvarsel, og der kan indføres nye aktiver i driften af
registersystemerne.
Derfor skal listen regelmæssigt tages op til revision, og nye oplysninger, der kategoriseres som
følsomme, skal straks registreres i listen.
Listen skal mindst indeholde følgende oplysninger:
•
•
•
•
•
Beskrivelse af oplysningerne
Oplysningens ejer
Følsomhedsniveau
Angivelse af, om oplysningerne omfatter personoplysninger
Eventuelle yderligere oplysninger.
Håndtering af følsomme oplysninger
10.5.
Når følsomme oplysninger behandles uden for forbindelsen mellem EU-registret og det schweiziske
register, skal de behandles i overensstemmelse med håndteringsinstrukserne.
Følsomme oplysninger, der behandles via en forbindelse mellem EU-registret og det schweiziske
register, behandles i overensstemmelse med parternes sikkerhedskrav.
10.6.
Adgangsstyring
Formålet med adgangsstyring er at give autoriserede brugere ret til at benytte en service og samtidig
forhindre adgang for uautoriserede brugere. Adgangsstyring omtales undertiden også som
"rettighedsstyring" eller "identitetsstyring".
I forbindelse med den permanente registerforbindelse og dens drift har begge parter behov for adgang
til følgende komponenter:
•
Wiki: Et samarbejdsmiljø for udveksling af fælles oplysninger som f.eks. planlægning af
frigivelser
DA
24
DA
 kom (2024) 0125 - Ingen titel
•
•
ITSM-værktøj til styring af hændelser og problemer (se kapitel 3, "Fremgangsmåde og
standarder")
System til udveksling af meddelelser: Hver part skal have et sikkert system til udveksling af
meddelelser, der indeholder transaktionsdata.
Administratoren af det schweiziske register og Unionens centrale administrator sørger for, at
adgangsrettighederne er ajourført, og fungerer som kontaktpunkter for parternes
adgangsstyringsaktiviteter. Anmodninger om adgang behandles i henhold til procedurerne for
opfyldelse af anmodninger.
10.7.
Certifikat-/nøglestyring
Hver part er ansvarlig for sin egen certifikat-/nøglestyring (generering, registrering, lagring,
installation, anvendelse, fornyelse, tilbagekaldelse, sikkerhedskopiering og tilbagelevering af
certifikater/nøgler). Som beskrevet i de tekniske standarder for sammenkobling må der kun bruges
digitale certifikater udstedt af en certificeringsmyndighed, som begge parter har tillid til. Håndtering
og opbevaring af certifikater/nøgler skal følge de bestemmelser, der er fastsat i
håndteringsinstrukserne.
Tilbagekaldelse og/eller fornyelse af certifikater og nøgler koordineres af begge parter. Dette sker i
overensstemmelse med procedurerne for opfyldelse af anmodninger.
Administratoren af det schweiziske register og Unionens centrale administrator udveksler
certifikater/nøgler via sikre kommunikationsmidler i overensstemmelse med de bestemmelser, der er
fastlagt i håndteringsinstrukserne.
Enhver verifikation af certifikater/nøgler på en hvilken som helst måde mellem parterne sker via en
anden
kanal.
DA
25
DA
 kom (2024) 0125 - Ingen titel
BILAG III
DA
26
DA
 kom (2024) 0125 - Ingen titel
TEKNISKE STANDARDER FOR SAMMENKOBLING
i henhold til artikel 3, stk. 7, i aftalen mellem Den Europæiske Union og Det Schweiziske
Forbund om sammenkobling af deres systemer for handel med drivhusgasemissioner
Standarder for permanent registerforbindelse
Indhold
1.
2.
2.1.
2.2.
3.
4.
4.1.
4.2.
4.3.
4.4.
4.5.
5.
5.1.
5.2.
5.3.
5.4.
5.5.
6.
6.1.
6.2.
6.3.
6.4.
6.5.
6.6.
6.7.
7.
7.1.
Ordliste ....................................................................................................................... 10
Indledning ................................................................................................................... 11
Anvendelsesområde .................................................................................................... 11
Adressater ................................................................................................................... 12
Fremgangsmåde og standarder ................................................................................... 12
Hændelsesstyring ........................................................................................................ 13
Opdagelse og registrering af hændelser ...................................................................... 13
Klassificering og indledende support ......................................................................... 13
Undersøgelse og diagnosticering ................................................................................ 14
Løsning og genopretning ............................................................................................ 14
Lukning af hændelser ................................................................................................. 14
Problemstyring ............................................................................................................ 16
Problemidentifikation og -løsning .............................................................................. 16
Prioritering af problemer ............................................................................................ 16
Undersøgelse og diagnosticering af problemer .......................................................... 16
Løsning ....................................................................................................................... 16
Lukning af problemer ................................................................................................. 16
Opfyldelse af anmodninger ......................................................................................... 17
Oprettelse af anmodning ............................................................................................. 17
Registrering og analyse af anmodning ....................................................................... 17
Godkendelse af anmodning ........................................................................................ 17
Opfyldelse af anmodninger ......................................................................................... 17
Eskalering af anmodning ............................................................................................ 17
Gennemgang af opfyldelsen af anmodning ................................................................ 18
Lukning af anmodning ................................................................................................ 18
Ændringsstyring .......................................................................................................... 19
Ændringsanmodning ................................................................................................... 19
DA
27
DA
 kom (2024) 0125 - Ingen titel
7.2.
7.3.
7.4.
8.
8.1.
8.2.
8.3.
8.4.
8.5.
9.
9.1.
9.2.
9.3.
9.4.
9.5.
9.6.
9.7.
10.
10.1.
10.2.
10.3.
10.4.
10.5.
10.6.
10.7.
1.
2.
2.1.
2.2.
3.
3.1.
3.1.1.
3.1.2.
Evaluering og planlægning af ændring ....................................................................... 19
Godkendelse af ændring ............................................................................................. 19
Gennemførelse af ændring .......................................................................................... 19
Frigivelsesstyring ........................................................................................................ 19
Planlægning af frigivelse ............................................................................................ 20
Udvikling og test af frigivelsespakke ......................................................................... 20
Forberedelse af ibrugtagning ...................................................................................... 20
Rollback af frigivelsen ................................................................................................ 21
Gennemgang og lukning af frigivelsen ....................................................................... 21
Styring af sikkerhedshændelser .................................................................................. 21
Kategorisering af informationssikkerhedshændelser .................................................. 21
Håndtering af informationssikkerhedshændelser ....................................................... 22
Identifikation af sikkerhedshændelser ........................................................................ 22
Analyse af sikkerhedshændelser ................................................................................. 22
Vurdering, eskalering og rapportering af sikkerhedshændelser ................................. 22
Rapportering om håndteringen af sikkerhedshændelsen ............................................ 22
Overvågning, kapacitetsopbygning og løbende forbedringer ..................................... 23
Informationssikkerhedsstyring ................................................................................... 23
Identifikation af følsomme oplysninger...................................................................... 23
Følsomhedsniveauer for informationsaktiver ............................................................. 23
Tildeling af ejer af informationsaktiver ...................................................................... 23
Registrering af følsomme oplysninger........................................................................ 24
Håndtering af følsomme oplysninger ......................................................................... 24
Adgangsstyring ........................................................................................................... 24
Certifikat-/nøglestyring............................................................................................... 25
Ordliste ....................................................................................................................... 30
Indledning ................................................................................................................... 32
Anvendelsesområde .................................................................................................... 32
Adressater ................................................................................................................... 32
Almindelige bestemmelser ......................................................................................... 33
Kommunikationsforbindelsens arkitektur .................................................................. 33
Udveksling af meddelelser ......................................................................................... 33
XML-meddelelse – beskrivelse på højt plan .............................................................. 33
DA
28
DA
 kom (2024) 0125 - Ingen titel
3.1.3.
3.1.4.
3.2.
3.2.1.
3.2.2.
3.2.3.
3.2.4.
3.2.5.
3.2.6.
3.3.
3.3.1.
3.3.2.
3.3.3.
3.4.
3.5.
4.
4.1.
4.2.
4.2.1.
4.2.2.
4.2.3.
4.2.4.
4.3.
5.
5.1.
5.2.
5.3.
5.4.
5.4.1.
5.4.2.
5.5.
Datafangstvinduer ....................................................................................................... 33
Transaktionsmeddelelsesstrømme .............................................................................. 34
Sikker dataoverførsel .................................................................................................. 36
Sammenkobling mellem firewall og netværk ............................................................. 37
Virtuelt privat netværk (VPN) .................................................................................... 37
IPSec-implementering ................................................................................................ 37
Sikker overførselsprotokol til udveksling af meddelelser .......................................... 37
XML-kryptering og -signatur ..................................................................................... 37
Krypteringsnøgler ....................................................................................................... 38
Liste over funktioner under sammenkoblingen .......................................................... 38
Forretningstransaktioner ............................................................................................. 38
Afstemningsprotokol .................................................................................................. 39
Testmeddelelse ........................................................................................................... 39
Krav til journalføring af data ...................................................................................... 39
Driftskrav .................................................................................................................... 40
Bestemmelser om tilgængelighed ............................................................................... 41
Opbygning af kommunikationens tilgængelighed ...................................................... 41
Initialiserings-, kommunikations-, genaktiverings- og testplan ................................. 41
Interne IKT-infrastrukturtest ...................................................................................... 42
Kommunikationstest ................................................................................................... 42
Fulde systemtest (ende til ende) ................................................................................. 42
Sikkerhedstest ............................................................................................................. 42
Godkendelses-/testmiljøer .......................................................................................... 43
Bestemmelser om fortrolighed og integritet ............................................................... 43
Sikkerhedstestinfrastruktur ......................................................................................... 43
Bestemmelser om suspension og genaktivering af sammenkoblingen ....................... 44
Bestemmelser om sikkerhedsbrud .............................................................................. 44
Retningslinjer for sikkerhedstest ................................................................................ 45
Software ...................................................................................................................... 45
Infrastruktur ................................................................................................................ 45
Bestemmelser om risikovurdering .............................................................................. 45
DA
29
DA
 kom (2024) 0125 - Ingen titel
2841386_0031.png
1.
O
RDLISTE
Tabel 1-1 Forretningsakronymer og definitioner
Akronym/begreb
Kvote
Definition
En ret til i en nærmere angivet periode at udlede et ton
kuldioxidækvivalent, som udelukkende er gyldig til opfyldelse af
kravene i en af enhedernes ETS.
Det Schweiziske Forbund
Type stationære kvoter, også kaldet CHU2 (med henvisning til Kyoto-
protokollens forpligtelsesperiode 2), udstedt af CH
Schweizisk luftfartskvote
Fælles driftsprocedurer Fælles udviklede procedurer til at gennemføre
sammenkoblingen mellem EU ETS og Schweiz' ETS.
Emissionshandelsregister
Emissionshandelssystem
Den Europæiske Union
Almindelig EU-kvote
EU-luftfartskvote
Den Europæiske Unions konsoliderede register
EU-transaktionsjournal
Et regnskabssystem for kvoter udstedt under det ETS, som holder styr
på ejerskabet af kvoter, der opbevares på elektroniske konti
Det schweiziske registers supplerende transaktionsjournal.
En proces i et register, der omfatter overdragelse af en kvote fra en
konto til en anden konto.
CH
CHU
CHUA
FDP
ETR
ETS
EU
EUA
EUAA
EUCR
EUTL
Register
SSTL
Transaktion
Transaktionsjournalsystem Transaktionsjournalen indeholder en fortegnelse over hver foreslået
transaktion, der sendes fra et register til et andet.
DA
30
DA
 kom (2024) 0125 - Ingen titel
2841386_0032.png
Tabel 1-2 Tekniske akronymer og definitioner
Akronym
Asymmetrisk
kryptografi
Definition
Bruger offentlige og private nøgler til at kryptere og dekryptere data.
Certifikatmyndighed Enhed, der udsteder digitale certifikater.
Krypteringsnøgle
En oplysning, der bestemmer det funktionelle output af en kryptografisk
algoritme.
Omvendt krypteringsproces.
En matematisk metode til validering af ægthed og integritet af en meddelelse,
software eller et digitalt dokument.
Konvertering af oplysninger eller data til en kode, navnlig for at forhindre
uautoriseret adgang.
Læsning af en fil.
Netsikkerhedsudstyr eller -software, der overvåger og kontrollerer indgående
og udgående nettrafik baseret på forudbestemte regler.
Periodisk signal, der genereres og overvåges af hardware eller software for at
angive normal drift eller synkronisere andre dele af et computersystem.
IP SECurity. Netværksprotokolfamilie, der autentificerer og krypterer
datapakkerne med henblik på at sikre krypteret kommunikation mellem to
computere via et internetprotokolnetværk.
Afprøvning af et computersystem, et netværk eller en webapplikation for at
identificere sikkerhedsmæssige sårbarheder, som en angriber kan udnytte.
Sikring af, at to fortegnelser er overensstemmende.
Virtuelt privat net.
Extensible Mark-up Language. Udviklere kan hermed oprette deres egne
skræddersyede tags, der muliggør definition, fremsendelse, validering og
fortolkning af data mellem applikationer og mellem organisationer.
Dekryptering
Digital signatur
Kryptering
Filfangst
Firewall
Heartbeat-
overvågning
IPSEC
Penetrationstest
Afstemningsproces
VPN
XML
DA
31
DA
 kom (2024) 0125 - Ingen titel
2.
I
NDLEDNING
Aftalen mellem Den Europæiske Union og Det Schweiziske Forbund om sammenkobling af deres
systemer for handel med drivhusgasemissioner af 23. november 2017 ("aftalen") indeholder
bestemmelser om gensidig anerkendelse af emissionskvoter, der kan anvendes til at opfylde kravene i
Den
Europæiske
Unions
emissionshandelssystem
("EU
ETS")
eller
Schweiz'
emissionshandelssystem ("Schweiz' ETS"). Med henblik på at gennemføre sammenkoblingen af EU
ETS og Schweiz' ETS vil der blive etableret en direkte forbindelse mellem EU-registrets EU-
transaktionsjournal (EUTL) og det schweiziske registers supplerende transaktionsjournal (SSTL),
som vil muliggøre overdragelse af emissionskvoter udstedt i et af ETS'erne mellem registrene
(aftalens artikel 3, stk. 2). For at gennemføre sammenkoblingen af EU ETS og Schweiz' ETS blev der
gennemført en foreløbig løsning i maj 2020. Fra og med 2023 vil registerforbindelsen mellem de to
emissionshandelssystemer gradvis blive udviklet hen imod en permanent registerforbindelse, der
forventes at blive gennemført senet i 2024, og som gør det muligt for de forbundne markeder at
fungere, for så vidt angår fordelene ved markedslikviditet og gennemførelse af transaktioner mellem
de to forbundne systemer på en måde, der svarer til et marked bestående af to systemer, og som gør
det muligt for markedsdeltagerne at handle, som om de befandt sig på ét marked, kun med det
forbehold, at de er underlagt parternes individuelle forskrifter (bilag II til aftalen).
I henhold til aftalens artikel 3, stk. 7, udvikler administratoren af det schweiziske register og den
centrale administrator af EU-registret tekniske standarder for sammenkobling på grundlag af de
principper, der er opstillet i bilag II til aftalen, som beskriver de detaljerede krav til etablering af en
robust og sikker forbindelse mellem SSTL og EUTL. De tekniske standarder for sammenkobling, der
udvikles af administratorerne, træder i kraft, når de er vedtaget ved en afgørelse truffet af det fælles
udvalg.
De tekniske standarder for sammenkobling blev vedtaget af det fælles udvalg ved afgørelse nr.
2/2020. De opdaterede tekniske standarder for sammenkobling, der fremgår af dette dokument, vil
blive vedtaget af det fælles udvalg ved afgørelse nr. 1/2024. I overensstemmelse med denne afgørelse
og efter anmodninger fra det fælles udvalg har administratoren af det schweiziske register og
Unionens centrale administrator udviklet yderligere tekniske retningslinjer for at gennemføre
sammenkoblingen og sikre, at disse løbende tilpasses til den tekniske udvikling og/eller nye krav til
sammenkoblingens sikkerhed og sikring og dens effektive drift.
2.1.
Anvendelsesområde
Dette dokument repræsenterer den fælles forståelse mellem parterne i aftalen om oprettelsen af det
tekniske grundlag for forbindelsen mellem registrene under EU ETS og Schweiz' ETS.
Udgangspunktet for de tekniske specifikationer, hvad angår kravene til arkitektur, tjenester og
sikkerhed, er beskrevet i dokumentet, men der mangler yderligere detaljerede retningslinjer for at
kunne gennemføre sammenkoblingen.
For at sikre korrekt funktion skal der indføres processer og procedurer for yderligere gennemførelse
af sammenkoblingen. I henhold til aftalens artikel 3, stk. 6, beskrives disse spørgsmål nærmere i et
separat dokument med fælles driftsprocedurer (FDP), der vedtages ved afgørelse truffet af det fælles
udvalg.
2.2.
Adressater
Dette dokument er stilet til administratoren af det schweiziske register og den centrale administrator
af EU-registret.
DA
32
DA
 kom (2024) 0125 - Ingen titel
2841386_0034.png
3.
3.1.
A
LMINDELIGE BESTEMMELSER
Kommunikationsforbindelsens arkitektur
Dette afsnit har til formål at beskrive den generelle arkitektur bag gennemførelsen af forbindelsen
mellem EU's ETS og Schweiz' ETS og de forskellige komponenter, der indgår i den.
Sikkerhed indgår som en vigtig del af arkitekturen, og alle foranstaltninger er derfor blevet truffet
med henblik på at skabe en robust arkitektur. Den permanente registerforbindelse anvender en
filudvekslingsmekanisme som gennemførelse af en sikker air gap-forbindelse.
Den tekniske løsning gør brug af:
•
•
•
•
en sikker overførselsprotokol til udveksling af meddelelser
XML-meddelelser
XML-baseret digital signatur og kryptering
VPN.
Udveksling af meddelelser
Følgende figur giver et samlet overblik over den permanente registerforbindelses struktur:
3.1.1.
Kommunikationen mellem EU-registret og det schweiziske register er baseret på en mekanisme til
udveksling af meddelelser via sikrede kanaler. Hver ende råder over et eget datalager for modtagne
meddelelser.
Begge parter fører en journal over de modtagne meddelelser, hvoraf også oplysningerne om
behandlingen fremgår.
Fejl eller uventet status skal indberettes som advarsler, og der bør være menneskelig kontakt mellem
de ansvarlige supporthold.
Fejl og uventede hændelser håndteres under overholdelse af de driftsprocedurer, der er fastlagt i
proceduren for håndtering af hændelser i FDP.
3.1.2.
•
•
•
•
•
XML-meddelelse – beskrivelse på højt plan
En XML-meddelelse indeholder en af følgende:
en eller flere transaktionsanmodninger og/eller et eller flere transaktionssvar
en operation/et svar i forbindelse med afstemning
en testmeddelelse.
Alle meddelelser omfatter et sidehoved med:
ophavs-ETS
sekvensnummer.
Datafangstvinduer
3.1.3.
Den permanente registerforbindelse er baseret på forhåndsfastsatte datafangstvinduer, der efterfølges
af en række navngivne begivenheder. De transaktionsanmodninger, der modtages via forbindelsen,
vil kun blive fanget med på forhånd fastsatte intervaller og omfatter en teknisk validering af
udgående og indgående transaktioner. Desuden kan der på daglig basis foregå afstemninger, og disse
kan tilmed udløses manuelt.
DA
33
DA
 kom (2024) 0125 - Ingen titel
2841386_0035.png
Ændringer i hyppigheden og/eller timingen for hændelser af enhver art håndteres under
overholdelse af de driftsprocedurer, der er fastlagt i proceduren for anmodningsbehandling i
FDP.
3.1.4.
Transaktionsmeddelelsesstrømme
Udgående transaktioner
Dette afspejler det overførende ETS's perspektiv. Den specifikke rækkefølge er vist i følgende
sekvensdiagram:
Basisrækkefølgen viser følgende trin (som på tegningen ovenfor):
(a)
I det overførende ETS sendes transaktionsanmodningen fra registret til
transaktionsjournalen efter alle forretningsmæssige forsinkelser (i givet fald 24 timers
forsinkelse).
Transaktionsjournalen validerer transaktionsanmodningen.
Transaktionsanmodningen sendes til destinations-ETS'et.
Acceptsvaret sendes til registret under ophavs-ETS'et.
Destinations-ETS'et validerer transaktionsanmodningen.
Destinations-ETS'et sender acceptsvaret tilbage til ophavs-ETS'ets transaktionsjournal.
Transaktionsjournalen sender acceptsvaret til registret.
(b)
(c)
(d)
(e)
(f)
(g)
Alternativ rækkefølge "Transaktionsjournal afvisning" (som på tegningen ovenfor, hvor a) er
startpunktet i basisrækkefølgen):
DA
34
DA
 kom (2024) 0125 - Ingen titel
2841386_0036.png
(a)
I
ophavssystemet
sendes
transaktionsanmodningen
fra
registret
til
transaktionsjournalen efter alle forretningsmæssige forsinkelser (i givet fald 24 timers
forsinkelse).
Transaktionsjournalen validerer ikke anmodningen.
Afvisningsmeddelelsen sendes til ophavsregistret.
(b)
(c)
Alternativ rækkefølge "ETS afvisning" (som på tegningen ovenfor, hvor d) er startpunktet i
basisrækkefølgen):
(a)
(b)
(c)
(d)
(e)
(f)
(g)
I ophavs-ETS'et sendes transaktionsanmodningen fra registret til transaktionsjournalen
efter alle forretningsmæssige forsinkelser (i givet fald 24 timers forsinkelse).
Transaktionsjournalen validerer transaktionen.
Transaktionsanmodningen sendes til destinations-ETS'et.
Acceptmeddelelsen sendes til registret under ophavs-ETS'et.
Det modtagende ETS's transaktionsjournal validerer ikke transaktionen.
Det modtagende ETS sender afvisningssvaret til det overførende ETS's
transaktionsjournal
Transaktionsjournalen sender afvisningen til registret.
Indgående transaktioner
DA
35
DA
 kom (2024) 0125 - Ingen titel
2841386_0037.png
Dette afspejler det modtagende ETS's perspektiv. Den specifikke rækkefølge er vist i følgende
sekvensdiagram:
Diagrammet viser:
(1)
Når det modtagende ETS's transaktionsjournal validerer anmodningen, sender den
acceptmeddelelsen til det overførende ETS og en "transaktion gennemført"-
meddelelse til registret under det modtagende ETS.
Hvis en indgående anmodning afvises i den modtagende transaktionsjournal og bliver
afvist, sendes transaktionsanmodningen ikke til registret under det modtagende ETS.
(2)
Protokol
Cyklus for transaktionsmeddelelser omfatter kun to meddelelser:
•
•
Transaktionsforslag fra overførende ETS
→
modtagende ETS.
Transaktionssvar fra modtagende ETS
→
overførende ETS: enten Accepteret eller Afvist
(herunder årsagen til afvisning).
o
Accepteret: Transaktionen er gennemført.
o
Afvist: Transaktionen er afsluttet.
Transaktionsstatus
•
•
•
•
•
•
Transaktionsstatus for det overførende ETS sættes til "foreslået", når anmodningen sendes af
sted.
Transaktionsstatus for det modtagende ETS sættes til "foreslået" ved modtagelse og behandling
af anmodningen.
Transaktionsstatus for det modtagende ETS sættes til "gennemført"/"afsluttet", når forslaget er
blevet behandlet. Det modtagende ETS sender efterfølgende den pågældende accept-
/afvisningsmeddelelse.
Transaktionsstatus for det overførende ETS sættes til gennemført/afsluttet ved modtagelse og
behandling af accepten/afvisningen.
I det overførende ETS angives transaktionsstatus fortsat som foreslået, så længe der ikke er
modtaget et svar.
Det modtagende ETS sætter enhver transaktion, der fortsat er foreslået efter 30 minutter, som
"afsluttet".
Hændelser i forbindelse med transaktioner håndteres under overholdelse af de driftsprocedurer, der er
fastlagt i proceduren for håndtering af hændelser i FDP.
3.2.
Sikker dataoverførsel
Der gælder fire sikkerhedsniveauer for dataoverførsler:
(1)
(2)
(3)
(4)
netadgangskontrol: sammenkoblingslag mellem firewall og netværk
kryptering på transportniveau: VPN.
kryptering på sessionsniveau: sikker overførselsprotokol til udveksling af meddelelser
kryptering på applikationsniveau: kryptering og signering af XML-indhold.
DA
36
DA
 kom (2024) 0125 - Ingen titel
3.2.1.
Sammenkobling mellem firewall og netværk
Sammenkoblingen etableres via et net, der er beskyttet af en hardwarebaseret firewall. Firewallen
skal konfigureres med regler, der sikrer, at kun "registrerede" brugere kan opnå forbindelse til VPN-
serveren.
3.2.2.
Virtuelt privat netværk (VPN)
Al kommunikation mellem parterne skal beskyttes ved hjælp af en sikker datatransportteknologi.
VPN-teknologier giver mulighed for at oprette en "tunnel" gennem et netværk som internettet fra et
punkt til et andet og herved beskytte al kommunikation. Forud for oprettelsen af VPN-tunnelen
udstedes der et digitalt certifikat til et fremadrettet brugerslutpunkt, der giver brugeren mulighed for
at fremlægge identitetsdokumentation under forhandlingerne om forbindelsen. Hver part er ansvarlig
for at installere certifikatet i sit VPN-slutpunkt. Ved hjælp af digitale certifikater vil hver slut-VPN-
server få adgang til en central myndighed til at forhandle autentificeringsdata. Under
tunneloprettelsesprocessen forhandles krypteringen, således at det sikres, at al kommunikation
gennem tunnelen beskyttes.
Brugerens VPN-slutpunkter skal være konfigureret til permanent at opretholde VPN-tunnellen med
henblik på en pålidelig tovejskommunikation i realtid mellem parterne til enhver tid.
Generelt anvender Den Europæiske Union de sikre transeuropæiske tjenester for telematik mellem
administrationerne (STESTA) som et privat IP-baseret netværk. Dette netværk er derfor også egnet
til den permanente registerforbindelse.
3.2.3.
IPSec-implementering
Brugen af IPSec-protokollen til oprettelse af VPN-infrastrukturen mellem stederne sikrer
autentificering mellem stederne, dataintegritet og datakryptering. IPsec-VPN-konfigurationer sørger
for korrekt autentificering mellem to slutpunkter i en VPN-forbindelse. Parterne identificerer og
autentificerer fjernbrugeren via IPSec-forbindelsen ved hjælp af et digitalt certifikat fra en
certifikatmyndighed, der er anerkendt af den anden part.
IPsec sikrer også dataintegritet for al kommunikation gennem VPN-tunnelen. Datapakker hashes og
signeres ved hjælp af autentifikationsinformation som etableret af VPN'en. IPSec-krypteringen sikrer
endvidere datafortrolighed.
3.2.4.
Sikker overførselsprotokol til udveksling af meddelelser
Den permanente registerforbindelse bygger på flere krypteringslag til sikker udveksling af data
mellem parterne. Begge systemer og deres forskellige miljøer er indbyrdes forbundet på netniveau
ved hjælp af VPN-tunneller. På applikationsniveau overføres filerne ved hjælp af en sikker
overførselsprotokol til udveksling af meddelelser på sessionsniveau.
3.2.5.
XML-kryptering og -signatur
I forbindelse med XML-filer sker signering og kryptering på to niveauer. Hver
transaktionsanmodning, hvert transaktionssvar og hver afstemningsmeddelelse signeres digitalt hver
for sig.
På andet trin krypteres hver underdel i "meddelelses-"elementet for sig.
Som tredje trin – for at sikre integriteten og uafviseligheden af hele meddelelsen – signeres
basiselementmeddelelsen digitalt. Dette resulterer i et højt beskyttelsesniveau for de XML-
DA
37
DA
 kom (2024) 0125 - Ingen titel
2841386_0039.png
indbyggede data. Den tekniske implementering overholder standarderne fra World Wide Web
Consortium.
For at dekryptere og kontrollere meddelelsen følges fremgangsmåden i omvendt rækkefølge.
3.2.6.
Krypteringsnøgler
Der gøres brug af offentlig nøglekryptering til kryptering og signering.
I forbindelse med IPSec anvendes der et digitalt certifikat udstedt af en certifikatmyndighed, som
begge parter har tillid til. Denne certifikatmyndighed kontrollerer identiteten og udsteder certifikater,
som anvendes til at identificere en organisation og etablere sikre datakommunikationskanaler mellem
parterne.
Der bruges krypteringsnøgler til signering og kryptering af kommunikationskanaler og datafiler. De
offentlige certifikater udveksles digitalt mellem parterne ved hjælp af sikre kanaler og kontrolleres
separat. Denne procedure er en integreret del af proceduren for informationssikkerhedsstyring i FDP.
3.3.
Liste over funktioner under sammenkoblingen
Sammenkoblingen udgøres af overførselssystemet, som har en række funktioner, der implementerer
forretningsprocesserne i henhold til aftalen. Sammenkoblingen omfatter endvidere specifikationen
for afstemningsprocessen og for de testmeddelelser, der vil gøre det muligt at implementere en
heartbeat-overvågning.
3.3.1.
•
Forretningstransaktioner
Set fra et forretningsperspektiv omfatter sammenkoblingen fire (4) typer af transaktionsanmodninger:
Ekstern overdragelse:
o
Efter ikrafttrædelsen af sammenkoblingen mellem ETS'erne er EU's og CH's kvoter
ombyttelige og kan dermed overdrages fuldt ud mellem parterne.
o
En overdragelse via sammenkoblingen involverer en overdragelseskonto tilknyttet det ene
ETS og en modtagelseskonto tilknyttet det andet ETS.
o
Overdragelsen kan omfatte forskellige mængder af de fire (4) typer af kvoter:
•
•
•
•
•
schweiziske almindelige kvoter (CHU)
schweiziske luftfartskvoter (CHUA)
almindelige EU-kvoter (EUA)
EU-luftfartskvoter (EUAA)
International tildeling:
Luftfartøjsoperatører, der administreres af et ETS med forpligtelser i forhold til det andet ETS, og
som har ret til at modtage gratis kvoter fra det andet ETS, modtager gratis luftfartskvoter fra det
andet ETS gennem den internationale tildelingstransaktion.
•
Tilbageførsel af international tildeling:
Denne transaktion finder sted, hvis de samlede gratis kvoter, der er tildelt en luftfartøjsdriftsleder fra
det andet ETS, skal tilbageføres i deres helhed.
•
Returnering af overskydende tildeling:
DA
38
DA
 kom (2024) 0125 - Ingen titel
2841386_0040.png
Dette minder om en tilbageførsel, men tildelingen skal ikke tilbageføres i sin helhed, og det kun er de
overskydende kvoter, der skal returneres til det tildelende ETS.
3.3.2.
Afstemningsprotokol
Afstemninger vil først finde sted efter afslutning af vinduerne for fangst, validering og behandling af
meddelelser.
Afstemninger er en integreret del af foranstaltningerne vedrørende sikkerhed og overensstemmelse i
forbindelse med sammenkoblingen. Begge parter skal nå til enighed om den nøjagtige timing for
afstemningen, inden der udarbejdes en tidsplan. Der kan finde en planlagt daglig afstemning sted,
hvis begge parter er enige herom. Der vil dog som minimum blive gennemført en planlagt
afstemning, efter at fangsten har fundet sted.
Hver af parterne kan dog på et hvilket som helst tidspunkt indlede manuelle afstemninger.
Ændringer i timingen og hyppigheden for den planlagte afstemning håndteres under overholdelse af
de driftsprocedurer, der er fastlagt i proceduren for anmodningsbehandling i FDP.
3.3.3.
Testmeddelelse
En testmeddelelse har til formål at teste ende til ende-kommunikationen. Meddelelsen omfatter data,
der identificerer meddelelsen som en test, og vil blive besvaret ved den anden endes modtagelse.
3.4.
Krav til journalføring af data
For at støtte begge parters behov for at have adgang til nøjagtige og sammenhængende oplysninger
og for at tilvejebringe værktøjer, der kan anvendes i afstemningsprocessen for at afhjælpe
uoverensstemmelser, arbejder begge parter med fire (4) typer datajournaler:
•
•
•
•
transaktionsjournaler
afstemningsjournaler
meddelelsesarkiv
interne revisionsjournaler.
Alle data i disse journaler skal opbevares i mindst tre (3) måneder med henblik på fejlfinding, og
deres yderligere lagring afhænger af den revisionslovgivning, der finder anvendelse i hver ende.
Journalfiler, der er over tre (3) måneder gamle, kan arkiveres et sikkert sted i et uafhængigt IT-
system, så længe de kan hentes eller tilgås inden for en rimelig periode.
Transaktionsjournaler
Både EUTL- og SSTL-undersystemerne er implementeringer af transaktionsjournaler. Spændt ud
mellem de to ETS-systemer.
Mere specifikt fører transaktionsjournalerne en fortegnelse over hver foreslået transaktion, der er
sendt til det andet ETS. Hver enkelt fortegnelse indeholder hele transaktionens indhold og det
efterfølgende resultat af transaktionen (svaret fra det modtagende ETS). Transaktionsjournalerne
fører også en fortegnelse over de indgående transaktioner samt det svar, der er sendt til ophavs-
ETS'et.
Afstemningsjournaler
DA
39
DA
 kom (2024) 0125 - Ingen titel
Afstemningsjournalen indeholder en fortegnelse over hver afstemningsmeddelelse som udvekslet
mellem begge parter, herunder afstemnings-ID, tidsstempel og resultatet af afstemningen:
afstemningsstatus "Gennemført" eller "Uoverensstemmelser". I det permanente register er
afstemningsmeddelelser en integreret del af de udvekslede meddelelser og lagres derfor som
beskrevet i afsnittet "Meddelelsesarkiv".
Begge parter registrerer hver anmodning og det pågældende svar i afstemningsjournalen. Det kan
være nødvendigt at få adgang til disse oplysninger for at afhjælpe uoverensstemmelser, selv om
oplysningerne i afstemningsjournalen ikke deles direkte som en del af selve afstemningen.
Meddelelsesarkiv
Begge parter skal arkivere en kopi af de udvekslede data (XML-filer), der sendes og modtages, og
hvorvidt disse eller XML-meddelelserne er korrekte i deres format eller ej.
Arkivet er hovedsagelig oprettet til revisionsformål for at kontrollere, hvad der er blevet sendt og
modtaget til og fra den anden part. De relaterede certifikater skal således også arkiveres sammen med
filerne.
Disse filer indeholder endvidere yderligere oplysninger til fejlfinding.
Intern revisionsjournal
Disse journaler defineres og anvendes særskilt af den enkelte part.
3.5.
Driftskrav
Udvekslingen af data mellem de to systemer er ikke fuldstændigt selvkørende i den permanente
registerforbindelse, hvilket betyder, at der skal operatører og procedurer til for at gennemføre
sammenkoblingen. Der er med henblik herpå beskrevet flere roller og værktøjer i denne proces.
DA
40
DA
 kom (2024) 0125 - Ingen titel
4.
4.1.
B
ESTEMMELSER OM TILGÆNGELIGHED
Opbygning af kommunikationens tilgængelighed
Arkitekturen for den permanente registerforbindelse er grundlæggende en IKT-infrastruktur og -
software, der gør det muligt at kommunikere mellem Schweiz' ETS og EU ETS. I forbindelse med
opbygningen af den permanente registerforbindelse bliver det således væsentligt at tage højde for, at
der for denne datastrøm sikres en høj tilgængelighed, integritet og fortrolighed. Da der er tale om et
projekt, hvor IKT-infrastrukturen, den specialdesignede software og processerne spiller en integreret
rolle, skal alle tre elementer tages i betragtning med henblik på at opbygge et modstandsdygtigt
system.
IKT-infrastrukturens modstandsdygtighed
Kapitlet med de almindelige bestemmelser i dette dokument indeholder en nærmere beskrivelse af
arkitekturens elementer. På IKT-infrastruktursiden skaber den permanente registerforbindelse et
modstandsdygtigt VPN-netværk, der etablerer sikre kommunikationstunneler til sikker
meddelelsesudveksling. Der konfigureres andre infrastrukturelementer med en høj tilgængelighed
og/eller understøttet af fallback-mekanismer.
Specialsoftwarens modstandsdygtighed
De specialdesignede softwaremoduler øger modstandsdygtigheden ved at prøve at genopbygge
kommunikationen i en given periode med den anden ende, hvis den af en eller anden grund svigter.
Tjenestens modstandsdygtighed
I den permanente registerforbindelse finder dataudveksling mellem parterne sted med
foruddefinerede intervaller. Nogle af de trin, der er nødvendige i forbindelse med den planlagte
dataudveksling, kræver, at systemoperatører og/eller registeradministratorer manuelt går ind og gør
noget. I lyset af ovenstående og for at øge udvekslingernes tilgængelighed og succes:
•
•
•
•
I henhold til driftsprocedurerne skal der være tid til udførelse af det enkelte trin.
Softwaremodulerne til den permanente registerforbindelse gennemfører asynkron
kommunikation.
Den automatiske afstemningsproces registrerer, om der var problemer med at fange datafiler i en
af enderne.
Overvågningsprocesser (IKT-infrastruktur og specialdesignede softwaremoduler) spiller ind og
udløser procedurer til håndtering af hændelser (som defineret i dokumentet om de fælles
driftsprocedurer). Disse procedurer, der har til formål at reducere den tid, det tager at genetablere
normal drift efter hændelser, er af afgørende betydning for at sikre en høj grad af tilgængelighed.
Initialiserings-, kommunikations-, genaktiverings- og testplan
4.2.
Alle de forskellige elementer, der indgår i den permanente registerforbindelses arkitektur, skal
gennemgå en række individuelle og kollektive test til bekræftelse af, at platformen er klar på IKT-
infrastruktur- og informationssystemniveau. Disse driftstest er en obligatorisk forudsætning, hver
gang platformen overgår fra suspenderet til driftsstatus for den permanente registerforbindelse.
For at aktivere driftsstatus for sammenkoblingen skal der gennemføres en forud fastlagt testplan.
Dette skal bekræfte, at hvert register har gennemgået en række interne test først, efterfulgt af en
validering af ende til ende-konnektiviteten inden indgivelse af produktionstransaktioner mellem
begge parter.
DA
41
DA
 kom (2024) 0125 - Ingen titel
Testplanen bør indeholde den overordnede teststrategi og nærmere
testinfrastrukturen. For hvert element i hver testblok bør den navnlig omfatte:
•
•
•
•
•
•
•
testkriterier og -værktøjer
tildelte roller til gennemførelse af testen
forventede resultater (positive og negative)
tidsplan for testen
journalføring af krav til testresultaterne
dokumentation af fejlfinding
eskaleringsbestemmelser.
oplysninger
om
Som proces kan test til aktivering af driftsstatus opdeles i fire (4) konceptblokke eller faser:
4.2.1.
Interne IKT-infrastrukturtest
Disse test skal udføres og/eller kontrolleres individuelt af registeradministratorer i hver ende.
Alle IKT-infrastrukturens elementer i hver ende skal testes hver for sig. Dette omfatter hver enkelt
komponent af infrastrukturen. Disse test kan udføres automatisk eller manuelt, men skal kontrollere,
at alle infrastrukturens elementer er operationelle.
4.2.2.
Kommunikationstest
Disse test indledes individuelt hos hver part og afsluttes i samarbejde med den anden ende.
Når de enkelte elementer er operationelle, skal kommunikationskanalerne mellem de to registre
testes. Med henblik herpå skal hver part kontrollere, at der er internetadgang, at der er oprettet VPN-
tunneller, og at der er etableret IP-konnektivitet mellem de enkelte steder. Sikring af adgang til lokale
og fjerntliggende infrastrukturelementer og IP-konnektivitet bør derefter bekræftes over for den
anden ende.
4.2.3.
Fulde systemtest (ende til ende)
Disse test skal udføres i hver ende, og resultaterne deles med den anden part.
Når kommunikationskanalerne og hver enkelt komponent i begge registre er blevet testet, skal hver
ende forberede en række simulerede transaktioner og afstemninger, som er repræsentative for alle de
funktioner, der skal implementeres under sammenkoblingen.
4.2.4.
Sikkerhedstest
Disse test skal udføres og/eller udløses af registeradministratorer i hver ende og som beskrevet i
afsnittet "Retningslinjer for sikkerhedstest" og "Bestemmelser om risikovurdering".
Først når hver af de fire faser/blokke er afsluttet med forudsigelige resultater, kan den permanente
registerforbindelse betragtes som operationel.
Testressourcer
Hver part skal råde over specifikke testressourcer (specifik IKT-infrastruktursoftware og -hardware)
og skal udvikle testfunktioner i deres respektive systemer for at støtte den manuelle og kontinuerlige
validering af platformen. Registeradministratorerne kan til enhver tid udføre manuelle individuelle
eller samarbejdsbaserede testprocedurer. Selve aktiveringen af driftsstatus er en manuel proces.
DA
42
DA
 kom (2024) 0125 - Ingen titel
Det er ligeledes meningen, at platformen med jævne mellemrum skal udføre automatiske kontroller.
Formålet med disse kontroller er at øge platformens tilgængelighed ved at opdage tidlige potentielle
infrastruktur- eller softwareproblemer. Denne platformovervågningsplan består af to elementer:
•
•
overvågning
af
IKT-infrastrukturer:
Infrastrukturen
overvåges
af
IKT-
infrastrukturtjenesteudbydere i hver ende. De automatiske test omfatter de forskellige
infrastrukturelementer og kommunikationskanalernes tilgængelighed
overvågning af applikationer: Softwaremodulerne til den permanente registersammenkobling
implementerer overvågningen af systemkommunikationen på applikationsniveau (enten manuelt
og/eller med regelmæssige mellemrum), som tester sammenkoblingens ende til ende-
tilgængelighed ved at simulere nogle af transaktionerne via sammenkoblingen.
Godkendelses-/testmiljøer
4.3.
•
•
•
EU-registrets og det schweiziske registers arkitektur består af følgende tre miljøer:
produktion (PROD): Dette miljø omfatter de reelle data og behandler de reelle transaktioner
godkendelse (ACC): Dette miljø omfatter ikkereelle eller anonymiserede, repræsentative data.
Begge parters systemoperatører validerer nye frigivelser inden for dette miljø
test (TEST): Dette miljø omfatter ikkereelle eller anonymiserede, repræsentative data. Dette miljø
er begrænset til registeradministratorer og skal bruges, så begge parter kan udføre
integrationstest.
Bortset fra VPN fungerer de tre miljøer helt uafhængigt af hinanden, dvs. hardware, software,
databaser, virtuelle miljøer, IP-adresser og porte etableres og drives uafhængigt af hinanden.
Hvad angår VPN-opbygningen, skal kommunikationen mellem de tre miljøer være fuldstændig
uafhængig, hvilket sikres ved hjælp af STESTA.
5.
B
ESTEMMELSER OM FORTROLIGHED OG INTEGRITET
Der er to personer involveret i sikkerhedsmekanismer og -procedurer (fire øjne-princippet) i
forbindelse med operationer knyttet til forbindelsen mellem EU-registret og det schweiziske register.
Inddragelsen af to personer gælder, når det er nødvendigt, men finder muligvis ikke anvendelse på
alle de trin, som registeradministratorerne udfører.
Der tages højde for sikkerhedskravene, som behandles i sikkerhedsstyringsplanen, der også omfatter
processer i forbindelse med håndtering af sikkerhedshændelser efter et eventuelt sikkerhedsbrud. Den
operationelle del af disse processer er beskrevet i de FDP.
5.1.
Sikkerhedstestinfrastruktur
Hver part forpligter sig til at oprette en sikkerhedstestinfrastruktur (ved hjælp af den fælles software
og hardware, der anvendes til registrering af sårbarheder i udviklings- og driftsfasen):
•
•
Denne adskiller sig fra produktionsmiljøet.
Her analyseres sikkerheden af et team, der er uafhængigt af systemets udvikling og drift.
Hver part forpligter sig til både at foretage statiske og dynamiske analyser.
I tilfælde af dynamiske analyser (såsom penetrationstest) forpligter begge parter sig til almindeligvis
at begrænse evalueringerne til godkendelses- og testmiljøer (som defineret i afsnittet "Godkendelses-
/testmiljøer"). Undtagelser fra denne politik skal godkendes af begge parter.
DA
43
DA
 kom (2024) 0125 - Ingen titel
2841386_0045.png
Inden ibrugtagningen i produktionsmiljøet skal alle sammenkoblingens softwaremoduler (som
defineret i afsnittet "Kommunikationsforbindelsens arkitektur") være sikkerhedstestet.
Testinfrastrukturen skal på både net- og infrastrukturniveau være adskilt fra
produktionsinfrastrukturen og give mulighed for at udføre de sikkerhedstest, der er nødvendige for at
kontrollere, at sikkerhedskravene overholdes.
5.2.
Bestemmelser om suspension og genaktivering af sammenkoblingen
Hvis der er mistanke om, at sikkerheden for Schweiz' register, SSTL, EU-registret eller EUTL er
blevet kompromitteret, skal hver part straks underrette den anden part og suspendere forbindelsen
mellem SSTL og EUTL.
Procedurerne for udveksling af oplysninger, beslutning om suspension og genaktivering indgår i
proceduren for anmodningsbehandling i FDP.
Suspensioner
Suspension af registerforbindelsen i overensstemmelse med bilag II til aftalen kan ske af:
•
•
administrative årsager (vedligeholdelse, ...) og er derfor planlagt
sikkerhedsmæssige årsager (eller IT-infrastruktursvigt) og er derfor ikke planlagt.
I nødsituationer underretter hver part den anden part og suspenderer ensidigt registerforbindelsen.
Hvis der træffes beslutning om suspension af registerforbindelsen, sikrer hver part, at forbindelsen
afbrydes på netniveau (ved at blokere dele eller alle indgående og udgående forbindelser).
Beslutningen om at suspendere registerforbindelsen – hvad enten det er planlagt eller ikke er planlagt
– træffes i overensstemmelse med proceduren for ændringsstyring eller håndtering af
sikkerhedshændelser i FDP.
Genaktivering af kommunikationen
Genaktiveringsbeslutningen træffes som beskrevet i FDP og under alle omstændigheder ikke før, der
er gennemført en vellykket sikkerhedstestprocedure som beskrevet i afsnittet "Retningslinjer for
sikkerhedstest" og "Initialiserings-, kommunikations-, genaktiverings- og testplan".
5.3.
Bestemmelser om sikkerhedsbrud
Et brud på sikkerheden betragtes som en sikkerhedshændelse, der påvirker fortroligheden og
integriteten af følsomme oplysninger og/eller tilgængeligheden af det system, der håndterer dem.
Følsomme oplysninger identificeres i listen over følsomme oplysninger og kan håndteres i systemet
eller dele heraf.
Oplysninger, der er direkte relateret til sikkerhedsbruddet, betragtes som følsomme, mærkes med
"SPECIAL
HANDLING:
ETS
Critical"og
håndteres
i
overensstemmelse
med
håndteringsinstrukserne, medmindre andet er anført.
Ethvert brud på sikkerheden håndteres i overensstemmelse med kapitlet om håndtering af
sikkerhedshændelser i FDP.
DA
44
DA
 kom (2024) 0125 - Ingen titel
5.4.
5.4.1.
Retningslinjer for sikkerhedstest
Software
Sikkerhedstesten, herunder i givet fald penetrationstest, skal som minimum udføres på alle nye større
frigivelser af software i overensstemmelse med de sikkerhedskrav, der er fastsat i de tekniske
standarder for sammenkobling, for at vurdere sammenkoblingens sikkerhed og de dermed forbundne
risici.
Hvis der ikke er blevet produceret nogen større frigivelse inden for de sidste 12 måneder, foretages
der sikkerhedstest af det nuværende system under hensyntagen til den udvikling i cybertrusler, der
har fundet sted de seneste 12 måneder.
Sikkerhedstesten af registerforbindelsen skal foregå i godkendelsesmiljøet og om nødvendigt i
produktionsmiljøet og skal koordineres med og aftales mellem begge parter.
Webapplikationstest skal overholde de internationale åbne standarder som dem, der er udviklet af
Open Web Application Security Project (OWASP).
5.4.2.
Infrastruktur
Den infrastruktur, der understøtter produktionssystemet, skal regelmæssigt scannes for sårbarheder
(mindst en gang om måneden), og de registrerede sårbarheder skal afhjælpes i henhold til samme
princip som defineret i det foregående afsnit ved hjælp af en ajourført sårbarhedsdatabase.
5.5.
Bestemmelser om risikovurdering
Hvis der skal gennemføres en penetrationstest, skal denne indgå i sikkerhedstesten.
Hver part kan bestille en specialiseret virksomhed til at udføre sikkerhedstesten, forudsat at denne
virksomhed:
•
•
•
råder over færdigheder og erfaringer inden for en sådan sikkerhedstest
ikke direkte rapporterer til udvikleren og/eller dennes kontrahent og hverken er involveret i
udviklingen af sammenkoblingssoftwaren eller er underkontrahent til udvikleren
har underskrevet fortrolighedsaftalen med henblik på at holde resultaterne fortrolige og behandle
dem på niveauet "SPECIAL HANDLING: ETS Critical" i overensstemmelse med
håndteringsinstrukserne.
DA
45
DA