Cyber insurance

It depends on the policy wording, not on the word “cyber” in its title. Policies differ in what they cover: incident response costs, restoring systems, business interruption, claims from third parties and, in some policies, the ransom itself. They also differ in exclusions, deductibles, waiting periods before interruption losses count, and the security conditions you declared when you applied, such as multi-factor authentication (MFA) and offline backups. Paying a ransom can also be restricted by law, for example when the attackers are on a sanctions list, so an insurer may refuse that part even when the rest is covered. Before an incident, read the cover with your broker, note the insurer’s hotline and the conditions for notifying them, and check that every declared control really exists. NetSenX does not decide cover, but its alerts and audit log, on every plan, help show what was monitored and when the first signs appeared.

Yes, they can help establish what happened and when, which both the claim and any breach notification depend on. Network records can show when unusual connections began, which devices were involved, whether a device kept calling an outside server at regular intervals and whether large volumes left the network, which helps separate an encryption-only attack from one where data was also taken. For that to count, records must cover the period in question, carry reliable timestamps and be protected from later changes, so set retention before you need it and keep copies outside the affected systems. NetSenX keeps alerts for your plan’s alert history and an audit log of actions and changes in the account. It records metadata, not the content of encrypted sessions, so it can show that data left and where it went, not what the files contained. Whether a record satisfies a particular insurer is for you and your broker to confirm.

It may, depending on what you declared and how the policy is worded. Application forms often ask not only whether a monitoring tool is installed but who reviews its alerts and how quickly, and an answer that did not match reality can reduce or void cover after an incident. Read the wording with your broker and describe your set-up as it actually is, including evenings, weekends and holidays. Then close the gap: name a person and a deputy for alerts, decide what counts as urgent, write down who calls whom, and test it. If no one in-house can do it, a managed service provider (MSP) can. A tool only helps if someone sees the alerts in time. NetSenX explains each alert in plain language, so a non-specialist can judge it, and from the Pro plan it can send alerts to Slack or a webhook so they reach the person on duty. The audit log records actions and changes in the account.

Most often because the facts after the incident do not match what was declared or required before it. Typical reasons are a security control stated in the application that was missing or only partly in place, such as MFA that covered e-mail but not remote access; a late notification to the insurer; an event that falls under an exclusion, such as war or an unpatched known vulnerability where the policy says so; losses outside the cover, such as a fine that cannot be insured; or response firms engaged without the insurer’s consent. Reduce the risk now: answer the questionnaire with the person who runs the systems, keep evidence that each control works, store the insurer’s notification procedure with the incident plan and tell your broker when your set-up changes. NetSenX cannot make a claim succeed. It helps with one part: a dated record of what the network showed and of actions and changes in your account.

Usually proof of three things: that a covered event happened, what it cost, and that the policy conditions were met. Expect to provide a timeline of the incident, the forensic or incident response report, invoices from response firms, restoration and overtime costs, figures for lost revenue during the interruption, any notifications to authorities or customers, and evidence that declared controls such as MFA, backups and monitoring were in place on the day. The policy and the claims handler decide what is enough, so ask them early and keep a list as you go. Preserve logs and affected systems before rebuilding, since a wiped server cannot show anything later. NetSenX contributes one piece: alerts with their timestamps and the affected devices, kept for your plan’s alert history (30 days on Free, longer on paid plans), and an audit log of actions and changes in the account. It does not provide endpoint forensics or a cost assessment.

Often it does, or at least it has a say. Many policies give access to a panel of response firms, lawyers and recovery specialists, and some cover the costs fully only when you use them or when the insurer approves another firm in advance. Find out before an incident: read the clause on incident response services, note the hotline number and who may call it, and ask whether your existing IT provider or managed service provider (MSP) can work alongside the panel firm. During an incident, call the insurer early, before you sign with anyone, and keep a written record of what was agreed. Also settle who owns the forensic report, since it may be shared with the insurer. NetSenX is not an incident response firm and is not on insurers’ panels. It can give the responders a starting point: which devices raised alerts, when, and which outside addresses they contacted.

A short list comes up in most application forms, although each insurer sets its own. Expect questions about multi-factor authentication (MFA) for e-mail, remote access and administrator accounts; backups kept offline or immutable and tested by a restore; timely patching, especially of systems reachable from the internet; endpoint detection and response (EDR) on laptops and servers; e-mail filtering and staff awareness training; restricted administrator rights; an incident response plan; and some form of monitoring with a named person who responds. Answer for the whole company, not the best-run part, and write down the evidence behind each “yes”. The form is part of the contract, so a wrong answer weighs more than a missing control you disclosed. NetSenX covers part of the monitoring question: on every plan, Free included, it detects beaconing to command-and-control servers, scanning, lateral movement and unusual outbound data volume on the segments it watches. It is not MFA, EDR or a backup, and does not replace them.

