+DORA Ch. II Sec. II Art. 9 3.

DORA Ch. II Sec. II Art. 9 3.

3.   In order to achieve the objectives referred to in paragraph 2, financial entities shall use ICT solutions and processes that are appropriate in accordance with Article 4. Those ICT solutions and processes shall:

  • (a) ensure the security of the means of transfer of data;
  • (b) minimise the risk of corruption or loss of data, unauthorised access and technical flaws that may hinder business activity;
  • (c) prevent the lack of availability, the impairment of the authenticity and integrity, the breaches of confidentiality and the loss of data;
  • (d) ensure that data is protected from risks arising from data management, including poor administration, processing-related risks and human error.

1. Übersicht

1.1 Referenzen

1.2 Identifizierte Anforderungen

1.3 Related Standards

2. Identifizierte Anforderungen

Anforderungen

3. Related Standards

Standards
NOREA ICT (Security) Systems, tools, and solutions
Design, procure, and implement security solutions and tooling with the goal to ensure resilience, continuity, and CIA of ICT systems, particularly those supporting critical or important functions.
NOREA Data Protection Practices
Establish a secure configuration baseline for ICT assets, incorporating industry practices and techniques to minimize exposure to cyber threats. Deploy security measures to ensure CIA, prevent data loss and leakage, and protect against malicious codes. Protect data from risks arising from data management, including poor administration, processing risks, and human error. Ensure secure transfer of data and minimize the risk of data corruption or loss, unauthorized access, and technical flaws that may hinder business activity. Implement access restrictions based on data classification schemes. Regularly verify the effective deployment of these baselines.
NOREA Vendor Recommended Security Settings

Consider the security measures and settings recommended by the third-party service provider delivering the ICT service. Implement technical and organisational measures to minimise the risks related to the infrastructure used and managed by the ICT third-party service provider.
NOREA Endpoint Devices
Enforce usage requirements for portable and nonportable endpoint devices. Ensure that only authorized data storage media, systems, and endpoint devices are used to transfer and store data. Implement security measures to ensure that teleworking and the use of private endpoint devices do not adversely impact the overall security of the entity. This includes having a centralized management solution to remotely manage and wipe endpoint devices, security mechanisms that cannot be modified, removed, or bypassed, and the use of removable data storage devices only when the residual ICT risk remains within predefined risk tolerance levels. Enforce security measures to allow only authorized software installation on systems and endpoint devices.
NOREA Secure Data Deletion and Disposal
Establish a process to securely delete data on and offpremises. Establish a process to securely dispose or decommission data storage devices on and offpremises that contain confidential information.
SCF Operationalizing Security, Compliance & Resilience Capabilities

Description

Mechanisms exist to compel data and/or process owners to operationalize security, compliance and resilience practices for each Technology Asset, Application and/or Service (TAAS) under their control.

Possible Solutions & Considerations

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

