+31. cikk A kritikus harmadik fél IKT-szolgáltatók kijelölése
---+31. cikk (1)
---+31. cikk (2)
---+31. cikk (3)
---+31. cikk (4)
---+31. cikk (5)
---+31. cikk (6)
---+31. cikk (7)
---+31. cikk (8)
---+31. cikk (9)
---+31. cikk (10)
---+31. cikk (11)
---+31. cikk (12)
---+31. cikk (13)
|
31. cikk A kritikus harmadik fél IKT-szolgáltatók kijelölése
1. Áttekintés
| Megnevezés |
Szabályozás |
|
31. cikk (1)
|
Az EFH-k a vegyes bizottság keretében, a 32. cikk (1) bekezdése alapján létrehozott felvigyázási fórum ajánlása alapján:
a)
kijelölik azon harmadik fél IKT-szolgáltatókat, amelyek – a (2) bekezdésben meghatározott kritériumok figyelembevételével végzett értékelés nyomán – a pénzügyi szervezetek számára kritikusak;
b)
a kritikus harmadik fél IKT-szolgáltatók mindegyikére vonatkozóan azon EFH-t nevezik ki vezető felvigyázóként, amely – az 1093/2010/EU, az 1094/2010/EU vagy az 1095/2010/EU rendeletnek megfelelően – azon pénzügyi szervezetekért felelős, amelyek teljes eszközértéke együttesen – amint azt az említett pénzügyi szervezetek egyedi mérlegeinek összesítése tanúsítja – a legnagyobb részt teszi ki a releváns kritikus harmadik fél IKT-szolgáltató szolgáltatásait igénybe vevő valamennyi pénzügyi szervezet teljes eszközértékén belül.
|
|
31. cikk (2)
|
Az (1) bekezdés a) pontjában említett kijelölésnek a harmadik fél IKT-szolgáltató által nyújtott IKT-szolgáltatásokkal kapcsolatban a következő kritériumokon kell alapulnia:
a)
azon rendszerszintű hatás, amely a pénzügyi szolgáltatások nyújtásának stabilitását, folytonosságát vagy minőségét érné akkor, ha a releváns harmadik fél IKT-szolgáltató kiterjedt működési hiányosság miatt nem képes a szolgáltatásait nyújtani, figyelembe véve azon pénzügyi szervezetek számát, valamint azon pénzügyi szervezetek eszközeinek összértékét, amelyek részére a harmadik fél IKT-szolgáltató szolgáltatásokat nyújt;
b)
a releváns harmadik fél IKT-szolgáltató szolgáltatásait igénybe vevő pénzügyi szervezetek rendszerszintű jellege vagy fontossága, a következő paraméterekkel összhangban értékelve:
i.
a vonatkozó harmadik fél IKT-szolgáltató szolgáltatásait igénybe vevő, globális rendszerszinten jelentős intézmények vagy egyéb rendszerszinten jelentős intézmények száma;
ii.
az i. alpontban említett globális rendszerszinten jelentős intézmények és egyéb rendszerszinten jelentős intézmények kölcsönös függése, beleértve azon helyzeteket is, amikor a globális rendszerszinten jelentős intézmények és egyéb rendszerszinten jelentős intézmények más pénzügyi szervezetek részére nyújtanak pénzügyi infrastrukturális szolgáltatásokat;
c)
a releváns harmadik fél IKT-szolgáltató által nyújtott szolgáltatások igénybevétele a pénzügyi szervezetek olyan kritikus vagy fontos funkciói kapcsán, amelyek ellátására végső soron ugyanezen harmadik fél IKT-szolgáltató közreműködésével kerül sor függetlenül attól, hogy a pénzügyi szervezetek az említett szolgáltatásokat közvetlenül vagy közvetetten, alvállalkozási megállapodások útján veszik-e igénybe;
d)
a harmadik fél IKT-szolgáltató helyettesíthetőségének mértéke, a következő paraméterek figyelembevételével:
i.
valós – legalább részleges – alternatívák hiánya, amely egy konkrét piacon működő harmadik fél IKT-szolgáltatók korlátozott számának, a releváns harmadik fél IKT-szolgáltató piaci részesedésének, vagy a megoldás technikai összetettségének vagy fejlettségének tulajdonítható, többek között bármely szabadalmaztatott technológia, vagy a harmadik fél IKT-szolgáltató szervezeti felépítésének vagy tevékenységének egyedi jellemzői kapcsán;
ii.
a releváns adatoknak és munkamennyiségnek a releváns harmadik fél IKT-szolgáltatótól egy másik harmadik fél IKT- szolgáltatóhoz történő részleges vagy teljes migrálásával járó nehézségek, amelyek okai lehetnek vagy a migrálási folyamattal esetleg együttjáró jelentős pénzügyi költségek, idő- vagy egyéb erőforrásigény, vagy azon megnövekedett IKT-kockázat vagy egyéb működési kockázatok, amelyeknek a pénzügyi szervezet ki lehet téve az ilyen migráció révén.
|
|
31. cikk (3)
|
Amennyiben a harmadik fél IKT-szolgáltató egy csoporthoz tartozik, a (2) bekezdésben említett kritériumokat a csoport egésze által nyújtott IKT-szolgáltatások tekintetében kell figyelembe venni.
|
|
31. cikk (4)
|
A csoport részét képező harmadik fél IKT-szolgáltatóknak koordinációs pontként ki kell jelölniük egy jogi személyt a megfelelő képviselet és a vezető felvigyázóval való kommunikáció biztosítása érdekében.
|
|
31. cikk (5)
|
A vezető felvigyázónak értesítenie kell a harmadik fél IKT-szolgáltatót az (1) bekezdés a) pontjában említett kijelöléshez vezető értékelés eredményéről. Az értesítés időpontjától számított 6 héten belül a harmadik fél IKT-szolgáltató indokolással ellátott nyilatkozatot nyújthat be a vezető felvigyázónak, amely tartalmazza az értékelés céljából releváns információkat. A vezető felvigyázónak meg kell vizsgálnia az indokolással ellátott nyilatkozatot, és az ilyen nyilatkozat kézhezvételétől számított 30 naptári napon belül további információk benyújtását kérheti. Miután egy harmadik fél IKT-szolgáltatót kritikusnak jelöltek ki, az EFH-knak a vegyes bizottságon keresztül értesíteniük kell a harmadik fél IKT-szolgáltatót az ilyen kijelölésről és azon kezdőidőpontról, amelytől ténylegesen felvigyázási tevékenységek alá fog esni. Az említett kezdő időpontot az értesítéstől számított egy hónapon belül kell meghatározni. A harmadik fél IKT-szolgáltatónak értesítenie kell azon pénzügyi szervezeteket, amelyeknek szolgáltatásokat nyújt, a kritikusnak való kijelöléséről.
|
|
31. cikk (6)
|
A Bizottság felhatalmazást kap arra, hogy – az 57. cikkel összhangban – 2024. július 17-ig felhatalmazáson alapuló jogi aktust fogadjon el, amely az e cikk (2) bekezdésében említett kritériumok részletesebb meghatározásával egészíti ki ezt a rendeletet.
|
|
31. cikk (7)
|
Az (1) bekezdés a) pontjában említett kijelölés csak azt követően alkalmazható, hogy a Bizottság a (6) bekezdésnek megfelelően felhatalmazáson alapuló jogi aktust fogadott el.
|
|
31. cikk (8)
|
Az (1) bekezdés a) pontjában említett kijelölés nem alkalmazható a következők tekintetében:
i.
azon pénzügyi intézmények, amelyek más pénzügyi intézményeknek nyújtanak IKT-szolgáltatásokat;
ii.
azon harmadik fél IKT-szolgáltatók, amelyek az Európai Unió működéséről szóló szerződés 127. cikkének (2) bekezdésében említett feladatok támogatásának céljából létrehozott felvigyázási keretrendszerek hatálya alá tartoznak;
iii.
a vállalatcsoporton belüli IKT-szolgáltatók;
iv.
olyan harmadik fél IKT-szolgáltatók, amelyek kizárólag egy tagállamban nyújtanak IKT-szolgáltatásokat olyan pénzügyi szervezetek számára, amelyek csak az említett tagállamban tevékenykednek.
|
|
31. cikk (9)
|
Az EFH-knak a vegyes bizottság keretében össze kell állítaniuk, közzé kell tenniük és évente frissíteniük kell a kritikus harmadik fél IKT-szolgáltatók uniós szintű jegyzékét.
|
|
31. cikk (10)
|
Az (1) bekezdés a) pontjának alkalmazásában az illetékes hatóságok összesített formában évente átadják a 32. cikk alapján létrehozott felvigyázási fórumnak a 28. cikk (3) bekezdésének harmadik albekezdésében említett jelentéseket. A felvigyázási fórum az illetékes hatóságoktól kapott információk alapján értékeli a pénzügyi szervezetek harmadik féltől való IKT-függőségét.
|
|
31. cikk (11)
|
Azon harmadik fél IKT-szolgáltatók, amelyek nem szerepelnek a (9) bekezdésben említett jegyzékben, kérhetik, hogy az (1) bekezdés a) pontjának megfelelően kritikusnak legyenek kijelölve. Az első albekezdés alkalmazásában a harmadik fél IKT-szolgáltatónak indokolással ellátott kérelmet kell benyújtania az EBH, az ESMA vagy az EIOPA részére, amely a vegyes bizottságon keresztül határoz arról, hogy az említett harmadik fél IKT-szolgáltatót az (1) bekezdés a) pontjának megfelelően kritikusnak jelöljék-e ki. A kérelem beérkezésétől számított 6 hónapon belül kell elfogadni a második albekezdésben említett határozatot, és arról értesíteni a harmadik fél IKT-szolgáltatót.
|
|
31. cikk (12)
|
A pénzügyi szervezetek csak akkor vehetik igénybe egy harmadik országban letelepedett és az (1) bekezdés a) pontjával összhangban kritikusnak kijelölt harmadik fél IKT-szolgáltató szolgáltatásait, ha az utóbbi a kijelölést követő 12 hónapon belül leányvállalatot létesített az Unióban.
|
|
31. cikk (13)
|
A (12) bekezdésben említett kritikus harmadik fél IKT-szolgáltatónak értesítenie kell a vezető felvigyázót az Unióban letelepedett leányvállalat irányítási struktúráját érintő bármely változásról.
|
,
1.1 Hivatkozások
1.2 Azonosított követelmények
1.3 Kapcsolódó szabványok
2. Azonosított követelmények
Követelmények
| Forrás |
Követelmény |
3. Kapcsolódó szabványok
Szabványok
| Forrás |
Követelmény |
|
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.
|
|