+14 artikla Valmistajien raportointivelvoitteet
---+14 artikla 1.
---+14 artikla 2.
---+14 artikla 3.
---+14 artikla 4.
---+14 artikla 5.
---+14 artikla 6.
---+14 artikla 7.
---+14 artikla 8.
---+14 artikla 9.
---+14 artikla 10.

14 artikla Valmistajien raportointivelvoitteet

-

1. Yleiskatsaus

,
14 artikla 1.
Valmistajan on ilmoitettava kaikista digitaalisia elementtejä sisältävään tuotteeseen sisältyvistä aktiivisesti hyödynnetyistä haavoittuvuuksista, joista se on tullut tietoiseksi, samanaikaisesti tämän artiklan 7 kohdan mukaisesti koordinaattoriksi nimetylle CSIRT-yksikölle ja ENISAlle. Valmistajan on ilmoitettava kyseisistä aktiivisesti hyödynnetyistä haavoittuvuuksista 16 artiklan nojalla perustetun keskitetyn raportointialustan kautta.
14 artikla 2.

Edellä 1 kohdassa tarkoitettua ilmoitusta varten valmistajan on annettava

a) 

ilman aiheetonta viivytystä ja joka tapauksessa 24 tunnin kuluessa siitä, kun valmistaja on tullut tietoiseksi aktiivisesti hyödynnetystä haavoittuvuudesta, sitä koskeva ennakkovaroitusilmoitus, jossa ilmoitetaan tarvittaessa jäsenvaltiot, joiden alueella valmistaja tietää digitaalisia elementtejä sisältävää tuotettaan asetetun saataville;

b) 

jollei asiaankuuluvia tietoja ole jo toimitettu, ilman aiheetonta viivytystä ja joka tapauksessa 72 tunnin kuluessa siitä, kun valmistaja on tullut tietoiseksi aktiivisesti hyödynnetystä haavoittuvuudesta, haavoittuvuusilmoitus, jossa annetaan saatavilla olevat yleiset tiedot kyseisestä digitaalisia elementtejä sisältävästä tuotteesta, kyseisen hyödyntämisen ja haavoittuvuuden yleisestä luonteesta sekä toteutetuista korjaavista tai lieventävistä toimenpiteistä ja korjaavista tai lieventävistä toimenpiteistä, joita käyttäjät voivat toteuttaa, ja jossa tarvittaessa myös ilmoitetaan, miten arkaluonteisina valmistaja pitää ilmoitettuja tietoja;

c) 

jollei asiaankuuluvia tietoja ole jo toimitettu, loppuraportti viimeistään 14 päivän kuluttua siitä, kun korjaava tai lieventävä toimenpide on käytettävissä, mukaan lukien vähintään seuraavat tiedot:

i) 

kuvaus haavoittuvuudesta, mukaan lukien sen vakavuus ja vaikutukset;

ii) 

jos saatavilla, tiedot mahdollisista pahantahtoisista toimijoista, jotka ovat hyödyntäneet tai hyödyntävät haavoittuvuutta;

iii) 

yksityiskohtaiset tiedot tietoturvapäivityksestä tai muista korjaavista toimenpiteistä, jotka on asetettu saataville haavoittuvuuden korjaamiseksi.
14 artikla 3.
Valmistajan on ilmoitettava kaikista digitaalisia elementtejä sisältävän tuotteen tietoturvaan vaikuttavista vakavista poikkeamista, joista se on tullut tietoiseksi, samanaikaisesti tämän artiklan 7 kohdan mukaisesti koordinaattoriksi nimetylle CSIRT-yksikölle ja ENISAlle. Valmistajan on ilmoitettava kyseisistä poikkeamista 16 artiklan nojalla perustetun keskitetyn raportointialustan kautta.
14 artikla 4.

Edellä 3 kohdassa tarkoitettua ilmoitusta varten valmistajan on annettava

a) 

