One in four claims is denied after an incident, and the problem is usually far less dramatic than people expect.
If security measures are said to be in place when they are not, an insurer may not be obliged to pay a claim. A cyber insurance cover can offer financial protection, legal support, forensic help and response services. It cannot correct weak controls after the event. That work has to happen first.
To avoid being that one in four, you should pay close attention to the familiar basics. So, let’s look more closely at the three tripwires that keep putting claims at risk.
1. Backups That Have Never Been Properly Tested
This is the control people trust too quickly because the language around it sounds comforting. However, “We have backups” tells you almost nothing. The conversation should carry on:
Can you restore them? Can you restore the right systems first? Have you tested under realistic conditions? Are the backups protected from the same incident that could hit production? Do the people responsible for recovery know the order, the dependencies and the timeframes involved?
A completed backup job only proves that data was copied somewhere. Recovery means the business can bring systems back in a controlled way, with the right data, in the right order, within a timeframe that the organisation can survive.
The National Cyber Security Centre (NCSC) highlights that ransomware will have a smaller impact if backups are kept separate from the network, or held in a cloud service designed for that purpose. That goes directly to the heart of the issue. A backup environment that is too exposed, too connected, or too lightly controlled can be damaged in the same incident as the production estate.
Restore testing carries more weight than backup completion rates. It shows whether recovery works outside the comfort of routine reporting. It shows whether data is intact, whether dependencies are understood, whether access to recovery tooling is still available, and whether the people involved can actually run the process under pressure.
There is another point worth stating plainly. Backup administration is itself a sensitive area. Who can change retention? Who can delete or alter sets? Who can access recovery tooling? Who reviews that access? Those questions become operational very quickly during a live incident.
If backups have never been properly tested, the business is relying on confidence rather than proof. That is a weak place to stand when systems are down, and costs are rising.
2. Incomplete MFA
This is one of the easiest controls to describe badly.
When a business says it has Multifactor Authentication (MFA), that often means MFA is in place for email, VPN, and a small number of administrator accounts. Then you look further: Supplier access is outside it. Recovery accounts are outside it. Remote tools are outside it. Older admin interfaces are outside it. Legacy systems are left alone because they are awkward, fragile, or poorly understood.
That is enough to cause serious trouble. An attacker does not need ten weak points. One is enough. If access to a critical system or a privileged account is not protected by MFA, the insurer will have every reason to question how accurately the control environment was presented.
That is the reason why “we have MFA” is a poor answer.
Where is MFA enforced? Which users are covered? Which systems are outside it? Are third-party connections included? Are recovery paths protected? Who approved any exceptions, and when were those exceptions last reviewed? If a business cannot answer those questions clearly, then it does not fully understand its own position.
NCSC states insurers may ask for information about technical, procedural and human controls, and that gathering those answers may require input from several people across the organisation or from outsourced providers. MFA should be reviewed and should be evidenced, not assumed.
Then, what is the right approach?
Map every route into important systems and data. Check privileged access, supplier access, remote management access and recovery access. Remove old exceptions that were never meant to last. If a gap must remain for a time, record it properly, assign ownership, and put strong compensating controls around it.
3. Patching That Slips
A patching policy does not prove that patching is under control. Neither does a regular cycle. Neither does a report showing activity across the estate. The real test is this: are known vulnerabilities on important systems being dealt with fast enough?
A patch is scheduled. An update is under review. A dependency has delayed the fix. The service owner is worried about downtime. The next maintenance window is a few weeks away. Meanwhile, the weakness remains in place, known to the business and potentially known to an attacker.
That is a risky position on any system. It is far worse on systems tied to operations, sensitive data, privileged access or recovery.
The NCSC advises organisations not to stop at an insurer’s minimum cyber security requirements. It says businesses should identify what needs the strongest protection and what scenarios must not happen. A process can look neat on paper and still leave the wrong vulnerabilities open on the wrong assets.
A better method starts with priority. Which systems would cause the greatest operational damage if they were compromised? Which assets hold sensitive information? Which vulnerabilities are being actively exploited? Which weaknesses would make ransomware, fraud, or service disruption worse? Those are the areas that need urgency.
Some delays are unavoidable. Fragile systems exist. Unsupported software exists. Change control can be tight for good reason. Once patching is deferred, though, the risk has to be handled properly. It needs a named owner, a clear rationale, a fixed review date, and real temporary controls. Without that discipline, the business has not managed the weakness. It has simply kept it.
If an incident later traces back to a vulnerability that sat open for weeks or months without proper handling, that becomes part of the claim story. No insurer expects perfection across a complex estate. It will expect evidence that obvious risks were not being ignored.
Final Thoughts on Securing Your Cyber Insurance Cover
Claims do not end up denied only because attackers were sophisticated. The claimers end up there because the controls were weaker than they thought, or because they described them more confidently than they should have.
To take the first steps towards meeting insurers’ requirements and addressing the most common causes of successful cyber attacks, focus on the basics with precision:
– Know where MFA applies and where it does not.
– Know which vulnerabilities remain open and why.
– Know whether backups can be restored under pressure, not just whether backup jobs complete on schedule.
– Make sure you understand your cyber insurance policy and are complying with any required controls.
– Ensure you have evidence that required controls and training are in place and operating effectively on an ongoing basis.
– Ensure recovery capability is tested frequently in an environment that reflects real-world conditions.
If you want to review your current cyber security position, get in touch with CiContinuity’s security consultants.
About the Author
Steve Dance, MBCS
Steve is an experienced consultant with in-depth experience of operational risk, resilience, business continuity, and information security management. He has worked with technical and non-technical management teams to develop and improve business continuity and information security capabilities for their organisation, including risk & exposure assessment, incident response & recovery, and the deployment of oversight, governance processes.
