You passed the audit. You met the deadline. The certificates are framed, the policies are filed, and the compliance checklist is complete. On paper, your organisation looks secure.
But when was the last time you actually ran your incident response plan? Not reviewed it — ran it. Simulated a ransomware attack. Tested whether your team knows who calls whom at 2 a.m. Verified that your logging and alerting stack would surface a breach within the dwell time your policy promises?
For the vast majority of SMEs, the honest answer is never. And that gap — between what your compliance documentation says and what your organisation can actually do under pressure — is precisely where attackers thrive.
This article is for the IT managers, operations leads, and founders of businesses between 10 and 500 people who have done the right thing by pursuing ISO 27001 certification or NIS2 alignment, but suspect, somewhere in the back of their minds, that a real incident would still be chaos. You are probably right. Here is why — and here is how an Incident Response Retainer closes that gap without requiring a full in-house security team.
Why Passing an Audit Does Not Mean You Are Ready for an Attack
Audits are designed to verify the existence and logical coherence of your security controls, not to simulate the conditions of an actual breach. An ISO 27001 auditor will confirm that your risk register exists, that your access control policy has been reviewed, and that your incident response procedure is documented. They will not inject a live threat actor into your environment to see what happens next.
This is not a criticism of the audit process — it is simply what audits are for. The problem arises when organisations mistake audit-readiness for attack-readiness.
Consider what a real incident actually demands: your team needs to detect the anomaly, escalate to the right people, contain the affected systems without destroying forensic evidence, communicate with regulators and customers within mandated timeframes, and continue operating — all simultaneously, all under pressure, potentially at an hour when half your staff are asleep.
None of those capabilities are tested by an audit. They are built through repetition, simulation, and the kind of muscle memory that only comes from having done the thing before, even in a controlled environment.
For SMEs, the stakes are particularly high. According to the 2024 IBM Cost of a Data Breach Report, organisations with incident response teams and tested plans saved an average of USD 1.49 million per breach compared to those without. For a business with 50 or 100 employees, a breach of that scale is not a financial setback — it is an existential one. Yet the resources required to build and continuously exercise a mature incident response capability are typically beyond what SMEs can sustain internally.
The Hidden Risks of an Untested Incident Response Plan
Most SMEs have an incident response plan. Fewer have ever opened it during a real or simulated emergency. The document exists because ISO 27001 requires it, or because a risk assessment flagged its absence. But the plan itself — sitting in a SharePoint folder, last reviewed fourteen months ago — introduces its own category of risk.
The first hidden risk is false confidence. When a plan exists, leadership naturally assumes it works. That assumption is rarely tested until it is tested under the worst possible conditions.
The second risk is plan decay. Your IT environment changes constantly. Staff turn over. Cloud providers are added or replaced. Critical systems are migrated. Each of these changes can silently invalidate assumptions baked into your incident response procedures — contact lists that reference people who no longer work there, escalation paths that route to a phone number nobody answers, containment steps that assume network architecture that no longer exists.
The third risk is procedural paralysis. When responders have never practised a procedure, even a well-written plan can freeze them. Research in human performance under stress consistently shows that novel, high-stakes situations impair decision-making and increase the likelihood of errors that compound the original problem. Tabletop exercises and simulated incidents are not optional enrichment — they are the mechanism by which procedures become instincts.
The fourth risk is regulatory exposure. Under NIS2, organisations are required not just to have an incident response plan but to demonstrate that it is functional. A breach followed by a chaotic, poorly coordinated response is the scenario most likely to attract supervisory attention and penalty proceedings — regardless of how well-formatted your policy document is.
How NIS2 and ISO 27001 Create Compliance Theatre Without Operational Drills
NIS2 and ISO 27001 are both well-designed frameworks. The problem is not the standards — it is how organisations implement them when under time and resource pressure.
ISO 27001 requires organisations to plan and implement actions to address risks, establish an incident management process, and review that process. But the standard's audit methodology is document-centric by necessity. Controls are assessed through evidence of existence and design, not through live operational testing. An organisation can achieve full certification with an incident response plan that has never been run, provided the plan is logically coherent and the required records exist.
NIS2 goes further in spirit, requiring member state transpositions to mandate that essential and important entities handle incidents effectively and report within defined windows. But in practice, for SMEs navigating NIS2 compliance without dedicated legal and security resources, the dominant question becomes: what do we need to have documented? Not: what do we need to be able to do?
The result is compliance theatre — a performance of security rather than its substance. Policies are written to satisfy auditors. Risk registers are populated to satisfy frameworks. Incident response plans are drafted to check a box. And then the document is filed, the certificate is issued, and the organisation returns to its actual work.
This is not negligence. It is the predictable outcome of asking resource-constrained organisations to meet compliance requirements that were designed with larger, better-resourced entities in mind, without providing a scalable mechanism for operationalising those requirements.
That mechanism is an Incident Response Retainer.
What an Incident Response Retainer Actually Provides for SMEs
An Incident Response Retainer is a pre-contracted arrangement with a specialist security provider that gives your organisation on-demand access to experienced incident responders, forensic analysts, and security advisors — without the overhead of employing them full-time.
For SMEs, the retainer model solves several problems at once.
Speed of response. When an incident begins, the worst thing you can do is spend the first four hours researching vendors and negotiating contracts. With a retainer in place, your provider already knows your environment, your critical systems, and your escalation contacts. Response begins immediately.
Pre-incident preparation. A quality retainer is not just break-glass emergency access. It includes ongoing support for the activities that make incident response functional: threat exposure assessments, tabletop exercises, plan reviews aligned to your current environment, and log and alert configuration reviews. This is where the compliance-to-readiness gap actually closes.
Forensic and legal coordination. SMEs rarely have internal expertise in digital forensics or in the intersection of incident response and regulatory notification requirements. A retainer provider brings both, ensuring that evidence is preserved correctly and that your communications with regulators — under NIS2's 24-hour initial notification window, for example — are accurate and defensible.
Cost predictability. The retainer model converts an unpredictable, potentially catastrophic incident cost into a planned operational expense. For finance leaders in SMEs, this matters. It also typically costs significantly less than a single day of emergency-rate incident response engagement initiated without a pre-existing relationship.
Continuous threat intelligence. Good retainer providers are not passive. They bring current threat intelligence relevant to your sector and geography, flag emerging attack patterns, and help you adjust your controls and monitoring posture in response — the kind of continuous threat exposure management that larger organisations build into dedicated security operations functions.
How to Close the Gap Between Paper Compliance and Real Readiness
Closing the gap is a practical process, not a philosophical one. Here is how SMEs can move from certified-but-untested to genuinely ready.
Step one: Audit your incident response plan against your current environment. Pull the document out and read it critically. Does it reflect your actual infrastructure? Are the contact lists current? Does it account for your cloud services, remote workforce, and third-party dependencies? Identify every assumption that may have decayed since the plan was last written.
Step two: Run a tabletop exercise. You do not need a sophisticated simulation environment to start. A facilitated tabletop — where your key stakeholders walk through a realistic breach scenario together, making decisions in sequence — will surface gaps that no document review will find. Who actually has the authority to take a production system offline? What is your communication protocol if your email is compromised? Who is authorised to speak to the press or regulators?
Step three: Test your technical controls. Your incident response plan assumes that your logging, alerting, and containment tools work. Verify that assumption. Can your SIEM detect the lateral movement patterns associated with common ransomware precursors? Do your alerts actually reach the right people? Is your backup restoration process tested and timed?
Step four: Establish or review your retainer arrangement. If you do not have an Incident Response Retainer, now is the time. If you have one, review the scope. Does it include pre-incident support, not just emergency response? Does your provider have specific expertise relevant to your regulatory environment — NIS2, GDPR, sector-specific requirements? Do they understand your technology stack?
Step five: Schedule ongoing exercises. Readiness is not a state you achieve — it is a practice you maintain. Build tabletop exercises and technical drills into your annual security calendar, ideally quarterly for critical components and at minimum annually for the full plan. Every significant change to your environment should trigger a review of the affected procedures.
Step six: Align your readiness programme to your compliance obligations. This is where compliance and readiness reinforce each other rather than diverging. Document your exercises, their findings, and the improvements you made in response. This evidence satisfies auditors, demonstrates good faith to regulators, and — crucially — creates an institutional record that survives staff turnover.
Building a Culture of Readiness Beyond the Certification Checkbox
The deepest version of the compliance-readiness gap is cultural, not procedural. When security is framed internally as a compliance obligation — something you do to pass audits — it becomes the responsibility of whoever manages the audit relationship. When security is framed as operational readiness — something you maintain because a breach would be genuinely damaging — it becomes a shared organisational concern.
For SMEs, this cultural shift is both more achievable and more important than it is for large enterprises. In a fifty-person company, the decisions made by the founder, the operations lead, and the IT manager shape how everyone else thinks about security. If those leaders treat a passed audit as a finish line, that attitude permeates the organisation. If they treat it as a baseline from which continuous improvement begins, that attitude permeates too.
Practically, building a readiness culture means a few things.
It means talking about near-misses and incidents openly rather than suppressing them to avoid embarrassment or perceived liability. Organisations that learn from incidents — their own and others' — adapt faster than those that treat every security event as a reputation risk to be managed into silence.
It means including non-technical staff in security awareness that goes beyond phishing simulations. Your finance team, your customer success managers, your HR staff — they are all potential vectors and potential first responders. A thirty-minute walkthrough of what a real ransomware incident looks like and what each person's role is costs almost nothing and dramatically improves your initial response speed.
It means treating your Incident Response Retainer provider as a strategic partner, not a vendor you call in emergencies. The best retainer relationships involve regular touchpoints, threat briefings, and ongoing plan refinement. Your provider should know your business well enough to give you relevant, specific advice — not generic guidance that applies to any organisation of your size.
And it means accepting that compliance and readiness are different things that reinforce each other when managed well. The ISO 27001 framework gives you a rigorous structure for identifying and treating risk. NIS2 gives you external accountability and, increasingly, supervisory scrutiny that will distinguish organisations that prepared from those that performed. An Incident Response Retainer gives you the expertise and operational support to make both frameworks real rather than theoretical.
The certificate on the wall is not the goal. The goal is the capability it is supposed to represent — and the only way to build that capability, for SMEs without dedicated security teams, is to practise it continuously, with expert support, before the breach that makes it unavoidable.
The organisations that survive significant incidents are rarely the ones with the most polished policies. They are the ones who practised.