DORA and Your Marketing Stack: Which SaaS Tools Belong in the Register of Information, and What to Ask Vendors

Under DORA (Regulation (EU) 2022/2554, applicable since 17 January 2025), every contractual arrangement for ICT services — including the SaaS tools your marketing team uses — must appear in your register of information (Article 28(3)), reported in the ESAs' standard templates (Implementing Regulation (EU) 2024/2956). Your customer data platform (CDP), email service provider, marketing automation, analytics and consent platform are ICT services; the question is not whether they go in the register but whether they support a "critical or important function", which triggers the stricter contract clauses of Article 30(3), exit planning and concentration-risk assessment. This guide maps typical martech tools to the register fields and gives you the vendor questionnaire.

Who this is for: the people who own the register and the people who own the tools. Marketing operations teams rarely know they are in scope until the third-party risk function sends a spreadsheet in January; this guide is written so both sides can fill it in correctly the first time. A downloadable martech vendor register worksheet accompanies it.

Why marketing SaaS is in scope

DORA defines ICT services broadly: digital and data services provided through ICT systems to internal or external users on an ongoing basis (Article 3(21)) 1. A hosted CDP, an email platform, a web analytics tool, a consent management platform, a push-notification service and an advertising platform's API integration all meet that definition. Article 28(3) requires financial entities to maintain and update a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers, distinguishing those that support critical or important functions from those that do not 1.

Two misconceptions cause most errors:

• "Only critical providers matter." The ESAs' first list of critical ICT third-party providers (18 November 2025) named 19 companies — hyperscalers and large IT groups such as AWS, Google Cloud, Microsoft, Oracle, SAP and IBM — and no martech vendor 2. Designation triggers oversight of the provider; it does not change your duties for every other provider under Articles 28–30. Your email vendor is not on the list, and it still belongs in your register.
• "Marketing is not a critical function." Often true, but it is a function-by-function test, not a department test. Regulatory notices, transactional and servicing communications, onboarding journeys and fraud alerts frequently run through the same platforms as promotions. If the tool carries them, the function it supports may be critical or important.

Decision tree: does this tool support a critical or important function?

DORA defines a critical or important function as one whose disruption would materially impair financial performance, soundness or continuity of services, or compliance with authorisation conditions and obligations (Article 3(22)) 1. Apply it to each tool, not to "marketing".

Typical outcomes:

Document the reasoning for each decision. Supervisors ask "why not" as often as "why".

Mapping typical martech tools to the register

Article 30 clauses you need in martech contracts

Article 30(2) lists the provisions every ICT contract must contain; Article 30(3) adds stricter requirements where the service supports a critical or important function 1. Translated into a checklist for a CDP or email contract:

For every arrangement (Article 30(2)):

• A clear description of the functions and ICT services provided, including sub-contracting of services supporting critical or important functions.
• The locations, at least regions or countries, where data is processed and stored, and a duty to notify in advance if they change.
• Provisions on availability, authenticity, integrity and confidentiality of data, including personal data.
• Provisions on access, recovery and return of data in a readable format on insolvency, resolution or termination.
• Service level descriptions, including updates and revisions.
• Assistance in the event of an ICT incident related to the service, at no or pre-determined cost.
• Cooperation with competent and resolution authorities.
• Termination rights and minimum notice periods consistent with supervisory expectations.
• Participation in the provider's ICT security awareness and training programmes where relevant.

Additionally, for critical or important functions (Article 30(3)):

• Full service level descriptions with quantitative and qualitative performance targets, enabling monitoring and corrective action.
• Notice periods and reporting obligations, including notification of developments that may materially affect the provider's ability to perform.
• Implementation and testing of business contingency plans; ICT security measures, tools and policies.
• Participation and full cooperation in threat-led penetration testing (TLPT).
• Unrestricted rights of access, inspection and audit for the financial entity and competent authorities, with cooperation during on-site inspections.
• Exit strategies: a mandatory adequate transition period during which the provider continues to perform, allowing migration or in-sourcing.

Most standard SaaS marketing contracts fail the audit-rights and exit-transition clauses. Expect negotiation, and expect some vendors to refuse; that refusal is itself information for the concentration-risk assessment under Article 29 1.

Vendor questionnaire (20 questions)

Send this before renewal, not after the register is due. The downloadable worksheet includes it as a sheet.

1. In which countries or regions is our data stored, and in which is it processed, including support access?
2. Which sub-contractors support the service (cloud provider, email relays, analytics, AI model providers), in which countries, and how will you notify us of changes?
3. Is the service multi-tenant or single-tenant? Can it be deployed in our own cloud account or on-premise?
4. Who holds the encryption keys? Can we hold them?
5. What are your availability and recovery targets (RTO, RPO), and how were they tested in the last twelve months?
6. How are incidents affecting our data detected, and within how many hours will we be notified?
7. Do you grant audit and inspection rights to us and to our supervisors, including on-site?
8. Will you participate in threat-led penetration testing if required?
9. What exit assistance do you provide, for how long, in what data formats, at what cost? Does it cover identity graphs, merge history and consent records?
10. What are the termination rights and notice periods, and do they meet the expectations of our supervisor?
11. Can you provide your legal entity identifier (LEI) and the identifiers of your material sub-contractors?
12. Which certifications and assurance reports can you share (SOC 2 Type II, ISO 27001), with scope statements?
13. How do you manage your own ICT third-party risk?
14. Do you offer a business contingency plan for our service, and when was it last tested?
15. Is any processing performed by AI models hosted by third parties? Where?
16. What logs are available to us for access to our data, and for how long are they retained?
17. How do you handle data subject rights requests that touch our data?
18. Can you commit to notifying us of material changes to ownership or control?
19. What is your process for sub-contractor changes, and can we object?
20. Do you support our register fields with a pre-filled information sheet, updated annually?

Vendors who answer in writing and in detail reduce your register work by hours; vendors who cannot answer questions 1, 2, 9 and 10 should prompt a substitutability discussion.

Exit strategy for a CDP or email platform (Article 28(8))

Financial entities must have exit strategies for ICT services supporting critical or important functions, covering foreseeable risks such as provider failure, deterioration of quality and business disruption, with transition plans that allow exit without disruption and within a realistic time frame 1. For a customer data platform the plan needs:

• an inventory of the data held (profiles, identifiers, consent and suppression state, segments, decision logs) and the export format for each;
• the destinations and systems that depend on the platform, and how they would be re-pointed;
• the alternative (another vendor, in-sourcing, or a reduced-function fallback) and the time and cost to reach it;
• a tested export: run it at least annually and record the result;
• the contractual transition period and assistance you are entitled to.

Our cloud exit strategy template walks through each section, and migrating off a SaaS CDP covers the engineering sequence. Note the EU Data Act: switching charges for data processing services are capped at cost now and abolished from 12 January 2027, which removes one commercial barrier to exit but none of the engineering 5.

How deployment model changes the entries

The register does not reward one deployment model over another, but the entries, the risk assessment and the exit plan look different.

A customer-operated deployment does not remove the vendor from the register — the software licence and support are ICT services — but it moves data location, access and exit under your control, which is what Articles 28–30 are trying to achieve. This is one reason banks evaluating a CDP increasingly ask for the deployment options described in on-premise and self-hosted customer data platforms.

Calendar

| EU Data Act switching charges abolished | 12 January 2027 | Relevant to exit-cost clauses 5 |

Plan the martech part of the register in October and November: vendor questionnaires out by October, answers and criticality decisions by December, so January is data entry rather than discovery. See the regulatory deadline tracker for the wider calendar.

Confirm classification and contract terms with your DORA counsel and national competent authority.*