ilman aiheetonta viivytystä ja joka tapauksessa 24 tunnin kuluessa siitä, kun valmistaja on tullut tietoiseksi digitaalisia elementtejä sisältävän tuotteen tietoturvaan vaikuttavasta vakavasta poikkeamasta, sitä koskeva ennakkovaroitusilmoitus, johon sisältyy ainakin se, epäilläänkö poikkeamaa laittomien tai pahantahtoisten tekojen aiheuttamaksi ja jossa ilmoitetaan myös tarvittaessa jäsenvaltiot, joiden alueella valmistaja tietää digitaalisia elementtejä sisältävää tuotettaan asetetun saataville;

b) 

jollei asiaankuuluvia tietoja ole jo toimitettu, ilman aiheetonta viivytystä ja joka tapauksessa 72 tunnin kuluessa siitä, kun valmistaja on tullut tietoiseksi poikkeamasta, poikkeamailmoitus, jossa annetaan saatavilla olevia yleisiä tietoja poikkeaman luonteesta, alustava arvio poikkeamasta sekä tietoa toteutetuista korjaavista tai lieventävistä toimenpiteistä ja korjaavista tai lieventävistä toimenpiteistä, joita käyttäjät voivat toteuttaa, ja jossa tarvittaessa myös ilmoitetaan, miten arkaluonteisina valmistaja pitää ilmoitettuja tietoja;

c) 

jollei asiaankuuluvia tietoja ole jo toimitettu, viimeistään kuukauden kuluttua b alakohdan mukaisen poikkeamailmoituksen antamisesta loppuraportti, joka sisältää vähintään seuraavat tiedot:

i) 

yksityiskohtainen kuvaus poikkeamasta, mukaan lukien sen vakavuus ja vaikutukset;

ii) 

uhkan tyyppi tai poikkeaman todennäköisesti aiheuttanut perimmäinen syy;

iii) 

toteutetut ja meneillään olevat lieventämistoimenpiteet.
14 artikla 5.

Edellä olevan 3 kohdan soveltamiseksi digitaalisia elementtejä sisältävän tuotteen tietoturvaan vaikuttava poikkeama katsotaan vakavaksi, jos

a) 

se vaikuttaa tai voi vaikuttaa kielteisesti digitaalisia elementtejä sisältävän tuotteen kykyyn suojella arkaluonteisten tai tärkeiden datan tai toimintojen saatavuutta, aitoutta, eheyttä tai luottamuksellisuutta; tai

b) 

se on johtanut tai voi johtaa haitallisen koodin sisällyttämiseen digitaalisia elementtejä sisältävään tuotteeseen tai digitaalisia elementtejä sisältävän tuotteen käyttäjän verkko- ja tietojärjestelmiin tai ajamiseen niissä.
14 artikla 6.
Koordinaattoriksi nimetty CSIRT-yksikkö, joka alun perin on saanut ilmoituksen, voi tarvittaessa pyytää valmistajia toimittamaan väliraportin, joka sisältää merkityksellisiä ajantasaisia tietoja digitaalisia elementtejä sisältävän tuotteen tietoturvaan vaikuttavan aktiivisesti hyödynnetyn haavoittuvuuden tai vakavan poikkeaman tilanteesta.
14 artikla 7.
Tämän artiklan 1 ja 3 kohdassa tarkoitetut ilmoitukset on annettava 16 artiklassa tarkoitetun keskitetyn raportointialustan kautta käyttäen jotakin 16 artiklan 1 kohdassa tarkoitetuista sähköisistä ilmoituspalveluista. Ilmoitus on annettava käyttäen sen jäsenvaltion koordinaattoriksi nimetyn CSIRT-yksikön sähköistä ilmoituspalvelua, jossa valmistajien päätoimipaikka on unionissa, ja sen on oltava samanaikaisesti ENISAn saatavilla.

