Cyber insurance: website evidence agencies can supply

Why insurers ask about the website

Commercial cyber insurance is growing, but from a low base. In 2025 the number of policies rose by 15.7 percent to about 157,000 (GDV). At the same time only about 5 percent of companies are insured against the consequences of a cyber attack (GDV), roughly one in 20. The German Insurance Association names as one reason for the low uptake that many companies do not meet the basic IT security requirements. These requirements are usually a prerequisite for taking out cyber insurance (GDV).

Two further figures from the association show how wide the gap is. According to the insurers, only about one third of German companies have adequate protective measures in place; examples given include regular security updates, reliable backups, clear access rights and working emergency plans (GDV). In a Forsa survey commissioned by the GDV, 69 percent of the 300 mid-sized companies surveyed did not even meet all basic requirements, for instance because backup copies were stored incorrectly or systems were protected only by weak passwords (GDV, Forsa survey 2024). For new policies, the association says, insurers insist on effective protective measures (GDV).

For the insurer this is about money, not formalities. In 2025 insured losses from cyber attacks came to just under 200 million euros, and the average claim rose by 5.8 percent to 43,186 euros (GDV). At the same time, according to GDV statistics, only about 3 percent of insured companies report a cyber claim (GDV). The situation report of the German Federal Office for Information Security shows that small businesses are not left out: about 80 percent of reported attacks targeted small and medium-sized enterprises, for the reporting period 1 July 2024 to 30 June 2025 (BSI).

If the most basic security standards are not met, insurance cover becomes difficult as well.

— Jörg Asmussen, chief executive of the GDV, press release of 5 September 2024 (translated)

What the model terms require

The GDV publishes model terms for cyber risk insurance, the AVB Cyber. The cover page describes them as a non-binding announcement for optional use, deviating agreements are possible; the version cited here is dated February 2024 (AVB Cyber). Each insurer words its own terms, and the client's own policy is what counts. The model terms do show which duties are common and in what language they are framed. The technical obligations before an insured event are set out in section A1-16. Under A1-16.1 they include in particular that the policyholder's information processing systems

• a) distinguish between individual users and permission levels - with individual accounts for all users; administrative accounts are reserved for administrators and for administrative tasks only (AVB Cyber).
• b) are additionally protected against unauthorised access if they are exposed to an increased risk - an increased risk explicitly exists for devices reachable over the internet, that is servers; the terms give firewall and two-factor authentication as examples (AVB Cyber).
• c) have protection against malware whose level of protection is kept up to date automatically (AVB Cyber).
• d) are subject to a patch management procedure that ensures the timely installation of relevant security updates; systems and applications with known vulnerabilities must not be used without additional suitable safeguards (AVB Cyber).
• e) are subject to an at least weekly backup process, set up so that no system and no permission level has write access to both originals and duplicates (AVB Cyber).

Two further sentences matter especially for agencies. The policyholder has to ensure that the backup and restore process works through regular testing on a fixed schedule; by the wording, a running backup alone is not enough (AVB Cyber). And under A1-16.2 all statutory, official and contractually agreed security regulations must be observed, and particularly hazardous circumstances must be removed within a reasonable period at the insurer's request (AVB Cyber). If any of these obligations is breached, A1-16.3 refers to the legal consequences in B3-4, described further below (AVB Cyber).

For the website this means: the web server is a device reachable over the internet and therefore belongs to the increased risk group. The content management system, its extensions and the server software are applications within the meaning of patch management, and the website backup is part of the backup process. If the agency looks after these parts, a good share of the facts the insurer asks about lies with the agency, even though the obligation stays with the client as policyholder. If the insurer demands that a hazardous circumstance be removed, such as an outdated extension with a known vulnerability, in practice it is usually the agency that carries this out and has to document it.

What can be measured on the website from outside

