Compliance · Briefing

DORA for marketing and operations teams

What the EU Digital Operational Resilience Act changes for teams outside IT: vendor registers, incident reporting and who owns compliance without a CISO.

Ilia PushinPublished Sep 23, 2026Updated Sep 23, 20267 min read
A brushed-metal shield with a clock face set into it, on a black background.
Short answer

The Digital Operational Resilience Act, DORA, is an EU regulation that has applied to banks, payment institutions, e-money institutions, investment firms and other regulated financial entities since 17 January 2025. It reaches well outside the IT department. Article 28 requires a register of every contract with an ICT third-party provider, which in practice includes the marketing automation platform, the analytics stack, the CRM and any agency with system access, not just cloud infrastructure. Article 19 sets strict incident reporting timelines that start the moment any employee, including someone in marketing or operations, notices a major disruption. Article 30 lists clauses that vendor contracts must carry. None of this requires a chief information security officer by name. DORA puts final responsibility on the management body under Article 5, so in a company without a CISO, a designated operations or compliance owner has to run the vendor register and the incident clock, or the obligation goes unmet.

Key takeaways

  • DORA's ICT services definition is broad enough to cover marketing automation, CRM and analytics tools, not just cloud infrastructure.
  • Article 28's vendor register has to move at the speed of procurement, not get updated once a year.
  • The Article 19 incident reporting clock starts the moment anyone notices a major disruption, inside IT or not.
  • DORA does not require a named CISO; it requires the management body to assign real ownership under Article 5.

What DORA changes for teams outside IT

The Digital Operational Resilience Act, DORA, is Regulation (EU) 2022/2554, published in the Official Journal on 27 December 2022 and applicable since 17 January 2025 under its Article 64. It reaches every part of a financial entity that touches an ICT system, not just the security team, because Article 3(21) defines ICT services broadly enough to cover cloud platforms, software-as-a-service tools and data analytics services, not only servers and networks.

Definition

An ICT service, under Article 3(21) of DORA, is a digital or data service provided through an ICT system on an ongoing basis, which covers cloud hosting, SaaS platforms and data analytics tools, and excludes only traditional analogue telephone services.

That definition puts a marketing automation platform, a CRM, an analytics or business intelligence tool and most agencies with system-level access inside DORA’s scope as ICT third-party service providers, alongside the cloud and payment infrastructure vendors a compliance team would flag first.

Who is actually in scope

DORA applies to financial entities as defined in its Article 2: credit institutions, payment institutions, e-money institutions, investment firms, crypto-asset service providers, crowdfunding platforms and about 15 other regulated categories. A licensed payment institution or e-money institution is covered directly. A technology company that merely sells software to banks is not itself a financial entity, but it becomes an ICT third-party service provider the moment a financial entity signs a contract for its services, and a small number of providers judged critical to the sector can be designated for direct oversight under Articles 31 to 44.

Article 4 sets a proportionality principle: requirements scale with an entity’s size, risk profile and the nature of its activities. Article 16 gives small and non-interconnected investment firms, small payment and e-money institutions, and certain other small entities a simplified ICT risk management framework, and the EU’s microenterprise definition it references covers firms with fewer than 10 employees and under EUR 2 million in annual turnover. None of this removes the register or incident reporting duties. It reduces how much documentation each one requires.

The vendor register nobody outside IT expects to own

Article 28 requires every financial entity to maintain a register of information covering all contracts with ICT third-party providers, at entity, sub-consolidated and consolidated level, distinguishing contracts that support a critical or important function from those that do not. In practice this register has to list the marketing automation platform, the analytics stack, the CRM and any agency with system access alongside cloud infrastructure, because Article 3(21) puts all of them in scope.

Regulation

Article 28(3) requires the register itself. Financial entities also report at least yearly to their competent authority on new ICT arrangements, and under the annual cycle set by Commission Implementing Regulation (EU) 2024/2956, many entities submit the full register, referenced to 31 December of the prior year, by 30 April each year.

A register built once and never updated fails the requirement the first time a marketing team adds a new analytics tool without telling whoever owns the file. The register has to move at the same speed as procurement, which usually means someone outside IT has to flag every new vendor contract before it is signed, not after.

The incident clock starts with whoever notices first

Articles 17 to 19 set out ICT-related incident management, classification and reporting. Article 18, detailed by Commission Delegated Regulation (EU) 2024/1772, sets 6 classification criteria, and an incident meeting the threshold on at least 2 of them, on top of the mandatory criterion for affected clients and transactions, counts as major.

Report Deadline What it contains
Initial notification Within 4 hours of classifying an incident as major, no later than 24 hours after detection That a major incident has occurred, and its known scope
Intermediate report Within 72 hours of the initial notification Updated impact assessment and status of the response
Final report Within 1 month of the intermediate report Root cause analysis and the total impact once resolved

