+Artikel 31 Klassificering av tredjepartsleverantörer av IKT-tjänster som kritiska
---+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 Klassificering av tredjepartsleverantörer av IKT-tjänster som kritiska
-
1. Översikt
| Rubrik |
Reglering |
|
Artikel 31 1
|
1. De europeiska tillsynsmyndigheterna ska, genom den gemensamma kommittén och på rekommendation av det tillsynsforum som har inrättats enligt artikel 32.1,
|
a)
|
klassificera tredjepartsleverantörer av IKT-tjänster som kritiska för finansiella entiteter, efter en bedömning som tar hänsyn till de kriterier som anges i punkt 2,
|
|
b)
|
utse till ledande tillsynsmyndighet för varje kritisk tredjepartsleverantör av IKT-tjänster den europeiska tillsynsmyndighet som är ansvarig enligt förordningarna (EU) nr 1093/2010, (EU) nr 1094/2010 eller (EU) nr 1095/2010 för de finansiella entiteter som tillsammans har den största andelen av de totala tillgångarna av värdet av de totala tillgångarna hos alla finansiella entiteter som utnyttjar tjänster från den relevanta kritiska tredjepartsleverantören av IKT-tjänster, i enlighet med vad som framgår av summan av dessa finansiella entiteters enskilda balansräkningar.
|
|
|
Artikel 31 2
|
2. Den klassificering som avses i punkt 1 a ska baseras på samtliga följande kriterier när det gäller IKT-tjänster som tillhandahålls av tredjepartsleverantören av IKT-tjänster:
|
a)
|
Systempåverkan på stabiliteten, kontinuiteten eller kvaliteten på tillhandahållandet av finansiella tjänster om den berörda tredjepartsleverantören av IKT-tjänster skulle drabbas av ett omfattande driftsavbrott i tillhandahållandet av tjänster, med tanke på antalet finansiella entiteter och det totala värdet av tillgångarna hos de finansiella entiteter som den berörda tredjepartsleverantören av IKT-tjänster tillhandahåller tjänster till.
|
|
b)
|
Påverkan på eller betydelsen för systemet av de finansiella entiteter som är beroende av den berörda tredjepartsleverantören av IKT-tjänster, bedömt enligt följande parametrar:
|
i)
|
Antalet globala systemviktiga institut eller andra systemviktiga institut som är beroende av respektive tredjepartsleverantör av IKT-tjänster.
|
|
ii)
|
Det ömsesidiga beroendet mellan de globala systemviktiga institut eller andra systemviktiga institut som avses i led i och andra finansiella entiteter, inbegripet situationer där de globala systemviktiga instituten eller andra systemviktiga instituten tillhandahåller finansiella infrastrukturtjänster till andra finansiella entiteter.
|
|
|
c)
|
Finansiella entiteters beroende av de tjänster som tillhandahålls av den berörda tredjepartsleverantören av IKT-tjänster i förhållande till kritiska eller viktiga funktioner hos de finansiella entiteter som i sista hand involverar samma tredjepartsleverantör av IKT-tjänster, oavsett om finansiella entiteter direkt eller indirekt är beroende av dessa tjänster, med hjälp av eller genom underleverantörsavtal.
|
|
d)
|
Graden av utbytbarhet hos tredjepartsleverantören av IKT-tjänster, med beaktande av följande parametrar:
|
i)
|
Avsaknad av verkliga alternativ, även delvis, på grund av det begränsade antalet tredjepartsleverantörer av IKT-tjänster som är verksamma på en viss marknad, eller marknadsandelen för den berörda tredjepartsleverantören av IKT-tjänster, eller den tekniska komplexiteten eller avancerade karaktären, inbegripet i förhållande till eventuell proprietär teknik, eller särdragen hos IKT-tredjepartsleverantörens organisation eller verksamhet.
|
|
ii)
|
Svårigheter när det gäller att helt eller delvis migrera relevanta data och arbetsbelastningar från den berörda tredjepartsleverantören av IKT-tjänster till en annan tredjepartsleverantör av IKT-tjänster, på grund av betydande finansiella kostnader, tidsåtgång eller andra resurser som migrationsprocessen kan medföra, eller på grund av ökad IKT-risk eller andra operativa risker som den finansiella entiteten kan utsättas för genom sådan migration.
|
|
|
|
Artikel 31 3
|
3. Om tredjepartsleverantören av IKT-tjänster ingår i en koncern ska de kriterier som avses i punkt 2 beaktas vad avser de IKT-tjänster som koncernen som helhet tillhandahåller.
|
|
Artikel 31 4
|
4. Kritiska tredjepartsleverantörer av IKT-tjänster som ingår i en koncern ska utse en juridisk person till samordningspunkt för att säkerställa lämplig representation och kommunikation med den ledande tillsynsmyndigheten.
|
|
Artikel 31 5
|
5. Den ledande tillsynsmyndigheten ska underrätta tredjepartsleverantören av IKT-tjänster om resultatet av den bedömning som leder till den klassificering som avses i punkt 1 a. Inom sex veckor från dagen för anmälan får tredjepartsleverantören av IKT-tjänster lämna in ett motiverat uttalande till den ledande tillsynsmyndigheten med all relevant information för bedömningen. Den ledande tillsynsmyndigheten ska beakta det motiverade uttalandet och får begära att ytterligare information lämnas inom 30 kalenderdagar efter mottagandet av ett sådant uttalande.
Efter att ha klassificerat en tredjepartsleverantör av IKT-tjänster som kritisk ska de europeiska tillsynsmyndigheterna, genom den gemensamma kommittén, underrätta tredjepartsleverantören av IKT-tjänster om klassificeringen och från och med vilket datum tredjepartsleverantören faktiskt kommer att omfattas av tillsynsverksamhet. Detta startdatum ska inträffa senast en månad efter anmälan. Tredjepartsleverantören av IKT-tjänster ska underrätta de finansiella entiteter som den tillhandahåller tjänster om att den klassificeras som kritisk.
|
|
Artikel 31 6
|
6. Kommissionen ges befogenhet att anta en delegerad akt i enlighet med artikel 57 för att komplettera denna förordning genom att närmare specificera kriterierna i punkt 2 i den här artikeln senast den 17 juli 2024.
|
|
Artikel 31 7
|
7. Den klassificering som avses i punkt 1 a får inte användas förrän kommissionen har antagit en delegerad akt i enlighet med punkt 6.
|
|
Artikel 31 8
|
8. Den klassificering som avses i punkt 1 a får inte tillämpas på följande:
|
i)
|
Finansiella entiteter som tillhandahåller IKT-tjänster till andra finansiella entiteter.
|
|
ii)
|
Tredjepartsleverantörer av IKT-tjänster som omfattas av tillsynsramar som har inrättats till stöd för de uppgifter som avses i artikel 127.2 i fördraget om Europeiska unionens funktionssätt.
|
|
iii)
|
Koncerninterna IKT-tjänsteleverantörer.
|
|
iv)
|
Tredjepartsleverantörer av IKT-tjänster som endast tillhandahåller IKT-tjänster i en medlemsstat till finansiella entiteter som endast är verksamma i den medlemsstaten.
|
|
|
Artikel 31 9
|
9. De europeiska tillsynsmyndigheterna ska genom den gemensamma kommittén upprätta, offentliggöra och årligen uppdatera förteckningen över kritiska tredjepartsleverantörer av IKT-tjänster på unionsnivå.
|
|
Artikel 31 10
|
10. Vid tillämpning av punkt 1 a ska de behöriga myndigheterna årligen och i aggregerad form översända de rapporter som avses i artikel 28.3 tredje stycket till det tillsynsforum som har inrättats enligt artikel 32. Tillsynsforumet ska bedöma finansiella entiteters IKT-beroende gentemot tredjepart baserat på den information som har mottagits från de behöriga myndigheterna.
|
|
Artikel 31 11
|
11. De tredjepartsleverantörer av IKT-tjänster som inte ingår i den förteckning som avses i punkt 9 får begära att bli klassificerade som kritiska i enlighet med punkt 1 a.
Vid tillämpning av första stycket ska tredjepartsleverantören av IKT-tjänster lämna in en motiverad ansökan till EBA, Esma eller Eiopa, som genom den gemensamma kommittén ska besluta huruvida den tredjepartsleverantören av IKT-tjänster ska klassificeras som kritisk i enlighet med punkt 1 a.
Det beslut som avses i andra stycket ska antas och meddelas tredjepartsleverantören av IKT-tjänster inom sex månader från mottagandet av ansökan.
|
|
Artikel 31 12
|
12. Finansiella entiteter ska endast använda sig av de tjänster som en tredjepartsleverantör av IKT-tjänster som är etablerad i ett tredjeland och som har klassificerats som kritisk i enlighet med punkt 1 a erbjuder om den har etablerat ett dotterföretag i unionen inom tolv månader efter klassificeringen.
|
|
Artikel 31 13
|
13. Den kritiska tredjepartsleverantör av IKT-tjänster som avses i punkt 12 ska underrätta den ledande tillsynsmyndigheten om eventuella ändringar av ledningsstrukturen för det dotterföretag som är etablerat i unionen.
|
,
1.1 Referenser
1.2 Identifierade krav
1.3 Relaterade standarder
2. Identifierade krav
3. Relaterade standarder
Standarder
| Källa |
Krav |
|
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.
|
|