+Artikel 19 Indberetning af større IKT-relaterede hændelserog frivillig underretning om væsentlige cybertrusler
---+Artikel 19 1
---+Artikel 19 2
---+Artikel 19 3
---+Artikel 19 4
---+Artikel 19 5
---+Artikel 19 6
---+Artikel 19 7
---+Artikel 19 8
|
Artikel 19 Indberetning af større IKT-relaterede hændelserog frivillig underretning om væsentlige cybertrusler
-
1. Oversigt
| Titel |
Regulering |
|
Artikel 19 1
|
1. De finansielle enheder indberetter større IKT-relaterede hændelser til den relevante kompetente myndighed som omhandlet i artikel 46 i overensstemmelse med nærværende artikels stk. 4.
Hvis en finansiel enhed er underlagt tilsyn af mere end en national kompetent myndighed som omhandlet i artikel 46, udpeger medlemsstaterne en fælles kompetent myndighed som den relevante kompetente myndighed, der er ansvarlig for at udføre de i denne artikel omhandlede funktioner og opgaver.
Kreditinstitutter, der er klassificeret som signifikante i overensstemmelse med artikel 6, stk. 4, i forordning (EU) nr. 1024/2013, indberetter større IKT-relaterede hændelser til den relevante nationale kompetente myndighed, der er udpeget i overensstemmelse med artikel 4 i direktiv 2013/36/EU, og som øjeblikkeligt videresender den pågældende rapport til ECB.
Med henblik på første afsnit udarbejder de finansielle enheder efter indsamling og analyse af alle relevante oplysninger den indledende underretning og de rapporter, der er omhandlet i denne artikels stk. 4, ved brug af de modeller, der er omhandlet i artikel 20, og indgiver dem til den kompetente myndighed. Hvis det er teknisk umuligt at indgive den indledende underretning ved brug af modellen, meddeler de finansielle enheder den kompetente myndighed den på anden vis.
Den indledende underretning og de rapporter, der er omhandlet i stk. 4, skal indeholde alle de oplysninger, der er nødvendige for, at den kompetente myndighed kan fastslå, hvorvidt den større IKT-relaterede hændelse er væsentlig, og vurdere mulige grænseoverskridende virkninger.
Med forbehold af den finansielle enheds indberetning i henhold til første afsnit til den relevante kompetente myndighed kan medlemsstaterne derudover bestemme, at visse eller alle finansielle enheder også skal indgive den indledende underretning og hver enkelt rapport som omhandlet i denne artikels stk. 4 ved brug af de modeller, der er omhandlet i artikel 20, til de kompetente myndigheder eller til de enheder, der håndterer IT-sikkerhedshændelser (CSIRT'er), som er udpeget eller oprettet i overensstemmelse med direktiv (EU) 2022/2555.
|
|
Artikel 19 2
|
2. De finansielle enheder kan på frivillig basis underrette den relevante kompetente myndighed om væsentlige cybertrusler, når de anser truslen for at være relevant for det finansielle system, tjenestebrugere eller kunder. Den relevante kompetente myndighed kan give sådanne oplysninger til andre relevante myndigheder som omhandlet i stk. 6.
Kreditinstitutter, der er klassificeret som signifikante i overensstemmelse med artikel 6, stk. 4, i forordning (EU) nr. 1024/2013, kan på frivillig basis underrette den relevante nationale kompetente myndighed, der er udpeget i overensstemmelse med artikel 4 i direktiv 2013/36/EU, og som øjeblikkeligt videresender underretningen til ECB, om væsentlige cybertrusler.
Medlemsstaterne kan bestemme, at disse finansielle enheder, som på frivillig basis indgiver en underretning, jf. først afsnit, også kan videresende den pågældende underretning til de CSIRT'er, der er udpeget eller oprettet i overensstemmelse med direktiv (EU) 2022/2555
|
|
Artikel 19 3
|
3. Hvis en større IKT-relateret hændelse indtræffer og har indflydelse på kunders finansielle interesser, underretter de finansielle enheder uden unødigt ophold, så snart de får kendskab til den, deres kunder om den større IKT-relaterede hændelse og om de foranstaltninger, der er truffet for at afbøde de negative virkninger af en sådan hændelse.
I tilfælde af en væsentlig cybertrussel underretter de finansielle enheder, hvis det er relevant, de af deres kunder, som potentielt er berørt heraf, om eventuelle passende beskyttelsesforanstaltninger, som sidstnævnte kan overveje at træffe.
|
|
Artikel 19 4
|
4. De finansielle enheder indgiver inden for de frister, der skal fastsættes i overensstemmelse med artikel 20, stk. 1, litra a), nr. ii), følgende til den relevante kompetente myndighed:
|
a)
|
en indledende underretning
|
|
b)
|
en foreløbig rapport efter den indledende underretning, jf. litra a), så snart den oprindelige hændelses status har ændret sig betydeligt, eller håndteringen af den større IKT-relaterede hændelse har ændret sig på grundlag af nye tilgængelige oplysninger, efterfulgt, alt efter hvad der er relevant, af ajourførte underretninger, hver gang der foreligger en relevant ajourføring af status, samt efter en specifik anmodning fra den kompetente myndighed
|
|
c)
|
en endelig rapport, når den grundlæggende årsagsanalyse er afsluttet, uanset om der allerede er gennemført afbødende foranstaltninger, og når tallene for de faktiske virkninger foreligger og kan erstatte skøn.
|
|
|
Artikel 19 5
|
5. De finansielle enheder kan i overensstemmelse med EU- og national sektorspecifik ret outsource opfyldelsen af indberetningsforpligtelserne i henhold til denne artikel til en tredjepartstjenesteudbyder. I tilfælde af en sådan outsourcing er den finansielle enhed fortsat fuldt ud ansvarlig for at opfylde kravene vedrørende indberetning af hændelser.
|
|
Artikel 19 6
|
6. Når den kompetente myndighed modtager den indledende underretning og hver enkelt rapport som omhandlet i stk. 4, forelægger den rettidigt nærmere oplysninger om den større IKT-relaterede hændelse for følgende modtagere på grundlag af deres respektive kompetencer, alt efter hvad der er relevant:
|
b)
|
ECB i tilfælde af finansielle enheder som omhandlet i artikel 2, stk. 1, litra a), b) og d)
|
|
c)
|
de kompetente myndigheder, de centrale kontaktpunkter eller CSIRT'er, der er udpeget eller oprettet i overensstemmelse med direktiv (EU) 2022/2555
|
|
d)
|
afviklingsmyndighederne som omhandlet i artikel 3 i direktiv 2014/59/EU og Den Fælles Afviklingsinstans (SRB) for så vidt angår de enheder, der er omhandlet i artikel 7, stk. 2, i Europa-Parlamentets og Rådets forordning (EU) nr. 806/2014 (37), og for så vidt angår de enheder og koncerner, der er omhandlet i artikel 7, stk. 4, litra b), og artikel 7, stk. 5, i forordning (EU) nr. 806/2014, hvis sådanne oplysninger vedrører hændelser, der udgør en risiko for sikringen af kritiske funktioner, jf. artikel 2, stk. 1, nr. 35), i direktiv 2014/59/EU, og
|
|
e)
|
andre relevante offentlige myndigheder i henhold til national ret.
|
|
|
Artikel 19 7
|
7. Efter modtagelse af oplysningerne i overensstemmelse med stk. 6 vurderer EBA, ESMA eller EIOPA og ECB i samråd med ENISA og i samarbejde med den relevante kompetente myndighed, om den større IKT-relaterede hændelse er relevant for kompetente myndigheder i andre medlemsstater. Efter denne vurdering underretter EBA, ESMA eller EIOPA så hurtigt som muligt de relevante kompetente myndigheder i andre medlemsstater herom. ECB underretter medlemmerne af Det Europæiske System af Centralbanker om spørgsmål, der er relevante for betalingssystemet. De kompetente myndigheder træffer på grundlag af underretningen, hvis det er hensigtsmæssigt, alle nødvendige foranstaltninger for at beskytte det finansielle systems umiddelbare stabilitet.
|
|
Artikel 19 8
|
8. Den underretning, som ESMA skal indgive i henhold til denne artikels stk. 7, berører ikke den kompetente myndigheds ansvar for hurtigt at videresende nærmere oplysninger om den større IKT-relaterede hændelse til den relevante myndighed i værtslandet, hvis en værdipapircentral har betydelige grænseoverskridende aktiviteter i værtslandet, den større IKT-relaterede hændelse forventes at have alvorlige konsekvenser for de finansielle markeder i værtslandet, og hvis der er samarbejdsordninger mellem de kompetente myndigheder med hensyn til tilsyn med finansielle enheder.
|
,
1.1 Referencer
1.2 Identificerede krav
1.3 Relaterede standarder
2. Identificerede krav
3. Relaterede standarder
Standarder
| Kilde |
Krav |
|
SCF
|
Incident Stakeholder Reporting
Description
Mechanisms exist to timely-report incidents to applicable: (1) Internal stakeholders; (2) Affected clients & third-parties; and (3) Regulatory authorities.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Basic incident response plan ∙ Designate incident response contact
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Documented incident response plan ∙ Incident log ∙ Designated IR team
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Formal incident response program ∙ IR playbooks ∙ Tabletop exercises
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Enterprise incident response program ∙ 24/7 SOC monitoring ∙ SOAR platform
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Enterprise SOC with SIEM/SOAR (e.g., Splunk SOAR, Palo Alto XSOAR) ∙ IR retainer ∙ Threat hunting
SCR-CMM
Level 0 Not Performed
Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed.
Level 1 Performed Informally
SCR-CMM Level 1 criteria definitions are not available for this control: ▪ A reasonable person would conclude this control requires a structured process. ▪ At this level of maturity, the "ad hoc" nature of performing a capability informally would indicate the intent of the control is not met due to a lack of consistency and formality.
Level 2 Planned Tracked
Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery. ▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.
Level 3 Well Defined
Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function. ▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery. ▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls). ▪ An implemented and operational capability exists to timely-report incidents to applicable: (1) Internal stakeholders; (2) Affected clients & third-parties; and (3) Regulatory authorities.
Level 4 Quantitatively Controlled
Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs). ▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs). ▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties. ▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review). ▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes. ▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.
Level 5 Continuously Improving
Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions: ▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. ▪ Level 5 capabilities should be considered “world-class” where the control builds on Level 4 capabilities, but are continuously improving through Artificial Intelligence (AI) and/or Machine Learning (ML) technologies. ▪ While it may be possible to develop responsive capabilities for this control through the use of AI and/or ML technologies, the criteria would be organization-specific to define.
|
|
SCF
|
Incident Stakeholder Reporting
Description
Mechanisms exist to timely-report incidents to applicable: (1) Internal stakeholders; (2) Affected clients & third-parties; and (3) Regulatory authorities.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Basic incident response plan ∙ Designate incident response contact
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Documented incident response plan ∙ Incident log ∙ Designated IR team
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Formal incident response program ∙ IR playbooks ∙ Tabletop exercises
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Enterprise incident response program ∙ 24/7 SOC monitoring ∙ SOAR platform
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Enterprise SOC with SIEM/SOAR (e.g., Splunk SOAR, Palo Alto XSOAR) ∙ IR retainer ∙ Threat hunting
SCR-CMM
Level 0 Not Performed
Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed.
Level 1 Performed Informally
SCR-CMM Level 1 criteria definitions are not available for this control: ▪ A reasonable person would conclude this control requires a structured process. ▪ At this level of maturity, the "ad hoc" nature of performing a capability informally would indicate the intent of the control is not met due to a lack of consistency and formality.
Level 2 Planned Tracked
Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery. ▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.
Level 3 Well Defined
Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function. ▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery. ▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls). ▪ An implemented and operational capability exists to timely-report incidents to applicable: (1) Internal stakeholders; (2) Affected clients & third-parties; and (3) Regulatory authorities.
Level 4 Quantitatively Controlled
Incident Response (IRO) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs). ▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs). ▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties. ▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review). ▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes. ▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.
Level 5 Continuously Improving
Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions: ▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. ▪ Level 5 capabilities should be considered “world-class” where the control builds on Level 4 capabilities, but are continuously improving through Artificial Intelligence (AI) and/or Machine Learning (ML) technologies. ▪ While it may be possible to develop responsive capabilities for this control through the use of AI and/or ML technologies, the criteria would be organization-specific to define.
|
|