+Vulnerability Remediation Process
---+Centralized Management of Flaw Remediation Processes
---+Continuous Vulnerability Remediation Activities
---+Known Exploited Vulnerabilities (KEV) Mitigations

Vulnerability Remediation Process

Description

Mechanisms exist to ensure that vulnerabilities are properly identified, tracked and remediated.

Possible Solutions & Considerations

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

∙ Patch software when updates are released

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

∙ Vulnerability remediation policy
∙ Prioritized patching schedule

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

∙ Formal vulnerability remediation process
∙ Risk-based prioritization
∙ Remediation SLAs

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

∙ Enterprise vulnerability remediation program
∙ Defined SLAs by severity
∙ Tracking and reporting

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

∙ Enterprise vulnerability management platform (e.g., Tenable.io, Qualys)
∙ Automated remediation tracking
∙ SIEM 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

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

Level 2 Planned Tracked

Vulnerability & Patch Management (VPM) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are documented and maintained by process owners.
▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with VPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ Vulnerability management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.

Level 3 Well Defined

Vulnerability & Patch Management (VPM) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.
▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution and vulnerability scanning 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 VPM domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).
▪ An implemented and operational capability exists to ensure that vulnerabilities are properly identified, tracked and remediated.

Level 4 Quantitatively Controlled

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

Level 5 Continuously Improving

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

1. Resumen

Centralized Management of Flaw Remediation Processes

Description

Mechanisms exist to centrally-manage the flaw remediation process.

Possible Solutions & Considerations

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

∙ Centrally track vulnerability status across all systems

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

∙ Centralized vulnerability tracking spreadsheet or tool

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

∙ Centralized vulnerability management platform (e.g., Tenable.io, Qualys)

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

∙ Enterprise centralized vulnerability management platform with integrated asset management

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

∙ Enterprise vulnerability management platform (e.g., Tenable One, Qualys VMDR)
∙ Full asset-vulnerability integration
∙ Automated centralized management

SCR-CMM

Level 0 Not Performed

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

Level 1 Performed Informally

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

Level 2 Planned Tracked

Level 3 Well Defined

Level 4 Quantitatively Controlled

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.

Continuous Vulnerability Remediation Activities

Description

Mechanisms exist to address new threats and vulnerabilities on an ongoing basis and ensure assets are protected against known attacks.

Possible Solutions & Considerations

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

∙ Continuously monitor for new vulnerabilities in used software

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

∙ Continuous vulnerability scanning and remediation cycle

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

∙ Formal continuous vulnerability management program
∙ Regular scan cadence

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

∙ Enterprise continuous vulnerability management (e.g., Tenable.io, Qualys)
∙ Automated remediation workflows

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

∙ Enterprise continuous vulnerability management platform
∙ Real-time scanning
∙ Automated patching integration
∙ SIEM/SOAR 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

Level 2 Planned Tracked

Level 3 Well Defined

Vulnerability & Patch Management (VPM) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.
▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution and vulnerability scanning 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 VPM domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).
▪ An implemented and operational capability exists to address new threats and vulnerabilities on an ongoing basis and ensure assets are protected against known attacks.

Level 4 Quantitatively Controlled

Level 5 Continuously Improving

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

Known Exploited Vulnerabilities (KEV) Mitigations

Description

Mechanisms exist to prioritize remediation and mitigation of Known Exploited Vulnerabilities (KEV) by:
(1) Reducing or removing public exposure to exploitation; and
(2) Expediting patch deployment actions.

Possible Solutions & Considerations

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

∙ Subscribe to CISA KEV catalog alerts (https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
∙ Prioritize patching KEV-listed vulnerabilities within CISA timeframes

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

∙ CISA KEV catalog subscription and monitoring
∙ Priority patching for KEV-listed vulnerabilities within CISA-defined windows

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

∙ KEV-integrated vulnerability management program
∙ CISA KEV catalog integration with vulnerability scanner
∙ Accelerated remediation SLAs for KEV items

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

∙ Enterprise vulnerability management with KEV prioritization
∙ Automated KEV alerting and remediation tracking
∙ Defined KEV remediation SLAs

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

∙ Enterprise KEV management program
∙ Automated CISA KEV catalog integration
∙ Real-time KEV exposure tracking and alerting
∙ Risk-based KEV remediation with board-level visibility for material exposures

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

Level 2 Planned Tracked

Level 3 Well Defined

Vulnerability & Patch Management (VPM) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with VPM domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Standardized Operating Procedures (SOP) associated with VPM domain capabilities are well-documented and kept current by process owners.
▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution and vulnerability scanning 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 VPM domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).
▪ An implemented and operational capability exists to prioritize remediation and mitigation of Known Exploited Vulnerabilities (KEV) by:
(1) Reducing or removing public exposure to exploitation; and
(2) Expediting patch deployment actions.

