+Third-Party Contract Requirements
---+Contract Flow-Down Requirements
---+Provider Contingency Plan

Third-Party Contract Requirements

Description

Mechanisms exist to require contractual requirements for applicable security, compliance and resilience requirements with third-parties, reflecting the organization's needs to protect its Technology Assets, Applications, Services and/or Data (TAASD).

Possible Solutions & Considerations

Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2

∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program
∙ Data Protection Impact Assessment (DPIA)
∙ Third-party contract requirements for cybersecurity controls
∙ Non-Disclosure Agreements (NDAs)

Small Business (10-49 staff) / BLS Firm Size Classes 3-4

∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program
∙ Data Protection Impact Assessment (DPIA)
∙ Third-party contract requirements for cybersecurity controls
∙ Non-Disclosure Agreements (NDAs)

Medium Business (50-249 staff) / BLS Firm Size Classes 5-6

∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program
∙ Data Protection Impact Assessment (DPIA)
∙ Third-party contract requirements for cybersecurity controls
∙ Non-Disclosure Agreements (NDAs)

Large Business (250-999 staff) / BLS Firm Size Classes 7-8

∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program
∙ Data Protection Impact Assessment (DPIA)
∙ Third-party contract requirements for cybersecurity controls
∙ Non-Disclosure Agreements (NDAs)

Enterprise (> 1,000 staff) / BLS Firm Size Class 9

∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program
∙ Data Protection Impact Assessment (DPIA)
∙ Third-party contract requirements for cybersecurity controls
∙ Non-Disclosure Agreements (NDAs)

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

SCR-CMM Level 1 criteria definitions are not available for this control:
▪ A reasonable person would conclude this control requires a structured process.
▪ At this level of maturity, the "ad hoc" nature of performing a capability informally would indicate the intent of the control is not met due to a lack of consistency and formality.

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.
▪ Procurement practices contractually require ESP to follow secure engineering practices as part of a broader Cybersecurity Supply Chain Risk Management (C-SCRM) initiative.
▪ A formal agreement exists between the organization and applicable third-parties that includes a Non-Disclosure Agreement (NDA) addressing shared sensitive data.

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 require contractual requirements for applicable security, compliance and resilience requirements with third-parties, reflecting the organization's needs to protect its TAASD.

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.

1. Översikt

Contract Flow-Down Requirements

Description

Mechanisms exist to ensure applicable security, compliance and resilience requirements are included in contracts that flow-down to applicable subcontractors and suppliers.

Possible Solutions & Considerations

Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2

∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program
∙ Data Protection Impact Assessment (DPIA)
∙ Third-party contract requirements for cybersecurity controls

Small Business (10-49 staff) / BLS Firm Size Classes 3-4

∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program
∙ Data Protection Impact Assessment (DPIA)
∙ Third-party contract requirements for cybersecurity controls

Medium Business (50-249 staff) / BLS Firm Size Classes 5-6

∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program
∙ Data Protection Impact Assessment (DPIA)
∙ Third-party contract requirements for cybersecurity controls

Large Business (250-999 staff) / BLS Firm Size Classes 7-8

∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program
∙ Data Protection Impact Assessment (DPIA)
∙ Third-party contract requirements for cybersecurity controls

Enterprise (> 1,000 staff) / BLS Firm Size Class 9

∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program
∙ Data Protection Impact Assessment (DPIA)
∙ Third-party contract requirements for cybersecurity controls

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

SCR-CMM Level 1 criteria definitions are not available for this control:
▪ A reasonable person would conclude this control requires a structured process.
▪ At this level of maturity, the "ad hoc" nature of performing a capability informally would indicate the intent of the control is not met due to a lack of consistency and formality.

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.
▪ Procurement practices contractually require ESP to follow secure engineering practices as part of a broader Cybersecurity Supply Chain Risk Management (C-SCRM) initiative.
▪ A formal agreement exists between the organization and applicable third-parties that includes a Non-Disclosure Agreement (NDA) addressing shared sensitive data.

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 ensure applicable security, compliance and resilience requirements are included in contracts that flow-down to applicable sub-contractors and suppliers.

