DORA Ch. II Sec. II Art. 9 4.

NOREA

Critical and Important Functions
Identify, classify and adequately document all critical and important functions. This process involves determining which functions are essential for the entity's operational stability and continuity. Review as needed, and at least yearly, the adequacy of this classification.

NOREA

Network Design and Segmentation
Design the network infrastructure in a way that allows it to be instantaneously severed or segmented to minimize and prevent contagion. Have provisions for temporarily isolating subnetworks and network components/devices. Ensure redundant capabilities are equipped with sufficient resources, capabilities, and functions (e.g., redundant network setup). Systems and networks must be segregated based on function criticality, classification, and overall risk profile. Maintain a separate network for asset administration. Provide a Layer 3 or 7 (L3/L7) visual representation of all networks and data flows. Conduct yearly performance reviews of the network architecture/design.

NOREA

Network Security

Implement controls to prevent and detect unauthorized network connections. Establish and maintain a secure configuration baseline for all network components, following vendor instructions, industry standards, and best practices. Ensure Confidentiality, Integrity, and Availability (CIA) of data during network transmission. Prevent and detect data leakage, and secure data transfer with external parties. Implement measures to secure network traffic between internal networks and the internet/external connections. Apply encryption for all communication protocols over corporate, public, domestic, thirdparty, and wireless networks, based on data classification and risk assessments.

Regularly review roles and responsibilities for defining, implementing, approving, changing, and reviewing firewall rules and connection filters.

Financial entities shall perform the review of firewall rules and connections filters on a regular basis according to the classification and overall risk profile of ICT systems involved. For the ICT systems supporting critical or important functions, the financial entities shall verify the adequacy of the existing firewall rules and connection filters at least every six months.

NOREA

Session Management
Enforce procedures to limit, lock, and terminate system and remote sessions after a predefined period of inactivity.

NOREA

Clear Segregation of Duties (SoD)
Establish Segregation of Duties (SoD) with regard to risk management functions, following the three lines of defence model or internal risk management and control model.

NOREA

ICT Risk management framework

A sound, comprehensive and well-documented ICT risk management framework is in place. Which as goal to address all ICT risks properly and ensure a high level of digital resilience. The reponsibility for risk management is properly assigned to a control function.

The ICT risk management framework shall be documented and reviewed at least annually, or periodically for microenterprises, with immediate reviews triggered by major ICT-related incidents or supervisory feedback. Continuous improvement will be ensured by incorporating lessons learned from implementation, monitoring, and audits. The report of the review will be prepared according to the requirements as stated in chapter 5 (Article 27) of the RTS RM and will be made available for submission to the competent authority upon request.

Assess new standards and relevant technology developments in the field of information security, cybersecurity and resilience on a continuous basis and make proposals on how they can strengthen the information security and cybersecurity control measures of the institution.

NOREA

Annual Framework Review and Audit Process

The effectiveness of the risk management framework is monitored based on the risk exposure over time to critical or important business functions. Implement a reviewing and auditing process, with a minimum yearly review of the framework, triggered by major ICT incidents, regulator instructions, or major audit findings.

The tasks of verifying compliance with ICT risk management requirements may be outsourced to intra-group or external undertakings. In case of such outsourcing, the financial entity remains fully responsible for the verification of compliance with the ICT risk management requirements.

NOREA

Third-Party (Multi-vendor) Risk Management Program

Maintain a comprehensive third-party risk management program which includes:

A register of information related to the use of thirdparty service providers, especially those supporting critical or important functions (see also control 17.3).
Put in place a policy on the management of ICT third-parties, including the criteria for determining the criticality of service providers and the internal responsibilities for managing third-parties.
Ensuring that senior management reviews the policy and designate a member to monitor relations with the third-parties and the contractual arrangements.
A (holistic) multi-vendor strategy, if deemed relevant, showing key dependencies on ICT third-party service providers and explaining the rationale behind the procurement mix of ICT third-party service providers.

NOREA

Protection Measures

