CSSF AI Communique: Mapping Frontier Cyber Risk to DORA

ByOfficer

On 7 July 2026 the Commission de Surveillance du Secteur Financier (CSSF) published a communique, “Evolving opportunities and risks in artificial intelligence and its adoption”, addressed to the entities it supervises. The CSSF AI communique responds to a specific concern: frontier AI models have the potential to shrink drastically the gap between vulnerability disclosure and active exploitation, while the CSSF says that, in most cases, vulnerability scans are not sufficiently frequent and fixes often arrive too late. That combination is the problem the communique wants management bodies to own.

The document introduces no new template, filing deadline, or return. For entities within DORA’s scope, the communique links its expectations and recommendations to ICT risk-management requirements that have applied since 17 January 2025; for other supervised entities, it refers to relevant national regulations. Some measures correspond directly to DORA or Commission Delegated Regulation (EU) 2024/1774, while others are CSSF advice rather than requirements expressly stated in DORA, including a minimum package age, phishing-resistant multi-factor authentication, a dedicated no-patch scenario and AI-assisted defence.

For an ICT risk officer or a member of a management body, that mapping is the entire practical point. The communique identifies the control areas on which the CSSF is expressing concern and giving advice, but it does not state an inspection sequence or identify where the CSSF will look first. This note walks each piece of the CSSF’s advice back to the DORA article it sits under, distinguishing binding DORA and RTS provisions from CSSF recommendations, so a Luxembourg entity can turn a two-page communique into evidence it can put in front of a supervisor.

Related reading: ECB AI Cybersecurity Letter: DORA ICT Risk Reporting

What the CSSF AI communique changes, and what it deliberately does not

Start with status, because it governs how you treat everything that follows. A CSSF communique is a supervisory expectation. It sits below a regulation or a technical standard, does not amend DORA, does not create a new data collection, and does not carry a submission date. Reading it as a new reporting obligation would be the first mistake, because there is no template attached and nothing to file on its account.

What the communique does is identify areas of supervisory concern. The CSSF states that vulnerability scans are often insufficiently frequent, fixes often arrive too late, a considerable number of entities do not review network-security safeguards as frequently as required, and automated, frequent reviews of secure-configuration baselines are missing. For financial entities subject to the full ICT risk-management framework in Title II of Commission Delegated Regulation (EU) 2024/1774, automated vulnerability scanning and assessments of ICT assets supporting critical or important functions must occur at least weekly; network architecture and network-security design must be reviewed once a year, or periodically for microenterprises; and firewall rules and connection filters for ICT systems supporting critical or important functions must be reviewed at least every six months. Entities subject to the simplified framework in Title III instead follow the risk-based requirements in Articles 34 and 35, which do not set those same minimum frequencies. The communique does not state what the CSSF will inspect next or prescribe a specific inspection checklist.

The scope is narrower than “everyone”. The communique is addressed to supervised entities and is flagged as relevant for central securities depositories, credit institutions, data reporting service providers, investment firms, issuers of tokens, payment and electronic money institutions and account information service providers, specialised PFS, support PFS, and virtual asset service providers. The CSSF frames the governance expectation “in line with the ICT risk management requirements set out in [DORA] or other relevant national regulations”, which is an explicit acknowledgement that some supervised entities sit under national ICT rules rather than DORA. Map yourself to the right regime before you map the controls.

Dates that matter

The communique itself carries no deadline of its own, though it sits inside a short cluster of dated items that a Luxembourg entity should log:

  • DORA (Regulation (EU) 2022/2554) has applied since 17 January 2025. The obligations the communique points to are already live.
  • The Financial Stability Board published its consultation report, “Sound Practices for Responsible Adoption of Artificial Intelligence (AI)”, on 10 June 2026.
  • The European Systemic Risk Board issued its warning that frontier AI models could strain cyber resilience in the financial system on 7 July 2026, the same day the CSSF communique was published.
  • 22 July 2026 is the deadline for comments on the FSB consultation. This is the only forward-looking action date in the package, and it opens a consultation response window; no CSSF filing attaches to it.

None of these dates triggers a CSSF submission. The value of the list is that it lets a reporting team separate a genuine deadline, the FSB comment window, from the standing DORA obligations that the communique is reminding everyone about.

The governance expectation lands on DORA Article 5

The heaviest sentence in the communique is the one aimed at the top of the house. The CSSF expects all members of the management body to establish governance structures that support effective management of frontier AI related risk, to monitor that risk closely, and to support strengthening the organisation’s resilience against AI-enabled threats. That expectation restates a duty DORA already imposes on full-framework entities through Article 5 (Article 16(1) simplified-framework entities carry the analogous duty under RTS Article 28 instead), with a sharper edge for AI.

