+Articolul 31 Desemnarea furnizorilor terți esențiali de servicii TIC
---+Articolul 31 (1)
---+Articolul 31 (2)
---+Articolul 31 (3)
---+Articolul 31 (4)
---+Articolul 31 (5)
---+Articolul 31 (6)
---+Articolul 31 (7)
---+Articolul 31 (8)
---+Articolul 31 (9)
---+Articolul 31 (10)
---+Articolul 31 (11)
---+Articolul 31 (12)
---+Articolul 31 (13)
|
Articolul 31 Desemnarea furnizorilor terți esențiali de servicii TIC
1. Prezentare generală
| Titlu |
Reglementare |
|
Articolul 31 (1)
|
AES, prin intermediul Comitetului comun și la recomandarea Forumului de supraveghere instituit în temeiul articolului 32 alineatul (1):
(a)
desemnează furnizorii terți de servicii TIC care sunt esențiali pentru entitățile financiare, în urma unei evaluări care ține seama de criteriile menționate la alineatul (2);
(b)
desemnează drept supraveghetor principal pentru fiecare furnizor terț esențial de servicii TIC acea AES care este responsabilă, în conformitate cu Regulamentul (UE) nr. 1093/2010, (UE) nr. 1094/2010 sau (UE) nr. 1095/2010, de entitățile financiare care dețin împreună cea mai mare parte a activelor totale din valoarea activelor totale ale tuturor entităților financiare care utilizează serviciile furnizorului terț esențial de servicii TIC relevant, astfel cum reiese din suma bilanțurilor individuale ale entităților financiare respective.
|
|
Articolul 31 (2)
|
Desemnarea prevăzută la alineatul (1) litera (a) se bazează pe toate criteriile următoare în ceea ce privește serviciile TIC furnizate de furnizorul terț de servicii TIC:
(a)
impactul sistemic asupra stabilității, continuității sau calității furnizării serviciilor financiare în situația în care furnizorul terț de servicii TIC relevant s-ar confrunta cu o defecțiune operațională la scară largă în ceea ce privește furnizarea serviciilor sale, ținând seama de numărul de entități financiare și de valoarea totală a activelor entităților financiare cărora furnizorul terț de servicii TIC relevant le oferă servicii;
(b)
caracterul sistemic sau importanța entităților financiare care se bazează pe furnizorul terț de servicii TIC relevant, evaluată în conformitate cu următorii parametri:
(i)
numărul de instituții de importanță sistemică globală (G-SII) sau de alte instituții de importanță sistemică (O-SII) care se bazează pe respectivul furnizor terț de servicii TIC;
(ii)
interdependența dintre G-SII sau O-SII menționate la punctul (i) și alte entități financiare, inclusiv situațiile în care G-SII sau O-SII furnizează servicii de infrastructură financiară altor entități financiare;
(c)
dependența entităților financiare de serviciile furnizate de furnizorul terț de servicii TIC relevant în ceea ce privește funcțiile critice sau importante ale entităților financiare care implică, în ultimă instanță, același furnizor terț de servicii TIC, indiferent dacă entitățile financiare se bazează direct sau indirect pe aceste servicii, prin intermediul unor acorduri de subcontractare;
(d)
gradul de substituibilitate a furnizorului terț de servicii TIC, ținând seama de următorii parametri:
(i)
lipsa unor alternative reale, chiar și parțiale, având în vedere numărul limitat de furnizori terți de servicii TIC activi pe o anumită piață sau cota de piață deținută de furnizorul terț de servicii TIC relevant sau complexitatea tehnică ori gradul de sofisticare implicat, inclusiv în ceea ce privește orice tehnologie protejată, sau caracteristicile specifice ale modului de organizare sau ale activității furnizorului terț de servicii TIC;
(ii)
dificultăți în ceea ce privește migrarea parțială sau integrală a datelor și a volumelor de lucru relevante de la furnizorul terț de servicii TIC relevant către un alt furnizor terț de servicii TIC, fie ca urmare a costurilor financiare semnificative, a timpului sau a altor resurse pe care le poate implica procesul de migrare, fie din cauza unor riscuri TIC sporite sau a altor riscuri operaționale la care poate fi expusă entitatea financiară prin intermediul unei astfel de migrări.
|
|
Articolul 31 (3)
|
În cazul în care furnizorul terț de servicii TIC face parte dintr-un grup, criteriile menționate la alineatul (2) sunt examinate în raport cu serviciile TIC furnizate de grup în ansamblul său.
|
|
Articolul 31 (4)
|
Furnizorii terți esențiali de servicii TIC care fac parte dintr-un grup desemnează o persoană juridică drept punct de coordonare pentru a asigura în mod adecvat reprezentarea și comunicarea cu supraveghetorul principal.
|
|
Articolul 31 (5)
|
Supraveghetorul principal notifică furnizorului terț de servicii TIC rezultatul evaluării care a dus la desemnarea menționată la alineatul (1) litera (a). În termen de șase săptămâni de la data notificării, furnizorul terț de servicii TIC îi poate transmite supraveghetorului principal o declarație motivată conținând orice informații relevante în scopul evaluării. Supraveghetorul principal analizează declarația motivată și poate solicita să îi fie furnizate informații suplimentare în termen de 30 de zile calendaristice de la primirea unei astfel de declarații. După ce a desemnat un furnizor terț de servicii TIC ca fiind esențial, AES, prin intermediul Comitetului comun, informează furnizorul terț de servicii TIC cu privire la această desemnare și cu privire la data de la care va începe să facă efectiv obiectul activităților de supraveghere. Data respectivă trebuie să fie la cel mult o lună de la momentul notificării. Furnizorul terț de servicii TIC informează entitățile financiare cărora le furnizează servicii cu privire la desemnarea sa drept esențial.
|
|
Articolul 31 (6)
|
Comisia este împuternicită să adopte un act delegat în conformitate cu articolul 57 pentru a completa prezentul regulament prin precizarea mai în detaliu a criteriilor menționate la alineatul (2) de la prezentul articol, până la 17 iulie 2024.
|
|
Articolul 31 (7)
|
Nu se recurge la desemnarea menționată la alineatul (1) litera (a) decât după ce Comisia a adoptat un act delegat în conformitate cu alineatul (6).
|
|
Articolul 31 (8)
|
Desemnarea menționată la alineatul (1) litera (a) nu se aplică în ceea ce privește:
(i)
entitățile financiare care furnizează servicii TIC altor entități financiare;
(ii)
furnizorii terți de servicii TIC care fac obiectul unor cadre de supraveghere instituite cu scopul de a sprijini misiunile menționate la articolul 127 alineatul (2) din Tratatul privind funcționarea Uniunii Europene;
(iii)
furnizorii de servicii TIC intragrup;
(iv)
furnizorii terți de servicii TIC care furnizează servicii TIC numai într-un stat membru unor entități financiare care își desfășoară activitatea numai în statul membru respectiv.
|
|
Articolul 31 (9)
|
AES, prin intermediul Comitetului comun, elaborează, publică și actualizează anual lista furnizorilor terți esențiali de servicii TIC la nivelul Uniunii.
|
|
Articolul 31 (10)
|
În sensul alineatului (1) litera (a), autoritățile competente transmit, anual și agregat, Forumului de supraveghere instituit în temeiul articolului 32 rapoartele menționate la articolul 28 alineatul (3) al treilea paragraf. Forumul de supraveghere evaluează dependențele entităților financiare față de furnizorii terți de servicii TIC pe baza informațiilor primite de la autoritățile competente.
|
|
Articolul 31 (11)
|
Furnizorii terți de servicii TIC care nu sunt incluși în lista menționată la alineatul (9) pot solicita să fie desemnați ca fiind esențiali în conformitate cu alineatul (1) litera (a). În scopul aplicării primului paragraf, furnizorul terț de servicii TIC transmite o cerere motivată către ABE, ESMA sau EIOPA care, prin intermediul Comitetului comun, decide dacă să desemneze respectivul furnizor terț de servicii TIC ca fiind esențial în conformitate cu alineatul (1) litera (a). Decizia menționată la al doilea paragraf se adoptă și se notifică furnizorului terț de servicii TIC în termen de șase luni de la primirea cererii.
|
|
Articolul 31 (12)
|
Entitățile financiare utilizează serviciile unui furnizor terț de servicii TIC stabilit într-o țară terță și care a fost desemnat ca fiind esențial în conformitate cu alineatul (1) litera (a) numai în cazul în care acesta din urmă a înființat o filială în Uniune în termen de 12 luni de la desemnare.
|
|
Articolul 31 (13)
|
Furnizorul terț esențial de servicii TIC menționat la alineatul (12) informează supraveghetorul principal cu privire la orice modificare a structurii conducerii filialei înființate în Uniune.
|
,
1.1 Referințe
1.2 Cerințe identificate
1.3 Standarde asociate
2. Cerințe identificate
3. Standarde asociate
Standarde
| Sursă |
Cerință |
|
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.
|
|