Our blog features practical articles on cybersecurity and regulations, written in plain language that business owners and managers can understand. We cover specific topics such as NIS2, DORA and CRA requirements, ISO 27001 implementations, incident analysis, phishing, ransomware and best practices for SMEs.
Instead of technical jargon we offer actionable guidance that can be applied to your business straight away. We focus on content you can implement immediately: checklists, threat analyses, SME guides and regular updates on new regulations.
Why Cyber Insurance Does Not Replace Cybersecurity
Cyber insurance can help cover some post-incident costs, but it will not stop an attack, automatically restore business operations or replace MFA, backups, monitoring, incident response planning, training and risk management. Good cyber insurance should be part of a cyber risk strategy, not an excuse to avoid investing in security.
Prepared by: CCyber Editorial Team
Cyber insurance does not replace cybersecurity because a policy mainly works after an incident, while security controls work before, during and after an incident. Insurance may help cover some costs, such as technical investigation, legal support, crisis communication, system recovery or third-party liability. However, it does not guarantee that the company will avoid downtime, data loss, loss of customer trust, regulatory problems or claim denial if policy conditions were not met. The best approach is to treat cyber insurance as a partial risk transfer tool, not as a replacement for MFA, backup, training, monitoring, incident response planning and governance.
July 2026
Cyber insurance is a policy designed to help a company financially and operationally after a cyber incident. It may cover selected costs related to incident response, technical investigation, data recovery, legal support, crisis communication, third-party liability, data breach, business interruption or ransomware.
The scope depends on the specific policy. There is no single standard cyber insurance product that works the same way with every insurer. Before purchase, the company must check what is covered, what is excluded and which conditions must be met.
Cyber insurance can be very valuable, but only when it is part of a broader cyber risk management programme.
A policy may help reduce the cost of a sudden incident. This is especially important for SMEs, where one major incident can affect liquidity.
Possible covered costs:
Some policies provide access to incident response companies, lawyers, communication specialists or negotiators. For a company without an internal cyber team, this may be very valuable.
However, check:
The cyber insurance purchase process may force the company to organize the basics: MFA, backup, administrators, patching, EDR, suppliers, incident planning and training.
This is a positive effect if the company treats the insurance questionnaire as a security improvement tool, not a formality.
A policy does not block phishing, ransomware, account takeover, application vulnerabilities or employee mistakes. Technical controls, processes, training and monitoring are needed for that.
After an incident, the company needs backup, recovery procedures, access to systems, people, emergency contacts and board decisions. The policy itself will not restore ERP, email, CRM, production or an online store.
The company must know what to do in the first 60 minutes. Who should be notified? How should evidence be preserved? Should the device be disconnected? Who contacts legal? Who speaks to the customer? When should the incident be reported?
The insurer may help, but it should not be the company’s first and only action plan.
Customers do not look only at whether the company had a policy. They look at whether the company was prepared, communicated honestly, limited impact quickly and proved that it learned from the incident.
A policy has conditions. If the company declared MFA, backup, EDR or patch management but did not actually have them, a claim dispute may arise. This is one of the most important reasons why cybersecurity must be real, not only declared in a questionnaire.
This is a dangerous shortcut. A policy may reduce some financial consequences, but it does not automatically reduce the likelihood of an attack. If the company lacks basic controls, an incident can still stop operations.
The board should understand three levels of risk:
Insurance mainly concerns the third level. Without the first two, the company is not managing risk, it is buying hope.
Insurers increasingly ask about real security controls. The company should take the insurance questionnaire seriously because answers may matter during a future claim.
Answer according to facts. Do not assume that “MFA is enabled” if it works only for some users. Do not write that backup is tested if nobody has ever restored data. Do not declare an incident plan if it is only an outdated document in a folder.
Evidence to prepare: evidence pack for the insurance questionnaire: MFA report, backup report, recovery test report, incident plan, administrator list, training report and supplier review.
Check which events are covered. Ransomware, data breach, business interruption, cyber extortion, legal costs and third-party liability may have different terms.
Exclusions matter as much as coverage. A policy may exclude certain types of loss, war-related events, missing required controls, some financial fraud types, previously known issues or actions not aligned with policy conditions.
The main policy limit may look high, but specific cost categories may have lower sublimits. This is especially important for downtime, ransomware, forensics, PR, legal costs and third-party liability.
The company should understand which part of the cost remains on its side and when business interruption cover starts.
The policy may require fast notification to the insurer, approval for specific costs or use of insurer panel providers.
If the policy requires MFA, backup, EDR or patch management, the company must have evidence that these controls were actually implemented and operating.
Multi-factor authentication should cover email, administrators, VPN, cloud, CRM, financial systems, hosting, domains and backup. Administrator accounts should have stronger protection than normal accounts.
Backup should cover critical data, be protected from deletion and ransomware, and be regularly tested. Without testing, the company does not know whether it can return to operation.
The plan should define roles, contacts, first actions, escalation, evidence preservation, communication, suppliers and insurer contact rules.
The company should protect computers and servers, especially against ransomware, malware, suspicious processes and unauthorized actions.
Systems and applications should be updated. Critical vulnerabilities cannot remain without decisions for months.
The more administrators, the greater the risk. Permissions must be limited, separate administrative accounts should be used and roles should be reviewed.
Phishing, fake invoices, executive impersonation and account takeover remain common. Training should be practical and repeated.
IT, cloud, hosting, MSP, SOC, software house and business system providers may be part of the risk. Their access and post-incident obligations should be known.
The board should treat cyber insurance as one element of cyber risk management. First understand risk, then reduce it, and only then decide which risks can be reasonably transferred.
Ransomware is one of the most important cyber insurance scenarios. A policy may support response costs, but it does not replace operational readiness.
If the company has no working backup, it may struggle to recover even with a policy. If it has no logs, it may not know what happened. If it has no communication plan, it may lose customer trust. If it does not report the claim according to policy conditions, it may make payment harder.
A data breach is not only a technical cost. It also involves law, communication, customers, reputation and obligations toward affected people.
Before buying a policy, check:
At the same time, the company must have real controls: access control, encryption, MFA, logs, data classification, sharing limits and data breach response procedure.
Many companies assume cyber insurance will cover every fraudulent payment. This is risky. Business email compromise, supplier impersonation or bank account change fraud may be covered under another policy, a sublimit or an exclusion.
That is why the company needs a payment procedure regardless of the policy.
First determine what may happen: ransomware, account takeover, data breach, payment fraud, system outage, supplier failure, cloud outage or application vulnerability.
Implement MFA, backup, recovery testing, training, EDR, incident response plan, administrator review and supplier control.
After controls, assess which risk remains. Part of this remaining risk may be a candidate for transfer through insurance.
Do not buy a policy by name only. Check whether it covers scenarios that really hurt the company: ransomware, BEC, data breach, business interruption, legal costs, forensics and customer liability.
The policy should be linked to evidence: MFA, backup, recovery test, training, incident response plan, access review, EDR, patch management and supplier review.
A tabletop exercise should include: when and how do we contact the insurer? Who has the policy number? Who approves costs? Who speaks to legal? Can we use our own incident response provider?
A policy is not MFA, backup, EDR or an incident response plan. It is a financial and organizational tool after an incident.
Companies often focus on the insurance limit and too little on exclusions. Yet exclusions may decide whether a specific loss is covered.
If the company declares MFA, backup and training, it should have reports. A declaration without evidence can be a problem during a claim.
During an incident, the company must know when to notify the insurer, who to contact and whether costs can be incurred without insurer approval.
The policy may help financially, but if the company cannot restore data, downtime may last much longer.
Policies have limits, sublimits, exclusions and duties. Fraudulent payment, regulatory fine, reputation loss or indirect losses may not be covered as the company expects.
Cyber risk changes every year. New systems, suppliers, cloud, AI, regulations and incidents should affect both the policy and the security programme.
A services company with 60 employees buys cyber insurance because an enterprise customer requires confirmation of coverage. The board assumes the cyber topic is solved. The company has a policy, but MFA works only for some accounts, backup has not been tested and no incident response plan exists.
Several months later, an email account is compromised. The criminal observes customer correspondence and attempts to change a payment account number. The company reports the incident to the insurer, but it quickly becomes clear that the insurance questionnaire answers were too optimistic. There is no MFA report, no training evidence, no backup test and no clear claim notification procedure.
After the incident, the company changes its approach. The policy remains in the strategy, but not as a replacement for security. The board approves MFA for everyone, backup testing, incident response plan, phishing training, supplier review and a quarterly cyber risk dashboard. At renewal, the company has evidence and a stronger position in the broker discussion.
The key lesson: cyber insurance can help after an incident, but only a company with real controls has a better chance to reduce loss and handle the claim process effectively.
ccyber.io helps companies prepare for cyber insurance in a way that actually reduces risk, not only fills a questionnaire. We combine board, IT, security, compliance and incident response perspectives.
We can support your organization with:
The best first step is a Cyber Insurance Readiness Workshop. In a short workshop, the company can determine which policy requirements are already met, where gaps exist, which evidence must be prepared and which actions reduce the risk of claim denial or a serious incident the most.
It can be very useful, especially when the company has customer data, critical systems, contractual requirements or high downtime risk. It should not replace security controls.
It depends on the policy. Check scope, exclusions, limits, required controls, notification procedure and incident response provider rules.
Not always. Business email compromise or bank account change fraud may have separate terms, sublimits or exclusions. This must be checked before purchase.
A dispute may arise if the company did not meet policy conditions, provided inaccurate questionnaire answers, did not notify the claim on time or incurred costs without required approval.
Usually MFA, backup and recovery testing, EDR, updates, incident response plan, training, administrator control and supplier management.
It may help as part of risk management, but customers usually ask about real controls too: MFA, backup, testing, training, incident response, access and suppliers.
Ideally jointly: CFO or board for the financial decision, IT and security for controls, legal for policy terms, compliance for requirements and risk owner for overall consistency.
Start with a cyber risk register, MFA, backup, incident response plan and evidence review. Then compare policies and answer the insurance questionnaire.
Cyber insurance does not replace cybersecurity because it does not prevent attacks and does not automatically restore business operations. It can be an important part of risk management, but it works best when the company has real controls, an incident plan and evidence.
A policy may help cover some costs, provide access to experts and support the company during a crisis. It will not replace MFA, backup, recovery testing, training, monitoring, administrator control, supplier management and board decisions.
The best approach is: reduce risk first, then transfer part of the risk that cannot be reasonably eliminated. Cyber insurance then becomes an addition to company resilience, not the only line of defense.
MFA, Backup and Phishing: The Security Minimum for SMEs
MFA, backup and phishing protection are three pillars of basic cybersecurity for SMEs. MFA protects accounts from takeover, backup enables recovery after outages or ransomware, and phishing readiness reduces fraud, payment scams and data leakage risk. Learn how to implement a security minimum without building a large security team.
Prepared by: CCyber Editorial Team
For SMEs, the absolute cybersecurity minimum is MFA, backup and phishing readiness. MFA, or multi-factor authentication, protects accounts even when a password is stolen. Backup allows the company to recover data after ransomware, outage, human error or device loss. Phishing readiness reduces the risk of email takeover, fake invoices, payment fraud and data leakage. These three areas do not solve everything, but they close the most common and costly risks in a small or medium-sized company.
July 2026
Small and medium companies usually do not start with advanced nation-state attacks. Most problems start simply: someone clicks a link, enters a password, an attacker takes over email, sends a fake invoice, encrypts data or deletes files.
MFA, backup and phishing answer three basic questions:
If the company does not have a good answer to these three questions, every additional security tool will be built on a weak foundation.
MFA, or multi-factor authentication, means that login requires more than just a password. The user confirms identity with a second factor, such as an authenticator app, hardware key, passkey, biometrics or code.
Simply put: a password can be stolen. MFA reduces the risk that the password alone is enough to take over an account.
Not all MFA provides the same level of protection. For normal accounts, an authenticator app or passkey is often a reasonable minimum. For administrators and critical accounts, stronger methods such as hardware keys or phishing-resistant MFA should be considered.
Practical hierarchy:
Evidence to prepare: MFA report for all accounts, exception list and a separate report for administrators.
Backup is a copy of data that can be used to restore company operations after an outage, file deletion, ransomware, employee mistake, laptop loss or supplier problem. Backup should cover data needed for business operations, not random folders.
Backup should answer three questions:
Cloud file synchronization helps work across devices, but it does not always protect against ransomware, mass deletion, incorrect synchronization or account takeover. If malicious changes synchronize everywhere, synchronization alone will not solve the problem.
Backup should have:
It depends on how much data the company can lose. For some companies, losing one day of data may be acceptable. For others, even one hour is a problem.
Define:
Evidence to prepare: critical data list, backup policy, latest recovery test report and list of people with backup access.
Phishing is an attempt to trick a person by impersonating a trusted person, company or system to steal a password, MFA code, payment, customer data, file access or cause malware installation.
Phishing may arrive through:
Evidence to prepare: phishing reporting procedure, training materials, training report, payment verification rule and account takeover playbook.
Start with email, administrators, finance, CRM, cloud, hosting, domain, social media and banking. Administrator accounts should be protected more strongly than normal accounts.
Inactive accounts of former employees, interns, contractors and suppliers are an easy target. Review accounts at least quarterly.
The fewer high-privilege accounts, the lower the impact of one account takeover. Administrators should use a separate account for administrative work.
You cannot design backup without knowing what matters. The critical data list should include email, files, business systems, customers, accounting and configurations.
Backup should protect against outage, data deletion, ransomware and account takeover. Backups should have separate permissions and point-in-time recovery.
Backup without a test is a promise. A recovery test shows whether data is complete, whether passwords are available, how long recovery takes and what must be fixed.
Configure SPF, DKIM and DMARC. This will not stop every attack, but it limits domain impersonation and improves email control.
Training should show realistic examples: fake login link, invoice, urgent payment request, fake cloud document and executive impersonation.
Supplier bank account changes, urgent payments or unusual financial requests should be confirmed through another channel, such as a phone call to a previously known number.
The company should know how to quickly block the account, revoke sessions, change the password, check MFA, remove email forwarding rules and notify customers if needed.
If ransomware appears, employees must know not to connect backups, delete evidence or restore systems chaotically before understanding the attack scope.
Every quarter, check MFA, accounts, administrators, backup, recovery test, training, phishing, suppliers and open remediation actions.
The attacker does not need to compromise the CEO. Sometimes an assistant, sales person or accountant account is enough. MFA should be the standard, and exceptions should be temporary and approved.
An administrator account can change settings, add users, disable controls or access data. Administrators must have stronger MFA and fewer standing privileges.
The company often pays for backup but does not know whether it can recover data. Recovery testing should be documented.
The fact that files are in the cloud does not automatically mean the company is resilient to ransomware, account takeover or mass deletion.
Phishing changes quickly. Training should be short, practical and repeated. The best examples are similar to real messages received by the company.
If employees are afraid to report clicks, the company loses the most important response minutes. Build a culture of fast reporting without blame.
Many fraud attempts do not need malware. Time pressure and supplier or executive impersonation are enough. Bank account changes should always be verified through another channel.
Someone must regularly check MFA, backup and phishing readiness. If responsibility is scattered, the minimum becomes outdated quickly.
A services company has 24 employees and uses Microsoft 365, CRM, online accounting and cloud drive. The company has basic antivirus protection, but MFA is enabled only for some users, backup has never been tested, and employees do not have a clear phishing reporting instruction.
The first incident starts with a fake email containing a link to an invoice. An employee signs in on a fake page and approves a login. The attacker creates an email forwarding rule, observes correspondence with a customer and attempts to change the payment account number.
After a review, the company implements the minimum: MFA for everyone, stronger MFA for administrators, email rule review, SPF, DKIM, DMARC, email and file backup, recovery test and phishing training. Accounting also introduces a rule to confirm bank account changes by phone using a known number.
After 90 days, the company has an MFA report, tested backup, trained employees, a simple phishing reporting channel and an account takeover playbook. This is not a full cybersecurity programme, but it is a real minimum that materially reduces the risk of common incidents.
ccyber.io helps SMEs implement the security minimum in practice: MFA, backup, phishing, email, administrators and first incident playbooks. We do not start with a complex enterprise programme. First, we close risks that most often cause real losses.
We can support your organization with:
The best first step is a short MFA, Backup and Phishing Assessment. In a short workshop, the company can check which accounts do not have MFA, whether backup works, whether email is secured and whether employees know what to do after a suspicious message.
Yes. Small companies are also targets of phishing and account takeover. MFA is one of the cheapest and most effective ways to reduce the risk of email, cloud, banking and business system compromise.
SMS is better than no MFA, but for administrator accounts and critical systems, stronger methods such as an authenticator app, passkey or hardware key are recommended.
They may help recover files, but synchronization alone is not always enough. The company should have a clear backup policy, version history, deletion protection and recovery test.
For critical data, at least quarterly or after major changes. Less critical systems may be tested less often, but the test should be documented.
Report the event quickly, do not delete the message, block or reset the account, revoke active sessions, check MFA, email forwarding rules and login logs.
No. Training is important, but it must be combined with MFA, email security, reporting procedure, payment verification and an account takeover playbook.
Start in parallel with MFA for the most important accounts, checking backup for critical data and a short phishing instruction for employees. These three actions can begin in the first 30 days.
It depends on users, systems and data. In a small company, it is often possible to start with several thousand PLN one-time for configuration and training, plus several hundred to several thousand PLN monthly for licenses, backup and maintenance.
MFA, backup and phishing are the most important security minimum for SMEs. MFA limits the impact of password theft. Backup gives a chance to recover from ransomware, outage or human error. Phishing readiness reduces the risk of account takeover, fake invoices, fraud and data leakage.
These three areas do not replace a full cybersecurity programme, but they are the best starting point. Only after organizing them does it make sense to move to endpoints, monitoring, PAM, security testing, vulnerability management, NIS2, ISO 27001 and vCISO.
The key rule for SMEs: do not wait for an incident. Enable MFA, test backup, train people and prepare a simple playbook. This is a small effort compared with the cost of email takeover, ransomware or payment fraud.
Cyber Resilience Act: What It Means for Software and Hardware Manufacturers
The Cyber Resilience Act means that software and hardware manufacturers selling products with digital elements on the EU market must design them securely, assess cyber risk, maintain technical documentation, manage vulnerabilities, provide security updates, define the support period, prepare conformity assessment, CE marking and report actively exploited vulnerabilities and severe incidents.
Prepared by: CCyber Editorial Team
The Cyber Resilience Act, or CRA, is an EU regulation that changes how digital products are built and sold in the EU. It applies to software and hardware manufacturers if their products with digital elements are placed on the European Union market. In practice, CRA requires cybersecurity to be built into the product from the design stage, not added only after an incident. The manufacturer must assess cyber risk, implement security requirements, control components, handle vulnerabilities, provide updates, prepare technical documentation, perform conformity assessment, apply CE marking and report specific vulnerabilities and incidents.
July 2026
The Cyber Resilience Act is an EU regulation establishing horizontal cybersecurity requirements for products with digital elements. Its goal is to increase the security of software and hardware products available on the EU market and reduce risks caused by vulnerabilities, missing updates and weak default configuration.
CRA matters because many digital products have historically reached the market without sufficient security, without a clear support period, without an effective update process and without transparent vulnerability handling. CRA changes this model. The manufacturer is responsible for product security not only on the sales date, but throughout the support period.
In practice, CRA requires the product to be:
CRA applies to products with digital elements made available on the EU market. It can cover both final products and software or hardware components placed on the market separately.
The manufacturer has the most significant obligations. However, CRA may also affect other economic operators in the supply chain.
The key question is: does your company place a product with digital elements on the EU market under its own name or trademark? If yes, CRA may be directly relevant.
This is one of the most common questions. CRA is not a classic regulation for every standalone SaaS service. At the same time, CRA may cover remote data processing solutions if they are designed and developed by the manufacturer or under the manufacturer’s responsibility and are necessary for a product with digital elements to perform one of its functions.
Example: if an IoT device only works with the manufacturer’s cloud, the cloud component may be relevant to the product assessment. If a company only sells a standalone SaaS service without a product with digital elements in the meaning of CRA, this requires separate analysis. Do not assume automatically that “SaaS always applies” or “SaaS never applies”.
Practical decision: every SaaS, cloud-connected, IoT, embedded or product company should perform a short CRA scope analysis.
For software manufacturers, CRA means moving from “we will fix it if the customer reports it” to a product security by design approach. Security must enter backlog, development process, testing, release management, documentation, vulnerability handling and user communication.
For hardware manufacturers, CRA means that security does not end with the physical device. Firmware, bootloader, communication, interfaces, updates, components, companion applications, manufacturer cloud and user documentation must also be considered.
The first step is scope analysis. The company should determine whether the product is a product with digital elements, whether it is made available on the EU market and which role the company has: manufacturer, importer, distributor, component supplier or subcontractor.
Evidence to prepare: CRA scope analysis for every product or product family.
The product may belong to the default, important or critical category. This classification affects the conformity assessment procedure and possible involvement of a notified body.
Check:
Evidence to prepare: CRA product classification card.
Cyber risk assessment is the basis for implementing requirements. The manufacturer should know which threats affect the product, which data and functions are critical and which controls are needed.
The assessment should cover:
Evidence to prepare: product cybersecurity risk assessment.
CRA requires the product to meet essential cybersecurity requirements. In practice, this includes default security, access control, attack surface reduction, data protection, resilience against misuse and the ability to update securely.
The requirements must be translated into concrete product tasks:
Evidence to prepare: CRA requirements register mapped to features, controls and evidence.
The manufacturer cannot ignore third-party components. If the product uses libraries, packages, firmware, modules, operating systems or hardware components, their impact on product security must be assessed.
In practice, this requires:
Evidence to prepare: SBOM, component register and vulnerability monitoring process.
CRA requires the manufacturer to handle product vulnerabilities during the support period. This means a process, not a one-time action.
The process should include:
Evidence to prepare: vulnerability handling procedure and product vulnerability register.
The manufacturer should be able to provide security updates. Depending on product type, this may include automatic updates, firmware updates, installation packages, mobile app updates or component fixes.
Define:
Evidence to prepare: security update policy and support period description.
Technical documentation will be one of the most important conformity evidence sets. It should show how the product meets CRA requirements and how the manufacturer manages risk.
Documentation should include, among other things:
Evidence to prepare: technical documentation pack for the product.
Before placing the product on the market, the manufacturer must perform the appropriate conformity assessment procedure. For many products this may be self-assessment, but for certain important and critical products the procedure will be more demanding.
Determine:
Evidence to prepare: conformity assessment file, EU declaration of conformity and decision on the assessment procedure.
After demonstrating conformity, the manufacturer can apply CE marking and provide the required user information and instructions. The information should enable secure installation, configuration, operation and maintenance of the product.
User information should cover:
Evidence to prepare: user instructions, declaration of conformity and CE marking.
CRA entered into force.
Rules on the notification of conformity assessment bodies started to apply.
Reporting obligations for actively exploited vulnerabilities and severe incidents affecting products with digital elements start to apply.
The main CRA obligations start to apply.
Products placed on the market before 11 December 2027 are generally subject to the main CRA obligations if they are substantially modified from that date. Reporting obligations, however, apply to products already made available on the EU market.
From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements.
Notifications are to be submitted through the CRA Single Reporting Platform managed by ENISA. In practice, the manufacturer needs an internal process that can quickly determine whether an event is reportable, collect facts and make the decision.
Evidence to prepare: CRA vulnerability and incident reporting playbook.
CRA does not replace other regulations. It mainly concerns the security of products with digital elements. NIS2 concerns organizational and service cyber resilience in specific sectors. DORA concerns digital operational resilience in the financial sector and its ICT provider ecosystem. GDPR concerns personal data protection.
A technology company may be subject to several requirements at once. Example: an application manufacturer may have CRA obligations for the product, NIS2 requirements as a supplier to an essential entity and GDPR requirements if it processes personal data.
Prepare a list of software and hardware products the company develops, sells or makes available on the EU market.
Evidence: product inventory.
For each product, determine whether it is a product with digital elements and what the company’s role is.
Evidence: CRA applicability analysis.
Determine whether the product belongs to the default, important or critical category.
Evidence: product classification memo.
Perform product risk assessment and define security requirements.
Evidence: product cybersecurity risk assessment.
Implement or organize secure SDLC, dependency control, SBOM and security testing.
Evidence: secure SDLC policy, SBOM, SAST, DAST, SCA and manual testing results.
Prepare vulnerability handling process and a security contact point.
Evidence: vulnerability handling procedure and coordinated vulnerability disclosure policy.
Define product support period and method of delivering security updates.
Evidence: support period statement and security update policy.
Prepare technical documentation, evidence and conformity assessment procedure.
Evidence: technical documentation, conformity assessment file and EU declaration of conformity.
CRA applies to both software and hardware. Applications, components, firmware and products with manufacturer cloud may require analysis.
The main obligations apply from 11 December 2027, but processes, documentation, SBOM, updates and vulnerability handling take time. Reporting obligations start earlier.
CRA requires legal work, but it is not only documentation. The product development process, testing, release management, vulnerability handling and user communication must change.
If nobody owns product security, CRA requirements will be scattered across legal, engineering, QA, support and the board.
The product may become vulnerable through a library, firmware, open source dependency, hardware component or external service. Without a component list, the company does not know what to update.
A support email address is not enough. The manufacturer should have a triage, prioritization, remediation, communication and evidence process.
Technical documentation should be created alongside the project. Creating it after the fact is more expensive and often fails to show real security decisions.
A company manufactures an IoT device for the European market. The device has firmware, a mobile app, an administrator panel and the manufacturer’s cloud, without which some functions do not work. Until now, the company focused on features and time to market, and security was mostly checked at the end of the project.
After CRA analysis, the company finds that it must prepare product risk assessment, technical documentation, firmware update process, component list, vulnerability handling, support period and user information. It also needs to determine whether the product belongs to the default, important or critical category.
The company starts with a 90-day plan. First it creates a component list, performs threat modeling, implements SCA for software, prepares a CVD process and organizes security updates. Then it creates the technical documentation structure and maps CRA requirements to controls and evidence.
The biggest change is not adding one test. The biggest change is that product security becomes a continuous process owned by product, engineering, security, legal and the board.
ccyber.io helps software and hardware manufacturers prepare products for the Cyber Resilience Act in a practical, technical and business-focused way. We combine regulation, product security, secure development, vulnerabilities, documentation and conformity assessment perspectives.
We can support your organization with:
The best first step is a CRA Product Readiness Workshop. It helps quickly determine which products are in CRA scope, what the biggest gaps are, what evidence must be prepared and how to plan work before the 2026 and 2027 deadlines.
No. CRA applies to both software and hardware if they are products with digital elements made available on the EU market.
Yes, a mobile app may be a product with digital elements if it is made available on the EU market and meets the regulation criteria.
Not automatically. A standalone SaaS service may need a different analysis than a product with digital elements. However, CRA may cover remote data processing linked to a product if it is necessary for product functionality.
No. Many products will be able to use self-assessment. Important and critical products may require a stricter conformity assessment procedure, including notified body involvement.
First prepare a product list and analyze whether products are in CRA scope. Only then classify the product, assess risk, plan requirements and documentation.
CRA requires effective vulnerability management for the product and its components. In practice, SBOM is one of the most important tools for controlling software ingredients and responding to vulnerabilities.
Reporting obligations for actively exploited vulnerabilities and severe incidents start on 11 September 2026.
The manufacturer should prepare product cyber risk assessment, secure development, vulnerability handling, security updates, technical documentation, conformity assessment procedure, user information and evidence of meeting requirements.
The Cyber Resilience Act turns digital product cybersecurity from good practice into a market requirement. A software or hardware manufacturer cannot limit itself to declaring that the product is secure. It must have a process, documentation, evidence, updates and vulnerability handling during the support period.
For software manufacturers, CRA means secure SDLC, SBOM, testing, vulnerability handling, CVD, updates and documentation. For hardware manufacturers, it means secure firmware, interface control, secure updates, secure defaults, support period and technical documentation.
The best strategy is to start with scope analysis and product classification. Then perform gap analysis, risk assessment, product security process implementation and conformity evidence preparation. Companies that start earlier will have an advantage in B2B sales, customer audits and placing products on the EU market.
How to Prepare the Board for NIS2? Practical Guidance
Preparing the board for NIS2 is not about a one-time legal presentation. The board should know whether the company falls under NIS2 or KSC, which cyber risks matter most, who owns the compliance programme, which measures must be approved, how incidents are reported, how suppliers are controlled and what evidence will be needed during audits, inspections or customer discussions.
Prepared by: CCyber Editorial Team
To prepare the board for NIS2, a company should do five things: determine whether it falls under NIS2 or national rules implementing the directive, explain the board’s responsibility for cyber risk oversight, prepare a register of top cyber risks, show gaps against required security measures and lead to concrete board decisions. The board does not need to know technical configuration details. It must understand how cybersecurity affects operations, incidents, suppliers, business continuity, budget, compliance evidence and residual risk.
July 2026
Preparing the board for NIS2 means building a shared understanding of the obligations, risks and decisions arising from the directive and the national rules implementing it. The goal is not for the board to memorize every article of the directive. The goal is for the board to make the right decisions.
The board should be able to answer:
Simply put: the board does not need to manage security tools. The board must manage risk and decisions.
NIS2 strengthens the role of management bodies. The board should understand risk, approve cybersecurity risk-management measures, oversee implementation and ensure that cybersecurity is treated as part of business continuity and company management.
For the board, this means three levels of responsibility:
This does not mean that a board member configures MFA or firewalls. It means the board should know whether MFA and other measures are implemented, whether they work and whether residual risk is acceptable.
The board cannot be prepared well without answering whether the company is in scope. Applicability analysis should be the first document for the board.
The analysis should include:
Evidence to prepare: NIS2 or KSC applicability analysis with a short recommendation for the board.
The board should not receive a long technical lecture at the start. The best briefing should take 30-60 minutes and end with decisions.
The briefing should explain:
A good briefing does not end with a “thank you” slide. It ends with decisions, owners and deadlines.
Evidence to prepare: NIS2 board briefing agenda, materials and decision note.
The board should see risks as business scenarios, not as a raw list of vulnerabilities. A scenario shows what may happen and how it affects operations.
Each risk should have:
Evidence to prepare: top 10 cyber risk register for the board.
Gap analysis shows the difference between the company’s current state and the required or expected level of security. It helps the board understand what must be done and why.
Gap analysis should cover:
Evidence to prepare: NIS2 gap analysis with priorities, costs and action plan.
One of the most common problems is distributed responsibility. IT says it is compliance. Compliance says it is IT. The board assumes someone is handling it. This does not work.
The NIS2 programme should have an owner who coordinates:
In smaller companies, the owner may be a board member supported by a vCISO or external advisor. In larger companies, it may be a CISO, risk manager, compliance manager or a person appointed by the board.
Evidence to prepare: board decision on the NIS2 programme owner and responsibility scope.
The board needs a realistic plan. Not everything can be done in one week. It is best to divide actions into quick controls, organizational actions and long-term projects.
Evidence to prepare: 90-day and 12-month NIS2 roadmap approved by the board.
The board should regularly see a simple dashboard, not a long list of tickets. The dashboard should show risk, progress, decisions and evidence.
The best rhythm for most companies is quarterly reporting. Regulated companies or companies in intensive implementation should report more often.
Evidence to prepare: quarterly NIS2 and cyber risk dashboard for the board.
NIS2 makes an incident more than a technical problem. It is also about communication, timelines, law, evidence, customers, suppliers and board decisions.
The board should know:
Evidence to prepare: incident response plan and tabletop exercise report involving the board.
Suppliers are one of the most important NIS2 topics. A company may have good internal security and still be exposed through an IT provider, cloud provider, hosting provider, software vendor, payment provider, managed service provider or integrator.
The board should require a critical supplier list showing:
The key board question: do we know which supplier can stop our business or expose us to an incident?
Evidence to prepare: critical supplier register and supplier risk assessment results.
NIS2 and customer requirements do not end with declarations. The company should have evidence that security measures work.
Evidence should be current, organized and assigned to owners. During a crisis, there will be no time to search for documents across folders.
Evidence to prepare: NIS2 evidence pack stored in a controlled repository.
Board training should be short, concrete and decision-oriented. It should not be only legal or technical. The best training combines regulation, risk, business and practical decisions.
Evidence to prepare: training agenda, participant list, materials and decision note.
After the first NIS2 briefing, the board should make concrete decisions. Otherwise the topic will keep dragging.
The board should approve not only that “something needs to be done”, but who does what and by when.
If the board meeting ends only with “this topic is important”, it is not preparation. Decisions, owners and deadlines should be created after the meeting.
IT is responsible for many technical actions, but NIS2 also concerns the board, risk, suppliers, incidents, continuity, budget, evidence and accountability.
Without applicability analysis, the company does not know whether it is preparing for a regulatory obligation, customer requirements, good practice or all of these at once.
The board needs information about company impact, not only vulnerabilities, CVEs, logs and configuration. Technical details should be translated into business risk.
The supply chain is one of the key NIS2 areas. Ignoring suppliers means the company does not understand the full risk.
The board must know how to act during an incident. A procedure alone is not enough. A tabletop exercise with the board and key people is needed.
Implementation without evidence is hard to defend. The company should collect reports, decisions, test results, training attendance and review confirmations.
A technology company has 140 employees and provides services to industrial clients. Customers start asking about NIS2, incident response, MFA, suppliers and backup testing. Initially, the board thinks this is only an IT topic.
After a short briefing, the board sees that the issue is broader. The company may be a supplier to organizations covered by NIS2, and customers will expect security evidence. The board decides to perform applicability analysis, gap analysis and prepare a risk register.
In the first 30 days, the company identifies critical systems, suppliers, top risks and MFA status. In the next 30 days, NIS2 gap analysis, action plan and dashboard are created. After 90 days, the board approves the budget, roadmap, incident exercise plan and customer evidence pack.
The biggest change is not buying one tool. The biggest change is moving cybersecurity from “IT handles it” to board decisions, business risk and measurable evidence.
ccyber.io helps prepare boards for NIS2 in a practical, business-focused and decision-oriented way. We do not only deliver a presentation about rules. We help move from uncertainty to a plan: applicability, risks, gaps, roadmap, budget, incidents, suppliers and evidence.
We can support your organization with:
The best first step is a NIS2 Board Readiness Workshop. In one workshop, the company can determine whether it may be affected by NIS2, which decisions the board must make and how to build the first 90-day action plan.
Yes, if the company falls under NIS2, national rules implementing it or customer supply chain requirements. The board should understand risk, approve security measures and oversee implementation.
No. The board needs business and decision training. The key topics are accountability, scope, risk, incidents, suppliers, budget and evidence.
Start with a short NIS2 briefing, applicability analysis and a decision to perform gap analysis. Then prepare a risk register, roadmap and board dashboard.
NIS2 is not reduced to having ISO 27001 certification. However, ISO 27001 can help organize information security management, risk, evidence and continual improvement.
The board should assign the programme owner, approve applicability analysis, approve gap analysis, request a risk register, review the incident plan, backup, MFA and critical suppliers.
Yes. Supply chain security is one of the key areas. The board should know which suppliers are critical, what access they have and which security requirements are in contracts.
Quarterly review is reasonable for most companies. During implementation or after an incident, the board should receive status updates more often.
The best evidence includes board training, applicability analysis, gap analysis, risk register, budget decisions, action plan, dashboard, incident plan, supplier review and compliance evidence pack.
Preparing the board for NIS2 should not be a one-time legal presentation. It should be a process leading to decisions, accountability, budget, roadmap and recurring oversight.
The board should know whether the company falls under NIS2 or KSC, which cyber risks are most important, which security measures must be implemented, how incidents are reported, how suppliers are controlled and what evidence will be needed.
The best result of board preparation is not a statement that “this topic is important”. The best result is a board that knows which risk it accepts, which actions it funds, which evidence it wants to see and how often it will oversee cybersecurity.
How Much Does Basic Cybersecurity Cost for a Company?
Basic cybersecurity for an SME usually costs from tens to several hundred PLN per user per month, plus from several to several tens of thousands PLN as a one-time budget for configuration, audit, backup, MFA, training and incident response planning. The exact cost depends on users, systems, cloud, data, suppliers and customer requirements.
Prepared by: CCyber Editorial Team
Basic cybersecurity for a company costs what is needed to secure accounts, devices, email, backups, data, administrator access and incident response. For a small company, this usually means around 100 to 300 PLN per user per month in a simple model, plus several to several tens of thousands PLN as a one-time budget for configuration, security review, training, backup and response planning. A 10-person company can often start with around 1,000 to 3,000 PLN monthly plus 5,000 to 20,000 PLN one-time. A 50-person company should more often assume 5,000 to 15,000 PLN monthly plus 20,000 to 70,000 PLN one-time. These are indicative ranges, not a price list. The key is that cost should follow risk, not a random list of tools.
July 2026
Basic cybersecurity is a minimum set of actions that significantly reduces the risk of common incidents: phishing, account takeover, ransomware, data loss, payment fraud, document leakage and outage without fast recovery.
For SMEs, a basic package should include:
This is not a luxury. It is the minimum that allows the company to answer: can we reduce the simplest and most common risks?
Indicatively, for SMEs in Poland in 2026, three budget levels are useful. Amounts are net and should be confirmed with current supplier offers.
For a very small company that wants to close the biggest risks fast.
Scope:
For a company serving B2B customers, holding customer data, using cloud and needing real security evidence.
Scope:
For a SaaS company, software house, e-commerce company, manufacturing company, IT provider or organization preparing for ISO 27001, NIS2, SOC 2, customer audit or cyber insurance.
Scope:
Two companies with the same number of employees may have very different cybersecurity costs. An accounting firm, online store, software house and manufacturing plant have different risks.
This is a monthly or annual cost. It includes tools for email, identity, MFA, endpoints, backup, password management, data protection and sometimes monitoring.
Typical ranges:
Note: some functions may already be included in licenses the company pays for. Higher Microsoft 365 or Google Workspace plans may include identity, email protection, device management, information protection and reporting. The first step is to review what the company already pays for.
A tool without configuration does not reduce risk. SMEs often pay for licenses but do not have the most important security features enabled.
Typical one-time ranges:
An assessment answers where the company has the biggest gaps and what should be done first. This is a good first cost because it prevents random tool purchases.
Typical ranges:
Training is relatively inexpensive compared with phishing, payment fraud and account takeover risk.
Typical ranges:
Backup is one of the most important baseline security costs. Backup alone is not enough. Recovery must be tested.
Typical costs:
The key rule: backup without a recovery test is an assumption, not evidence.
The company should have a plan, contacts, playbooks and a basic exercise. During a crisis, this reduces chaos.
Typical ranges:
After implementing the minimum, it must be maintained. Risks, accounts, suppliers, backups and vulnerabilities change every month.
Typical ranges:
This is the key question. Cybersecurity seems expensive only when compared with zero. It should be compared with the cost of an incident.
Typical incident costs for SMEs:
Simple example: if a 20-person company loses two workdays after ransomware, the cost is not only computer repair. It also includes salaries, lost orders, delays, customers, stress, lawyers, IT provider and trust rebuilding.
Minimum budget:
Priorities:
Minimum budget:
Priorities:
Minimum budget:
Priorities:
Minimum budget:
Priorities:
The best order for SMEs does not start with the most expensive tool. It starts from the risk that can be reduced quickly.
Missing MFA is one of the cheapest gaps to close and one of the most expensive gaps to ignore. Email account takeover may lead to data leakage, fake invoices and customer trust loss.
Backup is the last line of defense against ransomware, outage and human error. Saving money on backup may lead to several days of downtime.
A license does not configure itself. The biggest value is often not in buying, but in properly setting MFA, roles, sharing, email, backup and alerts.
An employee is often the first line of defense. Training does not have to be expensive, but it must be practical and repeated.
The company should know whether backup works, how long recovery takes and what is missing. Without a test, backup is only a promise.
A small company does not always need a full SIEM, 24/7 SOC or advanced PAM in month one. First close the basics.
Many companies already have security features in Microsoft 365, Google Workspace, cloud or endpoint tools. Often they simply need to be enabled and configured properly.
Start with MFA, backup, email, devices and incident plan. Then add EDR, monitoring, PAM, testing, governance, compliance and vCISO.
Instead of a long theory session, run short workshops on real scenarios: phishing, payment fraud, lost laptop, compromised account and ransomware.
Total: around 1,300 to 3,500 PLN monthly plus 7,500 to 20,000 PLN one-time.
Total: around 3,000 to 9,000 PLN monthly plus 16,000 to 40,000 PLN one-time.
Total: around 6,000 to 15,000 PLN monthly plus 30,000 to 90,000 PLN one-time.
Total: around 20,000 to 60,000 PLN monthly plus 30,000 to 100,000 PLN one-time.
The biggest cost is often not the license, but configuration, maintenance, testing, training and response.
A tool without someone responsible for configuration, alerts and review does not deliver full value.
The company pays for backup but does not know whether it can restore data. This is false economy.
Phishing and fraud remain among the most common incident sources. Training should be a permanent budget item.
Even a well-secured company can have an incident. Keep a reserve for emergency technical support, legal support and communication.
The budget must follow risk. A SaaS company, accounting office and manufacturing plant have different needs.
If customers start asking about ISO 27001, SOC 2, NIS2, backup, MFA and security testing, the basic budget may no longer be enough.
A services company has 18 employees. It uses Microsoft 365, one CRM system, online accounting, cloud storage and an external IT provider. The owner assumes that cybersecurity will cost tens of thousands per month, so the topic is postponed.
After a short assessment, the biggest risks turn out to be simple: MFA is not enabled for everyone, there are too many Global Administrators, SaaS data backup has not been tested, the domain does not have full DMARC and employees do not know how to report phishing.
The company implements a staged budget. In the first 30 days, it spends around 10,000 PLN one-time on MFA, email, administrator and backup configuration. Monthly cost increases by around 2,500 PLN for backup, endpoint protection and better management. In the next 60 days, the company adds training and a simple incident plan.
The result: the company does not have a full SOC, but closes the most important gaps. It has MFA, backup, recovery test, secured email, trained employees and a first-action incident checklist. It is not perfect cybersecurity. It is a reasonable minimum that materially reduces risk.
ccyber.io helps SMEs calculate and implement basic cybersecurity in a way that matches risk, budget and company growth. We do not start from the most expensive tool. We start from what can hurt the company most: account takeover, ransomware, missing backup, phishing, supplier risk, data leakage or customer requirements.
We can support your organization with:
The best first step is a short Cybersecurity Budget Workshop. It helps check what the company already pays for, what is missing, which actions have the highest impact and what budget is reasonable for the first 90 days.
For a 10-person small company, a reasonable start is often around 1,000 to 3,000 PLN monthly plus 5,000 to 20,000 PLN one-time for configuration, review, training, backup and incident planning.
Yes, if the company has a very simple structure and some functions are already included in licenses. However, do not save on MFA, backup, email configuration, training and recovery testing.
Usually MFA, inactive account removal, administrator role reduction, backup test, SPF/DKIM/DMARC configuration and short phishing training.
It is a good foundation, but having the license is not enough. Configuration matters: MFA, administrators, sharing, email, devices, logs, backup and access review.
Yes, if the company stores critical data in Microsoft 365, Google Workspace, CRM, ERP or another SaaS. Check whether data can be restored, how fast and from which point in time.
Not always at the start. First close the basics. SOC or MDR makes more sense when the company has more systems, higher risk, customer requirements or a stronger need for faster incident detection.
Both. One-time costs cover assessment, configuration, training, testing and documentation. Monthly costs cover licenses, backup, device protection, monitoring, maintenance and recurring oversight.
Start with users, devices, critical data, systems, suppliers and risk scenarios. Then calculate MFA, backup, endpoints, training, incident plan and first security review.
Basic cybersecurity for a company does not have to mean a large and expensive enterprise programme. For SMEs, the key is closing the most common risks: account takeover, phishing, ransomware, data loss, missing backup and incident chaos.
The real cost depends on users, systems, data and customer requirements. In practice, a small company should plan a monthly budget from several hundred to several thousand PLN and a one-time budget for configuration and implementation. A larger or more regulated company should plan more, especially for backup, monitoring, access review, vCISO and audit evidence.
The best rule is: do not buy cybersecurity randomly. First check risks, use the functions already included in current licenses, close the basics, test backup, train people and prepare an incident plan. Only then add more advanced tools.
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.