∙ ComplianceForge - Cybersecurity Standardized Operating Procedures (CSOP) (https://complianceforge.com)

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

∙ ComplianceForge - Cybersecurity Standardized Operating Procedures (CSOP) (https://complianceforge.com)

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

∙ ComplianceForge - Cybersecurity Standardized Operating Procedures (CSOP) (https://complianceforge.com)

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

∙ ComplianceForge - Cybersecurity Standardized Operating Procedures (CSOP) (https://complianceforge.com)

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

∙ ComplianceForge - Cybersecurity Standardized Operating Procedures (CSOP) (https://complianceforge.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.

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

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 compel data and/or process owners to operationalize security, compliance and resilience practices for each Technology Asset, Application and/or Service (TAAS) under their control.

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 Configuration Management Program

Description

Mechanisms exist to facilitate the implementation of configuration management controls.

Possible Solutions & Considerations

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

∙ Configuration Management (CM) program
∙ Change control program

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

∙ Configuration Management (CM) program
∙ Change control program

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

∙ Configuration Management (CM) program
∙ Change control program

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

∙ Configuration Management (CM) program
∙ Change control program

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

∙ Configuration Management (CM) program
∙ Change control 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

Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).

Level 2 Planned Tracked

Configuration Management (CFG) 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 CFG domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with CFG 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).
▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).

Level 3 Well Defined

Configuration Management (CFG) 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 CFG 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 CFG domain capabilities are well-documented and kept current by process owners.
▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).
▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with CFG 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 configuration management controls.

Level 4 Quantitatively Controlled

Configuration Management (CFG) 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

Configuration Management (CFG) 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.
SCF Secure Baseline Configurations

Description

Mechanisms exist to develop, document and maintain secure baseline configurations for Technology Assets, Applications and/or Services (TAAS) that are consistent with industry-accepted system hardening standards.

Possible Solutions & Considerations

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

∙ Secure Baseline Configurations (SBC)
∙ Defense Information Security Agency (DISA) Secure Technology Implementation Guides (STIGs)
∙ Center for Internet Security (CIS) Benchmarks
∙ Original Equipment Manufacturer (OEM) security guides

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

∙ Secure Baseline Configurations (SBC)
∙ Defense Information Security Agency (DISA) Secure Technology Implementation Guides (STIGs)
∙ Center for Internet Security (CIS) Benchmarks
∙ Original Equipment Manufacturer (OEM) security guides

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

∙ Secure Baseline Configurations (SBC)
∙ Defense Information Security Agency (DISA) Secure Technology Implementation Guides (STIGs)
∙ Center for Internet Security (CIS) Benchmarks
∙ Original Equipment Manufacturer (OEM) security guides
∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak)
∙ Netwrix Auditor (https://netrix.com)

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

∙ Secure Baseline Configurations (SBC)
∙ Defense Information Security Agency (DISA) Secure Technology Implementation Guides (STIGs)
∙ Center for Internet Security (CIS) Benchmarks
∙ Original Equipment Manufacturer (OEM) security guides
∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak)
∙ Netwrix Auditor (https://netrix.com)

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

∙ Secure Baseline Configurations (SBC)
∙ Defense Information Security Agency (DISA) Secure Technology Implementation Guides (STIGs)
∙ Center for Internet Security (CIS) Benchmarks
∙ Original Equipment Manufacturer (OEM) security guides
∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak)
∙ Netwrix Auditor (https://netrix.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

Configuration Management (CFG) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with CFG domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Configuration management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ Configurations mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).

Level 2 Planned Tracked

Configuration Management (CFG) 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 CFG domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with CFG 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 CFG domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Configuration management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).
▪ Configuration management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ Secure Baseline Configurations (SBC) are used to configure Technology Assets, Applications and/or Services (TAAS) according to the principles of least functionality and least privilege, mostly conforming to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).
▪ The restrictiveness of the SBCs are commensurate with the criticality of the TAAS and/or sensitivity of the data being protected, in accordance with applicable laws, regulations and frameworks.
▪ Tailored SBC are created for higher-risk operating environments and/or for TAAS that store, process or transmit sensitive/regulated data.

Level 3 Well Defined

Configuration Management (CFG) 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 CFG 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 CFG domain capabilities are well-documented and kept current by process owners.
▪ A configuration management team, or similar function, is appropriately staffed and supported to implement and maintain CFG domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of configuration management operations (e.g., Configuration Management Database (CMBD) Asset Management solution).
▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with CFG 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 develop, document and maintain secure baseline configurations for Technology Assets, Applications and/or Services (TAAS) that are consistent with industry-accepted system hardening standards.

Level 4 Quantitatively Controlled

Configuration Management (CFG) 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

Configuration Management (CFG) 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.
SCF Secure Engineering Principles

Description

Mechanisms exist to facilitate the implementation of industry-recognized security, compliance and resilience practices in the specification, design, development, implementation and modification of Technology Assets, Applications and/or Services (TAAS).

Possible Solutions & Considerations

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

∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160)

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

∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160)

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

∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160)

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

∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160)

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

∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160)

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

Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Security engineering-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 design, build and maintain secure, compliant and resilient solutions.

Level 2 Planned Tracked

Secure Engineering & Architecture (SEA) 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 SEA domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with SEA 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).
▪ Secure engineering and architecture 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 entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.
▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.
▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).
▪ IT and/or cybersecurity personnel manage separate development, testing and operational environments to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production TAASD.

Level 3 Well Defined

Secure Engineering & Architecture (SEA) 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 SEA 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 SEA domain capabilities are well-documented and kept current by process owners.
▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management 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 SEA 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).
▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).
▪ An implemented and operational capability exists to facilitate the implementation of industry-recognized security, compliance and resilience practices in the specification, design, development, implementation and modification of TAAS.

Level 4 Quantitatively Controlled

Secure Engineering & Architecture (SEA) 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 Alignment With Enterprise Architecture

Description

Mechanisms exist to develop an enterprise architecture, aligned with industry-recognized leading practices, with consideration for security, compliance and resilience principles that addresses risk to organizational operations, assets, individuals and other organizations.

Possible Solutions & Considerations

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

∙ Follow secure coding basics
∙ Document security decisions

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

∙ Secure design checklist
∙ Basic threat modeling

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

∙ Enterprise architecture committee

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

∙ Enterprise architecture committee

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

∙ Enterprise architecture committee

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

Secure Engineering & Architecture (SEA) 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 SEA domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with SEA 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).
▪ Secure engineering and architecture 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 entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.
▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.
▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).

Level 3 Well Defined

Secure Engineering & Architecture (SEA) 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 SEA 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 SEA domain capabilities are well-documented and kept current by process owners.
▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management 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 SEA 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).
▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).
▪ An implemented and operational capability exists to develop an enterprise architecture, aligned with industry-recognized leading practices, with consideration for security, compliance and resilience principles that addresses risk to organizational operations, assets, individuals and other organizations.

Level 4 Quantitatively Controlled

Secure Engineering & Architecture (SEA) 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 Defense-In-Depth (DiD) Architecture

Description

Mechanisms exist to implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers.

Possible Solutions & Considerations

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

∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
∙ Defense-in-depth (DiD) architecture

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

∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
∙ Defense-in-depth (DiD) architecture

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

∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
∙ Defense-in-depth (DiD) architecture
∙ Enterprise architecture committee

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

∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
∙ Defense-in-depth (DiD) architecture
∙ Enterprise architecture committee

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

∙ Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
∙ Defense-in-depth (DiD) architecture
∙ Enterprise architecture committee

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

Secure Engineering & Architecture (SEA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with SEA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Security engineering-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 design, build and maintain secure, compliant and resilient solutions.

Level 2 Planned Tracked

Secure Engineering & Architecture (SEA) 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 SEA domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with SEA 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 SEA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Secure engineering and architecture-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).
▪ Secure engineering and architecture 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 entity-specific secure engineering practices to protect the Confidentiality, Integrity, Availability and Safety (CIAS) of the entity's TAASD.
▪ IT and/or cybersecurity personnel align secure engineering practices with the entity's broader IT architecture practices.
▪ IT and/or cybersecurity personnel use secure engineering practices to influence Secure Baseline Configurations (SBC).
▪ IT and/or cybersecurity personnel manage separate development, testing and operational environments to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production TAASD.

Level 3 Well Defined

Secure Engineering & Architecture (SEA) 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 SEA 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 SEA domain capabilities are well-documented and kept current by process owners.
▪ A cybersecurity engineering / architecture team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of secure engineering management operations (e.g., project management 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 SEA 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).
▪ Secure Baseline Configurations (SBC) enforce the secure engineering principles on all applicable Technology Assets, Applications and/or Services (TAAS).
▪ An implemented and operational capability exists to implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers.

Level 4 Quantitatively Controlled

Secure Engineering & Architecture (SEA) 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.
Impressum Deutsch Englisch