+Artikel 6 Ramme for IKT-risikostyring
---+Artikel 6 1
---+Artikel 6 2
---+Artikel 6 3
---+Artikel 6 4
---+Artikel 6 5
---+Artikel 6 6
---+Artikel 6 7
---+Artikel 6 8
---+Artikel 6 9
---+Artikel 6 10

Artikel 6 Ramme for IKT-risikostyring

-

1. Oversigt

,
Artikel 6 1

1.   Finansielle enheder indfører en robust, omfattende og veldokumenteret ramme for IKT-risikostyring som en del af deres samlede risikostyringssystem, der sætter dem i stand til at håndtere IKT-risikoen hurtigt, effektivt og fyldestgørende, og som sikrer et højt niveau af digital operationel modstandsdygtighed.
Artikel 6 2

2.   Rammen for IKT-risikostyring skal som minimum omfatte strategier, politikker, procedurer, IKT-protokoller og -værktøjer, som er nødvendige for på behørig vis og i tilstrækkelig grad at beskytte alle informationsaktiver og IKT-aktiver, herunder computersoftware, -hardware og servere, samt for at beskytte alle relevante fysiske komponenter og infrastrukturer, såsom lokaler, datacentre og sensitive udpegede områder, for at sikre tilstrækkelig beskyttelse af alle informationsaktiver og IKT-aktiver mod risici, herunder skade og uautoriseret adgang eller brug.
Artikel 6 3

3.   I overensstemmelse med deres ramme for IKT-risikostyring minimerer de finansielle enheder virkningerne af IKT-risiko ved at indføre passende strategier, politikker, procedurer, IKT-protokoller og -værktøjer. De forelægger fuldstændige og ajourførte oplysninger om IKT-risiko og om deres ramme for IKT-styring for de kompetente myndigheder på disses anmodning.
Artikel 6 4

4.   Finansielle enheder, som ikke er mikrovirksomheder, overdrager ansvaret for styring af og tilsyn med IKT-risikoen til en kontrolfunktion og sikrer, at denne kontrolfunktion har et passende uafhængighedsniveau, således at interessekonflikter undgås. Finansielle enheder sikrer en passende adskillelse og uafhængighed af IKT-risikostyringsfunktioner, kontrolfunktioner og interne revisionsfunktioner efter modellen med tre forsvarslinjer eller en intern model for risikostyring og kontrol.
Artikel 6 5

5.   Rammen for IKT-risikostyring skal dokumenteres og gennemgås mindst én gang om året, eller regelmæssigt for så vidt angår mikrovirksomheder, samt når der forekommer større IKT-relaterede hændelser, og i henhold til tilsynsmæssige instrukser eller konklusioner, som er udledt af relevant test af digital operationel modstandsdygtighed eller revisionsprocesser. Den skal forbedres løbende på grundlag af indhøstede gennemførelses- og overvågningserfaringer. Der skal forelægges en rapport om gennemgangen af rammen for IKT-risikostyring for den kompetente myndighed på dens anmodning.
Artikel 6 6

6.   Revisorer foretager regelmæssigt intern revision af rammen for IKT-risikostyring for andre finansielle enheder end mikrovirksomheder i overensstemmelse med de finansielle enheders revisionsplan. Disse revisorer skal besidde tilstrækkelig viden, faglig kompetence og ekspertise med hensyn til IKT-risici og være tilstrækkeligt uafhængige. Hyppigheden af IKT-revisioner og deres fokus skal stå i rimeligt forhold til den finansielle enheds IKT-risiko.
Artikel 6 7

7.   De finansielle enheder etablerer på baggrund af konklusioner fra den interne revisionsgennemgang en formel opfølgningsproces, herunder regler for rettidig efterprøvning og udbedring af kritiske resultater af IKT-revisioner.
Artikel 6 8

8.   Rammen for IKT-risikostyring skal omfatte en strategi for digital operationel modstandsdygtighed, der fastsætter, hvordan rammen gennemføres. Med henblik herpå skal strategien for digital operationel modstandsdygtighed omfatte metoderne til håndtering af IKT-risiko og opfylde specifikke IKT-mål ved at

a)

redegøre for, hvordan rammen for IKT-risikostyring understøtter den finansielle enheds forretningsstrategi og -mål

b)

fastlægge risikotoleranceniveauet for IKT-risiko i overensstemmelse med den finansielle enheds risikovillighed og analysere tolerancen over for virkninger af IKT-forstyrrelser