Tätä direktiiviä sovellettaessa valmistajan päätoimipaikan katsotaan olevan unionissa siinä jäsenvaltiossa, jossa sen digitaalisia elementtejä sisältävien tuotteiden kyberturvallisuusriskeihin liittyvät päätökset pääsääntöisesti tehdään. Jos tällaista jäsenvaltiota ei voida määrittää, päätoimipaikan katsotaan sijaitsevan jäsenvaltiossa, jossa asianomaisella valmistajalla on eniten työntekijöitä työllistävä toimipaikka unionissa.

Jos valmistajalla ei ole päätoimipaikkaa unionissa, sen on annettava 1 ja 3 kohdassa tarkoitetut ilmoitukset käyttäen siinä jäsenvaltiossa koordinaattoriksi nimetyn CSIRT-yksikön sähköistä ilmoituspalvelua, joka määritetään seuraavaa järjestystä noudattaen ja valmistajan saatavilla olevien tietojen perusteella:

a) 

jäsenvaltio, johon on sijoittautunut se valmistajan puolesta toimiva valtuutettu edustaja, joka edustaa suurinta määrää kyseisen valmistajan digitaalisia elementtejä sisältäviä tuotteita;

b) 

jäsenvaltio, johon on sijoittautunut maahantuoja, joka saattaa markkinoille suurimman määrän kyseisen valmistajan digitaalisia elementtejä sisältäviä tuotteita;

c) 

jäsenvaltio, johon on sijoittautunut jakelija, joka asettaa saataville markkinoilla suurimman määrän kyseisen valmistajan digitaalisia elementtejä sisältäviä tuotteita;

d) 

jäsenvaltio, jossa sijaitsee suurin määrä kyseisen valmistajan digitaalisia elementtejä sisältävien tuotteiden käyttäjiä.

Kolmannen alakohdan d alakohdan osalta valmistaja voi antaa ilmoituksia mahdollisista myöhemmistä aktiivisesti hyödynnetyistä haavoittuvuuksista tai digitaalisia elementtejä sisältävän tuotteen tietoturvaan vaikuttavista vakavista poikkeamista samalle koordinaattoriksi nimetylle CSIRT-yksikölle, jolle se ensimmäisen kerran raportoi.
14 artikla 8.
Tultuaan tietoiseksi aktiivisesti hyödynnetystä haavoittuvuudesta tai digitaalisia elementtejä sisältävän tuotteen tietoturvaan vaikuttavasta vakavasta poikkeamasta valmistajan on tiedotettava digitaalisia elementtejä sisältävän tuotteen käyttäjille, joihin vaikutukset kohdistuvat, ja tarvittaessa kaikille käyttäjille kyseisestä haavoittuvuudesta tai poikkeamasta ja tarpeen mukaan mahdollisista riskinhallintatoimenpiteistä ja korjaavista toimenpiteistä, joita käyttäjät voivat toteuttaa lieventääkseen haavoittuvuuden tai poikkeaman vaikutuksia, tarvittaessa jäsennellyssä, koneellisesti luettavassa muodossa, jota on helppo käsitellä automaattisesti. Jos valmistaja ei anna digitaalisia elementtejä sisältävän tuotteen käyttäjille tietoja oikea-aikaisesti, koordinaattoreiksi nimetyt CSIRT-yksiköt, joille asiasta on ilmoitettu, voivat antaa näitä tietoja käyttäjille, kun se katsotaan oikeasuhtaiseksi ja tarpeelliseksi haavoittuvuuden tai poikkeaman vaikutusten ehkäisemiseksi tai lieventämiseksi.
14 artikla 9.
Komissio antaa viimeistään 11 päivänä joulukuuta 2025 tämän asetuksen 61 artiklan mukaisesti delegoituja säädöksiä, joilla täydennetään tätä asetusta määrittelemällä ehdot kyberturvallisuuteen liittyvien syiden soveltamiselle lykättäessä ilmoitusten välittämistä tämän asetuksen 16 artiklan 2 kohdassa tarkoitetulla tavalla. Komissio tekee yhteistyötä direktiivin (EU) 2022/2555 15 artiklan nojalla perustetun CSIRT-verkoston ja ENISAn kanssa valmistellessaan delegoitujen säädösten luonnoksia.
14 artikla 10.
Komissio voi täytäntöönpanosäädöksin täsmentää tässä artiklassa sekä 15 ja 16 artiklassa tarkoitettujen ilmoitusten muotoa ja niihin liittyviä menettelyjä. Nämä täytäntöönpanosäädökset hyväksytään 62 artiklan 2 kohdassa tarkoitettua tarkastelumenettelyä noudattaen. Komissio tekee yhteistyötä CSIRT-verkoston ja ENISAn kanssa valmistellessaan kyseisiä täytäntöönpanosäädösten luonnoksia.

