In short and in plain language
Many firms have insurance against attacks on the internet. For this, they give details about their tech. For example, about updates and backups.
After a loss, the insurer can ask for proof. Then records from your normal work count.
The article shows which records can help. These include reports on updates. They also include tests that show data can be brought back.
We keep such records as part of our maintenance.
A cyber insurance policy does not pay out because it exists, but because the technical measures pledged in the risk questionnaire were actually in place at the time of the loss. That is why disputes rarely turn on the scope of cover and in almost every case on the evidence: if you tick multi-factor authentication, 3-2-1 backups or patch deadlines but cannot produce records later, a valid policy alone puts you in a weak position. The context is tightening: cyberattacks now cause 202.4 billion euros in damage to the German economy every year (Bitkom, Wirtschaftsschutz 2025), and according to the German Insurance Association only about one quarter of small and medium-sized enterprises meet all the basic obligations of the model cyber conditions (GDV). This article translates the usual questionnaire items into technical artefacts that sound operations produce anyway — and shows how an SLA maintenance contract keeps that evidence complete.
Key takeaways
- In a claim the evidence counts, not the policy: what was ticked in the risk questionnaire - patch deadlines, 3-2-1 backups, MFA, role concept - must be provably in place at the time of loss. Only about one quarter of SMEs meet all basic obligations (GDV).
- A patch report shows more than the current version: trigger with date, severity, version before and after, timestamp, the role that acted and the test result. The BSI counts an average of 119 new vulnerabilities per day (BSI, situation report 2025).
- A green job log only proves a backup ran. Restorability is shown by a dated restore record with duration, target environment and outcome, plus evidence that one copy sits beyond the reach of the production system.
- MFA evidence fails on the word all: shop backend, hosting panel, SSH, VPN, deployment pipeline, domain management and service-provider accounts each belong in the coverage report, with technical accounts backed by documented compensating controls such as IP binding and rotation.
- A component inventory with exact versions and end-of-support dates is what makes an advisory attributable at all; alert and availability history date the incident. 48 percent of companies have no emergency plan (GDV, Forsa survey 2025).
- Records must be gapless, tamper-evident and attributable: ticket trails and repository histories carry more weight than a spreadsheet filled in later. Whether a breach of obligations has consequences is settled by the policy, the insurer and legal counsel alone.
Why the dispute is about the evidence
Cyber insurance is no longer a niche product in Germany. Insurers most recently counted around 261,000 cyber policies, up 15.7 percent year on year (GDV). Premium income rose by about a quarter to 309 million euros, while claims paid grew by almost 50 percent to 180 million euros (GDV). The combined ratio therefore climbed to 97 percent, after 77.7 percent the year before (GDV) — claims consumed nearly all premium income. When a line of business operates at that margin, two things tighten at once: pricing and scrutiny.
That is exactly what shop operators are feeling in 2026. Internationally the market keeps growing — Munich Re puts the global premium volume for cyber cover at around 15.3 billion US dollars and expects it to exceed 32 billion US dollars by 2030, at annual growth of more than 10 percent (Munich Re, Cyber Insurance Report). At the same time this still amounts to less than 1 percent of the global property and casualty premium volume (Munich Re, Cyber Insurance Report). A growing market, a strained claims picture, more concrete requirements: cover is not only getting more expensive, it is also being tied more precisely to the actual operating state.
What this article is — and what it is not
The gap in question is well documented. In a Forsa survey commissioned by the GDV, 77 percent (GDV, Forsa survey 2025) of the companies surveyed believe they are adequately protected against cyberattacks, while 52 percent rate their IT security posture better than it actually is (GDV, Forsa survey 2025). More than two thirds do not even meet basic criteria such as strong passwords and regular updates (GDV, Forsa survey 2025). In everyday business this overestimation has no consequences — in the questionnaire it becomes a pledge, and in a claim it becomes a question about proof.
The risk questionnaire is a pledge about operations
A risk questionnaire looks like a form but works like a description of the current state. What you tick is what applies at the time of application and is meant to apply throughout the contract: are security updates installed within a defined deadline? Do backups follow the 3-2-1 principle? Is multi-factor authentication active for remote access and administrative accounts? Is there a role and permission concept? None of these questions describes an intention — each describes a practice, and every practice either leaves traces in the systems or it does not.
The GDV deliberately framed the obligations in its model conditions as a catalogue of readily implementable baseline measures: regular data backups, strong passwords, individual accounts, anti-virus protection, firewalls and promptly installed security updates (GDV). The fact that only around one quarter of SMEs meet all of these baseline requirements (GDV), and that on average only a good half of the basic IT security requirements are implemented (GDV), shows the size of the delta between form and reality.
| Item in the questionnaire | Technical artefact that evidences it | Typical gap |
|---|---|---|
| Security updates are installed promptly | Patch report per change: CVE identifier, version before and after, timestamp, person who performed it | Only a current version list, no history and no proof that the deadline was met |
| Backups following the 3-2-1 principle | Backup log plus a documented restore test with date, duration and checksum | Successful job logs, but not a single evidenced restore |
| MFA for external access | Coverage report per account and access path, including exceptions and their justification | MFA active in the shop backend, but not on SSH, hosting panel or VPN |
| Role and permission concept | Access and role matrix with a change log: who received or lost which role and when | Permissions that grew over time without documentation, departed accounts still active |
| Deployed software is maintained | Component inventory with version and support status per extension, library and runtime | No overview of components outside their support window |
| Attacks are detected | Monitoring and alerting history with alert time, recipient and response time | Monitoring active, but without an analysable history and without documented escalation |
The evidence has to match the point in time
Patch evidence: timestamps beat recollection
Patch management is where the evidence question comes up most often — because it is measurable. For the reporting period from July 2024 to June 2025 the BSI recorded an average of 119 new vulnerabilities per day, about 24 percent more than in the previous period (BSI, Lagebericht 2025). Vulnerabilities of medium and high severity rose by roughly 20 percent, while critical ones remained almost unchanged at minus 2 percent (BSI, Lagebericht 2025). A shop with extensions, themes and libraries draws from exactly this stream — and the question is not whether a relevant CVE appears, but how quickly it is closed and how that is documented.
A robust patch report is therefore more than a list of installed versions. It links the trigger to the response and makes the deadline verifiable. How that chain is built technically is covered in detail in the article on CVE and security patch management for shops; what matters here is only which fields a third party needs to see.
- Trigger with a date: publication of the advisory or release of the update, not the moment you happened to notice it
- Assessment: severity, whether your own installation is affected, and the resulting deadline from the patch SLA
- Implementation: version before and after, installation timestamp, performing role, target system (staging and production kept separate)
- Verification: the result of the regression test after the update, so the report evidences not just installation but working functionality
- Exceptions: updates deliberately not installed, with justification, compensating measure and a review date
- Tamper evidence: storage in a ticket or repository history that makes subsequent changes visible
An exception is not a flaw — silence is
Backups: a job log is not a restore test
Backups are the second classic — and the point where most evidence stops halfway. A green job status proves that a process ran. It does not prove that a working shop can be reconstructed from the result. In a claim that difference is substantial: with ransomware, evidenced recoverability decides whether there is any alternative to paying at all. 34 percent of companies were recently affected by ransomware — almost three times as many as in 2022 with 12 percent (Bitkom, Wirtschaftsschutz 2025) — and 15 percent of those affected paid a ransom (Bitkom, Wirtschaftsschutz 2025).
The backup record
Time, scope, destination and checksum per backup, plus the retention period. Only the checksum turns a job status into evidence about the content.
The restore record
Date of the test, the state restored, the time it took, the target environment and a documented outcome. Without that line, recoverability remains an assumption.
Proof of separation
Evidence that at least one copy sits beyond the reach of the production system — offline or immutable, so a compromised account cannot delete it along the way.
How often a restore test makes sense and which targets for recovery time and data loss sit behind it belongs to the backup strategy; the article on backup strategies for online shops covers RPO and RTO in depth. For the evidence question a simple rule is enough: every test that took place produces a line with date, duration and outcome — and over months those lines form the chain an assessor wants to see. A backup service with fixed test intervals delivers that chain as a by-product of operations.
A backup without a performed restore is a hope with a timestamp. Only the restore record turns it into evidence — for your own management, for your customers, and for a third party asking questions after a loss.
Access, roles and MFA coverage across every path
With multi-factor authentication the evidence trap is not in the technology but in the word "all". Questionnaires usually ask for MFA on external access — meaning every path from the outside into the systems: shop backend, hosting panel, SSH, database interfaces, VPN, deployment pipeline, domain management and the accounts of external service providers. One tick covers all of that; a report has to show each one. The setup itself is described in the article on hardening shop admin access with MFA — here the question is coverage.
The attack data shows why this path is the decisive one: 68 percent of successful cyberattacks begin with phishing or malware emails (GDV, Forsa survey 2025), in other words with the takeover of credentials or endpoints. An account without a second factor is exactly the door whose key has already been lifted.
- A list of accounts, not a sample: every administrative and external account individually, with the status of the second factor and the activation date
- Access paths tracked separately: backend, servers, hosting panel, VPN, deployment and domain management assessed one by one, not as a single line
- Service provider accounts included: access held by agencies, freelancers and support partners belongs in the same matrix as internal accounts
- Technical accounts named: API keys and service accounts cannot use a second factor — they need documented compensating measures such as IP binding and rotation
- Exceptions justified and time-limited: every exception with a reason, a compensating measure and a review date instead of quietly staying open
- Change log maintained: access comes and goes; only the log shows that departed accounts were revoked promptly
The role matrix is the underrated record
Inventory and support status of the components in use
Questionnaires usually ask about maintained software. Technically that means there is an overview of what is actually running — with version and support status. Without that inventory the statement about maintained software cannot be evidenced, because the underlying population is missing. In a shop it covers the core, every extension, the theme, the libraries in the dependency chain, the runtime, database and web server, as well as the scripts embedded in the pages.
That list is also the basis of the supply chain view explored in the article on supply chain attacks via shop dependencies — and it is the precondition for mapping an advisory to an installation in the first place. If you do not know that a library is embedded, you cannot close its vulnerability within the deadline, and consequently you cannot evidence it either.
Inventory with versions
Core, extensions, themes, libraries, PHP version, database and web server — each with an exact version, not with "current".
Support status and end date
The end of security support per component. Only that date makes visible which building blocks need to be replaced on a plan.
Origin and responsibility
Where the component comes from, who maintains it, how it is sourced. That answers the supply chain question with substance instead of assumption.
Support status has the greatest leverage here, because it creates deadlines before an incident forces them. How to plan that for runtimes is shown in the article on PHP end-of-life management. The domain and DNS layer belongs in this inventory too: which safeguards apply there and how they are monitored is covered in the article on DNSSEC, registrar lock and DNS monitoring.
Monitoring and incident history as a timeline
The final group of records concerns whether an incident was noticed and handled. It determines how the sequence of events can be reconstructed — and every third party assessing a loss wants to see that. The starting position is unambiguous: for the reporting period the BSI documents 950 reported ransomware attacks (BSI, Lagebericht 2025), around 80 percent of which hit small and medium-sized enterprises (GDV). At the same time roughly 280,000 new malware variants emerge every day (BSI, Lagebericht 2025). Anyone who keeps no analysable history in this situation can evidence neither the timing nor the scope when it matters.
Strikingly, preparation is widely missing: 48 percent of the companies surveyed have no emergency plan (GDV, Forsa survey 2025). A plan is not only a response aid but an artefact in itself — it shows that the procedure existed before the incident rather than being invented afterwards. Which building blocks belong to it is described in the article on the emergency plan for hacked websites; the technical side of analysis is explored in the article on log monitoring and alerting.
- Alert history: which alert fired when, who received it and when it was acknowledged — the basis of any timeline
- Availability and error history: measurements over time, so an outage can be dated rather than merely asserted
- Retained log data: access, application and server logs with a defined retention period and protection against later modification
- Incident documentation: first knowledge, measures taken, people involved, recovery and follow-up as a continuous record
- Communication trail: notifications to affected parties, authorities or partners with timestamps — also relevant for regulatory deadlines
- Follow-up: what was changed so the same path is not open again, including the implementation date
Records work beyond insurance
The evidence file: complete rather than retrofitted
Individual artefacts are worth little as long as they are scattered across mailboxes, server paths and people's heads. They only develop value as an ordered collection that gives an answer for any given date. In practice a simple structure has proven itself, mirroring the questionnaire: one section per pledged measure, containing the continuously produced records in chronological order.
Patch history
Continuous reports with CVE, version, timestamp and test result — including justified exceptions with review dates.
Backup and restore evidence
Backup logs with checksums plus the dated restore tests with duration and outcome.
Access and MFA
Role and access matrix with a change log, plus the coverage report across all external access paths.
Component inventory
Inventory with versions, support end dates and origin, updated with every change rather than once a year.
Monitoring history
Alerts, availability history and retained log data with a defined retention period.
Incident and response
Emergency plan, incident documentation, communication trail and follow-up as one coherent case.
Three properties decide whether this file holds up when it matters. First, completeness: a month without entries raises the question of what happened in that month. Second, tamper evidence: records that can be adjusted afterwards carry less weight with a third party — ticket histories, repository logs and write-protected storage are therefore stronger than a maintained spreadsheet. Third, attributability: every record needs a system, a date and a responsible role, otherwise it cannot be tied to the time of the loss.
- The record appears automatically: the artefact is produced by the activity instead of being recalled and reconstructed later
- Fixed intervals: restore test, permission review and inventory reconciliation have a date, not an intention
- One place to store them: records sit together rather than spread across mailboxes, local machines and hallway conversations
- Retention defined: how long records are kept is decided — the article on GDPR-compliant backup retention covers the data protection side
- Anchored in the contract: the records are a deliverable of the maintenance contract, not a favour — the article maintenance contract: what it should include sets out the scope
- Date-ready: the question "what was the state on 14 March?" has an answer from the file, not from memory
The economics keep the effort in proportion: the average cyber claim in the insurance statistics stands at 45,370 euros per reported incident (GDV), around 4,000 hacker attacks were most recently reported to insurers (GDV), and only about 3 percent of insured companies suffer a cyber loss in any given year (GDV). The serious case is rare, then — but expensive, and it arrives without notice. This is exactly why an SLA maintenance contract moves evidence keeping out of the individual case and into routine operations: monitoring produces the timeline, security updates produce the patch history, the backup service produces the restore records, and emergency support produces the incident documentation. The services overview page shows how the building blocks fit together.
Sources and studies
Related Articles
White-Label Maintenance for Agency Client Sites
Agencies build shops, then care slips. How white-label maintenance works: cooperation models, SLA boundaries, tenant separation and reports in your own brand.
Taking Over Shop Maintenance Without Downtime
When your current maintenance ends, the handover decides: secure the credentials, review the real state in 30 days and switch provider without shop downtime.
Response-Time SLA: What Good Emergency Support Does
Response-time SLA for online shops: severity levels P1 to P4, realistic MTTR values and how to recognize reliable emergency support with a committed response.