DORA Article 5 places ultimate responsibility for managing ICT risk on the management body and requires it to define, approve, oversee and be responsible for implementation of the ICT risk-management framework, for entities within the full DORA framework; Article 16(1) simplified-framework entities carry an analogous governance duty under Article 28 of Commission Delegated Regulation (EU) 2024/1774 rather than Article 5 itself. The communique expects all management-body members to establish governance structures supporting effective management of frontier-AI-related risk, monitor that risk closely and support stronger resilience against AI-enabled threats. Management-body minutes, an approved action plan and documented progress reviews are practical evidence options, but the communique does not prescribe a particular governance artefact or state that board minutes are mandatory.

A common misreading here is to treat this as a job for the CISO alone. The communique is explicit that it addresses “all the members of your management body”, and Article 5 makes ICT risk a collective board responsibility for full-framework entities (RTS Article 28 for Article 16(1) simplified-framework entities). Pushing the whole topic down to a technical function would be inconsistent with the CSSF’s express expectation that all management-body members closely monitor frontier-AI-related risk and support stronger resilience against AI-enabled threats.

Reduce the attack surface, and the DORA identification duty behind it

The communique’s first measure is to reduce the attack surface: cut internet-exposed systems, treat edge devices and VPN appliances as leading entry points, and decommission end-of-life and unsupported technology because no amount of patching secures a component the vendor no longer fixes. It closes the point with the observation that an accurate ICT asset inventory is a prerequisite for reducing the attack surface at all.

That prerequisite is DORA Article 8, on identification. For entities within the full DORA framework, Article 8 requires financial entities to identify, classify, and document all ICT-supported business functions, the information assets and ICT assets supporting them, and their interdependencies, and to review that mapping regularly. Article 8(7) adds a specific duty to identify and periodically review the risks tied to legacy ICT systems. Article 16(1) simplified-framework entities instead follow the identification and classification duty in Article 30 of Commission Delegated Regulation (EU) 2024/1774. Further detail sits in the ICT asset management provisions of Commission Delegated Regulation (EU) 2024/1774, which differ depending on whether the entity falls under the ordinary or the simplified framework, as set out below.

For entities subject to the full framework in Title II of Regulation (EU) 2024/1774, the ICT asset-management records include whether an asset is exposed to external networks and, where applicable, the end-dates of provider support. Entities subject to the simplified framework must identify and classify assets supporting critical or important functions, manage their lifecycle and monitor whether they remain supported, but Title III does not prescribe those same two record fields. The practical response is therefore to query the records required by the entity’s applicable framework for internet-facing and unsupported or end-of-life assets and act on the results.

Patch by exposure and exploitability, not by severity score

The communique is unusually direct on patch management. It tells entities to stop letting theoretical severity scores drive the queue, because a vulnerability rated critical on paper is not always the one attackers will actually weaponise. Priority should follow exposure and exploitability: is the system internet-exposed, is the flaw already being exploited in the wild, is it on a Known Exploited Vulnerabilities list, is there a high probability of real-world exploitation. The CSSF also flags a caveat that matters in an AI-accelerated world: a freshly AI-discovered zero-day is by definition not yet listed or scored, so exposure has to be weighted as a first-class criterion and compensating controls applied when neither a patch nor a reliable score exists.

For entities subject to the full framework in Title II of Commission Delegated Regulation (EU) 2024/1774, Article 10 requires risk-based automated vulnerability scanning, with at least weekly scanning and assessments for ICT assets supporting critical or important functions. It also requires patch and mitigation prioritisation by vulnerability criticality, asset classification and asset risk profile, together with installation deadlines and escalation procedures. Entities under the simplified framework instead follow Article 34, which requires automated scanning commensurate with asset classification and risk profile and the deployment of patches, without the Title II weekly minimum. The CSSF adds exposure and real-world exploitability as recommended prioritisation factors and advises compensating controls where no patch or reliable score exists.

Containment, detection, and the “assume breach” posture

Several of the communique’s measures share one assumption: some cyberattacks will succeed, and the ICT environment has to be engineered so that a single compromised account, server, or application does not become a company-wide incident. The CSSF lists network segmentation, zero-trust principles, separation of privileged access through an identity tier model, frequent rotation of credentials and tokens, phishing-resistant multi-factor authentication, strict access controls between environments, and strong monitoring of privileged actions. It adds proactive threat hunting for the most critical systems, and a dedicated “no-patch-exists” response scenario with pre-built, tested containment measures and a defined authority to trigger them.

