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 vs ISO 27001: How to Combine Requirements into One Practical Plan
NIS2 and ISO 27001 should not be treated as two separate projects. NIS2 defines regulatory duties: cyber risk management, incident reporting, board oversight, supplier security and business continuity. ISO 27001 provides a management system that helps organize these duties: scope, risks, Statement of Applicability, controls, audits, management reviews and corrective actions. The best approach is one requirements map, one risk register, one action roadmap and one evidence repository.
Prepared by: CCyber Editorial Team
NIS2 and ISO 27001 are best combined into one practical plan instead of being managed as two parallel projects. NIS2 defines the regulatory duties a company must meet: cyber risk management, technical and organizational measures, incident reporting, board oversight, supplier security, business continuity and compliance evidence. ISO 27001 provides the management approach: scope, information security policy, risk assessment, risk treatment plan, Statement of Applicability, internal audits, management reviews and corrective actions. A shared plan should have one applicability assessment, one risk register, one control map, one roadmap, one evidence matrix and one board report.
July 2026
NIS2 and ISO 27001 are often discussed together, but they are not the same. The simplest distinction is: NIS2 says that certain organizations must meet cybersecurity requirements under law. ISO 27001 says how to build an information security management system that manages risk in an organized, auditable and repeatable way.
The best approach is not “NIS2 or ISO 27001”. The better question is how to use ISO 27001 as a management system that helps meet and prove NIS2 requirements.
Not automatically. An ISO 27001 certificate may be strong evidence of organizational maturity, but it does not by itself mean full NIS2 compliance. The reasons are simple.
The company still needs to check whether it is subject to NIS2, in which country, in which sector, in which role and whether it is essential or important.
NIS2 implementation details come from national law. In Poland, current rules connected with the national cybersecurity system must be checked.
NIS2 has specific incident reporting requirements. The company needs a procedure and templates for the first hours of an incident.
A certificate may cover only part of the organization. If the ISO 27001 scope does not include critical services, regulated systems or suppliers relevant to NIS2, it must be expanded or supplemented with separate mapping.
It provides the most value when it covers real risks, current assets, suppliers, incidents, tests, audits and corrective actions. A certificate without current evidence may not be enough in a NIS2 audit.
The best model is a layered approach: NIS2 as the regulatory duty layer, ISO 27001 as the management system layer, ISO 27002 as the control layer and evidence as the audit layer.
The most important practical tool is the requirements map. It is a table showing which NIS2 requirement is supported by which ISO 27001 element, which control the company uses and which evidence confirms operation.
NIS2 area: incident handling.
ISO 27001 element: planning, operation, performance evaluation, corrective action.
Controls: incident response procedure, logs, roles, escalation, exercise.
Evidence: response plan, tabletop report, incident register, remediation action list.
NIS2 requires an answer on whether the company is in scope. ISO 27001 requires defining the scope of the information security management system. These two activities should be combined.
Evidence: applicability assessment, management system scope, critical service map, board decision.
NIS2 emphasizes management accountability for approving and overseeing cyber risk management measures. ISO 27001 requires leadership, roles, responsibilities and management review.
Evidence: board minutes, risk reports, budget decisions, management review.
This is the shared core of NIS2 and ISO 27001. Without a risk register, the company cannot show why selected controls are adequate and proportionate.
Evidence: risk methodology, risk register, risk treatment plan, risk acceptance decisions.
The ISO 27001 Statement of Applicability can become the main NIS2 control map if extended with regulatory requirements.
Evidence: Statement of Applicability, NIS2 map, control list, implementation status.
ISO 27001 organizes incident management. NIS2 adds specific duties to report significant incidents within short timelines.
Evidence: incident procedure, notification templates, exercise report, incident register.
NIS2 requires business continuity and recovery after incidents. ISO 27001 helps embed this into management, testing and audits.
Evidence: business continuity plan, backup report, restore test report, action list after test.
NIS2 strongly emphasizes supplier risk. ISO 27001 and ISO 27002 help organize supplier relationships, contractual requirements and reviews.
Evidence: supplier register, risk assessments, contracts, supplier access review, exit plan.
Access control is one of the most important areas for NIS2 and ISO 27001. A compromised administrator account can undermine the whole security programme.
Evidence: MFA report, administrator list, access review report, offboarding checklists.
NIS2 refers to vulnerability handling and security in acquisition, development and maintenance of systems. ISO 27001 helps embed these actions into risk, change and evidence processes.
Evidence: vulnerability report, remediation list, retest, risk acceptances.
NIS2 requires awareness and board accountability. ISO 27001 requires competence, awareness, internal audits, management reviews and corrective actions.
Evidence: training plan, participant lists, internal audits, management review, corrective action register.
Determine whether the company is subject to NIS2, in which sector, role and country. In Poland, check current national rules connected with KSC.
Result: applicability report and board decision.
Determine whether the current or planned ISO 27001 scope covers all services, systems, locations and suppliers relevant to NIS2.
Result: management system scope and critical services map.
Compare NIS2 requirements with the current ISO 27001 status, controls, procedures and evidence.
Result: gap analysis with priorities.
Build one shared cyber risk register. Do not create one register for NIS2 and another for ISO 27001.
Result: risk register with owners, impact, controls and action plan.
Add columns to the Statement of Applicability: NIS2 requirement, owner, evidence, status, gap and remediation action.
Result: Statement of Applicability as NIS2 and ISO 27001 control map.
Define actions for 30, 60, 90 days and 12 months. Prioritize gaps that reduce the highest risk and matter most for audit.
Result: roadmap with deadlines, owners and budget.
Complete key procedures: incidents, reporting, backup, access, suppliers, vulnerabilities, training and corrective actions.
Result: procedure set used in practice.
Run restore test, incident exercise, access review and reporting path test.
Result: test reports, gap list and remediation actions.
Assess critical suppliers, add security requirements to contracts and review supplier access.
Result: supplier register, risk assessments and improvement plan.
Train the board and employees. Training should focus not only on knowledge, but also decisions and behaviors.
Result: materials, participant list and test results.
Build one evidence repository for NIS2, ISO 27001, KSC, customer audits and cyber insurance.
Result: evidence matrix with dates, owners and status.
Run internal audit, close nonconformities and prepare management review covering both ISO 27001 and NIS2.
Result: audit report, corrective action register and management review record.
The biggest mistake is creating two separate libraries: one for NIS2 and one for ISO 27001. This increases chaos, cost and inconsistency risk.
Do not create a new document if an existing document can be extended with scope, owner, evidence and requirement mapping.
The evidence matrix shows whether the company can prove controls are operating. This is especially important because NIS2 and ISO 27001 require not only declarations, but also repeatability, supervision and improvement.
One person runs NIS2, another runs ISO 27001, while documents, risks and evidence are not connected. The result is duplication, inconsistency and organizational fatigue.
ISO 27001 helps, but does not replace applicability assessment, national duties, incident reporting timelines and sector requirements.
The control table looks good, but the company cannot show an MFA report, restore test, access review or incident exercise.
The certificate covers headquarters or a selected process, but NIS2 concerns a service, system, company or supplier outside scope.
The company has an incident response procedure, but no templates and path for NIS2 duties: early warning, notification and final report.
Documentation is created by IT or compliance, but the board does not approve risks, budget, exceptions and priorities.
ISO and NIS2 both require supplier relationship controls, but the company has no critical supplier register or risk assessment.
The company checks ISO 27001 separately, but does not test whether the same evidence system answers NIS2 requirements.
A SaaS company has ISO 27001 certification for its platform and technical team. After NIS2 requirements begin affecting customers, clients start asking about incident reporting, suppliers, business continuity, vulnerabilities and board accountability. The company initially treats NIS2 as a separate legal project.
After analysis, it turns out most elements already exist in the ISO 27001 system, but there is no NIS2 mapping, no 24 and 72-hour notification templates, no formal assessment of several suppliers, no board training evidence and no readiness report. The company does not create a second documentation library. It extends the Statement of Applicability, updates the risk register, adds an evidence matrix and includes NIS2 in management review.
After 90 days, the company has one shared plan: NIS2 as the requirement layer, ISO 27001 as the management system, ISO 27002 as the control catalogue and one evidence repository. Customers receive consistent answers, and the board sees the real risk status.
ccyber.io helps companies combine NIS2 and ISO 27001 into one practical action plan. We do not create two parallel projects. We build shared requirements mapping, risk register, roadmap, Statement of Applicability, procedures and evidence repository.
We can support your organization with:
The best first step is a NIS2 and ISO 27001 Integration Workshop. In a short workshop, the company can determine which requirements are already covered, where gaps exist, which evidence is available and how to build one plan without duplicating work.
Not automatically. ISO 27001 helps significantly, but NIS2 applicability, national rules, scope, incident reporting, suppliers and evidence must be checked separately.
Yes, if the company wants to organize information security management in a repeatable and auditable way. ISO 27001 can be a very good structure for NIS2.
First combine scope, risk register, Statement of Applicability and evidence matrix. This quickly shows what is already covered and where gaps exist.
Not always. Existing ISO 27001 procedures can often be extended with NIS2 requirements, especially for incident reporting, suppliers and board oversight.
Applicability assessment, risk register, Statement of Applicability, MFA report, access review, restore test, tabletop report, supplier assessment, training and management review.
Sometimes it helps, but the customer may still ask about specific NIS2 requirements: incidents, 24 and 72-hour reporting, suppliers, business continuity, evidence and applicability.
Ideally the programme owner is from security or compliance, with board, IT, legal, risk, DPO, HR, procurement and business process owners involved.
Start with one table: NIS2 requirement, ISO 27001 element, control, owner, evidence, status and gap. This is the simplest way to stop managing two projects separately.
NIS2 and ISO 27001 do not need to compete with each other or create two separate workstreams. NIS2 defines regulatory duties, while ISO 27001 provides the management system that helps implement, supervise and prove them.
The best practical plan combines applicability assessment, management system scope, risk register, Statement of Applicability, ISO 27002 controls, procedures, tests, suppliers, training, audits and evidence in one model.
The best rule is: one risk register, one roadmap, one control matrix and one evidence repository. Then NIS2 is not an extra layer of chaos, but a natural extension of a mature information security management system.
NIS2 Checklist for Companies: 20 Actions Before an Audit or Inspection
A NIS2 checklist before an audit or inspection should cover not only policies, but primarily evidence of operation. The company should confirm applicability, service scope, risk owners, asset inventory, risk management measures, MFA, backup, restore testing, incident response, incident reporting, suppliers, board and employee training, logs, vulnerabilities, access reviews and the evidence pack. An auditor or authority will ask not only “do you have a procedure?”, but “when did you last test it and what evidence do you have?”.
Prepared by: CCyber Editorial Team
Before a NIS2 audit or inspection, a company should prepare not only documents, but also evidence that cybersecurity works in practice. The 20 key actions are: confirming applicability, defining the scope of services and systems, assigning owners, preparing a risk register, performing gap analysis, approving an action plan by the board, organizing policies, inventorying assets, MFA and access control, access review, backup and restore testing, incident response plan, 24 and 72-hour incident reporting procedure, tabletop exercise, logs and monitoring, vulnerability management, supplier security, training, evidence repository and internal mock audit. An audit or inspection usually does not stop at “do you have a document?”. The key question is: “can you prove the document is being used?”.
July 2026
NIS2 audit readiness means the organization can show three things:
An audit or inspection is not only about checking whether the company has an information security policy. In practice, questions will concern who owns risk, when the last review happened, what test results were, which gaps are open, who approved exceptions and how the company responds to incidents.
The audit scope depends on the company’s role, sector, national rules, customer expectations and inspection purpose. In practice, prepare for questions about:
Every preparation area should have two layers: document and evidence. The document states what the company declares. Evidence shows that the declaration works in practice.
The first action is a formal applicability assessment. The company should know whether it is an essential entity, important entity, supplier to such an entity or organization indirectly affected by customer requirements.
Evidence: applicability assessment with date, sources, conclusion and board decision.
The auditor must know what the NIS2 programme covers. Without scope, risk and controls cannot be assessed.
Evidence: NIS2 scope map, critical systems and services list and exclusion justification.
Lack of owners is one of the most common gaps. NIS2 requires real cyber risk management, not anonymous tasks in a spreadsheet.
Evidence: RACI matrix or owner list approved by the board.
The risk register shows that the company manages cybersecurity as business risk. It should be linked to critical services, suppliers and the action plan.
Evidence: current risk register and risk review record by board or risk committee.
Gap analysis shows what the company already has, what is missing and which actions are priority before the audit.
Evidence: NIS2 gap analysis with gaps, priority, owner and remediation plan.
An auditor may ask whether the board understands risks and approved cyber risk management measures. An IT-only plan is not enough.
Evidence: resolution, management note or record approving the NIS2 roadmap.
Policies should be current, short and aligned with how the company actually works. Do not show documents the organization does not follow.
Evidence: approved documents with owner, version, review date and scope.
You cannot protect systems the company does not know. Asset inventory is the foundation of access control, backup, monitoring and incident response.
Evidence: asset register with owners, criticality, data and last update date.
Privileged accounts are one of the most important control areas. Missing MFA or too many administrators is a typical pre-audit gap.
Evidence: MFA report, administrator account list, PAM or PIM report where applicable.
Access review shows that the company controls who has access to systems and data. It is a very important audit evidence item.
Evidence: access review report with decisions: keep, reduce, remove, investigate.
Backup without restore testing is weak evidence. An auditor or authority may ask when the company last recovered data from backup and what the result was.
Evidence: backup report, restore test report and remediation list after the test.
The response plan should work in the first hours of an incident. It must be clear, short and mapped to roles.
Evidence: incident response plan, emergency contact list and role owners.
NIS2 provides staged reporting of significant incidents. The company must be able to quickly collect minimum information and escalate.
Evidence: incident reporting procedure, report templates and escalation path test.
A scenario exercise is one of the best readiness evidence items. It shows whether procedures work, people know their roles and the board can make decisions under pressure.
Evidence: tabletop exercise report with findings, gaps and action plan.
Without logs, the company may not know what happened, when and from which account. Logs also matter as evidence after an incident.
Evidence: log source list, retention policy, alert report and examples of alert response.
The organization should show that it detects, assesses and closes vulnerabilities. A scanner report alone is not enough.
Evidence: vulnerability report, remediation list, retest evidence and risk acceptance decisions.
NIS2 strongly emphasizes supply chain security. Before an audit, the company should know critical suppliers and their impact on services.
Evidence: critical supplier register, supplier risk assessments and security requirements in contracts.
NIS2 raises board accountability, so management training is an important preparation element. Employees should also know key procedures.
Evidence: training plan, participant list, materials, knowledge test result and effectiveness report.
Time matters in an audit. If evidence is scattered across mailboxes, folders and messengers, the inspection will be chaotic.
Evidence: evidence matrix with owners, dates, status and file location.
A mock audit helps find gaps before inspection. It should check not only documents, but also process owner interviews and evidence availability.
Evidence: internal audit report, nonconformity list, observations and corrective action plan.
The board report should be short and decision-focused. It should not be a list of technical details. It should show whether the company is ready, what remains risky and which decisions are needed.
The company has policies, but no reports, tests, logs, decisions or remediation actions.
The company assumes NIS2 applies or does not apply, but has no documented conclusion.
The board discussed cybersecurity, but there are no minutes, budget, risk acceptances or approved roadmap.
The auditor asks about restore, and the company only shows that backup runs.
The plan exists, but nobody checked whether it works in the first 24 and 72 hours.
Suppliers have access to data and systems, but were not assessed or added to the risk register.
Evidence is scattered and nobody is responsible for keeping it current.
Some gaps can be closed quickly, but tests, exercises, reviews and evidence need time.
A technology company prepares for an audit by a regulated-sector customer. It has a security policy, backup, MFA and an external IT provider. During review, however, it turns out there is no formal applicability assessment, the risk register is outdated, backup has not been tested for a year, access review did not cover suppliers and the incident plan has never been exercised.
The company does not try to create a large documentation library from scratch. It creates a 20-action pre-audit list. In the first month, it defines scope, owners and evidence. In the second month, it performs access review, restore test, supplier assessment and training. In the third month, it runs a tabletop and internal mock audit.
The result is practical: the company not only passes the audit more smoothly, but also improves real incident readiness. The biggest change is not a new policy. The biggest change is that every important area has an owner, evidence and remediation plan.
ccyber.io helps companies prepare for audits, inspections and NIS2 requirements in a practical, risk-based and evidence-driven way. We do not start from documents for documents. We start from scope, applicability, risks, critical systems, incidents, suppliers and board accountability.
We can support your organization with:
The best first step is a NIS2 Audit Readiness Workshop. In a short workshop, the company can determine which evidence already exists, what is missing, which risks are most urgent and which actions must be completed before the audit or inspection.
No. Policies are needed, but the auditor will expect operating evidence: reports, tests, reviews, logs, training records, board decisions and remediation actions.
First prepare applicability assessment, scope, risk register, owners, evidence matrix and board report. Then close technical and operational gaps.
MFA report, access review, restore test, risk register, incident response plan, tabletop report, supplier assessment, board and employee training, and board decisions.
It is strongly recommended. It is one of the best ways to prove the company can act after an incident, escalate to the board and prepare notifications within short timelines.
Yes. Supply chain security is an important NIS2 element. The company should have a critical supplier register, risk assessment and security requirements in contracts.
The board should know applicability status, top risks, action plan, critical gaps, budget decisions, incident status, supplier status and evidence status.
A basic evidence pack can be organized in 90 days if the company has an action owner and access to evidence. Full maturity usually requires a longer programme.
Start with an evidence matrix: requirement, evidence, owner, date, status and gap. This quickly shows where the company is ready and where real evidence is missing.
A NIS2 checklist before an audit or inspection should focus on evidence, not only documents. The company must show that it knows its scope, risks, systems, suppliers, incidents and board accountability.
The 20 key actions are applicability assessment, scope, owners, risk register, gap analysis, board decisions, policies, assets, MFA, access review, backup, restore test, incident response, incident reporting, tabletop, logs, vulnerabilities, suppliers, training, evidence repository and mock audit.
The best rule is: an audit is prepared before the audit, not during it. The earlier the company starts collecting evidence of operation, the lower the risk of chaos, nonconformities and costly emergency actions.
How Many Companies Are Covered by NIS2 in Poland?
There is no single certain, final number of companies covered by NIS2 in Poland that should be treated as closed and unchanging. The number depends on final national transposition, sector classification, entity size, exceptions for selected services and registration of essential and important entities. NIS2 directly covers mainly medium-sized and large organizations in defined sectors, but indirectly it will affect many more companies as suppliers, subcontractors and partners of regulated entities.
Prepared by: CCyber Editorial Team
There is no single simple and final answer to “how many companies will be covered by NIS2 in Poland?”. The safest answer is: the number will depend on the final wording of Polish NIS2 implementing rules, sector classification, organization size, exceptions for certain types of services and the process of identifying or registering essential and important entities. NIS2 directly covers mainly medium-sized and large entities in sectors listed in the directive, and in some cases smaller organizations regardless of size. Indirectly, the requirements will affect many more companies because NIS2 entities will require security from their suppliers, subcontractors and technology partners.
July 2026
There is no single certain number of companies covered by NIS2 in Poland for several reasons.
NIS2 is a European Union directive. This means Member States must implement it into national law. Only national rules define practical details: competent authorities, registration process, procedural duties, sanctions and qualification practice.
A company may be medium-sized or large, but if it does not operate in a NIS2 sector, size alone does not determine applicability. Sector, subsector and type of service must be checked.
As a rule, NIS2 applies to medium-sized and large entities in sectors covered by the directive. However, there are exceptions where smaller organizations may also be in scope due to type of service, importance for society, economy or public safety.
The directive provides for lists of essential and important entities and notification to the European Commission of the number of such entities by sector and subsector. This means the number is not only a theoretical estimate, but also an administrative process.
Even if a company is not directly an essential or important entity, it may be a supplier to such an entity. Then NIS2 requirements may appear in contracts, security questionnaires, customer audits, access requirements, SLAs, incident reporting duties and expectations around backup, MFA and business continuity.
NIS2 applies to public and private entities of the types listed in Annexes I and II of the directive. As a rule, it applies to entities that qualify as medium-sized enterprises or exceed the ceilings for medium-sized enterprises and provide their services or carry out activities within the European Union.
NIS2 covers sectors of high criticality and other critical sectors. For Polish companies, the important point is that the scope is broader than under NIS1.
As a rule, NIS2 focuses mainly on medium-sized and large entities in defined sectors. This does not mean small companies can automatically ignore the topic.
This distinction is very important because many misunderstandings around the number of companies covered by NIS2 come from mixing these two groups.
These are entities meeting criteria under NIS2 and national implementing law. They may be essential or important entities and have their own regulatory duties.
These are companies that may not formally be essential or important entities, but support regulated entities. In practice, they may need to meet some requirements because the customer expects it.
A company indirectly affected by NIS2 may not need to register as a regulated entity, but may receive customer requirements for MFA, backup, business continuity, incident reporting, security testing, ISO 27001, control evidence or audit rights.
The best approach is a short applicability assessment. It should not be based only on the company’s statistical business activity code. Such codes may help, but are usually not enough because real service, sector, scale and supply chain role matter.
Answer whether the company operates in one of the NIS2 sectors or supports customers from these sectors.
Assess whether the company is medium-sized or large under the criteria used by the directive. Consider not only employee count, but also capital links, turnover and balance sheet total.
Some service types may be covered regardless of size. This is especially important for digital services, trust services, DNS, domains, electronic communications and services of particular importance.
If the company provides services to a regulated entity, it may be covered by contractual requirements. This is often the most important scenario for SMEs.
The final answer for Poland must come from current national rules implementing NIS2, meaning the KSC amendment and related acts. Every assessment should therefore include a date and indicate the version of law used.
Evidence to prepare: NIS2 applicability assessment with date, sources, legal version and board decision.
Estimates of the number of companies covered by NIS2 may differ because different authors count different things.
This approach includes essential and important entities meeting sector and size criteria or exceptions.
This approach shows the real economic impact of NIS2, but does not mean every supplier automatically becomes a regulated entity.
This may overstate the result if it does not consider size, service type and exceptions.
Business activity codes may help, but they do not always reflect the real service. A company may have a technology code but provide a service outside NIS2, or the opposite.
If a company is medium-sized or large and operates in a NIS2 sector, applicability assessment should be a priority.
IT providers, managed service providers, managed security service providers, integrators, cloud, hosting and backup companies should check both their own applicability and customer requirements.
Companies developing or maintaining systems for regulated sectors may quickly receive NIS2 requirements in contracts and audits.
If a supplier has an administrator account, VPN, code access, production access, backup access, customer data or monitoring access, it will be treated as supply chain risk.
Manufacturing of medical devices, computers, electronics, electrical equipment, machinery, vehicles and selected products may fall within Annex II.
Uncertainty is not the problem if the company acts. Lack of decision is the problem. The board should request a formal applicability assessment and prepare a minimum action plan whether or not the company ultimately falls directly in scope.
The number of companies covered by NIS2 is less important than whether a specific organization performed its own applicability assessment.
Business activity codes may help, but they do not replace analysis of real service, sector, size, customers and exceptions.
A company may not be directly regulated but may still receive NIS2 requirements from customers.
Even if the company waits for final national rules, it can already implement basics: MFA, backup, incident response, access review, suppliers and training.
If the company concludes NIS2 does not apply, it should have a documented basis. A verbal opinion is not enough.
Lack of direct applicability does not mean a customer cannot require similar controls in a contract.
Sales, procurement and legal often see NIS2 requirements first in contracts, questionnaires and tenders.
A SaaS company has 70 employees and serves customers in health, manufacturing and public administration. The board asks: “are we one of the companies covered by NIS2 in Poland?”. The first answer is: this cannot be answered based only on employee count or the general label “SaaS”. Sector, service type, customers, data, customer system access and final national rules must be checked.
The assessment shows that the company may not be an obvious essential entity, but it is an important supplier to regulated customers. Contracts start to include requirements for incident reporting, MFA, backup, security testing, supplier access, subcontractors and control evidence.
The company prepares a NIS2 readiness pack. It implements a risk register, access review, restore test, incident response procedure, supplier assessment and board training. Even if final legal qualification requires more analysis, the company is ready for customer requirements and audits.
ccyber.io helps companies determine whether NIS2 may affect them directly or indirectly. We do not rely on a single market number. We analyze sector, services, size, customers, supply chain, contracts, data, critical systems and national requirements.
We can support your organization with:
The best first step is a NIS2 Applicability Workshop. In a short workshop, the company can determine whether it may be directly regulated, whether it is indirectly affected by customer requirements and which actions should start without waiting for full certainty.
There is no single certain final number that should be used safely for every decision. The number will depend on national transposition, sectors, company size, exceptions and the process of identifying essential and important entities.
No. A medium-sized company falls under NIS2 if it operates in a sector covered by the directive or meets special criteria under the directive or national law.
Not always. NIS2 mainly focuses on medium-sized and large entities, but includes exceptions. Small companies may also be indirectly affected through customer requirements.
Yes, especially if it provides managed services, security services, cloud, hosting, digital infrastructure or supports regulated customers.
No. It is only a starting point. The real service type, sector, customers, size, supply chain role and national rules must be checked.
Perform an applicability assessment, prepare a board conclusion and start basic security actions: MFA, backup, incident response, access review, suppliers and training.
Yes. A regulated customer may require specific safeguards, incident reporting, control evidence, audits and contractual clauses from suppliers.
Start with three things: applicability assessment, list of regulated customers and gap analysis of basic cybersecurity controls.
The question “how many companies are covered by NIS2 in Poland?” is important, but it can lead to the wrong conclusion if the company looks only for one number. The answer depends on final transposition, sectors, size, exceptions, entity lists and authority practice.
NIS2 will directly cover mainly medium-sized and large entities in defined sectors and selected organizations regardless of size. Indirectly, it will affect a much larger group of companies, especially IT providers, software houses, SaaS companies, integrators, cloud, backup and managed service providers.
The best rule is: do not rely on someone else’s estimate. Perform your own applicability assessment, document the decision and prepare a minimum set of controls that will be useful regardless of final qualification.
NIS2 Directive: What Is the Company Board Personally Responsible For?
NIS2 does not mean that the board must personally configure firewalls, backups or monitoring systems. It does mean that the board must approve cyber risk management measures, oversee their implementation, understand the impact of cyber risks on business operations, ensure resources, complete training and maintain evidence that cybersecurity is actually managed. Personal board accountability mainly concerns lack of oversight, lack of decisions, ignoring risk, failing to act on supervisory recommendations and inability to prove that the company acted responsibly.
Prepared by: CCyber Editorial Team
Under NIS2, the company board is mainly responsible for overseeing cybersecurity as a business risk. The board does not need to implement technical controls personally, but it must approve cyber risk management measures, oversee their implementation, ensure resources, understand risks, participate in training and require evidence that controls work. Personal board accountability does not mean automatic liability for every incident. It does mean, however, that the board cannot say “this is an IT matter” if the company had no risk assessment, response plan, backup, access control, supplier oversight, training, reporting and evidence. The detailed scope of accountability depends on national law, the role of the specific person, company structure and circumstances of the infringement.
July 2026
Personal board accountability under NIS2 does not mean every board member becomes a system administrator or cybersecurity specialist. It means cybersecurity becomes an area where the board must exercise real oversight.
In practice, the board is responsible for whether the company:
Simply put: the board is not responsible for every technical detail, but it is responsible for whether the company has an effective cyber risk management system.
The board may delegate execution to IT, security, compliance, external advisors and suppliers. It should not delegate oversight responsibility.
If the board has no reports, does not know the risks and does not make decisions, it will be difficult to show real oversight.
The first board responsibility is to ensure that the company knows whether it is subject to NIS2 or national implementing rules. This should not be an assumption or verbal opinion. A documented assessment is needed.
The assessment should cover:
Board evidence: NIS2 applicability assessment with a decision on who owns further actions.
NIS2 states that management bodies approve cyber risk management measures. This means the board should know the main risks and approve a plan of technical, operational and organizational measures.
Risk management measures include, among others:
Board evidence: approved cyber risk management plan linked to the risk register and budget.
Approving the plan is not enough. The board should oversee whether the plan is being implemented. Oversight does not need to mean daily task tracking. It should mean recurring reporting, questions about delays and decisions on high-priority risks.
The board should see:
Board evidence: recurring NIS2 dashboard with decisions and remediation actions.
NIS2 requires members of management bodies to receive training. The purpose is not to turn the board into a technical team. The purpose is for the board to understand cyber risks, assess risk management practices and understand the impact of cybersecurity on the company’s services.
Board training should include:
Board evidence: training materials, participant list, test result or participation confirmation, and note with conclusions.
The board does not need to implement controls personally, but it must provide real resources. Lack of budget does not remove risk. It may show that the company knowingly did not implement required measures.
The board should require clear information on:
Board evidence: approved budget or conscious risk acceptance decision with justification and review date.
NIS2 provides short timelines for reporting significant incidents. The board should ensure that the organization has a process that works in the first hours of an incident.
The company should be able to prepare:
The board does not need to write the notification personally, but it should know who classifies the incident, who informs the authority, who manages communication and who approves the report.
Board evidence: incident reporting procedure, notification templates and exercise report covering the first 24 and 72 hours.
Cybersecurity under NIS2 is not only about preventing attacks, but also limiting the impact of incidents on services. The board should know whether the company can continue operations and recover critical systems.
The board should ask:
Board evidence: business continuity plan, recovery test report and decisions on residual risks after the test.
NIS2 emphasizes supply chain security. The board should know which suppliers are critical and what risks they introduce into the organization.
The supplier programme should include:
Board evidence: critical supplier register, risk assessments and decisions about high-risk suppliers.
The board sets the tone of the organization. If employees fear reporting mistakes or suspicious situations, the company loses time. If managers demand bypassing procedures, training will fail.
The board should support:
Board evidence: training plan, training effectiveness report, reporting metrics and remediation actions after exercises.
During inspection, audit or after an incident, declarations are not enough. The company must show evidence. The board should require an organized evidence pack.
Evidence should include:
Board evidence: evidence repository and requirements matrix for NIS2, KSC, ISO 27001 and customer requirements.
Not every incident automatically means board accountability. Incidents can happen even in well-managed organizations. The key question is whether the company acted responsibly before, during and after the incident.
Many companies discuss cybersecurity in meetings, but do not document decisions. This is a mistake. After an incident, the decision trail matters.
IT is critical, but NIS2 concerns risk management, business continuity, suppliers, budget, incidents and management accountability.
The company assumes NIS2 does not apply because it is not classic critical infrastructure. NIS2 has a broader scope, and requirements may also come through customers and supply chains.
Risks are discussed, but there are no decisions, owners, budgets and deadlines. After an incident, it is hard to show real oversight.
The board does not need to be technical, but it must understand risks, obligations and consequences of decisions.
Incident response plans, backups and business continuity without tests are only assumptions. The board should require exercise reports.
An ICT supplier, cloud provider, software vendor, integrator or service company may be the source of an incident. NIS2 requires supply chain risk to be considered.
Fines matter, but business disruption, customer loss, post-incident inspection and inability to prove responsible behavior may be bigger problems.
The company may be doing many good things, but without evidence, it is difficult to show them to an authority, customer, auditor or insurer.
A technology company provides services to healthcare and industrial customers. The board initially assumes that NIS2 is a technical topic, so it assigns it to IT. After the first assessment, it turns out that the company is an important supplier to regulated entities, has access to customer data and maintains systems affecting continuity of customer services.
The gap analysis shows that the company has MFA, backup and monitoring, but lacks a formal risk register, board decisions, incident exercise, supplier programme, access review reports and training evidence. IT performed many actions, but the board did not receive recurring reports and did not make formal risk decisions.
The board launches a 90-day plan. The company creates an applicability assessment, risk register, action plan, board report, tabletop exercise, recovery test and critical supplier register. The most important change is not creating one document. The most important change is that the board starts regularly overseeing cyber risk and making documented decisions.
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, board accountability, incidents, suppliers and business decisions.
We can support your organization with:
The best first step is a NIS2 Board Accountability Workshop. In a short workshop, the company can determine whether it is subject to NIS2, what the board’s duties are, which risks require decisions, what evidence must be prepared and which actions should start in the first 30 days.
NIS2 requires management bodies to approve cyber risk management measures, oversee their implementation and be potentially liable for infringements. The detailed scope of accountability depends on national law and circumstances.
Not automatically. An incident may happen despite reasonable safeguards. The key question is whether the company had adequate measures, oversight, procedures, timely reporting, response and evidence.
It does not need to know every technical detail. It must understand risks, business impact, reporting obligations, control status, gaps and budget decisions.
Yes. The directive requires training for members of management bodies so they have the knowledge and skills needed to identify risks and assess cybersecurity risk management practices.
Possible consequences depend on national law. NIS2 provides for liability of persons able to ensure compliance and, in certain cases, the possibility of temporary prohibition from exercising managerial functions in essential entities.
No. A CISO or vCISO can lead the programme, but the board should still approve measures, oversee implementation, provide resources and make risk decisions.
Applicability assessment, risk register, board reports, budget decisions, training evidence, backup tests, incident exercises, access reviews, supplier assessments and corrective actions.
Start with applicability assessment, board training, risk register, control status report and 90-day action plan. Then run an incident exercise and prepare an evidence pack.
The NIS2 Directive does not require the board to become the IT department. It does require the board to exercise real oversight over cybersecurity as business risk. This means approving risk management measures, overseeing implementation, training, budget decisions, supplier management, incident reporting readiness and evidence of control operation.
Personal board accountability will usually not result from the mere fact that an incident occurred. It will result from the question of whether the board did what could reasonably be expected: understood the risks, required action, provided resources, responded to gaps, trained, exercised incidents and documented decisions.
The best rule is: the board does not need to do everything personally, but it must have evidence that it oversees. Under NIS2, lack of oversight, lack of decisions and lack of evidence are often a bigger problem than the technical gap itself.
What Compliance Evidence Should You Prepare for NIS2, KSC and ISO 27001?
Compliance evidence for NIS2, KSC and ISO 27001 is not only policies and procedures. A company should be able to show that cybersecurity works in practice: risk register, control owners, board decisions, backup reports, recovery tests, access reviews, training, supplier assessments, logs, vulnerability reports, incident response exercises, corrective actions and recurring reviews. The best evidence pack shows not only “we have a document”, but “we implemented, tested, measured and improved it”.
Prepared by: CCyber Editorial Team
For NIS2, KSC and ISO 27001, companies should prepare evidence showing that cybersecurity is actually managed, not only documented. The most important evidence includes: applicability assessment, risk register, board decisions, security policies, Statement of Applicability for ISO 27001, risk treatment plan, backup reports, recovery tests, access reviews, MFA, vulnerability management, training, supplier assessment, incident response plan, exercise reports, logs, metrics and corrective actions. A good evidence pack answers four questions: what was the company supposed to do, who owns it, was it done and what proves that it works?
July 2026
Compliance evidence means documents, reports, logs, records, decisions, test results and other traces that show the organization meets a requirement. In cybersecurity, evidence is especially important because many controls are not visible from the outside. The company must show that they work in practice.
Example: a backup policy is a document. The latest backup report, restore test report and list of issues after the test are evidence that the process works.
Good evidence should show:
NIS2 is an EU directive. It requires cyber risk management, appropriate technical, operational and organizational measures, significant incident reporting, management body accountability, business continuity, supplier management and training. Evidence for NIS2 should show that the company knows whether it is in scope, what its risks are, which measures it implemented and how it responds to incidents.
KSC, the Polish Act on the national cybersecurity system, is the Polish legal basis for the national cybersecurity system. The current text should always be checked in official sources because laws and implementing acts may change. Evidence for KSC should align with national duties, deadlines, incident definitions, supervision requirements and expectations of competent authorities.
ISO 27001 is an information security management system standard. Evidence shows that the organization has an ISMS, operates through a continual improvement cycle and can demonstrate risks, objectives, controls, audits, management reviews and corrective actions.
The common denominator is simple: risk management, accountability, controls, testing, monitoring, incidents, suppliers, training and improvement. The language of requirements differs, but much of the evidence can support NIS2, KSC and ISO 27001 at the same time.
You do not need a separate document set for each regulation. Well-designed evidence can support several requirements at once.
Examples:
The best approach is to build one evidence matrix and map each item to NIS2, KSC, ISO 27001, customer contracts and cyber insurance requirements.
An evidence matrix is a central table showing which evidence the company has, what it supports and when it must be refreshed.
Area: backup and recovery.
Evidence: restore test report for a critical system.
Owner: IT operations.
Frequency: quarterly for critical systems.
Supports: NIS2 continuity, KSC information security management system, ISO 27001 Annex A continuity and backup controls.
This is the first evidence group. Before showing controls, the company must know whether and to what extent it is subject to NIS2 and KSC, while for ISO 27001 it must define the ISMS scope.
The company prepares policies and procedures but cannot explain which services, systems and group entities they apply to.
NIS2 and KSC raise cybersecurity to management accountability level. ISO 27001 also requires top management involvement in the information security management system.
Good evidence is not only a board presentation. Good evidence is a record with decisions, risks, budget, owners and deadlines.
Risk is the common foundation of NIS2, KSC and ISO 27001. Without a risk register, it is difficult to show why selected controls are adequate.
A risk register exists, but it has no owners, dates, actions, metrics or board decisions. In that case, it is a document, not a management tool.
Policies show the expected way of working. Procedures show how the company performs specific processes. Policies alone are not enough, but they are a necessary system layer.
A policy should have an owner, version, approval date, scope, review period and link to risks and controls.
The Statement of Applicability, or SoA, is one of the most important ISO 27001 documents. It shows which Annex A controls apply, which do not apply and why.
The SoA is treated as a certification table, not a live control map. A good SoA should be updated after risk, technology and ISMS scope changes.
Access control is one of the most important evidence areas. Account takeover, excessive permissions and missing MFA are frequent incident sources.
An access review report should show not only a user list, but owner decisions: keep, reduce, remove or investigate.
NIS2 and KSC explicitly emphasize business continuity, backup and recovery. ISO 27001 also requires organizations to prepare for disruptions and loss of availability.
The company shows that backup runs, but does not show restore testing. For audit and resilience, restore is more important than the fact that a copy exists.
Under NIS2 and KSC, incident response evidence is particularly important because reporting deadlines are short and the competent authority may ask about the incident handling process.
The best evidence is an exercise report where the company tested the first 24 and 72 hours of an incident: who decides, who reports, who gathers facts and who informs the board.
Vulnerability management shows that the company actively detects and closes gaps instead of waiting for an incident.
The company has a test report, but no evidence that vulnerabilities were fixed or consciously accepted by the risk owner.
NIS2 and KSC strongly emphasize supply chain risk. ISO 27001 also requires managing security in supplier relationships.
Good evidence is a critical supplier card: service, business owner, access scope, risk, contractual requirements, last assessment date and contingency plan.
Training is an organizational requirement and evidence of security culture. Under NIS2 and KSC, board and staff training matter. Under ISO 27001, awareness, competence and participation records matter.
The company shows an attendance list, but does not show whether training changed behavior. It is useful to measure phishing reports, second-channel use and exercise results.
Without logs and metrics, it is difficult to show that the company detects incidents, responds and improves controls.
A good monitoring report shows not only the number of alerts, but also response time, closure status, owners and remediation actions.
The ISMS scope shows which processes, locations, systems, teams and services are covered by the information security management system.
Evidence should show interested parties, legal requirements, customer requirements, internal and external factors, and how these affect the ISMS.
ISO 27001 requires a methodical approach to risk. Evidence includes the methodology, risk register, assessments, decisions and action plan.
The SoA shows which controls are applied, which are not applied and why. It should be consistent with the risk assessment.
The organization should have measurable information security objectives, for example closing high-risk vulnerabilities, backup tests, access reviews, training or MFA improvement.
Evidence includes audit plan, checklist, audit report, nonconformities, observations and corrective actions.
Evidence includes management review minutes covering risk status, audit results, incidents, metrics, corrective actions and management decisions.
Evidence includes nonconformity register, root cause analysis, correction plan, owner, deadline and closure confirmation.
The company should show why it concluded that it is or is not in scope. This should be a documented conclusion, not a verbal opinion.
If the company is an essential or important entity, it should have evidence of registration, decision, qualification or other confirmation according to the relevant national procedure.
The company should have procedures and templates for the first hours of an incident. Evidence should include reporting process tests, not only a written procedure.
Evidence includes board reports, decisions, training, approved plans and budget.
KSC may allow competent authorities to request documents, information and evidence of requirement implementation. Therefore, the evidence pack should be ready before inspection, not created only after a request.
The evidence repository should be organized, secure and easy to review. It should not be a folder where everyone uploads random files.
Not every file is good evidence. Evidence should be credible, current and linked to a requirement.
A policy says what should happen. Evidence shows what actually happened.
If nobody owns evidence, it quickly becomes expired.
During audit, the company wastes time searching for files, and some evidence disappears with the folder owner.
The auditor must know whether evidence is current. No date weakens credibility.
The company has backup, BCP or incident response procedures, but no reports showing the process was exercised.
The board discusses cybersecurity, but there are no minutes, decisions, budget or risk acceptance records.
The company has many files, but does not know which requirement each file supports.
A vulnerability report or audit report is not enough. You need to show what was fixed, when and who approved closure.
A SaaS company is preparing for enterprise customer requirements, NIS2 and ISO 27001. The IT team has many good practices: MFA, backup, monitoring, vulnerability scanning and training. The problem appears during a customer audit. The company cannot quickly show when the latest restore was performed, who approved access review, which risks the board accepted and whether critical suppliers were assessed.
The company creates an evidence matrix. Each control area gets an owner, file location, update frequency and status. Within 90 days, the company organizes its risk register, Statement of Applicability, backup reports, access reviews, training, suppliers, vulnerabilities and incident response.
The result: during the next audit, the company does not search for evidence chaotically. It shows an evidence pack: what is required, which evidence exists, when it was updated and which remediation actions are in progress. This shortens the audit and increases credibility with the customer, board and insurer.
ccyber.io helps companies prepare a practical compliance evidence pack for NIS2, KSC, ISO 27001, customer audits and cyber insurance. We do not create documents for documents. We build an evidence system that shows controls work in practice.
We can support your organization with:
The best first step is a Compliance Evidence Workshop. In a short workshop, the company can determine which evidence already exists, what is missing, which evidence is expired and how to build a pack ready for the board, auditor, customer or supervisory authority.
No. A policy is necessary, but you need operating evidence: reports, tests, reviews, logs, decisions and corrective actions.
Applicability assessment, risk register, action plan, security policy, MFA report, access review, restore test, incident plan, supplier assessment and training evidence.
Yes. Many evidence items can support several requirements at once. That is why it is worth creating an evidence matrix and mapping evidence to different regulations and standards.
It depends on the area. Risks, suppliers, access reviews, backup, training and vulnerabilities should have defined review frequency, usually quarterly, semi-annually or annually.
Lack of testing. Companies have backup, incident response or BCP procedures, but no reports showing that the process was exercised.
No, not automatically. ISO 27001 helps a lot, but NIS2, KSC, incident reporting, scope and national requirements must be assessed separately.
Usually compliance, CISO, vCISO, risk or the ISMS owner. Owners of specific evidence should be in IT, security, HR, legal, procurement, finance and business teams.
Start with an evidence matrix: requirement, evidence, owner, date, status and gap. Then complete the key areas: risk, access, backup, incidents, suppliers and training.
Compliance evidence for NIS2, KSC and ISO 27001 should show that cybersecurity works in practice. A policy, presentation or declaration alone is not enough. Reports, tests, logs, decisions, reviews and corrective actions are needed.
The most important evidence groups are: scope and applicability, board decisions, risk, policies, Statement of Applicability, access control, backup, incident response, vulnerabilities, suppliers, training, monitoring, audits and corrective actions.
The best approach is one repository and one evidence matrix connecting NIS2, KSC, ISO 27001, customers and insurers. Then the company does not prepare for audits in panic. It has an evidence system that works every day.
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.