These deadlines, and the exact content each report must carry, come from Commission Delegated Regulation (EU) 2025/301, with the standard forms set by Commission Implementing Regulation (EU) 2025/302. None of the 3 deadlines waits for the security team to confirm root cause. A marketing operations lead who notices a booking or lead-capture tool has gone dark because a vendor was breached is the trigger for the 4-hour clock, whether or not that person works in IT.

The clauses a marketing or analytics vendor contract needs

Article 30 lists what belongs in every ICT third-party contract, with a longer list for any provider supporting a critical or important function. A standard marketing platform contract signed before DORA applied rarely has all of it.

Clause What Article 30 requires
Service description A full description of the functions and ICT services provided, including sub-outsourcing terms
Data location Where data will be processed and stored, and under what law
Availability and security Service levels with measurable targets, and security and data protection commitments
Incident cooperation The vendor’s duty to notify and assist during an ICT-related incident
Audit rights Unrestricted rights of access, inspection and audit for the financial entity, its appointee and its competent authority
Termination and exit Termination rights and, for critical functions, a documented exit strategy with a transition period

A vendor that will not accept the audit and exit clauses is a vendor a compliance owner cannot sign off on for any function that touches customer data or a customer-facing process, regardless of how minor the tool looks from a marketing seat.

Who owns this in a company without a CISO

Article 5 puts final responsibility on the management body, the board or equivalent leadership, which must approve and oversee the ICT risk management framework and cannot delegate that accountability away, even where day-to-day work sits with a smaller team or an outside advisor. DORA does not require a named Chief Information Security Officer. It requires someone with real authority to own 3 things: the vendor register under Article 28, the incident classification and reporting clock under Articles 18 and 19, and the review of contract clauses under Article 30.

Example from practice

In a company without a dedicated security function, the operations lead who already owns the vendor list and the KPI tree is usually the person best placed to run the DORA register, provided the management body formally assigns that responsibility rather than leaving it implied.

A marketing operations audit checklist is a reasonable starting template for the vendor side of this work, extended to capture the DORA-specific fields, criticality, data location, audit rights, exit terms, that a standard vendor list does not usually track.

Building the register with what you already have

Most companies do not start this from zero. A vendor list built for fintech marketing operations or for a finance function already covers a large share of Article 28’s register, missing only the DORA-specific fields. The fastest path is usually to extend that existing list rather than build a parallel one, then run every open contract through the Article 30 checklist above before its next renewal.

This is general information about a still-developing regulatory framework, not legal advice for a specific entity’s DORA classification or contracts. A qualified EU financial services lawyer should confirm scope and sign off on register content and vendor contract language. Our Marketing-Operational System practice builds this kind of vendor register and reporting rhythm as part of a wider operations audit, working alongside your compliance and legal advisors rather than in place of them.

FAQ

Does DORA apply to every fintech company in the EU?

No. It applies to financial entities defined in Article 2, such as licensed payment institutions, e-money institutions and investment firms. A technology vendor that is not itself a financial entity is usually covered indirectly, as an ICT third-party provider named in a covered entity's register and contracts.

Do marketing and analytics vendors count as ICT third-party providers?

Usually yes. Article 3(21) defines ICT services broadly enough to include SaaS, cloud hosting and data analytics tools, so a marketing automation platform or analytics vendor under contract normally belongs in the Article 28 register.

How fast does a major ICT incident have to be reported?

Within 4 hours of classifying it as major, and no later than 24 hours after detection, under the timelines in Commission Delegated Regulation (EU) 2025/301. An intermediate report follows within 72 hours and a final report within 1 month.

Does a small fintech get any relief from these requirements?

Article 16 gives small and non-interconnected firms a simplified ICT risk management framework, and Article 4's proportionality principle scales documentation to size and risk. The register and incident reporting duties still apply.

Sources

  1. EUR-Lex, Regulation (EU) 2022/2554 (DORA)
  2. EUR-Lex, Commission Delegated Regulation (EU) 2024/1772 (incident classification and materiality thresholds)
  3. EUR-Lex, Commission Delegated Regulation (EU) 2025/301 (incident report content and timelines)
  4. EUR-Lex, Commission Implementing Regulation (EU) 2025/302 (incident reporting templates)
  5. EUR-Lex, Commission Implementing Regulation (EU) 2024/2956 (register of information templates)
  6. EUR-Lex, Commission Recommendation 2003/361/EC (micro, small and medium-sized enterprise definition)
Written and reviewed by Ilia Pushin · Last reviewed Sep 23, 2026Drafted with AI assistance, edited and fact-checked by the author.This article is for general information. It is not legal, financial or medical advice.
Ilia PushinFounder, Pushers · Co-founder and COO, ARBI ExchangeIlia builds operating systems for growing companies in fintech and healthcare. Since 2021 he has run cross-border payments at ARBI Exchange, a licensed currency exchange in Thailand, including KYC and AML and the move into new jurisdictions.About the authorLinkedIn
Working on this problem in your company?Discuss it with us