Business-focused cybersecurity content for boards, owners, CFOs, COOs, risk leaders and organizations that need strategic security leadership without hiring a full-time CISO. We explain cyber risk, governance, board accountability, supplier oversight, cyber insurance readiness, executive reporting and vCISO support.
Cyber Insurance in Business: Why It Matters and Where Its Role Ends
Cyber insurance matters because a cyberattack may involve not only technical recovery costs, but also downtime, data loss, legal support, customer communication, claims, forensic work, PR, restoration costs and lost revenue. A policy can help finance response and reduce the financial impact of an incident, but it does not prevent attacks and does not replace cybersecurity. A company should treat cyber insurance as part of risk management: alongside MFA, backup, EDR, updates, access control, training, incident response, BCP, testing and supplier management.
Prepared by: CCyber Editorial Team
Cyber insurance matters because a cyberattack can quickly become a financial, legal, operational and reputational problem. Ransomware, email takeover, data leakage, fake payment, supplier outage or an attack on an online store can generate unplanned costs: forensics, lawyers, customer communication, system restoration, lost revenue, PR support, claims handling and additional IT resources. A good policy can help finance some of these costs and provide access to experts after an incident. However, it does not replace MFA, backup, updates, EDR, training, incident response planning, BCP or good risk management. Cyber insurance is not a shield against attacks. It is a mechanism for transferring part of the financial impact when something goes wrong despite safeguards.
July 2026
Most companies now operate digitally. Email, payments, CRM, finance systems, files, cloud, invoices, production, customer service, online stores, logistics and employee data all depend on IT systems or digital providers. This means a cyber incident is no longer only a technical issue.
A cyberattack can stop sales, block access to data, create customer claims, trigger notification duties, disrupt production, delay payments and involve the board for days. This is why cyber insurance is increasingly treated as part of business risk management.
What will we do financially and operationally if an incident happens despite our safeguards?
Cyber insurance is a policy that may cover selected costs related to a cyber incident. The scope depends on the specific offer, terms, exclusions, limits, sublimits and the company’s answers in the insurance questionnaire.
Not every policy covers everything. That is why the company should not buy a policy based only on price. Scope, exclusions, sublimits, deductible, post-incident duties and claim conditions must be checked.
Cyber insurance is not a technical safeguard. It will not stop phishing, patch vulnerabilities, enable MFA, perform backup or train employees. The policy starts to matter only when an event covered by the policy happens and the company meets policy conditions.
The best approach is to treat cyber insurance as the third layer: after prevention and operational readiness.
These safeguards reduce incident likelihood. Examples include MFA, updates, EDR, limiting privileges, training, email protection and secure remote access.
This is the company’s ability to operate when an incident happens. Examples include backup, restore testing, incident response plan, tabletop, BCP, DRP, emergency contacts and crisis communication.
This is cyber insurance. It may help cover part of the cost, but it works best when the first two layers are implemented and documented.
After a cyberattack, the company often needs experts immediately: forensics, incident response, legal counsel, communication specialists, data recovery providers and IT support. Without insurance, these costs must be paid from the current budget.
A company loses access to email and file systems. It needs a forensic team, data recovery support, lawyers and customer communication. A policy may help cover part of such costs if they are within scope.
For many companies, the biggest cost is not technical repair, but business interruption. The store does not sell. Production stops. Consultants cannot serve customers. The invoicing system is down. Revenue falls, while fixed costs remain.
A data breach, loss of service availability or supplier incident may trigger duties toward customers, regulators, data protection authorities, partners and the insurer. The company often needs a lawyer who understands cyber incidents and notification duties.
If the company stores customer data, provides a digital service, processes payments or maintains a customer system, an incident may lead to claims. Cyber insurance may cover third-party liability, but the scope must be checked carefully.
Some policies provide access to a hotline, forensic experts, lawyers, PR and incident response teams. This can be especially valuable for SMEs without their own security team or standing contract with an incident response provider.
The insurance questionnaire can be uncomfortable, but useful. The broker or insurer will ask about MFA, backup, EDR, remote access, training, incidents, suppliers and procedures. This helps the board see the company’s gaps.
More customers, especially larger organizations and regulated entities, require suppliers to confirm cyber insurance. This is especially common for IT firms, SaaS companies, software houses, MSPs, digital service providers and organizations processing customer data.
Cybersecurity is often described technically. Cyber insurance forces a discussion about financial scenarios: cost of one day of downtime, cost of a data breach, required limits, acceptable deductible and what the company can self-fund.
The policy discussion should connect with BCP and DRP. The policy may cover selected costs, but the company still needs to know which systems to restore first, who makes decisions and how it operates without email, CRM or finance system.
A good policy and a prepared incident response plan indicate whom to contact, when to notify the insurer, which providers may be used and which information must be collected. This reduces chaos in the first hours of a crisis.
Each of these must be checked in the policy terms, offer, special conditions and exclusions. The word “cyber” in the policy name does not automatically mean full protection against every scenario.
The biggest disappointments happen when the company assumes the policy covers everything. It does not. Exclusions are as important as coverage.
The more customer data the company processes, the greater the risk of notification costs, claims, loss of trust and legal handling.
E-commerce, marketplaces, SaaS platforms and online services can lose revenue after only a few hours of unavailability.
An incident at an IT provider may affect customers. Contractual requirements for cyber insurance are common.
MSPs, MSSPs, integrators, administrators and maintenance providers face liability risk for damage at the customer side.
These sectors process sensitive, financial or confidential data, increasing potential incident impact.
For smaller companies, access to experts after an incident may be one of the biggest practical values of the policy.
The decision should come from risk assessment, not marketing pressure. The board should see scenarios, costs, gaps and risk transfer scope.
The company should know what matters most: email, finance system, CRM, ERP, online store, production, customer data, backup, identity system and suppliers.
MFA should cover email, administrators, VPN, cloud, finance system, backup and suppliers with remote access.
Backup without restore testing is weak resilience evidence. The test report is one of the most important documents for the broker and board.
Too many administrators, shared accounts and no access review increase risk and make insurer discussions harder.
Public RDP, old VPNs, supplier accounts without MFA and uncontrolled remote desktop tools are major risk signals.
The company should know who acts in the first hour, who contacts the broker, who contacts legal counsel, who decides on communication and where emergency contacts are stored.
Business email compromise and fake payments require second-channel verification, two-person approval and finance training.
Cloud, hosting, IT, backup, SOC, SaaS and critical system providers can be the source of an incident or outage.
The best questionnaire answer is supported by evidence: MFA report, backup report, restore test, EDR, access review, training, IR plan, BCP, supplier register and board decisions.
Check which types of incidents are covered. Do not assume that ransomware, BEC, social engineering fraud, supplier incident and business interruption are always standard.
The policy may have an overall limit, but specific scenarios may have lower sublimits. This is especially important for BEC, cyber extortion, PR, forensics and supplier incidents.
A lower policy price may come with a higher deductible. The board should know what cost the company will pay itself.
Check which safeguards the company must have and maintain. Questionnaire declarations should match reality.
The policy may require a specific claim notification process, hotline contact, use of approved providers or consent before incurring certain costs.
This is the most important part. An exclusion may mean that the company’s most realistic scenario is not covered.
Cyber insurance should be visible in the risk governance model. It should not be only a document in the finance department.
The policy will not stop an attack. The insurer may expect the company to maintain baseline safeguards.
The company looks at price and limit, but does not check whether the policy covers BEC, suppliers, ransomware, PR and business interruption.
“We have MFA” is too weak if the company does not know whether MFA covers administrators, VPN, suppliers and backup.
The questionnaire requires knowledge from IT, finance, legal, DPO, the board, HR, suppliers and process owners.
Backup without restore testing does not prove that the company can recover from ransomware.
During a crisis, the company should not be searching for broker, insurer, lawyer and incident response provider contact details.
A change in cloud, supplier, system, data scope or work model may affect risk and policy conditions.
The cheapest policy may have narrower scope, low sublimits, major exclusions or no coverage for key scenarios.
A SaaS company has 60 employees and serves B2B customers. It uses Microsoft 365, cloud infrastructure, code repository, ticketing system, CRM and an external DevOps provider. One larger customer requires cyber insurance confirmation before renewing the contract.
The board initially treats the policy as a formality. The broker sends a questionnaire. It turns out that MFA covers only some accounts, backup has not been tested for a year, administrator accounts have not been reviewed and the incident response plan is outdated. The policy is available, but the terms are weaker than expected.
Over 60 days, the company fixes the key issues: enables MFA for administrators and suppliers, performs restore testing, organizes DevOps accounts, updates the incident response plan, trains the team and prepares an evidence pack. After a renewed discussion with the broker, the company has a stronger negotiating position and, more importantly, a better understanding of its own risk.
ccyber.io helps companies treat cyber insurance as part of risk management, not only as a policy purchase. We help prepare the organization for broker discussions, assess gaps, collect evidence and check whether policy scope matches real incident scenarios.
We can support your organization with:
The best first step is a Cyber Insurance Risk Workshop. In a short workshop, the company can determine whether it needs cyber insurance, which scenarios the policy should cover, where security gaps exist and which evidence should be prepared before speaking with the broker.
Not every company needs the same policy, but every company dependent on data, systems, email, payments, cloud or digital customers should at least analyze cyber financial scenarios and incident cost.
No. The policy does not prevent attacks. The company still needs baseline safeguards such as MFA, backup, EDR, updates, training and incident response.
The most important things are understanding risks, preparing security evidence, checking exclusions and making sure questionnaire answers match reality.
It may, but this depends on policy conditions. Limits, sublimits, conditions, exclusions and required safeguards must be checked.
Not always. Business email compromise and social engineering fraud often require additional coverage or have sublimits.
A dispute may arise if the company provided false information, did not meet policy conditions, breached post-incident duties or the loss falls under an exclusion.
The business owner should ideally be CFO, risk or the board, with active participation from IT, security, legal, DPO, compliance and process owners.
Start with scenarios: ransomware, email takeover, data leakage, fake payment, supplier outage and critical system downtime. Then check whether the policy and safeguards match those scenarios.
Cyber insurance matters because it helps the company prepare financially and operationally for the consequences of a cyber incident. It may support response, recovery, legal handling, communication, claims and business interruption.
It is not magic protection against an attack. It creates the most value as part of a risk management model: alongside baseline safeguards, response plans, business continuity, tests and evidence.
The best rule is: do not buy cyber insurance to avoid doing cybersecurity. Buy it to consciously transfer part of the risk that cannot be fully eliminated, and to have support when an incident happens despite safeguards.
Third-Party Risk Management: How to Assess Suppliers Under NIS2 and DORA
Third-party risk management under NIS2 and DORA is not about sending one annual questionnaire to a supplier. A company must know which suppliers are critical, which data and systems they handle, whether they have privileged access, whether they support critical or important functions, where they process data, which subcontractors they use, how they report incidents, how they test continuity and whether the company can safely exit the relationship. The best model is a supplier lifecycle: classification, due diligence, risk assessment, contractual requirements, onboarding, monitoring, testing, incident response, review and exit plan.
Prepared by: CCyber Editorial Team
Third-party risk management under NIS2 and DORA should start with a supplier map, not a questionnaire. The company must know which suppliers support critical services, have access to data, have administrator accounts, maintain systems, provide cloud, software, monitoring, backup, OT, SOC, MDR or business processes. NIS2 requires supply chain security and supplier relationships to be included in cyber risk management. DORA goes further for the financial sector and requires formal ICT third-party risk management, register of information, assessment of services supporting critical or important functions, due diligence, monitoring, contractual clauses, subcontractor controls, audit rights and exit plans. Good supplier assessment is a process across the whole relationship lifecycle, not a one-time form.
July 2026
Third-party risk is the risk a company takes through relationships with suppliers, service providers, partners, subcontractors, integrators, group entities or external tools. In cybersecurity, it means that a supplier incident can become the company’s incident.
NIS2 covers a broad set of sectors and essential or important entities. In the supplier context, the key point is that supply chain security and supplier relationships must be included in cyber risk management measures. This means the organization must know which suppliers matter, what risks they create and which safeguards are required.
DORA is a financial sector regulation focused on ICT risk. It is more detailed in supplier management. It requires a register of information on ICT contracts, ICT third-party risk strategy, assessment of critical or important functions, due diligence, monitoring, audit rights, contractual requirements, subcontractor controls, concentration risk assessment and exit strategies.
NIS2 says: manage supplier risk as part of cybersecurity. DORA says: show exactly which ICT suppliers support critical or important functions, which contracts apply, where data is located, who the subcontractors are, what audit rights you have, how you monitor risk and how you can exit without losing resilience.
The best starting point is a simple supplier map. Without it, the company does not know who to assess, how deeply and against which requirements.
Not every supplier can be assessed the same way. A coffee supplier, ERP provider and backup provider do not create the same risk. Classification allows the company to choose the right level of due diligence.
The supplier supports a critical service, critical or important function, production, payments, customer data, security, backup, cloud or a system whose failure seriously affects the company.
The supplier does not stop the whole company, but has access to sensitive data, privileged accounts, customer systems, production environment or important integrations.
The supplier processes limited data or supports a less critical process, but still requires basic assessment and contractual requirements.
The supplier has no access to data, systems or critical processes. Light assessment, basic contractual language and periodic review are enough.
Before procurement or contract signature, the company should assess whether the supplier can be allowed for the intended type of data or service.
At this stage, the company collects information about safeguards, certifications, processes, subcontractors, continuity, incidents and supplier compliance.
This is not only a list of answers. Impact, likelihood, gaps, exceptions, residual risk and business decision must be assessed.
Security requirements should be included in the contract, annex, SLA, DPA, service terms or security schedule. A questionnaire without contract terms has limited value.
The supplier should receive only the access it needs. The owner, contacts, incident path and operating requirements must be defined.
Supplier risk changes. Incidents, audit results, SLA, subcontractor changes, vulnerabilities, data location and service changes must be monitored.
Critical suppliers require regular review. Frequency should depend on risk.
The company must know how it will leave the supplier, recover data, switch the process, remove access and maintain business continuity.
First determine whether the supplier affects a service that may be subject to NIS2 requirements. The real impact matters, not only the supplier’s formal label.
NIS2 focuses in part on relationships with direct suppliers. The company should understand their vulnerabilities, quality of cybersecurity practices and secure development approach.
The supplier should meet requirements appropriate to risk. Requirements will differ for a cleaning company, SOC provider and software house maintaining a customer application.
If an incident at the supplier may affect your service, customer or regulatory reporting timeline, the contract must define timing, channel and notification content.
A supplier whose failure can stop your company should show continuity plans, recovery tests and crisis communication process.
For NIS2 audit purposes, the company should keep evidence: supplier register, risk assessments, contractual requirements, reviews and remediation plan.
DORA concerns ICT services provided by third parties. Identify which contracts concern ICT services, which are outside the scope and which support critical or important functions.
The register of information is a key evidence item for ICT supplier management under DORA. It should include contracts, services, functions, suppliers, subcontractors, locations, identifiers, links and service assessment.
DORA places the strongest focus on services supporting critical or important functions. These require the most detailed assessment, contracts, monitoring, testing, audit rights and exit plans.
Before signing an ICT supplier contract, the company should assess risks, supplier capability, security, resources, subcontractors, data location, continuity and concentration risk.
Contracts should describe the service, SLA, data location, security, incidents, cooperation with authorities, audits, subcontracting, business continuity, testing and exit.
If the ICT supplier uses subcontractors for services supporting critical or important functions, the company must understand the subcontracting chain, location risk, concentration, audit rights and ability to object to material changes.
DORA does not end at due diligence. The supplier must be monitored, and risks, SLA, incidents, changes, subcontractors and tests should be reviewed regularly.
A questionnaire is only the start. Answers must be evaluated, documented and linked to a risk decision.
The same form for a critical supplier and low-risk supplier leads to fatigue, weak answers and no real decisions.
The company does not know how many suppliers it has, which contracts are ICT and who supports critical processes.
The best time for due diligence is before the contract. After signing, negotiating requirements becomes harder.
The supplier may be secure, but risk may come from its subcontractor, data location or downstream service chain.
The company knows how to buy the service, but not how to recover data, switch the process and remove access after the relationship ends.
Without audit rights or alternative assurance, the company must rely only on supplier declarations.
The supplier may have an incident, but the customer may learn about it too late to meet its own regulatory duties.
IT or procurement collects questionnaires, but nobody in the business owns supplier risk.
A financial company uses 180 suppliers, including 45 ICT suppliers. Initially, it keeps one procurement spreadsheet. There is no clear distinction between services supporting critical or important functions. Some supplier contracts lack audit, subcontractor, incident and exit plan clauses.
After analysis, the company creates a DORA register of information, classifies suppliers by criticality, identifies 12 ICT services supporting critical functions, assesses subcontractors and prepares security annexes. In parallel, it implements a process for assessing new suppliers before contract signature.
After 90 days, the board sees the real dependency map for the first time: which suppliers are critical, where data is located, where audit rights are missing, where concentration risk exists and which exit plans must be prepared first.
ccyber.io helps companies build practical third-party risk management programmes for NIS2, DORA, ISO 27001, cyber insurance and customer requirements. We combine cybersecurity, regulatory, procurement, legal, data and business continuity perspectives.
We can support your organization with:
The best first step is a TPRM and Supplier Risk Workshop. In a short workshop, the company can identify the most important suppliers, NIS2 or DORA requirements, contractual gaps and actions needed before audit or inspection.
Yes. NIS2 includes supply chain security and supplier relationships as part of cyber risk management measures. Control scope should depend on supplier risk and importance.
No. DORA applies to ICT services provided by third parties. Cloud is an important example, but SaaS, hosting, business systems, SOC, backup, IT outsourcing and other ICT services may also be in scope.
It is a function whose disruption could significantly affect business continuity, customers, regulatory duties or operational stability of a financial entity.
No. A questionnaire must lead to risk assessment, decision, contractual requirements, remediation actions and monitoring. A supplier answer without evidence is weak.
Supplier register, criticality classification, risk assessment, contract with security clauses, test reports, continuity plan, incident procedure, subcontractor list and exit plan.
Alternative assurance may be considered, such as certifications, independent reports, SOC 2, ISO 27001, security test reports, security documentation or independent third-party audit. For critical suppliers, refusal must be assessed as risk.
Critical suppliers should be reviewed at least annually and after every material change. Medium and low-risk suppliers can be reviewed less often according to classification.
Start with a supplier register, criticality classification, ICT supplier identification, contract review and assessment of the top 10 suppliers.
Third-party risk management under NIS2 and DORA requires visibility, classification, due diligence, contracts, monitoring and evidence. Supplier risk cannot be managed if the company does not know who has access to data, who supports critical services and who uses downstream subcontractors.
NIS2 requires suppliers to be included in cyber risk management. DORA requires a more detailed system for ICT suppliers in the financial sector: register of information, assessment of critical or important functions, subcontractor control, audit rights, monitoring and exit plans.
The best rule is: do not ask only whether the supplier has a certificate. Ask how supplier failure would affect your company, which data it processes, who has access, who its subcontractors are, how it will report an incident and whether you can safely exit the relationship.
How to Prepare Your Company for Questions from a Cyber Insurance Broker?
A cyber insurance broker will ask not only about the policy, but primarily about the actual cybersecurity posture of the company. Before the conversation, it is worth preparing answers and evidence on MFA, backup, restore testing, EDR, updates, administrator accounts, remote access, phishing, payment procedures, incident response, BCP, suppliers, incident history, regulations and expected coverage. The key point is not to answer “yes” based on assumptions. Every declaration should have scope, owner and evidence.
Prepared by: CCyber Editorial Team
A company should prepare for a conversation with a cyber insurance broker as if it were preparing for a mini cybersecurity audit. The broker will want to understand the company’s risks, critical data and systems, whether basic safeguards work, whether the company can recover data after ransomware and whether the answers in the insurance questionnaire reflect reality. The key areas are MFA, backup and restore testing, endpoint protection, updates, administrator accounts, remote access, email protection, training, payment procedure, suppliers, incident response, business continuity, incident history and regulatory compliance. A well-prepared company does not guess answers. It shows evidence.
July 2026
The broker helps match the policy to the company’s risk. To do that, the broker must understand what the company does, what data it processes, which systems it depends on, its revenue, customers, previous incidents and whether basic safeguards are in place.
In practice, the broker may act as a translator between the company and the insurer. The company speaks the language of business and IT. The insurer speaks the language of risk, limits, exclusions, questionnaires and coverage requirements. A good broker helps prepare answers, but should not guess the security state on behalf of the company.
The biggest cyber insurance problem is not the lack of perfect safeguards. The problem is declaring something the company cannot prove. If the company says it has MFA, but MFA works only for some users, the answer is incomplete. If the company says it has backup, but has never performed a restore test, that answer may also be misleading.
Weak answer: “We have MFA”.
Good answer: “MFA is enabled for Microsoft 365, VPN, administrator accounts and the finance system. It does not cover two technical accounts listed in the exception register. The latest MFA report is from June 2026.”
The broker will need a basic picture of the company. This is not a formality because industry, revenue, employee count and data type affect risk assessment.
The insurer wants to know what may be lost, encrypted, stolen or stopped.
The broker will likely ask about previous incidents, claims, ransomware, data breaches, account takeovers, fake payments and near misses. It is worth preparing an honest description and remediation actions.
This is one of the most common questions. The broker may ask whether MFA is enabled on email, VPN, administrator accounts, cloud, finance systems, backup and supplier access.
Evidence: MFA report, exception list and risk acceptance decisions.
The broker may ask whether the company performs backups, but the more important question is whether the company can restore data and systems. Backup without restore testing is weak resilience evidence.
Evidence: backup report, restore test report and remediation list.
Ransomware is one of the key insurance scenarios. The broker may ask how the company detects, isolates, restores and communicates a ransomware incident.
Evidence: ransomware playbook and tabletop exercise report.
The broker may ask whether devices are protected, who sees alerts and whether protection covers all laptops, servers and workstations.
Evidence: EDR or antivirus coverage report, alert report and exception list.
Insurers care about vulnerabilities because many incidents start from unpatched systems, VPNs, servers, network devices or web applications.
Evidence: vulnerability report, update report and exception register.
Administrator accounts are one of the largest risk sources. The broker may ask how many administrators exist, whether they have MFA, whether named accounts are used and whether access is reviewed.
Evidence: administrator account report and access review report.
Remote access, VPN, RDP and technical support tools are common broker questionnaire topics. Supplier access is especially important.
Evidence: remote access description, MFA report, supplier access list and administrative logs.
Email is one of the main attack vectors. The broker may ask about anti-phishing protection, malware filtering, mail forwarding rules, SPF, DKIM, DMARC and training.
Evidence: email configuration report, phishing report and SPF, DKIM and DMARC status.
The broker should know whether the company has business email compromise and fake payment risk. Not every policy covers that scenario, so it must be discussed explicitly.
Evidence: payment procedure, bank account change register and second-channel confirmations.
The broker may ask what the company will do in the first hour after an incident. The response plan does not need 100 pages, but it must be current and known by decision-makers.
Evidence: incident response plan, emergency contact list and exercise report.
The policy may cover business interruption, but the broker needs to understand how much downtime costs and whether the company can reduce its duration.
Evidence: BCP, DRP, restore test and downtime cost analysis.
The broker may ask what data the company processes and whether it is protected. The more personal, financial, medical, customer or trade secret data exists, the more important access controls and encryption become.
Evidence: data classification, encryption report and data access report.
The broker may ask about phishing, password, MFA, ransomware, data protection and payment training. Role-based training is useful for finance, HR and the board.
Evidence: participant list, materials, test results and training plan.
The broker may ask about cloud, hosting, IT, backup, SOC, MDR, accounting, CRM, ERP and other providers that can access data or systems.
Evidence: supplier register, risk assessments and security clauses in contracts.
The broker should not choose coverage blindly. The company should know which scenarios it wants to cover.
Evidence: risk scenario list and recommended coverage scope.
Knowing what the policy covers is not enough. The company must also know what it excludes. This is often the most important part of the broker conversation.
Evidence: policy terms analysis note and question list for the broker.
Many policies have claim reporting procedures and approved provider rules. The company should know who calls, when and which number to use.
Evidence: insurance contact card inside the incident response plan.
The insurance questionnaire should not be completed from memory by one person. Each area should have an owner confirming the answer.
Evidence: responsibility matrix for the questionnaire.
Not every gap needs to block a policy. It matters that the gap is known, described, prioritized and has an owner and deadline.
Evidence: remediation plan for policy purchase or renewal.
Cyber insurance is a board decision. The board should understand risks, limits, exclusions, required safeguards and actions needed after purchasing the policy.
Evidence: board report and budget decisions.
If MFA works only for email, but not for VPN and administrators, the answer should state the scope. “Partly” with a remediation plan is safer than unsupported “yes”.
The company may have EDR, but nobody responds to alerts. It may have backup, but nobody tests it. It may have an incident plan, but nobody knows it.
Exceptions should be described and accepted. Hidden exceptions may become a problem after an incident.
The IT provider may know configuration, but not all business processes, incident history, payments, data, contracts and governance risks.
The broker can help with questions and the insurance market, but the company should confirm its own security state or use an independent review.
The cheapest policy may have exclusions, sublimits and conditions that do not match the company’s real risk.
One person completes the questionnaire, even though answers require knowledge from IT, finance, legal, the board and suppliers.
The company declares MFA, backup, EDR and training, but has no reports or tests.
An incident at an IT, cloud or backup provider may stop the company, and the policy may have specific supplier conditions.
Fake payments and social engineering fraud are not always covered by a standard cyber policy. Ask explicitly.
Backup is listed as working in the questionnaire, but the company does not know whether it can restore data after ransomware.
After an incident, the company starts searching for broker, insurer, lawyer and response provider contact details.
The company changes cloud, supplier, work model or system scope, but does not update information provided to the broker.
An e-commerce company has 55 employees. It uses a shop platform, payment system, warehouse system, Microsoft 365, CRM, marketing tools and an external IT provider. The board wants cyber insurance because customer requirements are increasing and phishing attempts have appeared.
The broker sends a questionnaire. The company initially answers “yes” to most questions because it has an IT provider and backup. After an internal review, it turns out MFA works only in Microsoft 365, but not in the shop admin panel and IT provider accounts. Shop backup exists, but the restore test was not performed for more than a year. There is no formal supplier bank account change procedure. EDR covers laptops, but not the application server. The incident response plan is still a draft.
The company does not send the questionnaire immediately. Within 60 days, it improves MFA, performs a restore test, organizes administrator accounts, implements a payment procedure, trains finance and prepares an evidence pack. The broker conversation changes from price negotiation into a discussion about real risk, policy scope and conditions the company can actually meet.
ccyber.io helps companies prepare for a cyber insurance broker conversation in a practical, risk-based and evidence-driven way. We check whether questionnaire answers match reality, where gaps exist and which actions are worth taking before purchasing or renewing the policy.
We can support your organization with:
The best first step is a Cyber Insurance Broker Readiness Workshop. In a short workshop, the company can check which answers are reliable, where evidence is missing, which gaps may affect the policy and which questions should be asked before choosing coverage.
The broker may ask about technical safeguards, but usually does not perform a full technical audit. The company should prepare evidence itself or perform an independent review before submitting the questionnaire.
Company profile, critical systems and data list, incident history, current safeguards, MFA report, backup information, supplier information, incident response information and expected policy scope.
No. It is better to describe scope, exceptions and remediation plan. A “yes” answer without clarification may be misleading.
MFA, backup and ransomware questions are often critical. EDR, remote access, administrator accounts, updates, suppliers and incident response are also very important.
Not always. Business email compromise, social engineering fraud and fake payments may require separate coverage or have sublimits and specific conditions.
It is strongly recommended. Backup without restore testing is weak evidence. Brokers and insurers may ask not only about backups, but also about data recovery capability.
IT, security, finance, legal, risk, HR, the board and key IT providers. One person rarely has the complete picture of controls and risks.
Start by comparing the broker’s questions with facts: what is implemented, what works partially, what is missing and what evidence supports each answer.
Preparing for a conversation with a cyber insurance broker should be a short, practical cyber resilience review. The broker will ask about risks, safeguards, evidence, suppliers, incidents and expected coverage.
The most important areas are MFA, backup with restore testing, EDR, updates, administrators, remote access, email, phishing, payments, incident response, business continuity, suppliers and incident history.
The best rule is: do not prepare for a policy by guessing answers. Prepare facts, evidence and a gap closure plan. Then the broker conversation becomes part of risk management, not just the purchase of another service.
Cyber Insurance: What Should Be Implemented Before the Insurer Starts Asking Questions
Cyber insurance does not replace cybersecurity. Before the insurer starts asking questions, a company should have the basics implemented and documented: MFA, backup with restore testing, email protection, updates, EDR or endpoint protection, administrator account control, access reviews, training, incident response procedure, business continuity plan, supplier register, payment procedure and an evidence pack. The key point is that answers in the insurance questionnaire must match reality, because declarations without evidence may become a problem during policy renewal or claim handling.
Prepared by: CCyber Editorial Team
Before speaking with an insurer, a company should have basic safeguards implemented and evidence that they work. The most important items are: MFA for email, administrator accounts, cloud and remote access, tested backups, endpoint protection, updates, vulnerability management, incident response procedure, business continuity plan, employee training, access review, supplier control, payment procedure and an organized evidence pack. Cyber insurance may help cover part of incident costs, but it does not prevent attacks and does not replace the need for reasonable safeguards. The biggest mistake is writing in the insurance questionnaire that a control is in place when it is not implemented in practice or there is no evidence for it.
July 2026
Cyber insurance is designed to help a company reduce the financial impact of a cyber incident. It may cover response costs, expert services, legal support, data recovery, crisis communication, downtime, third-party claims or other costs listed in the policy. The scope depends on the contract, exclusions, limits, deductibles and conditions met by the company.
Cyber insurance may be especially useful when the company does not have an internal response team, a large legal department or wants access to vetted providers after an incident. However, this does not mean the policy solves the security problem.
The insurer assesses risk. Just as property insurance may involve questions about alarms, fire protection and the condition of installations, cyber insurance involves questions about protection of systems, data and processes. The goal is to understand whether the company is exposed to high risk and whether it can limit the impact of an incident.
Technical questions are not a formality. Answers may affect:
This is why the insurance questionnaire should be completed jointly by the board, IT, security, legal, finance and risk owner. One person should not complete it based on assumptions.
The biggest cyber insurance risk is the gap between declaration and reality. A company may state that it has MFA, backup, EDR and an incident response plan, but after an incident it turns out MFA does not cover administrators, backup was not tested, EDR does not cover all devices and the incident plan was never exercised.
“We have MFA”.
“MFA is enabled for Microsoft 365, administrator accounts, VPN, finance system and password manager. Exceptions are described in the register. The latest MFA report is dated 15 June 2026.”
The questionnaire depends on the insurer, industry, company size, revenue, data and incident history. In practice, most questions concern recurring areas.
MFA is one of the first controls insurers ask about. Email, administrator accounts, VPN, cloud, banking, CRM, finance systems, backup and remote access are especially important.
Evidence: MFA report from identity system, exception list and risk acceptance decisions.
The insurer will want to know not only whether backup exists, but whether the company can recover data. Restore testing is more important than simply declaring that backups run.
Evidence: backup report, restore test report and remediation list.
Ransomware is one of the most important scenarios for insurers. The company should show that it reduces both the likelihood and impact of an incident.
Evidence: ransomware plan, exercise report, EDR report and restore test.
The insurer may ask whether the company protects endpoints, who monitors alerts and whether protection covers all laptops, servers and workstations.
Evidence: EDR or antivirus coverage report, exception list and alert report.
Update questions cover operating systems, applications, network devices, servers, VPN, firewall, cloud and internet-facing systems. The company should have a process, not only a declaration.
Evidence: vulnerability report, patch management report and exception list.
Administrator accounts are especially important for insurers because their compromise may lead to a broad incident.
Evidence: administrator account report and access review report.
Access review shows that the company controls who has access to systems and data. It is useful evidence for the questionnaire, audit and claim handling.
Evidence: access review report and list of removed permissions.
Remote access is a common attacker entry path. The insurer may ask about VPN, RDP, remote support tools and supplier access.
Evidence: remote access model description, MFA report, supplier access list and session logs.
Email is one of the most important risk points. The insurer may ask about MFA, anti-phishing protections, SPF, DKIM, DMARC and training.
Evidence: email configuration report, SPF/DKIM/DMARC status, training report and reporting register.
Not every policy covers losses from payment fraud. The company should have a procedure that reduces fake transfer and supplier bank account change risk.
Evidence: payment procedure, bank account change register and second-channel confirmations.
The insurer may ask whether the company has a response plan, who activates it and whether it was tested. The plan should be simple, current and known by decision-makers.
Evidence: incident response plan and tabletop exercise report.
Cyber insurance often concerns downtime costs, but the company must show that it reduces the length and impact of downtime.
Evidence: BCP, DRP, restore test report and action list after test.
The insurer may ask what the company protects, what data it processes, where systems are and which systems are critical. Without inventory, answers are guesses.
Evidence: asset, system and data register.
If the company processes personal data, customer data, financial information or trade secrets, the insurer may ask about encryption and access control.
Evidence: data classification policy, device encryption report and data access report.
The insurer may ask about training on phishing, MFA, ransomware, passwords and payment procedures. A presentation alone is not enough. Participation and effectiveness evidence are needed.
Evidence: participant list, materials, test results and phishing reporting report.
A supplier attack or outage may cause a loss. The insurer may ask about IT, cloud, hosting, backup, finance system and managed service providers.
Evidence: supplier register, risk assessments and security clauses in contracts.
The insurer may ask about previous incidents, notifications, losses, ransomware, data breaches, payment fraud and remediation actions.
Evidence: incident register and post-incident action report.
The company should know whether it is subject to NIS2, DORA, KSC, GDPR, customer requirements or industry standards. The insurer may ask about legal duties and potential penalties.
Evidence: applicability assessment, requirements register and notification procedures.
Cyber insurance is a board decision. The board should know the risks, policy scope, exclusions, limits, insurer requirements and gaps that may affect coverage.
Evidence: board report and budget decisions.
In insurance, time and consistency matter. The company should have one place for evidence for the broker, insurer, auditor and claims team.
Evidence: evidence matrix with owners, dates and freshness status.
In cyber insurance, price and limit are not enough. You must understand what is covered, what is excluded, which payment conditions apply and what duties the company has before and after an incident.
IT, security, finance, legal, risk, HR and the board should participate. One person usually does not know the full picture.
Do not answer “yes” if the control is only partially implemented. It is better to describe scope, exceptions and remediation plan.
Every “yes” answer should have evidence. Every “partly” answer should have an improvement plan.
Exceptions do not necessarily prevent insurance, but they must be visible, justified and managed.
A change of cloud provider, supplier, backup, incident or major change of business scope may require discussion with the broker or insurer.
The insurance questionnaire is a risk document. Answers should be verified and reflect reality.
MFA may work for users, but not for administrators, VPN, suppliers or emergency accounts. This is a major difference.
The insurer may ask about backup, but after an incident what matters is whether the company can restore data and systems.
After an attack, the company starts looking for the insurer, lawyer and response provider contact details. This extends chaos.
Not every cyber policy covers fake payments. This must be checked separately.
A supplier may have administrator, backup or customer data access. The insurer may ask whether the company manages that risk.
The board buys the policy but does not know the exclusions, gaps, requirements and actions needed for renewal.
The company changes cloud, supplier, backup or operating model, but does not update information provided to the broker or insurer.
A services company has 80 employees and wants to buy cyber insurance. The questionnaire includes questions about MFA, backup, EDR, ransomware, training, incidents, suppliers and response planning. The board initially assumes most answers are “yes” because the company has an external IT provider.
A short review shows that MFA works in Microsoft 365, but does not cover the supplier’s administrator accounts. Backup exists, but has not been tested for more than a year. EDR does not cover all laptops. Access review has not been performed. There is no payment procedure, and phishing training happened only once.
The company does not enter uncertain answers into the questionnaire. Within 60 days, it improves MFA, performs a restore test, prepares access review, completes EDR coverage, creates a payment procedure and trains employees. It attaches evidence and a remediation plan to the questionnaire. The result: the conversation with broker and insurer is based on facts, not assumptions.
ccyber.io helps companies prepare for cyber insurance in a practical, risk-based and evidence-driven way. We do not start with the questionnaire alone. We start by checking whether the company has the safeguards it declares and whether it can prove them.
We can support your organization with:
The best first step is a Cyber Insurance Readiness Workshop. In a short workshop, the company can check which questionnaire answers are reliable, where evidence is missing, which gaps may affect coverage and what should be implemented before speaking with the insurer.
No. Cyber insurance can help after an incident, but it does not prevent attacks. The company still needs basic safeguards, procedures, tests and evidence.
MFA, backup, restore testing, EDR, updates, administrator accounts, remote access, training, incident response, incident history, suppliers and data protection.
In practice, MFA is one of the most important expectations. It should cover email, administrator accounts, cloud, remote access and critical systems.
No. The company needs restore testing, backup account protection, backups separated from production and a critical system recovery plan.
Do not pretend they are implemented. State the actual situation, exceptions, remediation plan and deadlines. This is better than unsupported declarations.
Not always. Business email compromise, social engineering fraud and fake payments may need separate coverage or special conditions. This must be checked in the policy.
MFA report, backup report, restore test, EDR report, access review, administrator account list, incident response plan, training records, supplier register and remediation report.
Start by comparing the insurance questionnaire with the actual security state. Mark answers as confirmed, partial or missing evidence, then close the most important gaps.
Cyber insurance is an important element of risk management, but it works best when the company has real safeguards and evidence. A policy does not replace MFA, backup, EDR, training, procedures, access control and incident response planning.
Before the insurer starts asking questions, the company should prepare the minimum: MFA, tested backup, endpoint protection, updates, administrator control, access review, email protection, payment procedure, incident response, BCP, training, supplier control and evidence repository.
The best rule is: do not buy a policy based on wishful answers. First check the actual state, collect evidence and show the insurer that the company truly manages cyber risk.
Will Your Company Survive a Ransomware Attack? Disaster Scenarios and Survival Strategies
A company will survive a ransomware attack if it knows before the incident which processes are critical, how long it can operate without systems, where backups are, who makes decisions, how to contain the attack, how to restore data and how to communicate with customers. Survival does not mean no loss. It means controlling chaos: fast detection, isolation, board decisions, safe recovery, business continuity, evidence and a plan to return to normal operations.
Prepared by: CCyber Editorial Team
A company survives a ransomware attack when it does not start thinking about survival only after systems are encrypted. The key elements are: critical service list, tested backups, recovery plan, MFA, administrator account reduction, monitoring, device protection, updates, prepared response plan, emergency contacts, board decisions and exercised scenarios. The worst case is when the company loses email, files, finance system, CRM, backups and administrator access at the same time, while the board is still deciding who should call the IT provider, bank, customer, lawyer and insurer. Survival means limiting damage, operating in emergency mode and returning to work safely.
July 2026
Surviving a ransomware attack does not mean the company suffers no losses. It means the company keeps control of the situation, limits spread, preserves evidence, maintains communication, restores the most important services and returns to operations safely.
A company survives if it can answer:
Ransomware is a test of technology and a test of company management under pressure.
Ransomware combines several problems at once. The company may lose access to systems, data, email, files, backups, devices and administrative tools. Add time pressure, extortion, possible data leak, customer questions, legal duties and reputation risk.
The board should therefore treat ransomware as a business continuity scenario, not only an IT failure.
There are no tested backups, no incident plan, no critical systems list, no emergency contacts, broad administrator access and no board ransomware exercise.
Backup, MFA and an IT provider exist, but nobody knows when data was last restored, who has administrator accounts, whether backups are attack-resistant and who makes decisions at night or during a weekend.
Documents exist, but they were not tested. During an attack, the company discovers that contact lists are outdated, backup misses an important system and customer communication has no owner.
The company knows critical systems, has separated backups, restore tests, procedures, owners, contacts, communication plan, scenario exercises and board reports.
The most resilient companies have not only an IT plan, but also a business plan: how to serve customers, take orders, produce, ship, invoice and communicate when digital systems do not work.
The attacker takes over a user or administrator account, gains access to email and cloud files, then encrypts or deletes documents. Employees lose access to offers, contracts, invoices, project documents and customer correspondence.
The company loses access to invoicing, accounting, ERP or file servers. It cannot issue invoices, process payments, check receivables or run core financial processes.
Ransomware blocks production systems, warehouse systems, labeling, planning, scanners, operator stations or connections between IT and OT. The company cannot produce, ship goods or control quality.
The company assumes it has backups. After the attack, it turns out backups were connected to the same network, the ransomware administrator had access, backups are encrypted or the last clean recovery point is weeks old.
The attacker not only encrypts data, but copies it first. The company receives a threat to publish customer data, contracts, financial documents, correspondence or employee data.
The attacker takes over an IT provider account, remote management tool or multi-customer support system. The company is attacked through a trusted administration channel.
The attacker takes over administrator accounts, changes access rules, adds their own accounts, resets passwords, disables MFA or destroys logs. The company does not know which accounts can be trusted.
The key board question is: what must work for the company to survive one week? This is not about full comfort. It is about minimum ability to serve customers, revenue, production, payments and communication.
Evidence to prepare: minimum operating level card with system recovery priority.
The company often knows which systems it has, but not what they depend on. Ransomware reveals dependencies at the worst moment.
Evidence to prepare: critical service dependency map.
Ransomware often starts with account takeover, remote access, vulnerabilities or administrator privileges. Identity protection is one of the most important survival strategies.
Evidence to prepare: MFA report, administrator account list and access review report.
Backup is a survival strategy only when it is available, clean and tested. The statement “backup runs” is not enough.
Evidence to prepare: backup report and restore test report.
Ransomware is much more dangerous if it can move from one laptop to servers, backups, file shares and production systems.
Evidence to prepare: segmentation map, access policies and endpoint protection report.
After an attack, communication may be harder than technology. Email may be down, phones may be overloaded, customers may ask about data and the team may receive conflicting information.
Evidence to prepare: crisis communication plan and emergency contact list stored outside the main email system.
A plan that has not been exercised is only a hypothesis. A ransomware exercise should include the board, IT, legal, communications, finance, operations and the IT provider.
Evidence to prepare: ransomware exercise report with gaps and remediation actions.
The ransom decision is a crisis, legal, financial, reputation and operational decision. It should not be made under pressure without consultation. Paying ransom does not guarantee data recovery, does not remove the attacker from the environment and may increase the risk of being targeted again.
The best strategy is to prepare the company so ransom pressure is as low as possible. This means backups, tests, plan, isolation and ability to operate in emergency mode.
Ransomware stops sales, production, finance, customer service and reputation. It is a board issue.
Backup without restore is not a strategy. Only a test shows whether the company can return to work.
Not everything can be restored immediately. The company should know how to operate for several days without some systems.
If email is encrypted or compromised, the crisis team must have another contact channel.
Not everything can be restored at once. The board should define which services return first.
The IT, cloud, backup or production system supplier must be part of the plan. Without them, the plan may fail.
During a real attack, people work under pressure. Exercises reduce chaos.
Restoring systems into a contaminated environment may cause re-encryption. First, understand scope and entry cause.
A manufacturing company has 180 employees. It uses ERP, warehouse system, email, cloud files, production planning systems and an external IT provider. The board assumes the company is prepared because “backup works”.
During a ransomware exercise, it turns out the backup covers ERP, but not several critical planning files. The warehouse system depends on a server nobody added to the critical list. The IT provider has broad administrator access, but the contract does not define incident response time. There is also no alternative communication channel if email stops working.
The company implements a 90-day plan. It tests recovery, updates the dependency map, reduces administrator access, defines minimum viable production operation, prepares crisis communication and exercises the first 24 hours of an attack. After three months, the company still has no guarantee ransomware will not hit it. But it has a much higher chance of surviving without weeks of chaos.
ccyber.io helps companies prepare for ransomware as a business continuity scenario, not only an IT incident. We combine the board, finance, IT, security, supplier, communication and audit evidence perspectives.
We can support your organization with:
The best first step is a Ransomware Survival Workshop. In a short workshop, the company can identify the most dangerous scenarios, calculate downtime cost, check whether backups really work, define which services must be restored first and decide what the board should approve before an incident.
No. Backup is necessary, but it must be separated, protected, tested and restorable into a clean environment. The company also needs a plan, people, communication and recovery priorities.
Isolation, backup protection, log preservation, crisis team activation, scope assessment, expert contact and board decisions about business priorities.
This decision should not be automatic. Consider law, sanctions, insurance, backup availability, data leak risk and the fact that payment does not guarantee recovery or attacker removal.
For critical systems, at least quarterly or after major changes. It is also worth testing full service recovery, not only a single file.
The board, IT, security, finance, operations, legal, communications, customer service, HR and key suppliers. Ransomware affects the whole company.
Start with basics: MFA, critical system list, tested backups, response provider, incident procedure, emergency contacts, employee training and a scenario exercise.
It means the ability to run the most important processes without full access to digital systems. It may include manual orders, alternative communication, emergency invoicing and priority support for key customers.
Start with three questions: which services must return first, were backups tested and who makes decisions in the first 24 hours of an attack?
A ransomware attack is a disaster scenario that checks whether the company truly understands its processes, data, systems, suppliers and board decisions. Tools are not enough. The company must know how to act when tools stop working.
A company survives if it prepares a minimum operating level, tested backups, recovery plan, identity protection, segmentation, monitoring, contact list, communication plan and scenario exercises.
The best rule is: do not ask only whether we have backup. Ask whether tomorrow morning we can restore the most important service into a clean environment and serve customers before everything returns to normal.
We write about regulations such as NIS2, DORA, CRA and ISO 27001, cybersecurity for SMEs and critical infrastructure, as well as cyber hygiene, emerging threats and building security awareness within organisations.
Every article delivers practical knowledge - no jargon, just concrete steps you can act on to effectively protect your data, people and business continuity.