NIS2 is no longer a future problem. The directive is enforceable, national regulators are operationalising their supervisory powers, and the first significant fines are a matter of when, not if. For large enterprises with dedicated security teams and legal counsel on speed dial, this is a compliance exercise. For SMEs with ten to five hundred staff, no in-house security function, and a patchwork of managed services held together by goodwill and spreadsheets, NIS2 is something closer to a reckoning.
The gap that will hurt most SMEs is not the one they spent the last eighteen months worrying about — it is not patching cadence, it is not password policy, and it is not multi-factor authentication. The gap is incident response. Specifically, the quiet, widely shared assumption that someone else is handling it. This article is about naming that assumption, understanding what regulators will actually ask for, and building the incident readiness posture that closes the gap before the fine letter arrives.
Why NIS2 Makes an Incident Response Retainer a Legal Requirement, Not a Nice-to-Have
Article 21 of NIS2 requires that entities in scope implement appropriate and proportionate technical and organisational measures to manage cybersecurity risks. Incident handling is explicitly listed among those measures — not as a recommendation, but as a mandated capability. Article 23 then layers on a notification framework that gives covered entities 24 hours to issue an early warning to their competent authority following a significant incident, 72 hours to provide an incident notification, and one month to submit a final report.
Think about what that timeline demands in practice. Within 24 hours of detecting a significant incident, your organisation must have already made a credible initial assessment of severity, impact, and whether the incident is likely ongoing. Within 72 hours, you must provide structured detail including the nature of the incident, affected services, and cross-border impact. Within a month, you must deliver a comprehensive account including root cause analysis and remediation steps taken.
None of that is possible if your incident response capability exists only as a vague understanding that your IT support provider will probably help if something bad happens. NIS2 does not ask whether you had good intentions. It asks whether you had documented, tested, and contractually supported capability. An incident response retainer is the mechanism that makes that capability real. It is a pre-negotiated agreement with a specialist provider that gives you guaranteed access to qualified incident responders, defined response times, and a pre-agreed scope of services — exactly what regulators mean when they ask whether your incident handling measures are appropriate and proportionate.
The proportionality framing matters for SMEs. NIS2 does not expect a fifty-person SaaS company to have an internal security operations centre. It does expect that fifty-person company to have a credible, documented plan for what happens when a breach occurs — and a retainer is the most efficient and cost-effective way to deliver that credibility.
The SME Assumption Gap: Who Did You Think Was Handling Your Incidents?
In conversations with SME founders, operations directors, and IT leads across regulated sectors, one answer comes up with striking consistency when the question of incident response is raised: a pause, followed by some version of "our IT provider handles that" or "we assumed it was covered under our managed services agreement."
It almost certainly is not.
Most managed service providers and IT support contracts are scoped around availability and day-to-day operations. They will restore a server, troubleshoot a connectivity issue, and manage your Microsoft 365 tenancy. They are not scoped, staffed, or contractually obligated to conduct forensic investigation of a suspected breach, preserve evidence in a legally defensible manner, contain a live ransomware incident, or produce the kind of documented incident timeline that satisfies a regulatory notification requirement. If you read the contract carefully — and most organisations have not — you will find that incident response in the NIS2 sense is either explicitly excluded or simply absent.
The assumption gap compounds in SaaS businesses, where the presence of cloud infrastructure can create a false sense of delegated security. AWS, Azure, and GCP operate under a shared responsibility model. The cloud provider secures the infrastructure. You are responsible for everything built on top of it: your application, your data, your access controls, and your ability to detect and respond to incidents affecting what you own. A significant breach of your customer data does not become the cloud provider's problem to investigate and report. It is yours.
For regulated SMEs specifically — those operating in sectors like financial services, health, digital infrastructure, or managed service provision — the assumption gap carries elevated risk. These organisations are more likely to be in scope for NIS2's stricter requirements, more likely to be early targets for regulatory inquiry, and more likely to face consequences if they cannot demonstrate that incident response was treated as a serious operational commitment rather than an afterthought.
The first step toward closing this gap is not technical. It is honest acknowledgement: unless you have a signed, scoped retainer agreement with a qualified incident response provider, your incident response capability does not exist in any form that will satisfy a regulator.
What Regulators Will Actually Ask For When the First Fine Lands
Regulatory inquiries following a significant incident are not primarily technical exercises. They are documentation exercises. Supervisory authorities want to understand what you had in place before the incident, how you detected it, what you did in the first hours, and whether your response was consistent with your documented policies and procedures.
In practical terms, when a competent authority investigates a notified incident from an SME, they are likely to ask for some or all of the following: your incident response plan and evidence of when it was last reviewed and tested; your contracts with any third-party security providers, specifically any retainer or incident response agreement; records of who was notified internally and externally, and when; evidence of forensic investigation including timeline reconstruction and root cause analysis; documentation of remediation steps and lessons learned; and evidence that your senior management was appropriately involved, which NIS2 explicitly requires through its management accountability provisions.
An organisation that cannot produce a current incident response plan, cannot point to a contractual relationship with a qualified responder, and cannot show evidence that these things were tested will struggle to demonstrate proportionate measures regardless of how well it performs on other NIS2 requirements. The absence of a retainer is not simply a gap in one line item — it undermines your ability to produce almost everything else on that list, because competent forensic investigation, evidence preservation, and regulatory-quality reporting require specialist capability that cannot be improvised in the middle of a live incident.
It is also worth noting that NIS2 gives national authorities the power to conduct proactive supervisory inspections, not just reactive investigations following reported incidents. Essential entities in particular can expect targeted audits. In that context, having an incident response retainer in place is not just about what happens after a breach — it is about being able to demonstrate readiness when the inspector arrives before anything has gone wrong.
How to Evaluate and Select an Incident Response Retainer on a Constrained Budget
The phrase "incident response retainer" can sound expensive, and some arrangements are. But the market has matured significantly, and there are structures that work for SMEs operating under real budget constraints. The key is knowing what to look for and what to avoid.
Understand what the retainer actually covers. Retainer agreements vary widely. Some are purely a priority access arrangement — you pay a fee to be at the front of the queue when you call. Others include prepaid hours that can be used for proactive work such as tabletop exercises, playbook development, and threat assessments, with incident response hours available if needed. The latter model is significantly more valuable for SMEs because it builds capability before an incident occurs rather than simply guaranteeing a faster callback afterward.
Verify the provider's regulatory familiarity. Your incident response provider needs to understand the notification requirements you operate under, not just the technical side of incident containment. For NIS2-covered entities, that means familiarity with the 24-hour and 72-hour notification timelines, experience producing the kind of documented output that satisfies competent authority requests, and ideally relationships with legal counsel who can advise on privilege and disclosure obligations during an active investigation.
Check response time commitments contractually. A retainer that promises "rapid response" without defining what rapid means is not a retainer — it is a marketing statement. Look for contractually defined response time SLAs, clarity on what constitutes an engagement trigger, and explicit commitments on the availability of named or categorised personnel rather than a generic team.
Assess scope of services carefully. Effective incident response for an SME typically needs to cover initial triage and scoping, forensic investigation and evidence preservation, containment and eradication support, regulatory notification drafting assistance, and post-incident review. Providers that are strong on the technical side but thin on the regulatory reporting side will leave you exposed at the moment the competent authority asks for documentation.
Budget realistically. Entry-level retainer arrangements with qualified providers typically start in the range of a few thousand pounds or euros annually for a basic priority access and prepaid hours structure. That is a fraction of the cost of a single regulatory fine under NIS2, which can reach ten million euros or two percent of global turnover for essential entities — as set out in Article 34 of the directive. Framing the retainer as an insurance premium rather than a discretionary security expense usually clarifies the budget conversation.
Your Pre-Fine Checklist: Five Things to Fix Before the Deadline Passes
If your incident response retainer does not exist yet, the following five actions represent the minimum viable programme for getting ahead of regulatory exposure. None of them require a large team or a large budget. All of them are achievable within a focused four-to-eight-week effort.
1. Audit your current contracts for incident response obligations. Pull every agreement you have with IT providers, managed service partners, cloud vendors, and any security-adjacent supplier. Read the scope of services carefully. Document explicitly what each provider is and is not obligated to do in the event of a security incident. This audit will confirm the assumption gap and provide the baseline for your retainer specification.
2. Draft or update your incident response plan. Your plan does not need to be a hundred-page document. It needs to define what constitutes a significant incident for your organisation, who is responsible for declaring an incident, your internal escalation path, your regulatory notification obligations and timelines, and your external contacts including your retainer provider and any relevant legal counsel. A clear, current, ten-page plan that your team has read is worth more than an elaborate document that lives in a drawer.
3. Procure and execute a retainer agreement. Using the evaluation criteria above, identify two or three candidate providers, request proposals, and prioritise getting a signed agreement in place. Do not let perfect be the enemy of good — a basic retainer with strong response time commitments and regulatory familiarity is significantly better than no retainer while you wait for the ideal arrangement.
4. Run a tabletop exercise. A tabletop exercise does not require external facilitation, though a retainer provider who includes facilitation as part of their prepaid hours is a useful choice. Walk your senior team through a realistic scenario — a ransomware notification from your IT provider, a suspected data exfiltration from a cloud environment, or a third-party supply chain compromise — and test your plan against it. Document the exercise and its findings. This documentation serves dual purpose: it improves your readiness and it provides evidence of tested capability for a regulator.
5. Establish your notification contacts and draft template notifications. Under NIS2, the clock starts when you become aware of a significant incident. Having pre-drafted template notifications for your competent authority, your data protection authority where relevant, and your key customers dramatically reduces the time pressure in the first 24 hours. Know who your competent authority is under NIS2 in your jurisdiction before you need to notify them.
Turning Compliance Pressure Into a Repeatable Incident Readiness Posture
The five-item checklist above gets you to a defensible baseline. But the organisations that will navigate the NIS2 era most effectively are not those that treat incident response as a compliance checkbox — they are those that treat it as a continuous operational capability.
What does that look like for an SME without an in-house security team? It looks like a structured rhythm of activity that keeps your incident readiness current without requiring constant investment of time or money. Quarterly reviews of your incident response plan to reflect changes in your technology environment, team, or regulatory obligations. Annual tabletop exercises that rotate scenarios and involve senior leadership. Regular threat briefings from your retainer provider that keep your team aware of the threat landscape relevant to your sector. Integration of incident response considerations into major changes — new cloud deployments, new third-party integrations, new product launches — rather than treating security as a retrospective concern.
This kind of repeatable posture is also what transforms a retainer from a static document into a living relationship. The best retainer providers do not simply wait for your call. They help you build the institutional knowledge and documented capability that makes your organisation more resilient over time and more defensible in front of a regulator.
For SMEs operating in regulated sectors, the pressure of NIS2 is real. But it is also an opportunity to build something that protects your business beyond compliance — a genuine, tested, documented capability to detect, contain, and recover from incidents that will inevitably come. The organisations that treat this moment as a prompt to build that capability, rather than simply as a fine to avoid, will be better placed across every dimension: operationally, commercially, and in the eyes of every regulator, customer, and partner who asks the question that NIS2 has made unavoidable: what happens when something goes wrong, and who exactly is responsible for fixing it?