1.1 Viittaukset

1.2 Tunnistetut vaatimukset

1.3 Liittyvät standardit

2. Tunnistetut vaatimukset

Vaatimukset

3. Liittyvät standardit

Standardit
SCF Incident Classification & Prioritization

Description

Mechanisms exist to identify classes of incidents and actions to take to ensure the continuation of organizational missions and business functions.

Possible Solutions & Considerations

Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2

∙ National Cyber Incident Scoring
System (NCISS) (https://cisa.gov)

Small Business (10-49 staff) / BLS Firm Size Classes 3-4

∙ National Cyber Incident Scoring
System (NCISS) (https://cisa.gov)

Medium Business (50-249 staff) / BLS Firm Size Classes 5-6

∙ National Cyber Incident Scoring
System (NCISS) (https://cisa.gov)

Large Business (250-999 staff) / BLS Firm Size Classes 7-8

∙ National Cyber Incident Scoring
System (NCISS) (https://cisa.gov)

Enterprise (> 1,000 staff) / BLS Firm Size Class 9

∙ National Cyber Incident Scoring
System (NCISS) (https://cisa.gov)

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 identify classes of incidents and actions to take to ensure the continuation of organizational missions and business functions.

Level 4 Quantitatively Controlled

Utilize SCR-CMM Level 3 criteria definitions:
▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control.
▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.

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.
SCF Cyber Incident Reporting for Sensitive / Regulated Data

Description

Mechanisms exist to report sensitive and/or regulated data incidents in a timely manner.

Possible Solutions & Considerations

Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2

∙ Incident Response Plan (IRP)

Small Business (10-49 staff) / BLS Firm Size Classes 3-4

∙ Incident Response Plan (IRP)

Medium Business (50-249 staff) / BLS Firm Size Classes 5-6

∙ Integrated Incident Response Program (IIRP)
∙ Integrated Security Incident Response Team (ISIRT)

Large Business (250-999 staff) / BLS Firm Size Classes 7-8

∙ Integrated Incident Response Program (IIRP)
∙ Integrated Security Incident Response Team (ISIRT)

Enterprise (> 1,000 staff) / BLS Firm Size Class 9

∙ Integrated Incident Response Program (IIRP)
∙ Integrated Security Incident Response Team (ISIRT)

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

Incident Response (IRO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with IRO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Incident response-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ IT and/or cybersecurity personnel use an informal process to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.

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.

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 report sensitive/regulated data incidents in a timely manner.

Level 4 Quantitatively Controlled

Utilize SCR-CMM Level 3 criteria definitions:
▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control.
▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.

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 Classification & Prioritization

Description

Mechanisms exist to identify classes of incidents and actions to take to ensure the continuation of organizational missions and business functions.

Possible Solutions & Considerations

Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2

∙ National Cyber Incident Scoring
System (NCISS) (https://cisa.gov)

Small Business (10-49 staff) / BLS Firm Size Classes 3-4

∙ National Cyber Incident Scoring
System (NCISS) (https://cisa.gov)

Medium Business (50-249 staff) / BLS Firm Size Classes 5-6

∙ National Cyber Incident Scoring
System (NCISS) (https://cisa.gov)

Large Business (250-999 staff) / BLS Firm Size Classes 7-8

∙ National Cyber Incident Scoring
System (NCISS) (https://cisa.gov)

Enterprise (> 1,000 staff) / BLS Firm Size Class 9

∙ National Cyber Incident Scoring
System (NCISS) (https://cisa.gov)

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 identify classes of incidents and actions to take to ensure the continuation of organizational missions and business functions.

Level 4 Quantitatively Controlled

Utilize SCR-CMM Level 3 criteria definitions:
▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control.
▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.

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.
SCF Cyber Incident Reporting for Sensitive / Regulated Data

Description

Mechanisms exist to report sensitive and/or regulated data incidents in a timely manner.

Possible Solutions & Considerations

Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2

∙ Incident Response Plan (IRP)

Small Business (10-49 staff) / BLS Firm Size Classes 3-4

∙ Incident Response Plan (IRP)

Medium Business (50-249 staff) / BLS Firm Size Classes 5-6

∙ Integrated Incident Response Program (IIRP)
∙ Integrated Security Incident Response Team (ISIRT)

Large Business (250-999 staff) / BLS Firm Size Classes 7-8

∙ Integrated Incident Response Program (IIRP)
∙ Integrated Security Incident Response Team (ISIRT)

Enterprise (> 1,000 staff) / BLS Firm Size Class 9

∙ Integrated Incident Response Program (IIRP)
∙ Integrated Security Incident Response Team (ISIRT)

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

Incident Response (IRO) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with IRO domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Incident response-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ IT and/or cybersecurity personnel use an informal process to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.

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.

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 report sensitive/regulated data incidents in a timely manner.

Level 4 Quantitatively Controlled

Utilize SCR-CMM Level 3 criteria definitions:
▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control.
▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.

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 Disclosure of Vulnerabilities

Description

Mechanisms exist to disclose information about vulnerabilities to relevant stakeholders, including:
(1) A description of the vulnerability(ies);
(2) Affected product(s) and/or service(s);
(3) Potential impact of the vulnerability(ies);
(4) Severity of the vulnerability(ies); and
(5) Guidance to remediate the vulnerability(ies).

Possible Solutions & Considerations

Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2

∙ Notify customers of vulnerabilities in any developed products via email/website

Small Business (10-49 staff) / BLS Firm Size Classes 3-4

∙ Security advisory template and distribution process
∙ security.txt / contact for vulnerability reports

Medium Business (50-249 staff) / BLS Firm Size Classes 5-6

∙ Vulnerability disclosure process with advisories (description, impact, remediation)
∙ Coordinated disclosure timelines

Large Business (250-999 staff) / BLS Firm Size Classes 7-8

∙ Product Security Incident Response Team (PSIRT) disclosure process (ISO/IEC 29147)
∙ CVE issuance for product vulnerabilities
∙ Customer notification channels

Enterprise (> 1,000 staff) / BLS Firm Size Class 9

∙ Enterprise coordinated vulnerability disclosure program (ISO/IEC 29147, CNA participation)
∙ Public advisory portal and machine-readable advisories (CSAF)
∙ Regulatory notification (e.g., EU CRA) integration

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

Technology Development & Acquisition (TDA) 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 TDA domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with TDA 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 TDA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ Technology development and acquisition management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ Secure development practices mostly conform to industry-recognized standards for secure engineering of Technology Assets, Applications and/or Services (TAAS) (e.g., OWASP, NIST SP 800-218 and NIST SP 800-160).
▪ An application development team, or similar function, uses a structured process to design, build and maintain secure configurations for test, development, staging and production environments.

Level 3 Well Defined

Technology Development & Acquisition (TDA) 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 TDA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners.
▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution and software testing tools).
▪ 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 TDA 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 disclose information about vulnerabilities to relevant stakeholders, including:
(1) A description of the vulnerability(ies);
(2) Affected product(s) and/or service(s);
(3) Potential impact of the vulnerability(ies);
(4) Severity of the vulnerability(ies); and
(5) Guidance to remediate the vulnerability(ies).

Level 4 Quantitatively Controlled

Utilize SCR-CMM Level 3 criteria definitions:
▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control.
▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.

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.