What DORA Article 30 requires from ICT service contracts
Since 17 January 2025, anyone selling software to financial entities has had to deal with Regulation (EU) 2022/2554, better known as DORA. Banks, insurers, payment providers and many of their suppliers must now manage the ICT supply chain not only technically but contractually. DORA Article 30 is the provision that procurement, legal, security and product teams argue about most, because it defines what an ICT service contract must contain at minimum.
Article 30(2) applies to all contractual arrangements on ICT services. In short, contracts must describe the functions and services clearly, name the locations where data is processed and stored, include data protection provisions, secure access, recovery and return of data in case of insolvency, describe service levels, regulate assistance during ICT incidents, set out cooperation with supervisory authorities, and define termination rights and exit strategies. Article 30(3) adds more for services supporting critical or important functions: precise quantitative and qualitative service levels, reporting duties, contingency plans, participation in testing, and audit rights.
For an ISV that embeds signing into its platform, this creates an awkward double role. Towards the financial customer, the ISV is itself an ICT third-party provider. Towards its signature vendor, it is the client that must pass supply chain questions upstream. A financial entity using your SaaS will eventually stop asking whether the signature is legally valid and start asking where the data sits, who has access, and how you prove the process ran as contractually promised.
That is where contract prose and auditable proof part ways. A contract can promise that locations are disclosed. Whether processing actually happened there only shows in a log that records events immutably and can be queried from outside. The difference between promise and proof is the one hard distinction of this article, and it shapes how you should assess a signature API in a DORA context.
One caveat up front: DORA knows no certification for signature APIs. No seal exists that you can buy from a vendor and then call yourself DORA-compliant. What exists is the obligation of financial entities to manage third-party risk, keep a register of information and present evidence when supervisors ask. Everything below is therefore evidence for those proofs, not a certification. Anyone promising otherwise hands the customer a claim that will not survive the audit.
Why paper, PDF archives and portal logins fail in audits
Most signing processes in finance and insurance SaaS grew historically. A contract is generated, handed to an external portal, the signer clicks through, and a PDF with a certificate page ends up in a folder or attached in the CRM. That works day to day. For a DORA-adjacent review it leaves three gaps that more discipline cannot close, because they sit in the architecture.
First, there is no link between contract content and process. A PDF shows what was signed, not who received which request when, in what order signers acted, whether a process was aborted and restarted, or which document version was valid at which moment. Auditors ask about the process because it shows whether controls actually work.
Second, the evidence sits with the vendor, not with you. If event logs are only visible in the signature vendor's portal, your proof depends on their login, their retention and their export function. When an auditor wants a gapless chain over several months, manual screenshot collecting begins. That neither scales nor holds up, and it is precisely what Article 30 tries to avoid with its requirements on access, return and cooperation with authorities.
Third, jurisdiction stays invisible. The contract may name a data centre in the EU. Who owns the operator and which law can reach it is often missing from the audit package. In our article on GDPR and the US Cloud Act for e-signature APIs we have already broken this down. For DORA, location and control should be documented and evidenced as part of the contract.
Portal solutions make this worse because they pull the process out of your product. The user leaves your interface, your events and the vendor's live in separate systems, and correlation happens by hand later. The background on the break between host system and signing flow is in white-label signing without context switching. In a DORA setting, the media break is not just a UX problem but an evidence gap.
A practical example: an ISV for broker administration supplies advisory records to insurers. In the review the customer asks whether it is traceable that a power of attorney was signed only after the signer was identified and that the document was not altered between dispatch and signature. With a portal and a PDF archive the ISV can only answer with a procedure note. With an API-backed event log it answers with an export.
The API audit trail as an evidence layer for the ICT supply chain
An evidence layer is neither a certification nor a replacement for your register of information. It is the technical layer ensuring that every relevant statement in the contract can be backed by a retrievable data point. For a signature API it consists of three elements: structured events per transaction, unique identifiers that tie events to your business object, and access that lands in your own systems instead of staying in the vendor's portal.
Concretely, every signing transaction produces state changes such as created, sent, opened, identified, signed, declined, expired or revoked. The API delivers these changes by webhook to your system with a timestamp and transaction ID. You store them in your own data store alongside tenant, document version and checksum. How to model this cleanly without burdening your ERP with polling is covered in webhook state management for e-signature events.
From an Article 30 perspective, this produces robust answers to typical audit questions. Which services does the provider deliver exactly? The API documentation and documented event types describe the functions in machine-readable form. Where is data processed? Hosting is named contractually and technically, and you can record it in your register. How are incidents reported? Error and status events are part of the log. How does exit work? Because events and documents can be exported via the API, your proof does not depend on a proprietary portal.
The separation of roles is decisive. The signature level follows the use case: SES for simple consents, AES when signers must be uniquely assigned and changes must be detectable, QES when the law requires the qualified form. Sign2x is not a qualified trust service provider. For QES the qualification runs through a partner QTSP such as Sign8. In all three cases the evidence layer documents the process, but it does not change the legal quality of the signature. An overview is in SES, AES and QES in SaaS.
One point teams often underestimate: the trail is only as good as its schema. If your event model only knows signed and not signed, it yields little evidence. At minimum, useful fields are transaction ID, event type, UTC time, acting role, document hash, signature level and the result of identification, where one took place. With these you can answer questions about sequence, responsibility and integrity without spreading personal content further than necessary.
The video shows how the signing flow fits into an existing interface and which events arise along the way. For this article the state changes are the interesting part: they are the raw material of your audit trail.
Hosting and jurisdiction as part of the evidence chain
Where a signature service runs and who owns it is no footnote under DORA. Article 30 requires naming the countries and regions where services are provided and data is processed. For financial entities, concentration risk adds another angle: the more critical functions depend on a single provider or jurisdiction, the closer the scrutiny.
Sign2x runs on the Open Sovereign Cloud (OSC) from T-Systems. For your evidence chain that matters for two reasons. First, the location can be named concretely and entered in your register. Second, operations fall under European law and not under the reach of statutes such as the US Cloud Act. Why EU data centres alone do not solve the jurisdiction problem is explained in the short piece Cloud Act vs data sovereignty, with technical depth in the article on the Open Sovereign Cloud for the e-signature API.
From an auditor's perspective it matters that you can present the hosting statement not as a marketing sentence but as a contract component with a concrete operator. In addition, document which data categories arise in the signing flow: document content, metadata on signers, event logs, and where applicable results of an identification by a partner. The clearer these categories, the easier it is to describe what sits where and how long it is retained.
Equally important is what we do not claim. Hosting on OSC does not make your product DORA-compliant automatically, and it replaces neither your own risk analysis nor your customer's register of information. It does remove a typical weak spot in the audit conversation, the open question of ownership and access rights. For the building blocks in context see Cloud Act and Open Sovereign Cloud for e-signature.
ISVs with a multi-tenant model face one more consequence. If you ship white-label, the location should be identical and documented for all tenants, or you must be able to evidence deviations per tenant cleanly. That argues for a single hosting foundation and against individual special paths nobody can oversee in an audit. More on tenancy in white-label requirements for ISVs.
Checklist for ISVs: preparing evidence before the audit
The checklist below is not legal advice and does not replace review by your compliance team. It does help set up the technology so that Article 30 questions from your customers can be answered in hours rather than weeks.
- Describe functions: record which signing functions you use, which levels (SES, AES, QES) you offer and where a partner QTSP is involved.
- Name locations: enter hosting on the Open Sovereign Cloud and any partner locations in your supply chain documentation.
- Persist events: store webhook events in your own data store with transaction ID, UTC time, role and document hash.
- Test export: verify you can export documents and logs completely in a documented format, including as an exit scenario.
- Map incidents: define which error and status events you classify as reportable, and how they arrive in your systems.
- Separate roles: document who is responsible for signature level, identification and qualification. Sign2x provides the API layer, QES qualification comes from the partner QTSP.
- Plan tests: include the signing flow in your resilience tests and exercises where it touches critical or important functions.
A word on priority: start with the event schema. Everything else depends on owning structured data at all. Contracts and register entries can be added later, events from the past cannot. If you start today, you collect evidence from today.
To assess your starting point in a structured way, the Sign2x quiz helps with classifying requirements, and the help centre covers the basics of events and status models. We collect use cases from regulated industries under use cases, more articles in the Sign2x blog. For a concrete conversation about your supply chain questions, the developer hub offers a sandbox and documentation.
If you want to know which evidence your signing flow already delivers today and where gaps remain, talk to us. We will also tell you what we do not cover.
Discuss your DORA supply chain with us
Related perspectives: the article on NIS-2 and the signature audit trail shows how DORA and NIS-2 complement each other on evidence. The role of the partner QTSP is covered in QTSP partners for ISVs. The legal basis of the signature levels is in the eIDAS Regulation, guidance on information security at the BSI.
Frequently asked questions
Is there a DORA certification for signature APIs?
No. DORA provides no certification for signature APIs. Financial entities must manage third-party risk and keep evidence. An API audit trail supplies evidence for those proofs but is not a certificate itself.
What does DORA Article 30 require in ICT contracts?
Article 30 requires, among other things, clear service descriptions, processing locations, data protection terms, access and return of data, service levels, incident assistance, cooperation with authorities, and termination and exit provisions. Additional requirements apply to critical or important functions.
Is Sign2x a qualified trust service provider?
No. Sign2x is the API layer. For QES the qualification runs through a partner QTSP such as Sign8. SES and AES can be mapped depending on the use case.
Where is the Sign2x platform hosted?
On the Open Sovereign Cloud (OSC) from T-Systems. The location can be named in supply chain documentation and in the register of information.
What should an audit trail contain at minimum?
Transaction ID, event type, UTC time, acting role, document hash, signature level and the result of identification where one took place. Store this data in your own data store.
