EBA ICT Guidelines AI Audit Evidence After the DORA Scope Change
The EBA narrowed its ICT and security risk management Guidelines after DORA began to apply. For AI used in payment-service customer interactions, the remaining evidence question concerns security guidance, customer choices, alerts, updates, and support. This guide builds an audit package around that current scope while separating runtime AI records from adjacent payment controls.
The EBA ICT Guidelines AI audit evidence question changed on 20 May 2025. After the Digital Operational Resilience Act introduced a harmonised ICT risk management framework, the European Banking Authority reduced EBA/GL/2019/04. The EBA's amendment report says most of the older Guidelines became obsolete in substance. The payment service user relationship section remains. If an LLM drafts fraud guidance or handles a security support request, the audit file should prove what the customer received and which controls shaped the response.
I would start by printing the current scope page and placing it at the front of the evidence binder. An auditor should see the legal fork before opening a folder of prompt logs.
TL;DR
- DORA has supplied the harmonised ICT risk framework since 17 January 2025. The amended EBA Guidelines retain payment service user relationship management rather than the former broad ICT control set.
- Build samples around customer security guidance, communicated threat updates, configurable payment functions, transaction alerts, and security procedure notices.
- Runtime AI evidence needs the customer or session context, the approved knowledge version, the model route, the policy decision, the response treatment, a timestamp and an integrity check.
- Payment limits, transaction alerts, case resolution and channel availability sit in adjacent systems. Reconcile those records with AI traffic instead of claiming one gateway proves the full control.
The evidence scope starts with the 2025 amendment
The EBA press release dated 11 February 2025 explains the transition plainly. DORA has applied since 17 January 2025. It introduced harmonised requirements for ICT risk management and incident reporting, then for third-party risk and testing. The EBA then narrowed EBA/GL/2019/04 to avoid duplicated requirements.
The consolidated EBA Guidelines published in May 2026 now say they cover aspects of payment user relationship management and complement DORA. Paragraphs 92 through 98 provide the current anchor for this evidence package. A bank should use the DORA AI compliance framework for the broader operational-resilience file and reserve this package for customer-facing payment security evidence. The two files should not overlap.
Sample selection follows the customer interaction
Start with a population of AI-assisted payment security interactions for the review period. Chatbot answers about suspicious payments belong there. So do agent-assist drafts for fraud cases. Explanations of transaction alerts and security procedure notices count too. Record the query that created the population and its time boundary. The included channels and the exclusions go in the same note.
Select samples across ordinary and adverse conditions. Include an approved answer and an answer that required redaction. Add a request denied by policy and an escalation to a human case queue. A model or knowledge-base change should appear too. The point is reproducibility. A reviewer should be able to locate the same interaction using a stable reference and see the customer-facing result. This is the same evidence principle described in AI agent action lineage, applied to payment-service communications rather than autonomous tool actions.
Each evidence item needs a linked record chain
For paragraph 92 and paragraph 93, retain the approved security guidance version and the threat or vulnerability update that triggered a change. Keep the approval record with the interactions served under each version. An AI response record should identify the authenticated principal or session and the model endpoint. It should carry the policy version and the source-content version. The record then carries the decision and any redaction, plus the final text delivered.
Paragraphs 94 through 96 require evidence from product and payment systems. The account setting proves that a customer could disable an eligible function. The payment platform has to show that an agreed limit could be adjusted within its maximum. Alert evidence comes from the notification service, which proves that initiated or failed transaction alerts were available. Join those artifacts to the AI conversation only when the assistant explained or initiated the relevant workflow. A routed LLM log cannot prove that the underlying payment setting changed.
Integrity and retrieval make the package auditable
Store the sample manifest with a checksum or signature for each exported artifact. Record the extraction time and the query definition beside it, along with the reviewer who approved the package. Preserve raw records under the applicable retention schedule and give the assessor a redacted view. Re-run the query before delivery and explain any population change caused by late-arriving events.
A good evidence room has one index and one naming convention. It also has an obvious gap register. I distrust screenshots as primary audit evidence because a cropped browser window hides the query and the population, and says nothing about the custody trail. Use screenshots only to help reviewers locate the source records. The broader record design in AI audit trail requirements by regulation shows the fields that support cross-regime reuse.
DeepInspect
DeepInspect can produce the runtime slice when the financial entity routes authenticated user or agent traffic to an HTTP LLM endpoint through the gateway. It evaluates application-supplied identity and policy context. Then it permits, redacts or denies the request. The decision goes into the record. That record can bind a customer-support interaction to the model route and the policy version, then to the data treatment and the outcome. The timestamp sits in the same record.
Payment configuration and notification systems still hold the surrounding EBA evidence. So do case management and content approval, along with the customer channels. Direct model calls and opaque AI embedded inside a vendor remain outside the record unless their traffic is routed through the enforcement point. Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- Did DORA repeal the EBA ICT and security risk management Guidelines?
The EBA amended EBA/GL/2019/04 rather than erasing the document. Its February 2025 report says the scope was reduced to payment service user relationship management, with the other parts repealed because DORA covered the broader ICT framework. The amended Guidelines applied by 20 May 2025. Treating the original 2019 control set as the current banking ICT baseline would therefore create a stale audit map.
- Which AI interactions belong in the evidence population?
Include AI interactions that communicate payment-security guidance or explain threat updates. Include the ones that support a customer reporting an anomaly or assist with an eligible payment-control workflow. Define the channels and review period before sampling. General marketing conversations and internal employee copilots belong elsewhere unless they directly support the scoped customer-security process.
- Can a prompt log prove compliance with paragraphs 94 through 96?
A prompt log proves only what crossed the routed AI boundary. Paragraphs 94 through 96 address product-function controls and spending-limit options. They also address transaction alerts. Evidence for those outcomes comes from payment and account configuration systems. Notification systems hold the rest. The AI record can show what was explained or requested, then a correlation key should connect it to the system that executed the action.
- What makes an AI response reproducible for an assessor?
The package should preserve the model route and the approved source-content version. The policy version and the input reference belong there too, with the output delivered. So do the data treatment and the timestamp. It should also record the sampling query and extraction time. If the model itself is nondeterministic, reproducibility means reconstructing the governed transaction and its controls, rather than promising an identical generated sentence.
- How should a bank handle an opaque vendor chatbot?
Ask the vendor for interaction records and the model and knowledge-base change history. Escalation events go on the same list, with retention terms and export procedures. Route the model traffic through an enterprise-controlled HTTP enforcement point where the architecture permits it. If the vendor keeps the route opaque, record the evidence limitation in the gap register and support it with contract and testing controls, backed by DORA monitoring.