An insurer offering cyber insurance usually asks for a combination of documents: an overview of which personal data you process and for what purpose, a description of your technical and organisational security measures, proof that you have agreements with suppliers who process data on your behalf, and a protocol for if something goes wrong. Some insurers ask for these separately, others process them in one digital questionnaire.
There is no legally prescribed list of documents for cyber insurance. The GDPR itself imposes an accountability obligation: an organisation must be able to demonstrate that it thinks about the protection of personal data and has it in order. How that demonstrability looks is determined by the insurer itself, not by law. This is precisely the detail most overlooked at this purchase moment: entrepreneurs look for the form or certificate that will suffice, while insurers in practice mainly want to see that there is a coherent whole in place.
What an insurer typically wants to see
The core of most questionnaires is a processing register: an overview of which personal data you process, for what purpose, how long you keep it and who has access to it. In addition, you are often asked about data processing agreements with parties who process data on your behalf, such as your accounting software, your HR system or a marketing tool. A third recurring component is the data breach protocol: how do you identify an incident, who do you inform within your organisation and how do you assess whether notification to the Dutch Data Protection Authority is necessary. Those who are unsure whether an incident falls under this can see in a few questions where a situation roughly stands.
Insurers also often look beyond the GDPR alone. Questions about backups, password policy, two-factor authentication and who within the company has access to which systems are part of information security in a broader sense. This overlaps with privacy, but is not the same: a company can have a neat processing register and at the same time weak technical security, or vice versa. An overview of the measures you have actually taken helps to connect these two; see also how this is looked at when assessing data and privacy.
Why demonstrability is different from a quality mark
A frequently heard question is whether an ISO certificate or other quality mark replaces the proof an insurer is looking for. A certificate can carry weight, but rarely replaces the question about your own situation: which data does this particular company process, which suppliers does it work with, and what happens if something goes wrong. Supervisory authorities and insurers look at similar things on this point, but with a different purpose: the supervisory authority assesses compliance with the law, the insurer assesses a risk before issuing a policy. This difference explains why two insurers sometimes ask for slightly different documents, while the underlying basis — the register, the agreements, the protocol — is always the same.
What you can prepare in advance
It is wise to start with what is already there: which software and suppliers does your company use, and is there a data processing agreement for them. Next, it is a matter of recording what actually happens: which data is where, who can access it and how long it is kept. For companies mapping this out for the first time, a structured overview of frequently asked questions is a good starting point; see answers to questions that come up more often with this type of request.
If you'd prefer to first understand how such a document list is structured and where the information is based on, you can read about that in the knowledge base. There you'll find a short answer per topic with the source location in the official text, so you can verify yourself where a requirement comes from; see for example in the knowledge base with explanations by topic before you speak with an insurer.
From separate documents to a live register
The most challenging aspect of this purchasing moment is not drawing up a single document, but keeping it current. A processing register that was created a year ago and hasn't been updated since often no longer aligns with the tools a company is now using. A system that lets the register grow along with the software actually in use, and that tracks which processor agreements are still missing, saves effort at the moment an insurer suddenly asks for it.
Whether this is relevant for your company right now and which documents you specifically need is something you're best off discussing with the insurer itself or with an adviser; this article provides guidance, not legal advice about your specific policy.
Would you like to first see where your company stands roughly? The free quick-scan gives you an indication in a few questions, and in the knowledge base you'll find per topic the short answer with the source location included. If you then want to maintain the register and monitoring on an ongoing basis, you can read on what the system around it costs what it entails.