Part of these facts is visible from outside, without access to the server: every visitor, every search engine and every attacker sees the same responses from the web server. Exactly these responses can be queried on a fixed schedule and stored with a date. This does not replace an examination of the server, but it answers the question of how the internet-facing system presented itself at a particular point in time. Six areas are particularly suitable:

The XICTRAQ security scan combines most of these points in one run: certificate and chain, security headers, embedded third-party scripts, mixed content, cookies and exposed paths, daily or weekly depending on the plan. For insurance purposes the individual finding matters less than the series. A scan from the day of the application says what the website looked like on that day. A series of scans over the whole policy year shows whether a flaw was fixed after it was found and how long that took. That is exactly the question that arises when timely installation of security updates is at stake.

The backup itself is not visible from outside, but its run is, once the backup script reports in. A heartbeat is a short call at the end of every successful run; if it does not arrive, monitoring raises an alert. How to set this up is described in the article on backup monitoring with heartbeats, and the feature itself is heartbeat monitoring for cron jobs and backups. For the evidence folder this is the series that matches the obligation of an at least weekly backup process (AVB Cyber): every run with a date, every gap with a date.

What only the client can show

The larger part of the obligations lies behind the website. Whether users and permission levels are separated, whether administrator accounts are used only for administrative work, whether workstations have up-to-date protection against malware and whether backups are protected from access by the systems being backed up cannot be measured from outside (AVB Cyber). Deriving such things from the outside view means writing an assumption into the questionnaire.

The agency can still supply evidence for its share, just from its own records instead of a measurement:

• Access: a list of all accounts the agency holds in the content management system, on the server and with the hosting provider, with role and date of the last review. How roles and an audit trail look in monitoring is shown in the article on team access control and audit trail.
• Update log: which component was brought to which version and when, and for deferred updates the reason and the compensating measure.
• Restore log: date, scope and duration of the last restore test, kept separate from the backup run.
• Incident list: every disruption with start, end, cause and action taken, even if no damage occurred.

Much of this information already exists if the agency works as a processor: the data processing agreement under Article 28 GDPR usually requires a description of the technical and organisational measures. And anyone looking after clients within the scope of NIS2 already knows similar questions from supply chain vetting under NIS2. The insurer asks in a similar way, but with a different consequence: this is not about supervision, it is about insurance cover. The following overview sorts the obligations in the model terms by what can be measured from outside and who provides the evidence.

The questionnaire at application

The questions before the contract is concluded are not a formality. Under B3-1.1 of the model terms, the policyholder has to disclose all known risk circumstances that the insurer has asked about in text form (AVB Cyber). If the policyholder breaches this duty of disclosure, the insurer can withdraw from the contract, and in that case there is no cover for the past either. There is no right of withdrawal if the policyholder proves that the incorrect or incomplete information was given neither intentionally nor with gross negligence; in the case of simple negligence or without fault, the insurer can terminate with a notice period of one month (AVB Cyber).

This leads to a clear division of work: the client answers and signs the questionnaire, the agency supplies the facts about the website, as measurements with a date rather than as an estimate. For the case where a representative concludes the contract, B3-1.1 expressly states that both the knowledge and fraudulent intent of the representative and those of the policyholder are to be taken into account (AVB Cyber). Everything the agency knows about the website therefore belongs in full in the documents the client receives before signing, including the uncomfortable findings. An open issue that is named in the application with a date for the fix is a different situation from an issue nobody mentioned.

What counts when a claim is made

Once damage has occurred, separate obligations apply. The policyholder has to notify the insurer of the damage without undue delay after becoming aware of it, and of facts that could result in liability towards third parties within one week (AVB Cyber). The policyholder also has to provide documents requested by the insurer whose procurement can reasonably be expected (AVB Cyber). For the agency this means: the documents the insurer asks for have to be at hand quickly, not only after a search through mailboxes and old tickets.

