newsonline24

Artificial intelligence does not create entirely new types of cybersecurity risks. However, it does change the speed , scale , and sophistication of known attack patterns. Vulnerabilities can be identified and exploited more quickly, working exploits can be created faster, phishing and social engineering attacks can be made more convincing, and attacks can be automated to a greater extent. Added to this are risks arising from software supply chains , open-source components , cloud environments , and outsourced ICT services .

The European Central Bank describes this development as a long-term shift in the threat landscape. AI does not necessarily create entirely new types of attacks, but it can significantly increase the speed and scale of established cyberattacks. The focus, therefore, is not on isolated AI-specific regulations, but rather on whether institutions can adapt their existing protection, detection, response, and recovery capabilities to this accelerated threat environment.

For less significant institutions (LSIs ), the ECB letter of 7 July 2026 does not impose a general obligation to submit an AI cybersecurity action plan to an ECB Joint Supervisory Team by 31 October 2026. The letter is explicitly addressed to significant institutions (SIs) and calls on them to submit a risk-based action plan to their relevant Joint Supervisory Team by 31 October 2026 .

For LSIs, the letter nevertheless sends a clear supervisory signal. The crucial factor is not whether an LSI adopts an SI-specific action plan. What matters is whether the institution can demonstrably prove that it has identified, assessed, prioritized, addressed, tested, and reported AI-accelerated cyber risks to its governing body.

DORA does not require complete risk-free operation or a fully modernized ICT landscape at all times. Rather, it demands an appropriate, comprehensive, documented, and effective ICT risk management framework. This framework must be aligned with the size, overall risk profile, and nature, scope, and complexity of the business activities. Proportionality does not reduce the obligation for effective risk management; instead, it determines the appropriate design of governance, controls, documentation, and resources.

Therefore, LSIs do not typically require a separate, dedicated AI program. A documented, risk-based DORA management review is appropriate. This should include the individual ICT landscape, critical or important functions, external attack surfaces, outsourcing and service provider dependencies, open vulnerabilities, and known audit or regulatory findings.

II. Responsibility of the Board of Directors and Management

Article 5, paragraph 2 of DORA assigns clear governance responsibilities to the governing body. The governing body defines, approves, monitors, and is responsible for the implementation of the ICT risk management framework. This includes, in particular, establishing an appropriate risk tolerance for ICT risks, approving relevant strategies and policies, providing sufficient resources, and regularly reviewing the effectiveness of the framework.

This does not mean that the board of directors or management must personally implement individual technical measures, approve security updates, or review individual log data. Such tasks should be delegated operationally to IT, information security, data protection, business continuity management, outsourcing management, compliance, and relevant departments.

However, the responsibility for the following remains non-delegable:

• The establishment of appropriate ICT risk governance.
• The definition of risk tolerances, escalation paths and decision-making rights.
• Providing the responsible functions with sufficient human, financial and technical resources.
• Monitoring of key ICT, cyber, resilience and third-party risks.
• The decision on essential measures, priorities and temporary residual risk acceptances.
• Tracking critical actions, exceptions, and escalations.
• Regular review of the effectiveness of the ICT risk management framework.

Personal liability does not automatically arise from a cyber incident, a DORA violation, or a regulatory finding. In the case of a stock corporation, internal liability under Section 93 Paragraph 2 of the German Stock Corporation Act (AktG) generally requires that a member of the management board culpably breaches their duties and that the company suffers damage as a result. A corresponding standard of liability applies to managing directors of a limited liability company (GmbH) under Section 43 Paragraph 2 of the German Limited Liability Companies Act (GmbHG) .

However, a supervisory finding or a DORA violation can be a significant indication that organizational, informational, monitoring, or response obligations have not been adequately fulfilled. The decisive factors always remain the individual case, the specific scope of duties, the available information, the quality and documentation of the decision-making process, any potential negligence, and any damage to the company.

The situation becomes particularly critical when known risks are not addressed despite clear indications, decision-relevant information does not reach the management body, resources are not provided despite documented gaps, exceptions continue indefinitely, or decided measures are not implemented despite repeated escalation.

The reliable management formula is:

Identify risks. Decide on measures. Monitor implementation. Document residual risks.

III. The 5-Point Plan

1. Assess the impact and vulnerabilities

The first step is not a new AI policy. What is needed is an ad-hoc review and update of the existing ICT risk analysis.

The key question is:

Where can an AI-accelerated attack lead to business disruption, data leakage, fraud, manipulation, impairment of critical or important functions, or a serious ICT-related incident?

Article 8 of DORA requires financial institutions to identify, classify, and document all ICT-supported business functions, information assets, and ICT assets. This includes recording dependencies on third-party ICT service providers. For institutions that do not qualify as micro-enterprises, the risk posed by legacy ICT systems must also be adequately considered.

