+Artikel 31 Einstufung kritischer IKT-Drittdienstleister
---+Artikel 31 (1)
---+Artikel 31 (2)
---+Artikel 31 (3)
---+Artikel 31 (4)
---+Artikel 31 (5)
---+Artikel 31 (6)
---+Artikel 31 (7)
---+Artikel 31 (8)
---+Artikel 31 (9)
---+Artikel 31 (10)
---+Artikel 31 (11)
---+Artikel 31 (12)
---+Artikel 31 (13)
|
Artikel 31 Einstufung kritischer IKT-Drittdienstleister
-
1. Übersicht
| Bezeichnung |
Regulierung |
|
Artikel 31 (1)
|
Die ESA nehmen über den Gemeinsamen Ausschuss und auf Empfehlung des gemäß Artikel 32 Absatz 1 eingerichteten Überwachungsforums folgende Aufgaben wahr:
a)
Einstufung der IKT-Drittdienstleister, die für Finanzunternehmen kritisch sind, nachdem eine entsprechende Bewertung unter Berücksichtigung der in Absatz 2 genannten Kriterien durchgeführt wurde;
b)
Ernennung derjenigen Europäischen Aufsichtsbehörde zur federführenden Überwachungsbehörde für jeden kritischen IKT-Drittdienstleister, die gemäß den Verordnungen (EU) Nr. 1093/2010, (EU) Nr. 1094/2010 bzw. (EU) Nr. 1095/2010 für diejenigen Finanzunternehmen zuständig ist, die nachweislich der Summe der einzelnen Bilanzen dieser Finanzunternehmen zusammen den größten Anteil des Gesamtvermögens am Gesamtwert der Aktiva aller Finanzunternehmen halten, die die Dienste des betreffenden kritischen IKT-Drittdienstleisters nutzen.
|
|
Artikel 31 (2)
|
Die Einstufung nach Absatz 1 Buchstabe a basiert in Bezug auf IKT-Dienstleistungen, die vom IKT-Drittdienstleister bereitgestellt werden, auf den folgenden Kriterien:
a)
den systemischen Auswirkungen auf die Stabilität, Kontinuität oder Qualität der Erbringung von Finanzdienstleistungen, falls der betreffende IKT-Drittdienstleister bei der Erbringung seiner Dienste einer umfassenden Betriebsstörung ausgesetzt wäre, wobei die Zahl von Finanzunternehmen und der Gesamtwert der Aktiva derjenigen Finanzunternehmen zu berücksichtigen ist, für die der betreffende IKT-Drittdienstleister Dienstleistungen erbringt;
b)
dem systemischen Charakter oder der Bedeutung der Finanzunternehmen, die auf den jeweiligen IKT-Drittdienstleister zurückgreifen, bewertet anhand der folgenden Parameter:
i)
der Anzahl global systemrelevanter Institute (G-SRI) oder anderer systemrelevanter Institute (A-SRI), die auf den jeweiligen IKT-Drittdienstleister zurückgreifen;
ii)
der Interdependenz zwischen den unter Ziffer i genannten G-SRI oder A-SRI und anderen Finanzunternehmen, einschließlich der Fälle, in denen die G-SRI oder A-SRI Finanzinfrastrukturdienstleistungen für andere Finanzunternehmen erbringen;
c)
der Abhängigkeit von Finanzunternehmen von den Dienstleistungen des betreffenden IKT-Drittdienstleisters mit Blick auf kritische oder wichtige Funktionen von Finanzunternehmen, in die letztlich derselbe IKT-Drittdienstleister involviert ist — unabhängig davon, ob Finanzunternehmen diese Dienste direkt oder indirekt durch Vereinbarungen über die Unterauftragsvergabe in Anspruch nehmen;
d)
dem Grad der Substituierbarkeit des IKT-Drittdienstleisters unter Berücksichtigung der folgenden Parameter:
i)
des Mangels an echten, auch teilweisen Alternativen aufgrund der begrenzten Zahl von IKT-Drittdienstleistern, die auf einem bestimmten Markt tätig sind, oder des Marktanteils des betreffenden IKT-Drittdienstleisters oder der damit verbundenen technischen Komplexität oder Differenziertheit, auch in Bezug auf proprietäre Technologien, oder der besonderen Merkmale der Organisation oder Tätigkeit des IKT-Drittdienstleisters;
ii)
der Schwierigkeiten bei der teilweisen oder vollständigen Migration der einschlägigen Daten und Arbeitslasten vom jeweiligen IKT-Drittdienstleister zu einem anderen IKT-Drittdienstleister, die entweder auf erhebliche finanzielle Kosten, zeitliche oder sonstige Ressourcen, die der Migrationsprozess mit sich bringen kann, oder auf erhöhte IKT-Risiken oder sonstige operationelle Risiken zurückzuführen sind, denen das Finanzunternehmen durch eine solche Migration ausgesetzt sein könnte.
|
|
Artikel 31 (3)
|
Gehört der IKT-Drittdienstleister zu einer Gruppe, so werden die in Absatz 2 genannten Kriterien in Bezug auf die von der Gruppe als Ganzes bereitgestellten IKT-Dienstleistungen berücksichtigt.
|
|
Artikel 31 (4)
|
Kritische IKT-Drittdienstleister, die Teil einer Gruppe sind, benennen eine juristische Person als Koordinierungsstelle, um eine angemessene Vertretung und Kommunikation mit der federführenden Überwachungsbehörde sicherzustellen.
|
|
Artikel 31 (5)
|
Die federführende Überwachungsbehörde unterrichtet den IKT-Drittdienstleister über das Ergebnis der Bewertung, die zu der in Absatz 1 Buchstabe a genannten Einstufung geführt hat. Innerhalb von sechs Wochen ab dem Datum der Unterrichtung kann der IKT-Drittdienstleister der federführenden Überwachungsbehörde eine begründete Erklärung mit allen für die Zwecke der Bewertung relevanten Informationen übermitteln. Die federführende Überwachungsbehörde prüft die begründete Erklärung und kann verlangen, dass innerhalb von 30 Kalendertagen nach Eingang der Erklärung zusätzliche Informationen übermittelt werden. Nach der Einstufung eines IKT-Drittdienstleisters als kritisch, unterrichten die ESA den IKT-Drittdienstleister über den Gemeinsamen Ausschuss über diese Einstufung und das Anfangsdatum, ab dem er tatsächlich Überwachungstätigkeiten unterliegen wird. Dieses Anfangsdatum darf nicht mehr als einen Monat nach der Unterrichtung liegen. Der IKT-Drittdienstleister teilt den Finanzunternehmen, für die er Dienstleistungen erbringt, seine Einstufung als kritisch mit.
|
|
Artikel 31 (6)
|
Der Kommission wird die Befugnis übertragen, gemäß Artikel 57 einen delegierten Rechtsakt zu erlassen, um diese Verordnung durch die weitere Präzisierung der in Absatz 2 genannten Kriterien bis 17. Juli 2024 zu ergänzen.
|
|
Artikel 31 (7)
|
Die Einstufung nach Absatz 1 Buchstabe a darf erst angewendet werden, wenn die Kommission einen delegierten Rechtsakt gemäß Absatz 6 erlassen hat.
|
|
Artikel 31 (8)
|
Die Einstufung nach Absatz 1 Buchstabe a gilt nicht für:
i)
Finanzunternehmen, die IKT-Dienstleistungen für andere Finanzunternehmen bereitstellen;
ii)
IKT-Drittdienstleister, die Überwachungsrahmen unterliegen, die zur Unterstützung der in Artikel 127 Absatz 2 des Vertrags über die Arbeitsweise der Europäischen Union genannten Aufgaben eingerichtet wurden;
iii)
gruppeninterne IKT-Dienstleister;
iv)
IKT-Drittdienstleister, die IKT-Dienstleistungen ausschließlich in einem Mitgliedstaat für Finanzunternehmen bereitstellen, die nur in diesem Mitgliedstaat tätig sind.
|
|
Artikel 31 (9)
|
Die ESA erstellen, veröffentlichen und aktualisieren die Liste kritischer IKT-Drittdienstleister auf Unionsebene jährlich über den Gemeinsamen Ausschuss.
|
|
Artikel 31 (10)
|
Die zuständigen Behörden übermitteln dem gemäß Artikel 32 eingerichteten Überwachungsforum für die Zwecke von Absatz 1 Buchstabe a die in Artikel 28 Absatz 3 Unterabsatz 3 genannten Berichte auf jährlicher und aggregierter Basis. Das Überwachungsforum bewertet die Abhängigkeiten von Finanzunternehmen gegenüber IKT-Drittdienstleistern auf der Grundlage der von den zuständigen Behörden übermittelten Informationen.
|
|
Artikel 31 (11)
|
Diejenigen IKT-Drittdienstleister, die nicht in der in Absatz 9 genannten Liste aufgeführt sind, können beantragen, gemäß Absatz 1 Buchstabe a als kritisch eingestuft zu werden. Für die Zwecke von Unterabsatz 1 reicht der IKT-Drittdienstleister bei der EBA, der ESMA oder der EIOPA einen begründeten Antrag ein, die über den Gemeinsamen Ausschuss entscheiden, ob dieser IKT-Drittdienstleister gemäß Absatz 1 Buchstabe a als kritisch eingestuft werden soll. Die in Unterabsatz 2 genannte Entscheidung wird innerhalb von 6 Monaten nach Eingang des Antrags getroffen und dem IKT-Drittdienstleister mitgeteilt.
|
|
Artikel 31 (12)
|
Finanzunternehmen dürfen nur dann die Dienstleistungen eines IKT-Drittdienstleisters mit Sitz in einem Drittland in Anspruch nehmen, der gemäß Absatz 1 Buchstabe a als kritisch eingestuft worden ist, wenn er innerhalb von zwölf Monaten nach der Einstufung ein Tochterunternehmen in der Union gegründet hat.
|
|
Artikel 31 (13)
|
Der in Absatz 12 genannte kritische IKT-Drittdienstleister teilt der federführenden Überwachungsbehörde jede Änderung der Leitungsstruktur des in der Union niedergelassenen Tochterunternehmens mit.
|
,
1.1 Referenzen
1.2 Identifizierte Anforderungen
1.3 Zugehörige Standards
2. Identifizierte Anforderungen
Anforderungen
| Quelle |
Anforderung |
3. Zugehörige Standards
Standards
| Quelle |
Anforderung |
|
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.
|
|