+Článek 8 Politiky a postupy pro operace IKT
---+Článek 8 1.
---+Článek 8 2.

Článek 8 Politiky a postupy pro operace IKT

1. Přehled

Článek 8 1.

V rámci politik, postupů, protokolů a nástrojů v oblasti bezpečnosti IKT uvedených v čl. 9 odst. 2 nařízení (EU) 2022/2554 finanční subjekty vypracují, zdokumentují a zavedou politiky a postupy pro řízení operací IKT. Tyto politiky a postupy stanoví, jak finanční subjekty provozují, monitorují, kontrolují a obnovují svá aktiva v oblasti IKT, včetně dokumentace operací IKT.

Článek 8 2.

Politiky a postupy pro operace IKT uvedené v odstavci 1 obsahují všechny tyto prvky:

popis aktiv v oblasti IKT, včetně všech následujících údajů:

požadavky na bezpečnou instalaci, údržbu, konfiguraci a deinstalaci systému IKT;

ii)

požadavky týkající se správy informačních aktiv využívaných aktivy v oblasti IKT, včetně jejich zpracování a jejich používání, a to jak automatizovaného, tak manuálního;

iii)

požadavky týkající se identifikace a kontroly původních systémů IKT;

kontroly a monitorování systémů IKT, včetně všech následujících položek:

požadavky na zálohování a obnovu systémů IKT;

ii)

požadavky na časové plánování s ohledem na vzájemné závislosti mezi systémy IKT;

iii)

protokoly pro auditní stopu a informace systémového protokolu;

iv)

požadavky na zajištění toho, aby provádění interního auditu a dalších testů co nejméně narušovalo obchodní činnost;

požadavky na oddělení produkčních prostředí IKT od vývojových, testovacích a jiných neprodukčních prostředí;

vi)

požadavky na provádění vývoje a testování v prostředích, která jsou oddělena od produkčního prostředí;

vii)

požadavky na provádění vývoje a testování v produkčním prostředí;

řešení chyb systémů IKT, včetně všech následujících položek:

postupy a protokoly pro řešení chyb;

ii)

kontakty pro účely podpory a eskalace, včetně kontaktů na externí podporu v případě neočekávaných provozních nebo technických problémů;

iii)

postupy pro restartování, zpětné obnovení („rollback“) a obnovu systému IKT, které se použijí v případě narušení systému IKT.

Pro účely písm. b) bodu v) se oddělení týká všech složek prostředí, včetně účtů, dat nebo spojení, jak požaduje čl. 13 první podostavec písm. a).

Pro účely písmene b) bodu vii) musí politiky a postupy uvedené v odstavci 1 stanovit, že případy, kdy je testování prováděno v produkčním prostředí, jsou jasně stanoveny, odůvodněny, jsou časově omezené a jsou schváleny příslušnou funkcí v souladu s čl. 16 odst. 6. Během vývojových a testovacích činností v produkčním prostředí finanční subjekty zajistí dostupnost, důvěrnost, integritu a hodnověrnost systémů IKT a produkčních dat.

1.1 Odkazy

1.2 Identifikované požadavky

1.3 Související standardy

2. Identifikované požadavky

Požadavky
Zdroj	Požadavek

3. Související standardy