c)

fastsætte klare informationssikkerhedsmål, herunder centrale resultatindikatorer og centrale risikoparametre

d)

redegøre for IKT-referencearkitekturen og eventuelle ændringer, der er nødvendige for at nå specifikke forretningsmål

e)

beskrive de forskellige indførte mekanismer til detektion af IKT-relaterede hændelser, forebygge deres virkning og give beskyttelse mod den

f)

dokumentere den nuværende situation for den digitale operationelle modstandsdygtighed på grundlag af antallet af indberettede større IKT-relaterede hændelser og de forebyggende foranstaltningers effektivitet

g)

gennemføre test af digital operationel modstandsdygtighed i overensstemmelse med denne forordnings kapitel IV

h)

fastlægge en kommunikationsstrategi i tilfælde af IKT-relaterede hændelser, hvis offentliggørelse er påkrævet i henhold til artikel 14.
Artikel 6 9

9.   Finansielle enheder kan i forbindelse med strategien for digital operationel modstandsdygtighed som omhandlet i stk. 8 fastlægge en helhedsorienteret strategi med flere IKT-udbydere på koncern- eller enhedsplan, som viser, hvor der er stor afhængighed af tredjepartsudbydere af IKT-tjenester, og begrunde den pågældende udbudssammensætning af tredjepartsudbydere af IKT-tjenester.
Artikel 6 10

10.   Finansielle enheder kan i overensstemmelse med sektorspecifik EU-ret og national ret outsource de opgaver, der er forbundet med efterprøvning af overholdelsen af kravene til IKT-risikostyring, til koncerninterne eller eksterne virksomheder. I tilfælde af en sådan outsourcing er den finansielle enhed fortsat fuldt ud ansvarlig for at efterprøve overholdelsen af kravene til IKT-risikostyring.

1.1 Referencer

1.2 Identificerede krav

1.3 Relaterede standarder

2. Identificerede krav

Krav

3. Relaterede standarder

Standarder
SCF Publishing Security, Compliance & Resilience Documentation

Description

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

Possible Solutions & Considerations

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

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

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

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

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

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

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

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

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

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

SCR-CMM

Level 0 Not Performed

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

Level 1 Performed Informally

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

Level 2 Planned Tracked

Cybersecurity & Data Protection Governance (GOV) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are documented and maintained by process owners.
▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with GOV domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Governance-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT and/or cybersecurity personnel.
▪ IT and/or cybersecurity personnel ensure cybersecurity policies and standards are aligned with a leading cybersecurity framework (e.g., SCF, NIST 800-53, NIST 800-171, ISO 27002 or NIST Cybersecurity Framework).
▪ The organization's cybersecurity policies and standards are made available to internal personnel.
▪ Documented procedures exist for requesting a deviation from approved standards.
▪ The responsibility for enforcing cybersecurity and data protection control implementation is assigned to business / process owners and asset custodians.

Level 3 Well Defined

Cybersecurity & Data Protection Governance (GOV) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.
▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).
▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).
▪ An implemented and operational capability exists to establish, maintain and disseminate policies, standards and procedures necessary for secure, compliant and resilient capabilities.

Level 4 Quantitatively Controlled

Cybersecurity & Data Protection Governance (GOV) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.
▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).
▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).
▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.
▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).
▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.
▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.

Level 5 Continuously Improving

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

Description

Mechanisms exist to develop, report and monitor Key Performance Indicators (KPIs) to assist organizational management in performance monitoring, trend analysis, and possible control redesign or replacement for the Security, Compliance & Resilience Program (SCRP).

Possible Solutions & Considerations

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

∙ Manually-generated metrics (spreadsheet)
∙ Key security KPIs: patch compliance %, training completion %, incident count, open vulnerability age

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

∙ Manually-generated metrics with defined KPI thresholds
∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)
∙ Monthly/quarterly KPI reporting to leadership

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

∙ Defined security KPI library (CIS, CISA, or custom)
∙ Automated KPI collection via GRC or SIEM integration
∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)

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

∙ Formal KPI program with defined targets, thresholds, and owners
∙ GRC platform with automated KPI dashboards (e.g., SCFConnect, Cyturus, etc.)
∙ Board-level security KPI reporting cadence

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

∙ Enterprise KPI program aligned to NIST, CIS, or custom security frameworks
∙ Automated KPI collection and reporting via GRC/SIEM integration
∙ Board and audit committee KPI reporting with trend analysis
∙ KPIs mapped to business risk appetite and strategic objectives