Implement policies and procedures to protect all information, ICT assets, and relevant physical ICT components and infrastructures. At least the following policies shall be established and maintained.

Security policy
Human resources policy
Encryption and cryptographic control policy
Identity and access management (IAM) policy
Change management policy
Network security policy
ICT operating policies and procedures
(Crisis) Communication policy
Vulnerability and patch management policy
Back up policy
Project management policy
Physical and environmental security policy
Business continuity policy with response and recovery plans (including testing plans), see control1.4 *
ICT third-party service providers management policy, see control 1.1. *
Operations of ICT assets (ensuring network security, protect against intrusions and data misuse and defining how the entity operates, monitors, controls, and restores ICT assets, including the documentation of ICT operations).

* must be approved by the Management body

SCF

Security, Compliance & Resilience Program (SCRP)

Description

Mechanisms exist to facilitate the implementation of security, compliance and resilience governance controls.

Possible Solutions & Considerations

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

∙ ComplianceForge - Cybersecurity & Data Protection Program (CDPP) (https://complianceforge.com)
∙ SCFConnect (https://scfconnect.com)
∙ NIST Cybersecurity Framework (CSF) 2.0 (https://www.nist.gov/cyberframework)

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

∙ ComplianceForge - Cybersecurity & Data Protection Program (CDPP) (https://complianceforge.com)
∙ SCFConnect (https://scfconnect.com)
∙ NIST Cybersecurity Framework (CSF) 2.0 (https://www.nist.gov/cyberframework)

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

∙ Steering committee
∙ ComplianceForge - Security, Compliance & Resilience Program (SCRP) (https://complianceforge.com)
∙ ComplianceForge - Cybersecurity & Data Protection Program (CDPP) (https://complianceforge.com)
∙ GRC platform (e.g., OneTrust, ServiceNow GRC, LogicGate)
∙ Secure Controls Framework (SCF), NIST SP 800-53 Rev 5 and/or ISO 27001:2022 alignment

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

∙ Steering committee
∙ ComplianceForge - Security, Compliance & Resilience Program (SCRP) (https://complianceforge.com)
∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)
∙ Secure Controls Framework (SCF), NIST SP 800-53 Rev 5 and/or ISO 27001:2022 alignment

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

∙ Steering committee
∙ ComplianceForge - Security, Compliance & Resilience Program (SCRP) (https://complianceforge.com)
∙ Enterprise GRC platform (e.g., Cyturus, Archer, MetricStream, ServiceNow IRM)
∙ Secure Controls Framework (SCF), NIST SP 800-53 Rev 5 and/or ISO 27001:2022 alignment

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

Cybersecurity & Data Protection Governance (GOV) capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.
▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.
▪ Basic procedures are established for important tasks, but are ad hoc and not formally documented.
▪ The responsibility for developing and operating cybersecurity and data privacy procedures are up to the business process owner(s) to determine, including the definition and enforcement of roles and responsibilities.
▪ Governance documentation is made available to internal personnel (e.g., policies, standards, procedures, etc.).
▪ IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.

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, procedures & guidelines).
▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.
▪ IT and/or cybersecurity personnel ensure cybersecurity policies and standards are aligned with a leading cybersecurity framework (e.g., SCF, NIST 800-53, NIST 800-171, ISO 27002 or NIST Cybersecurity Framework).
▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to implement and manage the organization's internal control system.
▪ Legal representation is consulted on an as-needed basis.

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 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 facilitate the implementation of security, compliance and resilience governance controls.

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

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

Publishing Security, Compliance & Resilience Documentation

Description

Mechanisms exist to establish, maintain and disseminate policies, standards and procedures necessary for secure, compliant and resilient capabilities.

Possible Solutions & Considerations

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

∙ ComplianceForge - Cybersecurity & Data Protection Program (CDPP) (https://complianceforge.com)
∙ SCFConnect (https://scfconnect.com)
∙ Shared drive or intranet for policy distribution (e.g., Google Drive, SharePoint Online)

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

∙ ComplianceForge - Cybersecurity & Data Protection Program (CDPP) (https://complianceforge.com)
∙ SCFConnect (https://scfconnect.com)
∙ Document management system (e.g., SharePoint, Confluence, Notion)

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

∙ ComplianceForge - Security, Compliance & Resilience Program (SCRP) (https://complianceforge.com)
∙ ComplianceForge - Cybersecurity & Data Protection Program (CDPP) (https://complianceforge.com)
∙ Document management / intranet portal (e.g., SharePoint, Confluence)
∙ Policy acknowledgement tracking (e.g., KnowBe4, Absorb LMS)

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

∙ ComplianceForge - Security, Compliance & Resilience Program (SCRP) (https://complianceforge.com)
∙ Policy management platform
∙ Version-controlled policy repository with access controls
∙ Automated policy attestation and acknowledgement tracking

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

∙ ComplianceForge - Security, Compliance & Resilience Program (SCRP) (https://complianceforge.com)
∙ Enterprise policy management platform
∙ Integrated GRC policy module with automated review workflows
∙ Enterprise-wide policy acknowledgement and training integration

SCR-CMM

Level 0 Not Performed

Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed.

Level 1 Performed Informally

Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.
▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.
▪ Basic procedures are established for important tasks, but are ad hoc and not formally documented.
▪ No formal cybersecurity and/or data protection principles are identified for the organization.
▪ Informal recommendations are leveraged to update existing policies and standards.
▪ The responsibility for developing and operating cybersecurity and data privacy procedures are up to the business process owner(s) to determine, including the definition and enforcement of roles and responsibilities.
▪ Governance documentation is made available to internal personnel (e.g., policies, standards, procedures, etc.).
▪ People affected by documentation changes are provided notification of the policy and standard changes.

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, procedures & guidelines).
▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.
▪ IT and/or cybersecurity personnel ensure cybersecurity policies and standards are aligned with a leading cybersecurity framework (e.g., SCF, NIST 800-53, NIST 800-171, ISO 27002 or NIST Cybersecurity Framework).
▪ The organization's cybersecurity policies and standards are made available to internal personnel.
▪ Documented procedures exist for requesting a deviation from approved standards.
▪ The responsibility for enforcing cybersecurity and data protection control implementation is assigned to business / process owners and asset custodians.

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 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 establish, maintain and disseminate policies, standards and procedures necessary for secure, compliant and resilient capabilities.

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

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

Change Management Program

Description

Mechanisms exist to facilitate the implementation of a change management program.

Possible Solutions & Considerations

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

∙ VisibleOps (https://itpi.org)
∙ ITIL 4 (https://axelos.com)

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

∙ VisibleOps (https://itpi.org)
∙ ITIL 4 (https://axelos.com)

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

∙ VisibleOps (https://itpi.org)
∙ ITIL 4 (https://axelos.com)

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

∙ VisibleOps (https://itpi.org)
∙ ITIL 4 (https://axelos.com)

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

∙ VisibleOps (https://itpi.org)
∙ ITIL 4 (https://axelos.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

Change Management (CHG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with CHG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Change management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ Documented change control processes are either informal or do not exist.

Level 2 Planned Tracked

Change Management (CHG) 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 CHG domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with CHG 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).
▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.
▪ A Change Advisory Board (CAB), or similar function, exists to govern Requests For Change (RFC) to TAAS to ensure security, compliance and resilience.
▪ The CAB includes a function to review RFCs for cybersecurity and data protection ramifications.
▪ The CAB notifies affected stakeholders to ensure awareness of the impact of proposed changes.

Level 3 Well Defined

Change Management (CHG) 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 CHG 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 CHG domain capabilities are well-documented and kept current by process owners.
▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.
▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.
▪ 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 CHG 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 a change management program.

Level 4 Quantitatively Controlled

Change Management (CHG) 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

Configuration Change Control

Description

Mechanisms exist to govern the technical configuration change control processes.

Possible Solutions & Considerations

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

∙ Change Control Board (CCB)
∙ Configuration Management Database (CMDB)
∙ VisibleOps (https://itpi.org)
∙ ITIL 4 (https://axelos.com)

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

∙ Change Control Board (CCB)
∙ Configuration Management Database (CMDB)
∙ VisibleOps (https://itpi.org)
∙ ITIL 4 (https://axelos.com)

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

∙ Change Control Board (CCB)
∙ Configuration Management Database (CMDB)
∙ VisibleOps (https://itpi.org)
∙ ITIL 4 (https://axelos.com)

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

∙ Change Control Board (CCB)
∙ Configuration Management Database (CMDB)
∙ VisibleOps (https://itpi.org)
∙ ITIL 4 (https://axelos.com)

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

∙ Change Control Board (CCB)
∙ Configuration Management Database (CMDB)
∙ VisibleOps (https://itpi.org)
∙ ITIL 4 (https://axelos.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

Change Management (CHG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with CHG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Change management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ Requests for Change (RFC) are submitted to IT and/or cybersecurity personnel.
▪ Documented change control processes are either informal or do not exist.

Level 2 Planned Tracked

Change Management (CHG) 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 CHG domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with CHG 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 CHG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Change management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).
▪ Change management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ Business stakeholders and process owners ensure changes to Technology Assets, Applications and/or Services (TAAS) within the System Development Lifecycle (SDLC) are controlled through formal change control procedures.
▪ Configuration management practices prevent unauthorized changes by limiting and reviewing permissions to modify TAAS components within a production/operational environment
▪ A Change Advisory Board (CAB), or similar function, exists to govern Requests For Change (RFC) to TAAS to ensure security, compliance and resilience.
▪ The CAB includes a function to review RFCs for cybersecurity and data protection ramifications.
▪ The CAB notifies affected stakeholders to ensure awareness of the impact of proposed changes.
▪ Unauthorized configuration changes are responded to in accordance with an Incident Response Plan (IRP) to determine if the unauthorized configuration is malicious in nature.

Level 3 Well Defined

Change Management (CHG) 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 CHG 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 CHG domain capabilities are well-documented and kept current by process owners.
▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain CHG domain capabilities.
▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities (e.g., Change Advisory Board (CAB)) to ensure successful, efficient and secure change management operations.
▪ 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 CHG 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 govern the technical configuration change control processes.

Level 4 Quantitatively Controlled

Change Management (CHG) 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

Identity & Access Management (IAM)

Description

Mechanisms exist to facilitate the implementation of identification and access management controls.

Possible Solutions & Considerations

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

∙ Strong password policy
∙ MFA for key accounts

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

∙ Password manager
∙ MFA on all accounts
∙ Identity policy

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

∙ Identity & Access Management (IAM) program

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

∙ Identity & Access Management (IAM) program

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

∙ Identity & Access Management (IAM) 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

Identification & Authentication (IAC) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with IAC domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Identity & Access Management (IAM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ IAM controls are primarily administrative in nature (e.g., policies & standards) to manage accounts and permissions.
▪ IT and/or cybersecurity personnel identify and implement IAM cybersecurity and data protection controls that are appropriate to address applicable statutory, regulatory and contractual requirements.
▪ Active Directory (AD), or a similar technologies, are used to centrally manage identities and permissions, but asset/process owners are authorized to operate a decentralized access control program for their specific Technology Assets, Applications, Services and/or Data (TAASD).

Level 2 Planned Tracked

Identification & Authentication (IAC) 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 IAC domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with IAC 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).
▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.
▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.
▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.
▪ IAM restricts the assignment of privileged accounts to entity-defined personnel and/or roles (privilege assignment requires management approval).

Level 3 Well Defined

Identification & Authentication (IAC) 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 IAC 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 IAC domain capabilities are well-documented and kept current by process owners.
▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).
▪ 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 IAC 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 identification and access management controls.

Level 4 Quantitatively Controlled

Identification & Authentication (IAC) 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

Least Privilege

Description

Mechanisms exist to utilize the concept of least privilege, allowing only authorized access to processes necessary to accomplish assigned tasks in accordance with organizational business functions.

Possible Solutions & Considerations

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

∙ Role Based Access Control (RBAC)

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

∙ Role Based Access Control (RBAC)

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

∙ Role Based Access Control (RBAC)

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

∙ Role Based Access Control (RBAC)

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

∙ Role Based Access Control (RBAC)

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

Identification & Authentication (IAC) 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 IAC domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with IAC 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 IAC domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Identity & Access Management (IAM)-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines) to enforce Logical Access Control (LAC).
▪ IAM may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel to implement Role Based Access Control (RBAC) practices for the management of user, group and system accounts, including privileged accounts.
▪ A directory services technology is used to centrally manage identities and permissions with RBAC. Due to technical or business limitations, asset/process owners are empowered to operate a decentralized access control program for their specific Technology Assets, Applications and/or Services (TAAS) that cannot be integrated into directory services.
▪ Configuration management and IAM functions collaborate to ensure Secure Baseline Configurations (SBC) enforce “least privileges” on TAAS.

Level 3 Well Defined

Identification & Authentication (IAC) 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 IAC 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 IAC domain capabilities are well-documented and kept current by process owners.
▪ An Identity & Access Management (IAM) team, or similar function, is appropriately staffed and supported to implement and maintain IAC domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of IAM operations (e.g., directory services, Authenticate, Authorize and Audit (AAA) solution, etc.).
▪ 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 IAC 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 utilize the concept of least privilege, allowing only authorized access to processes necessary to accomplish assigned tasks in accordance with organizational business functions.

Level 4 Quantitatively Controlled

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

Level 5 Continuously Improving

Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:
▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control.
▪ Level 5 capabilities should be considered “world-class” where the control builds on Level 4 capabilities, but are continuously improving through Artificial Intelligence (AI) and/or Machine Learning (ML) technologies.
▪ While it may be possible to develop responsive capabilities for this control through the use of AI and/or ML technologies, the criteria would be organization-specific to define.

SCF

Incident Response Operations

Description

Mechanisms exist to implement and govern processes and documentation to facilitate an organization-wide response capability for cybersecurity and data protection-related incidents.

Possible Solutions & Considerations

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

∙ Incident Response Plan (IRP)

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

∙ Incident Response Plan (IRP)

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

∙ Integrated Incident Response Program (IIRP)

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

∙ Integrated Incident Response Program (IIRP)

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

∙ Integrated Incident Response Program (IIRP)

SCR-CMM

Level 0 Not Performed

Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed.

Level 1 Performed Informally

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

Level 2 Planned Tracked

Incident Response (IRO) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with DCH domain capabilities are documented and maintained by process owners.
▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with IRO domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Incident response-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).
▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.
▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.

Level 3 Well Defined

Incident Response (IRO) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with IRO domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.
▪ An incident response team, or similar function, is appropriately staffed and supported to implement and maintain IRO domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of incident response operations (e.g., incident management software, etc.).
▪ 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 implement and govern processes and documentation to facilitate an organization-wide response capability for cybersecurity and data protection-related incidents.

Level 4 Quantitatively Controlled

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

Level 5 Continuously Improving

Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:
▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control.
▪ Level 5 capabilities should be considered “world-class” where the control builds on Level 4 capabilities, but are continuously improving through Artificial Intelligence (AI) and/or Machine Learning (ML) technologies.
▪ While it may be possible to develop responsive capabilities for this control through the use of AI and/or ML technologies, the criteria would be organization-specific to define.

SCF

Incident Handling

Description

Mechanisms exist to cover:
(1) Preparation;
(2) Automated event detection or manual incident report intake;
(3) Analysis;
(4) Containment;
(5) Eradication; and
(6) Recovery.

Possible Solutions & Considerations

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

∙ Incident Response Plan (IRP)

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

∙ Incident Response Plan (IRP)

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

∙ Integrated Incident Response Program (IIRP)
∙ ITIL 4 (https://axelos.com) ∙ Incident and problem management

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

∙ Integrated Incident Response Program (IIRP)
∙ ITIL 4 (https://axelos.com) ∙ Incident and problem management

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

∙ Integrated Incident Response Program (IIRP)
∙ ITIL 4 (https://axelos.com) ∙ Incident and problem management

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, procedures & guidelines).
▪ Incident response management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ IT and/or cybersecurity personnel operate an incident response capability using a documented and tested Incident Response Plan (IRP) to facilitate incident management operations that cover preparation, detection and analysis, containment, eradication and recovery.
▪ IT and/or cybersecurity personnel facilitate prompt response to suspected or confirmed security incidents, including timely notification to affected stakeholders.
▪ IT and/or cybersecurity personnel operate facilitate basic forensic investigations in the event of a suspected or confirmed security incident.
▪ The IRP contains eDiscovery processes to support Federal Rules of Civil Procedure (FRCP) requirements for eDiscovery practices.
▪ IT personnel support incident response operations by provisioning and deprovisioning incident responders with temporary emergency accounts.

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, etc.).
▪ 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 cover:
(1) Preparation;
(2) Automated event detection or manual incident report intake;
(3) Analysis;
(4) Containment;
(5) Eradication; and
(6) Recovery.

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

Automated Incident Handling Processes

Description

Automated mechanisms exist to support the incident handling process.

Possible Solutions & Considerations

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

∙ Basic incident response plan
∙ Designate incident response contact

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

∙ Documented incident response plan
∙ Incident log
∙ Designated IR team

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

∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak)

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

∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak)

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

∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak)

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

SCR-CMM Level 2 criteria definitions are not available for this control:
▪ A reasonable person would conclude a well-defined and standardized process is required.
▪ At this level of maturity, the “requirements-driven” nature of performing the control is focused on a localized and/or regionalized implementation, not uniform and consistent across the organization.
▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).

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, etc.).
▪ 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 automatically support the incident handling process.

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

Automatic Disabling of Technology Assets, Applications and/or Services (TAAS)

Description

Mechanisms exist to automatically disable Technology Assets, Applications and/or Services (TAAS), upon detection of a possible incident that meets organizational criteria, which allows for forensic analysis to be performed.

Possible Solutions & Considerations

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

∙ Basic incident response plan
∙ Designate incident response contact

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

∙ Documented incident response plan
∙ Incident log
∙ Designated IR team

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

∙ Formal incident response program
∙ IR playbooks
∙ Tabletop exercises

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

∙ Enterprise incident response program
∙ 24/7 SOC monitoring
∙ SOAR platform

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

∙ Enterprise SOC with SIEM/SOAR (e.g., Splunk SOAR, Palo Alto XSOAR)
∙ IR retainer
∙ Threat hunting

SCR-CMM

Level 0 Not Performed

Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed.

Level 1 Performed Informally

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

Level 2 Planned Tracked

SCR-CMM Level 2 criteria definitions are not available for this control:
▪ A reasonable person would conclude a well-defined and standardized process is required.
▪ At this level of maturity, the “requirements-driven” nature of performing the control is focused on a localized and/or regionalized implementation, not uniform and consistent across the organization.
▪ Requirements are narrowly scoped for applicability and are primarily derived from compliance obligations (e.g., laws, regulations and contracts).

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, etc.).
▪ 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 automatically disable Technology Assets, Applications and/or Services (TAAS), upon detection of a possible incident that meets organizational criteria, which allows for forensic analysis to be performed.

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

Standardized Operating Procedures (SOP)

Description

Mechanisms exist to identify and document Standardized Operating Procedures (SOP), or similar documentation, to enable the proper execution of day-to-day / assigned tasks.

Possible Solutions & Considerations

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

∙ Documented Standardized Operating Procedures (SOP)
∙ ComplianceForge - Cybersecurity Standardized Operating Procedures (CSOP)

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

∙ Documented Standardized Operating Procedures (SOP)
∙ ComplianceForge - Cybersecurity Standardized Operating Procedures (CSOP)

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

∙ Documented Standardized Operating Procedures (SOP)
∙ ComplianceForge - Cybersecurity Standardized Operating Procedures (CSOP)

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

∙ Documented Standardized Operating Procedures (SOP)
∙ ComplianceForge - Cybersecurity Standardized Operating Procedures (CSOP)

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

∙ Documented Standardized Operating Procedures (SOP)
∙ ComplianceForge - Cybersecurity Standardized Operating Procedures (CSOP)

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 Operations (OPS) 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 OPS domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with OPS 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 OPS domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Security operations management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).
▪ Security operations 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 create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the organization's TAASD.

Level 3 Well Defined

Security Operations (OPS) 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 OPS 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 OPS domain capabilities are well-documented and kept current by process owners.
▪ A Security Operations Center (SOC), or similar function, is appropriately staffed and supported to implement and maintain OPS domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of security operations management (e.g., SIEM solution, EDR/XDR tools, etc.).
▪ 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 OPS 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).
▪ Cybersecurity personnel create “run books,” or SOPs, to capture operational knowledge in documentation form for critical business functions and/or for sensitive/regulated obligations.
▪ An implemented and operational capability exists to identify and document Standardized Operating Procedures (SOP), or similar documentation, to enable the proper execution of day-to-day / assigned tasks.

Level 4 Quantitatively Controlled

Security Operations (OPS) 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

Vulnerability & Patch Management Program (VPMP)

Description

Mechanisms exist to facilitate the implementation and monitoring of vulnerability management 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

∙ Vulnerability & Patch Management Program

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

∙ Vulnerability & Patch Management Program

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

∙ Vulnerability & Patch Management 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

Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Attack Surface Management (ASM)-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 apply software patches through an informal process.
▪ Occasional vulnerability scanning is conducted on High Value Assets (HVAs).
▪ Vulnerability scanning services may not be internal competencies and have to be outsourced.
▪ Penetration testing services may not be internal competencies and have to be outsourced.

Level 2 Planned Tracked

Vulnerability & Patch Management (VPM) 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 VPM domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with VPM 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 VPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).
▪ Vulnerability 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 define the breadth and depth of coverage for vulnerability scanning that covers system components scanned and types of vulnerabilities that are checked for.
▪ IT and/or cybersecurity personnel maintain a structured process to apply software patches and other vulnerability remediation efforts.

Level 3 Well Defined

Vulnerability & Patch Management (VPM) 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 VPM 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 VPM domain capabilities are well-documented and kept current by process owners.
▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).
▪ 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 VPM 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 and monitoring of vulnerability management controls.

Level 4 Quantitatively Controlled

Vulnerability & Patch Management (VPM) 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

Software & Firmware Patching

Description

Mechanisms exist to conduct software patching for all deployed Technology Assets, Applications and/or Services (TAAS), including firmware.

Possible Solutions & Considerations

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

∙ ManageEngine Endpoint Central (https://manageengine.com)

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

∙ ManageEngine Endpoint Central (https://manageengine.com)

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

∙ ManageEngine Endpoint Central (https://manageengine.com)

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

∙ ManageEngine Endpoint Central (https://manageengine.com)

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

∙ ManageEngine Endpoint Central (https://manageengine.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

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.
Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Attack Surface Management (ASM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.

Level 2 Planned Tracked

Vulnerability & Patch Management (VPM) 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 VPM domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with VPM 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 VPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).
▪ Vulnerability 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 maintain a structured process to apply software patches and other vulnerability remediation efforts.

Level 3 Well Defined

Vulnerability & Patch Management (VPM) 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 VPM 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 VPM domain capabilities are well-documented and kept current by process owners.
▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).
▪ 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 VPM 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 software patching for all deployed Technology Assets, Applications and/or Services (TAAS), including firmware.

Level 4 Quantitatively Controlled

Vulnerability & Patch Management (VPM) 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

Vulnerability & Patch Management (VPM) 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.

DORA Ch. II Sec. II Art. 9 4.

1. Übersicht

1.1 Referenzen

1.2 Identifizierte Anforderungen

1.3 Related Standards

2. Identifizierte Anforderungen

3. Related Standards

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