+Artikel 14 Fabrikantens rapporteringsforpligtelser
---+Artikel 14 1.
---+Artikel 14 2.
---+Artikel 14 3.
---+Artikel 14 4.
---+Artikel 14 5.
---+Artikel 14 6.
---+Artikel 14 7.
---+Artikel 14 8.
---+Artikel 14 9.
---+Artikel 14 10.

Artikel 14 Fabrikantens rapporteringsforpligtelser

-

1. Oversigt

,
Artikel 14 1.
En fabrikant underretter samtidig den CSIRT, der er udpeget som koordinator i overensstemmelse med denne artikels stk. 7, og ENISA om enhver aktivt udnyttet sårbarhed i produktet med digitale elementer, som fabrikanten får kendskab til. Fabrikanten underretter om den aktivt udnyttede sårbarhed via den fælles indberetningsplatform, der er oprettet i henhold til artikel 16.
Artikel 14 2.

Med henblik på den underretning, der er omhandlet i stk. 1, indgiver fabrikanten:

a) 

en tidlig varsling om en aktivt udnyttet sårbarhed uden unødigt ophold og under alle omstændigheder senest 24 timer efter, at fabrikanten har fået kendskab hertil, i givet fald med angivelse af de medlemsstater, på hvis område fabrikanten er bekendt med, at dennes produkt med digitale elementer er gjort tilgængeligt

b) 

medmindre de relevante oplysninger allerede er afgivet, en meddelelse om sårbarhed uden unødigt ophold og under alle omstændigheder senest 72 timer efter, at fabrikanten har fået kendskab til den aktivt udnyttede sårbarhed, hvilken meddelelse skal indeholde generelle oplysninger, i det omfang sådanne foreligger, om det pågældende produkt med digitale elementer, den generelle karakter af udnyttelsen og den pågældende sårbarhed samt eventuelle korrigerende eller afbødende foranstaltninger, der er truffet, og korrigerende eller afbødende foranstaltninger, som brugerne kan træffe, og som i givet fald også angiver, hvor følsomme fabrikanten vurderer de meddelte oplysninger at være

c) 

medmindre de relevante oplysninger allerede er afgivet, en endelig rapport senest 14 dage efter, at en korrigerende eller afbødende foranstaltning bliver tilgængelig, der som minimum indeholder følgende:

i) 

en beskrivelse af sårbarheden, herunder dens alvor og indvirkning

ii) 

oplysninger om eventuelle ondsindede aktører, der har udnyttet eller udnytter sårbarheden, hvis sådanne oplysninger foreligger

iii) 

oplysninger om sikkerhedsopdateringen eller andre korrigerende foranstaltninger, der er gjort tilgængelige for at afhjælpe sårbarheden.
Artikel 14 3.
En fabrikant underretter samtidig den CSIRT, der er udpeget som koordinator i overensstemmelse med denne artikels stk. 7, og ENISA, om enhver alvorlig hændelse, der har indvirkning på sikkerheden af produktet med digitale elementer, som fabrikanten får kendskab til. Fabrikanten underretter om hændelsen via den fælles indberetningsplatform, der er oprettet i henhold til artikel 16.
Artikel 14 4.

Med henblik på den underretning, der er omhandlet i stk. 3, indgiver fabrikanten:

a) 

en tidlig varsling om en alvorlig hændelse, der indvirker på sikkerheden af produktet med digitale elementer, uden unødigt opholde og under alle omstændigheder senest 24 timer efter, at fabrikanten har fået kendskab hertil, herunder som minimum om, hvorvidt fabrikanten har mistanke om at hændelsen skyldes ulovlige eller ondsindede handlinger, og i givet fald med angivelse af de medlemsstater, på hvis område fabrikanten er bekendt med, at dennes produkt med digitale elementer er blevet gjort tilgængeligt

b) 

medmindre de relevante oplysninger allerede er afgivet, en underretning om en hændelse uden unødigt ophold og under alle omstændigheder senest 72 timer efter, at fabrikanten har fået kendskab til hændelsen, med generelle oplysninger, hvis sådanne foreligger, om arten af hændelsen, en indledende vurdering af hændelsen samt eventuelle korrigerende eller afbødende foranstaltninger, der er truffet, og korrigerende eller afbødende foranstaltninger, som brugerne kan træffe, og som også, i givet fald, angiver, hvor følsomme fabrikanten vurderer de meddelte oplysninger at være

c) 

medmindre de relevante oplysninger allerede er afgivet, en endelig rapport senest en måned efter indgivelsen af den i litra b) omhandlede underretning om en hændelse, der som minimum omfatter følgende:

i) 

en detaljeret beskrivelse af hændelsen, herunder dens alvor og indvirkning

ii) 

den type trussel eller grundlæggende årsag, der sandsynligvis udløste hændelsen

iii) 

anvendte og igangværende afbødende foranstaltninger.
Artikel 14 5.

Med henblik på stk. 3 anses en hændelse, der indvirker på sikkerheden af produktet med digitale elementer, for at være alvorlig, hvis:

a) 

den indvirker eller kan indvirke negativt på evnen til at beskytte tilgængeligheden, autenticiteten, integriteten eller fortroligheden af følsomme eller vigtige data eller funktioner, eller

