+Article 13 Apprentissage et évolution
---+Article 13 1
---+Article 13 2
---+Article 13 3
---+Article 13 4
---+Article 13 5
---+Article 13 6
---+Article 13 7

Article 13 Apprentissage et évolution

1. Vue d’ensemble

Article 13 1

1. Financial entities shall have in place capabilities and staff to gather information on vulnerabilities and cyber threats, ICT-related incidents, in particular cyber-attacks, and analyse the impact they are likely to have on their digital operational resilience.

Article 13 2

2. Financial entities shall put in place post ICT-related incident reviews after a major ICT-related incident disrupts their core activities, analysing the causes of disruption and identifying required improvements to the ICT operations or within the ICT business continuity policy referred to in Article 11.

Financial entities, other than microenterprises, shall, upon request, communicate to the competent authorities, the changes that were implemented following post ICT-related incident reviews as referred to in the first subparagraph.

The post ICT-related incident reviews referred to in the first subparagraph shall determine whether the established procedures were followed and the actions taken were effective, including in relation to the following:

(a)	the promptness in responding to security alerts and determining the impact of ICT-related incidents and their severity;

(b)	the quality and speed of performing a forensic analysis, where deemed appropriate;

(c)	the effectiveness of incident escalation within the financial entity;

(d)	the effectiveness of internal and external communication.

Article 13 3

3. Lessons derived from the digital operational resilience testing carried out in accordance with Articles 26 and 27 and from real life ICT-related incidents, in particular cyber-attacks, along with challenges faced upon the activation of ICT business continuity plans and ICT response and recovery plans, together with relevant information exchanged with counterparts and assessed during supervisory reviews, shall be duly incorporated on a continuous basis into the ICT risk assessment process. Those findings shall form the basis for appropriate reviews of relevant components of the ICT risk management framework referred to in Article 6(1).

Article 13 4

4. Financial entities shall monitor the effectiveness of the implementation of their digital operational resilience strategy set out in Article 6(8). They shall map the evolution of ICT risk over time, analyse the frequency, types, magnitude and evolution of ICT-related incidents, in particular cyber-attacks and their patterns, with a view to understanding the level of ICT risk exposure, in particular in relation to critical or important functions, and enhance the cyber maturity and preparedness of the financial entity.

Article 13 5

5. Senior ICT staff shall report at least yearly to the management body on the findings referred to in paragraph 3 and put forward recommendations.

Article 13 6

6. Financial entities shall develop ICT security awareness programmes and digital operational resilience training as compulsory modules in their staff training schemes. Those programmes and training shall be applicable to all employees and to senior management staff, and shall have a level of complexity commensurate to the remit of their functions. Where appropriate, financial entities shall also include ICT third-party service providers in their relevant training schemes in accordance with Article 30(2), point (i).

Article 13 7

7. Financial entities, other than microenterprises, shall monitor relevant technological developments on a continuous basis, also with a view to understanding the possible impact of the deployment of such new technologies on ICT security requirements and digital operational resilience. They shall keep up-to-date with the latest ICT risk management processes, in order to effectively combat current or new forms of cyber-attacks.

1.1 Références

1.2 Exigences identifiées

1.3 Normes associées

2. Exigences identifiées

Exigences
Source	Exigence

3. Normes associées

