The EU's Digital Operational Resilience Act, DORA, has applied since 17 January 2025. Its Article 30 lists contract terms that financial entities must include with their ICT providers, among them subcontracting conditions, data locations and "unrestricted rights of access, inspection and audit" for critical services. If you sell software to a bank, insurer or payment firm in the EU, these clauses are now in your redlines. They sit on top of a duty software vendors already know: the data processing agreement under GDPR Article 28.
This guide covers the three items buyers push on hardest: the DPA, the subprocessor list and audit rights.
What's affected
The DPA. GDPR Article 28(3) says processing by a processor must be governed by a binding contract that sets out the subject matter, duration, nature and purpose of processing, the type of personal data and categories of data subjects, and the controller's obligations and rights. The contract must stipulate that the processor:
- processes data only on documented instructions, including on transfers to third countries;
- ensures persons authorised to process data are bound by confidentiality;
- takes all measures required under Article 32 (security of processing);
- respects the conditions for engaging another processor;
- assists with data subject requests and with obligations under Articles 32 to 36;
- deletes or returns all personal data at the end of the services, at the controller's choice;
- makes available all information necessary to demonstrate compliance and allows for and contributes to audits, including inspections.
Subprocessors. Article 28(2) says the processor shall not engage another processor without prior specific or general written authorisation. With general authorisation, you must inform the controller of intended additions or replacements and give them the opportunity to object. Article 28(4) requires the same data protection obligations to flow down by contract, and the initial processor "shall remain fully liable" for the other processor's failures.
Audit rights. Article 28(3)(h) is the legal basis for customer audits. DORA Article 30(3) goes further for critical or important functions, including a right of access, inspection and audit, and, importantly for vendors with many customers, "the right to agree on alternative assurance levels if other clients' rights are affected".
How to check if you're exposed
- Pull your standard DPA and tick each Article 28(3) item above. A missing item is a redline waiting to happen.
- Compare your public subprocessor list with your actual vendors. Export your cloud accounts, support tools, analytics, email and error tracking services, and check each one that can see customer data.
- Read your audit clause. Does it say how often, with what notice, at whose cost, and what happens if you hold a recent third-party report?
- Check Article 33(2): a processor must notify the controller without undue delay after becoming aware of a personal data breach. Your DPA should give a concrete number of hours or days.
Subprocessor list columns that customers expect
Name | Service provided | Data processed | Location | Date added
What to do now
- Publish a subprocessor page with the five columns above, and keep a change log.
- Offer a notification route: an email list or a form where customers subscribe to changes, with a notice period such as 30 days and a stated objection process.
- Put the flow down obligation in your vendor contracts, and keep a copy of each vendor's DPA.
- Write an audit clause with three tiers: first, you share a recent independent report, pen test summary and completed questionnaire; second, a remote walkthrough with an engineer; third, an on-site or on-system audit, once per year, with notice, at the customer's cost, limited to systems that process their data, and under confidentiality.
- Add the DORA-style clause when asked: if on-site audits would affect other customers, you may propose alternative assurance, such as a pooled audit or an independent report.
- Keep a single approved answer for "who are your subprocessors and where are they", and link it everywhere.
How to avoid this trap
The usual trap is an outdated list. A customer who finds a vendor in your product that is not on your list will question every other answer. Add a step to your vendor onboarding: no tool touches customer data until it is on the list and has a DPA.
Another trap is accepting unlimited audit rights in a redline to close a deal. Unlimited rights from every customer are impossible to honour. Offer the tiers above and put limits in writing.
A third is vague breach notification wording. "Promptly" gets argued over. A number of hours does not.
Why it matters
These three documents decide whether a regulated customer can legally use you. For banks and similar firms, DORA moves the burden: they must show their regulator that contracts contain the required terms. A vendor with ready answers gets through legal review in days instead of weeks.
It also protects you. A clear audit process means customers audit in an orderly way, and a clear list means you know where customer data goes.
Try it yourself
List every service that can see customer data. For each, write the location and whether you hold its DPA. Compare the result with your public list.
Click through it at your own pace, or open it full screen.
Quick check
Which GDPR article is the legal basis for customer audits of a processor?
Article 28(3)(h): the processor allows for and contributes to audits, including inspections, by the controller or an auditor it mandates.
Are you liable if your subprocessor fails?
Yes. Article 28(4) says the initial processor remains fully liable to the controller for the other processor's obligations.
What does DORA Article 30 allow when audits would affect other customers?
The right to agree on alternative assurance levels.