Level 4 Quantitatively Controlled

Utilize SCR-CMM Level 3 criteria definitions:
▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control.
▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.

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.
Provider Contingency Plan

Description

Mechanisms exist to contractually-require external service providers to have contingency plans that meet organizational contingency requirements.

Possible Solutions & Considerations

Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2

∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program

Small Business (10-49 staff) / BLS Firm Size Classes 3-4

∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program

Medium Business (50-249 staff) / BLS Firm Size Classes 5-6

∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program

Large Business (250-999 staff) / BLS Firm Size Classes 7-8

∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program

Enterprise (> 1,000 staff) / BLS Firm Size Class 9

∙ Cybersecurity Supply Chain Risk Management (C-SCRM) program

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

SCR-CMM Level 1 criteria definitions are not available for this control:
▪ A reasonable person would conclude this control requires a structured process.
▪ At this level of maturity, the "ad hoc" nature of performing a capability informally would indicate the intent of the control is not met due to a lack of consistency and formality.

Level 2 Planned Tracked

Business Continuity & Disaster Recovery (BCD) 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 BCD domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with BCD 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 BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ BC/DR 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 contractually-require external service providers to have contingency plans that meet organizational contingency requirements.

Level 4 Quantitatively Controlled

Utilize SCR-CMM Level 3 criteria definitions:
▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control.
▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.

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.

1.1 Referenser

1.2 Identifierade krav

1.3 Relaterade regleringar

2. Identifierade krav

Krav

3. Relaterade regleringar

Regleringar
EULAW Artikel 11 Data- och systemsäkerhet
-
EULAW Artikel 13 Hantering av nätverkssäkerhet

Artikel 13

Hantering av nätverkssäkerhet

Finansiella entiteter ska, som en del av de skyddsåtgärder som säkerställer nätverkens säkerhet mot intrång och missbruk av uppgifter, utarbeta, dokumentera och införa strategier, förfaranden, protokoll och verktyg för hantering av nätverkssäkerhet, inklusive allt av följande:

a) 

Segregering och segmentering av IKT-system och nätverk med beaktande av

i) 

kritikaliteten hos eller vikten av den funktion som dessa IKT-system och nätverk stöder,

ii) 

den klassificering som fastställts i enlighet med artikel 8.1 i förordning (EU) 2022/2554,

iii) 

den allmänna riskprofilen för IKT-tillgångar som använder dessa IKT-system och nätverk.

b) 

Dokumentation av den finansiella entitetens samtliga nätverksanslutningar och dataflöden.

c) 

Användning av ett separat och särskilt nätverk för administration av IKT-tillgångar.

d) 

Identifiering och genomförande av kontroller för nätverksåtkomst för att förhindra och upptäcka anslutningar till den finansiella entitetens nätverk av en obehörig enhet eller ett obehörigt system, eller någon slutpunkt som inte uppfyller den finansiella entitetens säkerhetskrav.

e) 

Kryptering av nätverksanslutningar som går via företagsnätverk, offentliga nätverk, inhemska nätverk, tredje parts nätverk och trådlösa nätverk, för kommunikationsprotokoll som används, med beaktande av resultaten av den godkända dataklassificeringen, resultaten av IKT-riskbedömningen och den kryptering av nätverksanslutningar som avses i artikel 6.2.

f) 

Utformning av nätverk i linje med de IKT-säkerhetskrav som fastställts av den finansiella entiteten, med beaktande av ledande praxis för att säkerställa nätverkets konfidentialitet, integritet och tillgänglighet.

g) 

Säkring av nätverkstrafik mellan de interna nätverken och internet och andra externa anslutningar.

h) 

Identifiering av roller och ansvarsområden samt steg för specifikation, införande, godkännande, ändring och granskning av brandväggsregler och anslutningsfilter.

i) 

Granskning av nätverksarkitekturen och utformningen av nätverkssäkerheten en gång per år, och regelbundet för mikroföretag, för att identifiera potentiella sårbarheter.

