“If we were hit tonight”:
Incident readiness self-assessment

There is a named person (not a team, not “IT”) with the authority and responsibility to make the call that an incident has occurred and that the response plan is activated. That person is known to the rest of the leadership team. If they are unavailable, there is a named alternate. The role is not assumed: it is documented and agreed.

Most incidents are discovered outside business hours. A phone tree or escalation list with current personal mobile numbers for the incident owner, a second-in-command, the IT support contact, and the insurer emergency line exists in printed or offline form. If this information is only accessible via the email system that may be compromised, it does not count.

The instinct in an incident is to fix things quickly: wipe a device, reset a password, restore a system. Each of these actions can destroy the forensic evidence needed to understand what happened, how far the attacker progressed, and what the insurer or regulator will ask about. A written rule (even a simple one: isolate but do not wipe, preserve logs before resetting) prevents the most common early mistakes. Every person who might respond to an incident knows this rule.

In the first hour, the organisation needs to triage: what has been affected, what is at risk, and what must be protected or isolated first. This is impossible without a current, shared view of which systems are most critical to operations and who is responsible for each. A simple list, reviewed in the last three months and accessible outside the main IT environment, is sufficient. If this knowledge lives entirely in one person’s head, that is a single point of failure in the incident response.

Containment speed directly affects the blast radius of an incident. The steps to disconnect a device from the network, disable an email account, revoke an admin session, or block a compromised supplier connection should be written down and accessible to the person most likely to need them. If those steps require calling your IT support firm to ask what to do, containment is delayed by however long that call takes.

Enforced means that MFA cannot be bypassed: a conditional access policy blocks logins without a second factor, not just that MFA is available for users who choose to enable it. This distinction matters significantly. Many SMEs have MFA “available” but not enforced, meaning a single stolen password is still sufficient for account access. Admin accounts and finance accounts in particular should require phishing-resistant MFA (authenticator app) rather than SMS codes where the platform supports it.

When an account is compromised, the priority is to terminate active sessions and prevent further access. The steps to do this, the credentials needed to do it, and the person responsible for doing it must be clear before an incident. If account disablement requires access to the admin console that is itself protected by the compromised account, or if only one person knows how to do it and they are unreachable, containment fails at the first step.

Admin accounts are separate from daily-use accounts. The number of people with global admin rights is small, named, and reviewed at least quarterly. Nobody uses an admin account for day-to-day tasks such as email and browsing. Shared admin accounts, if they exist at all, have a clear business justification and their credentials are rotated. If “everyone is an admin because it’s easier” is the current position, the blast radius of any account compromise is maximised.

If your primary admin account is locked, compromised, or the MFA device is lost, you need a way to regain administrative access that does not involve the compromised pathway. A break-glass account is an emergency access account with a known, securely stored credential that is excluded from normal MFA policy but whose usage triggers an immediate alert. Without this, a compromised admin account can lock an organisation out of its own systems entirely.

A backup that is accessible from the same admin credentials used in the production environment can be encrypted or deleted by ransomware alongside the primary data. At minimum, one backup copy should be stored in a location that the primary environment’s admin credentials cannot reach: a separate cloud tenant, an offline copy, or an immutable backup target with different credentials. If your backup strategy consists of a single always-online destination authenticated with your main admin account, it provides minimal protection in a ransomware scenario.

A backup that has never been successfully restored from is a belief, not a control. Tests should cover your most critical systems, should be documented with the date, the system tested, and the outcome, and should be repeated at least every six months. Common restore failures discovered during testing rather than during incidents: incomplete data scope, file-level backup that cannot restore whole-system state, retention periods shorter than assumed, and backup jobs that showed “completed” but had silent errors in file transfers.

Recovery Time Objective is how long it takes to restore a system to operational state after a failure. Recovery Point Objective is the maximum amount of data loss that is acceptable in hours. These figures should be based on tested restores, not assumptions. If you have never timed a restore for your critical systems, you do not know your RTO. A business that discovers its finance system takes four days to restore from backup when it assumed 24 hours is in a different class of crisis than one that knew the figure in advance.

A recovery runbook does not need to be long. It needs to answer four questions for each critical system: who has the authority to initiate a restore, who has the technical access and skill to execute it, what order do systems come back in if multiple systems are affected simultaneously, and who is responsible for telling clients and suppliers what is happening while systems are down. If the answers to these questions exist only in the memory of your IT lead, the runbook does not exist.

SPF and DKIM reduce the ability to spoof your domain. DMARC enforces what happens to emails that fail those checks: reject or quarantine rather than the default of delivering them anyway. Many SMEs have SPF set up but DMARC absent or in reporting-only mode (p=none), which prevents no spoofed email from being delivered. The correct configuration is DMARC at enforcement (p=quarantine or p=reject), which requires both SPF and DKIM to be correctly aligned first. This is a technical configuration task but is achievable in a single afternoon for most SMEs.