Normes
Source	Exigence
SCF	Status Reporting To Governing Body Description Mechanisms exist to provide governance oversight reporting and recommendations enabling executives to make decisions about matters considered material to the organization's Security, Compliance & Resilience Program (SCRP). Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Quarterly Business Review (QBR) ∙ Simple security status dashboard (spreadsheet or slide deck) ∙ Email status updates to owner/manager Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Quarterly Business Review (QBR) ∙ Structured security metrics report (incidents, patching status, training completion) ∙ Documented reporting cadence Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Quarterly Business Review (QBR) ∙ Formal security status reports to leadership ∙ KPI/KRI dashboard (e.g., Power BI, Tableau, or GRC tool reporting) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Quarterly Business Review (QBR) ∙ Executive security dashboard with KPIs/KRIs ∙ Board-level reporting on material risk indicators ∙ Automated reporting via GRC platform Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Quarterly Business Review (QBR) ∙ Board and audit committee cybersecurity briefings ∙ Integrated GRC dashboard with real-time metrics ∙ SEC cybersecurity disclosure-ready reporting processes (if applicable) 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 Cybersecurity & Data Protection Governance (GOV) 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 GOV domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with GOV 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel. ▪ Organizational leadership maintains an informal process to review and respond to trends. Level 3 Well Defined Cybersecurity & Data Protection Governance (GOV) 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 GOV 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 GOV domain capabilities are well-documented and kept current by process owners. ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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). ▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform). ▪ An implemented and operational capability exists to provide governance oversight reporting and recommendations to those entrusted to make executive decisions about matters considered material to the organization's Security, Compliance & Resilience Program (SCRP). 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	Measures of Performance Description Mechanisms exist to develop, report and monitor Security, Compliance & Resilience Program (SCRP) measures of performance. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Manually-generated metrics (spreadsheet-based dashboard) ∙ Basic security scorecard (patch %, training completion %, incident count) Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Manually-generated metrics with structured reporting template ∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.) ∙ Simple security dashboard (e.g., Power BI free tier, Google Looker Studio) Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Automated metrics via GRC or security tool integrations ∙ Security dashboard with defined KPIs/KRIs (e.g., Power BI, GRC platform reporting) ∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ GRC platform with integrated metrics and dashboards ∙ Automated data collection from security tools (SIEM, vulnerability scanner, etc.) ∙ Defined measurement cadence aligned with board reporting schedule Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Enterprise GRC platform with automated metrics collection and reporting ∙ Security metrics integrated with business intelligence platform (e.g., Tableau, Power BI) ∙ Automated benchmarking against industry standards (e.g., CIS Benchmarks, CISA metrics) ∙ Real-time security posture dashboards for executive and board reporting 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 Cybersecurity & Data Protection Governance (GOV) 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 GOV domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with GOV 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 GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel. ▪ Basic metrics are developed to provide operational oversight of a limited scope of cybersecurity and data protection controls. Level 3 Well Defined Cybersecurity & Data Protection Governance (GOV) 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 GOV 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 GOV domain capabilities are well-documented and kept current by process owners. ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV 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). ▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform). ▪ An implemented and operational capability exists to develop, report and monitor Security, Compliance & Resilience Program (SCRP) measures of performance. Level 4 Quantitatively Controlled Cybersecurity & Data Protection Governance (GOV) 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 Cybersecurity & Data Protection Governance (GOV) 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. ▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes. ▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies.
SCF	Contingency Plan Root Cause Analysis (RCA) & Lessons Learned Description Mechanisms exist to conduct a Root Cause Analysis (RCA) and "lessons learned" activity every time the contingency plan is activated. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Root Cause Analysis (RCA) (After Action Review (AAR), lessons learned, etc.) Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Root Cause Analysis (RCA) (After Action Review (AAR), lessons learned, etc.) Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Root Cause Analysis (RCA) (After Action Review (AAR), lessons learned, etc.) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Root Cause Analysis (RCA) (After Action Review (AAR), lessons learned, etc.) Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Root Cause Analysis (RCA) (After Action Review (AAR), lessons learned, etc.) 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 Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs and redundant power). Level 2 Planned Tracked Business Continuity & Disaster Recovery (BCD) 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 BCD domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with BCD 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. Level 3 Well Defined Business Continuity & Disaster Recovery (BCD) 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 BCD 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 BCD domain capabilities are well-documented and kept current by process owners. ▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation 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 BCD 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 conduct a Root Cause Analysis (RCA) and "lessons learned" activity every time the contingency plan is activated. 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	Root Cause Analysis (RCA) & Lessons Learned Description Mechanisms exist to incorporate lessons learned from analyzing and resolving cybersecurity and data protection incidents to reduce the likelihood or impact of future incidents. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Root Cause Analysis (RCA) Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Root Cause Analysis (RCA) Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Root Cause Analysis (RCA) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Root Cause Analysis (RCA) Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Root Cause Analysis (RCA) 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. ▪ Incident responders provide After Action Review (AAR) feedback on what worked, what did not work and ways to improve future responses to similar incidents. ▪ A formal Root Cause Analysis (RCA) is performed that documents the findings in a report for both technical and business leadership management. 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 incorporate lessons learned from analyzing and resolving cybersecurity and data protection incidents to reduce the likelihood or impact of future incidents. 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	Root Cause Analysis (RCA) & Lessons Learned Description Mechanisms exist to incorporate lessons learned from analyzing and resolving cybersecurity and data protection incidents to reduce the likelihood or impact of future incidents. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Root Cause Analysis (RCA) Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Root Cause Analysis (RCA) Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Root Cause Analysis (RCA) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Root Cause Analysis (RCA) Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Root Cause Analysis (RCA) 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. ▪ Incident responders provide After Action Review (AAR) feedback on what worked, what did not work and ways to improve future responses to similar incidents. ▪ A formal Root Cause Analysis (RCA) is performed that documents the findings in a report for both technical and business leadership management. 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 incorporate lessons learned from analyzing and resolving cybersecurity and data protection incidents to reduce the likelihood or impact of future incidents. 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	Security, Compliance & Resilience-Minded Workforce Description Mechanisms exist to facilitate the implementation of security workforce development and awareness controls. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Third-party advisors (e.g., virtual CISO, Managed Security Services Provider (MSSP), etc.) Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Third-party advisors (e.g., virtual CISO, Managed Security Services Provider (MSSP), etc.) Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Chief Information Security Officer (CISO) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Chief Information Security Officer (CISO) Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Chief Information Security Officer (CISO) 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 Security Awareness & Training (SAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with SAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Security awareness and training-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ Security awareness and training methods are often generic, without organization-specific content. Level 2 Planned Tracked Security Awareness & Training (SAT) 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 SAT domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with SAT 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Users are educated on their responsibilities to protect TAASD assigned to them or under their supervision. ▪ IT and/or cybersecurity personnel create/govern security and awareness training to meet specific statutory, regulatory and/or contractual compliance obligations. ▪ Privileged users receive formal security and/or data privacy awareness training to ensure they understand their unique roles and responsibilities. ▪ The responsibility for training users and enforcing policies may be assigned to user's immediate supervisor(s)/manager(s), including the definition and enforcement of the user's specific role(s) and responsibilities. Level 3 Well Defined Security Awareness & Training (SAT) 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 SAT 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 SAT domain capabilities are well-documented and kept current by process owners. ▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions). ▪ 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 SAT 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 facilitate the implementation of security workforce development and awareness controls. Level 4 Quantitatively Controlled Security Awareness & Training (SAT) 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	Security, Compliance & Resilience Awareness Training Description Mechanisms exist to provide all employees and contractors appropriate security, compliance and resilience awareness education and training that is relevant for their job function. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Initial & annual security, compliance and resilience awareness training ∙ KnowB4 (https://knowbe4.com) Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Initial & annual security, compliance and resilience awareness training ∙ KnowB4 (https://knowbe4.com) Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Initial & annual security, compliance and resilience awareness training ∙ KnowB4 (https://knowbe4.com) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Initial & annual security, compliance and resilience awareness training ∙ KnowB4 (https://knowbe4.com) Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Initial & annual security, compliance and resilience awareness training ∙ KnowB4 (https://knowbe4.com) 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 Security Awareness & Training (SAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with SAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Security awareness and training-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ Security awareness and training methods are often generic, without organization-specific content. Level 2 Planned Tracked Security Awareness & Training (SAT) 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 SAT domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with SAT 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Users are educated on their responsibilities to protect TAASD assigned to them or under their supervision. ▪ IT and/or cybersecurity personnel create/govern security and awareness training to meet specific statutory, regulatory and/or contractual compliance obligations. Level 3 Well Defined Security Awareness & Training (SAT) 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 SAT 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 SAT domain capabilities are well-documented and kept current by process owners. ▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions). ▪ 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 SAT 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 provide all employees and contractors appropriate security, compliance and resilience awareness education and training that is relevant for their job function. Level 4 Quantitatively Controlled Security Awareness & Training (SAT) 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	Role-Based Security, Compliance & Resilience Training Description Mechanisms exist to provide role-based security, compliance and resilience-related training: (1) Before authorizing access to the system or performing assigned duties; (2) When required by system changes; and (3) Annually thereafter. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ KnowB4 (https://knowbe4.com) Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ KnowB4 (https://knowbe4.com) Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ KnowB4 (https://knowbe4.com) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ KnowB4 (https://knowbe4.com) Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ KnowB4 (https://knowbe4.com) 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 Security Awareness & Training (SAT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with SAT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Security awareness and training-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ Security awareness and training methods are often generic, without organization-specific content. ▪ IT/cybersecurity personnel self-manage their professional certification requirements to support their assigned duties. Level 2 Planned Tracked Security Awareness & Training (SAT) 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 SAT domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with SAT 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Users are educated on their responsibilities to protect TAASD assigned to them or under their supervision. ▪ IT and/or cybersecurity personnel create/govern security and awareness training to meet specific statutory, regulatory and/or contractual compliance obligations. ▪ Privileged users receive formal security and/or data privacy awareness training to ensure they understand their unique roles and responsibilities. ▪ The responsibility for training users and enforcing policies may be assigned to user's immediate supervisor(s)/manager(s), including the definition and enforcement of the user's specific role(s) and responsibilities. ▪ Security awareness and training methods are role-based (e.g., handling sensitive/regulated data). Level 3 Well Defined Security Awareness & Training (SAT) 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 SAT 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 SAT domain capabilities are well-documented and kept current by process owners. ▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions). ▪ 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 SAT 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 provide role-based security, compliance and resilience-related training: (1) Before authorizing access to the system or performing assigned duties; (2) When required by system changes; and (3) Annually thereafter. Level 4 Quantitatively Controlled Security Awareness & Training (SAT) 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 Threat Environment Situational Awareness Description Mechanisms exist to provide role-based security, compliance and resilience awareness training that is current and relevant to the cyber threats that users might encounter in day-to-day business operations. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ US-CERT mailing lists & feeds ∙ Internal newsletters Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ US-CERT mailing lists & feeds ∙ Internal newsletters Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ US-CERT mailing lists & feeds ∙ Internal newsletters ∙ InfraGard (https://infragard.org) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ US-CERT mailing lists & feeds ∙ Internal newsletters ∙ InfraGard (https://infragard.org) Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ US-CERT mailing lists & feeds ∙ Internal newsletters ∙ InfraGard (https://infragard.org) 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 Security Awareness & Training (SAT) 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 SAT domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with SAT 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 SAT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Security Awareness & Training-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Security Awareness & Training may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Users are educated on their responsibilities to protect TAASD assigned to them or under their supervision. ▪ IT and/or cybersecurity personnel create/govern security and awareness training to meet specific statutory, regulatory and/or contractual compliance obligations. ▪ Privileged users receive formal security and/or data privacy awareness training to ensure they understand their unique roles and responsibilities. ▪ The responsibility for training users and enforcing policies may be assigned to user's immediate supervisor(s)/manager(s), including the definition and enforcement of the user's specific role(s) and responsibilities. ▪ Security awareness and training methods are role-based (e.g., handling sensitive/regulated data). ▪ Business process owners are required to incorporate vendor-specific security training in support of new technology initiatives. ▪ Security awareness training covers recommended practices for securing laptops and mobile devices while traveling. ▪ Security awareness training covers reporting of unauthorized alterations and evidence of tampering of equipment Level 3 Well Defined Security Awareness & Training (SAT) 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 SAT 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 SAT domain capabilities are well-documented and kept current by process owners. ▪ A security awareness & training team, or similar function, is appropriately staffed and supported to implement and maintain SAT domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of security awareness and training management (e.g., Computer Based Learning (CBL) solutions). ▪ 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 SAT 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 provide role-based security, compliance and resilience awareness training that is current and relevant to the cyber threats that users might encounter in day-to-day business operations. 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	Technology Development & Acquisition Description Mechanisms exist to facilitate the implementation of tailored development and acquisition strategies, contract tools and procurement methods to meet unique business needs. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160) ∙ Defined business processes ∙ Product / project management ∙ Defined technical requirements ∙ Defined business requirements Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160) ∙ Defined business processes ∙ Product / project management ∙ Defined technical requirements ∙ Defined business requirements Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160) ∙ Defined business processes ∙ Product / project management ∙ Defined technical requirements ∙ Defined business requirements ∙ System Development Lifecycle (SDLC) governance / oversight Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160) ∙ Defined business processes ∙ Product / project management ∙ Defined technical requirements ∙ Defined business requirements ∙ System Development Lifecycle (SDLC) governance / oversight Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160) ∙ Defined business processes ∙ Product / project management ∙ Defined technical requirements ∙ Defined business requirements ∙ System Development Lifecycle (SDLC) governance / oversight 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 Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Technology development & acquisition-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218 and NIST SP 800-160). 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. ▪ Development and acquisition management is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. 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 facilitate the implementation of tailored development and acquisition strategies, contract tools and procurement methods to meet unique business needs. 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	Product Management Description Mechanisms exist to design and implement product management processes to proactively govern the design, development and production of Technology Assets, Applications and/or Services (TAAS) across the System Development Life Cycle (SDLC) to: (1) Improve functionality; (2) Enhance security and resiliency capabilities; (3) Correct security deficiencies; and (4) Conform with applicable statutory, regulatory and/or contractual obligations. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Defined business processes ∙ Product / project management ∙ Defined technical requirements ∙ Defined business requirements Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Defined business processes ∙ Product / project management ∙ Defined technical requirements ∙ Defined business requirements Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Defined business processes ∙ Product / project management ∙ Defined technical requirements ∙ Defined business requirements ∙ System Development Lifecycle (SDLC) governance / oversight Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Defined business processes ∙ Product / project management ∙ Defined technical requirements ∙ Defined business requirements ∙ System Development Lifecycle (SDLC) governance / oversight Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Defined business processes ∙ Product / project management ∙ Defined technical requirements ∙ Defined business requirements ∙ System Development Lifecycle (SDLC) governance / oversight 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 Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Technology development & acquisition-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218 and NIST SP 800-160). ▪ IT and/or cybersecurity personnel use an informal process to govern changes to the software library to prevent unauthorized changes and create an audit trail of changes made. 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. ▪ Development and acquisition management is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. 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 design and implement product management processes to proactively govern the design, development and production of Technology Assets, Applications and/or Services (TAAS) across the System Development Life Cycle (SDLC) to: (1) Improve functionality; (2) Enhance security and resiliency capabilities; (3) Correct security deficiencies; and (4) Conform with applicable statutory, regulatory and/or contractual obligations. Level 4 Quantitatively Controlled Technology Development & Acquisition (TDA) 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	Threat Intelligence Program Description Mechanisms exist to implement a threat intelligence program that includes a cross-organization information-sharing capability that can influence the development of the system and security architectures, selection of security solutions, monitoring, threat hunting, response and recovery activities. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Subscribe to free threat intelligence feeds (e.g., CISA alerts) Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ CISA alerts subscription ∙ Basic threat awareness program Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Threat intelligence program Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Threat intelligence program Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Threat intelligence program 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 Threat Management (THR) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with THR domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Threat management-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 subscribe to threat feeds to maintain situational awareness of emerging threats. Level 2 Planned Tracked Threat Management (THR) 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 THR domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with THR 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Threat management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. Level 3 Well Defined Threat Management (THR) 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 THR 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 THR domain capabilities are well-documented and kept current by process owners. ▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution and bug bounty solution). ▪ 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 THR 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 implement a threat intelligence program that includes a cross-organization information-sharing capability that can influence the development of the system and security architectures, selection of security solutions, monitoring, threat hunting, response and recovery activities. Level 4 Quantitatively Controlled Threat Management (THR) 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	Threat Intelligence Feeds Description Mechanisms exist to maintain situational awareness of vulnerabilities and evolving threats by leveraging the knowledge of attacker tactics, techniques and procedures to facilitate the implementation of preventative and compensating controls. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ US-CERT mailing lists & feeds ∙ Internal newsletters Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ US-CERT mailing lists & feeds ∙ Internal newsletters Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ US-CERT mailing lists & feeds ∙ Internal newsletters ∙ InfraGard (https://infragard.org) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ US-CERT mailing lists & feeds ∙ Internal newsletters ∙ InfraGard (https://infragard.org) Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ US-CERT mailing lists & feeds ∙ Internal newsletters ∙ InfraGard (https://infragard.org) 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 Threat Management (THR) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with THR domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Threat management-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 subscribe to threat feeds to maintain situational awareness of emerging threats. Level 2 Planned Tracked Threat Management (THR) 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 THR domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with THR 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 THR domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Threat management-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Threat 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 in supervisory positions subscribe to news feeds from groups and associations to facilitate ongoing education and training. Level 3 Well Defined Threat Management (THR) 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 THR 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 THR domain capabilities are well-documented and kept current by process owners. ▪ A threat management team, or similar function, is appropriately staffed and supported to implement and maintain THR domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of threat management operations (e.g., threat intelligence solution and bug bounty solution). ▪ 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 THR 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 maintain situational awareness of vulnerabilities and evolving threats by leveraging the knowledge of attacker tactics, techniques and procedures to facilitate the implementation of preventative and compensating controls. Level 4 Quantitatively Controlled Threat Management (THR) 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.

Builddate: 27.12.2022 00:00:00 -Doknr: CELEX:32022R2554
EULAW -
European Regulation published on http://eur-lex.europa.eu/

Article 13 Apprentissage et évolution

1. Vue d’ensemble

1.1 Références

1.2 Exigences identifiées

1.3 Normes associées

2. Exigences identifiées

3. Normes associées

Description

Possible Solutions & Considerations

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

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

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

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

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

SCR-CMM

Level 0 Not Performed

Level 1 Performed Informally

Level 2 Planned Tracked

Level 3 Well Defined

Level 4 Quantitatively Controlled

Level 5 Continuously Improving

Description

Possible Solutions & Considerations

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

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

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

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

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

SCR-CMM

Level 0 Not Performed

Level 1 Performed Informally

Level 2 Planned Tracked

Level 3 Well Defined

Level 4 Quantitatively Controlled

Level 5 Continuously Improving

Description

Possible Solutions & Considerations

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

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

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

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

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

SCR-CMM

Level 0 Not Performed

Level 1 Performed Informally

Level 2 Planned Tracked

Level 3 Well Defined

Level 4 Quantitatively Controlled

Level 5 Continuously Improving

Description

Possible Solutions & Considerations

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

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

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

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

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

SCR-CMM

Level 0 Not Performed

Level 1 Performed Informally

Level 2 Planned Tracked

Level 3 Well Defined

Level 4 Quantitatively Controlled

Level 5 Continuously Improving

Description

Possible Solutions & Considerations

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

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

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

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

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

SCR-CMM

Level 0 Not Performed

Level 1 Performed Informally

Level 2 Planned Tracked

Level 3 Well Defined

Level 4 Quantitatively Controlled

Level 5 Continuously Improving

Description

Possible Solutions & Considerations

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