These measures align with broader DORA controls, but they are not all specified DORA requirements. For entities within the full DORA framework, network segmentation aligns with DORA Article 9 and Article 13 of Commission Delegated Regulation (EU) 2024/1774; access control and strong authentication align with Articles 20 and 21 of that RTS; anomalous-activity monitoring aligns with DORA Article 10; and containment and recovery align with DORA Article 11. DORA Article 16(1) disapplies Articles 5 to 15 for the simplified-framework entities named in that Article, which instead follow Articles 33 to 35 of the same RTS for access control, ICT operations security and network security. DORA and the RTS do not expressly prescribe the CSSF’s formulations of zero-trust, an identity-tier model, phishing-resistant multi-factor authentication, proactive threat hunting or a dedicated no-patch playbook; those are CSSF-recommended ways to strengthen the broader framework, not proof that an entity already operates every listed control.

One measure needs a careful read. The communique encourages entities to “adopt AI for defence”, integrating AI-assisted vulnerability discovery and threat-hunting, but insists a human reviews the findings and owns the remediation, to avoid false positives and unfit countermeasures. That human-in-the-loop condition is load-bearing. Under DORA the accountability for ICT risk decisions cannot be handed to a tool, and a defence pipeline that auto-remediates without human ownership would sit awkwardly against the governance and risk-treatment duties the framework sets.

Testing is where the expectation becomes checkable

The communique’s final measure is to test cybersecurity defences and incident response plans, from penetration testing through to scenario-based simulation of sophisticated real-world attacks against live systems. This is the part of the advice DORA has already made mandatory and measurable.

For entities within the full DORA framework, Article 24 requires financial entities other than microenterprises to maintain a digital operational resilience testing programme, integral to the Article 6 ICT risk-management framework, and to conduct appropriate tests at least yearly on all ICT systems and applications supporting critical or important functions. Article 16(1) simplified-framework entities are not subject to that Article 24 programme and instead follow the risk-based ICT security testing plan and business continuity plan testing in Articles 36 and 40 of Commission Delegated Regulation (EU) 2024/1774. Article 25 lists test types including vulnerability assessments and scans, network-security assessments, scenario-based tests and penetration testing. Financial entities identified under Article 26 are subject to a baseline TLPT frequency of at least every three years, although the competent authority may require a higher or lower frequency based on the entity’s risk profile and operational circumstances. TLPT covers critical or important functions and the relevant live production systems, processes, technologies and contracted ICT services supporting them; the participation of an ICT third-party service provider is governed by Article 26(3) and (4). Microenterprises instead follow the risk-based testing approach in Article 25(3), a proportionality split covered in our guide to DORA resilience testing for smaller firms.

The communique does not set a new testing frequency. A reasonable implementation response is to incorporate relevant AI-augmented attack techniques and the proposed containment measures into the entity’s risk-based testing scenarios, in line with our note on DORA TLPT for European financial entities. The binding testing frequency and TLPT scope remain those set by DORA and the applicable TLPT rules; the communique itself does not expressly require a distinct AI testing scenario.

Third-party and supply-chain oversight: where the mapping needs care

The topic that most needs a precise touch is third-party risk, because the communique raises two very different supply-chain problems and DORA treats them differently. The first is edge devices, VPN appliances, and vendor end-of-support, hardware and software an entity buys from an ICT supplier. The second is the software development pipeline: supply-chain attacks that target open-source software libraries as an initial-access vector, which the communique addresses with locked-down pipelines, a minimum age for package updates with a security-fix fast-path, and the removal of plaintext secrets.

DORA Chapter V applies to contractual arrangements for ICT services provided by ICT third-party service providers. Article 28 requires a register covering all such contractual arrangements, structured as set out in our walkthrough of the DORA register of information, while Article 30 sets the applicable contractual provisions. A managed service, hardware-as-a-service arrangement, or hardware support service involving ongoing software or firmware support may fall within the register, as our supply-chain register example shows. A one-off purchase of an appliance or software product does not automatically belong in the register merely because it has a named vendor; classification depends on whether the arrangement involves an ongoing ICT service within Article 3(21) and a contractual arrangement covered by Article 28.