Any new or changed payment instruction received by email (a supplier changing their bank account, an urgent payment request from a director, an invoice with new payment details) is verified using a phone number already held in the organisation’s records, not one provided in the email. This single policy prevents the majority of invoice fraud, payment diversion, and impersonation fraud affecting UK SMEs. The policy must be documented, communicated, and treated as non-negotiable: no exceptions for urgency, no exceptions for seniority of the request sender.

The most common BEC scenarios are recognisable with minimal training: urgency and pressure combined with an unusual request, a slightly-off sender address, a request to change payment details or bypass a normal process, and a request to keep the communication confidential. Staff need a clear, blame-free route to report any email that seems unusual, and the culture needs to support reporting suspicion as the right action rather than treating it as wasting time. A single unreported suspicious email that turned out to be a genuine BEC attempt is a preventable loss.

A common BEC technique is to compromise a mailbox silently and set up an inbox rule that forwards copies of specific emails (supplier invoices, finance correspondence, client communications) to an attacker-controlled address. The mailbox owner sees nothing different; their inbox functions normally. Detection requires monitoring for new forwarding rules created on email accounts, flagging logins from unexpected geographic locations or from unfamiliar devices, and alerting on large numbers of emails being moved or deleted. In Microsoft 365 and Google Workspace, these alerts can be configured in the admin console at no additional cost.

Your IT support provider’s emergency contact number, your cloud vendor support escalation path, your domain registrar access details, and your DNS provider credentials all need to be accessible when your primary systems are unavailable. If these details live only in your email inbox or on a server that is currently encrypted, you are starting from zero. A printed contact sheet, a personal notes app that is not connected to your business systems, or a separate personal email with the key details is a minimum. Review whether your MSP contract includes an incident response commitment and what the SLA is for emergency response.

Cyber insurance policies typically have notification requirements that must be met for a claim to be valid: notification within a specific window (commonly 24 to 72 hours of discovery), preservation of specific types of evidence, and in some cases approval before engaging third-party IR firms. A claim that is valid in principle can be jeopardised by late notification, by actions taken before the insurer was informed, or by engaging support firms not approved by the insurer. The policy document, the emergency contact number for the insurer, and the notification window should be known to the incident owner before any incident occurs.

The types of evidence most commonly requested after a cyber incident are: authentication logs (who logged in, from where, when), email access and forwarding logs, system access logs for critical systems, network traffic logs if available, and any communications related to the incident. Many of these logs have short default retention periods in cloud platforms: Microsoft 365 Audit Logs default to 90 days for most licence types, which may not cover a compromise that began months before it was detected. Check your log retention settings before an incident, not during one.

Under UK GDPR, a personal data breach that is likely to result in a risk to individuals must be reported to the ICO within 72 hours of the organisation becoming aware of it. “Becoming aware” is the point at which you have reasonable certainty that a breach has occurred, not the point at which you have confirmed every detail. The clock starts then. Failure to notify within 72 hours is itself an aggravating factor in ICO investigations, separate from the breach. A named person in the organisation should know this obligation and be responsible for making the notification decision. See the GDPR for owner-led SMEs guide for detail on what constitutes a notifiable breach.

A security questionnaire from a buyer or client asks what controls you have in place. If the honest answer requires you to say what you intend to have in place, or to reconstruct from memory what you believe to be true, rather than to point to current documentation, the questionnaire response is not defensible if challenged. The controls that matter most for buyer questionnaires are: MFA evidence, backup and restore documentation, an incident response procedure, and a basic governance document. Current means reviewed in the last twelve months and reflecting actual practice.

The applicable obligations vary significantly by sector and customer base: ICO registration and UK GDPR apply to almost every UK SME processing personal data. FCA oversight applies to financial services and some intermediaries. SRA requirements apply to law firms. CQC and NHS data security requirements apply to healthcare providers. Cyber Essentials may be contractually required by public sector buyers or large enterprise clients. Knowing which obligations apply to your organisation, and being able to demonstrate that you are meeting them, is different from assuming that general good practice is sufficient.

When a breach occurs, three separate communication paths run simultaneously: notification to the ICO (if notifiable), notification to affected individuals (if required), and communication to clients and suppliers (to manage the relationship and protect the business). Each of these has a different required content, different timing, and a different audience. Pre-approved holding statements, a list of who needs to be told and in what order, and a named person responsible for each path, prepared before an incident, makes this manageable. Writing it from scratch under pressure, while simultaneously trying to contain the incident, produces inconsistent and legally risky communications.