A cyber incident is not usually lost because the attack was too clever. It is often lost because the paperwork cannot prove the basics: what happened, when you reported it, and what controls were in place at the time. For many SMEs, that gap turns a valid event into a declined claim.
Many cyber claims are declined because SMEs cannot prove what happened, when they reported it, or what controls were in place. The safest approach is to keep a dated incident file with logs, emails, invoices, screenshots, policy terms and evidence of MFA, then match every claim item to supporting documents before submitting.
If your insurer has already pushed back, do not start by writing a long explanation. Start by sorting the file into three buckets: what happened, what was done, and what the policy covers. That split helps you see whether the problem is technical, a process miss, or a coverage issue.
A denial is usually caused by one missing item, like no proof of MFA, a late notice email, or a cost that is not linked to the incident. Rebuild the paper trail as if an outsider had to check it in order. A file that is chronological, dated, and tied to each cost is far harder to dismiss than a folder of loose screenshots and forwarded emails.
A denial usually falls into one of three groups: missing proof, late action, or a policy mismatch. Missing proof means the insurer says you have not shown enough evidence. Late action means you missed a notice or response deadline. A policy mismatch means the loss may sit outside the wording, even if the attack really happened.
The most common trap is treating every refusal as if it needs the same reply. If the insurer says the loss was excluded, you need policy wording and facts. If the insurer says the evidence is weak, you need logs, invoices, and a dated incident timeline.
The three denial types
Technical failure means the insurer could not verify the event. That often happens when logs were not saved, screenshots were altered, or the first detection time is only based on memory. A process failure means the right people were not told on time, or the wrong provider was used. A coverage failure means the policy wording did not include the loss, or the application gave the insurer the wrong picture.
The Financial Conduct Authority expects firms to handle claims fairly, and the Insurance Act 2015 makes truthful, careful disclosure a serious matter. If your file is messy, the insurer may treat that as a risk signal rather than a small admin slip.
What insurers expect in your file
Insurers want a file that tells the same story from start to finish. That means the first alert, the first response, the costs, and the policy hook must all line up. A clean file is not fancy. It is just easy to check.
Think of the file as a receipt trail. If you bought a laptop, you would keep the invoice, proof of payment, and warranty. A cyber claim is the same, only the receipt trail includes logs, emails, screenshots, and vendor reports. The insurer is asking one question: can we see the loss and link it to cover?
Incident timeline and first notice
Build the incident timeline first. Start with the earliest sign of trouble, then add every later event in order. Include the person who noticed it, the device or account involved, the time of first notice, and the time you told your broker, insurer, IT supplier, or breach coach.
Use exact times where you can. If you cannot, use a clear range and say why. A claim file with “around 9 am” and a matching email at 9:07 am is much better than a file that only says “morning”.
Logs, screenshots, and audit trails
Keep the original files, not just pasted images in a Word document. Logs are the system’s own record of what happened. Audit trails are the trail of actions, like logins, deletions, and file changes. Screenshots help, but they should sit beside the original source, not replace it.
If you are dealing with ransomware or account takeover, save the alert, the affected email headers, the IP address details, and any security tool output. Keep original evidence in a read-only folder, then work from copies.
Policy wording and notification requirements
Read the notification section of the policy before you send any new evidence. The wording often says who must be told, how fast, and by which route. Some policies require notice within 24 to 72 hours. Others want the approved panel provider used first. If you miss that, the insurer may say the process was not followed.
If the policy has a strict notice deadline or a named response provider, do not wait while you “gather everything first”. Send the notice with what you have, then follow up in writing with the missing papers.
Documents to keep before an incident
The best claim files are built before the incident. That sounds boring, but it saves days later. A small set of dated records can stop a denial that would otherwise come from weak proof.
You do not need a giant archive. You need a sensible folder structure and a short list of proof items. For most SMEs, that means access records, MFA evidence, backup proof, patch records, a response plan, and a list of who to call.
MFA and access control evidence
Keep proof that multi-factor authentication, or MFA, was turned on for key accounts. MFA means a second check after the password, like a code on a phone or an app prompt. Save screenshots from admin pages, setup emails, or export reports that show the date it was enabled.
Also keep evidence of who can access what. A simple user list is fine if it shows privileged accounts, active users, and any removals after someone leaves. A dated admin screenshot or exported report is much stronger than saying MFA was “on for everyone” without proof.
Backup records and patch logs
Keep backup reports and patch logs together. Backups are your copies of data. Patches are the updates that close known holes, like locking a door after a break-in. Together they show the business tried to reduce loss, which helps both the claims file and the underwriting picture.
Patches should show the date installed, the system name, and any failures. Backup records should show successful runs, restore tests, and the date of the last test. Do not wait for an incident to ask for these reports.
Keep a short incident response plan and a call list. The plan should say who leads, who contacts the insurer, who calls the IT provider, and who handles staff updates. It should also note where evidence is saved and who can approve spend.
A one-page plan often works better than a long document. For businesses that handle personal data, the plan should also mention the Data Protection Act 2018, UK GDPR, and when to consider the ICO.
Before an incident, an SME should keep a small but specific set of records that can later prove the state of the business at the time of loss. That usually means MFA enrolment evidence, user-access lists, privileged-account approvals, patch and backup reports, supplier contracts, cyber insurance claim correspondence, and the current policy wording. After an incident, the file should add the incident timeline, first notice of loss, internal ticket notes, preserved logs and screenshots, forensic reports, invoices, and a proof of loss schedule that links each cost to the event.
In practice, a ransomware response file that includes the original alert, endpoint logs, a restoration record, and the payment decision is much easier to defend than a folder of scattered emails and screenshots with no sequence.
How to rebuild an incomplete claim file
If the insurer has already said the file is incomplete, rebuild it in order. Start from the incident, not from the cost. That gives the claim a spine, and everything else hangs from that spine.
The fastest way is to make one master timeline and one master evidence list. Then match each expense, email, and report to a point on that timeline. A business gathers invoices first, then tries to explain the event later; the better method is event first, spend second, proof for both.
Recreate the incident timeline
Start by asking three questions: what was first seen, who saw it, and what happened next. Then pull dated evidence for each answer. Use emails, ticket notes, logs, call records, and supplier messages.
If you have no exact time, use a range and mark it clearly as estimated. Do not hide the gap. The insurer will spot it anyway, and a clean estimate is better than a guessed exact minute.
Match costs to the incident
Match every invoice to one incident activity. For example, forensic investigation, system restoration, legal advice, customer notice, call centre support, and business interruption costs should each point to a dated event or instruction. If a spend was for general IT work, say so and keep it separate.
Use a simple table if needed, with date, supplier, amount, why it was needed, and the evidence that links it to the incident.
| Claim item |
Best supporting proof |
Common gap |
| Forensic report |
Instruction email, invoice, final report |
No written instruction from the insured |
| Business interruption |
Revenue figures, downtime log, restoration dates |
Only a rough estimate of lost sales |
| Ransomware response |
Alert, incident notes, provider ticket, payment approval |
No link between action and threat |
Collect third-party reports
Bring in the reports from outside firms in the order they were used. That may include forensic investigators, legal advisers, breach coaches, payroll vendors, or cloud providers. Keep the instruction, the report, and the invoice together.
A report without instruction can look untethered. An invoice without a report can look unsupported. A report and invoice without a timeline can still leave the insurer unsure what the money was for.
A workable audit trail starts with a master chronology and a source index. List each item in order: the first alert, the first internal report, the first notice to the insurer, each control that was checked, and every expense raised afterwards. For each document, note who created it, when it was created, where the original file is stored, and whether it is an email, log export, screenshot, or invoice.
If the claim involves account takeover, keep the login history, MFA evidence, password reset records, and any change in administrator rights. This kind of structure makes documentation gaps obvious early and helps show that the evidence has not been edited or selectively assembled.
Technical, process, and coverage failures
Not every refusal should be fought the same way. Separate the problem before you reply. That saves time and stops you sending the wrong kind of evidence.
Technical failures are about proof. Process failures are about timing and notice. Coverage failures are about the contract. If you mix them up, you may answer a policy question with a spreadsheet, or answer a log issue with an apology letter.
Missing logs or poor evidence
Missing logs are the easiest technical weakness to spot. If the insurer asks how the breach happened and you cannot show access records, email headers, or system alerts, the file looks thin. That does not always end the claim, but it makes it harder.
What helps most is original evidence and a note on why anything is missing. For example, if a cloud tool overwrote logs after 14 days, say that and show the retention setting. That is much stronger than pretending the data existed.
Late notice or wrong provider
Late notice is a process failure. The insurer may require early notice, sometimes within 24 to 72 hours, and may ask you to use approved providers. If you wait for perfect paperwork, you may miss the window.
Keep proof of the notice itself: the sent email, portal receipt, call note, or broker message. Without that, you may know you told them, but you may not be able to prove it.
Excluded loss or misrepresentation
Coverage problems are different. If the policy excludes social engineering, losses from a supplier failure, or certain unencrypted devices, no amount of tidy paperwork will fix that. The answer is the wording, not the file shape.
Misrepresentation is trickier. If the application said MFA was in place everywhere and the logs show it was not, the insurer may rely on that gap. The application pack should be kept with the claim file.
Quick audit checklist
Use this checklist before you send a claim or a challenge letter. It is short on purpose. If you cannot tick an item, find the document before you reply.
- Incident date and first notice: show when the issue first appeared and when it was reported.
- Original evidence: keep logs, emails, screenshots, and ticket notes in dated folders.
- Policy match: link each cost to wording that shows why it should be covered.
- Notice proof: keep the email, portal receipt, or call note proving you notified on time.
- Control evidence: save MFA, backup, and patch records that were in place before the incident.
- Third-party papers: attach reports, instructions, and invoices from outside providers.
If you can only do one thing today, build the timeline and save the originals.
Frequently asked questions
What are the two main reasons for denying a claim?
The two main reasons are missing proof and policy mismatch. Missing proof means the insurer cannot verify what happened or when you reported it. Policy mismatch means the loss may sit outside the wording or the application details do not line up.
What is the 90 10 rule in cyber security?
The 90 10 rule usually means 90% of security depends on people and process, and 10% on tools. It is a rough idea, not a legal rule. For claims, that matters because poor process often shows up as missing notice, weak logs, or bad record keeping.
What causes 95% of all cybersecurity breaches?
There is no single official cause for 95% of breaches across every study. Many incidents involve phishing, weak passwords, stolen credentials, or simple human error. The safe move is to record the exact cause in your file rather than guess.
Close the file and prepare the reply
Send a short reply that points to the documents, not to emotion. Start with the incident date, the notice date, the policy section, and the exact proof you are attaching. That makes the response easy to review.
If you need to challenge a refusal, do not flood the insurer with every document at once. Send the strongest items first: the timeline, the notice proof, the key logs, and the cost summary. Then add the rest in a second round if needed.
A practical final test is simple. If a stranger could read your file in 10 minutes and understand what happened, what was covered, and what each cost was for, you are much closer to a defendable claim. If not, keep rebuilding before you send.
If a cyber claim is declined, the response should focus on curing the exact weakness the insurer identified. Where the issue is missing evidence, send the missing logs, screenshots, invoices, and an updated incident timeline with a short index. Where the issue is late notice or a process error, explain the reason for the delay and attach proof of the first notice of loss, such as the broker email, portal receipt, or call note. Where the issue is coverage mismatch, quote the relevant policy wording and show why the loss fits the insuring clause.
If the file is still rejected, ask for the denial grounds in writing, correct the package, and resubmit a tighter, dated bundle rather than a broad narrative with no supporting paper trail.
Where do 90% of all cyber incidents begin?
Many incidents begin with email, a password reset, or a user clicking a bad link. That is why email headers, alert logs, and MFA records matter so much. They often show the first real clue.