The non-example matters just as much. A public open-source library obtained without an undertaking providing an ongoing ICT service is generally not, by itself, a contractual arrangement for the DORA register of information. For entities subject to Title II of Regulation (EU) 2024/1774, Article 10(2)(d) requires the tracking of third-party libraries, including open-source libraries, used by ICT services supporting critical or important functions, while Articles 15 to 17 contain acquisition, development, testing and change-management controls. Entities subject to the simplified framework in Title III instead follow the risk-based controls in Articles 34, 37 and 38; Title III does not reproduce Article 10’s express library-tracking requirement. The CSSF’s minimum-package-age and plaintext-secret measures are additional supervisory advice. Getting the register-versus-secure-development split right keeps the register accurate and puts the library-supply-chain controls where a supervisor will actually look for them.

What actually gets reported, if an AI-enabled attack succeeds

The communique creates no new return. If an event is classified as a major ICT-related incident under DORA and the applicable RTS, the entity must report it to the relevant competent authority through the initial, intermediate and final reporting sequence, as set out in our DORA ICT incident reporting guide. For entities within the scope of Circular CSSF 25/893, the circular sets the practical Luxembourg reporting modalities. Luxembourg branches of financial entities whose head office is in another EU Member State are excluded from the circular and are expected to report under DORA to the competent authority of their home Member State. Because DORA’s classification criteria turn on the incident’s impact rather than the method of attack, an AI-enabled event is assessed the same way as any other major ICT-related incident. Other notification duties may also apply depending on the facts, including data-protection, criminal, sectoral or contractual obligations, so the DORA report should not be described as the only possible filing.

Turning the communique into evidence a supervisor can see

Because the communique is a set of expectations rather than a rule, the useful output for a Luxembourg entity is a short evidence map that ties each expectation to an artefact. The CSSF has not said it will inspect against the communique, so what follows is interpretation, but the controls it names are the controls a DORA review already touches (several of the DORA articles named below apply only to full-framework entities, with Article 16(1) simplified-framework entities following the Title III analogues discussed earlier):

  • Management-body minutes showing AI-augmented cyber risk discussed, an action plan approved, and progress reviewed, evidencing the Article 5 governance expectation.
  • An ICT asset inventory query returning internet-facing and end-of-support assets, evidencing Article 8 identification and the asset-management fields in Regulation (EU) 2024/1774.
  • A vulnerability-management policy that prioritises by exposure and exploitability with a documented compensating-control path for unpatchable or unscored flaws, evidencing Articles 9 and 10.
  • A tested “no-patch-exists” containment procedure with a named trigger authority, evidencing Article 11 response and recovery.
  • A testing programme that includes AI-augmented attack scenarios and, for in-scope entities, the TLPT cycle set under Article 26, evidencing Articles 24 to 26.
  • A register of information and contractual controls covering qualifying vendor arrangements, evidencing Chapter V, with pipeline hardening documented under the secure-development controls.

Much of that should build on an entity’s existing DORA framework, but the CSSF’s additional recommendations, such as a minimum package age, a dedicated no-patch scenario and AI-assisted defence, may require new or enhanced controls. The communique’s contribution is to name, in one place, eight areas of measures and advice that entities are invited to consider against AI-augmented cyberattacks, while recording that the CSSF has observed weaknesses in several existing controls.

Frequently Asked Questions

Does the CSSF AI communique create a new reporting obligation or template?

No. The communique carries no template, filing deadline or return. If an AI-enabled event meets the DORA criteria for a major ICT-related incident, the existing DORA reporting requirements apply. Other notification duties may also arise under separate legal, regulatory or contractual regimes depending on the incident.

Which entities does the communique apply to?

It is addressed to CSSF-supervised entities and flagged as relevant for central securities depositories, credit institutions, data reporting service providers, investment firms, issuers of tokens, payment and electronic money institutions and account information service providers, specialised PFS, support PFS, and virtual asset service providers. The CSSF frames the governance expectation as applying in line with DORA or other relevant national regulations, so an entity should first confirm whether it sits under DORA or a national ICT regime.

Is the management-body expectation a new governance duty?

It is a sharpening of an existing one. DORA Article 5 already makes the management body ultimately responsible for the ICT risk management framework for full-framework entities (Article 16(1) simplified-framework entities carry the analogous duty under RTS Article 28 instead). The communique adds the specific expectation that the body understands and steers frontier AI risk, and can show it in governance records, so that the topic is not left entirely to a technical function.

How should we treat open-source software libraries under DORA third-party rules?