j) 

Åtgärder för att vid behov tillfälligt isolera delnätverk samt nätverkskomponenter och nätverksenheter.

k) 

Införande av en baslinje för säker konfiguration av alla nätverkskomponenter och härdning av nätverket och nätverksenheter i linje med eventuella leverantörsanvisningar, i tillämpliga fall standarder enligt definitionen i artikel 2.1 i förordning (EU) nr 1025/2012 och ledande praxis.

l) 

Förfaranden för att begränsa, låsa och avsluta system- och fjärrsessioner efter en angiven period av inaktivitet.

m) 

När det gäller avtal om nätverkstjänster,

i) 

identifiering och specificering av IKT-säkerhetsåtgärder och informationssäkerhetsåtgärder, servicenivåer och hanteringskrav för alla nätverkstjänster,

ii) 

huruvida dessa tjänster tillhandahålls av en koncernintern IKT-tjänteleverantör eller av tredjepartsleverantörer av IKT-tjänster.

Vid tillämpning av led h ska finansiella entiteter regelbundet granska brandväggsregler och anslutningsfilter i enlighet med den klassificering som fastställts i enlighet med artikel 8.1 i förordning (EU) 2022/2554 och den allmänna riskprofilen för de berörda IKT-systemen. När det gäller IKT-system som stöder kritiska eller viktiga funktioner ska finansiella entiteter kontrollera att de befintliga brandväggsreglerna och anslutningsfiltren är tillräckliga minst var sjätte månad.
EULAW Artikel 28 Allmänna principer
-
EULAW Artikel 29 Preliminär bedömning av IKT-koncentrationsrisker på entitetsnivå
-
EULAW Artikel 30 Viktiga avtalsbestämmelser
-
EULAW Artikel 21 Riskhanteringsåtgärder för cybersäkerhet
-
EULAW Artikel 28 Allmänna principer
-
EULAW Artikel 29 Preliminär bedömning av IKT-koncentrationsrisker på entitetsnivå
-
EULAW Artikel 30 Viktiga avtalsbestämmelser
-
EULAW Artikel 21 Riskhanteringsåtgärder för cybersäkerhet
-
EULAW Artikel 28 Allmänna principer
-
EULAW Artikel 29 Preliminär bedömning av IKT-koncentrationsrisker på entitetsnivå
-
EULAW Artikel 30 Viktiga avtalsbestämmelser
-
EULAW Artikel 21 Riskhanteringsåtgärder för cybersäkerhet
-
EULAW Artikel 28 1

1.   Finansiella entiteter ska hantera IKT-tredjepartsrisker som en integrerad del av IKT-risken inom sin IKT-riskhanteringsram som avses i artikel 6.1, och i enlighet med följande principer:

a)

De finansiella entiteter som har ingått ett kontraktsmässigt arrangemang om användningen av IKT-tjänster för att bedriva sin affärsverksamhet ska alltid ha det fulla ansvaret för uppfyllandet och fullgörandet av alla skyldigheter enligt denna förordning och tillämplig rätt avseende finansiella tjänster.

b)

Finansiella entiteters hantering av IKT-tredjepartsrisker ska genomföras med hänsyn till proportionalitetsprincipen, med beaktande av

i)

IKT-relaterade beroendens karaktär, omfattning, komplexitet och betydelse,

ii)

de risker som uppstår till följd av kontraktsmässiga arrangemang om användningen av IKT-tjänster som har ingåtts med tredjepartsleverantörer av IKT-tjänster, med hänsyn till den kritikaliteten eller betydelsen av respektive tjänst, process eller funktion, och den potentiella inverkan på kontinuiteten och tillgängligheten hos finansiella tjänster och verksamheter, på individuell nivå och på koncernnivå.
EULAW Artikel 29 2