The assessment should include at least the following areas:

• Customer portals, online banking, mobile banking, web applications and APIs.
• VPNs, remote access, external remote maintenance and administratively usable interfaces.
• Cloud tenants, SaaS applications, and cloud management accounts.
• Identity, authorization, and privileged administration systems.
• Payment transactions, core banking processes, credit, trading and reporting processes.
• AML transaction monitoring, sanctions screening, KYC systems and video identification procedures.
• Backup, recovery, logging, SIEM, EDR and security orchestration systems.
• Unsupported, end-of-life, or legacy systems that are difficult to patch.
• Critical third-party ICT service providers, key sub-service providers and relevant open-source components.
• Critical data sets, cryptographic keys, interfaces and automated data transfers.

Not only the individual system, but the specific attack path must be evaluated:

Entry point → Compromise → Expansion of privileges → Lateral spread → Business damage

An attacker could, for example, exploit a vulnerability in a customer portal or a compromised cloud administrator account. This could lead to unauthorized access to customer data, payment fraud, manipulation, disruptions in payment transactions, or the spread of the attack to other systems.

The assessment should therefore also include whether an attack can be detected, contained, and forensically investigated in a timely manner using existing protective measures. These include, in particular, multi-factor authentication, least-privilege concepts, protection of privileged accounts, network segmentation, EDR, SIEM, centralized logging, and robust escalation channels.

Result:  A top 10 list of the most significant AI-accelerated cyber risks, including risk owner, affected asset or process, attack path, existing controls, residual risk, action, deadline, and escalation status.

2. Realistically test vulnerability, patch and mitigation management

A patch policy does not prove that an institution is capable of taking action in the event of a critical vulnerability.

Article 10 of Delegated Regulation (EU) 2024/1774 requires documented procedures for vulnerability and patch management. These include reliable information sources, risk-based automated vulnerability scans, prioritization of patches and other countermeasures, monitoring and verification of remediation, and documentation of identified vulnerabilities and their status.

For ICT assets that support critical or important functions, the Delegated Regulation requires automated vulnerability assessments to be carried out regularly, at least weekly. Prioritization must consider not only technical scores, but also the specific threat landscape, the exposure of a system, its importance to business processes, and its potential impact on critical or important functions.

Management reporting should therefore not stop at general patch rates. The following questions are particularly crucial:

• Which systems are not scanned, not patched, or not adequately monitored?
• Which critical or high-priority vulnerabilities are overdue for improvement?
• Which open vulnerabilities affect externally accessible, privileged, or business-critical systems?
• Are there any indications of active exploitation or relevant threat intelligence reports?
• Which systems cannot be patched in the short term due to legacy systems, vendor dependency, or operational restrictions?
• Is there a documented compensatory control in place for every weakness that cannot be remedied in the short term?
• Who can order emergency measures outside of regular change windows?
• Do exceptions have an owner, a justification, a risk assessment, compensating controls, a deadline, and an expiry date?
• Is the fix technically verified, or is only the patch installation documented?

CVSS scores alone are not sufficient. A vulnerability rated as medium technically can be business-critical if it affects an externally accessible customer portal, privileged access, a cloud management account, or a critical ICT-supported function.

Institutions should test the emergency procedure in practice at least once. A suitable scenario is an actively exploited critical vulnerability in an externally accessible system for which no vendor patch is yet available.

It then needs to be examined whether the institute can implement suitable countermeasures in the short term, for example:

• Shutdown or restriction of the affected function.
• Segmentation or additional network filtering.
• Restriction of external access.
• Further refinement of MFA and privileged authorizations.
• Increased monitoring of logs, data leaks, and indicators of compromise.
• Use of a virtual patch, a web application firewall, or other suitable protective measures.
• Activation of an emergency operation or an alternative access route.

Result:  A vulnerability, patch and mitigation dashboard with P1/P2 vulnerabilities, affected systems, due dates, exceptions, compensating controls, escalations, residual risks and management reporting.

3. Managing third-party ICT service providers and supply chains to be crisis-proof

DORA does not treat third-party ICT risks as merely a matter of procurement, contracts, or outsourcing. Using cloud, SaaS, managed security, hosting, telecommunications, or core banking service providers does not shift the responsibility for regulatory compliance to the provider.

Article 28 of DORA requires that third-party ICT risks be managed as an integral part of the ICT risk management framework. Article 30 of DORA contains additional requirements for contractual agreements concerning the use of ICT services, particularly services supporting critical or important functions. These include, among other things, provisions regarding service descriptions, data locations, availability, incident support, audit and access rights, termination rights, and transition and exit arrangements.