b) 

den har ført til eller er i stand til at føre til indførelse eller udførelse af ondsindet kode i et produkt med digitale elementer eller i net- og informationssystemer hos en bruger af produktet med digitale elementer.
Artikel 14 6.
Hvis det er nødvendigt, kan den CSIRT, der er udpeget som koordinator, og som indledningsvist modtager underretningen, anmode fabrikanten om at forelægge en foreløbig rapport om relevante statusopdateringer om den aktivt udnyttede sårbarhed eller alvorlige hændelse, der har indvirkning på sikkerheden af produktet med digitale elementer.
Artikel 14 7.
De underretninger, der er omhandlet i denne artikels stk. 1 og 3, indgives via den fælles indberetningsplatform, der er omhandlet i artikel 16, ved hjælp af et af de adgangspunkter for elektronisk underretning, der er omhandlet i artikel 16, stk. 1. Underretningen indgives ved hjælp af adgangspunktet for elektronisk underretning i den CSIRT, der er udpeget som koordinator i den medlemsstat, hvor fabrikanten har sit hovedforretningssted i Unionen, og skal samtidig være tilgængelig for ENISA.

Med henblik på denne forordning anses en fabrikant for at have sit hovedforretningssted i Unionen i den medlemsstat, hvor beslutningerne vedrørende cybersikkerheden af fabrikantens produkter med digitale elementer overvejende træffes. Hvis en sådan medlemsstat ikke kan fastslås, anses hovedforretningsstedet for at være i den medlemsstat, hvor den pågældende fabrikant forretningssted med det største antal ansatte i Unionen er beliggende.

Hvis en fabrikant ikke har noget hovedforretningssted i Unionen, indgiver denne de underretninger, der er omhandlet i stk. 1 og 3, ved hjælp af adgangspunktet for elektronisk underretning i den CSIRT, der er udpeget som koordinator i den medlemsstat, der er fastsat i henhold til følgende rækkefølge og på grundlag af de oplysninger, som fabrikanten har til rådighed:

a) 

den medlemsstat, hvor den bemyndigede repræsentant, som handler på fabrikantens vegne for det største antal produkter med digitale elementer fra den pågældende fabrikant, er etableret

b) 

den medlemsstat, hvor den importør, som bringer det største antal produkter med digitale elementer fra den pågældende fabrikant i omsætning, er etableret

c) 

den medlemsstat, hvor den distributør, som bringer det største antal produkter med digitale elementer fra den pågældende fabrikant i omsætning, er etableret

d) 

den medlemsstat, hvor det største antal brugere af produkter med digitale elementer fra den pågældende fabrikant befinder sig.

For så vidt angår tredje afsnit, litra d), kan en fabrikant indgive underretninger vedrørende enhver efterfølgende aktivt udnyttet sårbarhed eller alvorlig hændelse, der har indvirkning på sikkerheden af produktet med digitale elementer, til den samme CSIRT, der er udpeget som koordinator, og til hvem fabrikanten indberettede i første omgang.
Artikel 14 8.
Efter at have fået kendskab til en aktivt udnyttet sårbarhed eller en alvorlig hændelse, der har indvirkning på sikkerheden af produktet med digitale elementer, underretter fabrikanten de berørte brugere af produktet med digitale elementer og, hvor det er relevant, alle brugere om denne sårbarhed eller hændelse, og om nødvendigt om eventuel risikobegrænsning og eventuelle korrigerende foranstaltninger, som brugerne kan træffe for at afbøde virkningen af den pågældende sårbarhed eller hændelse, hvor det er relevant i et struktureret maskinlæsbart format, der er let automatisk bearbejdeligt. Hvis fabrikanten ikke rettidigt oplyser brugerne af produktet med digitale elementer, kan de underrettede CSIRT'er, der er udpeget som koordinatorer, give brugerne sådanne oplysninger, når dette anses for at være forholdsmæssigt og nødvendigt for at forebygge eller afbøde virkningen af den pågældende sårbarhed eller hændelse.
Artikel 14 9.
Senest den 11. december 2025 vedtager Kommissionen delegerede retsakter i overensstemmelse med denne forordnings artikel 61 med henblik på at supplere denne forordning ved at præcisere vilkårene og betingelserne for anvendelse af de cybersikkerhedsrelaterede grunde i forbindelse med udsættelse af formidlingen af underretninger som omhandlet i denne forordnings artikel 16, stk. 2. Kommissionen samarbejder med CSIRT-netværket oprettet i henhold til artikel 15 i direktiv (EU) 2022/2555 og ENISA om udarbejdelsen af udkastene til delegerede retsakter.
Artikel 14 10.
Kommissionen kan ved hjælp af gennemførelsesretsakter yderligere præcisere formatet og procedurerne for de underretninger, der er omhandlet i denne artikel samt i artikel 15 og 16. Disse gennemførelsesretsakter vedtages efter undersøgelsesproceduren, jf. artikel 62, stk. 2. Kommissionen samarbejder med CSIRT-netværket og ENISA om udarbejdelsen af disse udkast til gennemførelsesretsakter.

1.1 Referencer

1.2 Identificerede krav

1.3 Relaterede standarder

2. Identificerede krav

Krav

3. Relaterede standarder

Standarder
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.