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.
Cyber Resilience Act: What Digital Product Manufacturers Must Prepare in 2026 and 2027
The Cyber Resilience Act means that manufacturers of software, hardware and products with digital elements must prepare product security as a process, not as a one-time test. In 2026, the key tasks are vulnerability handling, reporting of actively exploited vulnerabilities and severe incidents, product inventory, product classification, SBOM, update process, reporting contact and evidence. In 2027, manufacturers must complete risk assessment, technical documentation, conformity assessment, user instructions, support period, CE marking and market surveillance readiness.
Prepared by: CCyber Editorial Team
The Cyber Resilience Act, or CRA, changes the approach to digital product security in the European Union. A manufacturer of software, hardware, applications, components or products connected to a network must prepare not only a secure product on the day it is placed on the market, but also a security maintenance process throughout the support period. In 2026, the most important task is to prepare vulnerability handling and reporting of actively exploited vulnerabilities and severe incidents affecting product security. In 2027, manufacturers must complete full readiness: cybersecurity risk assessment, essential requirements, technical documentation, conformity assessment, EU declaration of conformity, CE marking, user instructions, support period, SBOM, security updates and evidence for market surveillance.
July 2026
The Cyber Resilience Act is an EU regulation that introduces horizontal cybersecurity requirements for products with digital elements. Its goal is to reduce the number of vulnerable products on the market, improve transparency for users and require manufacturers to maintain product security throughout the expected period of use.
In practice, CRA means that product security becomes a condition for entering the EU market. A manufacturer should not think only about functionality, sales and UX. It must also show that the product was designed, developed, documented, assessed and maintained according to cybersecurity requirements.
From 11 September 2026, reporting obligations for actively exploited vulnerabilities and severe incidents affecting product security will start applying. This means the manufacturer should already have a working process for detection, qualification, escalation and notification.
From 11 December 2027, the main CRA obligations will apply. New products with digital elements made available on the EU market will need to meet the essential cybersecurity requirements. The manufacturer must have technical documentation, risk assessment, conformity assessment, instructions, support period and declaration of conformity ready.
Companies that start preparation only at the end of 2027 will be late. CRA requires changes in the product, code, architecture, documentation, supplier contracts, update process, vulnerability handling and the way product teams work.
CRA applies to products with digital elements made available on the EU market. This includes final products and separately marketed components. A product with digital elements may be hardware, software or a combination of hardware and software.
This requires careful analysis. CRA applies to products with digital elements, and the definition includes remote data processing solutions if they are designed or developed by the manufacturer or under its responsibility and if their absence would prevent the product from performing one of its functions. Therefore, a SaaS company should check whether it offers a product with digital elements, component, client application, agent, installed software, device or remote data processing solution that is necessary for product functionality.
A software house will not always be the manufacturer under CRA. If it creates custom software and the customer places the product on the market under its own brand, roles must be defined in the contract. If the software house develops and sells a product under its own name or trademark, it may be the manufacturer and should prepare for CRA obligations.
The key role for this article is the manufacturer. This is the entity that develops or manufactures a product with digital elements, or has it designed, developed or manufactured, and markets it under its own name or trademark.
The manufacturer is responsible for product security, risk assessment, requirements, technical documentation, conformity assessment, declaration of conformity, CE marking, support period, updates and vulnerability handling.
The importer places on the EU market a product from a manufacturer outside the EU. It must make sure the product meets the requirements and that the manufacturer has performed the required actions.
The distributor makes a product available on the market without affecting its properties. It must act with due care and check basic conformity elements.
If a company modifies a product, sells it under its own brand, integrates it into a larger solution or makes a substantial modification, it should check whether it assumes manufacturer obligations.
The manufacturer should start with a full list of products with digital elements. Without a register, CRA scope, product class, support period, vulnerabilities, components and documentation cannot be managed.
Evidence to prepare: CRA product register with owners and classification.
Not every product will follow the same conformity assessment path. Many products may use manufacturer self-assessment, but important and critical products may require stricter procedures, including notified body involvement.
Evidence to prepare: product classification card with justification.
This is the most important area for 2026. The manufacturer must know how it receives vulnerability reports, qualifies them, escalates them, fixes them, informs users and reports actively exploited vulnerabilities.
Evidence to prepare: vulnerability handling procedure and vulnerability register.
From 11 September 2026, the manufacturer should be ready to report actively exploited vulnerabilities and severe incidents affecting product security. Roles, escalation path, templates and decisions must be prepared before an incident occurs.
Evidence to prepare: CRA reporting playbook, notification templates and escalation exercise.
CRA requires identifying and documenting vulnerabilities and components contained in products, including preparing a software bill of materials in a commonly used and machine-readable format covering at least top-level dependencies.
Evidence to prepare: SBOM, component policy and dependency vulnerability report.
The manufacturer should show that security is part of product development, not an end-stage test. Secure SDLC should cover security requirements, architecture, code, tests, reviews and updates.
Evidence to prepare: secure SDLC policy, test results and review evidence.
CRA requires effective mechanisms for distributing updates so that vulnerabilities are fixed or mitigated in a timely manner. For many products, security updates should be easy for users, secure and separated from functionality updates where technically feasible.
Evidence to prepare: security update procedure and update process test report.
Every in-scope CRA product should have a cybersecurity risk assessment. The assessment should identify risks, operating environment, users, interfaces, data, foreseeable misuse, vulnerabilities, components and applicable requirements.
Evidence to prepare: product cybersecurity risk assessment.
The manufacturer must show how the product meets the essential cybersecurity requirements in Annex I. In practice, this means the product should be designed without known exploitable vulnerabilities, have secure default settings, limited attack surface, access control, data protection, security updates and vulnerability handling.
Evidence to prepare: CRA requirements matrix with controls, tests and evidence.
Technical documentation will be one of the most important conformity evidence items. It should make it possible to demonstrate that the product meets CRA requirements and that the manufacturer operates product security processes.
Evidence to prepare: complete CRA technical documentation.
The manufacturer must select the right conformity assessment procedure. For many products, self-assessment will be possible. For important or critical products, a stricter procedure or notified body involvement may be required.
Evidence to prepare: conformity assessment path decision and evidence pack.
After a positive conformity assessment, the manufacturer can issue the EU declaration of conformity and mark the product with CE. This is not only a formality. CE means the manufacturer declares that the product meets the applicable requirements.
Evidence to prepare: EU declaration of conformity and CE marking procedure.
CRA requires that users receive information necessary for secure use of the product. This includes contact details for vulnerability reporting, intended purpose, security properties, support period, security updates, secure setup and secure decommissioning.
Evidence to prepare: product security instructions and public support information.
CRA has legal consequences, but implementation is mainly a product, engineering and operational task. Legal analysis alone is not enough without changes in the product development process.
The company does not know which products are in scope, which are components, which are important or critical and which versions are still supported.
From 2026, reporting actively exploited vulnerabilities requires a fast decision path. Without a process, the company may not assess and report on time.
A component list is not enough. The company needs an update process, vulnerability monitoring and mapping between components and product versions.
CRA requires security throughout the product lifecycle. An end-stage test does not replace secure SDLC, threat modeling and dependency control.
The user must know how long security support will be provided. The manufacturer must justify and document it.
If the product is important or critical, the manufacturer may need notified body involvement. This requires time and planning.
Documentation, tests, updates, risk decisions and vulnerability handling must leave a trace. Without evidence, conformity is difficult to demonstrate.
A SaaS company and software house develops an access management product for B2B customers. The product consists of a web application, an agent installed at the customer, API, open source components, login module and cloud integrations. The company initially assumes CRA mainly concerns IoT devices and delays the topic.
After analysis, it turns out that the customer-installed agent and access management product may be products with digital elements in scope of CRA. The company must prepare product register, risk assessment, SBOM, vulnerability reporting process, security update handling, customer instructions and conformity assessment path analysis.
In 2026, the company launches vulnerability contact, CVD, vulnerability register, SBOM and reporting playbook. In 2027, it completes technical documentation, tests, conformity assessment, instructions and CE process. As a result, CRA becomes part of product maturity, not a panic project at the end of 2027.
ccyber.io helps digital product manufacturers prepare for the Cyber Resilience Act in a practical, product-focused and evidence-driven way. We combine regulatory, security engineering, secure SDLC, security testing, SBOM, vulnerability, update and conformity documentation perspectives.
We can support your organization with:
The best first step is a CRA Product Readiness Workshop. In a short workshop, the company can identify which products are in scope, which obligations are urgent in 2026, which conformity path may be needed and what evidence must be prepared before 2027.
No. CRA applies to products with digital elements, meaning many hardware and software products, including applications, components, firmware, network devices, security products, embedded systems and network-connected products.
The most important task is preparing vulnerability handling and reporting of actively exploited vulnerabilities and severe incidents affecting product security.
The most important task is full product readiness: risk assessment, essential requirements, technical documentation, conformity assessment, instructions, support period, CE marking and evidence repository.
No. Many products can use self-assessment. Important or critical products may require stricter procedures and, in certain cases, notified body involvement.
Products placed on the market before 11 December 2027 will generally be subject to the requirements only if they undergo a substantial modification from that date. However, Article 14 reporting obligations apply to in-scope CRA products even if they were placed on the market before that date.
CRA requires preparing an SBOM as part of identifying components and vulnerabilities. Public availability to users is a separate issue. The manufacturer should prepare SBOM and procedures for making it available to relevant parties where required.
The support period should be defined by the manufacturer and generally should be at least 5 years, unless the expected product use period is shorter. It must be clearly indicated to the user and justified in documentation.
Start with the product register, CRA classification, in-scope assessment, vulnerability handling process, SBOM and action roadmap before 11 September 2026 and 11 December 2027.
The Cyber Resilience Act requires digital product manufacturers to move from “we released a product” to “we maintain a secure product throughout the support period”. This means changes in product, engineering, legal, quality and operational processes.
In 2026, the manufacturer should focus on reporting, vulnerability handling, SBOM, updates and secure SDLC foundations. In 2027, it must complete full readiness: risk assessment, requirements, documentation, conformity assessment, declaration of conformity, CE and user information.
The best rule is: do not wait until 2027. A product whose architecture, components, updates and documentation are not prepared today may require far more work than a formal declaration of conformity.
Does My Company Fall Under NIS2? A Simple Guide for SMEs
An SME should not answer the NIS2 applicability question only based on employee count or business activity code. Five things must be checked: sector, company size, size-independent exceptions, supply chain role and current national rules implementing NIS2. A small company often will not be directly an essential or important entity, but it may be indirectly affected by customer requirements if it provides IT, software, cloud, managed services, components, maintenance, data or processes to regulated entities.
Prepared by: CCyber Editorial Team
Not every small or medium-sized company in Poland is directly subject to NIS2. The fact that a company is an SME is not enough. The sector, type of services, company size, group relationships, size-independent exceptions and whether the company is a supplier to a regulated entity must be checked. As a rule, NIS2 mainly covers medium-sized and large entities in defined sectors. However, small and micro companies may be covered in exceptional cases or affected indirectly through customer requirements, contracts, security questionnaires and supplier audits. The safest approach is to prepare a short applicability assessment with date, sources, board decision and a minimum cybersecurity action plan.
July 2026
NIS2 is a European Union directive. This means that the practical answer in Poland must look at the directive, but also at national implementing rules, especially amendments to the national cybersecurity system. Therefore, the answer to “does my company fall under NIS2?” should include a date and the legal version used.
This guide helps prepare a practical assessment. It does not replace individual legal advice, but it shows how an SME board should organize the topic before speaking with a lawyer, auditor, customer or cybersecurity provider.
If the company is micro or small, does not operate in a special sector and does not provide critical services to larger entities, it will probably not be directly an essential or important entity. This does not mean it can ignore the topic.
If the company is medium-sized, operates in one of the NIS2 sectors or serves customers from those sectors, a formal applicability assessment should be performed.
If the company provides IT, cloud, managed, security, DNS, hosting, telecommunications, trust, domain registration services or maintains customer systems, NIS2 should be treated as a priority regardless of whether the company is ultimately directly covered.
Only answers to these questions allow a reasonable conclusion. A business activity code alone, employee count alone or the general label “IT” is not enough.
NIS2 covers sectors of high criticality and other critical sectors. For SMEs, the key point is to check whether the company’s real activity fits one of these sectors or whether the company serves customers from those sectors.
A small manufacturing company may think NIS2 does not concern it, but if it produces components for the medical, transport, energy or technology sector, it may receive customer requirements. A software house may not be an obvious essential entity, but if it maintains a system for a hospital, infrastructure operator, bank or managed service provider, NIS2 requirements may appear in the contract.
As a rule, NIS2 covers medium-sized and large entities in the sectors listed by the directive. In practice, employee count, turnover, balance sheet total and links with other entities must be checked.
For NIS2, it is especially important whether the company qualifies as a medium-sized enterprise or exceeds the thresholds for a medium-sized enterprise. Partner and linked enterprises must also be considered because the corporate group may affect qualification.
If the company has fewer than 50 employees and does not provide special services, it will often be outside the direct NIS2 scope. If the company has 50 to 249 employees and operates in a NIS2 sector, applicability assessment becomes a board-level task.
Some entities may be covered by NIS2 regardless of size. This is especially important for technology, telecommunications, domain, trust service and entities of special importance for society or the economy.
A small company should not automatically assume it is outside the scope. If it provides a service of special importance, operates in digital infrastructure or is essential for a critical customer service, deeper analysis is needed.
NIS2 divides entities into essential and important. The distinction matters for supervision and enforcement. For SMEs, the first priority is to determine whether the company is directly in scope at all.
An essential entity is generally an organization of higher importance, often larger and operating in high criticality sectors or meeting special criteria. Essential entities are usually subject to stronger supervision.
An important entity is an organization covered by NIS2 that does not qualify as essential. Risk management and incident reporting obligations still matter, but the supervisory regime may differ.
For most SMEs, the first question is: are we directly in scope? Only then is it useful to decide whether the status is essential or important.
This is the most important part for many SMEs. The company may not be directly an essential or important entity, but it may serve customers that are subject to NIS2. Then requirements will appear in contracts, security questionnaires, audits, procurement procedures and access requirements.
No. A business activity code may be a useful starting point, but it does not replace analysis of real activity. NIS2 concerns service types, sectors, the importance of activity, scale and the organization’s role. A company may have a broad activity code, but in practice provide a critical service to a regulated customer. It may also have a technology code but operate outside NIS2 scope.
The company operates in a NIS2 sector, meets the size threshold or falls under a size-independent exception. In this case, a fuller compliance and evidence programme is needed.
The company operates close to a regulated sector, has an unusual role, is part of a group, provides a service of special importance or its qualification depends on national rules.
This is a very common scenario for SMEs. The company may not be a formal regulated entity, but customers will require specific safeguards and evidence.
The company does not operate in a covered sector, does not meet the size threshold and has no regulated customers. However, changes in law, customers and business model should be monitored.
The software house may not be directly an essential or important entity if it does not meet NIS2 criteria. However, it may be an important supplier to a healthcare entity. The customer may require secure SDLC, testing, vulnerability management, SLA, incident reporting and subcontractor controls.
If the manufacturing customer is subject to NIS2, the IT provider may be covered by contractual requirements. This is especially likely if it has administrator access, manages backup, user accounts, networks or critical systems.
A typical small online shop will usually not be directly covered only because it operates online. However, scale, service type, possible platform status, customer data, payment providers and contractual requirements should be checked.
Such a company should perform an applicability assessment. It may be a medium-sized enterprise, a digital or ICT service provider and a supplier to regulated customers. Even if final legal qualification requires deeper analysis, customer requirements are highly likely.
Size alone may suggest no direct applicability. However, if the company supplies critical components to healthcare, energy, transport or large regulated customers, it may be affected through the supply chain.
If the assessment indicates that the company may be directly covered by NIS2, it should not wait for an audit or customer letter. A readiness plan should be prepared.
This is the most common scenario for SMEs. The company should prepare “NIS2 supplier readiness”, meaning the evidence pack and controls that regulated customers will expect.
A supplier that can quickly answer a NIS2 questionnaire, show evidence and explain its security model has an advantage when selling to larger customers.
A small company may be indirectly affected through customers or directly through an exception. Facts must be checked first.
Business activity codes do not show the full picture of services, customers, system access and importance in the supply chain.
Company size may depend on partner and linked enterprises. This can change qualification.
The company may be outside direct scope, but a regulated-sector customer may impose contractual requirements.
A verbal answer “NIS2 does not apply” is weak. A note or assessment with reasoning is needed.
Even if qualification needs clarification, the company can already implement the basics: MFA, backup, incident response, access review and training.
NIS2 is not only legal analysis. It also concerns cyber risk, suppliers, incidents, business continuity and evidence.
Larger companies will ask suppliers about safeguards. SMEs should have answers and evidence ready.
Even if the company is not directly subject to NIS2, basic safeguards are needed. They protect against ransomware, phishing, email takeover, data loss and customer relationship problems.
A SaaS company has 42 employees. It provides a document handling platform for customers in manufacturing, healthcare and local public administration. The board asks whether the company falls under NIS2 because the company itself is small and does not consider itself critical.
The assessment shows that direct applicability requires checking service details, size, customers and national rules. At the same time, it is clear that the company is indirectly affected by NIS2 because several customers may be regulated entities. Customers already ask about MFA, backup, incident reporting, security testing and subcontractors.
The company does not wait for final interpretation. Within 90 days, it prepares applicability assessment, customer evidence pack, MFA, restore test, incident response plan, customer incident reporting procedure and supplier assessment. This makes the company ready for customer requirements and further legal analysis.
ccyber.io helps SMEs determine whether NIS2 may affect the company directly or indirectly. We combine legal, technical, supplier and business perspectives. We do not stop at a “yes” or “no” answer. We prepare a practical action plan and evidence pack that helps in conversations with customers, auditors and insurers.
We can support your organization with:
The best first step is a NIS2 Applicability Workshop for SMEs. In a short workshop, the company can determine whether it may be directly covered, whether it is indirectly affected by customers and which minimum safeguards should be implemented regardless of final qualification.
No. A small company usually is not directly covered only because it operates a business. Sector, service, exceptions and customers must be checked.
No. A medium-sized company is covered when it operates in a sector or provides a service covered by NIS2 or meets special criteria. Size alone is not enough.
No. It may help, but it does not replace analysis of real activity, customers, services, data, system access and supply chain role.
Not always directly. However, it may be covered by customer requirements in contracts, audits, security questionnaires and incident reporting procedures.
Yes, if it meets sector, size or special service criteria. Even if it is not directly covered, it may be indirectly affected as a system supplier to regulated entities.
Prepare an applicability assessment, collect company, service and customer data, check NIS2 sectors and consult the conclusion with a lawyer or advisor. In parallel, implement basic safeguards.
Most often: MFA, backup, restore test, incident response plan, access review, training, vulnerability management, supplier security and incident reporting procedure.
Start with five things: service list, regulated customer list, company size data, analysis of size-independent exceptions and a quick review of basic safeguards.
The question “does my company fall under NIS2?” requires practical analysis. Checking company size or business activity code is not enough. Sector, service, exceptions, customers, capital links, access to data and systems, and current national rules must be assessed.
For many SMEs, indirect impact will be the most important issue. The company may not be a formal essential or important entity, but as a supplier to a regulated entity it will need to show safeguards, procedures and evidence.
The best rule is: do not wait for a customer questionnaire or inspection. Prepare an applicability assessment, implement the cybersecurity minimum and collect evidence that shows the company manages risk in practice.
Cybersecurity Funding: What Polish Companies Should Pay Attention to in 2026
In 2026, Polish companies should look at cybersecurity funding more broadly than just as a “grant for a firewall”. The biggest opportunities appear where cybersecurity is part of digitalization, automation, Industry 4.0, NIS2 compliance, CRA product readiness, operational resilience, cloud, AI, backup, access management and security testing. The best-prepared projects include a risk diagnosis, technical scope, budget, schedule, evidence of need, regulatory links and measurable business outcomes.
Prepared by: CCyber Editorial Team
In 2026, Polish companies should look for cybersecurity funding not only in programmes explicitly called “cyber”. In practice, cybersecurity may be part of projects related to digitalization, automation, digital transformation, Industry 4.0, digital product development, NIS2 compliance, Cyber Resilience Act readiness, operational resilience, cloud, AI, backup, identity management, security testing and training. The key is proper project preparation: risk diagnosis, system list, business justification, budget, schedule, measurable outcomes, regulatory links and evidence that the company can implement and maintain the purchased solutions. A list of tools alone is rarely enough. Funding institutions want to see purpose, impact and sustainability.
July 2026
2026 is important because companies face several trends at the same time. Customer, insurer, auditor and regulatory requirements are increasing. NIS2 increases pressure on cyber risk and supplier management. The Cyber Resilience Act requires software and hardware producers to prepare for digital product security. DORA affects the financial sector and ICT providers. AI accelerates digitalization, but also creates new risks. Ransomware and phishing still cause real downtime and losses.
This means cybersecurity is no longer only an IT cost. It becomes part of competitiveness, operational resilience, regulatory compliance and access to larger customers. For this reason, cybersecurity funding should be planned not as a “security project”, but as a company development project.
Polish companies often search for programmes using the phrase “cybersecurity grant”. This is too narrow. In practice, cybersecurity costs may appear in projects related to digitalization, automation, IT system implementation, cloud, AI, Industry 4.0, e-services, product security, regulatory compliance or operational resilience.
A good funding strategy therefore starts by finding the right programme objective, and then showing why cybersecurity is necessary to achieve that objective.
The European Funds portal indicates that company digitalization may be supported through grants, subsidies and preferential loans. In practice, support may cover ready-made solutions, licenses, technologies, software development work and pre-implementation advisory. This is important because cybersecurity is often part of secure digitalization, not a separate product.
Dig.IT is an example of an instrument where cybersecurity may appear as part of modern digital technology implementation. The programme is addressed to micro, small and medium-sized enterprises from the manufacturing and production services sector. Its description includes big data, AI and cybersecurity.
For manufacturing companies, cybersecurity is often connected with automation, system integration, production data, cloud, IoT, MES, ERP or SCADA systems. If a digitalization project increases dependency on digital systems, security should be included in the scope.
Loan instruments may be a good option for larger projects where cybersecurity is part of broad digital modernization. Loans for digital and green transformation are available to companies across Poland, and the digital part may include transformation toward Industry 4.0, automation, robotization, cloud, data analytics and digital systems.
EDIH is an especially important path for SMEs that are not ready for a large investment project yet. EDIHs offer audits, advisory, test before invest, training, skills development, funding support, networking and access to the innovation ecosystem. Cybersecurity is also part of the Polish EDIH offer.
In 2026, regional programmes should be monitored closely because some support for digitalization and SME growth is available at voivodeship level. The European Funds portal lists examples of regional loans and instruments for company digitalization.
The Digital Europe Programme is an important source of funding for cybersecurity, AI, digital skills and digital infrastructure projects. For many companies, this path will be more difficult than national programmes because it often requires a consortium, international partners, larger scope and alignment with programme objectives.
Not every cybersecurity project must be grant-funded. Larger projects may use repayable funding, preferential loans, guarantees, technology leasing or investment financing. In 2026, it will be especially important to connect cybersecurity with business resilience, technology, automation and digital sovereignty.
The application should not start with “we want to buy a tool”. It should start with a problem: ransomware risk, lack of tested backup, broad access, customer requirements, NIS2, CRA, OT risk or lack of secure product update process.
Cybersecurity is easier to finance when it is connected to a specific business outcome.
Not every cyber cost is eligible in every programme. Check the rules, cost catalogue, state aid, limits, own contribution, timelines, payment mechanism and sustainability requirements.
Funding institutions want to see results. For cybersecurity, practical indicators are useful.
A one-time purchase is not enough. The company must show who will maintain the solution, who will respond to alerts, who will update procedures, who will perform tests and how results will be sustained after funding ends.
If the company wants to buy a tool but does not show risk, purpose and outcome, the project may look like an ordinary operating cost.
Replacing one tool with another may be difficult to justify if it does not show improved resilience, compliance or maturity.
Grant-funded cybersecurity should have an owner inside the company, not only a technology supplier.
If the company does not show who will maintain the solution after implementation, the project may be evaluated weaker.
Not every programme finances everything. Even a good cyber project may not fit a programme if it does not meet its objective.
First check programme objective, cost eligibility and requirements. Only then define the technical scope.
Without an audit or risk assessment, it is difficult to justify why the project is needed.
“Improving cybersecurity” is too broad. It is better to identify specific risks, systems, controls and outcomes.
The project should show how the company will measure security improvement.
EDR, SIEM or backup implementation without people, processes and maintenance may not create lasting value.
A good budget requires time, option comparison and alignment between scope and programme rules.
NIS2, CRA, DORA, ISO 27001 and customer requirements may strongly justify a project. They should be shown.
A cybersecurity funding application requires technical, financial and business perspectives. One person rarely sees the full picture.
The company has ransomware risk, no tested backup, no MFA on critical accounts, customer requirements or regulatory duties.
Increase digital resilience, reduce downtime risk, meet NIS2 or CRA requirements, securely implement digital technologies.
Diagnosis, technology implementation, procedures, tests, training, documentation and evidence.
MFA on critical systems, restore test, shorter recovery time, closed vulnerabilities, more secure product, trained team.
Control owner, recurring tests, maintenance budget, procedures, board reporting.
For companies in scope of NIS2 or working with regulated entities, the project may cover risk management, incident response, backup, suppliers, training, logs, MFA, vulnerabilities and compliance evidence.
For software and hardware producers, the project may cover product security: SBOM, secure SDLC, testing, vulnerability management, update process, vulnerability disclosure and technical documentation.
For financial companies and ICT providers, the project may cover digital resilience, testing, supplier register, ICT contracts, incident reporting, backup, business continuity and auditability.
For companies preparing for certification, the project may cover risk register, policies, controls, audits, training, supplier management and evidence repository.
A manufacturing company has 120 employees. It plans to implement MES, ERP integration, automated production data collection and a B2B customer portal. Initially, the project is described as production digitalization. After analysis, however, it becomes clear that the new solution will increase dependency on cloud, industrial network, user accounts, API integrations and production data.
The company expands the project with cybersecurity: network segmentation, MFA for critical accounts, configuration backup, restore testing, monitoring, administrator training and incident procedure. The application does not describe cyber as an add-on, but as a condition of secure digital transformation.
This makes the project consistent: automation improves efficiency, while cybersecurity reduces downtime, data loss and operational error risk. The company also prepares indicators: number of systems covered by MFA, recovery time, number of trained people and restore test after implementation.
ccyber.io helps companies prepare cybersecurity projects for funding from grants, subsidies, loans and digitalization programmes. We combine security, regulatory, funding, technology and business perspectives.
We can support your organization with:
The best first step is a Cyber Funding Readiness Workshop. In a short workshop, the company can determine what it wants to finance, which funding sources fit the project, which costs may be problematic and how to prepare a project that makes business and technical sense.
It depends on the call. Often, cybersecurity is not a standalone objective, but it may be part of digitalization, digital transformation, Industry 4.0, regulatory compliance or digital product development.
It may be, but only if it fits the rules of the specific programme and is justified in the project. A tool purchase without diagnosis and outcome may be harder to defend.
Yes. EDIHs offer SMEs services related to digital transformation, including audits, advisory, test before invest, training, funding support and cybersecurity services.
Yes. ERP, MES, SCADA, IoT, AI, cloud and automation projects should include a security element because they increase the company’s dependency on digital technologies.
In many cases, elements of NIS2 readiness may be part of a digitalization, resilience, risk management, training, backup, incident or supplier project. The rules of the specific programme must be checked.
The most important elements are alignment with the programme objective, clear risk justification, measurable outcomes, realistic budget, schedule and sustainability of results.
Start with cybersecurity diagnosis, risk list, critical systems map and current call review. Then match the project to the funding source, not the other way around.
Yes. Calls are competitive and timelines change. The company should have a minimum plan funded from own resources, a loan or staged financing.
Cybersecurity funding in 2026 requires a broad view. Polish companies should look not only for programmes called “cyber”, but also for digitalization, transformation, Industry 4.0, EDIH, FENG, regional programmes, Digital Europe, loans and repayable financing.
The best cyber projects are specific: they come from diagnosis, address real risk, connect with business, regulations and technology, have measurable outcomes and a maintenance plan. The weakest projects are shopping lists without justification.
The best rule is: do not ask first “what grant is available?”. Ask which cyber risk you reduce, which business outcome you achieve and which funding source best fits that objective.
10 Employee Mistakes That Most Often Lead to Incidents
The most common incidents do not start with a spectacular hack, but with small mistakes: clicking phishing links, sharing MFA codes, reusing passwords, sending data to the wrong recipient, approving a fake payment, ignoring updates or failing to report suspicious activity. The goal of training should not be to scare employees, but to teach simple behaviors: stop, verify through a second channel, never share codes, report quickly, use approved tools and ask when something looks unusual.
Prepared by: CCyber Editorial Team
The most common employee mistakes leading to incidents are clicking phishing links, sharing passwords or MFA codes, reusing passwords, using unapproved tools, sending data to the wrong recipients, ignoring updates and alerts, bypassing payment procedures, working on personal devices without rules, failing to report suspicious activity and trusting messages, calls and requests that look “normal”. This is not about blaming people. Most mistakes come from time pressure, weak processes, unclear rules, poorly designed tools and training that teaches theory instead of behaviors. Good cyber awareness means the employee knows when to stop, how to verify a request, what not to share, where to report a problem and that reporting a mistake quickly is better than staying silent.
July 2026
Most employees do not make mistakes because they ignore security. Mistakes happen because everyday work requires speed, reacting to messages, serving customers, approving payments, handling documents, using many systems and making decisions under pressure.
Attackers exploit this. They do not always try to “hack the system”. They often try to convince a person to do something for them: click a link, share a code, open an attachment, approve a payment, share a file, reset a password or ignore an unusual signal.
This is why the awareness programme should be designed like a security system, not a one-time presentation.
Phishing is still one of the most common ways to start an incident. A message may imitate a bank, supplier, customer, courier, public office, IT team, board member or known platform. It no longer has to look like a classic suspicious email full of spelling errors. It may be well-written, context-aware and sent from a compromised account of a real person.
If a message requires login, payment, file download, data sharing or quick action, stop and verify it through a second channel.
The password is no longer the only attacker target. Increasingly, the target is an MFA code, approval in an authentication app or convincing the employee that “IT” needs a code to fix a problem.
Never share an MFA code and never approve a login you did not start.
Password reuse means a leak from one service can open access to other accounts. The problem grows when an employee uses the same password at work and privately.
One account, one password. Store company passwords only in the approved password manager.
An incident does not always begin with an attack. Sometimes it is a file sent by mistake, autocomplete selecting the wrong address, adding the wrong person to a thread, sharing a folder too broadly or pasting data into a public AI tool.
Before sending customer data, check the recipient, attachment, sharing scope and communication channel.
Payment attacks often do not require malware. A fake supplier email, compromised customer mailbox, phone call from someone pretending to be the board or a message asking for an “urgent transfer” may be enough.
A new bank account, urgent payment or unusual payment request always requires a second channel and a second person.
Employees often delay updates because they interrupt work. Sometimes they ignore alerts about suspicious login, account lockout, risky file or browser warnings. This may open the door to known vulnerability exploitation or account loss.
Do not disable safeguards and do not ignore warnings. If a message blocks work, report it instead of bypassing it.
An employee may use private email, private cloud storage, messenger, phone or an unapproved tool because it feels faster. This often creates Shadow IT and Shadow AI, meaning an area outside organizational control.
Process company and customer data only in approved tools and on devices that meet company rules.
This mistake is often not spectacular, but very common. An employee changes role, a project ends, a supplier finishes work, but access remains. A former employee still has an account, or someone from a previous project still sees customer data.
Access is needed only as long as there is a real business need.
This is one of the most dangerous mistakes because it turns a small incident into a large one. An employee clicked a link, shared a password, sent a file to the wrong recipient or approved suspicious MFA, but fears consequences and says nothing.
Fast reporting of a mistake protects the company. Hiding a mistake helps the attacker.
Social engineering attacks do not end with email. An employee may receive a call from “the CEO”, a message from “a supplier”, a voice recording, a messenger request, meeting invite or material that looks real. AI and deepfakes make such attempts more convincing.
An unusual request from an important person still requires verification. Authority does not cancel the procedure.
Effective training should not start with a slide explaining “what is phishing”. It should start with real workplace situations. Employees need to practice decisions they make in everyday processes.
Many companies measure only how many people clicked in a phishing simulation. This is not enough. The goal is behavior change, not only reducing the click rate.
After training, employees should know what to do, not only what to fear.
Finance, HR, sales, IT and the board have different risks. Training should reflect roles.
Public shaming reduces reporting. Fast reporting is critical.
It matters more whether employees report suspicious situations and whether procedures work.
If reporting is difficult, employees will delay it or not report at all.
If a manager demands speed over procedure, training will not work.
Attacks change. Training must include SMS, phone calls, QR codes, deepfakes, AI and compromised supplier accounts.
Training without phishing, payment, MFA and incident reporting procedures remains theory.
A services company has 60 employees. It uses Microsoft 365, CRM, invoicing system, cloud files and external accounting. After two incidents, a fake login link click and an attempted supplier bank account change, the board asks for “phishing training”.
A short review shows the problem is not only phishing. Employees do not know where to report suspicious messages. Finance has no second-channel procedure. MFA is enabled, but employees do not know what to do with an unexpected prompt. Some marketing accounts are shared. Managers push for quick task completion, even when a request is unusual.
The company prepares a 90-day programme. It introduces a reporting channel, trains employees using scenarios, creates a payment procedure, exercises suspicious MFA, reduces shared accounts and reports to the board not only clicks, but also reporting and response time. After three months, the number of reports increases, which initially looks like more problems. In practice, the company sees more risks earlier and can respond faster.
ccyber.io helps companies build cyber awareness programmes that change behavior, not only check a training box. We combine training, procedures, simulations, metrics and board reporting.
We can support your organization with:
The best first step is a Cyber Awareness Risk Workshop. In a short workshop, the company can identify which mistakes are most dangerous, which teams need role-based training and which procedures must be improved so employees can work safely.
It is not helpful to frame it that way. Employees are part of the security system. If they lack clear rules, simple tools and a reporting culture, they will make mistakes more often.
The most dangerous mistake is quickly following an unusual request without verification: clicking a link, sharing an MFA code, changing a supplier bank account or sending data to the wrong person.
They work best when combined with debriefing, reporting procedures and behavior-focused training. A simulation alone may only stress employees.
Shorter and more frequent is better. Starter training during onboarding, short quarterly reminders and role-based training for high-risk teams are more practical than one long presentation per year.
They should report immediately without fear of punishment. The company should change the password, review sessions, MFA, logins, mail rules and the possible attacker access scope.
Punishment usually reduces reporting. Clear rules, quick response, training and consequences only for deliberate, repeated procedure bypass are better.
Measure reports, response time, number of suspicious MFA prompts reported, second-channel effectiveness, data sending mistakes, exercise results and remediation actions.
Start with three things: a simple reporting channel, phishing and MFA training, and second-channel verification for payments, data and access changes.
The most common incidents often begin with everyday employee decisions: clicking a link, sharing a code, sending a file, approving a payment, using a private tool or ignoring an unusual signal. This does not mean the person alone is at fault. It means the company must design processes so that safe behavior is easy.
The key actions are role-based training, reporting procedure, MFA, password manager, second-channel verification, clear rules for data and tools, secure offboarding and a culture where fast mistake reporting is appreciated.
The best rule is: do not expect employees to be perfect. Give them clear rules, simple tools, permission to pause a process and a safe reporting path before a small mistake becomes a large incident.
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.
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.