DORA Articles 28-30: Third-Party ICT Risk Management

Asqav slots into the third-party ICT risk-management posture that EU Regulation 2022/2554 (the Digital Operational Resilience Act, DORA) Articles 28-30 set out for in-scope financial entities. The signed-receipt layer produces continuous compliance evidence that supports the audit-rights leg of the regulation, with no bespoke instrumentation per entity.

DORA reached full effect on 17 January 2025 for EU financial entities. Asqav addresses the AI-agent slice of that posture.

What DORA 28-30 governs: how a financial entity manages its ICT third-party providers, which contract clauses are mandatory, and what continuous oversight it must perform.

Where Asqav fits: it reads as an ICT third-party service for the AI-agent evidence layer. The entity records Asqav in its register, exercises the audit rights the contract grants, and uses the receipt stream as continuous-monitoring evidence.

What the receipts give the auditor: a competent authority can verify the receipt set offline, against the public verify key, with no dependency on Asqav.

What the relevant articles say

Three articles carry the obligations Asqav maps onto:

How the signed receipts demonstrate continuous compliance

Each clause of Article 30 maps onto something Asqav already serves:

• Article 30(3)(a) asks for a description of the functions the provider supplies. Asqav describes one function: receive an action from the entity's AI agent, sign a receipt over the canonical envelope, and retain it under the agreed terms.
• Article 30(3)(f) asks for cooperation with the competent authority and access to information. Asqav publishes the verify key at GET /.well-known/jwks.json and the wire format at draft-marques-asqav-compliance-receipts on the IETF Datatracker. The authority verifies the receipt set offline, with no dependency on Asqav.
• Article 30(2)(e) asks for the right to monitor the third party's performance on an ongoing basis. The signed-receipt stream is the monitoring artefact.

Each receipt carries the principal, the action, the request digest, the result digest, the time of signing, and the policy decision that gated the action. The entity's continuous-monitoring function reads the stream against its policy expectations and surfaces deviations in real time.

How Asqav slots into the third-party ICT register

DORA Article 28(3) requires the register to capture, per Pillar III ITS:

• the contractual arrangement
• the ICT services category
• whether the service supports a critical or important function
• the location of the data
• the subcontracting chain
• the substitutability of the provider.

Asqav publishes the inputs the financial entity's third-party-risk team needs to complete the register:

• The legal entity name, jurisdiction, and incorporating jurisdiction.
• The data-processing locations for the deployment pattern in use (multi-tenant SaaS, BYO HSM customer-isolated, on-prem self-host with attested boot).
• The subcontractor list (cloud-infrastructure vendors and key-management vendors, with their locations).
• The substitutability assessment: the wire format is published as an IETF Internet-Draft, the verify procedure is open source, and the offline evidence pack is portable. A financial entity can transition off Asqav for new receipts at any time without losing the verifiability of past receipts.

The third-party-risk team writes Asqav into the register against the appropriate ICT services category (recordkeeping / audit-trail), marks the critical-or-important flag according to the entity's own risk classification of the AI-agent function, and captures the substitutability inputs above.

DORA Tier-1 entities and oversight by the European Supervisory Authorities

DORA also introduces an oversight framework for critical ICT third-party service providers (CTPPs), where the European Supervisory Authorities (the EBA, ESMA, and EIOPA acting jointly) directly oversee third parties whose disruption would have systemic effects. The CTPP designation is made by the Joint Committee against criteria laid out in Article 31.

Asqav does not hold a CTPP designation under Article 31. Customers whose own risk classification places them in DORA Tier 1 retain full audit rights against Asqav under Article 30 regardless of CTPP status. The Article 30 audit-rights leg is the load-bearing surface for Tier-1 entities. The CTPP framework is the regulator's oversight surface and applies to the third party directly.

How to wire Asqav into a DORA-compliant posture

1. Identify the AI agent action surfaces that touch the financial-entity functions covered by DORA (the ICT functions supporting critical or important business activities). These are the surfaces the audit-rights clause covers.
2. Wire the Asqav SDK at each surface so every action produces a signed receipt before the action takes effect. The SDK defaults to compliance_mode=True. Receipts missing required fields are rejected at the signer.
3. Engage Asqav for the commercial terms that cover the Article 30 mandatory provisions: description of services, audit rights, cooperation with the competent authority, substitutability, and termination. Contact info@asqav.com for the contractual templates that reflect those clauses.
4. Add Asqav to the third-party ICT register per Article 28(3) and the Pillar III ITS. The inputs above match the register fields.
5. Wire the receipt stream into the financial entity's continuous-monitoring function. The stream is the evidence the Article 30(2)(e) ongoing-monitoring obligation rests on.
6. On inbound competent-authority engagement, produce the receipt set with asqav audit-pack export and direct the authority to the public verify key for offline verification.

Customer questions about the contractual or operational arrangement: info@asqav.com.

Adjacent surfaces in the DORA cluster

• Article 5 (ICT risk management framework): the AI-agent receipt stream feeds into the entity's ICT risk reporting.
• Article 8 (identification): every AI-agent action surface that produces a receipt is an identified information asset.
• Article 17 (ICT-related incident management): the receipt stream surfaces deviations the incident classifier reads.
• Article 24 (digital operational resilience testing): the audit-pack export is the artefact a TLPT or scenario-based test would inspect.
• Article 30 (key contractual provisions): the contract Asqav signs with the customer covers the mandatory clauses above.