2.   Om de kontraktsmässiga arrangemangen om användning av IKT-tjänster som stöder kritiska eller viktiga funktioner inbegriper möjligheten att en tredjepartsleverantör av IKT-tjänster lägger ut IKT-tjänster som stöder kritisk eller viktig funktion på underentreprenad till andra tredjepartsleverantörer av IKT-tjänster, ska finansiella entiteter väga de fördelar och risker som kan uppstå i samband med en sådan underentreprenad, särskilt när det gäller en IKT-underleverantör som är etablerad i ett tredjeland.

Om de kontraktsmässiga arrangemangen gäller IKT-tjänster som stöder kritiska eller viktiga funktioner ska finansiella entiteter vederbörligen ta hänsyn till de insolvensrättsliga bestämmelser som skulle vara tillämpliga om IKT-tjänsteleverantören går i konkurs samt eventuella begränsningar som kan uppstå när det gäller skyndsam återställning av den finansiella entitetens data.

Om kontraktsmässiga arrangemang om användning av IKT-tjänster som stöder kritiska eller viktiga funktioner ingås med en tredjepartsleverantör av IKT-tjänster som är etablerad i ett tredjeland ska finansiella entiteter utöver de hänsynstaganden som avses i andra stycket även beakta överensstämmelsen med unionens dataskyddsregler och den faktiska efterlevnaden av rätten i det tredjelandet.

Om de kontraktsmässiga arrangemangen om användning av IKT-tjänster som stöder kritiska eller viktiga funktioner medger underentreprenad, ska finansiella entiteter bedöma om och hur potentiellt långa eller komplexa underentreprenadskedjor kan påverka deras förmåga att till fullo övervaka de avtalade funktionerna och den behöriga myndighetens förmåga att effektivt övervaka den finansiella entiteten i detta avseende.
EULAW Artikel 30 1

1.   Rättigheterna och skyldigheterna för den finansiella entiteten och tredjepartsleverantören av IKT-tjänster ska vara tydligt fördelade och skriftligen angivna. Det fullständiga avtalet ska omfatta servicenivåavtalen och dokumenteras i ett skriftligt dokument som parterna ska ha tillgång till på papper eller i ett dokument med ett annat nedladdningsbart, varaktigt och tillgängligt format.
EULAW Artikel 30 2

2.   De kontraktsmässiga arrangemangen för användning av IKT-tjänster ska innehålla åtminstone följande delar:

a)

En tydlig och fullständig beskrivning av alla funktioner och IKT-tjänster som ska tillhandahållas av tredjepartsleverantören av IKT-tjänster, med uppgift om huruvida underentreprenad av en IKT-tjänst som stöder en kritisk eller viktig funktion eller väsentliga delar därav, är tillåten och, när så är fallet, de villkor som gäller för sådan underentreprenad.

b)

De platser, nämligen regioner eller länder, där de funktioner och IKT-tjänster som har utkontrakterats eller lagts ut på underentreprenad ska tillhandahållas och var uppgifterna ska behandlas, inklusive lagringsplatsen, och ett krav på att tredjepartsleverantören av IKT-tjänster på förhand ska underrätta den finansiella entiteten om den planerar att ändra sådana platser.

c)

Bestämmelser om tillgänglighet, äkthet, integritet och konfidentialitet vad gäller skydd av data, inbegripet personuppgifter.

d)

Bestämmelser om säkerställande av åtkomst, återställande och återlämnande i ett lättillgängligt format av personuppgifter och andra uppgifter än personuppgifter som behandlas av den finansiella entiteten i händelse av insolvens, resolution eller nedläggning av verksamheten vad avser tredjepartsleverantören av IKT-tjänster, eller i händelse av uppsägning av de kontraktsmässiga arrangemangen.

e)

Beskrivningar av servicenivå, inbegripet uppdateringar och revideringar av dessa.

f)

Skyldigheten för tredjepartsleverantören av IKT-tjänster att tillhandahålla assistans till den finansiella entiteten utan extra kostnad, eller till en kostnad som fastställs på förhand, när en IKT-incident med anknytning till den IKT-tjänst som tillhandahålls den finansiella entiteten inträffar.

g)