Standardy
Zdroj	Požadavek
SCF	Technical Debt Reviews Description Mechanisms exist to conduct ongoing “technical debt” reviews of hardware and software technologies to remediate outdated and/or unsupported technologies. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Computer Lifecycle Program (CLP) ∙ IT Asset Management (ITAM) program ∙ Risk Management Program (RMP) Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Computer Lifecycle Program (CLP) ∙ IT Asset Management (ITAM) program ∙ Risk Management Program (RMP) Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Computer Lifecycle Program (CLP) ∙ IT Asset Management (ITAM) program ∙ Risk Management Program (RMP) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Computer Lifecycle Program (CLP) ∙ IT Asset Management (ITAM) program ∙ Risk Management Program (RMP) Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Computer Lifecycle Program (CLP) ∙ IT Asset Management (ITAM) program ∙ Risk Management Program (RMP) 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 Asset Management (AST) 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 AST 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 AST domain capabilities are well-documented and kept current by process owners. ▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (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 AST 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 ongoing “technical debt” reviews of hardware and software technologies to remediate outdated and/or unsupported technologies. 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	Unsupported Technology Assets, Applications and/or Services (TAAS) Description Mechanisms exist to prevent unsupported Technology Assets, Applications and/or Services (TAAS) by: (1) Removing and/or replacing TAAS when support for the components is no longer available from the developer, vendor or manufacturer; and (2) Requiring justification and documented approval for the continued use of unsupported TAAS required to satisfy mission/business needs. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program ∙ Product / project management ∙ Computer Lifecycle Program (CLP) ∙ IT Asset Management (ITAM) program ∙ Risk Management Program (RMP) Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program ∙ Product / project management ∙ Computer Lifecycle Program (CLP) ∙ IT Asset Management (ITAM) program ∙ Risk Management Program (RMP) Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program ∙ Product / project management ∙ Computer Lifecycle Program (CLP) ∙ IT Asset Management (ITAM) program ∙ Risk Management Program (RMP) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program ∙ Product / project management ∙ Computer Lifecycle Program (CLP) ∙ IT Asset Management (ITAM) program ∙ Risk Management Program (RMP) Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program ∙ Product / project management ∙ Computer Lifecycle Program (CLP) ∙ IT Asset Management (ITAM) program ∙ Risk Management Program (RMP) SCR-CMM Level 0 Not Performed Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed. Level 1 Performed Informally Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Technology development & acquisition-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218 and NIST SP 800-160). Level 2 Planned Tracked Technology Development & Acquisition (TDA) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with TDA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Technology development and acquisition management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Secure development practices mostly conform to industry-recognized standards for secure engineering of Technology Assets, Applications and/or Services (TAAS) (e.g., OWASP, NIST SP 800-218 and NIST SP 800-160). ▪ An application development team, or similar function, uses a structured process to design, build and maintain secure configurations for test, development, staging and production environments. ▪ An application development team, or similar function, provides in-house support or contract external providers for support with unsupported system components. Level 3 Well Defined Asset Management (AST) 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 AST 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 AST domain capabilities are well-documented and kept current by process owners. ▪ An IT Asset Management (ITAM) team, or similar function, is appropriately staffed and supported to implement and maintain AST domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of ITAM operations (e.g., ITAM platform, (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 AST 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 prevent unsupported Technology Assets, Applications and/or Services (TAAS) by: (1) Removing and/or replacing TAAS when support for the components is no longer available from the developer, vendor or manufacturer; and (2) Requiring justification and documented approval for the continued use of unsupported TAAS required to satisfy mission/business needs. Level 4 Quantitatively Controlled Technology Development & Acquisition (TDA) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs). ▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs). ▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties. ▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review). ▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes. ▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities. Level 5 Continuously Improving Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions: ▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. ▪ Level 5 capabilities should be considered “world-class” where the control builds on Level 4 capabilities, but are continuously improving through Artificial Intelligence (AI) and/or Machine Learning (ML) technologies. ▪ While it may be possible to develop responsive capabilities for this control through the use of AI and/or ML technologies, the criteria would be organization-specific to define.
SCF	Technology Assets, Applications and/or Services (TAAS) Recovery & Reconstitution Description Mechanisms exist to ensure the secure recovery and reconstitution of Technology Assets, Applications and/or Services (TAAS) to a known state after a disruption, compromise or failure. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Virtual machines ∙ Acronis (https://acronis.com) ∙ Documented system recovery runbooks Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Virtual machines ∙ Acronis (https://acronis.com) ∙ Docker (https://docker.com) ∙ Documented system recovery runbooks and checklists Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Virtual machines ∙ Docker (https://docker.com) ∙ Acronis Cyber Backup (https://acronis.com) ∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak) ∙ Documented and tested recovery runbooks Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Enterprise DR platform (e.g., Veeam, Zerto, AWS DRS) ∙ Docker (https://docker.com) ∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak) ∙ Tested recovery runbooks with RTO/RPO validation Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Enterprise recovery and reconstitution platform (e.g., Commvault, Veeam Enterprise, Rubrik) ∙ Automated recovery orchestration (e.g., Zerto, AWS DRS) ∙ IaC-based reconstitution (Terraform, Ansible) ∙ CimTrak Integrity Suite (https://cimcor.com/cimtrak) ∙ Regularly tested recovery with documented evidence 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 Business Continuity & Disaster Recovery (BCD) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. Level 3 Well Defined Business Continuity & Disaster Recovery (BCD) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function. ▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners. ▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with BCD domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls). ▪ An implemented and operational capability exists to ensure the secure recovery and reconstitution of Technology Assets, Applications and/or Services (TAAS) to a known state after a disruption, compromise or failure. Level 4 Quantitatively Controlled Business Continuity & Disaster Recovery (BCD) 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	Data Backups Description Mechanisms exist to create recurring backups of data, software and/or system images, as well as verify the integrity of these backups, to ensure the availability of the data to satisfy Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs). Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Disaster Recovery Plan (DRP) ∙ 3-2-1 backup rule (3 copies, 2 media types, 1 offsite) ∙ Cloud backup service (e.g., Backblaze B2, iDrive, Veeam Agent Free) Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Disaster Recovery Plan (DRP) ∙ 3-2-1 backup strategy (on-site + off-site/cloud) ∙ Cloud backup service (e.g., Acronis, Veeam, Azure Backup) Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Disaster Recovery Plan (DRP) ∙ 3-2-1-1 backup strategy (including immutable/offsite copy) ∙ Enterprise backup solution (e.g., Veeam Backup & Replication, Acronis Cyber Backup) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Disaster Recovery Plan (DRP) ∙ Immutable backup copies (air-gapped or object-locked S3/Azure Blob) ∙ Enterprise backup platform (e.g., Veeam, Commvault, Cohesity) ∙ Automated backup testing and alerting Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Disaster Recovery Plan (DRP) ∙ Enterprise backup platform with immutable storage (e.g., Commvault, Veeam, Rubrik) ∙ Ransomware-resilient backup architecture (air-gap or immutable) ∙ Automated backup validation and recovery testing ∙ Backup data encrypted at rest and in transit SCR-CMM Level 0 Not Performed Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed. Level 1 Performed Informally Business Continuity & Disaster Recovery (BCD) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with BCD domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Contingency management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ Limited technologies exist to support near real-time network infrastructure failover (e.g., redundant ISPs and redundant power). ▪ Backups are performed ad-hoc and focus on business-critical Technology Assets, Applications, Services and/or Data (TAASD). ▪ IT and/or cybersecurity personnel use a backup methodology (e.g., grandfather and father & son rotation) to create backups to support business needs (e.g., Recovery Time Objectives). ▪ Limited technologies exist to conduct full, incremental or differential backups (e.g., tape/disk, hybrid cloud or direct-to-cloud). ▪ Backups of sensitive/regulated data are cryptographically protected to prevent the unauthorized disclosure and modification of backup information. Level 2 Planned Tracked Business Continuity & Disaster Recovery (BCD) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Appropriate TAASD exist to conduct full, incremental and/or differential backups (e.g., tape/disk, hybrid cloud or direct-to-cloud). ▪ IT personnel configure business-critical Technology Assets, Applications and/or Services to transfer backup data to the alternate site(s) at a rate that is capable of meeting RTOs and RPOs. ▪ The backup methodology is sufficient to support RTOs and RPOs for critical business functions. ▪ IT personnel store backups in a secondary location, separate from the primary storage site (e.g., cloud-based storage). Level 3 Well Defined Business Continuity & Disaster Recovery (BCD) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function. ▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners. ▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with BCD domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls). ▪ An implemented and operational capability exists to create recurring backups of data, software and/or system images, as well as verify the integrity of these backups, to ensure the availability of the data to satisfy Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs). Level 4 Quantitatively Controlled Business Continuity & Disaster Recovery (BCD) 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	Audit Planning Activities Description Mechanisms exist to thoughtfully plan audits by including input from operational risk and compliance partners to minimize the impact of audit-related activities on business operations. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Internal audit program Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Internal audit program Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Internal audit program Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Internal audit program Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Internal audit 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 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 Compliance (CPL) 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 CPL domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with CPL 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 CPL domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Compliance management controls-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Compliance management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ External compliance requirements for cybersecurity and data privacy are identified and documented, based on applicable laws, regulations and contractual obligations. Level 3 Well Defined Compliance (CPL) 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 CPL 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 CPL domain capabilities are well-documented and kept current by process owners. ▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain CPL domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform). ▪ 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 CPL 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 thoughtfully plan audits by including input from operational risk and compliance partners to minimize the impact of audit-related activities on business operations. Level 4 Quantitatively Controlled Utilize SCR-CMM Level 3 criteria definitions: ▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control. ▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define. Level 5 Continuously Improving Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions: ▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. ▪ Level 5 capabilities should be considered “world-class” where the control builds on Level 4 capabilities, but are continuously improving through Artificial Intelligence (AI) and/or Machine Learning (ML) technologies. ▪ While it may be possible to develop responsive capabilities for this control through the use of AI and/or ML technologies, the criteria would be organization-specific to define.
SCF	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 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 and 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 via Artificial Intelligence (AI) or Machine Learning (ML) technologies.
SCF	Content of Event Logs Description Mechanisms exist to configure Technology Assets, Applications and/or Services (TAAS) to produce event logs that contain sufficient information to, at a minimum: (1) Establish what type of event occurred; (2) When (date and time) the event occurred; (3) Where the event occurred; (4) The source of the event; (5) The outcome (success or failure) of the event; and (6) The identity of any user/subject associated with the event. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Secure Baseline Configurations (SBC) Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Secure Baseline Configurations (SBC) Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Secure Baseline Configurations (SBC) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Secure Baseline Configurations (SBC) Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Secure Baseline Configurations (SBC) 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 Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred. ▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors. ▪ Generating event logs and the review of those event logs is narrowly-focused to business-critical Technology Assets, Applications, Services and/or Data (TAASD). Level 2 Planned Tracked Continuous Monitoring (MON) 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 MON domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with MON 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Continuous monitoring 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) enforce security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis. ▪ SBC enforce logging to link system access to individual users or service accounts using a non-repudiation capability to protect against an individual falsely denying having performed a particular action. ▪ SBC enforce local security event logging and forward those logs to a centralized log repository to provide an alternate audit capability in the event of a failure in the primary audit capability. Level 3 Well Defined Continuous Monitoring (MON) 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 MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function. ▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs. ▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM)). ▪ 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 MON 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 security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis. ▪ An implemented and operational capability exists to configure Technology Assets, Applications and/or Services (TAAS) to produce event logs that contain sufficient information to, at a minimum: (1) Establish what type of event occurred; (2) When (date and time) the event occurred; (3) Where the event occurred; (4) The source of the event; (5) The outcome (success or failure) of the event; and (6) The identity of any user/subject associated with the event. 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	Event Log & Security-Relevant Telemetry Retention Description Mechanisms exist to retain event logs and security-relevant telemetry for a time period consistent with records retention requirements to provide support for after-the-fact investigations of security incidents and to meet statutory, regulatory and contractual retention requirements. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Managed Security Services Provider (MSSP) ∙ Log retention policy (minimum 90 days online, 1 year archived) ∙ Cloud log storage (e.g., AWS S3, Azure Storage) Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Managed Security Services Provider (MSSP) ∙ Log retention policy (minimum 90 days online, 1 year archived) ∙ Cloud SIEM with configurable retention Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Security Incident Event Manager (SIEM) with defined retention schedules ∙ Managed Security Services Provider (MSSP) ∙ Log archiving to cold storage (e.g., AWS S3 Glacier, Azure Archive) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ SIEM with tiered log retention (hot/warm/cold storage) ∙ Log retention policy aligned to regulatory requirements (e.g., HIPAA 6 yrs, PCI DSS 1 yr) ∙ Managed Security Services Provider (MSSP) Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Enterprise log retention program aligned to all applicable regulations ∙ SIEM with tiered retention (hot/warm/cold storage) ∙ Immutable log archives (e.g., AWS S3 Object Lock, Azure Blob WORM) ∙ Legal hold capability for investigation support 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 Continuous Monitoring (MON) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with MON domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Event monitoring-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ Monitoring is primarily reactive in nature, focused on identifying incidents that occurred. ▪ Event log reviews primarily rely on manual processes to identify anomalous behaviors. Level 2 Planned Tracked Continuous Monitoring (MON) 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 MON domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with MON 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 MON domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Continuous monitoring-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Continuous monitoring may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. Level 3 Well Defined Continuous Monitoring (MON) 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 MON domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function. ▪ Cybersecurity personnel use a structured process via Standardized Operating Procedures (SOP) to review and analyze logs. ▪ A Security Operations Center (SOC) team, or similar function, is appropriately staffed and supported to implement and maintain MON domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of continuous monitoring operations (e.g., Security Incident Event Manager (SIEM)). ▪ 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 MON 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 security event logging to contain sufficient information to establish necessary details of activity and allow for forensics analysis. ▪ An implemented and operational capability exists to retain event logs for a time period consistent with records retention requirements to provide support for after-the-fact investigations of security incidents and to meet statutory, regulatory and contractual retention requirements. 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	Data Protection Description Mechanisms exist to facilitate the implementation of data protection controls. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Logical Access Control (LAC) ∙ Physical Access Control (PAC) Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Logical Access Control (LAC) ∙ Physical Access Control (PAC) Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Logical Access Control (LAC) ∙ Physical Access Control (PAC) ∙ Data governance program Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Logical Access Control (LAC) ∙ Physical Access Control (PAC) ∙ Data governance program ∙ Chief Data Officer (CDO) Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Logical Access Control (LAC) ∙ Physical Access Control (PAC) ∙ Data governance program ∙ Chief Data Officer (CDO) 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 Data Classification & Handling (DCH) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with DCH domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Data management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ A basic data classification process exists to identify categories of sensitive/regulated data for compliance-related protection requirements. ▪ Data protection controls are primarily administrative in nature (e.g., policies & standards) to classify, protect and dispose of systems and data, including storage media. Level 2 Planned Tracked Data Classification & Handling (DCH) 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 DCH 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 DCH domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Data classification and handling-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Data classification and handling management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ A formalized data classification scheme exists to identify categories of data, based on protection requirements from applicable laws, regulations and/or contractual obligations. ▪ TAASD are categorized according to data classification and business criticality. ▪ Data classification and handling criteria govern requirements protect sensitive/regulated regardless of where it is stored, processed and/or transmitted. ▪ The data retention process is manual and IT and/or cybersecurity personnel work with business stakeholders and process owners to manage the process. Level 3 Well Defined Data Classification & Handling (DCH) 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 DCH 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 DCH domain capabilities are well-documented and kept current by process owners. ▪ A Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain DCH domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of data classification and handling operations (e.g., GRC platform). ▪ 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 DCH 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 data protection controls. Level 4 Quantitatively Controlled Data Classification & Handling (DCH) 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	Maintenance Operations Description Mechanisms exist to develop, disseminate, review & update procedures to facilitate the implementation of maintenance controls across the enterprise. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ IT maintenance program Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ IT maintenance program Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ IT maintenance program Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ IT maintenance program Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ IT maintenance 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 Maintenance (MNT) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with MNT domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Maintenance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ Maintenance controls are primarily administrative in nature (e.g., policies & standards) to manage change control processes associated with maintenance operations. ▪ IT and/or cybersecurity personnel use an informal process to implement secure and timely technology asset-specific maintenance operations, including preventative and reactive maintenance operations. Level 2 Planned Tracked Maintenance (MNT) 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 MNT domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with MNT 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 MNT domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Maintenance-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Asset 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 personnel, in conjunction with asset custodians, develop and maintain facilitate localized/regionalized procedures to conduct controlled and timely maintenance activities throughout the lifecycle of the Technology Asset, Application and/or Service (TAAS). ▪ Maintenance operations may be centralized for certain locations (e.g., datacenters) and decentralized for other locations, both in terms of change management and execution. Level 3 Well Defined Maintenance (MNT) 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 MNT 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 MNT domain capabilities (e.g., maintenance pans) are documented and maintained by process owners. ▪ A centralized Change Management Office (CMO), or similar function, is appropriately staffed and supported to implement and maintain MNT domain capabilities. ▪ Technical procedures (e.g., ITIL change enablement) are utilized along with change management governance capabilities to ensure successful, efficient and secure maintenance 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 MNT 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, disseminate, review & update procedures to facilitate the implementation of maintenance controls across the enterprise. Level 4 Quantitatively Controlled Maintenance (MNT) 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	Operations Security Description Mechanisms exist to facilitate the implementation of operational security controls. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Documented Standardized Operating Procedures (SOP) Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Documented Standardized Operating Procedures (SOP) Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Documented Standardized Operating Procedures (SOP) ∙ VisibleOps (https://itpi.org) ∙ ITIL 4 (https://axelos.com) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Documented Standardized Operating Procedures (SOP) ∙ VisibleOps (https://itpi.org) ∙ ITIL 4 (https://axelos.com) ∙ COBIT 2019 Framework (https://isaca.org) Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Documented Standardized Operating Procedures (SOP) ∙ VisibleOps (https://itpi.org) ∙ ITIL 4 (https://axelos.com) ∙ COBIT 2019 Framework (https://isaca.org) SCR-CMM Level 0 Not Performed Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed. Level 1 Performed Informally Security Operations (OPS) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with OPS domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Cybersecurity operations-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ Cybersecurity operations are primarily viewed as additional duties for IT staff. ▪ There is no Security Operations Center (SOC) with 24x7x365 operations coverage. 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 and 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. 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 and EDR/XDR tools). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with 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 facilitate the implementation of operational security controls. 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	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 and 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 and EDR/XDR tools). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with 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	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 and 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 and EDR/XDR tools). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with 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	Error Handling Description Mechanisms exist to handle error conditions by: (1) Identifying potentially security-relevant error conditions; (2) Generating error messages that provide information necessary for corrective actions without revealing sensitive or potentially harmful information in error logs and administrative messages that could be exploited; and (3) Revealing error messages only to authorized personnel. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Generic error messages to users; details logged server-side Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Error handling standard (no stack traces or sensitive data in user-facing errors) Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Error handling requirements in SSDP ∙ Centralized logging of error details with restricted access ∙ DAST checks for information leakage Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Enterprise error handling standard with automated testing ∙ Centralized error logging (SIEM) with role-based access ∙ Security-relevant error alerting Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Enterprise error handling and information leakage prevention standards ∙ Automated DAST/IAST verification ∙ SIEM correlation of security-relevant error conditions SCR-CMM Level 0 Not Performed Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed. Level 1 Performed Informally SCR-CMM Level 1 criteria definitions are not available for this control: ▪ A reasonable person would conclude this control requires a structured process. ▪ At this level of maturity, the "ad hoc" nature of performing a capability informally would indicate the intent of the control is not met due to a lack of consistency and formality. Level 2 Planned Tracked Technology Development & Acquisition (TDA) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with TDA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Technology development and acquisition management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Secure development practices mostly conform to industry-recognized standards for secure engineering of Technology Assets, Applications and/or Services (TAAS) (e.g., OWASP, NIST SP 800-218 and NIST SP 800-160). ▪ An application development team, or similar function, uses a structured process to design, build and maintain secure configurations for test, development, staging and production environments. Level 3 Well Defined Technology Development & Acquisition (TDA) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function. ▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners. ▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution and software testing tools). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with TDA domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls). ▪ An implemented and operational capability exists to handle error conditions by: (1) Identifying potentially security-relevant error conditions; (2) Generating error messages that provide information necessary for corrective actions without revealing sensitive or potentially harmful information in error logs and administrative messages that could be exploited; and (3) Revealing error messages only to authorized personnel. Level 4 Quantitatively Controlled Technology Development & Acquisition (TDA) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs). ▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs). ▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties. ▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review). ▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes. ▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities. Level 5 Continuously Improving Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions: ▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. ▪ Level 5 capabilities should be considered “world-class” where the control builds on Level 4 capabilities, but are continuously improving through Artificial Intelligence (AI) and/or Machine Learning (ML) technologies. ▪ While it may be possible to develop responsive capabilities for this control through the use of AI and/or ML technologies, the criteria would be organization-specific to define.
SCF	Error Handling Description Mechanisms exist to handle error conditions by: (1) Identifying potentially security-relevant error conditions; (2) Generating error messages that provide information necessary for corrective actions without revealing sensitive or potentially harmful information in error logs and administrative messages that could be exploited; and (3) Revealing error messages only to authorized personnel. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Generic error messages to users; details logged server-side Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Error handling standard (no stack traces or sensitive data in user-facing errors) Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Error handling requirements in SSDP ∙ Centralized logging of error details with restricted access ∙ DAST checks for information leakage Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Enterprise error handling standard with automated testing ∙ Centralized error logging (SIEM) with role-based access ∙ Security-relevant error alerting Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Enterprise error handling and information leakage prevention standards ∙ Automated DAST/IAST verification ∙ SIEM correlation of security-relevant error conditions SCR-CMM Level 0 Not Performed Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed. Level 1 Performed Informally SCR-CMM Level 1 criteria definitions are not available for this control: ▪ A reasonable person would conclude this control requires a structured process. ▪ At this level of maturity, the "ad hoc" nature of performing a capability informally would indicate the intent of the control is not met due to a lack of consistency and formality. Level 2 Planned Tracked Technology Development & Acquisition (TDA) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with TDA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Technology development and acquisition management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Secure development practices mostly conform to industry-recognized standards for secure engineering of Technology Assets, Applications and/or Services (TAAS) (e.g., OWASP, NIST SP 800-218 and NIST SP 800-160). ▪ An application development team, or similar function, uses a structured process to design, build and maintain secure configurations for test, development, staging and production environments. Level 3 Well Defined Technology Development & Acquisition (TDA) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function. ▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners. ▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution and software testing tools). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with TDA domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls). ▪ An implemented and operational capability exists to handle error conditions by: (1) Identifying potentially security-relevant error conditions; (2) Generating error messages that provide information necessary for corrective actions without revealing sensitive or potentially harmful information in error logs and administrative messages that could be exploited; and (3) Revealing error messages only to authorized personnel. Level 4 Quantitatively Controlled Technology Development & Acquisition (TDA) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs). ▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs). ▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties. ▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review). ▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes. ▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities. Level 5 Continuously Improving Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions: ▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. ▪ Level 5 capabilities should be considered “world-class” where the control builds on Level 4 capabilities, but are continuously improving through Artificial Intelligence (AI) and/or Machine Learning (ML) technologies. ▪ While it may be possible to develop responsive capabilities for this control through the use of AI and/or ML technologies, the criteria would be organization-specific to define.
SCF	Separation of Development, Testing and Operational Environments Description Mechanisms exist to 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 Technology Assets, Applications and/or Services (TAAS). Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Separate development/test and production environments (e.g., separate cloud accounts or instances) Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Distinct dev, test and production environments ∙ Deployment only through defined promotion process Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Separate dev/test/prod environments with access separation ∙ Change management for promotion to production Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Environment separation enforced by cloud account/subscription boundaries and network segmentation ∙ Release management with approval gates ∙ Separation of Duties (SoD) Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Enterprise environment segregation standards (separate accounts, networks, identities) ∙ Automated promotion pipelines with approvals ∙ SoD enforcement and audit SCR-CMM Level 0 Not Performed Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed. Level 1 Performed Informally SCR-CMM Level 1 criteria definitions are not available for this control: ▪ A reasonable person would conclude this control requires a structured process. ▪ At this level of maturity, the "ad hoc" nature of performing a capability informally would indicate the intent of the control is not met due to a lack of consistency and formality. Level 2 Planned Tracked Technology Development & Acquisition (TDA) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with TDA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Technology development and acquisition management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Secure development practices mostly conform to industry-recognized standards for secure engineering of Technology Assets, Applications and/or Services (TAAS) (e.g., OWASP, NIST SP 800-218 and NIST SP 800-160). ▪ An application development team, or similar function, uses a structured process to design, build and maintain secure configurations for test, development, staging and production environments. Level 3 Well Defined Technology Development & Acquisition (TDA) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function. ▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners. ▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution and software testing tools). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with TDA domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls). ▪ An implemented and operational capability exists to 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 Technology Assets, Applications and/or Services (TAAS). 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	Separation of Development, Testing and Operational Environments Description Mechanisms exist to 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 Technology Assets, Applications and/or Services (TAAS). Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Separate development/test and production environments (e.g., separate cloud accounts or instances) Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Distinct dev, test and production environments ∙ Deployment only through defined promotion process Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Separate dev/test/prod environments with access separation ∙ Change management for promotion to production Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Environment separation enforced by cloud account/subscription boundaries and network segmentation ∙ Release management with approval gates ∙ Separation of Duties (SoD) Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Enterprise environment segregation standards (separate accounts, networks, identities) ∙ Automated promotion pipelines with approvals ∙ SoD enforcement and audit SCR-CMM Level 0 Not Performed Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed. Level 1 Performed Informally SCR-CMM Level 1 criteria definitions are not available for this control: ▪ A reasonable person would conclude this control requires a structured process. ▪ At this level of maturity, the "ad hoc" nature of performing a capability informally would indicate the intent of the control is not met due to a lack of consistency and formality. Level 2 Planned Tracked Technology Development & Acquisition (TDA) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with TDA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Technology development and acquisition management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Secure development practices mostly conform to industry-recognized standards for secure engineering of Technology Assets, Applications and/or Services (TAAS) (e.g., OWASP, NIST SP 800-218 and NIST SP 800-160). ▪ An application development team, or similar function, uses a structured process to design, build and maintain secure configurations for test, development, staging and production environments. Level 3 Well Defined Technology Development & Acquisition (TDA) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function. ▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners. ▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution and software testing tools). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with TDA domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls). ▪ An implemented and operational capability exists to 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 Technology Assets, Applications and/or Services (TAAS). 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	Separation of Development, Testing and Operational Environments Description Mechanisms exist to 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 Technology Assets, Applications and/or Services (TAAS). Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Separate development/test and production environments (e.g., separate cloud accounts or instances) Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Distinct dev, test and production environments ∙ Deployment only through defined promotion process Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Separate dev/test/prod environments with access separation ∙ Change management for promotion to production Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Environment separation enforced by cloud account/subscription boundaries and network segmentation ∙ Release management with approval gates ∙ Separation of Duties (SoD) Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Enterprise environment segregation standards (separate accounts, networks, identities) ∙ Automated promotion pipelines with approvals ∙ SoD enforcement and audit SCR-CMM Level 0 Not Performed Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed. Level 1 Performed Informally SCR-CMM Level 1 criteria definitions are not available for this control: ▪ A reasonable person would conclude this control requires a structured process. ▪ At this level of maturity, the "ad hoc" nature of performing a capability informally would indicate the intent of the control is not met due to a lack of consistency and formality. Level 2 Planned Tracked Technology Development & Acquisition (TDA) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with TDA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Technology development and acquisition management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Secure development practices mostly conform to industry-recognized standards for secure engineering of Technology Assets, Applications and/or Services (TAAS) (e.g., OWASP, NIST SP 800-218 and NIST SP 800-160). ▪ An application development team, or similar function, uses a structured process to design, build and maintain secure configurations for test, development, staging and production environments. Level 3 Well Defined Technology Development & Acquisition (TDA) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function. ▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners. ▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution and software testing tools). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with TDA domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls). ▪ An implemented and operational capability exists to 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 Technology Assets, Applications and/or Services (TAAS). 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	Use of Live Data Description Mechanisms exist to approve, document and control the use of live data in development and test environments. Possible Solutions & Considerations Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2 ∙ Do not use customer/production data in test; use sample data Small Business (10-49 staff) / BLS Firm Size Classes 3-4 ∙ Policy prohibiting live data in dev/test without approval ∙ Anonymized or synthetic test data Medium Business (50-249 staff) / BLS Firm Size Classes 5-6 ∙ Approval and documentation process for any live data use in test ∙ Data masking/anonymization (e.g., database masking tools) Large Business (250-999 staff) / BLS Firm Size Classes 7-8 ∙ Test data management with masking/synthetic data (e.g., Delphix, Informatica TDM, Tonic) ∙ Approval workflow and logging for live data exceptions Enterprise (> 1,000 staff) / BLS Firm Size Class 9 ∙ Enterprise test data management program (masking, synthetic data, approval controls) ∙ DLP monitoring of non-production environments ∙ Compliance reporting on live data use SCR-CMM Level 0 Not Performed Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed. Level 1 Performed Informally Technology Development & Acquisition (TDA) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with TDA domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Technology development & acquisition-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218 and NIST SP 800-160). Level 2 Planned Tracked Technology Development & Acquisition (TDA) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are documented and maintained by process owners. ▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with TDA domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Technology development and acquisition-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines). ▪ Technology development and acquisition management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel. ▪ Secure development practices mostly conform to industry-recognized standards for secure engineering of Technology Assets, Applications and/or Services (TAAS) (e.g., OWASP, NIST SP 800-218 and NIST SP 800-160). ▪ An application development team, or similar function, uses a structured process to design, build and maintain secure configurations for test, development, staging and production environments. Level 3 Well Defined Technology Development & Acquisition (TDA) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Policies and standards associated with TDA domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function. ▪ Standardized Operating Procedures (SOP) associated with TDA domain capabilities are well-documented and kept current by process owners. ▪ A software development team, or similar function, is appropriately staffed and supported to implement and maintain TDA domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of technology development and acquisition management (e.g., project management software, software escrow solution and software testing tools). ▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with TDA domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls). ▪ An implemented and operational capability exists to approve, document and control the use of live data in development and test environments. Level 4 Quantitatively Controlled Technology Development & Acquisition (TDA) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist: ▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational. ▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs). ▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs). ▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties. ▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review). ▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes. ▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities. Level 5 Continuously Improving Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions: ▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control. ▪ Level 5 capabilities should be considered “world-class” where the control builds on Level 4 capabilities, but are continuously improving through Artificial Intelligence (AI) and/or Machine Learning (ML) technologies. ▪ While it may be possible to develop responsive capabilities for this control through the use of AI and/or ML technologies, the criteria would be organization-specific to define.

Builddate: 25.06.2024 00:00:00 -Doknr: CELEX:32024R1774
EULAW -
European Regulation published on http://eur-lex.europa.eu/

Článek 8 Politiky a postupy pro operace IKT

1. Přehled

1.1 Odkazy

1.2 Identifikované požadavky

1.3 Související standardy

2. Identifikované požadavky

3. Související standardy

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