For most insurers today it is close to a condition, at least for e-mail, remote access and administrator accounts. Multi-factor authentication (MFA) adds a second step to a login, such as a code from an app or a hardware key, so a stolen password alone does not open the account. Questionnaires often ask where exactly MFA is enforced, and the detail matters: MFA on e-mail but not on the VPN, or on users but not on administrators, can turn a “yes” into a misstatement after an incident. List every way into your systems, enforce MFA on each, document the exceptions and tell your broker about them. A network sensor cannot check MFA, because login events live in your identity and VPN logs. NetSenX itself offers two-factor authentication on every plan, Free included, for access to the NetSenX account, and does not verify MFA in your other systems.

Many ask for it on all laptops and servers, and some ask what share of devices it covers, so check the exact question. Endpoint detection and response (EDR) is software on each computer that watches processes and files and can isolate a machine. It cannot run on many devices, such as printers, cameras, phones, building controls or industrial equipment, and it is missing wherever someone forgot to install it. Answer with real numbers: count your devices, count those with EDR and explain the rest and how they are protected, for example by network separation. Network detection is the usual complement, because it sees traffic from every device on a monitored segment, with or without an agent. NetSenX is that complement: it watches devices and connections, not processes inside a host, and it is not an EDR. Its network map shows the devices seen on each monitored segment, which helps you find the ones your EDR count is missing.

Mostly whether you could recover without paying and how quickly an attack would be noticed. Typical questions cover backups (are they offline or immutable, separate from your normal administrator accounts, and when were they last restored as a test), multi-factor authentication on remote access and e-mail, how fast critical patches are applied, whether remote desktop is exposed to the internet, whether administrator rights are limited, whether endpoints run EDR and whether someone monitors and responds to alerts. Some insurers also ask whether you have a ransomware playbook and who decides about a ransom demand. Ransomware is usually preceded by days of preparation inside the network: the attacker calls home, scans and moves between machines. That window is what network detection can shorten. NetSenX alerts on those steps on every plan and shows them in plain language, but it does not block traffic or restore data; backups and a tested recovery plan remain the answer to the first question.

Usually because the insurer’s view of your risk changed, not because of one missing tool. Common reasons are answers on the renewal form that show a control gap, such as MFA missing on remote access or no tested backup; a claim or incident in the past year; a change in your business, such as new countries, more data or acquisitions; exposed systems the insurer found by scanning your internet-facing addresses; and changes in the insurer’s own appetite for your sector. Ask your broker for the specific reasons in writing, fix what can be fixed, document it and ask for a reassessment or approach other insurers with the evidence. Do not tick boxes you cannot support. NetSenX can help with one item: it shows monitoring is in place and gives you records of alerts on the segments it watches. It does not scan your internet-facing systems the way insurers do, and it cannot guarantee cover or a price.

Some ask about it and a few make it a condition, but many only ask whether monitoring exists and who responds. Read the exact question: “24/7 monitoring” in an insurer’s form usually means that alerts are reviewed by a person at any hour, often through a security operations centre (SOC) or a managed provider, not merely that software runs all the time. Attacks are often timed for nights, weekends and holidays, when nobody is looking, which is why insurers care. If you cannot staff every hour, say so honestly and describe what you do: alerts sent to a phone, a rota, an MSP contract or a response time you can actually meet. NetSenX analyses traffic continuously on the segments it watches and raises alerts at any hour, and from the Pro plan it can send them to Slack or a webhook. A person still has to read and act on them; NetSenX does not provide staffed monitoring.

Usually not on its own, because insurers asking about 24/7 monitoring generally mean that a person can respond at any hour. Software that analyses traffic all the time and sends alerts is the first half; the second half is someone who receives the alert at 3 a.m., understands it and can act, for example by disconnecting a device or calling a response firm. Whether a set-up with alerts sent to an on-call phone counts depends on the insurer’s wording, so describe it exactly and ask your broker rather than ticking the box. Write down the response time you can really meet outside office hours and test it once with a deliberate alert. NetSenX provides the first half: continuous analysis on the segments it watches, with alerts in plain language, and from the Pro plan delivery to Slack or a webhook. The second half is your rota, your MSP or a security operations centre.