SCR-CMM

Level 0 Not Performed

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

Level 1 Performed Informally

SCR-CMM Level 1 criteria definitions are not available for this control:
▪ A reasonable person would conclude this control requires a structured process.
▪ At this level of maturity, the "ad hoc" nature of performing a capability informally would indicate the intent of the control is not met due to a lack of consistency and formality.

Level 2 Planned Tracked

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

Level 3 Well Defined

Cybersecurity & Data Protection Governance (GOV) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.
▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).
▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).
▪ An implemented and operational capability exists to develop, report and monitor Key Performance Indicators (KPIs) to assist organizational management in performance monitoring and trend analysis of the Security, Compliance & Resilience Program (SCRP).

Level 4 Quantitatively Controlled

Cybersecurity & Data Protection Governance (GOV) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.
▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).
▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).
▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.
▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).
▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.
▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.

Level 5 Continuously Improving

Cybersecurity & Data Protection Governance (GOV) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.
▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.
▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies.
SCF Key Risk Indicators (KRIs)

Description

Mechanisms exist to develop, report and monitor Key Risk Indicators (KRIs) to assist senior management in performance monitoring, trend analysis, and possible control redesign or replacement for the Security, Compliance & Resilience Program (SCRP).

Possible Solutions & Considerations

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

∙ Manually-generated metrics (spreadsheet)
∙ Basic risk indicators: critical unpatched vulnerabilities, failed logins, open security incidents

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

∙ Manually-generated KRI tracking with alert thresholds
∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)
∙ Documented risk tolerance thresholds

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

∙ Defined KRI library tied to organizational risk register
∙ Automated KRI monitoring via GRC platform or SIEM (e.g., Splunk, Microsoft Sentinel)
∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.)

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

∙ Formal KRI program with defined risk appetite thresholds
∙ Automated KRI monitoring with escalation triggers
∙ GRC platform with KRI dashboards linked to risk register
∙ Regular KRI reporting to risk committee

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

∙ Enterprise KRI program integrated with risk management framework
∙ Automated real-time KRI monitoring with AI-assisted anomaly detection
∙ Board-level risk indicator reporting with trend analysis
∙ KRIs linked to enterprise risk appetite and materiality thresholds

SCR-CMM

Level 0 Not Performed

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

Level 1 Performed Informally

Cybersecurity & Data Protection Governance (GOV) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with GOV domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Governance-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ No formal Governance, Risk & Compliance (GRC) team exists. GRC roles are assigned to existing IT/cybersecurity personnel.
▪ Cybersecurity and data protection governance is informally assigned as an additional duty to existing IT/cybersecurity personnel.
▪ Organizational leadership maintains an informal process to review and respond to observed trends.

Level 2 Planned Tracked

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

Level 3 Well Defined

Cybersecurity & Data Protection Governance (GOV) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with GOV domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Standardized Operating Procedures (SOP) associated with GOV domain capabilities are well-documented and kept current by process owners.
▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, is appropriately staffed and supported to implement and maintain GOV domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).
▪ Technology is leveraged to enhance the efficiency and accuracy of governance, risk management and compliance operations (e.g., GRC platform).
▪ An implemented and operational capability exists to develop, report and monitor Key Risk Indicators (KRIs) to assist senior management in performance monitoring and trend analysis of the Security, Compliance & Resilience Program (SCRP).

Level 4 Quantitatively Controlled

Cybersecurity & Data Protection Governance (GOV) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.
▪ Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).
▪ Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).
▪ Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.
▪ Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).
▪ Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.
▪ Business and technical stakeholders are involved in reviewing and approving proposed changes to evolve capabilities.

Level 5 Continuously Improving

Cybersecurity & Data Protection Governance (GOV) capabilities, in addition to being standardized across the entity and centrally managed to ensure consistency across Technology Assets, Applications, Services and/or Data (TAASD), efforts are metrics driven to provide sufficient insight for decision makers to predict optimal performance, ensure continued operations and/or identify areas for improvement. Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Applicable SCR-CMM Level 3 (Well Defined) capabilities are implemented and operational.
▪ Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.
▪ Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions via Artificial Intelligence (AI) or Machine Learning (ML) technologies.
SCF Strategic Plan & Objectives

Description

Mechanisms exist to establish a:
(1) Strategic security, compliance and resilience-specific business plan; and
(2) Set of objectives to achieve that plan.

Possible Solutions & Considerations

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

