NIS2, DORA and the incident response retainer

The claim to be careful with

A retainer is not required by NIS2, DORA or the GDPR. What is required is an incident handling capability: documented, staffed, tested and able to produce specific outputs inside specific deadlines. A retainer is one lawful way to hold part of that capability under contract instead of on payroll.

The distinction matters in two directions. It protects you from paying for a retainer and assuming the duty is discharged, because the policy, the classification scheme and the management-body oversight all remain yours. And it protects you from the opposite error of building everything internally, because nothing in either instrument says the responders have to be your employees.

NIS2: what Article 21 actually says

Article 21(1) of Directive (EU) 2022/2555 requires Member States to ensure that essential and important entities “take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems”, taking into account “the state-of-the-art and, where applicable, relevant European and international standards, as well as the cost of implementation”. Proportionality is assessed against the entity’s exposure, its size, and the likelihood and severity of incidents including their societal and economic impact.

Article 21(2) then sets a minimum list on an all-hazards basis. Three of its ten points bear on a retainer:

• (b) incident handling. The direct hook, and the shortest point in the list.
• (c) business continuity, such as backup management and disaster recovery, and crisis management. A responder contributes to this; it does not replace it.
• (d) supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers. This is the point that applies to the retainer provider itself.

Two words in point (b) do a lot of work: incident handling, not incident response. The Directive defines it broadly enough to cover detection, analysis, containment, recovery, documentation and reporting, and the implementing rules confirm that reading.

What the implementing regulation turns that into

Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 sets out the technical and methodological requirements for the Article 21(2) measures. Its scope is limited: it binds DNS service providers, TLD name registries, cloud computing providers, data centre providers, content delivery network providers, managed service providers, managed security service providers, online marketplaces, online search engines, social networking platforms and trust service providers. For everyone else it is not directly binding.

It is still the most concrete published statement of what a regulator considers adequate incident handling, which makes it the best available checklist against a retainer proposal. Point 3 of its Annex requires, among other things:

• An incident handling policy laying down “the roles, responsibilities, and procedures for detecting, analysing, containing or responding to, recovering from, documenting and reporting of incidents in a timely manner” (3.1.1).
• A categorisation system for incidents; “effective communication plans including for escalation and reporting”; assignment of detection and response roles to competent employees; and “documents to be used in the course of incident detection and response such as incident response manuals, escalation charts, contact lists and templates” (3.1.2).
• Testing and review of those roles, responsibilities and procedures at planned intervals and after significant incidents (3.1.3).
• Assessment “based on predefined criteria laid down in advance, and on a triage to determine prioritisation of incident containment and eradication” (3.4.2(a)).
• Response procedures covering containment, eradication and recovery (3.5.2), communication plans with the CSIRT or competent authority and with internal and external stakeholders (3.5.3), logged response activity with recorded evidence (3.5.4), and tested procedures (3.5.5).
• Post-incident reviews identifying, where possible, the root cause, producing documented lessons learned (3.6.1).

Read that list as an onboarding specification. Almost every item is an artefact that either exists before an incident or does not exist at all, and a retainer that does not produce them leaves you holding the gap.

The NIS2 reporting sequence, and why triage speed decides it

Article 23(3) defines a significant incident as one that “has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned”, or that “has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage”.

Article 23(4) then sets the sequence, all measured from becoming aware:

The 24-hour line is the one that shapes the retainer. Suspected malicious action and possible cross-border impact are triage findings, not administrative details, and they have to be stated on day one. That is the clearest argument available for a target measured in hours rather than days, and for agreeing in advance who drafts the early warning: your team, the provider, or the provider under your name.

One reassurance is written into the Directive itself. Recital 101 records the intent that reporting must not cannibalise response: Member States should ensure the obligation “does not divert the notifying entity’s resources from activities related to incident handling that should be prioritised”. Article 23(5) also obliges the CSIRT or competent authority to respond to the early warning where possible within 24 hours, with initial feedback and, on request, guidance or operational advice on mitigation. Your national CSIRT is a resource, not only a recipient.

DORA: response and recovery under Article 11

Regulation (EU) 2022/2554 approaches the same ground from the resilience side. Article 11(1) requires a comprehensive ICT business continuity policy. Article 11(2) requires it to be implemented through “dedicated, appropriate and documented arrangements, plans, procedures and mechanisms” that, among other things, “quickly, appropriately and effectively respond to, and resolve, all ICT-related incidents in a way that limits damage and prioritises the resumption of activities and recovery actions”, and “activate, without delay, dedicated plans that enable containment measures, processes and technologies suited to each type of ICT-related incident”.

Several further paragraphs constrain how much of this can be outsourced:

• Article 11(3): ICT response and recovery plans are subject to independent internal audit reviews, for entities other than microenterprises.
• Article 11(4): business continuity plans must be tested, “notably with regard to critical or important functions outsourced or contracted through arrangements with ICT third-party service providers”. Your retainer is one of those arrangements, so it is in scope of the testing duty.
• Article 11(6)(a): plans are tested at least yearly and after substantive changes, with cyber-attack scenarios included for entities other than microenterprises.
• Article 11(7): entities other than microenterprises must have a crisis management function. A provider can support it; it cannot be it.
• Article 11(8): keep readily accessible records of activities before and during disruption events.