A public open-source library obtained without an undertaking providing an ongoing ICT service is generally not, by itself, a contractual arrangement for the DORA register of information. For entities subject to Title II of Regulation (EU) 2024/1774, Article 10(2)(d) requires the tracking of third-party libraries, including open-source libraries, used by ICT services supporting critical or important functions, while Articles 15 to 17 contain acquisition, development, testing and change-management controls. Entities subject to the simplified framework in Title III instead follow the risk-based controls in Articles 34, 37 and 38; Title III does not reproduce Article 10’s express library-tracking requirement. The CSSF’s minimum-package-age and plaintext-secret measures are additional supervisory advice. Managed services and vendor arrangements involving ongoing ICT services may enter the register; a named appliance or software product does not automatically qualify without an arrangement meeting DORA’s ICT-service definition.

Does “adopt AI for defence” mean we can automate remediation?

Not without human ownership. The communique is explicit that a human must review AI-generated findings and own the remediation, to avoid false positives and unfit countermeasures. Under DORA the accountability for ICT risk decisions stays with the entity, so an auto-remediating pipeline with no human in the loop would sit poorly against the framework’s governance and risk-treatment duties.

How does this connect to DORA resilience testing?

The communique’s call to test defences and incident-response plans is already mandatory under DORA. Article 24 requires an annual testing programme for critical or important functions for full-DORA-framework entities other than microenterprises (Article 16(1) simplified-framework entities instead follow RTS Articles 36 and 40 for security testing and business continuity testing), Article 25 lists the test types including penetration testing, and Article 26 requires TLPT at least every three years for in-scope entities on live production systems, a frequency the competent authority may adjust based on the entity’s risk profile. The AI angle mainly shapes the scenarios you test, including whether your containment measures actually hold.

Do we need to respond to the FSB consultation the CSSF cited?

Responding is optional. The CSSF invites entities to review the FSB consultation on sound practices for responsible AI adoption, published 10 June 2026 with comments due 22 July 2026, and the ESRB warning of 7 July 2026. These are context the supervisor wants entities to read, and the 22 July date opens a consultation window rather than a CSSF filing deadline.

Related Articles

Key Takeaways

  • The CSSF AI communique of 7 July 2026 is a supervisory expectation, not a new obligation: it adds no template, deadline, or return.
  • For entities within DORA’s scope, several measures align with DORA and Commission Delegated Regulation (EU) 2024/1774, which have applied since 17 January 2025; other measures are additional CSSF recommendations, and entities outside DORA must identify the applicable national ICT regime.
  • The management-body expectation is a sharpening of DORA Article 5 for full-framework entities (RTS Article 28 for Article 16(1) simplified-framework entities); the CSSF wants the whole board steering frontier AI risk, with the CISO one voice among several, evidenced in governance records.
  • Reduce-the-attack-surface, patch-by-exposure, containment, and testing all sit under DORA Articles 8 to 26 and Regulation (EU) 2024/1774, though several of those DORA articles bind only full-framework entities, with Article 16(1) simplified-framework entities following the Title III analogues instead; the inventory and testing programme built for DORA already hold most of what the CSSF is asking about.
  • The CSSF wants exposure-and-exploitability prioritisation plus a tested fallback for vulnerabilities that cannot yet be patched, and it explicitly rejects blanket faster patching as the goal.
  • Third-party mapping needs care: contractual arrangements for ongoing ICT services fall within the Article 28 register, including qualifying managed, hardware-as-a-service and supported-hardware arrangements. A one-off vendor-appliance purchase does not automatically qualify. Open-source libraries must still be tracked and controlled under the vulnerability-management and secure-development provisions where applicable.
  • The communique creates no new filing. An AI-enabled event that qualifies as a major ICT-related incident triggers the existing DORA reporting regime, driven by the incident’s impact and classification criteria; separate notification duties may also apply under other regimes.
  • The FSB consultation (comments due 22 July 2026) and the ESRB warning of 7 July 2026 are context to review, and neither is an obligation to file.

Sources and References

The communique is a reading of your existing DORA framework

The most useful way for a Luxembourg entity to treat the CSSF AI communique is as a supervisor reading its own DORA rulebook back to the market, with the AI-accelerated threat landscape as the lens. The communique creates no new filing and links the AI-accelerated threat landscape to existing ICT risk-management frameworks. Several measures correspond directly to DORA and Commission Delegated Regulation (EU) 2024/1774, while others are additional CSSF recommendations on how entities should strengthen those frameworks. A Luxembourg entity should therefore map each measure separately: identify the governing DORA or national requirement, distinguish CSSF advice from binding provisions, record any control gap, and evidence the management body’s monitoring and oversight of the resulting action plan.

Last updated: July 2026

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.

Similar Posts