+Artículo 31 Designación de proveedores terceros esenciales de servicios de TIC
---+Artículo 31 1
---+Artículo 31 2
---+Artículo 31 3
---+Artículo 31 4
---+Artículo 31 5
---+Artículo 31 6
---+Artículo 31 7
---+Artículo 31 8
---+Artículo 31 9
---+Artículo 31 10
---+Artículo 31 11
---+Artículo 31 12
---+Artículo 31 13
|
Artículo 31 Designación de proveedores terceros esenciales de servicios de TIC
-
1. Resumen
| Título |
Regulación |
|
Artículo 31 1
|
1. Las Autoridades Europeas de Supervisión, a través del Comité Mixto y por recomendación del Foro de Supervisión establecido en virtud del artículo 32, apartado 1, deberán:
|
a)
|
designar a los proveedores terceros de servicios de TIC que sean esenciales para las entidades financieras, tras una evaluación que tenga en cuenta los criterios especificados en el apartado 2;
|
|
b)
|
nombrar como supervisor principal para cada proveedor tercero esencial de servicios de TIC a la Autoridad Europea de Supervisión que sea responsable, de conformidad con los Reglamentos (UE) n.o 1093/2010, (UE) n.o 1094/2010 o (UE) n.o 1095/2010, para las entidades financieras que tengan conjuntamente la parte más grande de activos totales del valor de activos totales de todas las entidades financieras que utilizan los servicios del proveedor tercero esencial de servicios de TIC pertinente, según conste en la suma de los balances particulares de dichas entidades financieras.
|
|
|
Artículo 31 2
|
2. La designación a que se refiere el apartado 1, letra a), se basará en todos los criterios siguientes en relación con los servicios de TIC prestados por el proveedor tercero de servicios de TIC:
|
a)
|
el impacto sistémico en la estabilidad, la continuidad o la calidad de la prestación de servicios financieros en caso de un posible fallo operativo a gran escala del proveedor tercero de servicios de TIC de que se trate que afecte a la prestación de sus servicios, teniendo en cuenta el número de entidades financieras y el valor total de los activos de las entidades financieras a las que presta servicios el proveedor tercero de servicios de TIC de que se trate;
|
|
b)
|
el carácter o la importancia sistémicos de las entidades financieras que dependen del proveedor tercero de servicios de TIC de que se trate, evaluados con arreglo a los parámetros siguientes:
|
i)
|
el número de entidades de importancia sistémica mundial (EISM) u otras entidades de importancia sistémica (OEIS) que dependen del proveedor tercero de servicios de TIC correspondiente,
|
|
ii)
|
la interdependencia entre las EISM u OEIS a que se refiere el inciso i) y otras entidades financieras, incluidas las situaciones en las que las EISM u OEIS prestan servicios de infraestructura financiera a otras entidades financieras;
|
|
|
c)
|
la dependencia de las entidades financieras respecto de los servicios prestados por el proveedor tercero de servicios de TIC pertinente en relación con funciones esenciales o importantes de entidades financieras que, en última instancia, impliquen al mismo proveedor tercero de servicios de TIC, con independencia de que las entidades financieras recurran a dichos servicios directa o indirectamente, a través de acuerdos de subcontratación;
|
|
d)
|
el grado de sustituibilidad del proveedor tercero de servicios de TIC, teniendo en cuenta los parámetros siguientes:
|
i)
|
la falta de alternativas reales, siquiera parciales, debido al número limitado de proveedores terceros de servicios de TIC activos en un mercado específico, o a la cuota de mercado del proveedor tercero de servicios de TIC de que se trate, o a la complejidad o dificultad técnica existente, entre otras cosas en relación con tecnologías protegidas por derechos, o a las características específicas de la organización o la actividad del proveedor tercero de servicios de TIC,
|
|
ii)
|
las dificultades relacionadas con la migración parcial o total de los datos y cargas de trabajo pertinentes del proveedor tercero de servicios de TIC en cuestión a otro, al ser considerables los costes financieros, el tiempo u otros recursos que el proceso de migración podría implicar, o debido al aumento del riesgo de TIC o de otros riesgos operativos a los que podría verse expuesta la entidad financiera a través de dicha migración.
|
|
|
|
Artículo 31 3
|
3. Cuando el proveedor tercero de servicios de TIC pertenezca a un grupo, los criterios a que se refiere el apartado 2 se tendrán en cuenta en relación con los servicios de TIC prestados por el grupo en su conjunto.
|
|
Artículo 31 4
|
4. Los proveedores terceros esenciales de servicios de TIC que formen parte de un grupo designarán a una persona jurídica como punto de coordinación para garantizar una representación y una comunicación adecuadas con el supervisor principal.
|
|
Artículo 31 5
|
5. El supervisor principal notificará al proveedor tercero de servicios de TIC el resultado de la evaluación previa a la designación a que se refiere el apartado 1, letra a). En el plazo de seis semanas a partir de la fecha de la notificación, el proveedor tercero de servicios de TIC podrá presentar al supervisor principal una declaración motivada con cualquier información pertinente a efectos de la evaluación. El supervisor principal considerará la declaración motivada y podrá solicitar que se presente información adicional en un plazo de treinta días naturales a partir de la recepción de dicha declaración.
Tras designar a un proveedor tercero de servicios de TIC como esencial, las Autoridades Europeas de Supervisión, a través del Comité Mixto, notificarán al proveedor tercero de servicios de TIC dicha designación y la fecha de inicio a partir de la cual será efectivamente objeto de actividades de supervisión. Dicha fecha de inicio no será posterior en más de un mes a la notificación. El proveedor tercero de servicios de TIC notificará a las entidades financieras a las que presta servicios su designación como esencial.
|
|
Artículo 31 6
|
6. Se otorgan a la Comisión los poderes para adoptar un acto delegado, de conformidad con el artículo 57, para completar el presente Reglamento especificando con más detalle los criterios mencionados en el apartado 2 del presente artículo, a más tardar el 17 de julio de 2024.
|
|
Artículo 31 7
|
7. La designación a que se refiere el apartado 1, letra a), no se utilizará hasta que la Comisión haya adoptado un acto delegado de conformidad con el apartado 6.
|
|
Artículo 31 8
|
8. La designación a que se refiere el apartado 1, letra a), no se aplicará a:
|
i)
|
las entidades financieras que presten servicios de TIC a otras entidades financieras,
|
|
ii)
|
los proveedores terceros de servicios de TIC que estén sujetos a marcos de supervisión establecidos en apoyo de las tareas a que se refiere el artículo 127, apartado 2, del TFUE,
|
|
iii)
|
los proveedores intragrupo de servicios de TIC,
|
|
iv)
|
los proveedores terceros de servicios de TIC que presten servicios de TIC únicamente en un Estado miembro a entidades financieras que operan exclusivamente en ese Estado miembro.
|
|
|
Artículo 31 9
|
9. Las Autoridades Europeas de Supervisión, a través del Comité Mixto, establecerán, publicarán y actualizarán anualmente la lista de proveedores terceros esenciales de servicios de TIC a escala de la Unión.
|
|
Artículo 31 10
|
10. A efectos de lo dispuesto en el apartado 1, letra a), las autoridades competentes transmitirán anualmente y de forma agregada los informes a que se refiere el artículo 28, apartado 3, párrafo tercero, al Foro de Supervisión establecido en virtud del artículo 32. El Foro de Supervisión evaluará las dependencias de terceros en el ámbito de las TIC de las entidades financieras basándose en la información recibida de las autoridades competentes.
|
|
Artículo 31 11
|
11. Los proveedores terceros de servicios de TIC que no estén incluidos en la lista a que se refiere el apartado 9 podrán solicitar ser designados como esenciales de conformidad con el apartado 1, letra a).
A efectos de lo dispuesto en el párrafo primero, el proveedor tercero de servicios de TIC presentará una solicitud motivada a la ABE, la AEVM o la AESPJ que, a través del Comité Mixto, decidirán si lo designan o no como esencial de conformidad con el apartado 1, letra a).
La decisión a que se refiere el párrafo segundo se adoptará y notificará al proveedor tercero de servicios de TIC en un plazo de seis meses a partir de la recepción de la solicitud.
|
|
Artículo 31 12
|
12. Las entidades financieras solo recurrirán a los servicios de un proveedor tercero de servicios de TIC establecido en un tercer país y que haya sido designado como esencial de conformidad con el apartado 1, letra a), si este último ha establecido una filial en la Unión en los 12 meses siguientes a la designación.
|
|
Artículo 31 13
|
13. El proveedor tercero esencial de servicios de TIC a que se refiere el apartado 12 notificará al supervisor principal cualquier cambio en la estructura de la dirección de la filial establecida en la Unión.
|
,
1.1 Referencias
1.2 Requisitos identificados
1.3 Estándares relacionados
2. Requisitos identificados
Requisitos
| Fuente |
Requisito |
3. Estándares relacionados
Estándares
| Fuente |
Requisito |
|
SCF
|
Contacts With Authorities
Description
Mechanisms exist to identify and document appropriate contacts with relevant law enforcement and regulatory bodies.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ Documented list of law enforcement and regulatory contacts (FBI, CISA, state AG) ∙ MS-ISAC free membership (https://www.cisecurity.org/ms-isac)
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Documented contacts with FBI Cyber Division, CISA, and relevant regulators ∙ MS-ISAC or sector-specific ISAC membership ∙ Pre-established law enforcement liaisons for incident response
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Integrated Security Incident Response Team (ISIRT) with defined authority contacts ∙ CISA Cyber Liaison and FBI Cyber Division contacts ∙ Sector ISAC membership (e.g., FS-ISAC, H-ISAC, E-ISAC) ∙ Regulatory notification contact list (e.g., FTC, OCR, state regulators)
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Integrated Security Incident Response Team (ISIRT) with pre-established authority relationships ∙ Formal engagement with law enforcement (FBI, USSS, CISA) ∙ Sector ISAC active membership with information sharing participation ∙ Regulatory breach notification contacts and documented procedures
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Dedicated government liaison program (FBI, CISA, NSA, sector regulators) ∙ Active ISAC membership with classified threat briefing access (where applicable) ∙ Pre-established breach notification workflows for all applicable regulators ∙ Integrated Security Incident Response Team (ISIRT) with 24/7 law enforcement contact protocols
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. ▪ Cybersecurity personnel identify and maintain contact information for local and national law enforcement (e.g., FBI field office) in case of cybersecurity incidents that require law enforcement involvement.
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.
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 identify and document appropriate contacts with relevant law enforcement and regulatory bodies.
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
|
Third-Party Management
Description
Mechanisms exist to facilitate the implementation of third-party management controls.
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
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program ∙ Product / project management
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program ∙ Product / project management
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program ∙ Product / project management
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program ∙ Product / project 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
Third-Party Management (TPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with TPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Third-party management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ No centralized inventory of External Service Providers (ESP) is maintained. ▪ ESP are not formally managed according to criticality.
Level 2 Planned Tracked
Third-Party Management (TPM) 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 TPM domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with TPM 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Third-party management-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.
Level 3 Well Defined
Third-Party Management (TPM) 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 TPM 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 TPM domain capabilities are well-documented and kept current by process owners. ▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution and vendor 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 TPM 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 third-party management controls.
Level 4 Quantitatively Controlled
Third-Party Management (TPM) 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
|
Third-Party Management
Description
Mechanisms exist to facilitate the implementation of third-party management controls.
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
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program ∙ Product / project management
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program ∙ Product / project management
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program ∙ Product / project management
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program ∙ Product / project 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
Third-Party Management (TPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with TPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Third-party management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ No centralized inventory of External Service Providers (ESP) is maintained. ▪ ESP are not formally managed according to criticality.
Level 2 Planned Tracked
Third-Party Management (TPM) 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 TPM domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with TPM 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Third-party management-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.
Level 3 Well Defined
Third-Party Management (TPM) 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 TPM 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 TPM domain capabilities are well-documented and kept current by process owners. ▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution and vendor 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 TPM 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 third-party management controls.
Level 4 Quantitatively Controlled
Third-Party Management (TPM) 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
|
Third-Party Management
Description
Mechanisms exist to facilitate the implementation of third-party management controls.
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
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program ∙ Product / project management
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program ∙ Product / project management
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program ∙ Product / project management
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program ∙ Product / project 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
Third-Party Management (TPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include: ▪ Policies, standards & procedures associated with TPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation. ▪ Third-party management-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices. ▪ No centralized inventory of External Service Providers (ESP) is maintained. ▪ ESP are not formally managed according to criticality.
Level 2 Planned Tracked
Third-Party Management (TPM) 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 TPM domain capabilities are formally documented and centrally-managed by the entity. ▪ Standardized Operating Procedures (SOP) associated with TPM 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 TPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD). ▪ Third-party management-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.
Level 3 Well Defined
Third-Party Management (TPM) 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 TPM 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 TPM domain capabilities are well-documented and kept current by process owners. ▪ A procurement team, or similar function, is appropriately staffed and supported to implement and maintain TPM domain capabilities. ▪ Technology is leveraged to enhance the efficiency and accuracy of third-party management operations (e.g., TPRM risk management solution and vendor 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 TPM 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 third-party management controls.
Level 4 Quantitatively Controlled
Third-Party Management (TPM) 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.
|
|