Skyldigheten för tredjepartsleverantören av IKT-tjänster att samarbeta fullt ut med de behöriga myndigheterna och resolutionsmyndigheterna för den finansiella entiteten, inbegripet personer som har utsetts av dem.

h)

Uppsägningsrätt och tillhörande minsta uppsägningstid för uppsägning av det kontraktsmässiga arrangemanget, i enlighet med de behöriga myndigheternas och resolutionsmyndigheternas förväntningar.

i)

Villkoren för deltagande av tredjepartsleverantörer av IKT-tjänster i finansiella entiteters program för medvetenhet om IKT-säkerhet och utbildning om digital operativ motståndskraft i enlighet med artikel 13.6.
EULAW Artikel 30 3

3.   De kontraktsmässiga arrangemangen om användning av IKT-tjänster som stöder kritiska eller viktiga funktioner ska, utöver de delar som avses i punkt 2, innehålla åtminstone följande:

a)

Beskrivningar av fullständig servicenivå, inklusive uppdateringar och revideringar av dessa, med exakta kvantitativa och kvalitativa prestationsmål inom de överenskomna servicenivåerna för att göra det möjligt för den finansiella entiteten att effektivt övervaka IKT-tjänster och göra det möjligt att utan onödigt dröjsmål vidta lämpliga korrigerande åtgärder när överenskomna servicenivåer inte uppnås.

b)

Anmälningsperioder och rapporteringsskyldigheter för tredjepartsleverantören av IKT-tjänster till den finansiella entiteten, inbegripet underrättelse om varje händelse som kan ha en väsentlig inverkan på IKT-tredjepartsleverantörens förmåga att effektivt tillhandahålla IKT-tjänster som stöder kritiska eller viktiga funktioner i linje med överenskomna servicenivåer.

c)

Krav på att tredjepartsleverantören av IKT-tjänster ska genomföra och testa beredskapsplaner för verksamheten och ha infört IKT-säkerhetsåtgärder, IKT-verktyg och IKT-strategier som ger en lämplig säkerhetsnivå vid tillhandahållande av tjänster från den finansiella entitetens sida i enlighet med dess regelverk.

d)

Skyldigheten för tredjepartsleverantören av IKT-tjänster att delta och fullt ut samarbeta i den finansiella entitetens hotbildsstyrda penetrationstestning enligt artiklarna 26 och 27.

e)

Rätten att fortlöpande övervaka prestandan hos tredjepartsleverantören av IKT-tjänster, vilket omfattar följande:

i)

Obegränsad rätt till tillgång till, inspektion och revision för den finansiella entiteten eller en utsedd tredjepart, och för den behöriga myndigheten, och rätt att ta kopior av relevant dokumentation på plats om de är kritiska för verksamheten hos tredjepartsleverantören av IKT-tjänster, vars faktiska utövande inte hindras eller begränsas av andra kontraktsmässiga arrangemang eller strategier för genomförande.

ii)

Rätten att komma överens om alternativa garantinivåer om andra kunders rättigheter påverkas.

iii)

Skyldigheten för tredjepartsleverantören av IKT-tjänster att samarbeta fullt ut under de inspektioner och revisioner på plats som utförs av de behöriga myndigheterna, den ledande tillsynsmyndigheten, den finansiella entiteten eller en utsedd tredjepart.

iv)

Skyldigheten att tillhandahålla närmare uppgifter om omfattningen, de förfaranden som ska följas och frekvensen för sådana inspektioner och revisioner.

f)

Exitstrategier, särskilt inrättande av en obligatorisk lämplig övergångsperiod

i)

under vilken tredjepartsleverantören av IKT-tjänster kommer att fortsätta att tillhandahålla respektive funktioner eller IKT-tjänster i syfte att minska risken för avbrott hos den finansiella entiteten, eller säkerställa en effektiv resolution och omstrukturering av denna,

ii)

som gör det möjligt för den finansiella entiteten att migrera till en annan tredjepartsleverantör av IKT-tjänster eller byta till interna lösningar som är förenliga med komplexiteten hos den tillhandahållna tjänsten.

