+14 straipsnis Gamintojų pareiga pranešti
---+14 straipsnis 1.
---+14 straipsnis 2.
---+14 straipsnis 3.
---+14 straipsnis 4.
---+14 straipsnis 5.
---+14 straipsnis 6.
---+14 straipsnis 7.
---+14 straipsnis 8.
---+14 straipsnis 9.
---+14 straipsnis 10.
|
14 straipsnis Gamintojų pareiga pranešti
-
1. Apžvalga
| Pavadinimas |
Reguliavimas |
|
14 straipsnis 1.
|
Gamintojas praneša apie visus aktyviai išnaudojamus produkto su skaitmeniniais elementais pažeidžiamumus, apie kuriuos sužino, tuo pačiu metu koordinatore paskirtai CSIRT pagal šio straipsnio 7 dalį ir ENISA. Gamintojas apie tą aktyviai išnaudojamą pažeidžiamumą praneša per bendrą pranešimų teikimo platformą, sukurtą pagal 16 straipsnį.
|
|
14 straipsnis 2.
|
1 dalyje nurodyto pranešimo tikslais gamintojas:
a)
nepagrįstai nedelsdamas ir bet kuriuo atveju per 24 valandas nuo tada, kai gamintojas apie jį sužino, pateikia ankstyvąjį perspėjimą apie aktyviai išnaudojamą pažeidžiamumą, nurodydamas, kai taikytina, valstybes nares, kurių teritorijoje, gamintojo žiniomis, jo produktas su skaitmeniniais elementais yra prieinamas;
b)
išskyrus atvejus, kai atitinkama informacija jau yra pateikta, nepagrįstai nedelsdamas ir bet kuriuo atveju ne vėliau kaip per 72 valandas nuo tada, kai gamintojas sužino apie aktyviai išnaudojamą pažeidžiamumą, pateikia pranešimą apie pažeidžiamumą, kuriame pateikiama turima bendro pobūdžio informacija apie atitinkamą produktą su skaitmeniniais elementais, bendrą išnaudojimo ir atitinkamo pažeidžiamumo pobūdį, taip pat apie visas taisomąsias ar rizikos mažinimo priemones, kurių imtasi, ir apie taisomąsias ar rizikos mažinimo priemones, kurių gali imtis naudotojai, ir kuriame taip pat nurodoma, kai taikytina, kiek neskelbtina, gamintojo nuomone, yra jo pateikta informacija;
c)
išskyrus atvejus, kai atitinkama informacija jau yra pateikta, pateikia galutinį pranešimą ne vėliau kaip per 14 dienų po to, kai buvo imtasi taisomosios ar rizikos mažinimo priemonės, įskaitant bent šią informaciją:
i)
pažeidžiamumo aprašymą, įskaitant jo sunkumą ir poveikį;
ii)
jei turima, informaciją apie bet kurį piktavalį subjektą, kuris išnaudojo arba išnaudoja pažeidžiamumą;
iii)
duomenis apie saugumo naujinius arba kitas taisomąsias priemones, kurių buvo imtasi siekiant pašalinti pažeidžiamumą.
|
|
14 straipsnis 3.
|
Gamintojas praneša apie didelį incidentą, darantį poveikį produkto su skaitmeniniais elementais saugumui, apie kurį sužino, tuo pačiu metu koordinatore paskirtai CSIRT pagal šio straipsnio 7 dalį ir ENISA. Gamintojas apie tą incidentą praneša per bendrą pranešimų teikimo platformą, sukurtą pagal 16 straipsnį.
|
|
14 straipsnis 4.
|
3 dalyje nurodyto pranešimo tikslais gamintojas:
a)
pateikia ankstyvąjį perspėjimą apie didelį incidentą, darantį poveikį produkto su skaitmeniniais elementais saugumui, nepagrįstai nedelsdamas ir bet kuriuo atveju per 24 valandas nuo tada, kai gamintojas apie jį sužino, be kita ko, bent tuo momentu, kai įtariama, kad incidentą sukėlė neteisėti ar piktavališki veiksmai, kuriame taip pat nurodomos, kai taikytina, valstybės narės, kurių teritorijoje, gamintojo žiniomis, jo produktas su skaitmeniniais elementais yra prieinamas;
b)
išskyrus atvejus, kai atitinkama informacija jau yra pateikta, nepagrįstai nedelsdamas ir bet kuriuo atveju ne vėliau kaip per 72 valandas nuo tada, kai gamintojas sužino apie incidentą, pateikia pranešimą apie incidentą, kuriame pateikiama turima bendro pobūdžio informacija apie incidentą, pradinį incidento vertinimą, taip pat apie visas taisomąsias ar rizikos mažinimo priemones, kurių imtasi, visas taisomąsias ar rizikos mažinimo priemones, kurių gali imtis naudotojai, ir kuriame taip pat nurodoma, kai taikytina, kiek neskelbtina, gamintojo nuomone, yra jo pateikta informacija;
c)
išskyrus atvejus, kai atitinkama informacija jau yra pateikta, pateikia galutinį pranešimą per vieną mėnesį nuo b punkte nurodyto pranešimo apie incidentą pateikimo dienos, įskaitant bent šią informaciją:
i)
išsamų incidento, įskaitant jo sunkumą ir poveikį, aprašymą;
ii)
grėsmės arba pagrindinės priežasties, dėl kurios incidentas galėjo būti sukeltas, tipą;
iii)
taikomas ir įgyvendinamas rizikos mažinimo priemones.
|
|
14 straipsnis 5.
|
3 dalies tikslais incidentas, darantis poveikį produkto su skaitmeniniais elementais saugumui, laikomas dideliu, jei:
a)
jis neigiamai veikia arba gali neigiamai paveikti produkto su skaitmeniniais elementais gebėjimą apsaugoti neskelbtinų ar svarbių duomenų arba funkcijų prieinamumą, autentiškumą, vientisumą ar konfidencialumą, arba
b)
jis lėmė arba gali lemti piktavališko kodo įdiegimą į produktą su skaitmeniniais elementais arba produkto su skaitmeniniais elementais naudotojo tinklų ir informacines sistemas ar tokio kodo vykdymą.
|
|
14 straipsnis 6.
|
Prireikus, koordinatore paskirta CSIRT, kuri pirmoji gavo pranešimą, gali paprašyti gamintojų pateikti tarpinį pranešimą apie atitinkamą atnaujintą padėties informaciją apie aktyviai išnaudojamą pažeidžiamumą arba didelį incidentą, darantį poveikį produkto su skaitmeniniais elementais saugumui.
|
|
14 straipsnis 7.
|
Šio straipsnio 1 ir 3 dalyse nurodyti pranešimai teikiami per 16 straipsnyje nurodytą bendrą pranešimų teikimo platformą, naudojant vieną iš 16 straipsnio 1 dalyje nurodytų elektroninio pranešimo galinių įrenginių. Pranešimas pateikiamas naudojant valstybės narės, kurioje yra gamintojo pagrindinė buveinė Sąjungoje, koordinatore paskirtos CSIRT elektroninio pranešimo galinį įrenginį ir jis tuo pačiu metu turi būti prieinamas ENISA. Šio reglamento tikslais laikoma, kad gamintojo pagrindinė buveinė Sąjungoje yra toje valstybėje narėje, kurioje daugiausia priimami su to gamintojo produktų su skaitmeniniais elementais kibernetiniu saugumu susiję sprendimai. Jei tokios valstybės narės neįmanoma nustatyti, laikoma, kad pagrindinė buveinė yra valstybėje narėje, kurioje atitinkamas gamintojas turi padalinį, kuriame dirba daugiausia darbuotojų Sąjungoje. Jei gamintojas neturi pagrindinės buveinės Sąjungoje, jis 1 ir 3 dalyse nurodytus pranešimus pateikia naudodamas valstybės narės, kuri nustatoma laikantis toliau nurodytos tvarkos ir remiantis gamintojo turima informacija, koordinatore paskirtos CSIRT elektroninio pranešimo galinį įrenginį:
a)
valstybė narė, kurioje įsisteigęs gamintojo vardu veikiantis įgaliotasis atstovas, atstovaujantis didžiausiam skaičiui to gamintojo produktų su skaitmeniniais elementais;
b)
valstybė narė, kurioje įsisteigęs importuotojas, pateikiantis rinkai didžiausią to gamintojo produktų su skaitmeniniais elementais skaičių;
c)
valstybė narė, kurioje įsisteigęs platintojas, tiekiantis rinkai didžiausią to gamintojo produktų su skaitmeniniais elementais skaičių;
d)
valstybė narė, kurioje yra didžiausias to gamintojo produktų su skaitmeniniais elementais naudotojų skaičius.
Kiek tai susiję su trečios pastraipos d punktu, gamintojas gali pateikti pranešimus, susijusius su bet kokiu vėlesniu aktyviai išnaudojamu pažeidžiamumu arba dideliu incidentu, darančiu poveikį produkto su skaitmeniniais elementais saugumui, tai pačiai koordinatore paskirtai CSIRT, kuriai jis pirmą kartą pateikė pranešimą.
|
|
14 straipsnis 8.
|
Sužinojęs apie aktyviai išnaudojamą pažeidžiamumą arba didelį incidentą, darantį poveikį produkto su skaitmeniniais elementais saugumui, gamintojas informuoja paveiktus produkto su skaitmeniniais elementais naudotojus ir, kai tinkama, visus naudotojus apie tą pažeidžiamumą arba didelį incidentą, ir, jei būtina, apie visas rizikos mažinimo ir taisomąsias priemones, kurių naudotojai gali imtis, kad sumažintų to pažeidžiamumo ar incidento poveikį, kai tinkama, struktūrizuotu, kompiuterio skaitomu formatu, kuris būtų lengvai automatiškai apdorojamas. Jei gamintojas laiku neinformuoja produkto su skaitmeniniais elementais naudotojų, koordinatorėmis paskirtos CSIRT, gavusios pranešimą, gali pateikti tokią informaciją naudotojams, kai manoma, kad tai proporcinga ir būtina siekiant užkirsti kelią to pažeidžiamumo ar incidento poveikiui arba jį sumažinti.
|
|
14 straipsnis 9.
|
Ne vėliau kaip 2025 m. gruodžio 11 d. Komisija pagal šio reglamento 61 straipsnį priima deleguotuosius aktus, siekiant šį reglamentą papildyti, kuriais nustatomos sąlygos, kuriomis taikomos su kibernetiniu saugumu susijusios priežastys, dėl kurių atidedamas pranešimų platinimas, kaip nurodyta šio reglamento 16 straipsnio 2 dalyje. Rengdama deleguotųjų aktų projektus Komisija bendradarbiauja su CSIRT tinklu, sukurtu pagal Direktyvos (ES) 2022/2555 15 straipsnį, ir ENISA.
|
|
14 straipsnis 10.
|
Komisija gali įgyvendinimo aktais išsamiau nustatyti šiame straipsnyje ir 15 bei 16 straipsniuose nurodytų pranešimų formatą ir procedūras. Tie įgyvendinimo aktai priimami laikantis 62 straipsnio 2 dalyje nurodytos nagrinėjimo procedūros. Rengdama tų įgyvendinimo aktų projektus Komisija bendradarbiauja su CSIRT tinklu ir ENISA.
|
,
1.1 Nuorodos
1.2 Nustatyti reikalavimai
1.3 Susiję standartai
2. Nustatyti reikalavimai
Reikalavimai
| Šaltinis |
Reikalavimas |
3. Susiję standartai
Standartai
| Šaltinis |
Reikalavimas |
|
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.
|
|