DORA in Iceland: what should your next resilience test prove?

Your next resilience test should establish whether a credible attacker can cross the dependencies of a critical business function - and whether your team can detect, contain and recover from that path. Iceland’s frontier-AI warning makes that question more urgent; it does not turn every supervised organisation’s next engagement into a test of an AI model.

For CISOs and operational-resilience leaders, the buying decision is therefore specific: do you need a targeted technical assessment, preparation for TIBER-IS, or a formally governed TLPT? Start with the decision the evidence must support, rather than purchasing a framework name.

The short version

• Separate the legal basis, the testing framework and the changing threat environment.
• Include AI-enabled attacker risk even when your organisation does not deploy frontier models.
• Commission a bounded attack path with named dependencies, safety rules and evidence owners.
• Do not describe readiness work as a completed TIBER-IS exercise or a compliance certificate.

What the Icelandic sources actually say

Iceland’s Act 78/2025 gives Regulation (EU) 2022/2554, DORA, legal force with the applicable EEA adaptations.[1] The Act entered into force on 1 January 2026.[1] It identifies the Central Bank of Iceland as the competent authority and assigns it responsibility for matters relating to threat-led penetration testing.[1] TIBER-IS is not the legislation that introduced DORA.

The Central Bank describes TIBER-IS as a framework for testing participants critical to Iceland’s financial system, based on TIBER-EU.[4] It also says the framework can be used in other sectors.[4] Its purpose is learning and improved resilience, not a pass-or-fail result.[4] The ECB explains that TIBER-EU can help authorities and financial entities meet DORA’s TLPT requirements.[5] That connection is not permission to label any red-team engagement “DORA TLPT”.

On 18 August 2026, the Central Bank drew supervised entities’ attention to practical measures in the European Supervisory Authorities’ frontier-AI statement: reducing attack surface, accelerating vulnerability discovery and patching, improving monitoring, strengthening governance and supply-chain security, and improving response and resilience.[2]

The underlying statement covers both internal use of frontier models and indirect exposure to their capabilities.[3] Its annex explicitly does not establish additional requirements and is not a comprehensive checklist.[3] Read this as a risk-based supervisory message about cyber resilience—not a blanket instruction to pentest every deployed AI model.

Application: choose the engagement before choosing the scenario

The following is a proposed scoping approach, not an additional regulatory requirement. Ask legal and compliance colleagues to confirm the entity’s DORA position and any supervisory TLPT selection or instructions. An export-SaaS business should not infer its status from the fact that it sells internationally. Establish separately whether its relevant role is that of a regulated entity, an ICT supplier, or a supplier responding to customer assurance demands.

Then distinguish three deliverables. A technical assessment answers whether specified weaknesses and attack paths exist. Readiness work establishes whether scope, dependencies, permissions and organisational arrangements are ready for a larger exercise. A formal TIBER-IS/TLPT engagement requires the applicable governance and authority coordination. These deliverables can inform one another, but they are not interchangeable.

An illustrative scope: from a supplier account to a payment dependency

Consider a fictional payment-service environment. A supplier support identity can reach a management interface connected to a critical payment function. The exercise asks whether misuse of that identity can cross into privileged administration, and whether responders can contain the path without losing the recovery capability. This is an illustrative scenario, not an XPLT client incident or a claim about an Icelandic institution.

Use synthetic records and pre-agreed proof points. No real payment, destructive action or third-party system should enter scope by implication. If a dependency cannot be tested safely, record the limitation and choose an agreed simulation or separate exercise; do not count the omitted step as passed.

Frontier AI changes the threat assumptions you discuss: what if reconnaissance and exploitation become faster, or a shared dependency exposes several services? It does not require the tester to use AI, and it does not justify disruptive production activity. Include a deployed model or connector only where it materially belongs to the selected attack path.

What to put in the scoping brief

• Business objective: the critical function and the decision its owner needs to make.
• Dependencies: identities, applications, infrastructure, suppliers and recovery systems.
• Starting position: what the simulated attacker controls, supported by relevant threat intelligence.
• Authority and safety: permissions, excluded systems, stop conditions, contacts and supplier consent.
• Evidence handling: access, storage, retention and who may receive the findings across borders.
• Closure: remediation owners, retest criteria and unresolved dependencies.

What the result will not prove

A bounded assessment cannot demonstrate resilience against every future AI-assisted attack. Nor does its report establish DORA compliance or guarantee acceptance by another supervisor. Agree the intended audience and recognition process before commissioning the work. Recheck applicable requirements at procurement: this article provides a technical decision framework, not legal advice.

Preparing an Icelandic resilience test? Bring XPLT one critical function, its dependency map and any supervisory instructions. Discuss a scope that separates technical testing, TIBER-IS readiness and formal TLPT requirements.