Genom undantag från led e får tredjepartsleverantören av IKT-tjänster och en finansiell entitet som är ett mikroföretag komma överens om att den finansiella entitetens rätt till tillgång, inspektion och revision kan delegeras till en oberoende tredjepart som utsetts av tredjepartsleverantören av IKT-tjänster, och att den finansiella entiteten när som helst kan begära information och försäkran om IKT-tredjepartsleverantörens prestanda från den tredje parten.
EULAW Artikel 30 4

4.   När finansiella entiteter och tredjepartsleverantörer av IKT-tjänster förhandlar om kontraktsmässiga arrangemang ska de överväga att använda standardavtalsklausuler som har utarbetats av offentliga myndigheter för specifika tjänster.

Länkade ärenden

Länkar
is related to Annual
is related to relative Control Weighting = 10
is related to Process
is related to Identify
is related to SCRM Focus Tier 1 STRATEGIC
is related to SCRM Focus Tier 2 OPERATIONAL
is related to SCRM Focus Tier 3 TACTICAL
blocks Unauthorized Retention / Inability to Dispose of Data
blocks Business / Service Interruption
blocks Contractual Default / Termination
blocks Regulatory / Legal / Contractual Financial Liability
blocks Loss of Authorization / Certification / License
blocks Failure to Support Business / Mission Objectives
blocks Unaddressed Security / Compliance Exposure
blocks Unperformed / Unowned Control Responsibilities
blocks Uncontrolled Third-Party Security / Privacy Exposure
blocks Lack of oversight of third-party controls
blocks Inability to Demonstrate Due Diligence / Due Care
blocks Unreliable Assurance / Decision Information
blocks Recovery Failure / Unacceptable Recovery Delay
blocks Third-Party Cybersecurity Compromise / Exposure
blocks Third-Party Physical Security Disruption / Exposure
blocks Sub-Tier / Fourth-Party Supply Chain Exposure
blocks Third-Party Legal / Compliance Exposure
blocks Harm from Unauthorized / Unintended Product or Service Use
blocks Third-Party Dependency Failure
blocks Counterfeit / Non-Conforming Component Impact
blocks Loss of Confidentiality
blocks Privacy Harm / Unauthorized Processing
blocks Drought & Water Shortage
blocks Earthquakes
blocks Fire & Wildfires
blocks Floods
blocks Hurricanes & Tropical Storms
blocks Landslides & Debris Flow
blocks Pandemic (Disease) Outbreaks
blocks Severe Weather
blocks Space Weather
blocks Thunderstorms & Lightning
blocks Tornadoes
blocks Tsunamis
blocks Volcanoes
blocks Winter Storms & Extreme Cold
blocks Dysfunctional Management Practices
blocks Human Error
blocks Statutory / Regulatory / Contractual Change
blocks Fraud, Corruption and/or Intentional Criminal Conduct
blocks Conflict of Interest (COI) / Undue Influence / Insider Misconduct
blocks Economic Shock / Market Disruption
blocks Foreign Ownership, Control, or Influence (FOCI)
blocks Sanctions / Trade Restriction Disruption
blocks Supplier Financial Distress / Insolvency
blocks Workforce Shortage / Loss of Critical Skills / Labor Disruption
blocks HR-06.02B
blocks PS-01.05B
blocks PS-06.04AC
blocks OPS-11.02B
blocks IAM-07.06B
blocks IAM-07.06AS
blocks IAM-07.01AC
blocks PI-02.01B
blocks PI-02.01AC
blocks PI-02.02AC
blocks DEV-02.01B
blocks SSO-01.01B
blocks SSO-01.02AC
blocks SSO-03.02B
blocks SIM-04.02AC
blocks COM-02.01AC
blocks PSS-12.03B
blocks Unauthorized Retention / Inability to Dispose of Data
blocks Business / Service Interruption
blocks Contractual Default / Termination
blocks Regulatory / Legal / Contractual Financial Liability
blocks Loss of Authorization / Certification / License
blocks Failure to Support Business / Mission Objectives
blocks Unaddressed Security / Compliance Exposure
blocks Unperformed / Unowned Control Responsibilities
blocks Uncontrolled Third-Party Security / Privacy Exposure
blocks Lack of oversight of third-party controls
blocks Inability to Demonstrate Due Diligence / Due Care
blocks Unreliable Assurance / Decision Information
blocks Recovery Failure / Unacceptable Recovery Delay
blocks Third-Party Cybersecurity Compromise / Exposure
blocks Third-Party Physical Security Disruption / Exposure
blocks Sub-Tier / Fourth-Party Supply Chain Exposure
blocks Third-Party Legal / Compliance Exposure
blocks Harm from Unauthorized / Unintended Product or Service Use
blocks Third-Party Dependency Failure
blocks Counterfeit / Non-Conforming Component Impact
blocks Loss of Confidentiality
blocks Privacy Harm / Unauthorized Processing
blocks Drought & Water Shortage
blocks Earthquakes
blocks Fire & Wildfires
blocks Floods
blocks Hurricanes & Tropical Storms
blocks Landslides & Debris Flow
blocks Pandemic (Disease) Outbreaks
blocks Severe Weather
blocks Space Weather
blocks Thunderstorms & Lightning
blocks Tornadoes
blocks Tsunamis
blocks Volcanoes
blocks Winter Storms & Extreme Cold
blocks Dysfunctional Management Practices
blocks Human Error
blocks Statutory / Regulatory / Contractual Change
blocks Fraud, Corruption and/or Intentional Criminal Conduct
blocks Conflict of Interest (COI) / Undue Influence / Insider Misconduct
blocks Economic Shock / Market Disruption
blocks Foreign Ownership, Control, or Influence (FOCI)
blocks Sanctions / Trade Restriction Disruption
blocks Supplier Financial Distress / Insolvency
blocks Workforce Shortage / Loss of Critical Skills / Labor Disruption
blocks HR-06.02B
blocks PS-01.05B
blocks PS-06.04AC
blocks OPS-11.02B
blocks IAM-07.06B
blocks IAM-07.06AS
blocks IAM-07.01AC
blocks PI-02.01B
blocks PI-02.01AC
blocks PI-02.02AC
blocks DEV-02.01B
blocks SSO-01.01B
blocks SSO-01.02AC
blocks SSO-03.02B
blocks SIM-04.02AC
blocks COM-02.01AC
blocks PSS-12.03B
blocks Unauthorized Retention / Inability to Dispose of Data
blocks Business / Service Interruption
blocks Contractual Default / Termination
blocks Regulatory / Legal / Contractual Financial Liability
blocks Loss of Authorization / Certification / License
blocks Failure to Support Business / Mission Objectives
blocks Unaddressed Security / Compliance Exposure
blocks Unperformed / Unowned Control Responsibilities
blocks Uncontrolled Third-Party Security / Privacy Exposure
blocks Lack of oversight of third-party controls
blocks Inability to Demonstrate Due Diligence / Due Care
blocks Unreliable Assurance / Decision Information
blocks Recovery Failure / Unacceptable Recovery Delay
blocks Third-Party Cybersecurity Compromise / Exposure
blocks Third-Party Physical Security Disruption / Exposure
blocks Sub-Tier / Fourth-Party Supply Chain Exposure
blocks Third-Party Legal / Compliance Exposure
blocks Harm from Unauthorized / Unintended Product or Service Use
blocks Third-Party Dependency Failure
blocks Counterfeit / Non-Conforming Component Impact
blocks Loss of Confidentiality
blocks Privacy Harm / Unauthorized Processing
blocks Drought & Water Shortage
blocks Earthquakes
blocks Fire & Wildfires
blocks Floods
blocks Hurricanes & Tropical Storms
blocks Landslides & Debris Flow
blocks Pandemic (Disease) Outbreaks
blocks Severe Weather
blocks Space Weather
blocks Thunderstorms & Lightning
blocks Tornadoes
blocks Tsunamis
blocks Volcanoes
blocks Winter Storms & Extreme Cold
blocks Dysfunctional Management Practices
blocks Human Error
blocks Statutory / Regulatory / Contractual Change
blocks Fraud, Corruption and/or Intentional Criminal Conduct
blocks Conflict of Interest (COI) / Undue Influence / Insider Misconduct
blocks Economic Shock / Market Disruption
blocks Foreign Ownership, Control, or Influence (FOCI)
blocks Sanctions / Trade Restriction Disruption
blocks Supplier Financial Distress / Insolvency
blocks Workforce Shortage / Loss of Critical Skills / Labor Disruption
blocks HR-06.02B
blocks PS-01.05B
blocks PS-06.04AC
blocks OPS-11.02B
blocks IAM-07.06B
blocks IAM-07.06AS
blocks IAM-07.01AC
blocks PI-02.01B
blocks PI-02.01AC
blocks PI-02.02AC
blocks DEV-02.01B
blocks SSO-01.01B
blocks SSO-01.02AC
blocks SSO-03.02B
blocks SIM-04.02AC
blocks COM-02.01AC
blocks PSS-12.03B
is blocked by TPM-14 Third-Party Contract Requirements – Assessment Procedure
blocks SR-03(03) Sub-tier Flow Down
blocks 03.01.20 Use of External Systems
blocks 03.07.06 Maintenance Personnel
blocks 03.16.03 External System Services
blocks 03.17.02 Acquisition Strategies, Tools, and Methods
blocks 03.17.03 Supply Chain Requirements and Processes
blocks GV.OC-02 Internal and external stakeholders are understood, and their needs and expectations regarding cybersecurity risk management are understood and …
blocks GV.OC-03 Legal, regulatory, and contractual requirements regarding cybersecurity - including privacy and civil liberties obligations - are understood and …
blocks GV.SC-02 Cybersecurity roles and responsibilities for suppliers, customers, and partners are established, communicated, and coordinated internally and …
blocks GV.SC-05 Requirements to address cybersecurity risks in supply chains are established, prioritized, and integrated into contracts and other types of …
blocks GV.SC-06 Planning and due diligence are performed to reduce risks before entering into formal supplier or other third-party relationships
blocks PO.1 Define Security Requirements for Software Development
  • Secure Controls Framework -

    The Secure Controls Framework® (SCF)

    "The SCF is the Common Controls Framework™ (CCF), the world's most comprehensive cybersecurity and data privacy metaframework - it is also free to use. The entire concept is building secure, compliant and resilient capabilities in the most efficient and cost-effective manner possible.

    The SCF is more than just a unified control catalog, since its included content creates a playbook for Governance, Risk & Compliance (GRC) capabilities. Used globally by organizations of every size, the SCF is a robust and scalable solution for security, compliance and resilience controls. As a comprehensive security framework, the SCF maps 1,400+ controls across 200+ laws, regulations, and industry frameworks so you can implement once and comply everywhere.

    Like it or not, cybersecurity is a protracted war on an asymmetric battlefield, where the threats are everywhere and as defenders we have to make the effort to work together to help improve cybersecurity and data privacy practices, since we all suffer when massive data breaches occur or when cyber attacks have physical impacts. Hackers share information on attack methods with other hackers, so why shouldn’t the good guys share information on how to best protect an organization? We decided to take action and make a difference, since we feel it is too important to wait for someone else to fix the problems that exist.

    The SCF is made up of volunteers, mainly specialists within the cybersecurity profession, who focus on GRC and the cybersecurity side of data privacy. These are auditors, engineers, architects, incident responders, consultants and other specialists who live and breathe these topics on a daily basis. The end product is "expert-derived content" that makes up the SCF." https://securecontrolsframework.com/ 

    Terms & Conditions

    The SCF End User License Agreement (EULA) governs the use of the Secure Controls Framework® (SCF) under the Creative Commons Attribution-No Derivatives 4.0 International Public License.