Practical guides on EU cybersecurity regulations and compliance requirements for companies operating in Poland and the European Union. We explain NIS2, the Polish KSC Act, DORA, the Cyber Resilience Act, ISO/IEC 27001, NIST Cybersecurity Framework and related obligations in a clear, business-focused way.
NIS2 Penalties: What Management Boards Need to Know About the New Directive
NIS2 penalties may reach millions of euros or a percentage of global annual turnover, but the numbers alone are not the most important issue for the board. NIS2 moves cybersecurity into management accountability: the board must approve cyber risk management measures, oversee implementation, understand incident reporting duties and ensure compliance evidence. Penalties are not only about the incident itself, but about poor risk management, missing reporting, ignored supervisory orders or lack of real controls.
Prepared by: CCyber Editorial Team
NIS2 penalties can be very high, but management boards should not treat the directive only as a sanctions topic. NIS2 requires organizations in scope to have a real cyber risk management system, incident reporting procedures, supplier oversight, business continuity, training, access control, supply chain security and implementation evidence. The directive states that for essential entities the maximum administrative fine must be at least EUR 10 000 000 or 2% of total worldwide annual turnover, whichever is higher. For important entities, the threshold is at least EUR 7 000 000 or 1.4% of turnover. However, details in Poland must be checked in the national law implementing NIS2 because the directive is implemented through national legislation.
July 2026
NIS2 is a European Union directive. This means Member States must implement its requirements into national law. The directive defines a minimum level of requirements, including the minimum level of maximum fines, but the detailed control process, supervisory authority, procedures, national definitions and sanctions come from the implementing law in each country.
For the board, the practical conclusion is simple: knowing the directive text is not enough. Three things must be checked:
In Poland, NIS2 implementation is connected with the Act on the national cybersecurity system and its amendment. Therefore, in practice, the board should work with the current national law, not only with general NIS2 presentations.
For essential entities, the directive provides that infringements of cyber risk management and incident reporting obligations may be subject to administrative fines with a maximum level of at least:
For important entities, the directive provides a maximum penalty level of at least:
This wording is important. NIS2 defines the minimum level of maximum penalties that Member States must ensure. National rules may include their own procedures, conversions, periodic penalties, rules for public administration and additional supervisory measures.
Not every incident automatically means a penalty. Cybersecurity is not a promise that an incident will never happen. The regulation looks at whether the organization managed risk appropriately for its scale, sector, threats and impact on services.
The penalty risk increases when the company:
The key message for the board: the authority will not assess only that something happened. It will assess whether the company acted reasonably, proportionately, on time and with evidence.
NIS2 requires technical, operational and organizational measures. This is not only a firewall or antivirus. It is a full cyber risk management system.
Risk areas include, among others:
NIS2 introduces strict deadlines for reporting significant incidents. In simplified terms, an organization should prepare for:
The practical problem is that the company must have a process that works under stress. It is difficult to prepare a good notification within 24 hours if nobody knows in advance who decides, who gathers facts, who contacts the CSIRT, who informs the board and who manages communication.
NIS2 requires management bodies to approve cyber risk management measures and oversee their implementation. The board cannot limit itself to saying “IT handles this”.
In practice, the board should have:
The risk of sanctions increases when the company receives recommendations, orders or audit findings and does not act. NIS2 provides a broad set of supervisory measures, not only financial fines.
In practice, the authority may require, among other things:
Evidence matters in NIS2 compliance. A company may have good technical actions, but if it cannot document them, it will be harder to defend its approach before an authority, auditor or customer.
Evidence may include:
NIS2 clearly raises cybersecurity to board level. This does not mean every board member must configure systems. It means the board must understand risk, approve direction, oversee implementation and provide resources.
NIS2 requires Member States to ensure that it is possible to hold responsible persons or legal representatives of essential entities liable for breaches of their duties to ensure compliance. The directive also provides for the possibility of a temporary prohibition from exercising managerial functions in certain cases involving essential entities, in accordance with national law and procedural safeguards.
This does not mean that every outage or incident automatically leads to personal liability for a board member. It does mean, however, that the board should treat cybersecurity as an oversight obligation, not only a technical IT task.
NIS2 distinguishes essential and important entities. This distinction affects, among other things, supervision, authority approach and maximum penalty levels.
These are usually organizations in sectors of highest criticality, where disruption may have a particularly important impact on society, economy, public safety or continuity of important services.
These are organizations in scope that must also meet NIS2 requirements, but are subject to a different supervisory model and lower minimum thresholds for maximum fines.
The board should not guess the category. It should request a formal applicability assessment covering sector, company size, type of services, group dependencies, country of operation and national rules.
NIS2 covers a broad range of sectors. The European Commission states that the directive establishes a framework for 18 critical sectors across the European Union.
The regulatory scope may depend on national details, organization size and service type. That is why an applicability assessment should be the first step.
After a serious incident, an authority or customer may ask not only what happened. Questions usually focus on how prepared the organization was before the incident.
The worst answer is: “we do not know”, “there was no owner”, “there was no procedure”, “we did not test it”, “we have no evidence”.
The best answer is: “we had a process, we know the scope, we reported on time, we have logs, we have a report, we have board decisions, we have a remediation plan and we can show evidence”.
First, determine whether the company is subject to the regulation and in which role.
The assessment should include:
Evidence to prepare: NIS2 applicability assessment report and board decision on next steps.
The company should compare the current state with NIS2 requirements. This should be about practical gaps, not only a list of documents.
Check:
Evidence to prepare: NIS2 gap analysis with priorities and action plan.
The board needs to see cybersecurity as business risk. The risk register should show impact on services, customers, revenue, business continuity and compliance.
The register should include:
Evidence to prepare: cyber risk register approved or periodically reviewed by the board.
The company must know how to act in the first hours of an incident. NIS2 requires fast reporting, so the process must be exercised.
The plan should state:
Evidence to prepare: incident response plan and tabletop exercise report.
NIS2 strongly emphasizes supply chain security. The company should know which suppliers are critical and what risks they create.
The supplier programme should include:
Evidence to prepare: supplier register and supply chain risk assessment report.
The board should receive a regular, understandable report. It does not need excessive technical detail, but it must show risk, decisions and progress.
The report should cover:
Evidence to prepare: recurring NIS2 dashboard for the board.
IT can implement many controls, but accountability concerns the whole organization: board, risk, legal, suppliers, finance, HR, communication and business continuity.
Penalties matter, but a better question is: can the company ensure service continuity, report an incident on time and show evidence of risk management?
The company assumes NIS2 does not apply because it is not large critical infrastructure. The NIS2 scope is broader than previous rules.
Without evidence, it is hard to show that measures were implemented, tested and supervised.
Reporting deadlines are short. Without an exercise, the company may lose valuable hours defining roles and communication channels.
ICT suppliers, cloud providers, software providers, integrators and outsourcing companies may create significant risk.
NIS2 requires management body members to have the knowledge needed to understand cyber risk and risk management practices.
The board may accept risk, but it should do so consciously, based on data, not through lack of decision.
A technology company provides services to healthcare and industrial customers. The board initially assumes NIS2 mainly concerns critical infrastructure operators, so the topic is postponed. After analysis, it turns out the company may be an important supplier in the chain of services covered by customer requirements, and some NIS2 obligations will affect contracts, audits and security expectations.
The company performs a gap analysis. The largest gaps are lack of a formal risk register, untested incident response, no recurring access review, weak backup evidence, no supplier assessment and no cyber reporting to the board. The IT team had many good practices, but they were not structured or documented.
The board approves a 90-day plan: applicability assessment, risk register, tabletop, MFA for critical accounts, restore test, supplier programme and dashboard. After three months, the company is not “ready for everything”, but it has evidence, owners and a plan. This significantly reduces sanction risk and improves business resilience.
ccyber.io helps boards and security teams prepare organizations for NIS2 in a practical, measurable and evidence-based way. We do not start from documents for documents. We start from applicability, risk, critical services, incidents, suppliers and board accountability.
We can support your organization with:
The best first step is a NIS2 Board Readiness Workshop. In a short workshop, the company can determine whether it is subject to NIS2, what the key risks are, what the board must know, which decisions are needed and which actions should start immediately.
For essential entities, the directive sets a maximum fine level of at least EUR 10 000 000 or 2% of worldwide annual turnover. For important entities, at least EUR 7 000 000 or 1.4% of turnover. Details depend on national law.
Yes. NIS2 requires management bodies to approve cyber risk management measures, oversee implementation and be potentially liable for infringements, according to national law.
Not every incident automatically leads to a fine. The risk increases when the company lacks adequate measures, fails to report, ignores recommendations or cannot show evidence.
An essential entity usually has higher criticality and is subject to stronger supervision and higher fine levels. An important entity must also meet requirements, but is subject to a different supervision model and lower penalty thresholds.
First, request a NIS2 applicability assessment, then gap analysis, risk register, action plan, incident reporting plan and governance dashboard.
Yes. The directive requires members of management bodies to follow training that allows them to understand cyber risks and assess risk management practices.
ISO 27001 can help significantly because it organizes information security management, risk, controls and continual improvement. However, it does not automatically replace NIS2 analysis, incident obligations and national requirements.
Start with four things: applicability assessment, risk register, incident plan with 24 and 72-hour deadlines, and board report with priorities and budget.
NIS2 penalties are high, but the biggest change is not only the level of sanctions. The biggest change is that cybersecurity becomes a formal topic of board oversight, evidence and organizational accountability.
The board should understand whether the company is in scope, which services are critical, what the top risks are, whether the company can report an incident on time, whether suppliers are under control and whether evidence of implemented security measures exists.
The best response to penalty risk is not panic or documentation alone. The best response is a practical NIS2 readiness programme: applicability assessment, gap analysis, risk register, incident response, suppliers, training, tests, metrics and recurring board oversight.
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.
DORA for IT and Technology Providers: What You Need to Know
DORA primarily applies to financial entities, but it has a strong impact on IT, cloud, SaaS, cybersecurity, data center, outsourcing and technology providers. Even if a provider is not directly supervised, financial clients will require DORA-ready contracts, security evidence, incident support, testing, audit rights, subcontractor controls and exit planning.
Prepared by: CCyber Editorial Team
DORA, the Digital Operational Resilience Act, is an EU regulation on digital operational resilience in the financial sector. For IT and technology providers, the key point is that DORA transfers many requirements into relationships with financial clients. A bank, insurer, investment firm, fintech or other financial entity will require clear contracts, SLAs, incident support, continuity testing, audit rights, information about data locations, subcontractor controls, exit plans and security evidence.
July 2026
DORA is an EU regulation on digital operational resilience in the financial sector. Its goal is to ensure that financial entities can prevent ICT disruptions, detect incidents, respond to them, recover operations and control risks related to technology providers.
DORA covers five main areas:
For IT providers, the fourth area is the most important: ICT third-party risk management. This is what makes financial clients require more detailed contracts, audits, evidence, reports and subcontractor controls.
The answer depends on provider type and service role. DORA directly regulates financial entities, but it also creates an oversight framework for critical ICT third-party service providers. In addition, most providers will feel DORA through financial client requirements.
This is the most common case. The provider is not directly supervised by European supervisory authorities, but its financial client must comply with DORA. In practice, the client will transfer requirements into the contract, questionnaire, audit and supplier management process.
The provider must be ready for questions about:
If the provider’s service supports a critical or important function, requirements will be stronger. The client will need fuller SLAs, reporting, continuity tests, audit conditions, exit plans and better subcontractor controls.
Examples:
The largest and systemically important ICT providers may be designated as critical. They may then fall under EU oversight by the relevant European supervisory authorities. This mainly concerns large providers whose services are important for many financial entities and may create concentration risk.
For most smaller providers, the practical conclusion is simple: even without direct supervision, they must be ready for DORA requirements in customer contracts and audits.
DORA changes how the financial sector buys, evaluates and supervises technology services. An IT provider will no longer be assessed only on price, features and experience. It will also be assessed on resilience, security, evidence, procedures and ability to cooperate during incidents.
DORA may affect:
A provider that has evidence, procedures and answers ready can shorten sales cycles and look more credible. A provider with nothing prepared will slow down procurement and may lose to competitors.
Cloud, data center, hosting, infrastructure-as-a-service and platform-as-a-service providers will be asked about availability, data location, resilience, subcontractors, testing, physical security, encryption, backups and exit planning.
SaaS companies serving banks, insurers, fintechs or investment firms must prepare evidence of application security, business continuity, incident support, logging, access control and update management.
SOC, EDR, SIEM, IAM, PAM, vulnerability scanning, security testing and incident response providers often support critical areas. Their clients may require especially high availability, clear responsibility split, escalation procedures and audit rights.
Software houses and maintenance teams will be asked about secure development, vulnerability management, access to client environments, code repositories, subcontractors, testing and incident response.
Payment, AML, KYC, core banking, CRM, transaction, accounting and reporting system providers may have a major impact on critical functions of a financial client. Requirements will usually be more detailed.
DORA puts strong emphasis on contracts with ICT providers. Contracts should clearly define the rights and obligations of both parties and allow the financial entity to manage provider risk.
The contract should clearly describe which ICT functions and services the provider delivers. For the provider, this means having a precise service catalogue, responsibility boundaries and technical dependencies.
The client may require information on the countries or regions where the service is delivered and where data is processed or stored. Location changes may require advance notice.
The contract should cover availability, authenticity, integrity and confidentiality of data, including personal data. The provider must be able to show technical and organizational controls.
The financial client will need service level descriptions, availability parameters, response times, escalation rules, reporting and corrective actions when service levels are not met.
The provider should support the client when an ICT incident is related to the service delivered by the provider. In practice, emergency contacts, response times, escalation mode and rules for sharing technical information must be prepared.
The contract may require cooperation with competent authorities and persons appointed by them. The provider should know who handles such requests and how to protect confidentiality of other clients.
The financial client may require rights of audit, inspection, access to documentation, reports and evidence. The provider must prepare an audit model that is operationally feasible and does not compromise the security of other customers.
If the provider uses subcontractors, the client will want to know scope, locations, risks and change rules. For critical or important functions, subcontractor control will be particularly important.
The financial client must be able to terminate the service or move it to another provider without excessive risk. The provider should have a description of data return, migration, transitional support and data deletion after termination.
The provider should have a clear description of the services it offers to financial clients. It is important to distinguish what the provider does, what the client does and what subcontractors are responsible for.
Evidence to prepare: service catalogue, shared responsibility model and service boundary description.
The provider should have a ready package of answers to client questions. This shortens sales cycles and reduces chaos in every security questionnaire.
The package may include:
Evidence to prepare: DORA-ready security pack for financial clients.
Financial entities have ICT incident obligations. The provider must quickly provide information if an incident concerns the service delivered to the client.
The procedure should define:
Evidence to prepare: client incident notification procedure and first notification template.
The financial client will want to know whether the provider can maintain or recover the service after an outage, cyberattack, data center loss, failed deployment or subcontractor issue.
Prepare:
Evidence to prepare: BCP, DRP and recovery test report.
The provider should know its subcontractors and be able to explain how they affect the service for a financial client. This includes cloud, hosting, technical support, security services, monitoring tools, development subcontractors and data providers.
The register should include:
Evidence to prepare: subcontractor register and change approval procedure.
The provider should define in advance how it handles audits by financial clients. Without this, every audit becomes a separate organizational crisis.
The audit model should define:
Evidence to prepare: client audit procedure and standard evidence package.
The client may send a DORA addendum extending the contract with requirements on audit, incidents, subcontractors, data location, SLA and exit planning.
The questionnaire may include dozens or hundreds of questions about information security, business continuity, access, monitoring, vulnerabilities, cloud, subcontractors and incident response.
The client may require audit rights, access to reports, inspections or assurance from an independent auditor.
The client may require fast incident notification and status updates. The provider must have a process that can provide information without chaos and without breaching other clients’ confidentiality.
The client may require a list of material subcontractors, data location information and a right to object or be notified about subcontractor changes.
The client may require a description of how to terminate the service, recover data, migrate the service, delete data and receive transition support.
For a provider, the most important question is whether its service supports a critical or important function of the financial client. If it does, requirements will be stronger.
A service may be critical or important if its failure, unavailability, security breach or incorrect operation may materially affect:
The provider should ask the client for service classification. Without this information, it is difficult to determine the right level of requirements, evidence, SLA and audit.
DORA can be a problem or a sales advantage. A provider that answers chaotically, does not know its subcontractors and has no evidence will slow down procurement. A provider with a ready DORA-ready package may look more mature than competitors.
DORA-ready can support sales because it:
For technology companies serving the financial sector, DORA is not only an obligation. It is also an opportunity to organize the offer and improve market positioning.
DORA formally applies to financial entities, but technology providers are part of their operational risk. A financial client will transfer requirements to the provider through contracts, audits and questionnaires.
If the provider searches for documents from scratch for every questionnaire, the sales process will be slow and chaotic. The evidence pack should be prepared in advance.
A financial client will ask not only about the provider, but also about its subcontractors. No subcontractor register is one of the most common gaps.
SLA without continuity and recovery testing can be risky. The provider should know whether declared RTO and RPO values are realistic.
An incident on the provider side may trigger obligations for the financial client. The provider must be able to provide information quickly and in an organized way.
A client may require audit rights, but the provider must protect the security and confidentiality of other clients. A model for evidence sharing, remote audits and inspections is needed.
DORA requires financial entities to be able to exit provider relationships. A provider without a data return and migration plan will be seen as higher risk.
A SaaS company provides a sales process platform for banks and fintechs. For several years, clients mainly asked about features, availability and personal data protection. After DORA, they start sending contract addenda, subcontractor questionnaires, exit plan questions, audit rights, RTO, RPO and incident notification requirements.
The sales team sends questions to IT, IT sends them to legal, legal sends them to the board, and answers are created manually every time. The sales process slows down, and one large client pauses contract signature until evidence is completed.
The company prepares a DORA-ready programme. It creates a service catalogue, subcontractor register, security evidence package, client notification procedure, exit plan and standard questionnaire answers. It also tests service recovery and documents the result.
After 90 days, client discussions are faster. The company no longer answers every question from scratch. It has a ready evidence pack, clear responsibility boundaries and a stronger position in negotiations with the financial sector.
ccyber.io helps IT and technology providers prepare for DORA requirements in a practical, sales-oriented way aligned with financial client expectations. It is not only about documents. It is about being able to pass due diligence, sign contracts, handle audits and provide evidence of operational resilience.
We can support your organization with:
The best first step is a short DORA readiness workshop for providers. It helps determine which services are most exposed to DORA requirements, what evidence is already available, what is missing and how to prepare a package for financial clients in the first 30, 60 and 90 days.
Yes, but most often indirectly. DORA imposes obligations mainly on financial entities, which must manage ICT provider risk. This is why IT providers receive requirements through contracts, audits, questionnaires and due diligence.
No. Direct oversight applies to critical ICT third-party providers designated under DORA. Most providers will not be directly supervised, but they will need to meet financial client requirements.
Start with a service catalogue, financial client list, subcontractor register, data location description, MFA status for administrators, incident procedure, business continuity plan and security questionnaire answer pack.
It is a function whose disruption may materially affect the financial entity, its clients, regulatory compliance or continuity of services. The provider should determine with the client whether the service supports such a function.
DORA requires contracts with ICT providers to contain appropriate access, inspection and audit rights, especially for services supporting critical or important functions. The provider should prepare a practical audit handling model.
In practice, yes, especially where subcontractors affect the financial client’s service or a critical or important function. The client will require information about service scope, location, risk and changes.
Not always. ISO 27001 helps as evidence of an information security management system, but DORA also covers detailed contract requirements, incidents, continuity, subcontractors, testing and exit planning.
A provider can prepare a DORA-ready security pack, shorten questionnaire response time, pass due diligence more easily and show financial clients that it understands their regulatory obligations and operational risk.
DORA is not only a regulation for banks and insurers. For IT and technology providers, it changes how services are sold, contracted, audited and maintained for the financial sector.
The most important step is preparation before the client asks. A provider that knows its services, subcontractors, SLAs, data locations, incident procedures, recovery tests and audit model will be much better prepared for financial client discussions.
DORA-ready does not mean having only a document. It means the ability to prove that the service is secure, resilient, monitored, recoverable, auditable and possible to exit without paralyzing the client. For technology providers, this is not only an obligation. It is a competitive advantage in the financial sector.
NIS2 vs ISO/IEC 27001 vs NIST CSF: Which Approach Should You Choose?
NIS2, ISO/IEC 27001 and the NIST Cybersecurity Framework are not the same. NIS2 is a legal requirement for regulated entities, ISO/IEC 27001 is a certifiable information security management system, and NIST CSF is a flexible framework for assessing and communicating cyber risk. In practice, mature companies combine these approaches instead of choosing only one.
Prepared by: CCyber Editorial Team
NIS2, ISO/IEC 27001 and NIST CSF serve different purposes. NIS2 answers: what legal obligations must an essential or important entity meet? ISO/IEC 27001 answers: how do we build and certify an information security management system? NIST CSF answers: how do we assess, organize, prioritize and communicate cyber risk? For most companies, the best decision is not to choose only one approach, but to combine them: NIS2 as the requirement, ISO/IEC 27001 as the management system and evidence base, and NIST CSF as the risk map and action roadmap.
July 2026
NIS2 is the European Union directive on a high common level of cybersecurity across the EU. It applies to organizations operating in specific sectors and categories, including essential and important entities. In Poland, NIS2 requirements are connected with the National Cybersecurity System Act, known as KSC.
NIS2 focuses on ensuring that regulated organizations have appropriate and proportionate technical, operational and organizational measures to manage cyber risk and reduce the impact of incidents.
NIS2 covers, among other areas:
NIS2 should be the starting point if the company:
Key point: NIS2 says what the organization must achieve as a regulatory obligation. It does not always provide a full implementation manual. ISO/IEC 27001 and NIST CSF can help with that.
ISO/IEC 27001 is an international standard for an information security management system, or ISMS. It helps an organization establish, implement, maintain and improve an information security management system using a risk-based approach.
ISO/IEC 27001 is especially important when a company needs:
ISO/IEC 27001 helps answer the question: does the company have a system that regularly identifies risks, selects controls, documents decisions, monitors effectiveness and continuously improves?
ISO/IEC 27001 should be the starting point if the company:
Key point: ISO/IEC 27001 is an excellent tool for building evidence and a management system. However, the certificate alone does not automatically guarantee full NIS2 compliance or strong technical resilience. The scope, risks and real controls must be defined properly.
The NIST Cybersecurity Framework, or NIST CSF, is a framework for cybersecurity risk management. Version 2.0 organizes cybersecurity around six functions: Govern, Identify, Protect, Detect, Respond and Recover.
In practice, NIST CSF helps a company:
NIST CSF is not a certificate. Its strength is simplicity, flexibility and language that works well in board-level discussions.
NIST CSF should be the starting point if the company:
Key point: NIST CSF works very well for assessment and prioritization. It does not replace NIS2 legal obligations or an ISO/IEC 27001 certificate when a customer or regulator requires one.
If the company is subject to NIS2 or KSC, there is no point starting with the question whether to choose ISO or NIST. First, determine the legal obligations.
In practice, this means:
Best decision: NIS2 as the target requirement, ISO/IEC 27001 and NIST CSF as implementation tools.
If the company receives customer security questionnaires, participates in tenders, sells to large organizations or must demonstrate a formal management system, ISO/IEC 27001 will often be the clearest business signal.
ISO/IEC 27001 helps organize:
Best decision: ISO/IEC 27001 as the management system and certifiable evidence, NIST CSF as the prioritization tool, NIS2/KSC as legal requirements to map.
If the company does not know where to start, has many disconnected security actions, lacks clear priorities and wants to show the board the risk picture quickly, NIST CSF is a very good starting point.
NIST CSF helps build:
Best decision: NIST CSF as the first map and roadmap, then ISO/IEC 27001 if a system and certificate are needed, and NIS2/KSC if the company is regulated.
The biggest mistake is creating three separate programmes: one for NIS2, one for ISO/IEC 27001 and one for NIST CSF. This leads to duplicate documents, chaos, team fatigue and unclear accountability.
A better approach:
In practice, a company can use NIST CSF for the first assessment, ISO/IEC 27001 to build the management system and NIS2/KSC as the legal requirement list that must be met and evidenced.
First determine whether the organization is an essential entity, important entity, supplier to such an entity or a company that may receive contractual requirements linked to NIS2.
Evidence to prepare: NIS2/KSC applicability assessment and board decision on the organization’s status.
NIST CSF works well for quickly checking where the company is now and where it should be. The assessment should cover governance, asset identification, protection, detection, response and recovery.
Evidence to prepare: NIST CSF current profile, target profile and gap list.
If the company needs a durable system, evidence and certification, ISO/IEC 27001 can become the organizational backbone. NIS2 requirements and NIST CSF results should then be included in risk registers, policies, plans and reviews.
Evidence to prepare: ISMS scope, security policy, risk register, risk treatment plan and statement of applicability.
Every NIS2 requirement should have an owner, control, evidence and status. It is not enough to say that the company has “procedures”. The company must show which procedures exist, who executes them and what evidence is created.
Evidence to prepare: NIS2/KSC, ISO/IEC 27001 and NIST CSF requirements matrix.
The roadmap should be one, even if the sources of requirements are many. Actions should have business priority, owner, deadline, cost, risk and completion evidence.
Evidence to prepare: 90-day and 12-month cybersecurity roadmap.
Best choice: NIS2/KSC as the legal obligation, ISO/IEC 27001 as the management system, NIST CSF as assessment and board reporting.
Priority:
Best choice: NIST CSF as a quick start, ISO/IEC 27001 as a direction if customers require certification, NIS2/KSC as contractual requirements if the company supplies regulated entities.
Priority:
Best choice: ISO/IEC 27001 as system and customer evidence, NIST CSF as roadmap, NIS2/KSC as customer requirement or own qualification if the company provides regulated services.
Priority:
Best choice: NIS2/KSC if the company is regulated, NIST CSF for governance and roadmap, ISO/IEC 27001 for the management system, and IEC 62443 as a specialist approach for OT.
Priority:
Best choice: DORA as sector regulation, NIS2/KSC if applicable, ISO/IEC 27001 as ISMS, NIST CSF as risk and reporting framework.
Priority:
A framework is a tool. The goal is reducing risk and meeting obligations. The company should not implement a standard for the standard’s sake.
ISO/IEC 27001 can help significantly, but a certificate does not automatically mean that the organization meets all NIS2 or KSC obligations. Requirement mapping is needed.
NIST CSF is not a certificate. It is excellent for assessment, prioritization and communication, but does not replace ISO/IEC 27001 certification if a customer requires it.
A separate NIS2 project, separate ISO project and separate NIST project create chaos. One map, one risk register and one roadmap are better.
Documentation matters, but it will not stop ransomware, enable MFA or recover a system after failure. Every document should lead to a control, evidence or decision.
NIS2, ISO/IEC 27001 and NIST CSF all require board involvement. Cybersecurity cannot be only the IT administrator’s task.
During audits and customer discussions, it is not enough to say that the company has backup, MFA or training. A report, log, register, confirmation or test result must be shown.
A technology company sells SaaS services to customers in manufacturing and infrastructure. Customers begin asking about NIS2, ISO/IEC 27001, backup, MFA, security testing and incident response. The board wants to know whether the company should “implement NIS2, ISO or NIST”.
The analysis shows that the company is not directly an essential or important entity, but it is a supplier to NIS2-covered customers. It does not have a registration obligation as a regulated entity, but it will receive contractual requirements from customers. At the same time, several large customers expect ISO/IEC 27001 certification within 12 months.
The best decision is not choosing one approach. The company uses NIST CSF for quick assessment and roadmap, ISO/IEC 27001 as the target management system and NIS2 as the map of requirements that customers will pass down to suppliers.
Within 90 days, the company prepares a NIST CSF current profile and target profile, implements MFA, tests backup, organizes the risk register, prepares an incident response plan and creates a customer requirements matrix. After 12 months, it passes ISO/IEC 27001 certification with evidence already aligned with expectations of NIS2-covered customers.
ccyber.io helps companies choose the right approach to NIS2, ISO/IEC 27001 and NIST CSF without creating three separate projects. We focus on practical implementation, evidence, business risk and readiness for audits and customer requirements.
We can support your organization with:
The best first step is a short decision workshop: NIS2, ISO/IEC 27001 or NIST CSF. It helps determine what is a legal obligation, what is a customer requirement, what is a governance tool and which roadmap will give the company the best result in the shortest time.
No. NIS2 is a legal regulation, ISO/IEC 27001 is a certifiable information security management system, and NIST CSF is a framework for managing and communicating cyber risk.
Not automatically. ISO/IEC 27001 can help significantly, but the company must map specific NIS2 or KSC obligations to its processes, controls and evidence.
Not in the usual sense. NIST CSF is used for assessment, communication and prioritization. It is not a certification standard like ISO/IEC 27001.
If the company is subject to NIS2 or KSC, start with regulatory obligations. If a customer requires a certificate, start with ISO/IEC 27001 readiness. If the company has chaos and no priorities, start with a NIST CSF assessment.
It depends on customers, risk and budget. A small company can start with NIST CSF or selected ISO/IEC 27001 elements and plan certification only when sales or the market require it.
It may affect them indirectly. Even if a supplier is not directly an essential or important entity, customers covered by NIS2 may require specific security controls and evidence.
Yes. NIST CSF works well for discussing risk, priorities, maturity, gaps and roadmap. The Govern function in version 2.0 particularly strengthens governance and accountability.
Create one requirements and evidence matrix. One risk register, one roadmap and one board report can support NIS2, ISO/IEC 27001 and NIST CSF at the same time.
NIS2, ISO/IEC 27001 and NIST CSF address different needs. NIS2 creates legal obligations and urgency. ISO/IEC 27001 provides a management system and certifiable evidence. NIST CSF helps assess maturity, set priorities and discuss cyber risk with the board.
For most companies, the best decision is not choosing one approach and rejecting the rest. The best decision is intelligently combining these sources into one cybersecurity programme.
The practical order is simple: check NIS2/KSC obligations, assess maturity using NIST CSF, build the management system using ISO/IEC 27001, then maintain one roadmap, one evidence matrix and one cyber risk report for the board.
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.