Six Controls That Stand Between You and a Denied Cyber Claim
Thursday 9 April 2026
I want to give you something practical today. Not a list of things to worry about. A list of things to do, in order, with specific outcomes you can verify.
This week we have been talking about cyber insurance, following Episode 15 of the podcast. Monday and Tuesday covered why claims get denied. Wednesday covered the state-backed exclusion clause that most people have never read. Today is about the practical controls that stand between you and an insurer’s forensic team finding reasons to dispute your claim.
There are six of them. They are not complicated. They are just rarely done completely, with evidence.
Important note. This article is for information and educational purposes only. It does not constitute regulated insurance advice. For advice on your specific policy, speak with a qualified, FCA-authorised broker.
Before You Start: The Evidence Principle
Everything in this guide operates on one principle: having a control is not the same as being able to prove you have a control.
After a breach, the insurer’s forensic team will compare your proposal form answers against the technical reality of your network. They will ask you to produce evidence. Screenshots. Exports. Logs. Reports. If you cannot produce it, the control does not exist from their perspective. Your intention does not count. The evidence does.
So for each of the six controls below, I am going to tell you what “in place” means, and what evidence you need to keep.
Control 1: Multi-Factor Authentication
What “in place” actually means: MFA is enforced (not just enabled) for every user, on every email account, every remote access route (VPN, remote desktop, cloud applications), and every account with administrator or privileged access. No exceptions. No exemptions for senior staff.
The partial deployment trap: The most common failure I see is a business that has enabled MFA for Microsoft 365 and the main VPN, considers the job done, and has never checked whether it is enforced across all accounts, whether all users have actually completed enrolment, or whether there are other remote access services running in parallel.
What to do:
- Pull a list of all users from your Microsoft 365 or Google Workspace admin console
- Check the MFA registration status for each user: not just whether the option is available, but whether each account has completed setup and has MFA enforced (not just offered)
- Check every remote access service: VPN, Remote Desktop, any remote management tools, any cloud-hosted applications
- For any legacy system that genuinely cannot support MFA, document the exception, restrict access to that system to the minimum necessary, and make sure the exception is disclosed on your proposal form
Evidence to keep:
- A screenshot or export of your MFA policy settings, showing enforcement status
- A report or screenshot showing MFA registration status for all users, with a date
- A list of any exceptions, with justification and compensating controls documented
- Date of last review
Good enough standard for a typical UK SMB: MFA on all Microsoft 365 or Google Workspace accounts (enforced, not optional), MFA on VPN or remote access, and MFA on any admin or shared accounts. Legacy exceptions documented and restricted. Review the status quarterly and keep dated records.
Control 2: Backups
What “in place” actually means: Regular backups of critical data, with at least one copy that is logically isolated from your main network (offline, immutable cloud storage, or a separate network that cannot be reached from your main environment), tested with a documented restore within the last six months.
The backup failure patterns:
- Backup running to a network share on the same network. When ransomware encrypts your files, it encrypts the backup too.
- Backup running correctly, but never tested. You discover on breach day that the last six months of restores failed silently.
- Backup scope that misses critical systems or databases.
What to do:
- Identify your critical data: customer records, financial data, operational data, any regulated data
- Confirm your backup covers all of it, not just your main file server
- Check where your backup goes. If it can be reached from a compromised workstation, it is not isolated
- Run a restore test. Restore a specific file or folder from a specific backup date, confirm it works, and write down the date, what you restored, and how long it took
- Set a calendar reminder to repeat this every three to six months
Evidence to keep:
- Backup job completion reports, showing dates and success/failure status
- Documentation of where backups are stored (ideally confirming isolation from main network)
- Written record of restore tests: date, what was restored, result, how long it took
- Any vendor documentation confirming immutability settings on cloud backup
Good enough standard for a typical UK SMB: Daily backup to an isolated destination (offline drive disconnected after backup, or cloud backup with immutability enabled), full backup of all critical systems and data, restore test completed and documented every six months.
Control 3: Patch Management
What “in place” actually means: Critical security patches are applied within a defined timeframe (most policies specify 14 to 30 days for critical patches), across all systems including servers, workstations, and any third-party applications, with a log to prove it.
The patching failure patterns:
- Patches applied to workstations reasonably promptly, but servers patched infrequently because of production concerns
- Patches applied but not logged, so there is no evidence when the forensic team asks
- Certain systems excluded from patch management because they are old or because patching them requires downtime the business is reluctant to accept
What to do:
- Define your patching policy: what is the maximum time between a critical patch release and its application? Write it down. One page is sufficient.
- Identify all systems that need patching: workstations, servers, network equipment, any internet-facing services
- Set up a process to receive and act on patch notifications. Microsoft, Adobe, your network equipment vendors, and your software suppliers all have security bulletin services.
- Run a patch report after each patch cycle and keep it. Most endpoint management tools (including Microsoft Intune and the Windows Update for Business policy) can export patch compliance reports.
- For any system that cannot be patched promptly, document the reason, restrict access to that system, and consider whether it needs to be disclosed on your proposal form.
Evidence to keep:
- Written patching policy with defined timelines
- Patch compliance reports, dated, showing which patches were applied and when
- Documentation of any exceptions, with compensating controls
Good enough standard for a typical UK SMB: Critical patches applied within 30 days on a best-efforts basis, with a genuine process and a log to prove it. Perfect is the enemy of good here. A documented 30-day process that you actually follow is better than an aspirational 14-day claim you cannot verify.
Control 4: Default Credentials and Account Hygiene
What “in place” actually means: No default administrator passwords on any device or system. No shared local admin accounts without a proper process. Administrative accounts limited to the people who actually need them.
The failure pattern: Network equipment, servers, and applications are routinely shipped with default credentials. Many businesses never change them. Attackers know this. Many ransomware attacks begin with an attacker walking in through a door that was left with the factory key still in it.
What to do:
- List every network device: routers, switches, firewalls, wireless access points, NAS devices
- Confirm the admin password on each one has been changed from the default
- List any shared local administrator accounts on servers or workstations. These should be managed through a tool like Local Administrator Password Solution (LAPS) if you have the technical capability, or at minimum should have unique, strong passwords documented in a secure password manager.
- Review who has administrator rights on your systems. It is usually far more people than actually need it.
Evidence to keep:
- A record confirming default passwords have been changed (does not need to include the actual passwords, just confirmation it was done and when)
- Your password management approach for privileged accounts
- A list of who holds administrator rights, reviewed at least annually
Control 5: Basic Logging
What “in place” actually means: Your key systems keep logs for long enough that, after a breach, you can reconstruct what happened. Most forensic investigations need at least 90 days of logs to understand how an attacker moved through a network.
The failure pattern: Windows event logs set to overwrite after seven days. No logging on the VPN. No central collection of logs from different systems. The forensic team asks for logs and discovers they were overwritten within 48 hours of the breach.
What to do:
- Check the log retention settings on your Windows servers and workstations. Increase the maximum log size and set the retention period appropriately.
- If your VPN or firewall logs to a file or a management console, check the retention period and increase it if it is less than 90 days.
- If you have a cloud service like Microsoft 365 or Google Workspace, check the audit log retention settings in the admin console. Microsoft 365 Business Premium includes 90-day audit log retention. Standard Microsoft 365 plans may be shorter.
- Consider centralising logs from multiple systems into a single location (a SIEM tool, or even a simple syslog server) if you have the technical capability.
Evidence to keep:
- Log retention settings for key systems, confirmed and dated
- Confirmation that centralised logging is in place, if applicable
Control 6: A Written Incident Response Plan
What “in place” actually means: A written document, accessible to the people who need it, that answers four questions: who do we call when it happens, who can authorise shutting systems down, who communicates with customers and staff, and who contacts the insurer?
What to do: Write it. One page. It does not need to be a formal document. It needs to exist.
Your one-page plan should include:
- The insurer’s 24-hour incident hotline number (find it now, not during an incident)
- Your IT provider or managed service company’s emergency contact number
- The name and mobile number of the person in your business who can authorise major decisions (shutting down systems, paying costs, communicating externally)
- The name of who handles customer communication
- Three immediate actions: contain (disconnect affected systems from the network), call IT, call the insurer
- A commitment not to pay a ransom or wipe systems before talking to the insurer
Print it. Put a copy in a physical location that does not depend on your network being up. The most common failure I see is incident plans stored on a shared drive that becomes inaccessible during the incident.
The Breach Day Protocol
In Episode 15, Mauven summarised the timeline for the first 72 hours. These are the actions that protect your claim:
Immediate: Disconnect affected systems from the network. Pull the network cable, disable the wireless. Not the power: turning systems off destroys forensic evidence. Call IT and say this is a priority one incident.
Within hours: Call the insurer or broker. Do not wait until you understand the full scope. Early notification is a contractual obligation in most policies. Missing the notification window (often 24 to 48 hours) gives the insurer an argument you do not want them to have.
Throughout: Keep a written log. Times, actions, decisions, who did what. That log is evidence of your good faith response. It can also protect you if there are later disputes about what happened and when.
Never: Pay a ransom without talking to the insurer first. Many policies have consent clauses around ransom payments, including concerns about sanctions. Wipe and rebuild systems before forensics have seen them, unless the business has no other option to survive. Rewrite history, let anyone tidy up the story, or quietly implement controls you wish you had before the investigation starts.
How to Turn This Into a Competitive Advantage
Going through this checklist and being able to document that you meet all six controls puts you in a materially better position than most of your competitors. That is a legitimate business advantage:
- Lower cyber insurance premiums (some insurers offer discounts of 10 to 25% for businesses with documented controls and Cyber Essentials certification)
- Faster claim processing when the controls are evidenced rather than contested
- A stronger story for customers, procurement teams, and business partners who ask about your security posture
How to Sell This to Your Board
The cost of implementing and documenting these six controls is measurable and modest. The cost of a denied cyber claim is potentially terminal. That is a straightforward risk/return argument:
Risk reduction: Six controls, properly implemented and documented, address the majority of reasons UK cyber claims are denied.
Premium savings: Evidence of strong controls is increasingly reflected in lower premiums. The investment in documentation can pay for itself in the first renewal.
Supplier qualification: Buyers who require cyber insurance as a supplier condition are also increasingly asking about the underlying controls. Getting this right protects existing contracts and opens new ones.
What This Means for Your Business
The six controls above are not aspirational. They are achievable for any UK SMB with a functioning IT environment, within weeks rather than months. None of them require significant capital expenditure.
What they do require is someone taking ownership and following through. That person might be you, your IT provider, or a managed service company. But it has to be someone specific, with a deadline, and a plan to produce the evidence that matters.
Pick one control. Start today.
Listen to the full episode: The Small Business Cyber Security Guy Podcast - Episode 15
Related Posts:
- The Proposal Form That’s Building a Landmine Under Your Business
- You Bought Cyber Insurance. Congratulations. Now Read the Bloody Small Print.
- You’ve Got a Flood Plan, But No Cyber Plan? Here’s Why That’s a Business Killer