One obligation runs against every agency's reflex. Under B3-3.4 the policyholder has to leave the state of the damage unchanged until the insurer permits a change; if changes are unavoidable, the state of the damage has to be documented in a traceable way (AVB Cyber). If a compromised website serves, for example, fake CAPTCHAs with malicious code, the urge is to clean up immediately because visitors are at risk. Before the clean-up there should then be a snapshot and, where time allows, coordination with the insurer: screenshots, the delivered source code, headers, the modified files with checksums. The article on detecting and reporting defacement describes the procedure, and the screenshot changelog provides the state before the incident.

For breaches of obligations the model terms distinguish by degree of fault. For an intentional breach the insurer is released from its obligation to pay; for a grossly negligent breach it may reduce its benefit in proportion to the severity of the fault (AVB Cyber). It remains obliged to pay if the policyholder proves that there was no gross negligence, or that the breach was not causal for the insured event and the extent of the benefit (AVB Cyber). In both cases the policyholder has to provide the proof. A dated measurement series can help, for example if it shows that an update was installed shortly after its release, or that the attack came through a route that had nothing to do with the breached obligation. Whether it suffices in a given case is not for the agency to decide.

The evidence folder for application and renewal

All this adds up to one folder per client and policy year. It is not put together when a claim arises but continuously, and it is presented as a whole at application, at renewal and whenever the insurer asks. A fixed structure makes sense so that client, broker and insurer find the documents in the same place every year:

1. Scope: all of the client's domains and subdomains, host, content management system and the responsibilities between client, agency and host.
2. TLS and security headers: the measurement series over the year, each finding with the date it was fixed.
3. Versions and updates: update log, findings on visible versions and end of life, justified exceptions with compensating measures.
4. Backup and restore: the heartbeat series of backup runs and the logs of restore tests with their schedule.
5. Changes and incidents: screenshot changelog, incident list and the snapshots taken before clean-ups.
6. Agency access: accounts with role, two-factor sign-in status and date of the last review.
7. Claim procedure: contacts at client, agency, host and insurer, and the order of notification, securing the state of the damage and clean-up.

As a file in the project directory the structure can look like this. The addresses end in .invalid because they are sample data:

client: Client A
policy_year: 2026-11-01 to 2027-10-31
domains:
  - www.client.example.invalid
  - shop.client.example.invalid
responsible:
  website: agency
  server: hosting provider per contract
  workstations: client
registers:
  01-scope: domains-and-responsibilities.pdf
  02-tls-headers: scan-series-2026.pdf
  03-versions-updates: update-log.csv
  04-backup: heartbeat-series.pdf, restore-2026-03.pdf
  05-changes-incidents: changelog-export.pdf, incidents.csv
  06-agency-access: access-2026-10.csv
  07-claim-procedure: procedure-and-contacts.pdf
not_in_folder:
  - firewall and endpoint protection at the client
  - user management in the company network

A few commands are enough for a spot check on the day of the application. They show the security headers, the certificate expiry date and the checksum of a saved snapshot:

Such one-off queries are good for a spot check, but they are not yet a folder. The series only emerges when measurements run automatically and are filed as reports. How agencies set this up for many clients is described in the article on automated weekly client reports. With XICTRAQ, weekly or monthly PDF reports, optionally in your own branding, are produced for this and go straight into the matching register.

The agency's role and its limits

In this process the agency is a supplier of evidence, not an insurance intermediary and not a legal adviser. It does not assess whether a clause is valid, which policy fits or whether the insurer will pay in the event of a claim. It supplies facts about the part of the IT it looks after and states just as clearly which parts it does not look after. This boundary belongs in writing in the service contract, so that nobody relies on an assumed responsibility when a claim arises.

For agencies with many clients, the evidence folder is a service that can be described and invoiced: a fixed scope per website, a fixed date before renewal, a handover to the client with a short explanation. How XICTRAQ supports agencies with client accounts, reports and roles is set out on the page XICTRAQ for agencies.