Übersetzungen exportieren
Aus RI Wiki
Zur Navigation springen
Zur Suche springen
Einstellungen
Gruppe
Critical Entities‘ Resilience Directive (CER)
Cyber Resilience Act (CRA)
Cyber Security Act (CSA)
Cyber Solidarity Act
Cybersecurity
Digital Operational Resilienec Act (DORA)
Hauptseite
Network and Information Security Directive (NIS2-RL)
Sprache
aa - Afar
aae - Arbëresh
ab - Abkhazian
abs - Ambonese Malay
ace - Acehnese
acf - Saint Lucian Creole
acm - Iraqi Arabic
ady - Adyghe
ady-cyrl - Adyghe (Cyrillic script)
aeb - Tunisian Arabic
aeb-arab - Tunisian Arabic (Arabic script)
aeb-latn - Tunisian Arabic (Latin script)
af - Afrikaans
aln - Gheg Albanian
alt - Southern Altai
am - Amharic
ami - Amis
an - Aragonese
ang - Old English
ann - Obolo
anp - Angika
apc - Levantine Arabic
ar - Arabic
arc - Aramaic
arn - Mapuche
arq - Algerian Arabic
ary - Moroccan Arabic
arz - Egyptian Arabic
as - Assamese
ase - American Sign Language
ast - Asturian
atj - Atikamekw
av - Avaric
avk - Kotava
awa - Awadhi
ay - Aymara
az - Azerbaijani
azb - South Azerbaijani
ba - Bashkir
ban - Balinese
ban-bali - Balinese (Balinese script)
bar - Bavarian
bbc - Batak Toba
bbc-latn - Batak Toba (Latin script)
bcc - Southern Balochi
bci - Baoulé
bcl - Central Bikol
bdr - West Coast Bajau
be - Belarusian
be-tarask - Belarusian (Taraškievica orthography)
bew - Betawi
bg - Bulgarian
bgc - Haryanvi
bgn - Western Balochi
bh - Bhojpuri
bho - Bhojpuri
bi - Bislama
bjn - Banjar
blk - Pa'O
bm - Bambara
bn - Bangla
bo - Tibetan
bpy - Bishnupriya
bqi - Bakhtiari
br - Breton
brh - Brahui
bs - Bosnian
btm - Batak Mandailing
bto - Rinconada Bikol
bug - Buginese
bxr - Russia Buriat
ca - Catalan
cbk-zam - Chavacano
ccp - Chakma
cdo - Mindong
ce - Chechen
ceb - Cebuano
ch - Chamorro
chn - Chinook Jargon
cho - Choctaw
chr - Cherokee
chy - Cheyenne
ckb - Central Kurdish
co - Corsican
cps - Capiznon
cpx - Puxian
cpx-hans - Puxian (Simplified Han script)
cpx-hant - Puxian (Traditional Han script)
cpx-latn - Puxian (Latin script)
cr - Cree
crh - Crimean Tatar
crh-cyrl - Crimean Tatar (Cyrillic script)
crh-latn - Crimean Tatar (Latin script)
crh-ro - Dobrujan Tatar
cs - Czech
csb - Kashubian
cu - Church Slavic
cv - Chuvash
cy - Welsh
da - Danish
dag - Dagbani
de - German
de-at - Austrian German
de-ch - Swiss High German
de-formal - German (formal address)
dga - Southern Dagaare
din - Dinka
diq - Dimli
dsb - Lower Sorbian
dtp - Central Dusun
dty - Doteli
dua - Duala
dv - Divehi
dz - Dzongkha
ee - Ewe
efi - Efik
egl - Emilian
el - Greek
eml - Emiliano-Romagnolo
en - English
en-ca - Canadian English
en-gb - British English
eo - Esperanto
es - Spanish
es-419 - Latin American Spanish
es-formal - Spanish (formal address)
et - Estonian
eu - Basque
ext - Extremaduran
fa - Persian
fat - Fanti
ff - Fula
fi - Finnish
fit - Tornedalen Finnish
fj - Fijian
fo - Faroese
fon - Fon
fr - French
frc - Cajun French
frp - Arpitan
frr - Northern Frisian
fur - Friulian
fy - Western Frisian
ga - Irish
gaa - Ga
gag - Gagauz
gan - Gan
gan-hans - Gan (Simplified Han script)
gan-hant - Gan (Traditional Han script)
gcf - Guadeloupean Creole
gcr - Guianan Creole
gd - Scottish Gaelic
gl - Galician
gld - Nanai
glk - Gilaki
gn - Guarani
gom - Goan Konkani
gom-deva - Goan Konkani (Devanagari script)
gom-latn - Goan Konkani (Latin script)
gor - Gorontalo
got - Gothic
gpe - Ghanaian Pidgin
grc - Ancient Greek
gsw - Alemannic
gu - Gujarati
guc - Wayuu
gur - Frafra
guw - Gun
gv - Manx
ha - Hausa
hak - Hakka Chinese
hak-hans - Hakka (Simplified Han script)
hak-hant - Hakka (Traditional Han script)
hak-latn - Hakka (Latin script)
haw - Hawaiian
he - Hebrew
hi - Hindi
hif - Fiji Hindi
hif-latn - Fiji Hindi (Latin script)
hil - Hiligaynon
hno - Northern Hindko
ho - Hiri Motu
hr - Croatian
hrx - Hunsrik
hsb - Upper Sorbian
hsn - Xiang
ht - Haitian Creole
hu - Hungarian
hu-formal - Hungarian (formal address)
hy - Armenian
hyw - Western Armenian
hz - Herero
ia - Interlingua
iba - Iban
ibb - Ibibio
id - Indonesian
ie - Interlingue
ig - Igbo
igl - Igala
ii - Sichuan Yi
ik - Inupiaq
ike-cans - Eastern Canadian (Aboriginal syllabics)
ike-latn - Eastern Canadian (Latin script)
ilo - Iloko
inh - Ingush
io - Ido
is - Icelandic
isv-cyrl - Interslavic (Cyrillic script)
isv-latn - Interslavic (Latin script)
it - Italian
iu - Inuktitut
ja - Japanese
jam - Jamaican Creole English
jbo - Lojban
jut - Jutish
jv - Javanese
ka - Georgian
kaa - Kara-Kalpak
kab - Kabyle
kai - Karekare
kbd - Kabardian
kbd-cyrl - Kabardian (Cyrillic script)
kbp - Kabiye
kcg - Tyap
kea - Kabuverdianu
kg - Kongo
kge - Komering
khw - Khowar
ki - Kikuyu
kiu - Kirmanjki
kj - Kuanyama
kjh - Khakas
kjp - Eastern Pwo
kk - Kazakh
kk-arab - Kazakh (Arabic script)
kk-cn - Kazakh (China)
kk-cyrl - Kazakh (Cyrillic script)
kk-kz - Kazakh (Kazakhstan)
kk-latn - Kazakh (Latin script)
kk-tr - Kazakh (Turkey)
kl - Kalaallisut
km - Khmer
kn - Kannada
knc - Central Kanuri
ko - Korean
ko-kp - Korean (North Korea)
koi - Komi-Permyak
kr - Kanuri
krc - Karachay-Balkar
kri - Krio
krj - Kinaray-a
krl - Karelian
ks - Kashmiri
ks-arab - Kashmiri (Arabic script)
ks-deva - Kashmiri (Devanagari script)
ksh - Colognian
ksw - S'gaw Karen
ku - Kurdish
ku-arab - Kurdish (Arabic script)
ku-latn - Kurdish (Latin script)
kum - Kumyk
kus - Kusaal
kv - Komi
kw - Cornish
ky - Kyrgyz
la - Latin
lad - Ladino
lb - Luxembourgish
lbe - Lak
lez - Lezghian
lfn - Lingua Franca Nova
lg - Ganda
li - Limburgish
lij - Ligurian
liv - Livonian
lki - Laki
lld - Ladin
lmo - Lombard
ln - Lingala
lo - Lao
loz - Lozi
lrc - Northern Luri
lt - Lithuanian
ltg - Latgalian
lua - Luba-Lulua
lus - Mizo
luz - Southern Luri
lv - Latvian
lzh - Literary Chinese
lzz - Laz
mad - Madurese
mag - Magahi
mai - Maithili
map-bms - Banyumasan
mdf - Moksha
mg - Malagasy
mh - Marshallese
mhr - Eastern Mari
mi - Māori
min - Minangkabau
mk - Macedonian
ml - Malayalam
mn - Mongolian
mnc - Manchu
mnc-latn - Manchu (Latin script)
mnc-mong - Manchu (Mongolian script)
mni - Manipuri
mnw - Mon
mo - Moldovan
mos - Mossi
mr - Marathi
mrh - Mara
mrj - Western Mari
ms - Malay
ms-arab - Malay (Jawi script)
mt - Maltese
mui - Musi
mus - Muscogee
mwl - Mirandese
my - Burmese
myv - Erzya
mzn - Mazanderani
na - Nauru
nah - Nahuatl
nan - Minnan
nan-hant - Minnan (Traditional Han script)
nan-latn-pehoeji - Minnan (Pe̍h-ōe-jī)
nan-latn-tailo - Minnan (Tâi-lô)
nap - Neapolitan
nb - Norwegian Bokmål
nds - Low German
nds-nl - Low Saxon
ne - Nepali
new - Newari
ng - Ndonga
nia - Nias
nit - Southeastern Kolami
niu - Niuean
nl - Dutch
nl-informal - Dutch (informal address)
nmz - Nawdm
nn - Norwegian Nynorsk
no - Norwegian
nod - Northern Thai
nog - Nogai
nov - Novial
nqo - N’Ko
nr - South Ndebele
nrm - Norman
nso - Northern Sotho
nup - Nupe
nv - Navajo
ny - Nyanja
nyn - Nyankole
nyo - Nyoro
nys - Nyungar
oc - Occitan
ojb - Northwestern Ojibwa
olo - Livvi-Karelian
om - Oromo
or - Odia
os - Ossetic
pa - Punjabi
pag - Pangasinan
pam - Pampanga
pap - Papiamento
pcd - Picard
pcm - Nigerian Pidgin
pdc - Pennsylvania German
pdt - Plautdietsch
pfl - Palatine German
pi - Pali
pih - Pitcairn-Norfolk
pl - Polish
pms - Piedmontese
pnb - Western Punjabi
pnt - Pontic
prg - Prussian
ps - Pashto
pt - Portuguese
pt-br - Brazilian Portuguese
pwn - Paiwan
qqq - Message documentation
qu - Quechua
qug - Chimborazo Highland Quichua
rgn - Romagnol
rif - Riffian
rki - Arakanese
rm - Romansh
rmc - Carpathian Romani
rmy - Vlax Romani
rn - Rundi
ro - Romanian
roa-tara - Tarantino
rsk - Pannonian Rusyn
ru - Russian
rue - Rusyn
rup - Aromanian
ruq - Megleno-Romanian
ruq-cyrl - Megleno-Romanian (Cyrillic script)
ruq-latn - Megleno-Romanian (Latin script)
rut - Rutul
rw - Kinyarwanda
ryu - Okinawan
sa - Sanskrit
sah - Yakut
sat - Santali
sc - Sardinian
scn - Sicilian
sco - Scots
sd - Sindhi
sdc - Sassarese Sardinian
sdh - Southern Kurdish
se - Northern Sami
se-fi - Northern Sami (Finland)
se-no - Northern Sami (Norway)
se-se - Northern Sami (Sweden)
sei - Seri
ses - Koyraboro Senni
sg - Sango
sgs - Samogitian
sh - Serbo-Croatian
sh-cyrl - Serbo-Croatian (Cyrillic script)
sh-latn - Serbo-Croatian (Latin script)
shi - Tachelhit
shi-latn - Tachelhit (Latin script)
shi-tfng - Tachelhit (Tifinagh script)
shn - Shan
shy - Shawiya
shy-latn - Shawiya (Latin script)
si - Sinhala
simple - Simple English
sjd - Kildin Sami
sje - Pite Sami
sk - Slovak
skr - Saraiki
skr-arab - Saraiki (Arabic script)
sl - Slovenian
sli - Lower Silesian
sm - Samoan
sma - Southern Sami
smn - Inari Sami
sms - Skolt Sami
sn - Shona
so - Somali
sq - Albanian
sr - Serbian
sr-ec - Serbian (Cyrillic script)
sr-el - Serbian (Latin script)
srn - Sranan Tongo
sro - Campidanese Sardinian
ss - Swati
st - Southern Sotho
stq - Saterland Frisian
sty - Siberian Tatar
su - Sundanese
sv - Swedish
sw - Swahili
syl - Sylheti
szl - Silesian
szy - Sakizaya
ta - Tamil
tay - Atayal
tcy - Tulu
tdd - Tai Nuea
te - Telugu
tet - Tetum
tg - Tajik
tg-cyrl - Tajik (Cyrillic script)
tg-latn - Tajik (Latin script)
th - Thai
ti - Tigrinya
tig - Tigre
tk - Turkmen
tl - Tagalog
tly - Talysh
tly-cyrl - Talysh (Cyrillic script)
tn - Tswana
to - Tongan
tok - Toki Pona
tpi - Tok Pisin
tr - Turkish
tru - Turoyo
trv - Taroko
ts - Tsonga
tt - Tatar
tt-cyrl - Tatar (Cyrillic script)
tt-latn - Tatar (Latin script)
ttj - Tooro
tum - Tumbuka
tw - Twi
ty - Tahitian
tyv - Tuvinian
tzm - Central Atlas Tamazight
udm - Udmurt
ug - Uyghur
ug-arab - Uyghur (Arabic script)
ug-latn - Uyghur (Latin script)
uk - Ukrainian
ur - Urdu
uz - Uzbek
uz-cyrl - Uzbek (Cyrillic script)
uz-latn - Uzbek (Latin script)
ve - Venda
vec - Venetian
vep - Veps
vi - Vietnamese
vls - West Flemish
vmf - Main-Franconian
vmw - Makhuwa
vo - Volapük
vot - Votic
vro - Võro
wa - Walloon
wal - Wolaytta
war - Waray
wls - Wallisian
wo - Wolof
wuu - Wu
wuu-hans - Wu (Simplified Han script)
wuu-hant - Wu (Traditional Han script)
xal - Kalmyk
xh - Xhosa
xmf - Mingrelian
xsy - Saisiyat
yi - Yiddish
yo - Yoruba
yrl - Nheengatu
yue - Cantonese
yue-hans - Cantonese (Simplified Han script)
yue-hant - Cantonese (Traditional Han script)
za - Zhuang
zea - Zeelandic
zgh - Standard Moroccan Tamazight
zgh-latn - Standard Moroccan Tamazight (Latin script)
zh - Chinese
zh-cn - Chinese (China)
zh-hans - Simplified Chinese
zh-hant - Traditional Chinese
zh-hk - Chinese (Hong Kong)
zh-mo - Chinese (Macau)
zh-my - Chinese (Malaysia)
zh-sg - Chinese (Singapore)
zh-tw - Chinese (Taiwan)
zu - Zulu
Format
Für die Offline-Übersetzung exportieren
Im systemeigenen Format exportieren
Im CSV-Format exportieren
Hole
<languages/> {{Infobox Rechtsakt (EU)|Typ=Verordnung|Jahr=2022|Nummer=2554|Vertrag=EU|EWR=ja|Titel=Verordnung (EU) 2022/2554 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 über die digitale operationale Resilienz im Finanzsektor und zur Änderung der Verordnungen (EG) Nr. 1060/2009, (EU) Nr. 648/2012, (EU) Nr. 600/2014, (EU) Nr. 909/2014 und (EU) 2016/1011|Kurztitel=Digital Operational Resilienec Act|Bezeichnung=DORA|Rechtsmaterie=Binnenmarkt, Cybersicherheit|Grundlage=AEUV, insbesondere {{Art.|114|AEUV|dejure|}} <div lang="de" dir="ltr" class="mw-content-ltr"> |Fundstelle=ABl L 2022/333, 1|Anzuwenden=17. Januar 2025|Gültig=anwendbar}} </div> <div lang="de" dir="ltr" class="mw-content-ltr"> == Kurzübersicht == </div> <div lang="de" dir="ltr" class="mw-content-ltr"> {| class="wikitable" |+ !Ziele !Anwendungsbereich !Inhalt !Synergie !Konsequenzen |- |Operationale Resilienz im Finanzsektor stärken |Finanzunternehmen |Management von IKT-Risiken und Vorfällen |NIS2-RL |National festgelegte Verwaltungsstrafen gegen Finanzunternehmen<ref>DORA-Vollzugsgesetz (DORA-VG) https://www.parlament.gv.at/gegenstand/XXVII/I/2596.</ref> |- | |IKT-Dienstleister |Prüfung digitaler Betriebsstbilität |DSGVO |Geldstrafe von bis zu 1 % des durchschnittlichen täglichen weltweiten Umsatzes gegen Drittdienstleister |- | | |Lieferkettenmanagement | |Veröffentlichung von Strafen |- | | |Informationsaustausch | | |} </div> <div lang="de" dir="ltr" class="mw-content-ltr"> == Einführung == </div> <div lang="de" dir="ltr" class="mw-content-ltr"> Die DORA-Verordnung (Digital Operational Resilience Act) ist eine umfassende Regelung zur digitalen Resilienz, die speziell für den '''Finanzsektor''' der Europäischen Union entwickelt wurde. Sie ergänzt bestehende Regelungen und baut auf bekannten Konzepten wie Informationssicherheit, Datenschutz und Risikomanagement auf, um die Widerstandsfähigkeit gegenüber IKT-Risiken zu stärken. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> Gleichzeitig mit DORA wurde die Richtlinie 2022/2556 hinsichtlich der digitalen operationalen Resilienz im Finanzsektor („'''DORA-RL'''“)<ref>RL (E) 2022/2556 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 zur Änderung der Richtlinien 2009/65/EG, 2009/138/EG, 2011/61/EU, 2013/36/EU, 2014/59/EU, 2014/65/EU, (EU) 2015/2366 und (EU) 2016/2341 hinsichtlich der digitalen operationalen Resilienz im Finanzsektor, ABl L 2022/333, 153.</ref> sowie Richtlinie (EU) 2022/2557 über die [[Special:MyLanguage/Critical Entities‘ Resilience Directive (CER)|Resilienz kritischer Einrichtungen]], welche einzelne Anpassungen von mehreren Richtlinien, vorsieht, erlassen. Die ab dem 17. 1. 2025 anwendbare DORA-RL muss von den EU-Mitgliedstaaten in nationales Recht umgesetzt werden. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> Die '''Delegierte Verordnung''' (EU) 2024/1774 vom 13. März 2024 ergänzt die DORA zusätzlich. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> Im Verhältnis zur NIS2-RL nimmt DORA eine besondere Stellung ein, da sie gemäß ErwGr 16 DORA als lex specialis gilt und somit Vorrang vor NIS2-RL hat. Diese Vorrangstellung von DORA bedeutet, dass für Finanzunternehmen primär die DORA-Vorschriften maßgeblich sind. In Bereichen, in denen NIS2-RL spezifischere Regelungen als DORA vorsieht, gelten diese NIS2-Vorschriften ergänzend zu DORA. Die Implementierung von DORA und Umsetzungsgesetzgebung zu NIS2 hat auch Auswirkungen auf nationale Regularien und Anforderungsvorgaben. Bestehende nationale Vorschriften (Oktober 2024 ist die NIS2-RL in Österreich noch nicht umgesetzt), sie diese beachtlich. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> == Anwendungsbereich == </div> <div lang="de" dir="ltr" class="mw-content-ltr"> ==== Persönlicher / Sachlicher Anwendungsbereich ==== </div> <div lang="de" dir="ltr" class="mw-content-ltr"> DORA ist auf in Art 2 Abs 1 lit a bis t DORA angeführte Tätigkeitsbereiche (sog. „'''Finanzunternehmen'''“) anwendbar. Hierzu zählen (a) Kreditinstitute, (b) Zahlungsinstitute, einschließlich gemäß der Richtlinie (EU) 2015/2366 ausgenommene Zahlungsinstitute, (c) Kontoinformationsdienstleister, (d) E-Geld-Institute, einschließlich gemäß der Richtlinie 2009/110/EG ausgenommene E-Geld-Institute, (e) Wertpapierfirmen, (f) Anbieter von Krypto-Dienstleistungen, die gemäß der sogenannten „Verordnung über Märkte von Krypto-Werten“ zugelassen sind, und Emittenten wertreferenzierter Token, (g) Zentralverwahrer, (h) zentrale Gegenparteien, (i) Handelsplätze, (j) Transaktionsregister, (k) Verwalter alternativer Investmentfonds, (l) Verwaltungsgesellschaften, (m) Datenbereitstellungsdienste, (n) Versicherungs- und Rückversicherungsunternehmen, (o) Versicherungsvermittler, Rückversicherungsvermittler und Versicherungsvermittler in Nebentätigkeit, (p) Einrichtungen der betrieblichen Altersversorgung, (q) Ratingagenturen, (r) Administratoren kritischer Referenzwerte, (s) Schwarmfinanzierungsdienstleister und (t) Verbriefungsregister. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> Darüber hinaus sind Unternehmen erfasst, die IT-Leistungen an Finanzunternehmen erbringen (sog. „IKT-Drittdienstleister“), wie etwa Cloud-Anbieter. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> '''Ausnahmen''' </div> <div lang="de" dir="ltr" class="mw-content-ltr"> Außerhalb des Anwendungsbereichs stehen zudem gemäß Art 2 Abs 3 (a) Verwalter alternativer Investmentfonds im Sinne von Art 3 Abs 2 der Richtlinie 2011/61/EU, (b) Versicherungs- und Rückversicherungsunternehmen im Sinne von Art 4 der Richtlinie 2009/138/EG, (c) Einrichtungen der betrieblichen Altersversorgung, die Altersversorgungssysteme mit insgesamt weniger als 15 Versorgungsanwärtern betreiben, (d) gemäß den Artikeln 2 und 3 der Richtlinie 2014/65/EU ausgenommene natürliche oder juristische Personen, (e) Versicherungsvermittler, Rückversicherungsvermittler und Versicherungsvermittler in Nebentätigkeit, bei denen es sich um Kleinstunternehmen oder kleine oder mittlere Unternehmen handelt, sowie (f) Postgiroämter im Sinne von Art 2 Abs 5 Z 3 der Richtlinie 2013/36/EU. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> Weitreichende Ausnahmen von den Verpflichtungen bestehen für Kleinstunternehmen (dh Finanzunternehmen, die weniger als zehn Personen beschäftigen und deren Jahresumsatz bzw. -bilanzsumme 2 Mio EUR nicht überschreitet). </div> <div lang="de" dir="ltr" class="mw-content-ltr"> DORA betrifft '''alle Finanzinstitute''', wenn sie in den Anwendungsbereich fallen, unabhängig von ihrer Größe oder Struktur. Eine Einschränkung des Scopes auf lokaler Ebene ist nicht möglich. Die Begriffsdefinitionen, zB "kritische Dienste" und "wesentliche Dienste", können nicht modifiziert werden. Wenn ein Unternehmen betroffen ist, dann in seiner Gesamtheit, einschließlich etwaiger Tochtergesellschaften oder Nebentätigkeiten (theoretisch auch der Betriebskindergärten). </div> <div lang="de" dir="ltr" class="mw-content-ltr"> ==== Territorialer Anwendungsbereich ==== </div> <div lang="de" dir="ltr" class="mw-content-ltr"> Der territoriale Anwendungsbereich des DORA umfasst primär alle Finanzunternehmen und relevante IKT-Dienstleister, die in der Europäischen Union tätig sind. Zusätzlich zu den in der EU ansässigen Finanzunternehmen und IKT-Dienstleistern betrifft DORA auch Niederlassungen und Tochtergesellschaften von EU-Finanzunternehmen, die sich außerhalb der Union befinden, sofern diese Niederlassungen und Tochtergesellschaften Dienstleistungen in die EU erbringen. So soll die operationelle Resilienz des Finanzsektors in der gesamten Union sichergestellt werden, auch bei Abhängigkeiten von globalen Anbietern oder internationalen Tochtergesellschaften. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> == Zentrale Inhalte == </div> <div lang="de" dir="ltr" class="mw-content-ltr"> === Management von IKT-Risiken und Vorfällen === </div> <div lang="de" dir="ltr" class="mw-content-ltr"> ==== IKT-Risiken ==== </div> <div lang="de" dir="ltr" class="mw-content-ltr"> Nach dem DORA sind Finanzunternehmen verpflichtet, einen umfassenden internen '''Governance- und Kontrollrahmen''' für das Management von Informations- und Kommunikationstechnologie-Risiken (IKT-Risiken) zu etablieren. Dieser Rahmen muss regelmäßig überprüft und dokumentiert werden, wobei für Kleinstunternehmen lediglich eine regelmäßige Überprüfung ausreicht. Ziel ist es, IKT-Risiken wirksam zu begegnen. Die spezifischen Anforderungen an das IKT-Risikomanagement sind in Art 5 Abs 2 DORA festgelegt. Die Verantwortung für die Definition, Genehmigung und Überwachung des IKT-Risikomanagements liegt beim '''Leitungsorgan''' des jeweiligen Finanzunternehmens, das auch für die Umsetzung der Maßnahmen verantwortlich ist. Finanzunternehmen, die nicht als Kleinstunternehmen eingestuft sind, haben zusätzlich eine unabhängige Kontrollfunktion einzurichten, um die Überwachung und das Management von IKT-Risiken sicherzustellen. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> Ein zentraler Aspekt des DORA ist die Verantwortung des Leitungsorgans (zB Vorstand) für die digitale Resilienz. Das Business Continuity Management (BCM) ist dabei das wichtigste Einfallstor für die operative Umsetzung dieser Verantwortung. DORA fordert, dass das Leitungsorgan selbst die notwendigen Sachkenntnisse besitzen muss und die nicht mehr rigoros delegieren darf. Dies könnte zu strukturellen Veränderungen in der Unternehmensführung führen, zB durch die Einbindung eines CIO oder CTO auf Vorstandsebene. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> ==== IKT-bezogene Vorfälle ==== </div> <div lang="de" dir="ltr" class="mw-content-ltr"> Darüber hinaus müssen Finanzunternehmen Prozesse etablieren, die sicherstellen, dass IKT-bezogene Vorfälle frühzeitig erkannt, behandelt, klassifiziert und gemeldet werden. Besonders '''schwerwiegende''' IKT-Vorfälle, die nach den Kriterien des Art 18 Abs 1 DORA als solche einzustufen sind, müssen den zuständigen Aufsichtsbehörden in einem dreistufigen Verfahren gemeldet werden. In Fällen, in denen schwerwiegende IKT-Vorfälle die finanziellen Interessen der Kund*innen betreffen, müssen die Finanzunternehmen ihre Kund*innen unverzüglich nach Kenntnis des Vorfalls informieren. Cyberbedrohungen, die gemäß Art 18 Abs 2 DORA als '''erheblich''' einzustufen sind, müssen ebenfalls erfasst werden und können auf freiwilliger Basis gemeldet werden. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> Zur Unterstützung der Finanzunternehmen bei der Umsetzung dieser Anforderungen haben die Europäischen Aufsichtsbehörden mehrere technische Regulierungsstandards veröffentlicht. Diese umfassen ua Vorgaben zur Festlegung der Tools, Methoden, Prozesse und Richtlinien für das IKT-Risikomanagement sowie vereinfachte Risikomanagement-Rahmen für Kleinstunternehmen. Weitere RTS spezifizieren die Kriterien für die Klassifizierung von IKT-Vorfällen und Cyberbedrohungen, sowie die Wesentlichkeitsschwellen und Anforderungen an die Meldungen schwerwiegender Vorfälle. Meldung und Einstufung über IKT-bezogene Vorfälle ist mithilfe der harmonisierten '''Standardvorlagen''' durchzuführen.<ref>''European Banking Authority'', Joint Technical Standards on major incident reporting, https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/operational-resilience/joint-technical-standards-major-incident-reporting (abgerufen 22. 1. 2025).</ref> Die zuständigen Behörden, an die gemeldet werden muss, unterscheiden sich von denen der NIS2-RL. Eine klare Festlegung und unternehmensinterne Kommunikation der Meldepflichten und der empfangenden Stellen ist wichtig. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> === Prüfung digitaler Betriebsstabilität === </div> <div lang="de" dir="ltr" class="mw-content-ltr"> Bedeutende Finanzunternehmen haben verpflichtend so '''Threat Led Penetration Tests''' durchzuführen. Diese – auch in der Produktionsumgebung durchgeführten – Tests zielen auf die Kern-IT-Systeme des Unternehmens ab. So können Verpflichtete Schwächen, Mängel und Lücken in der digitalen operationellen Resilienz zu identifizieren und unverzüglich Korrekturmaßnahmen zu ergreifen. Die Tests müssen von unabhängigen Parteien durchgeführt werden, um eine objektive Bewertung sicherzustellen. Dabei sind die Tests mindestens einmal jährlich bei den IKT-Systemen oder Anwendungen durchzuführen, die kritische oder wichtige Funktionen unterstützen. Hierbei wird darauf geachtet, dass die Resilienz in diesen Schlüsselbereichen kontinuierlich sichergestellt wird. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> DORA spezifiziert in Art 25 Abs 1 verschiedene Arten von Tests, die in Betracht gezogen werden können, darunter Simulationen, Red Teaming oder Penetrationstests. Zusätzlich sind bestimmte Finanzunternehmen nach Art 26 DORA verpflichtet, mindestens alle drei Jahre '''Threat-Led Penetration Tests''' (TLPT) durchzuführen, bei denen gezielt realistische Bedrohungsszenarien simuliert werden. Diese Tests sollen sicherstellen, dass Schwachstellen, die durch herkömmliche Sicherheitsmaßnahmen nicht entdeckt werden, aufgedeckt werden. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> Die spezifischen Anforderungen und Elemente dieser TLPT sind in den von den Europäischen Aufsichtsbehörden (EBA, ESMA und EIOPA (zusammen die „ESA“)) veröffentlichten technischen Regulierungsstandards (RTS) festgelegt. Die konkrete Methodik, die für diese Tests gemäß DORA anzuwenden ist, beruht auf dem Rahmenwerk TIBER-EU (Threat Intelligence-Based Ethical Red Teaming“) welcher in Österreich durch [https://www.fma.gv.at/tiber-at/ TIBER-AT] umgesetzt wird. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> === Lieferkettenmanagement === </div> <div lang="de" dir="ltr" class="mw-content-ltr"> DORA stellt klare Anforderungen an das Management des IKT-Drittparteienrisikos und die vertraglichen Vereinbarungen mit IKT-Drittdienstleistern, die von Finanzunternehmen beachtet werden müssen. Mit Ausnahme von Kleinstunternehmen haben Finanzunternehmen die Pflicht, eine Strategie zum Management des IKT-Drittparteienrisikos zu entwickeln und regelmäßig zu überprüfen. Diese Strategie umfasst Leitlinien für die Nutzung von IKT-Drittdienstleistungen, die dazu dienen, das Risiko, das durch externe Dienstleister entsteht, effektiv zu steuern. Die Europäische Aufsichtsbehörde (ESA) hat hierzu technische Regulierungsstandards (RTS) veröffentlicht, welche den detaillierten Inhalt dieser Leitlinien spezifizieren.<ref>https://www.eba.europa.eu/publications-and-media/press-releases/esas-published-second-batch-policy-products-under-dora</ref> </div> <div lang="de" dir="ltr" class="mw-content-ltr"> ==== Informationsregister ==== </div> <div lang="de" dir="ltr" class="mw-content-ltr"> Ein wesentlicher Bestandteil der Anforderungen ist, dass Finanzunternehmen ein stets aktuelles Informationsregister führen müssen, welches Informationen zu allen ausgelagerten IKT-Prozessen enthält. Dieses Register beinhaltet die entsprechenden vertraglichen Vereinbarungen sowie die Einordnung der Prozesse als kritisch oder nicht kritisch. Auf Anfrage müssen diese Informationen den zuständigen Behörden zur Verfügung gestellt werden. Außerdem müssen Finanzunternehmen jährlich Bericht erstatten über die Anzahl neuer Vereinbarungen mit IKT-Drittdienstleistern, die bereitgestellten Dienstleistungen und Funktionen sowie über die Art der vertraglichen Vereinbarungen. Finanzunternehmen sind außerdem verpflichtet, geplante neue Vereinbarungen bezüglich kritischer Funktionen oder Veränderungen des Status einer Funktion als „kritisch“ den Behörden zeitnah zu melden. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> ==== Verträge ==== </div> <div lang="de" dir="ltr" class="mw-content-ltr"> Vor Abschluss eines Vertrags mit einem IKT-Drittdienstleister müssen Finanzunternehmen eine Risikoanalyse durchführen, die die Kriterien von Art 28 Abs 4 und 5 DORA berücksichtigt. Während der Vertragsverhandlungen müssen sie sicherstellen, dass Audit-Frequenzen und zu prüfende Bereiche festgelegt werden, um die Kontrolle über kritische Systeme zu wahren. Des Weiteren sind vertragliche Kündigungsrechte sowie angemessene Ausstiegsstrategien für den Fall einer Beendigung der Vertragsbeziehung festzulegen, insbesondere bei kritischen oder wichtigen Funktionen. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> '''Praxistipp:''' Mittelständische Unternehmen sollten Musterverträge vorbereiten, um die Anforderungen an Drittdienstleister klar zu regeln. Viele KMUs verfügen nicht über zentrale Vertragswerke, was die Umsetzung erschwert. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> Darüber hinaus sieht DORA in Art 30 spezielle Vertragsbedingungen für die Vergabe von Unteraufträgen durch IKT-Drittdienstleister vor, welche ebenfalls in den technischen Standards der ESA spezifiziert sind. Diese Vorschriften regeln unter anderem die Zulässigkeit der Unterauftragsvergabe sowie die dafür geltenden Kriterien. IKT-Dienstleister fallen vollständig unter den DORA. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> ==== Überwachung ==== </div> <div lang="de" dir="ltr" class="mw-content-ltr"> Die Überwachung von IKT-Drittdienstleistern erfolgt durch die ESA, welche nach Art 31 Abs 2 DORA die Drittdienstleister als „kritisch“ einstufen können. Für jeden als kritisch eingestuften IKT-Drittdienstleister wird eine federführende Überwachungsbehörde ernannt, die über weitreichende Befugnisse verfügt. Dazu zählen das Recht auf Informationsanforderungen, Inspektionen und das Aussprechen von Empfehlungen hinsichtlich der Sicherheitsanforderungen und der Unterauftragsvergabe. IKT-Drittdienstleistern können auch zentral geprüft werden . Es stellt sich die Frage, welche Behörde in Österreich diese Prüfungen durchführen wird (evtl. Finanzmarktaufsicht, FMA). </div> <div lang="de" dir="ltr" class="mw-content-ltr"> '''Praxistipp:''' Sofern zentrale Prüfungen großer IKT-Dienstleister erfolgen, können sich Unternehmen auf diese Prüfungsergebnisse verlassen und eigene dezentrale Prüfungen minimalhalten. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> === Informationsaustausch === </div> <div lang="de" dir="ltr" class="mw-content-ltr"> Die Vorgaben des DORA ermöglichen es Finanzunternehmen, Informationen und Erkenntnisse über Cyberbedrohungen untereinander – innerhalb vertrauenswürdiger Gemeinschaften und unter Wahrung der Vertraulichkeit potenziell sensibler Informationen – auszutauschen. Dies trägt zur Schärfung des Bewusstseins bei und verstärkt die Fähigkeit, reale informations- und kommunikationstechnologische Vorfälle zu verhindern bzw. deren Auswirkungen wirksamer einzudämmen. Dieser Informationsaustausch wird durch DORA ermöglicht und erfolgt freiwillig. Bei Teilnahme oder Beendigung einer solchen Vereinbarung, erfolgt eine diesbezügliche Meldung an die FMA.<ref>''FMA'', DORA – Informationsaustausch und Notfallübungen, https://www.fma.gv.at/querschnittsthemen/dora/dora-informationsaustausch-und-notfalluebungen/ (abgerufen 22. 1. 2025).</ref> </div> <div lang="de" dir="ltr" class="mw-content-ltr"> == Fallbeispiele == </div> <div lang="de" dir="ltr" class="mw-content-ltr"> * Anwendungsbereich: Eine Bank kauft das Core-Banking-System von einem externen Dienstleister ein und verwaltet nur das Vertragsmanagement. Hier muss die Bank dennoch sicherstellen, dass die Anforderungen des DORA erfüllt werden, sowohl hinsichtlich des Risikomanagements als auch des Lieferkettenmanagements. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> * In Unternehmen mit einer zentralisierten IT-Governance, wie zB Holding-Strukturen, stellt sich die Frage, wie die Governance optimal gestaltet und eingebunden werden kann. Hierzu müssen zentrale Weisungen klar formuliert und durchgesetzt werden. Dies betrifft sowohl operative Einheiten als auch die Gesamtorganisation. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> == Synergien == </div> <div lang="de" dir="ltr" class="mw-content-ltr"> ===== Datenschutz ===== </div> <div lang="de" dir="ltr" class="mw-content-ltr"> * Datenschutz und Informationssicherheit sind eng miteinander verknüpfte Konzepte, die gemeinsam gedacht werden müssen. Jede Maßnahme, wie zB Monitoring und Logging, muss auch in Bezug auf Datenschutzanforderungen betrachtet werden. Art 88 der DSGVO betont den Schutz der Würde des Menschen am Arbeitsplatz, was insbesondere bei eingriffsintensiven Technologien wie KI-gestütztem Anomalie-Monitoring relevant ist. Der Einsatz von KI-Systemen zur Erkennung und Meldung von Anomalien nimmt zu, was potenziell tiefere Eingriffe in den Datenschutz von Mitarbeiter*innendaten bedeutet. Dies muss im Sinne der DSGVO und DORA sorgfältig abgewogen werden. * Normen wie ISO 27001 und ÖNORM A 2017:2023:06:01 vereinen Datenschutz und Datensicherheit und ist ein geeigneter Anknüpfungspunkt für die Umsetzung von DORA. Sie können konzeptionell in Verbindung mit den entsprechenden DORA-Normen als Umsetzungsstruktur integriert werden. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> ===== NIS2-RL ===== </div> <div lang="de" dir="ltr" class="mw-content-ltr"> Die unter DORA entwickelten Regulatory Technical Standards (RTS) und Implementing Technical Standards (ITS) bieten wertvolle Ansatzpunkte für die Umsetzung der NIS2-RL: </div> <div lang="de" dir="ltr" class="mw-content-ltr"> '''Risikomanagement''': Die RTS zu IKT-Risikomanagement unter DORA können als Vorlage für die Implementierung ähnlicher Frameworks unter NIS-II dienen. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> '''Incident Reporting''': Die ITS zu Meldepflichten bei schwerwiegenden Vorfällen bieten standardisierte Vorlagen, die auch für NIS2-pflichtige Unternehmen adaptierbar sind. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> '''Drittanbieter-Management''': DORA's RTS zur Nutzung von IKT-Diensten und Unterauftragsvergabe können als Best Practices für das Lieferkettenrisikomanagement unter NIS2 genutzt werden. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> '''Penetrationstests''': Der RTS zu Threat-Led Penetration Tests (TLPT) unter DORA bietet detaillierte Vorgaben, die auch für kritische Infrastrukturen im Rahmen von NIS-II relevant sind. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> * [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1774 RTS zum IKT-Risikomanagement (Art 15, Art. 16 Abs 3)] * [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1772 RTS zur Klassifizierung von IKT-bezogenen Vorfällen (Art 18 Abs 3)] * [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1773 RTS zu vertraglichen Vereinbarungen mit IKT-Drittdienstleistern (Art. 28.10)] * [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2956 ITS zum Informationsregister (Art. 29 Abs 9)] </div> <div lang="de" dir="ltr" class="mw-content-ltr"> * [https://www.esma.europa.eu/sites/default/files/2024-07/JC_2024-33_-_Final_report_on_the_draft_RTS_and_ITS_on_incident_reporting.pdf RTS zur Meldung größerer IKT-bezogener Vorfälle und erheblicher Cyber-Bedrohungen (Art 20a)] * [https://www.esma.europa.eu/sites/default/files/2024-07/JC_2024-33_-_Final_report_on_the_draft_RTS_and_ITS_on_incident_reporting.pdf ITS zur Meldung größerer IKT-bezogener Vorfälle und erheblicher Cyber-Bedrohungen (Art 20b)] * [https://www.esma.europa.eu/sites/default/files/2024-07/JC_2024-29_-_Final_report_DORA_RTS_on_TLPT.pdf RTS zum Threat-Led Penetration Testing (Art 26 Abs 11)] * [https://www.esma.europa.eu/sites/default/files/2024-07/JC_2024-35_-_Final_report_on_RTS_on_harmonisation_of_conditions_for_OVS_conduct.pdf RTS für die Harmonisierung von Überwachungstätigkeiten (Art 41 Abs 1)] * [https://www.esma.europa.eu/sites/default/files/2024-07/JC_2024_54_-_Final_Report_RTS_on_JET.pdf RTS zur Festlegung der Kriterien für die Zusammensetzung des Joint Examination Teams (Art 41 Abs 1c)] </div> <div lang="de" dir="ltr" class="mw-content-ltr"> * [https://www.eiopa.europa.eu/publications/joint-final-report-draft-rts-subcontracting-ict-services-supporting-critical-or-important-functions_en?prefLang=de RTS zur Unterauftragsvergabe an IKT-Drittparteien (Art 30 Abs 5)] </div> <div lang="de" dir="ltr" class="mw-content-ltr"> == Konsequenzen/Strafen == </div> <div lang="de" dir="ltr" class="mw-content-ltr"> === Bußgelder === </div> <div lang="de" dir="ltr" class="mw-content-ltr"> DORA sieht strenge '''Bußgelder''' und Strafen für Verstöße vor, um die digitale Betriebsstabilität im Finanzsektor zu gewährleisten: </div> <div lang="de" dir="ltr" class="mw-content-ltr"> * Finanzinstitute: National determiniert, in Österreich bis 500.000 oder bis zu 1% des weltweiten Jahresumsatzes (DORA-Vollzugsgesetz - DORA-VG) * Kritische IKT-Drittanbieter: Bis zu 1% des weltweiten Jahresumsatzes </div> <div lang="de" dir="ltr" class="mw-content-ltr"> === Administrative Maßnahmen === </div> <div lang="de" dir="ltr" class="mw-content-ltr"> * Lizenzentzug oder -aussetzung (Art 50) * Verpflichtende Korrekturmaßnahmen (Art 50) </div> <div lang="de" dir="ltr" class="mw-content-ltr"> === Strafrechtliche Konsequenzen === </div> <div lang="de" dir="ltr" class="mw-content-ltr"> * Mögliche strafrechtliche Verfolgung von Führungskräften bei grober Fahrlässigkeit (Art 11) * Nationale Bestimmungen können Haftstrafen vorsehen (Art 52) </div> <div lang="de" dir="ltr" class="mw-content-ltr"> == Weiterführende Literatur == </div> <div lang="de" dir="ltr" class="mw-content-ltr"> * ''Siglmüller'', Cyber Resilience Act und Digital Operational Resilience Act - Lässt sich IT-Sicherheit rechtlich erzwingen?, ZfPC 2023, 221. * ''Škorjanc'', Digital Operational Resilience Act, ÖBA 2023, 658. </div> <div lang="de" dir="ltr" class="mw-content-ltr"> == Einzelnachweise == </div> <div lang="de" dir="ltr" class="mw-content-ltr"> <references /> </div>
Navigationsmenü
Seitenaktionen
Übersetzen
Statistiken zu Sprachen
Statistiken zu Nachrichtengruppen
Exportieren
Seitenaktionen
Übersetzen
Werkzeuge
Meine Werkzeuge
Deutsch
Anmelden
Benutzerkonto beantragen
Navigation
Hauptseite
Letzte Änderungen
Zufällige Seite
Hilfe zu MediaWiki
Suche
Werkzeuge
Spezialseiten
Druckversion