Article 17 adds the process requirements: early warning indicators; procedures to identify, track, log, categorise and classify incidents by priority and severity; roles and responsibilities “that need to be activated for different ICT-related incident types and scenarios”; internal escalation procedures and communication plans; reporting of at least major incidents to senior management and the management body; and response procedures that mitigate impact and restore services securely.

Article 10(2) is the detection counterpart, and it explains why a retainer alone is insufficient for an entity with no monitoring: detection mechanisms must “define alert thresholds and criteria to trigger and initiate ICT-related incident response processes, including automatic alert mechanisms for relevant staff in charge of ICT-related incident response”. The response process is triggered by detection. Nothing downstream of that trigger can compensate for its absence.

DORA Article 30: the part that regulates your retainer contract

This is the section most retainer buyers have never read, and it is the reason a financial entity cannot simply sign a provider’s standard terms.

Article 30(1) requires that the rights and obligations of both parties be clearly allocated and set out in writing, and that “the full contract shall include the service level agreements and be documented in one written document”. A proposal that references an SLA held elsewhere does not satisfy that.

Article 30(2) sets minimum elements for any ICT services contract. The ones that bite hardest on an incident response retainer:

• (a) a clear and complete description of the services, and whether subcontracting of a service supporting a critical or important function is permitted and on what conditions.
• (b) “the locations, namely the regions or countries, where the contracted or subcontracted functions and ICT services are to be provided and where data is to be processed, including the storage location”, plus a requirement to notify you in advance of any change. For a responder taking forensic images, this is the clause that decides where your evidence goes.
• (e) service level descriptions, including updates and revisions.
• (f) an obligation “to provide assistance to the financial entity at no additional cost, or at a cost that is determined ex-ante, when an ICT incident that is related to the ICT service provided to the financial entity occurs”.
• (h) termination rights and minimum notice periods.

Article 30(3) then adds, for services supporting critical or important functions: “full service level descriptions … with precise quantitative and qualitative performance targets within the agreed service levels to allow effective monitoring by the financial entity of ICT services and enable appropriate corrective actions to be taken, without undue delay, when agreed service levels are not met”; notice and reporting obligations; requirements to implement and test business contingency plans; an obligation to participate and fully cooperate in the entity’s threat-led penetration testing under Articles 26 and 27; and unrestricted rights of access, inspection and audit for the entity, an appointed third party and the competent authority.

Two practical consequences. A retainer sold on “commercially reasonable efforts” fails 30(3)(a) on its face. And the audit and inspection rights in 30(3)(e) are not boilerplate: a provider that will not accept them cannot support a critical or important function, whatever its reputation.

The DORA reporting clock

Commission Delegated Regulation (EU) 2025/301 of 20 February 2025 sets the time limits for major ICT-related incident reporting. The initial notification is due “as early as possible, but in any case, within four hours from the classification of the ICT-related incident as a major ICT-related incident and no later than 24 hours from the moment the financial entity has become aware of the ICT-related incident”. The intermediate report follows at the latest within 72 hours of the initial notification, even if nothing has changed, and again without undue delay once regular activities are recovered. The final report is due no later than one month after the intermediate report or the latest updated intermediate report.

Where an incident is classified as major later than 24 hours after awareness, the initial notification is due within four hours of that classification. Deadlines falling on a weekend or a bank holiday may move to noon of the next working day, but that relief does not apply to initial notifications or intermediate reports from credit institutions, central counterparties, trading venue operators, or other financial entities identified as essential or important under NIS2 Article 3.

The design implication is precise. DORA’s clock starts at an analytic act performed on incomplete information, so the four hours are only survivable if the classification criteria, the evidence required and the person authorised to apply them were settled before the incident. That is onboarding work, and it belongs in the retainer.

GDPR: your responder is a processor

A responder collecting memory images, disk images, endpoint telemetry and mailbox exports is processing personal data on your behalf. Article 28(3) of Regulation (EU) 2016/679 requires that processing to be governed by a binding contract setting out the subject matter, duration, nature and purpose, the types of personal data and categories of data subjects, and stipulating in particular that the processor processes personal data “only on documented instructions from the controller, including with regard to transfers of personal data to a third country”; ensures confidentiality commitments; takes Article 32 measures; assists with Articles 32 to 36; and, at your choice, deletes or returns all personal data at the end of the service.

Article 28(2) adds that a processor “shall not engage another processor without prior specific or general written authorisation of the controller”. Read against a real incident, that means the sub-processor list, including any offshore analysis centre or specialist laboratory, has to be authorised before the engagement rather than during it.

Article 33(1) then runs its own clock: notification to the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of a personal data breach, unless the breach is unlikely to result in a risk. Late notification must be accompanied by reasons for the delay, and Article 33(2) requires the processor to notify the controller without undue delay after it becomes aware.

One tension is worth resolving in advance. Article 28(3)(g) requires deletion or return of personal data at the end of the service, while both the NIS2 implementing rules and DORA require you to keep records and evidence. Decide at onboarding what the responder deletes, what it returns, and what you retain yourself, so that a data protection clause does not destroy the evidence a supervisor will ask for.

Mapping a proposal against the duties

Use that table when a proposal claims to deliver compliance. Anything in the right-hand column stays with you regardless of what you paid. The scoping tool turns your regulatory position into the specific clauses to require, and the SLA guide covers the wording Article 30(3)(a) demands.