+DORA Ch. IV Art. 26 4.

DORA Ch. IV Art. 26 4.

4.   Without prejudice to paragraph 2, first and second subparagraphs, where the participation of an ICT third-party service provider in the TLPT, referred to in paragraph 3, is reasonably expected to have an adverse impact on the quality or security of services delivered by the ICT third-party service provider to customers that are entities falling outside the scope of this Regulation, or on the confidentiality of the data related to such services, the financial entity and the ICT third-party service provider may agree in writing that the ICT third-party service provider directly enters into contractual arrangements with an external tester, for the purpose of conducting, under the direction of one designated financial entity, a pooled TLPT involving several financial entities (pooled testing) to which the ICT third-party service provider provides ICT services.

That pooled testing shall cover the relevant range of ICT services supporting critical or important functions contracted to the respective ICT third-party service provider by the financial entities. The pooled testing shall be considered TLPT carried out by the financial entities participating in the pooled testing.

The number of financial entities participating in the pooled testing shall be duly calibrated taking into account the complexity and types of services involved.

1. Overview

1.1 References

1.2 Identified Requirements

1.3 Related Standards

2. Identified Requirements

Requirements

3. Related Standards

Standards
NOREA Outsourced System testing

Extend TLPT to critical outsourced systems, processes, and technologies. The entity shall remain responsible for control compliance. Collaborate with the service providers to establish risk management controls, mitigating risks to data, assets, and critical functions.

*Note that this control is only applicable for financial institutions wich are eligible for TLPT. Refer to the RTS on TLPT for more information on applicability.
NOREA Selection of TLPT Testers

Engage either internal or external TLPT testers, with external testers contracted every third TLPT cycle. Ensure internal testers are regulator-approved, possess adequate resources, and engage external threat intelligence providers. Select TLPT testers based on reputation, expertise in threat intelligence, penetration testing, and red team practices, relevant certifications, independent assurance, and indemnity insurance coverage. Ensure that contracts concluded with external testers require a sound management of the TLPT results and that any data processing thereof, including any generation, store, aggregation, draft, report, communication or destruction, do not create risks. 

Ensure independence of teams where internal and external testers operate separately, and verify relevant certifications, independent assurance, and indemnity insurance coverage. 
*Note that this control is only applicable for financial institutions wich are eligible for TLPT. Refer to the RTS on TLPT for more information on applicability.
NOREA (Critical) Service Level Management

Ensure the contract with ICT third-party service provider delivering critical or important services encompasses comprehensive service level descriptions, including updates and detailed reporting (both quantitative and qualitative). Evaluate the service provider's compliance with performance and quality standards by reviewing reports on activities and services, incident reports, security and business continuity measures, and testing. Assess performance using key performance indicators, key control indicators, audits, self-certifications, and independent reviews. Receive relevant information from the service provider regarding their activities and services and ensure timely notification and response to incidents. Conduct independent reviews and compliance audits with legal and regulatory requirements and policies. Specify notification periods for any material changes that may impact the entity or agreed service levels.
NOREA Contractual Clauses

Secure rights for continuous performance monitoring, including unrestricted rights to access, inspection, and audit. This encompasses alternative assurance levels, cooperation with regulator inspections, and full disclosure of audit scope, procedures, and frequency. Include a mandatory transition period upon termination, allowing the service provider to continue services during migration, affording the entity time to transition to another provider or in-house solutions based on service complexity. Mandate the implementation and testing of business contingency plans and the establishment of a security management system by the service provider. 

When negotiating contractual arrangements, consider the use of standard contractual clauses developed by public authorities for specific services.

Require the service provider's participation in the entity's (advanced) testing program (TLPT), where required. Where participation of an ICT third-party service provider in TLPT may adversely impact services or data confidentiality for customers outside the scope of DORA, it may be agreed in writing to perform a pooled TLPT.
NOREA Third-party Critical Subcontracting Management

Delineate critical and important ICT services in contracts with third-party ICT service providers, specifying conditions for subcontracting. Require continual monitoring of subcontracted services supporting critical functions to ensure compliance with contractual obligations. Detail monitoring and reporting responsibilities of the third-party service provider to the financial entity, including risk assessments related to subcontractor locations and data ownership. Mandate incident response and business continuity plans for subcontractors, along with adherence to specified service levels and security standards. Retain termination rights for the financial entity in cases of unauthorized subcontracting or failure to meet agreed-upon service levels. Implement changes relative to contractual agreements as soon as possible and document the planned timeline for the implementation.
NOREA Periodic TLPT Testing

Conduct Threat-led penetration testing (TLPT) every three years, aligning with the entity's risk profile. Ensure TLPT covers all critical or important functions and test on live production systems. Provide the regulator with a report encompassing TLPT findings, remediation plans, and documentation demonstrating adherence to this control. Perform TLPT according to the DORA TLPT framework (based on the TIBER-EU framework) as defined in the corresponding RTS. 

*Note that this control is only applicable for financial institutions wich are eligible for TLPT. Refer to the RTS on TLPT for more information on applicability.
SCF Penetration Testing

Description

Mechanisms exist to conduct penetration testing on Technology Assets, Applications and/or Services (TAAS).

Possible Solutions & Considerations

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

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

∙ Annual penetration test by qualified tester

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

∙ Annual penetration test by qualified third-party tester

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

∙ Enterprise penetration testing program
∙ Annual external and internal pen tests

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

∙ Enterprise penetration testing program
∙ Annual and event-driven pen tests
∙ Red team exercises
∙ Purple teaming

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.
Vulnerability & Patch Management (VPM) domain capabilities are ad hoc and inconsistent. Capability criteria associated with this control may include:
▪ Policies, standards & procedures associated with VPM domain capabilities provide limited coverage due to the depth and breadth of the existing documentation.
▪ Attack Surface Management (ASM)-related activities are decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.

Level 2 Planned Tracked

Vulnerability & Patch Management (VPM) 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 VPM domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with VPM 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 VPM domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Vulnerability management-related controls are primarily administrative and preventative in nature (e.g., policies, standards, procedures & guidelines).
▪ Vulnerability management may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
▪ IT and/or cybersecurity personnel, or contracted professionals, conduct annual penetration testing on network segments hosting High Value Assets (HVAs).

Level 3 Well Defined

Vulnerability & Patch Management (VPM) 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 VPM 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 VPM domain capabilities are well-documented and kept current by process owners.
▪ A vulnerability management team, or similar function, is appropriately staffed and supported to implement and maintain VPM domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of vulnerability management operations (e.g., patch management solution, vulnerability scanning solution, etc.).
▪ 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 VPM 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 conduct penetration testing on Technology Assets, Applications and/or Services (TAAS).

Level 4 Quantitatively Controlled

Vulnerability & Patch Management (VPM) 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.
Impressum German English