Level 4 Quantitatively Controlled

Level 5 Continuously Improving

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

1.1 Referencias

1.2 Requisitos identificados

1.3 Regulaciones relacionadas

2. Requisitos identificados

Requisitos
Fuente	Requisito

3. Regulaciones relacionadas

Regulaciones
Fuente	Regulación
EULAW	Artículo 25 1 1. El programa de pruebas de resiliencia operativa digital a que se refiere el artículo 24 dispondrá, de conformidad con los criterios establecidos en el artículo 4, apartado 2, la ejecución de las pruebas adecuadas, como evaluaciones y exploraciones de vulnerabilidad, análisis del software de código abierto, evaluaciones de seguridad de la red, análisis de carencias, exámenes de la seguridad física, cuestionarios y soluciones de software de detección, revisiones del código fuente cuando sea posible, pruebas basadas en escenarios, pruebas de compatibilidad, pruebas de rendimiento, pruebas de extremo a extremo y pruebas de penetración.
EULAW	Artículo 25 2 2. Los depositarios centrales de valores y las entidades de contrapartida central realizarán evaluaciones de vulnerabilidad antes de implantar o reimplantar aplicaciones y componentes de infraestructuras y servicios de TIC que sustenten funciones esenciales o importantes de la entidad financiera nuevos o ya existentes.
EULAW	Artículo 25 3 3. Las microempresas realizarán las pruebas a que se refiere el apartado 1 mediante la combinación de un enfoque basado en el riesgo con una planificación estratégica de las pruebas de TIC, teniendo debidamente en cuenta la necesidad de mantener un planteamiento equilibrado entre la dimensión de los recursos y el tiempo que se asigne a las pruebas de TIC previstas en el presente artículo, por una parte, y la urgencia, el tipo de riesgo, el carácter esencial de los activos de información y de los servicios prestados, así como cualquier otro factor pertinente, incluida la capacidad de la entidad financiera para asumir riesgos calculados, por otra.
EULAW	Artículo 10 Gestión de vulnerabilidades y parches -
EULAW	Artículo 10 Gestión de vulnerabilidades y parches -
EULAW	Artículo 10 Gestión de vulnerabilidades y parches -
EULAW	Artículo 34 Seguridad de las operaciones de TIC Artículo 34 Seguridad de las operaciones de TIC Dentro de sus sistemas, protocolos y herramientas, y con respecto a todos los activos de TIC, las entidades financieras a que se refiere el artículo 16, apartado 1, del Reglamento (UE) 2022/2554: a) harán un seguimiento del ciclo de vida de todos los activos de TIC y lo gestionarán; b) harán un seguimiento, en su caso, de si los activos de TIC cuentan con el soporte de proveedores terceros de servicios de TIC; c) determinarán los requisitos de capacidad de sus activos de TIC y las medidas para mantener y mejorar la disponibilidad y eficiencia de los sistemas de TIC y prevenir la escasez de capacidad de TIC antes de que se materialice; d) llevarán a cabo exploraciones y evaluaciones automatizadas de vulnerabilidad de los activos de TIC, acordes con la clasificación de tales activos contemplada en el artículo 30, apartado 1, y con el perfil de riesgo general de cada activo de TIC, e implementarán parches para hacer frente a las vulnerabilidades detectadas; e) gestionarán los riesgos relacionados con los activos de TIC obsoletos, sin soporte o heredados; f) registrarán los acontecimientos relacionados con el control del acceso lógico y físico, las operaciones de TIC, incluidas las actividades de sistema y de tráfico de red, y la gestión de cambios en las TIC; g) determinarán y aplicarán medidas para el seguimiento y el análisis de la información sobre actividades y comportamientos anómalos respecto de operaciones de TIC esenciales o importantes; h) aplicarán medidas para el seguimiento de la información pertinente y actualizada sobre las ciberamenazas; i) aplicarán medidas para la detección de posibles fugas de información, códigos maliciosos y otras amenazas para la seguridad, así como vulnerabilidades en el software y el hardware conocidas públicamente, y comprobarán las nuevas actualizaciones de seguridad correspondientes. A efectos de la letra f), las entidades financieras adaptarán el grado de detalle de los registros a la finalidad y al uso del activo de TIC que los genere.
EULAW	Artículo 21 Medidas para la gestión de riesgos de ciberseguridad -
EULAW	Artículo 13 Obligaciones de los fabricantes -