First, examine the ten to twenty most important ICT service providers. Prioritize providers that support critical or important functions, have privileged access, process central data, or represent a single point of failure.

The following should be checked in particular:

• What critical or important function does the service provider support?
• What data does it process and which systems can it access administratively?
• How quickly does he inform you about critical vulnerabilities, active exploitation, security incidents, and relevant changes?
• Are there robust patch, mitigation, incident, and recovery SLAs in place?
• Is there a functioning 24/7 escalation contact?
• Are information, access, audit and instruction rights sufficiently designed and practically usable?
• Are key subcontractors, sub-outsourcing providers, and relevant supply chains transparent?
• Is there reliable evidence regarding backup, recovery, logging, and security monitoring?
• Is there a plausible exit, transition, or substitution strategy?
• What are the risks of concentration, lock-in, or single-point-of-failure?
• Can the institute realistically assess the impact of a provider outage or compromise on critical business processes?

The ECB explicitly identifies the review of third-party governance, including critical ICT providers and dependencies on third-party software and open-source sources, as a priority area for action in the face of AI-accelerated cyber threats. This does not obligate LSIs to adopt an SI-specific action plan. However, it provides a comprehensible, risk-based benchmark for prioritizing their own measures.

Result:  A provider and supply chain map showing criticality, supported function, concentration risk, available evidence, open contract or SLA gaps, responsible party, and prioritized remediation plan.

4. Demonstrate Detection, Incident Response and Recovery

A backup alone is not proof of resilience. Resilience only becomes apparent when an attack is detected in time, contained, investigated, communicated, and a controlled restart can be carried out.

AI-accelerated attacks shorten the time between initial compromise, privilege escalation, lateral movement, and potential business damage. Institutions should therefore effectively monitor external applications, cloud management accounts, privileged access, identity events, API access, suspicious data transfers, and relevant indicators of compromise.

The following aspects in particular should be examined:

• Are security-relevant logs stored centrally, completely, and for a sufficient length of time?
• Are customer portals, cloud management accounts, VPNs, administrator access, and critical interfaces included in the monitoring?
• Are unusual admin logins, impossible travel patterns, permission changes, mass downloads, and atypical data leaks detected?
• Can EDR, SIEM, SOAR or similar systems prioritize alarms and escalate them to the appropriate departments?
• Is there a reliable 24/7 response capability or contractually regulated external support?
• Can forensically relevant data be secured before systems are cleaned, shut down, or restored?
• Do escalation and crisis communication still work when email or collaboration tools are impaired?

The use of AI-supported detection or defense tools can be useful. However, it does not replace clear responsibilities, human review, reliable data quality, documented decision-making processes, or appropriate control mechanisms.

Articles 17 to 19 of the DORA (Digital Operational Resilience Assessment) regulate requirements for the management, classification, and reporting of ICT-related incidents. The digital operational resilience tests according to Articles 24 and 25 of the DORA serve to regularly review the effectiveness of ICT systems, controls, and processes.

Conduct at least one tabletop exercise. A realistic scenario is:

• A critical zero-day vulnerability affects an external access platform. There are indications of active exploitation. Simultaneously, unusual administrator logins and suspicious data transfers have been detected. The provider will not be able to patch until the following day. The customer portal may need to be restricted or shut down.

The exercise was designed to force concrete decisions:

• Who classifies the incident and activates crisis mode?
• Who decides on shutdown, emergency operation or limited continued operation?
• Which forensic data must be secured immediately?
• When will the board, data protection, compliance, communications, outsourcing management and specialist departments be involved?
• When should a DORA notification of a serious ICT-related incident be reviewed?
• How does the crisis team communicate when internal communication systems fail?
• Can critical applications be restored within the planned restart time?
• Can data be recovered consistently and within the defined data loss window?
• Are lessons learned mandatoryly incorporated into the register of measures, the risk analysis, and the control architecture?

Result:  A test protocol, documented crisis decisions, secured evidence, lessons learned, a binding register of measures and a reliable restore record.

5. Make the board of directors capable of making decisions

The board doesn’t need an 80-page technical report. It needs a reliable basis for decision-making with clear risks, impacts, measures, resource requirements, and decision points.

A proven approach is an executive summary of two to four pages, supplemented by technical appendices. It should contain at least the following:

• The five to ten most important ICT, cyber and third-party risks.
• Significant external attack surfaces and insufficiently covered systems.
• Open critical and overdue weaknesses, including exceptional and compensatory situations.
• Risks arising from legacy, end-of-life, and non-patchable systems.
• Significant detection and monitoring gaps.
• Critical provider, sub-service provider and concentration risks.
• Results from incidents, drills, restore tests, and control audits.
• Actions, owner, deadlines, budget requirements, dependencies and escalation status.
• Temporary residual risks and necessary management decisions.

