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, DORA and GDPR: One Security Programme, Separate Legal Duties
NIS2, DORA and GDPR require structured security management, but they do not cover the same organizations, information and obligations. This guide explains how to establish applicability, distinguish statutory duties from customer requirements and reuse safeguards without creating three parallel projects. It also identifies what must remain distinct: risk assessments, statutory registers, deadlines and incident notifications. A sample requirement record shows how to connect obligations with responsibilities, implementation and evidence.
Prepared by: CCyber Editorial Team
NIS2, DORA and GDPR can be supported through a coordinated security programme, but not through one universal declaration of compliance. First establish which provisions apply to the organization and in which capacity. Work on access, recovery, suppliers, training and incident response can then be coordinated.
Legal bases, the scope of individual obligations, statutory registers and notification arrangements remain distinct. A recovery test report may support several assessments, but it does not replace an assessment of lawful processing or the register of information required under DORA.
The practical objective is to perform a properly designed activity once and use its result wherever it genuinely meets a requirement. It is not to copy the same document into three folders.
19 September 2026
This article develops the topic of EU regulation and cybersecurity requirements. It focuses on coordination rather than providing an exhaustive account of GDPR, DORA or Poland’s KSC obligations. The working model and requirement record are CCyber recommendations, not official forms.
Boards, IT managers, CISOs, compliance professionals, data protection teams and procurement managers. It is particularly relevant where different teams commission similar assessments, send separate supplier questionnaires and prepare reports about the same safeguards.
It also supports IT and SaaS providers receiving customer requirements labelled “NIS2”, “DORA” or “GDPR” who need to understand their actual significance.
NIS2 establishes cybersecurity risk-management requirements across specified sectors. In Poland, the practical legal basis is the National Cybersecurity System Act, commonly referred to as KSC.
Applicability is not determined simply by whether a company uses the internet or processes customer data. Sector, activity, size and exceptions matter. The scope is explained by the European Commission and the Polish Ministry of Digital Affairs.
Question for the organization: which services do we provide, and what is the legal basis for determining our obligations?
DORA applies to financial entities identified in the regulation, subject to exclusions and proportionality. It covers areas including ICT risk management, incidents, resilience testing and technology supplier risk. ICT means information and communication technology.
Digital resilience is not limited to defence against attackers. Outages, failed changes and supplier unavailability can also matter. DORA’s objectives and areas are explained by the European Securities and Markets Authority, ESMA.
Question for the organization: are we an in-scope financial entity, or a provider receiving requirements from such a customer?
GDPR is not solely a cybersecurity regulation. It also governs processing principles and individuals’ rights. For each relevant processing activity, the company should establish whether it acts as a controller, processor or in another applicable capacity.
A controller determines the purposes and means of processing. A processor acts on the controller’s behalf. This is a different role from an IT system administrator. The distinction is explained by the European Data Protection Board.
Question for the organization: whose data do we process, for what purpose and who decides how it is used?
For a defined scope, but not as a universal exemption from every KSC provision. Article 4 of NIS2 addresses sector-specific EU legislation. Article 1(2) of DORA identifies it as such legislation for the relevant financial entities. The legal references are NIS2 and the DORA regulation.
In Poland, Article 8i of KSC must also be considered. It establishes special arrangements for banking and financial market infrastructure, excluding certain provisions while retaining specified obligations.
Organizations should therefore neither implement two identical programmes without checking the relationship nor mark KSC as inapplicable solely because they implement DORA. The assessment should identify which obligations are displaced and which remain.
DORA requires specified provisions in ICT service contracts. They include matters such as service descriptions, processing locations, incident assistance and data recovery. Services supporting critical or important functions are subject to additional requirements under Article 30.
A provider may therefore receive bank requirements concerning availability, testing, subcontracting or exit arrangements. This does not automatically make it a financial entity. A separate mechanism applies to formally designated critical ICT third-party providers, as explained by the European Banking Authority.
We recommend labelling requirements in three categories: the company’s statutory duty, a customer contractual obligation or a voluntarily adopted practice. All may matter, but each requires a different justification and approach to change management.
NIS2, DORA and Article 32 of GDPR share areas such as risk management, access security, continuity and safeguard assessment. GDPR requires protection to be considered against risks to individuals. This perspective is emphasized in the EDPB guide to securing personal data.
The following is a proposed operating model. Shared delivery does not mean that each component has identical requirements under all three regimes.
Agree common identifiers for services, applications, owners and suppliers. Teams can then work from the same information instead of repeatedly establishing who operates an application.
Do not replace one register with another. Records of processing activities, asset inventories and the DORA register of information have different purposes and content. EBA explains that the DORA register covers contractual arrangements for ICT services.
Outcome: source information is shared, while each required record retains its appropriate structure.
An account compromise can simultaneously disrupt a service, expose personal data and breach a customer commitment. The event description can be shared, but its consequences should not be reduced to a single lost-revenue figure.
We recommend separately identifying effects on operations, service continuity and individuals’ rights. An absence of significant financial loss to the company does not establish low risk to the person whose information was exposed.
Outcome: one investigation informs several assessments without concealing differences between them.
Access control, patching, backups and monitoring can support multiple requirements. For each safeguard, record the systems covered, owner, operating procedure and verification method.
A report confirming MFA for office users should not be presented as evidence that every administrator account is protected. Similarly, recovering one application does not automatically demonstrate recovery of the complete service.
Outcome: evidence is reused only where its scope matches the requirement being assessed.
Teams can conduct a coordinated supplier security review. Separate the technical assessment from required contractual clauses, data-processing arrangements and requirements specific to a financial-sector customer.
A signed data-processing agreement does not demonstrate recovery capability. Conversely, a security test report does not determine subcontracting permissions or what happens to data when the service ends.
Outcome: the supplier receives coherent questions, while the organization preserves the separate decisions required for each area.
Where several assessments identify the same gap, create one remediation action and connect it to the relevant requirements. Identify the delivery owner, deadline, acceptance criteria and person verifying the result.
Foundational training can be shared, with role-specific modules added afterwards. Someone reporting a suspicious message needs different preparation from someone determining whether a personal data breach is reportable.
Outcome: less duplicated work without closing several obligations through an action that does not adequately address them.
A well-protected database can still be used unlawfully, for example outside the appropriate purpose or without a valid legal basis. A common cybersecurity programme does not replace individuals’ rights or the remaining data protection obligations.
The scope of those rights is explained in the EDPB guide to respecting individuals’ rights. Not every issue requires purchasing a security tool. A business-process change may be needed instead.
Do not retain every log and backup indefinitely simply because several regulations require records. Article 5 of GDPR establishes data minimization and storage limitation.
Determine retention for the particular information, purpose and applicable obligation. A requirement to retain an audit report does not automatically mean retaining forever every item of data examined during that audit.
A register entry, supplier report and management-system certificate answer different questions. None should automatically be treated as proof of complete compliance with all three regimes.
Preserve conditions, exceptions and sector-specific rules in the requirements register. Listing article numbers next to a safeguard does not itself establish that those articles have been satisfied.
We recommend a shared incident record and timeline, with distinct decisions about notification obligations. This does not mean automatically reporting every incident to every authority.
A controller notifies the competent authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach, unless it is unlikely to result in a risk to individuals’ rights and freedoms. High risk also requires assessment of communication to affected individuals.
A processor informs the controller without undue delay. It should not assume it always has its own 72-hour window. Breaches not requiring notification to the authority must also be documented. The rules are explained in the EDPB data-breach guide.
Check the effect on services, entity status, applicable regime and transitional arrangements. The amended KSC reporting model provides for staged information rather than one universal report for every organization.
Incident significance should not simply be copied from the GDPR assessment of risk to individuals. The applicable provisions are in the Polish KSC Act.
A financial entity assesses a major ICT-related incident against the applicable DORA criteria. Its procedure should not import GDPR’s 72-hour period as the only reporting obligation.
For entities reporting to Poland’s financial supervisor, KNF identifies the DORA Incident Handling System and a fallback arrangement. The instructions are provided on the KNF DORA incident page.
Assign a trigger, deadline starting point, recipient and responsible person to each reporting route. A shared incident-management tool does not remove legal distinctions. Related exercise material is available in CCyber’s Incident Response and Business Continuity category.
Illustrative scenario, not a description of a specific client. A company provides system administration to a bank. Assume a separate assessment has established that it is an important entity under KSC. For some operations, it processes personal data on the customer’s behalf.
The company therefore has its own KSC duties, processor obligations and contractual commitments to the bank. The contract alone does not turn it into a financial entity subject to the full financial-entity requirements of DORA.
Following compromise of a support account, the team can conduct one technical investigation: preserve logs, establish access scope and contain the consequences. In parallel, the provider assesses its own KSC reporting, informs the data controller and gives the bank information needed for its DORA assessment.
The investigation is shared. Roles and reporting decisions remain distinct. The provider should neither wait for the bank’s entire assessment before fulfilling its own duty nor report everything on the customer’s behalf without authority.
The following template is an organizational recommendation. It connects obligations with delivery while preserving their source.
Entity and role: which company, service and legal capacity does the record concern?
Source: the specific legal provision, contractual clause or approved internal rule.
Required outcome: what must be performed, and across which scope?
Shared activity: which process or safeguard implements the requirement, and which other obligations does it support?
Responsibility: who decides, who performs the activity and who verifies the result?
Deadline and evidence: which event starts the deadline, where is confirmation recorded and when must it be refreshed?
Differences and limitations: what does the evidence exclude, which exceptions remain and which activities require separate delivery?
For example, one action removing unnecessary access can support several requirements. Closing it does not establish complete GDPR, KSC or bank-contract compliance for the entire application.
Prepare a concise applicability assessment for each relevant entity, service and role. Identify obligations already being performed, not only those planned for the future.
GDPR has applied since 25 May 2018 and DORA since 17 January 2025. Their applicable obligations should not be postponed until the KSC project is complete.
For organizations meeting the criteria when the KSC amendment entered into force, the relevant timeline provides for implementation by 3 April 2027. Entities required to self-register under the transition arrangements face a 3 October 2026 deadline. Check the Ministry’s timeline and self-registration guidance.
Compare open actions and check whether two teams are planning the same configuration, questionnaire or test. Agree one delivery activity incorporating the needs of all relevant recipients.
Do not combine activities merely because their names resemble one another. A data protection impact assessment is not automatically the same as a business impact analysis of downtime.
Select an important service and walk through access, supplier management, recovery and an incident. Verify that each team receives the information needed to fulfil its responsibilities.
Then extend the model to further services. A successful pilot does not establish compliance across the entire organization.
We recommend a management sponsor and a coordinator working across IT, security, procurement and compliance. Service owners should participate in prioritization and acceptance decisions.
A data protection officer, where appointed, advises and monitors within that function. The DPO should not automatically own every decision about processing. Articles 38-39 of GDPR require attention to independence and conflicts of interest.
Do not equate “one programme” with “one person responsible for everything”. The model should improve cooperation without removing necessary separation of roles.
Detailed guidance is available in the EU Cyber Regulations and Compliance category. Accountability and management reporting are explored in the Cyber Risk, Governance and vCISO category. These links lead to Polish-language resources.
This article supports the design of cooperation between disciplines. It does not replace a detailed assessment of a particular obligation.
Through its EU regulatory compliance services, CCyber supports gap assessment, policy and procedure preparation, responsibility mapping and planning of safeguards and evidence.
Identify which activities can be combined and which need separate delivery. Your current requirements register, service inventory and open actions provide a starting point. The objective is one agreed action plan that preserves the relevant legal distinctions.
No. Applicability must be established separately. Processing personal data does not automatically bring a company under DORA or KSC. Similarly, serving a bank does not automatically confer financial-entity status.
A shared overarching policy can be used where its scope is appropriate. Separate procedures and registers may still be needed. Document count is not the measure of compliance. Coverage of the applicable obligations is what matters.
No. Requirements may concern different data, entities and purposes. Longer retention is not always correct, and stricter access does not replace a lawful processing basis. First establish what the requirement applies to.
One audit engagement can assess several sets of criteria, but their scope and conclusions must remain distinguishable. Applicable assessor and independence requirements must also be met. A general technical report does not automatically become a statutory audit.
It can reduce duplicated assessments and activities, but there is no guaranteed saving. Start by measuring duplicated work, the time required to produce evidence and the number of obligations without an owner.
NIS2, DORA and GDPR approach security from different perspectives: service operation, financial-sector resilience and the protection of individuals. Many activities can be performed together, but their legal significance needs separate assessment.
The starting point is not three new projects, but one map linking entity, obligation, process, owner and evidence. This enables the organization to reduce duplication without overlooking the requirements that genuinely apply.
NIS2 in Poland: 7 KSC Compliance Misconceptions to Avoid
A NIS2 implementation plan based on draft legislation may need updating. This guide examines seven misconceptions about entity classification, registration, deadlines, fines, incident reporting and management accountability. It explains why six months is not a single deadline for every obligation and why PLN 100 million is not an automatic fine for every gap. It also provides a practical method for updating an earlier assessment and action plan against Poland’s enacted National Cybersecurity System Act.
Prepared by: CCyber Editorial Team
NIS2 preparation in Poland should be based on the enacted National Cybersecurity System Act, known as KSC, rather than assumptions from an earlier draft. An organization must separately establish its status, registration deadline, implementation deadline and audit obligations. Correct interpretation of incident-reporting deadlines and the grounds for fines is equally important.
It is not enough to assume that every company in a listed industry is an essential entity, every obligation must be completed within six months or an IT provider takes over management’s accountability. These shortcuts can produce the wrong project scope, unnecessary expenditure or missed obligations.
19 September 2026
The source article is compared with enacted legislation and official communications. The proposed review method is a CCyber recommendation, not an official procedure. An assessment of a particular organization must consider its activities, structure and applicable special provisions.
Boards, business owners, compliance professionals and teams implementing NIS2 and KSC. It is particularly relevant to organizations that prepared an applicability assessment, budget or schedule before the amendment was enacted and have not checked whether their assumptions remain valid.
Copla’s article on NIS2 implementation in Poland, updated on 19 January 2026, discusses draft legislation. It includes estimated registration and implementation windows and references to proposed classifications for food and chemicals.
The explanations below concern enacted law. They should not be attributed to the earlier article, and its forecasts should not be treated as the current implementation schedule.
The Act of 23 January 2026 amending KSC was published on 2 March 2026 and entered into force on 3 April 2026. This is confirmed by the official ELI record.
Entry into force does not mean that every new obligation had to be completed on that day. The amendment includes transitional provisions. However, a transition period does not allow an organization to disregard existing obligations, active incidents or registration deadlines.
What to change in the plan: remove statements such as “once the law is enacted” and “deadline to be confirmed” where the relevant issue has already been settled. Assign a current legal basis, date and triggering event to each obligation.
An industry’s economic significance does not replace legal classification. KSC distinguishes sectors and entity types. Organizational status depends on the combination of activities, size criteria and special provisions.
The enacted Annex 2 includes food production, processing and distribution, and the production, manufacture and distribution of chemicals. These are listed as important sectors. This does not automatically bring every business in those industries into scope or mean that an organization can never qualify as an essential entity on another basis.
The entity description must also be read. For food, the annex refers to businesses engaged in wholesale distribution and industrial production and processing. The general description “food company” is insufficient.
The assessment should use Article 5 and the KSC annexes. Where size matters, apply the relevant rules for linked and partner enterprises together with the statutory exclusions.
Article 8i establishes special arrangements for entities in banking and financial market infrastructure. It excludes parts of the ISMS and reporting provisions while retaining specified obligations. Organizations should neither duplicate the entire DORA and KSC programmes nor assume complete exclusion from KSC.
What to change in the plan: record the activity, classification basis, justification and relevant exceptions for each legal entity. A corporate group’s name does not replace an assessment of its individual entities.
KSC contains several different deadlines. Six months can relate to registration or a specific transitional obligation, but it is not a universal deadline for implementing the entire security programme.
The following dates concern the relevant transition arrangements for organizations meeting the statutory criteria on 3 April 2026. They are explained in the Ministry of Digital Affairs timeline.
This is the application deadline for entities required to self-register in the KSC register. Some organizations are registered by the authority and follow the relevant process for completing their information. All registration duties should not be reduced to “we are waiting for a letter”.
The obligation to identify applicability and register is reinforced in the Ministry’s communication of 3 September 2026.
For entities covered by the applicable transition period, this is the deadline for implementing their obligations and commencing S46 use under the relevant schedule. The objective is operational processes and safeguards, not merely approval of an implementation project.
The deadline concerns new essential entities that were not previously operators of essential services. Existing operators, known in Poland as OUK, retain their audit cycle. An important entity does not automatically acquire the same first-audit obligation merely because it falls under KSC.
Where an organization meets the criteria later, the general rules separately provide six months for the registration application, 12 months to implement obligations and 24 months for an essential entity’s first audit. Articles 7c and 16 provide the basis, subject to special routes and exclusions.
Additionally, Article 33(4) of the amendment provides a six-month transition to the new significant-incident reporting model for existing operators of essential services. This is another reason not to apply one date to every organization and task.
What to change in the plan: track registration, implementation, reporting and auditing separately. Registration does not demonstrate compliance, and an audit deadline does not extend the time for implementing safeguards.
Both parts require separate examination. KSC establishes different grounds and rules for fines. A headline amount is not a ready-made calculation for an individual company.
Article 73(3) provides an essential entity’s ceiling by reference to EUR 10 million or 2% of revenue from economic activity in the preceding financial year, whichever amount is higher. It also specifies a PLN 20,000 minimum.
Article 73(4) refers to EUR 7 million or 1.4% of such revenue for important entities and specifies a PLN 15,000 minimum. An individual assessment must consider the complete wording, currency-conversion rules and special provisions.
These figures should not be treated as the amount automatically payable for every finding. The Act establishes grounds for liability and criteria for determining sanctions. Revenue should not be replaced with profit, and a simplified description of worldwide turnover in an article about the directive should not be imported into a Polish penalty calculation without analysis.
Article 73(5) concerns infringements causing the threats specified in that provision, involving matters such as state security, human life and health, and serious harm or service disruption.
It is not an automatic sanction for a missing document or a universal ceiling for every KSC fine. Applying it requires assessment of its statutory conditions. The legal basis is Article 73 of KSC.
Article 35 of the amending Act defers the first imposition of the fines listed in Article 73(1)-(4), Articles 73a-73c and Article 76b until two years after the amendment entered into force.
That provision does not list Article 73(5). Consequently, the general statement “fines only start in 2028” should not be interpreted as a complete exclusion of every sanction. The omission alone does not determine whether a particular company can be fined on a particular date. The applicable duty, its deadline and the conditions for liability must still be established.
This detail can be checked directly in Article 35 of the amendment. Deferral of specified fines does not postpone implementation deadlines or remove the authorities’ separate supervisory powers.
What to change in the plan: separate sanction exposure from obligation deadlines. Do not build the security schedule solely around when a fine might be imposed.
Under the general KSC reporting model, an early warning must be submitted without undue delay and no later than 24 hours after detection of a significant incident. The incident notification must be submitted without undue delay and no later than 72 hours from that same detection point.
This is not 24 hours followed by another 72. The clock does not begin only after management approves the form. Nor should the organization wait for the entire technical investigation to finish before providing the information available at notification.
The final report is generally due within one month of the incident notification. Where handling continues, Article 12b provides for a progress report followed by the final report.
Exceptions exist. Trust service providers have a shorter notification deadline. Special rules also apply to specified public entities and financial sectors. The relevant transitional arrangements must be considered as well. Do not copy one reporting model into every organization.
Practical channels and principal deadlines are described in the S46 incident-reporting guidance. The statutory basis is in Articles 11-12c of KSC.
What to change in the plan: document the start of the reporting clock, correct recipient, deputies and fallback channel. Exercise ideas are available in CCyber’s incident response and business continuity resources.
Article 8c states that the entity’s manager remains accountable even where specified duties have been assigned to another person with that person’s consent. Outsourcing helps deliver activities but does not automatically remove statutory accountability.
Articles 8d and 8e cover matters including ISMS decisions, financial resources, task allocation, supervision and documented management training once per calendar year. The provider’s contractual liability and the manager’s statutory accountability arise from different legal grounds.
What to change in the plan: identify not only the delivery party but also the person making decisions and accepting results inside the organization. Related topics are discussed in the Cyber Risk, Governance and vCISO category.
An internal assessment that a supplier presents high risk is not the same as a formal high-risk supplier designation under Article 67b. The Act establishes a separate mechanism and consequences linked to the scope of the relevant decision.
Do not assume that every product must be replaced solely because of a manufacturer’s name or a general press comment. Check the applicable decision, the products or services it covers and the statutory deadlines.
A GRC platform can support registers, task ownership and evidence collection. It does not replace management decisions, system configuration, incident response or verification that safeguards work.
Article 10 distinguishes normative documentation from operating records. The latter includes records demonstrating that activities were performed, including system logs. The Act allows paper or electronic documentation. Purchasing a particular platform is therefore not a general condition of KSC compliance.
Similarly, an ISO/IEC 27001 certificate can support an assessment of maturity but does not independently demonstrate fulfilment of every KSC obligation. Compare the certification scope with statutory applicability and separately check registration, notification and audit duties.
What to change in the plan: give each task an acceptance criterion. “Service purchased” and “service verified as operating across the required scope” should be separate statuses.
The following method is a CCyber recommendation. It helps correct an earlier project without automatically discarding completed assessments and deployments.
Review the applicability assessment, schedule, audit scope, incident procedures and board presentations. Pay particular attention to dates, thresholds, definitions and “not applicable” conclusions. Record the source version supporting each significant assumption.
For each difference, identify the legal basis and organizational impact. Do not merely update the date in the document header. A change in entity classification may also affect auditing, supervision and the scope of a purchased service.
Assign an owner, deadline and completion criterion. Establish whether the change concerns a document, configuration, contract or budget decision. Preserve the revision history rather than presenting the corrected document as if it had applied from the project’s beginning.
Give management a brief account of what changed, which earlier activities remain useful, what must be corrected and which decisions are needed. The objective is to remove the gap between the formal plan and the organization’s actual obligations.
Illustrative scenario, not a description of a specific client. An industrial food processor prepared its project using an earlier publication. It assumed essential-entity status, one six-month deadline and an automatic first-audit obligation in 2028.
An updated assessment, under the scenario’s assumed size conditions and absence of another essential-entity basis, identifies the company as an important entity. It separates registration from implementation, updates the commissioned audit scope and retains planned security testing as a risk-based activity.
The company does not abandon safeguards because its classification changed. Instead, it removes incorrect justifications and aligns spending with the applicable obligations. The earlier technical assessment can remain useful even though its regulatory section needs correction.
Further explanations of obligations, evidence and inspection preparation are available in the EU Cyber Regulations and Compliance category. This article focuses on checking legal assumptions before translating them into budgets and schedules. The linked blog resources are in Polish.
The CCyber NIS2 compliance programme covers gap analysis, maturity assessment, action planning and support with implementing policies, procedures and controls.
Check whether your NIS2 plan reflects the current KSC requirements. An existing assessment, schedule and list of unresolved questions provide a starting point. The review should identify specific changes rather than produce another generic report.
Not automatically. First check its date, scope, assessment criteria and the currency of its evidence. Technical findings may remain useful while regulatory conclusions require updating. Separately assess whether the engagement meets the conditions of a statutory audit.
No. Registration is a separate activity. It does not independently demonstrate an implemented ISMS, operating safeguards or incident-handling readiness.
Not having the same periodic audit obligation as an essential entity does not mean there is no verification. An authority may order an audit in specified circumstances. Testing and assessments may also be necessary to verify safeguard effectiveness.
No. The triggers, recipients and information requirements differ. One incident may require assessment under several regimes. The procedure should run these assessments in parallel rather than assume that one form completes every obligation.
No. The specific obligation must be identified. For example, the general registration application period is linked to meeting the criteria, while completing missing register information can have a different triggering event.
The main weakness in an earlier NIS2 plan may not be the technical work. It may be draft-law assumptions left in documents that still guide organizational decisions.
Verify classification, separate deadlines, check reporting rules and assign accountability. Assess sanctions against the relevant provisions and measure implementation through completed and verified activities. This allows the programme to be corrected without unnecessarily restarting everything.
Poland’s KSC: The 2027 ISMS Deadline and How to Prepare for an Inspection
Entities meeting Poland’s KSC criteria when the amendment entered into force must implement the applicable obligations, including an operational ISMS, by 3 April 2027. The first-audit deadline in 2028 does not provide another year to implement safeguards. This guide explains the difference between regulatory inspections and audits, the scope of criminal-record checks and how to prepare evidence. A practical matrix connects risk assessment, policies, access, backups, incidents, suppliers and testing with records demonstrating that safeguards actually operate.
Prepared by: CCyber Editorial Team
By 3 April 2027, an organization covered by the relevant KSC transition period should have an implemented and operational information security management system, not just completed documents. The first-audit deadline in 2028 does not extend the implementation deadline.
Inspection readiness means connecting requirements, risks, safeguards, responsibilities and evidence. A company should be able to show not only a backup policy, but also a recovery result. Not only an access procedure, but also a completed access review. Not only an incident response plan, but also a record of an actual incident or a clearly labelled exercise.
19 September 2026
This article concerns Poland’s National Cybersecurity System Act, commonly referred to as KSC, which implements NIS2. Statutory deadlines and rules are distinguished from recommended inspection-readiness practices. The evidence overview and delivery schedule below are organizational recommendations, not an official regulatory checklist.
Boards, managers of essential and important entities, ISMS implementation owners, and IT, security, HR, compliance and audit teams. It is particularly relevant to organizations that already have policies or have started a NIS2 programme but cannot yet demonstrate that the documented safeguards operate in practice.
The schedule below primarily concerns organizations meeting the criteria for an essential or important entity on 3 April 2026. It is based on the amendment’s transitional provisions and the official Polish Ministry of Digital Affairs timeline.
This is the deadline for submitting an application for entry in the KSC register by entities required to self-register under the transition period described here.
Practical implication: confirm the entity’s status and registration route. Self-registration and registration by the authority are different processes.
This is the deadline for implementing the obligations and commencing S46 use under the relevant schedule. It concerns the organization’s actual ability to fulfil the requirements, not simply approval of a delivery plan.
Practical implication: the ISMS, incident handling, required roles and other obligations should be operational rather than merely planned.
This deadline concerns the first audit of new essential entities covered by the transition period described here that were not previously operators of essential services.
Practical implication: the audit evaluates an operating environment and processes. It is not the ISMS implementation start date or an additional year to establish safeguards.
Existing operators of essential services, known in Poland as OUK, retain their audit cycle. They should not automatically postpone their next audit until 2028. Separate transitional provisions also apply to them, including those concerning incident reporting.
For organizations meeting the criteria later, Article 16 generally provides 12 months to implement the obligations and 24 months for an essential entity’s first audit, counted from meeting the criteria.
Special provisions and any designation by administrative decision must also be checked. Do not assume that the clock always starts with registration. The relevant provision is Article 16 of KSC.
The Ministry’s September communication also confirms that registration is an initial step, not confirmation of full compliance.
Supervision is exercised by the competent cybersecurity authority for the relevant sector or subsector. This authority should not automatically be equated with the CSIRT receiving incident reports. Its remit can be checked in the Ministry’s overview of competent authorities.
Article 53 provides for measures including inspections at the entity’s premises, business locations or remotely, requests for information and access to documents, and requests for evidence of compliance.
Essential entities are subject to preventive and subsequent supervision. Important entities are subject to subsequent supervision, particularly where there are reasonable grounds to suspect a possible breach.
The audit under Article 15 concerns the security of the information system used to provide a service. Essential entities conduct it at their own expense at least once every three years.
The authority may also order an important entity to undergo an audit in circumstances specified by the Act, such as a significant incident or another breach.
A readiness review checks whether the organization can demonstrate that safeguards have been implemented and operate. It can be conducted before the statutory deadline to identify gaps. However, it does not become a statutory audit simply because a provider labels the service a “NIS2 audit”.
The first-audit deadline neither announces the date of a regulatory inspection nor guarantees that no information will be requested earlier. The legal basis and scope of the respective activities are set out in Article 15 and Chapter 11 of KSC.
An information security management system is a way of making decisions and performing activities that protect information and services. Policies describe the rules, but the system also includes people, accountability, safeguards, monitoring, testing and action on test results.
Article 8 connects technical and organizational measures with assessed risk. The organization should therefore be able to explain why it selected particular measures and what they cover. Not having an expensive platform does not itself demonstrate non-compliance. Buying one does not demonstrate effective protection either.
The practical question is: for a specific service, can we trace the risk to a safeguard and then to a verifiable result?
Service and assets → risk assessment → risk register → treatment decision → policies and safeguards → process operation → test → result → correction.
This is a relationship model, not a rigid project sequence. Incident response, access control and remediation of urgent vulnerabilities should not wait until all documentation has been completed.
The following overview covers risk assessment, registers, ISMS, safeguards, incidents, continuity, suppliers, vulnerabilities, access, training and audits. It gives examples of evidence rather than an exhaustive document catalogue or prescribed file names.
Before using it, align it with the applicable provisions, service scope and organizational status. Special rules may apply, including to financial entities and certain public entities.
Example evidence: risk assessment methodology, assessed scenarios, assigned risk owners, documented decisions and a risk treatment plan.
Verification question: does the assessment reflect current systems, suppliers and downtime consequences?
Example evidence: ISMS scope, approved policies, assigned responsibilities, budget decisions and review records.
Verification question: does management make decisions based on results and reported gaps?
Example evidence: system, data and device inventory, identified owners and relationships between assets and services.
Verification question: is it clear what other reports cover and what they omit?
Example evidence: safeguard configurations, protection coverage reports, physical access reviews and alerting test results.
Verification question: do safeguards operate across the declared scope, with exceptions identified and supervised?
Example evidence: response plan, incident records, timelines, incident classification, actions taken and lessons learned.
Verification question: can decisions and response activities be reconstructed from detection onwards?
Example evidence: appointed contacts, access to the relevant reporting channels, deputies, templates and submission confirmations.
Verification question: can the organization report an incident when its primary contact is unavailable?
Example evidence: business impact analysis, contingency plans, backup reports, recovery test records and follow-up actions.
Verification question: was the service restored, or only an individual file?
Example evidence: supplier risk assessments, contractual requirements, access reviews and service verification records.
Verification question: does supplier assurance cover the service the organization actually purchases?
Example evidence: identified vulnerabilities, agreed priorities, change records, documented exceptions and verification results.
Verification question: was remediation verified, or only marked complete?
Example evidence: access requests and approvals, MFA enforcement reports, access reviews and access removal evidence.
Verification question: can a former employee or supplier still obtain access?
Example evidence: documented training, assigned roles and confirmation of required personnel checks.
Verification question: do checks cover the relevant people, and does training reflect their responsibilities?
Example evidence: assessment scope and criteria, reports, findings, remediation actions and reassessment results.
Verification question: do findings lead to changes, and has their effectiveness been confirmed?
A policy requires multi-factor authentication for administrative access. This demonstrates that a requirement has been established, not that it is being applied.
A configuration shows that a rule enforces MFA. The organization still needs to establish which accounts, applications and authentication paths it covers and whether exclusions exist.
A controlled test and relevant logs confirm that an in-scope account could not obtain access without the required authentication. A review also confirms that exceptions are justified and supervised.
For MFA, “the user registered an authentication method” is not the same as “the system enforces that method on the required access path”. This illustrates the difference between a feature being present and a safeguard being verified.
A related approach to control assessment is described in NIST SP 800-53A. This is a supporting assessment methodology, not the Polish legal basis for a KSC inspection.
We recommend recording the requirement, system or service, owner, date or period, source and assessment result for every evidence item. It is also useful to identify the evidence’s limitations and the next verification date.
Example record: supplier access control for a warehouse management service, owned by IT, reviewed for a specified month using identity-system records and service tickets.
Result: one unnecessary account disabled, active sessions revoked and effective access removal confirmed through testing.
An attachment without a date, scope or source may be difficult to assess. Conversely, a lengthy report is not necessarily useful evidence if it concerns a different environment from the one covered by the ISMS.
Access-related evidence should be connected with identity, access and cloud security practices, rather than being stored only in a folder assembled before an inspection.
Article 8f concerns individuals performing the tasks specified in Article 8 or Article 11. Before starting those tasks, the individual presents information from Poland’s National Criminal Register concerning the absence of convictions for offences against the protection of information.
The Act also recognizes the requirements as met where the person holds a valid security clearance authorizing access to classified information marked “confidential” or higher.
This should not be interpreted as an identical checking requirement for the entire workforce. First identify the relevant tasks and the people performing them, then establish a procedure consistent with Article 8f.
Operationally, a controlled register of verification status can help. Criminal-record documents should not be placed in a broadly accessible project repository. Access should be limited to people who genuinely need it.
Before an inspection, consider an exercise in which a supplier reports an administrative account compromise on a Friday evening. Can the organization establish the service impact, classify the event, activate its response and provide the required information to the correct recipient?
Prepare a notification matrix identifying the legal basis, triggering conditions, start of the reporting deadline, recipient, responsible person and deputy. Include the appropriate CSIRT and S46 arrangements, including the fallback when the primary channel is unavailable.
Registration alone does not demonstrate that the appointed people can perform these activities.
Evidence may include an actual incident timeline or an exercise report with draft notifications. Exercises must be labelled as exercises. Do not submit a fictional incident through a production channel without agreeing the test arrangements with its operator.
CCyber’s incident response and business continuity resources can support scenario preparation.
When commissioning the statutory audit, verify its scope, the assessors’ qualifications, independence and reporting arrangements.
Article 15(2a) excludes individuals performing the specified tasks in the audited entity or who performed them during the year before the audit. Relabelling an implementation engagement as an audit is not sufficient.
Also plan for submission of the report to the competent authority. Article 15(1a) specifies three working days from receipt. The detailed conditions are set out in Article 15.
An ISO/IEC 27001 certificate may contribute to the evidence, but it does not independently demonstrate fulfilment of every KSC obligation. Compare the certification scope with the services and systems covered by the Act, and separately verify administrative, reporting and audit duties.
Verify the sender, legal basis, deadline, relevant systems and period. Assign one response coordinator and owners for individual evidence items. Clarify uncertainty through the appropriate channel without postponing preparation of the remaining information.
Map each question to an answer, supporting evidence and someone able to explain it. Compare declarations with current configurations and records.
A policy requiring quarterly reviews should not be presented as proof that four reviews occurred if only one was performed.
Agree the appropriate channel, mark protected information and maintain a submission register. Do not add passwords, private keys or unnecessary personal data. However, confidentiality should not be used to unilaterally restrict a legally required disclosure.
Document the gap, impact, owner, remediation deadline and verification plan. Preserve original records and change history. Do not backdate documents or present new safeguards as if they had been operating for months.
A remediation plan records the response to a gap. It does not automatically turn the gap into compliance. Similarly, internal risk acceptance does not remove a statutory obligation.
This schedule is proposed for an organization organizing its programme in September 2026. Urgent vulnerabilities and active threats require action regardless of the project sequence.
Confirm applicability, the competent authority and the registration route. Where self-registration applies, meet the relevant 3 October deadline. Appoint a management sponsor and ISMS coordinator.
In parallel, review privileged accounts, remote access, backups and incident-reporting capability.
Connect services with systems, data and suppliers. Assess risk and assign safeguards and owners.
For each action, define not only the implementation date but also acceptance evidence and subsequent verification. Establish the appropriate scope of personnel checks.
Implement safeguards and procedures, deliver training and begin recurring reviews. Collect operating records from the start.
Check external providers, contact availability and operational readiness for S46.
Review readiness across selected services. Test recovery, access removal, alert handling and the reporting workflow.
Correct identified gaps and reassess them. Management should receive the actual operational status, not just a project completion percentage.
Continue monitoring, reviews, training and recording decisions. A new essential entity should schedule its audit sufficiently ahead of its applicable 2028 deadline.
ISMS operation should not depend on whether an inspection has been announced.
Instead of reporting only “implementation is 85% complete”, we recommend four points: which requirements remain unmet, which services are exposed, which decisions are needed and which safeguards have verified operating evidence.
Useful measures include the proportion of requirements supported by current evidence, the proportion of services with successful recovery tests, accounts retaining access after cooperation has ended and overdue high-risk remediation actions.
Every percentage should have a clear scope and denominator. Otherwise, a report may look reassuring while failing to reveal the most important gaps.
Illustrative scenario, not a description of a specific client. A company has a backup policy and reports showing successful database backups. It therefore marks the recovery requirement as complete.
A readiness review finds that application configuration was not protected, required licensing information is unavailable and the recovery account depends on the same identity environment that has failed. The database exists in a backup, but the service remains unavailable.
The company expands its recovery scope, organizes emergency access and performs a test that includes starting the service and obtaining confirmation from its business owner.
This report addresses recovery readiness. A successful backup-job report remains useful, but does not replace the test.
Additional context is available in the EU cyber regulations and compliance category. Access management and incident response can be developed separately and their results connected through a single ISMS evidence index. These linked resources are available in Polish.
Organizations implementing requirements or addressing gaps can use the CCyber NIS2 compliance programme, covering gap analysis, action planning, implementation support and inspection preparation.
CCyber supports the translation of requirements into work packages, responsibilities and verifiable outcomes. A useful starting point is reviewing a selected service from its risk assessment through safeguards to operating evidence and remaining gaps.
Assess your company’s readiness for a KSC inspection. The NIS2 compliance programme can help organize the requirements-to-evidence matrix and gap-closure plan.
Readiness reviews and implementation support should be distinguished from the statutory audit, whose assessors must meet the applicable conditions.
No. For organizations covered by the transition period described here, the implementation deadline is 3 April 2027. The audit deadline concerns a separate obligation for a defined group of essential entities.
It must be able to demonstrate fulfilment of its obligations. A different periodic audit obligation does not mean an absence of supervision. The authority can also order an audit in circumstances defined by the Act.
Not as standalone confirmation of all KSC obligations. The certification scope, current process operation and obligations beyond certification must be checked.
That does not follow from Article 8f alone. The provision concerns individuals performing specified tasks and a defined category of offences. The verification scope requires mapping actual responsibilities to the law.
They can form part of the evidence when they establish the relevant scope, date and configuration. They do not replace process records or testing when the question concerns operation over time.
A controlled register and document repository can be used. Access permissions, versioning, completeness, currency and traceability to requirements matter more than the tool’s name.
KSC inspection readiness is not about assembling a policy folder shortly before the authority arrives. It means operating the ISMS so that decisions, activities, tests and corrections leave a consistent record.
The key question is not “Do we have a document?”. It is “Can we demonstrate that the required activity was performed across the appropriate scope and achieved its intended result?”.
That capability should be established before the implementation deadline and maintained afterwards.
NIS2 in the Food Industry: Will Cybersecurity Costs Increase Food Prices?
The food industry was not included in NIS2 and national cybersecurity rules by accident. Modern food production depends on ERP, MES, WMS, cold storage, quality systems, logistics, invoicing, OT, automation and digital suppliers. A cyberattack can stop production, disrupt the cold chain, delay deliveries, weaken batch traceability, block warehouses or force manual work. Implementing NIS2 and national cybersecurity rules means costs for food producers: risk management, ISMS, MFA, backup, monitoring, segmentation, supplier assessment, training, incident response and audits. Some costs may end up in product prices, but the cost of low resilience can be higher: downtime, lost batches, penalties, lost contracts and supply disruption.
Prepared by: CCyber Editorial Team
Yes, cybersecurity costs in the food industry may indirectly affect food prices, especially among large producers, processors and wholesale distributors covered by national cybersecurity rules and NIS2. This does not mean that cybersecurity is an unnecessary regulatory cost. Food production is now dependent on IT, OT, automation, cold chain, warehouses, invoicing, quality systems, logistics, suppliers and data. A cyberattack may stop a plant, delay deliveries, disrupt production, block traceability, affect warehouses or force manual work. Implementing national cybersecurity rules and NIS2 means costs for risk management, ISMS, MFA, backup, monitoring, segmentation, supplier assessment, training, incident response and audits. Some of these costs may be passed through to contracts, price lists or consumers. However, the cost of a successful attack can be higher than the cost of well-planned resilience.
July 2026
Food is a basic element of economic and social security. A large producer, processor, wholesale distributor, cold storage operator or supplier to retail chains does not operate only through machines and people. It operates through digital systems.
A modern food plant uses ERP, MES, WMS, production planning systems, automation, quality control systems, refrigeration systems, laboratory systems, electronic data exchange with customers, invoicing, transport, labelling, traceability and supplier communication.
It can, but not in a simple way. Cybersecurity is a cost of operating a modern plant. Companies must pay for people, tools, audits, training, backup, monitoring, segmentation, documentation, suppliers, tests and maintenance of safeguards. In a low-margin sector, part of these costs may be passed on to contracts, price lists, service fees or ultimately consumers.
However, the question should be reversed. What does low cybersecurity cost when the plant cannot produce for several days, cannot invoice, has no access to quality documentation, loses data, suffers cold storage downtime or cannot ship goods to a retail chain?
The cost of compliance is visible because it appears in the budget. The cost of an incident is often underestimated because the organization sees it only after an attack. This is one of the reasons why boards sometimes see cybersecurity as a cost rather than insurance for business continuity.
Every company involved in food production, processing or distribution should analyze its status. This especially applies to medium-sized and large companies, wholesale distributors, industrial producers, large processors, cold storage operators and suppliers to retail chains.
Even a smaller company may feel NIS2 impact if it supplies a regulated entity. A large producer, retail chain or distributor may require MFA, backup, incident procedure, training evidence, supplier assessment, audit or cyber insurance from its suppliers.
The key obligations are not limited to one document. The company should build an operating cyber risk management system covering people, processes, technology, production, OT and suppliers.
NIS2 preparation should start with a map of systems affecting production and deliveries. Not all of them are typical IT. Some are OT, automation or intermediate systems between production and office.
ERP stops working. The company cannot issue warehouse documents, invoices, production orders and shipping documents. Production may continue for a short time, but data, orders and confirmations quickly become unavailable.
The warehouse does not know where product batches are, what expiration dates apply, which orders must be shipped and which documents are needed. Manual work slows deliveries, increases errors and can affect retail chains.
A temperature monitoring system or cold storage automation stops working or the data becomes unreliable. The company must assess whether batches still meet quality requirements and whether they can be shipped to customers.
A supplier has remote access to the plant systems. Its account is compromised or its service tool becomes the attack vector. The company does not control who connected to the environment and when.
The company loses access to batch traceability data. In case of a quality issue, it cannot quickly determine where the product went and which batches should be blocked or recalled.
Food plants increasingly use automation, robotics, sensors, industrial IoT, dosing systems, refrigeration, packaging machines and digitally managed production lines. This improves efficiency, but creates OT risks.
OT is not secured in the same way as office laptops. Production continuity, physical safety, maintenance windows, automation supplier responsibility and product quality impact must be considered.
The board does not need to configure firewalls. It must understand risk, approve priorities and require evidence. National cybersecurity rules and NIS2 move cybersecurity from IT level to organizational accountability.
The company should check sector, size, group structure, activity type and customer relationships. In corporate groups, it must be clear which companies and plants are in scope.
Do not start with tools. Start with the process: order, production, quality control, cold storage, warehouse, shipping, invoicing, traceability, complaints and batch recall.
Risks must be described in business language. Example: WMS unavailability blocks shipments to a retail chain, which triggers contractual penalties and shelf-space risk.
MFA, EDR, backup, restore testing, updates, segmentation, monitoring, email protection and remote access control should be treated as the operational minimum.
Every obligation should have evidence: MFA report, backup report, restore test, access review, supplier assessment, training report, incident register, tabletop report and board decision.
Documents are needed, but not enough. If the company has no backup, MFA, supplier control and manual work plan, documentation will not stop downtime.
The IT team secures email and laptops, but does not analyze production lines, automation, cold storage, SCADA and service access.
The board sees implementation cost, but does not know the cost of one day of production downtime, lost batches or delayed deliveries to retail chains.
The company says it has backups, but has never restored ERP, WMS, MES or quality documentation in a realistic scenario.
Automation and IT suppliers have system access, but there is no MFA, named accounts, logging or periodic access review.
Incident response is written for IT, but does not say what production, warehouse, quality, logistics and the board should do.
Training covers office staff, but not production, warehouse, maintenance and automation teams.
The cheapest compliance often ends with documents without operation. It is better to implement fewer elements that truly reduce risk.
Not every cyber expense must automatically increase unit product cost. A well-planned programme can reduce cost through prioritization, shared purchasing, standardization, automation and eliminating fake compliance.
A medium-sized food producer has two plants, ERP, WMS, quality system, laboratory, cold storage, packaging lines, several automation suppliers and an external IT provider. The analysis shows that the company is likely to fall under national cybersecurity rules as an important entity. The board is concerned about costs because margins are low and retail chains negotiate prices strongly.
The first review shows partial MFA, backup without current testing, no IT/OT segmentation, incomplete remote supplier list, no formal incident procedure and no board reporting. At the same time, the cost of one day of production downtime is several times higher than the cost of implementing a baseline cyber programme.
The company implements a 90-day plan: applicability assessment, risk register, MFA for critical accounts, restore test for ERP and WMS, assessment of automation suppliers, ransomware playbook, training for production and warehouse staff, and IT/OT segmentation review. After three months, the board sees not only a list of costs, but also concrete risk reduction: shorter recovery time, supplier control and incident readiness. The cybersecurity discussion moves from “regulatory cost” to “cost of maintaining supply”.
This topic can be connected with further reading and CCyber services to move from cost concerns to a practical compliance and resilience plan.
ccyber.io helps food companies translate national cybersecurity rules and NIS2 into a practical cyber resilience programme that covers production, OT, logistics, quality, suppliers and costs. This is not only about documentation. It is about maintaining production, deliveries and customer trust despite growing threats.
We can support your organization with:
The best first step is a Food Sector NIS2 Readiness Workshop. In a short workshop, the company can determine whether it is in scope of national cybersecurity rules and NIS2, which processes are critical, where the biggest gaps are, how much downtime can cost and which actions reduce risk most without overloading the budget.
Not automatically. Sector, company size, role in the supply chain, group structure and national law must be checked. Even a company not directly in scope may receive requirements from customers.
Yes. Under Polish national cybersecurity rules, food production, processing and distribution are listed among important sectors.
They may partly affect prices, especially where margins are low and implementation costs are high. However, this is not only regulatory cost. It is an investment in production and supply continuity.
Applicability assessment, critical system map, risk register, MFA, backup, restore test, supplier assessment, incident response and basic training.
No. Documentation must be supported by operating evidence: MFA reports, restore tests, access reviews, supplier assessments, training, incident procedures and board reporting.
Yes. OT in a food plant requires separate analysis because it includes production lines, automation, cold storage, SCADA, PLCs and supplier service access.
Yes, especially if they supply large producers, retail chains, wholesalers or entities covered by NIS2. Requirements may appear in contracts and security questionnaires.
Start with the highest-impact risks, use existing tools, combine NIS2 with ISO 27001 and customer requirements, standardize across plants and measure outcomes.
NIS2 and national cybersecurity rules in the food industry are not a legislative curiosity. Food production, processing and distribution now depend on digital systems, suppliers, automation, data and supply chains. A cyberattack can quickly affect production, logistics, store shelves and consumer costs.
Implementation costs may be significant, but the cost of low resilience can be higher: downtime, lost batches, supply chaos, contractual penalties, lost customers and economic security risk. This is why implementation should be proportionate, practical and measurable.
The best rule is: do not ask only how much NIS2 costs. Ask how much one day without production, warehouse, cold storage, ERP, WMS, traceability and customer deliveries costs. Only then does cybersecurity become part of the resilience calculation, not only a regulatory cost.
Cybersecurity of Hospitals and Healthcare Providers: EU Action Plan, NIS2 and Practical Steps
The European action plan on the cybersecurity of hospitals and healthcare providers shows that healthcare is one of the most sensitive digital sectors. A cyberattack on a hospital is not only an IT problem. It can mean delayed procedures, unavailable medical records, emergency room disruption, patient data loss, diagnostic delays or operational chaos for medical staff. The EU plan focuses on four pillars: prevention, detection, response and recovery, and deterrence. For healthcare providers, this means implementing an ISMS, risk assessment, MFA, backup, segmentation, medical device security, monitoring, incident procedures, supplier assessment, training and readiness to report incidents under NIS2 and national cybersecurity rules.
Prepared by: CCyber Editorial Team
Cybersecurity of hospitals and healthcare providers is directly connected with patient safety. Ransomware, data leakage, unavailable electronic medical records, administrator account takeover, an attack on a diagnostic supplier or loss of access to medical records can affect treatment, diagnostics, emergency departments, planned procedures and patient trust. The European action plan for cybersecurity of hospitals and healthcare providers defines four pillars: prevention, detection, response and recovery, and deterrence. For healthcare providers in Poland, this means connecting the EU plan with NIS2, national cybersecurity rules, GDPR, EHDS, AI Act, cyber insurance and daily risk management. The key actions are: risk register, ISMS, backup and restore testing, MFA, EDR, segmentation, medical device control, monitoring, incident procedures, supplier assessment, staff training and board reporting.
July 2026
Digitalisation of healthcare has accelerated. Electronic health records, e-prescriptions, telemedicine, AI-supported diagnostics, connected devices, imaging systems, laboratories, patient portals and cloud improve care efficiency, but also expand the attack surface.
A hospital is now a digital organization. Doctors, nurses, reception, laboratories, imaging, hospital pharmacy, administration and external providers rely on IT systems. When these systems stop working, the problem is not only technical. It can delay treatment, force staff to work on paper, limit access to results and disrupt patient flow.
Prevention means building cybersecurity foundations before an incident happens. In practice, this includes critical security practices, risk management, guidance, training, procurement with cyber requirements, digital hygiene and financial support for smaller providers.
Detection means the ability to notice an attack early, before full disruption occurs. The EU plan foresees an EU-wide early warning service for the health sector and better sharing of threat information.
Response and recovery mean preparing for the worst scenario: ransomware, data leakage, unavailable EHR system, supplier failure or attack on medical devices. The EU plan refers to rapid response, the EU Cybersecurity Reserve, exercises and playbooks for the health sector.
Deterrence concerns actions at state and EU level. The goal is to show attackers that attacks against healthcare systems are met with coordinated diplomatic, legal and operational response.
The EU plan proposes a European Cybersecurity Support Centre for hospitals and healthcare providers. It is intended to operate with ENISA and provide practical support to the sector: guidance, tools, services, training, playbooks and early warning.
For a healthcare provider, the key is readiness to use such support. The existence of a support centre will not replace a local incident plan, backup, MFA and system owners.
In a company, system downtime often means lost sales or delayed work. In a hospital, downtime can delay diagnostics, a procedure, discharge, admission or access to test results. This changes the weight of decisions.
HIS, EHR, PACS, RIS, LIS, pharmacy, operating theatre system, emergency department, medical devices, finance system, HR, email, registration, patient portal and supplier systems create a complex ecosystem.
Some medical devices operate for many years, have limited update options, require certification, depend on specialist service and cannot easily be shut down for patching.
A hospital operates 24/7. Doctors and nurses cannot stop working only because a security measure is inconvenient. Safeguards must be designed to protect without blocking care.
Providers of medical, diagnostic, laboratory, cloud and service systems often have remote access, and their incident can affect the healthcare provider.
The EU plan sets the direction. NIS2 and national rules create obligations. A healthcare provider should connect both levels into one cyber resilience programme.
Not everything can be secured at once. Start with critical services and dependencies. In healthcare, criticality is not only technical. It depends on patient impact.
Ransomware is one of the key threats for healthcare. Backup must therefore be designed not as an archive, but as part of maintaining continuity of care.
Account takeover is one of the easiest ways into a healthcare provider. In healthcare, the challenge is harder because staff rotate, work shifts, use shared workstations and often need fast access to systems.
MFA must not block care in emergencies. This is why exceptions, emergency accounts, break glass procedures, logging of their use and review after each use are needed.
Medical devices and Internet of Medical Things are among the hardest areas of hospital cybersecurity. Some devices communicate with the network, some send data to clinical systems, some require supplier service and some operate on older operating systems.
A hospital does not operate alone. Many key processes depend on suppliers: HIS, EHR, PACS, RIS, LIS, diagnostics, outsourced IT, cloud, medical device service, laboratories, external companies and healthcare service providers.
A healthcare provider does not need to operate its own SOC, but it must have detection and escalation capability. In practice, this can be an internal team, MSSP, MDR, SOC as a Service or a mixed model.
A healthcare provider must have an incident procedure connecting IT, clinical staff, board, DPO, communications, legal, suppliers and public or private owners. The procedure should answer: what do we do in the first 15 minutes, first hour and first day?
Health data is one of the most sensitive categories of personal data. The European Health Data Space will increase the importance of secure access, exchange and reuse of medical data. Cybersecurity and data protection therefore cannot be managed separately.
AI can support diagnostics, triage, image analysis, documentation, administrative automation and research. It can also create risks: data leakage into public tools, wrong recommendations, shadow AI, lack of validation, attacks on models and supplier dependency.
Clinical staff have little time and work under pressure. Training must be short, practical and role-based. The board, doctor, nurse, reception team, IT team and clinical engineer need different training.
A cyberattack can affect treatment. Cybersecurity must therefore be managed together with patient safety, business continuity and clinical risk.
The provider has a paper procedure, but never checked whether staff can operate without EHR, email and online results.
The hospital secures office computers, but does not know which medical devices are connected to the network, who manages them and how they are updated.
A copy exists, but nobody knows whether HIS, EHR, PACS or LIS can be restored within acceptable time.
Medical system suppliers have remote access without MFA, named accounts, logging and clear incident responsibilities.
The board does not need only alert numbers. It needs to know which clinical services are at risk, which decisions are needed and what the cost of inaction is.
Staff use AI tools to summarize documents or draft content, but the provider has no rules for patient data and accountability.
One e-learning course does not change behavior. Short modules, simulations, reminders and scenario exercises are needed.
A county hospital uses HIS, EHR, PACS, RIS, LIS, Microsoft 365, finance system, patient portal and several remote suppliers. The board knows that healthcare is under increasing requirements, but cybersecurity has so far been treated as an IT task.
The first review shows several gaps: incomplete MFA for administrators, backup without current restore test, no register of medical devices on the network, incomplete list of suppliers with remote access, no exercise of working without EHR and no CSIRT incident reporting procedure. At the same time, clinical staff say they are afraid to report mistakes because they do not know what counts as an incident.
The hospital implements a 90-day plan. It creates a critical system register, enables MFA, performs a restore test, prepares a ransomware playbook, assesses suppliers, performs basic inventory of medical devices and runs a tabletop involving board, IT, DPO, emergency department, diagnostics and communications. After the exercise, the board sees not only technical gaps, but also patient, communication and operational impact. This is a real start of cyber resilience.
This topic can be connected with further reading and CCyber services to move from the EU plan to concrete action in a healthcare provider.
ccyber.io helps healthcare providers translate the European action plan, NIS2, national cybersecurity rules, GDPR, EHDS and AI Act into a practical cyber resilience programme. We combine patient safety, IT, medical devices, suppliers, compliance, training and risk management.
We can support your organization with:
The best first step is a Healthcare Cyber Resilience Workshop. In a short workshop, the provider can identify critical clinical systems, key gaps, ransomware readiness and actions needed in the first 90 days.
The action plan itself is strategic and coordination-oriented. Direct obligations mainly come from NIS2, national cybersecurity rules, GDPR, EHDS, AI Act, medical regulations, contracts and ownership requirements.
It depends on status, activity type, size, sector and national law. A healthcare provider should perform an applicability assessment and not assume automatically that obligations do not apply.
First critical services, backup, MFA, incident response, emergency work, suppliers, monitoring and training. Then more advanced elements such as SOC, automation and mature GRC.
No. Backup is necessary, but it must be protected, tested and connected with recovery procedure, communication, emergency work, system isolation and board decisions.
Not exactly. Medical devices require cooperation between IT, clinical engineering, supplier and clinical staff. Certification, availability, updates, patient impact and emergency operation must be considered.
Yes. A smaller provider may not have a full security team, but it still processes medical data, uses digital systems and can be targeted by phishing, ransomware or data leakage.
Short, practical and repeatable training works best. It should be scenario-based: phishing, suspicious attachment, EHR outage, data leak, ransomware, paper procedures and safe AI use.
Start with the map of clinical services, critical systems, backup, MFA, suppliers, ransomware procedure and a simple board report. Then plan a 90-day action programme and the first tabletop exercise.
The European action plan for cybersecurity of hospitals and healthcare providers shows that healthcare requires a dedicated approach. A cyberattack on a healthcare provider can affect patients, procedures, diagnostics, data access and public trust.
The most important actions are not only tool purchases. A provider needs a security management system, risk register, critical service map, MFA, backup, restore tests, medical device protection, supplier assessment, monitoring, incident procedures, training and board reporting.
The best rule is: do not ask only whether the hospital has safeguards. Ask whether the hospital can continue patient care when digital systems fail, whether it knows whom to notify, how to restore data and how to maintain clinical work despite an incident.
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.