Incidencias vinculadas

Vínculos
Tipo de vínculo	Incidencia
is related to	Semi-Annual
is related to	relative Control Weighting = 09
is related to	Process
is related to	Detect
is related to	SCRM Focus Tier 2 OPERATIONAL
is related to	SCRM Focus Tier 3 TACTICAL
blocks	Excessive or Unauthorized Privilege
blocks	Unauthorized Privilege Elevation
blocks	Unauthorized Access
blocks	Unauthorized Retention / Inability to Dispose of Data
blocks	Business / Service Interruption
blocks	Data Loss / Integrity Compromise
blocks	Reduced Operational Productivity
blocks	System / Data Compromise (Technical Vector)
blocks	Revenue Loss
blocks	Contractual Default / Termination
blocks	Loss of Competitive Advantage
blocks	Reputational Harm / Loss of Stakeholder Trust
blocks	Regulatory / Legal / Contractual Financial Liability
blocks	Exposure from Unaddressed Vulnerabilities
blocks	System / Service Compromise
blocks	Failure to Support Business / Mission Objectives
blocks	Unaddressed Security / Compliance Exposure
blocks	Unperformed / Unowned Control Responsibilities
blocks	Uncontrolled Internal Security / Privacy Exposure
blocks	Uncontrolled Third-Party Security / Privacy Exposure
blocks	Lack of oversight of internal controls
blocks	Lack of oversight of third-party controls
blocks	Loss of Investigative / Evidentiary Capability
blocks	Delayed Containment / Increased Incident Impact
blocks	Incident Persistence / Recurrence
blocks	Incident Response / Recovery Cost
blocks	Undetected / Delayed Detection of Adverse Activity
blocks	Third-Party Cybersecurity Compromise / Exposure
blocks	Third-Party Physical Security Disruption / Exposure
blocks	Sub-Tier / Fourth-Party Supply Chain Exposure
blocks	Third-Party Legal / Compliance Exposure
blocks	Harm from Unauthorized / Unintended Product or Service Use
blocks	Third-Party Dependency Failure
blocks	Exfiltration Over Bluetooth
blocks	Remote Desktop Protocol
blocks	Distributed Component Object Model
blocks	SSH
blocks	VNC
blocks	Windows Remote Management
blocks	Network Service Discovery
blocks	Windows Management Instrumentation
blocks	Exfiltration Over Physical Medium
blocks	Exfiltration over USB
blocks	Scheduled Task/Job
blocks	At
blocks	Cron
blocks	Scheduled Task
blocks	Command and Scripting Interpreter
blocks	PowerShell
blocks	Visual Basic
blocks	JavaScript
blocks	Exploitation for Privilege Escalation
blocks	Valid Accounts
blocks	Replication Through Removable Media
blocks	Communication Through Removable Media
blocks	SSH Authorized Keys
blocks	Trusted Developer Utilities Proxy Execution
blocks	MSBuild
blocks	ClickOnce
blocks	External Remote Services
blocks	Office Application Startup
blocks	Office Template Macros
blocks	Software Extensions
blocks	Exploit Public-Facing Application
blocks	Supply Chain Compromise
blocks	Compromise Software Dependencies and Development Tools
blocks	Compromise Software Supply Chain
blocks	Malicious Image
blocks	Exploitation of Remote Services
blocks	Exploitation for Stealth
blocks	Exploitation for Credential Access
blocks	Data from Information Repositories
blocks	Confluence
blocks	Sharepoint
blocks	Code Repositories
blocks	Messaging Applications
blocks	System Binary Proxy Execution
blocks	CMSTP
blocks	InstallUtil
blocks	Mshta
blocks	Odbcconf
blocks	Regsvcs/Regasm
blocks	Verclsid
blocks	Mavinject
blocks	MMC
blocks	Electron Applications
blocks	Template Injection
blocks	Domain Trust Discovery
blocks	Domain or Tenant Policy Modification
blocks	Server Software Component
blocks	SQL Stored Procedures
blocks	Transport Agent
blocks	Web Shell
blocks	IIS Components
blocks	Terminal Services DLL
blocks	Implant Internal Image
blocks	Steal Application Access Token
blocks	Data from Cloud Storage
blocks	ROMMONkit
blocks	TFTP Boot
blocks	Create or Modify System Process
blocks	Screensaver
blocks	Emond
blocks	Kernel Modules and Extensions
blocks	Re-opened Applications
blocks	LSASS Driver
blocks	Abuse Elevation Control Mechanism
blocks	Bypass User Account Control
blocks	Sudo and Sudo Caching
blocks	TCC Manipulation
blocks	Unsecured Credentials
blocks	Credentials In Files
blocks	Credentials in Registry
blocks	Private Keys
blocks	Group Policy Preferences
blocks	Adversary-in-the-Middle
blocks	AS-REP Roasting
blocks	Inter-Process Communication
blocks	Dynamic Data Exchange
blocks	Archive Collected Data
blocks	Archive via Utility
blocks	Remote Service Session Hijacking
blocks	SSH Hijacking
blocks	RDP Hijacking
blocks	Phishing
blocks	Hijack Execution Flow
blocks	DLL
blocks	Dylib Hijacking
blocks	Executable Installer File Permissions Weakness
blocks	Path Interception by PATH Environment Variable
blocks	Path Interception by Search Order Hijacking
blocks	Path Interception by Unquoted Path
blocks	Services File Permissions Weakness
blocks	Modify Cloud Compute Infrastructure
blocks	Create Snapshot
blocks	Create Cloud Instance
blocks	Delete Cloud Instance
blocks	Build Image on Host
is related to	Annual
is related to	relative Control Weighting = 10
is related to	Protect
is related to	SCRM Focus Tier 1 STRATEGIC
blocks	Inability to Demonstrate Due Diligence / Due Care
blocks	OT Safety / Process Availability Failure
blocks	Drought & Water Shortage
blocks	Earthquakes
blocks	Fire & Wildfires
blocks	Floods
blocks	Hurricanes & Tropical Storms
blocks	Landslides & Debris Flow
blocks	Pandemic (Disease) Outbreaks
blocks	Severe Weather
blocks	Space Weather
blocks	Thunderstorms & Lightning
blocks	Tornadoes
blocks	Tsunamis
blocks	Volcanoes
blocks	Winter Storms & Extreme Cold
blocks	Malicious Cyber Activity
blocks	Dysfunctional Management Practices
blocks	Human Error
blocks	Technical / Mechanical Failure
blocks	Data Quality Degradation / Data Poisoning
blocks	Conflict of Interest (COI) / Undue Influence / Insider Misconduct
blocks	Workforce Shortage / Loss of Critical Skills / Labor Disruption
blocks	OPS-18.01B
blocks	OPS-18.02B
blocks	OPS-18.03B
blocks	OPS-18.04B
blocks	OPS-22.07B
blocks	OPS-22.08B
blocks	OPS-25.03B
blocks	OPS-25.01AC
blocks	COS-03.04B
blocks	DEV-01.01B
blocks	DEV-07.05B
blocks	PSS-02.03B
blocks	PSS-03.02B
blocks	PSS-09.03B
is blocked by	VPM-06 Vulnerability Remediation Process – Assessment Procedure
blocks	PM-04 Plan of Action and Milestones Process
blocks	SC-18(01) Identify Unacceptable Code and Take Corrective Actions
blocks	PM-04 [P] Plan of Action and Milestones Process
blocks	03.11.02 Vulnerability Monitoring and Scanning
blocks	03.12.02 Plan of Action and Milestones
blocks	03.14.01 Flaw Remediation
blocks	ID.RA-08 Processes for receiving, analyzing, and responding to vulnerability disclosures are established
blocks	PR.PS-02 Software is maintained, replaced, and removed commensurate with risk
blocks	RV.2.2 Plan and implement risk responses for vulnerabilities.

Secure Controls Framework -
EN: GRCA includes the Secure Controls Framework® (SCF) content, © Secure Controls Framework Council, LLC, used under the Creative Commons Attribution-NoDerivatives 4.0 International Public License. SCF control numbers, names, descriptions and mappings appear exactly as published by the SCF Council – https://securecontrolsframework.com. GRCA may group or reorder SCF content for display, which does not change SCF content; the mappings are shown as links to the frameworks they name. Learn more at https://securecontrolsframework.com.

DE: GRCA enthält Inhalte des Secure Controls Framework® (SCF), © Secure Controls Framework Council, LLC, genutzt unter der Creative Commons Attribution-NoDerivatives 4.0 International Public License. Nummern, Namen, Beschreibungen und Zuordnungen der SCF-Controls erscheinen genau so, wie der SCF Council sie veröffentlicht – https://securecontrolsframework.com. GRCA gruppiert oder sortiert SCF-Inhalte für die Anzeige, ohne sie zu verändern; die Zuordnungen erscheinen als Verknüpfungen zu den genannten Regelwerken. Mehr unter https://securecontrolsframework.com.