+Artikel 31 Udpegelse af kritiske tredjepartsudbydere af IKT-tjenester
---+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 Udpegelse af kritiske tredjepartsudbydere af IKT-tjenester
-
1. Oversigt
| Titel |
Regulering |
|
Artikel 31 1
|
1. ESA'erne skal via Det Fælles Udvalg og efter henstilling fra det tilsynsforum, der er oprettet i henhold til artikel 32, stk. 1,
|
a)
|
udpege de tredjepartsudbydere af IKT-tjenester, der er kritiske for finansielle enheder efter en vurdering, der tager hensyn til kriterierne i stk. 2
|
|
b)
|
som ledende tilsynsførende for hver kritisk tredjepartsudbyder af IKT-tjenester udpege den ESA, der i overensstemmelse med forordning (EU) nr. 1093/2010, (EU) nr. 1094/2010 eller (EU) nr. 1095/2010 er ansvarlig for de finansielle enheder, der tilsammen besidder den største andel samlede aktiver ud af værdien af de samlede aktiver for alle de finansielle enheder, der benytter sig af tjenester fra den pågældende kritiske tredjepartsudbyder af IKT-tjenester, således som det fremgår af summen af de individuelle balancer for disse finansielle enheder.
|
|
|
Artikel 31 2
|
2. Den udpegelse, der er omhandlet i stk. 1, litra a), skal i forbindelse med IKT-tjenester, der leveres af tredjepartsudbyderen af IKT-tjenester, baseres på samtlige følgende kriterier:
|
a)
|
den systemiske indvirkning på stabiliteten, kontinuiteten eller kvaliteten af leveringen af finansielle tjenesteydelser i tilfælde af, at den pågældende tredjepartsudbyder af IKT-tjenester udsættes for et stort operationelt svigt, således at denne ikke kan levere sine tjenester, idet der tages hensyn til antallet af finansielle enheder og den samlede værdi af aktiverne hos de finansielle enheder, som den pågældende tredjepartsudbyder af IKT-tjenester leverer tjenester til
|
|
b)
|
den systemiske karakter eller betydning af de finansielle enheder, der er afhængige af den pågældende tredjepartsudbyder af IKT-tjenester, vurderet i overensstemmelse med følgende parametre:
|
i)
|
antallet af globale systemisk vigtige institutter (G-SII'er) eller andre systemisk vigtige institutter (O-SII'er), som er afhængige af den pågældende tredjepartsudbyder af IKT-tjenester
|
|
ii)
|
den indbyrdes afhængighed mellem de i nr. i) omhandlede G-SII'er eller O-SII'er og andre finansielle enheder, herunder situationer, hvor G-SII'erne eller O-SII'erne leverer finansielle infrastrukturtjenester til andre finansielle enheder
|
|
|
c)
|
finansielle enheders afhængighed af de tjenester, der leveres af de pågældende tredjepartsudbydere af IKT-tjenester, i forbindelse med kritiske eller vigtige funktioner i finansielle enheder, som i sidste ende involverer den samme tredjepartsudbyder af IKT-tjenester, uanset om de benytter sig af disse tjenester direkte eller indirekte, gennem underentrepriseordninger
|
|
d)
|
i hvilket omfang tredjepartsudbyderen af IKT-tjenester kan erstattes under hensyntagen til følgende parametre:
|
i)
|
manglen på reelle alternativer, selv delvist, på grund af det begrænsede antal tredjepartsudbydere af IKT-tjenester, der er aktive på et specifikt marked, eller den pågældende tredjepartsudbyder af IKT-tjenesters markedsandel, eller den involverede tekniske kompleksitet eller finesse, herunder i forbindelse med eventuelle egne teknologier, eller de særlige kendetegn ved tredjepartsudbyderen af IKT-tjenesters organisation eller aktivitet
|
|
ii)
|
vanskeligheder i forbindelse med helt eller delvist at migrere de relevante data og arbejdsbyrden fra den pågældende tredjepartsudbyder af IKT-tjenester til en anden tredjepartsudbyder af IKT-tjenester, enten på grund af betydelige finansielle omkostninger, tid eller andre ressourcer, som migreringen kan kræve, eller en øget IKT-risiko eller andre operationelle risici, som den finansielle enhed kan blive eksponeret for ved en sådan migrering.
|
|
|
|
Artikel 31 3
|
3. Hvis tredjepartsudbyderen af IKT-tjenester indgår i en koncern, tages kriterierne i stk. 2 i betragtning i forhold til de IKT-tjenester, der leveres af koncernen som helhed.
|
|
Artikel 31 4
|
4. Kritiske tredjepartsudbydere af IKT-tjenester, som indgår i en koncern, udpeger én juridisk person som koordineringspunkt for at sikre en passende repræsentation og kommunikation med den ledende tilsynsførende.
|
|
Artikel 31 5
|
5. Den ledende tilsynsførende underretter tredjepartsudbyderen af IKT-tjenester om resultatet af den vurdering, der fører til udpegelsen, jf. stk. 1, litra a). Senest seks uger efter datoen for underretningen kan tredjepartsudbyderen af IKT-tjenester forelægge den ledende tilsynsførende en begrundet erklæring med alle relevante oplysninger med henblik på vurderingen. Den ledende tilsynsførende tager den begrundede erklæring i betragtning og kan anmode om, at der forelægges yderligere oplysninger inden for 30 kalenderdage efter modtagelsen af en sådan erklæring.
Efter at have udpeget en tredjepartsudbyder af IKT-tjenester som kritisk underretter ESA'erne gennem Det Fælles Udvalg tredjepartsudbyderen af IKT-tjenester om en sådan udpegelse og om startdatoen for, hvornår de reelt vil være omfattet af tilsynsaktiviteter. Denne startdato må ikke være senere end en måned efter underretningen. Tredjepartsudbyderen af IKT-tjenester underretter de finansielle enheder, som de leverer tjenester til, om deres udpegelse som kritiske.
|
|
Artikel 31 6
|
6. Kommissionen tillægges beføjelser til at vedtage en delegeret retsakt i overensstemmelse med artikel 57 for at supplere denne forordning ved yderligere at præcisere de kriterier, der er omhandlet i nærværende artikels stk. 2, senest den 17. juli 2024.
|
|
Artikel 31 7
|
7. Den udpegelse, der er omhandlet i stk. 1, litra a), må først anvendes, når Kommissionen har vedtaget en delegeret retsakt i overensstemmelse med stk. 6.
|
|
Artikel 31 8
|
8. Den udpegelse, der er omhandlet i stk. 1, litra a), finder ikke anvendelse på følgende:
|
i)
|
finansielle enheder, der leverer IKT-tjenester til andre finansielle enheder
|
|
ii)
|
tredjepartsudbydere af IKT-tjenester, som er underlagt tilsynsrammer, der er etableret med henblik på at understøtte de opgaver, der er omhandlet i artikel 127, stk. 2, i traktaten om Den Europæiske Unions funktionsmåde
|
|
iii)
|
koncerninterne udbydere af IKT-tjenester
|
|
iv)
|
tredjepartsudbydere af IKT-tjenester, der udelukkende leverer IKT-tjenester i én medlemsstat til finansielle enheder, der kun er aktive i den pågældende medlemsstat.
|
|
|
Artikel 31 9
|
9. ESA'erne udarbejder, offentliggør og ajourfører årligt via Det Fælles Udvalg listen over kritiske tredjepartsudbydere af IKT-tjenester på EU-plan.
|
|
Artikel 31 10
|
10. Med henblik på stk. 1, litra a), videregiver de kompetente myndigheder på et årligt og aggregeret grundlag de rapporter, der er omhandlet i artikel 28, stk. 3, tredje afsnit, til det tilsynsforum, der er oprettet i henhold til artikel 32. Tilsynsforummet vurderer finansielle enheders afhængighed af tredjepartsudbydere af IKT-tjenester på grundlag af oplysninger, som det modtager fra de kompetente myndigheder.
|
|
Artikel 31 11
|
11. De tredjepartsudbydere af IKT-tjenester, der ikke er opført på den i stk. 9 omhandlede liste, kan anmode om at blive udpeget som kritiske i overensstemmelse med stk. 1, litra a).
Med henblik på første afsnit indgiver tredjepartsudbyderen af IKT-tjenester en begrundet anmodning til EBA, ESMA eller EIOPA, som via Det Fælles Udvalg træffer afgørelse, om den pågældende tredjepartsudbyder af IKT-tjenester skal udpeges som kritisk i overensstemmelse med stk. 1, litra a).
Den i andet afsnit omhandlede afgørelse vedtages og meddeles tredjepartsudbyderen af IKT-tjenester senest 6 måneder efter modtagelsen af anmodningen.
|
|
Artikel 31 12
|
12. Finansielle enheder benytter kun tjenester, der udbydes af en tredjepartsudbyder af IKT-tjenester med hjemsted i et tredjeland, der er udpeget som kritisk i overensstemmelse med stk. 1, litra a), hvis sidstnævnte har etableret en dattervirksomhed i Unionen senest 12 måneder efter udpegelsen.
|
|
Artikel 31 13
|
13. Den i stk. 12 omhandlede kritiske tredjepartsudbyder af IKT-tjenester underretter den ledende tilsynsførende om eventuelle ændringer af ledelsesstrukturen i den dattervirksomhed, der er etableret i Unionen.
|
,
1.1 Referencer
1.2 Identificerede krav
1.3 Relaterede standarder
2. Identificerede krav
3. Relaterede standarder
Standarder
| Kilde |
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.
|
|