The board should explicitly and comprehensibly document at least three decisions:

• Which critical risks, systems, and measures are prioritized?
• What human, financial, and technical resources will be provided?
• Which residual risks are accepted on a temporary basis, under which compensating controls and until what date?

Furthermore, the board should ensure that the changed threat landscape is incorporated into training, awareness, and crisis exercise programs. This includes, in particular, AI-optimized phishing, convincing CEO fraud and deepfake scenarios, the misuse of privileged access, atypical payment instructions, and secure and tested escalation channels.

Article 5 DORA does not require the governing body to design individual technical solutions. However, it does require the governing body to effectively manage and monitor the ICT risk management framework and to assume responsibility for its implementation.

Result:  A board proposal, a documented resolution, an action and escalation mechanism, and a fixed reporting schedule.

IV. Conclusion

The ECB letter of 7 July 2026 does not impose a general obligation on LSIs to submit an SI-specific AI cybersecurity action plan to a Joint Supervisory Team by 31 October 2026.

However, the ECB letter shows which topics the supervisory authority is currently prioritizing: protection of external attack surfaces, accelerated vulnerability and patch management, monitoring and detection, control of critical ICT third parties and supply chains, defense-in-depth, legacy risks, and tested incident and recovery capabilities.

The appropriate response from a low-risk entity (LSI) is not an abstract, special AI program unrelated to the actual risk situation. A concise, documented, and risk-based DORA management review is more effective.

Identify critical risks. Prioritize control gaps. Decide on measures. Test effectiveness. Document residual risks. Enable the board to make decisions.

The mere existence of a separate AI policy is not the decisive factor. What matters is whether the institution effectively, appropriately, and transparently manages its actual ICT risks. Furthermore, if the institution itself uses AI systems, additional requirements arising from AI governance, data protection, information security, model risk management, and the AI ​​Act may become relevant.

S+P Editorial Team

V. List of Sources

European law

Official Journal of the European Union – Regulations

Regulation (EU) 2022/2554  of the European Parliament and of the Council of 14 December 2022 on digital operational resilience in the financial sector and amending Regulations (EC) No 1060/2009, (EU) No 648/2012, (EU) No 600/2014, (EU) No 909/2014 and (EU) 2016/1011 (Digital Operational Resilience Act – DORA), OJ L 333, 27 December 2022, p. 1:  https://eur-lex.europa.eu/…:32022R2554 , accessed on 15 September 2026.

Of particular relevance are: Article 5 on the responsibility of the governing body, Article 6 on the ICT risk management framework, Article 8 on the identification and classification of ICT assets, Articles 17 to 19 on the management, classification and reporting of ICT-related incidents, Articles 24 and 25 on testing of digital operational resilience, and Articles 28 to 30 on ICT third-party risks and contractual agreements.

Commission Delegated Regulation (EU) 2024/1774  of 13 March 2024 supplementing Regulation (EU) 2022/2554 of the European Parliament and of the Council with regard to regulatory technical standards laying down instruments, methods, processes and strategies for ICT risk management and the simplified ICT risk management framework, OJ L 25, 2024:  https://eur-lex.europa.eu/…:32024R1774 , accessed on 15 September 2026.

Of particular relevance are Article 3 on ICT risk assessment, Article 5 on ICT asset management policy, and Article 10 on vulnerability and patch management.

National law Germany

Federal law

Stock Corporation Act (AktG)  of 6 September 1965, Federal Law Gazette I p. 1089, as amended:  https://www.gesetze-im-internet.de/… , accessed on 15 September 2026.

Of particular relevance: Section 93 of the German Stock Corporation Act (AktG) concerning the duty of care and responsibility of the members of the management board.

German Limited Liability Companies Act (GmbHG)  in its currently valid version:  https://www.gesetze-im-internet.de/… , accessed on September 15, 2026.

Of particular relevance: Section 43 of the German Limited Liability Companies Act (GmbHG) concerning the duty of care and responsibility of managing directors.

Official publications and supervisory practice

European Central Bank (ECB) – Banking Supervision:  Addressing AI-enabled cybersecurity threats , Letter from the Chair of the ECB Supervisory Board of 7 July 2026 to the Chief Executive Officers of significant institutions under direct ECB supervision:  https://www.bankingsupervision.europa.eu/… , accessed on 15 September 2026.

Relevance to this article: The letter is addressed to significant institutions and calls for a risk-based action plan to be submitted to the responsible Joint Supervisory Team by October 31, 2026. The ECB focuses in particular on protecting against external attack surfaces, accelerating vulnerability and patch management, monitoring and detection, third-party and supply chain risks, defense-in-depth, legacy risks, and incident response and recovery.