It can be part of the answer if the provider actually commits to watching and responding at all hours, and the contract says so. What makes a “yes” defensible is the service, not the software: a written response time, coverage for nights and weekends, a clear list of what the provider may do on its own, such as isolating a device, and regular reports to you. Ask the provider for the contract clauses, check them against the insurer’s question with your broker, and keep the contract with your policy documents. NetSenX supports this model: each customer has its own tenant, kept apart from other customers in the database; from the Pro plan alerts can be sent to the provider’s Slack or a webhook; and team management with roles is available from the Starter plan, so the provider can work in your account under its own logins. White-label reports are available on Enterprise by contract. The monitoring commitment itself is the provider’s, not NetSenX’s.

It should state who watches, when, how fast they respond and what they are allowed to do. A security operations centre (SOC) is a team that monitors security alerts and responds to them, either in-house or bought as a service. When insurers ask about one, they look for a few concrete points: hours of coverage, including nights and weekends; a response time for urgent alerts, written as a service level agreement (SLA); which systems and data sources are covered; the actions the provider may take without asking, such as isolating a device or disabling an account; how and when you are informed; and what happens during the provider’s own outages. Make sure the scope in the contract matches the scope you declare, since a SOC that only sees your firewall does not cover your laptops. NetSenX can be one of the data sources such a team uses, with alerts sent to Slack or a webhook from the Pro plan and SIEM export from the Business plan. NetSenX does not sell SOC services.

Usually whether you would notice suspicious activity inside your network and who would act on it, not whether a firewall is installed. A firewall filters traffic at the edge; network monitoring looks at the traffic that passes, including traffic between internal devices, and raises alerts on patterns such as a device calling an outside server at regular intervals, one machine probing many others, or unusual amounts of data leaving. The question often comes with follow-ups about coverage (which sites and segments), alert review and retention of records. Answer with the actual scope: list which networks are watched and which are not, such as a remote office or a guest Wi-Fi. NetSenX is network detection and response (NDR): on every plan it detects beaconing, scanning, lateral movement and unusual outbound volume on the segments it watches, through an agent on Linux or macOS or a sensor on a SPAN/TAP port. It does not see segments that are not connected to it.

Evidence that the monitoring exists, covers what you say, and is acted on. Insurers rarely ask for proof at application time but may ask at renewal, during an audit or after a claim, so collect it as you go. Useful items are a short description of what is monitored and how, with a network diagram marking the watched segments; the name of the person or provider who reviews alerts and the agreed response times; a few recent alerts with what was done about them; and a periodic summary report. Keep these with your policy documents and update them when the network changes. NetSenX can supply part of this: the network map with the devices seen on each monitored segment, on every plan; PDF reports from the Starter plan; and an audit log of actions and changes in the account, on every plan. It does not certify your monitoring, and whether an item is accepted is the insurer’s decision.

Yes, as one piece of evidence, but NetSenX does not certify anything and the insurer decides what it accepts. PDF compliance reports are available from the Starter plan. Together with the alert history, they help show that monitoring was running, what it found and when. Pair each report with the context an insurer needs: which segments were monitored and which were not, who reviewed the alerts, and what was done about the important ones. A report from a monitoring tool says nothing about your backups, MFA or patching, which are usually the insurer’s first questions. After an incident, export the relevant alerts promptly so they are kept beyond your plan’s alert history (30 days on Free, longer on paid plans, unlimited on Enterprise). From the Pro plan alerts can also be pulled through the API into your own archive.

Sometimes it helps, but no tool guarantees a lower price, and premiums depend far more on your sector, revenue, claims history and core controls. Insurers price the risk they see in your answers and, increasingly, in their own scans of your internet-facing systems. Monitoring with someone who responds can improve that picture, especially if your previous answer was “no”, yet MFA, tested backups and patching usually weigh more. If you add network detection, tell your broker at renewal, describe the scope and who reviews alerts, and attach evidence such as a report. Ask whether the insurer offers credits for specific controls and what proof it needs. Do not buy a tool only for the form: a monitoring tool that nobody watches can hurt you after a claim. NetSenX’s core detection is available on every plan, Free included, so you can describe real monitoring before you pay for anything; it cannot promise any premium change.

Partly at most, and it depends on national law and the policy. NIS2 makes the management bodies of entities in scope responsible for approving and overseeing cybersecurity risk-management measures, and national laws attach consequences: in Germany, section 38(2) of the BSIG makes managing directors liable under company law for breaching that duty. Directors and officers (D&O) insurance can cover the cost of defending a claim and damages a manager owes the company or third parties. Administrative fines are a different matter: whether they can be insured at all is decided by national law and public policy, and many policies exclude them. Read three things with your broker: whether the D&O policy excludes cyber events or refers them to the cyber policy, whether fines are covered where the law allows, and how the two policies interact. Insurance does not remove the duty itself, which is to approve and oversee the measures. NetSenX has no role in insurance cover.