∙ Include security tasks in project plans

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

∙ Security requirements in project planning
∙ Project security checklist

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

∙ Documented cybersecurity and data protection-specific business plan

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

∙ Documented cybersecurity and data protection-specific business plan

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

∙ Documented cybersecurity and data protection-specific business plan

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

Project & Resource Management (PRM) 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 PRM domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with PRM 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 PRM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Project & Resource Management -related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ Project & Resource Management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ The Chief Information Officer (CIO), or similar function, analyzes the organization's business strategy and prioritizes the objectives and resourcing of the security function, based on broader business requirements.
▪ A Project Management Office (PMO), or project management function, enables the implementation of cybersecurity and data protection-related resource planning controls across the System Development Lifecycle (SDLC) for all high-value projects.
▪ Quarterly Business Review (QBR), or similar status reporting, exists to provide recurring reports on the state of the cybersecurity and data protection program.

Level 3 Well Defined

Project & Resource Management (PRM) 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 PRM 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 PRM domain capabilities are well-documented and kept current by process owners.
▪ A Project Management Office (PMO), or similar function, is appropriately staffed and supported to implement and maintain PRM domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of project and resource management operations (e.g., project 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 PRM 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).
▪ The Chief Information Officer (CIO), or similar function, analyzes the organization's business strategy and prioritizes the objectives and resourcing of the security function, based on broader business requirements.
▪ An implemented and operational capability exists to establish a:
(1) Strategic security, compliance and resilience-specific business plan; and
(2) Set of objectives to achieve that plan.

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

Description

Mechanisms exist to facilitate the implementation of strategic, operational and tactical risk management controls that are aligned with:
(1) The organization's Enterprise Risk Management (ERM); and
(2) Industry-recognized cybersecurity risk management practices.

Possible Solutions & Considerations

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

∙ Risk Management Program (RMP)

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

∙ Risk Management Program (RMP)

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

∙ Risk Management Program (RMP)

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

∙ Risk Management Program (RMP)

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

∙ 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

Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.
▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.
▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.

Level 2 Planned Tracked

Risk Management (RSK) 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 RSK domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with RSK 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.
▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.
▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.
▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).

Level 3 Well Defined

Risk Management (RSK) 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 RSK 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 RSK domain capabilities are well-documented and kept current by process owners.
▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform and TPRM tool).
▪ 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 RSK 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 strategic, operational and tactical risk management controls.

Level 4 Quantitatively Controlled

Risk Management (RSK) 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 Risk Management Program

Description

Mechanisms exist to facilitate the implementation of strategic, operational and tactical risk management controls that are aligned with:
(1) The organization's Enterprise Risk Management (ERM); and
(2) Industry-recognized cybersecurity risk management practices.

Possible Solutions & Considerations

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

∙ Risk Management Program (RMP)

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

∙ Risk Management Program (RMP)

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

∙ Risk Management Program (RMP)

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

∙ Risk Management Program (RMP)

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

∙ 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

Risk Management (RSK) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with RSK domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Risk management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
▪ IT and/or cybersecurity personnel use an informal process to identify, assess, remediate and report on risk.
▪ Risk management processes (e.g., risk assessments) focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.
▪ Data/process owners are expected to self-manage risks associated with their Technology Assets, Applications, Services and/or Data (TAASD), based on the organization's published policies and standards, including the identification, remediation and reporting of risks.

Level 2 Planned Tracked

Risk Management (RSK) 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 RSK domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with RSK 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 RSK domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Risk management-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ Risk management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ Risk management processes (e.g., risk assessments) and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.
▪ IT and/or cybersecurity personnel implement and maintain a form of Risk Management Program (RMP) that provides operational guidance on how risk is identified, assessed, remediated and reported.
▪ Data/process owners are expected to self-manage risks associated with their systems, applications, services and data, based on the organization's published policies and standards, including the identification, remediation and reporting of risks.
▪ Business process owners (BPOs) are made aware of cybersecurity and data protection risk(s).

Level 3 Well Defined

Risk Management (RSK) 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 RSK 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 RSK domain capabilities are well-documented and kept current by process owners.
▪ A risk management team, or similar function, is appropriately staffed and supported to implement and maintain RSK domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of risk management operations (e.g., risk management solution, GRC platform and TPRM tool).
▪ 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 RSK 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 strategic, operational and tactical risk management controls.

Level 4 Quantitatively Controlled

Risk Management (RSK) 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.