DORA defines an ICT third-party service provider as an undertaking providing ICT services, and defines ICT services as digital and data services provided through ICT systems on an ongoing basis. A software vendor offering SaaS or ongoing digital services to a financial entity is likely to count. Check the definition against what you actually deliver.
The definitions
DORA Article 3 defines:
- ICT services: digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis, including hardware as a service and hardware services with technical support through software or firmware updates, excluding traditional analogue telephone services.
- ICT third-party service provider: an undertaking providing ICT services.
The key words are "on an ongoing basis". A hosted service, a managed platform or a subscription with continuing updates fits more naturally than a one-off licence. Where your product sits between the two, ask your customer's legal team how they classify it, since the financial entity makes the classification for its own register.
What changes for you
DORA does not usually require a vendor to be supervised directly. The effect is through the customer:
- Contract terms. Article 30 requires written contracts with items such as service description, data locations, data return, incident assistance, termination rights and cooperation with authorities. For critical or important functions, add audit access, exit transition periods and participation in testing.
- Register of information. Your customer must record you, your services and subcontractors (Article 28(3)).
- Due diligence. Before contracting, the entity assesses risks, concentration risk and your suitability (Article 28(4)).
- Ongoing monitoring against the service levels you agreed.
- Exit planning by the customer, which you may be asked to support.
If designated critical by the ESAs, you face direct oversight. That is a small group (see our post on designation).
Common questions in a bank's security review
- Where is data processed and stored, and will you notify us before changing locations?
- Which subprocessors do you use for services supporting our functions?
- How quickly will you tell us about an incident, and what help will you give at no extra cost?
- Can we or our regulator audit you?
- How do we get our data back if the contract ends or you fail?
- Will you take part in our resilience tests?
Preparing a standard pack
Build a short package: data location list, subprocessor list, incident notification process, audit and assurance summary, exit assistance terms, and a current component inventory. Mark accurately what you do not hold. Do not claim certifications you do not have, and do not describe your product as "DORA compliant", because compliance belongs to the regulated entity.
Safeguard's SBOM and dependency scanning, compliance and evidence automation can help vendors compile the technical parts of that pack.
Quick check
Does a vendor need to register with a DORA authority?
Not generally. The register of information is kept by the financial entity. Only providers designated as critical face direct oversight.
Can I call my product DORA compliant?
Be careful. DORA obligations fall on financial entities, and your product supports them. Describe the specific terms and evidence you provide instead.
Sources
Last reviewed: 19 October 2026.
