Cyberversicherung: what German cyber insurers expect from a pentest

A growing share of the German companies we talk to are scoping a pentest partly because a Cyberversicherung (cyber-insurance) policy is in play. This post covers what the market commonly expects around pentests, and how we structure engagements and reports to meet it.

What insurers expect from the insured

Before granting or renewing cover, insurers commonly check for a set of baseline controls: firewalls and endpoint protection (EDR/XDR for larger environments), a documented patch/vulnerability process, MFA on remote access and privileged accounts, encryption of sensitive data, tested and segregated backups, role-based access control, network segmentation, a tested incident-response plan, security-awareness training, and DSGVO/NIS-2 compliance. None of this is pass/fail, and none of it is a legal baseline: insurers set their own conditions (GDV's AVB Cyber is a model policy, not a standard), so the bar moves with insurer, company size, industry, and claims history. We use this list as a gap-analysis lens during scoping: findings that touch one of these areas are worth flagging to you separately and early, since they affect your coverage position now, not just your security posture.

What insurers expect from the pentest itself

Insurers increasingly want a pentest repeated periodically (often annually) as evidence that declared controls hold up under real attack conditions, and market practice already treats it as a lever that can reduce premiums and pass renewal review. What they respond well to in the report is specific, and it's also how we build every report by default:

Answers given in an insurer's underwriting questionnaire are binding declarations. If our pentest turns up a gap between what was declared and what actually holds, that's information you should have before your next renewal. We call it out separately in the report.

Obligations that stay live during the engagement

These bind you, the client, but breaching them can cost you coverage, so we flag them during scoping. Cyber policies typically require maintaining the controls declared at underwriting throughout the policy term, reporting changes that materially raise risk (Gefahrerhöhung), and, on an actual incident, notifying the insurer without delay and using insurer-approved forensics/IR providers where required. Consequences scale with fault: negligent breach can reduce a payout, gross negligence or intent can void cover entirely.

Whether damage from an authorized, client-commissioned pentest itself could be read as a notifiable Gefahrerhöhung, or fall under a self-inflicted-loss exclusion, isn't something we've found a clean public answer to. It depends on your specific policy wording. Our practical mitigation, regardless: a written, signed Rules of Engagement before anything starts, a scope that excludes anything that could trigger real business interruption, and a recommendation that you loop in your insurer or broker before we touch production systems if your policy conditions coverage on maintaining continuous security posture.

Folding this into scoping

For engagements where your Cyberversicherung is in play, our scoping call covers: written authorization with explicit scope, timing window, and excluded systems/techniques; whether your policy requires insurer/broker notification before offensive testing, and getting that done before we start; what your policy or underwriting declared about your controls, so we can flag contradictions early; and a report structure (CVSS 3.1, proof-of-exploit, explicit scope, regulatory mapping) that doubles as insurer evidence without a second pass.

If your renewal or underwriting is coming up and you want a pentest that speaks to it directly, request an engagement.

← All posts