A few months ago I spoke with the director of a district hospital who told me plainly: “Łukasz, I have 800 beds, 1,200 employees and an IT budget at the level of one ambulance. What am I supposed to do with NIS2?” That is a question I hear more and more often. Not from cybersecurity enthusiasts, but from physicians, administrators and local government officials who have suddenly discovered that their hospital is a target — and a very attractive one for criminals.
Cybersecurity in healthcare operates under different rules than in banks or corporations. The stakes here are not merely reputation or money. When ransomware paralysed a hospital in Düsseldorf in 2020, and a critically ill patient had to be transported to another facility and died en route, something new and irreversible happened. For the first time in history, a cyberattack probably killed a human being. This is not an abstraction. It is the new reality that Polish hospital management boards must confront today.
Why are medical facilities one of the primary targets of cyberattacks?
The healthcare sector has become one of cybercriminals’ favourite targets not by accident, but through cold, calculated business reasoning on the part of the attackers. Hospitals combine all the features that make a target ideal: invaluable data, enormous pressure to maintain operational continuity, historically under-investment in IT and an organisational culture centred on saving lives rather than on password policies. When ransomware locks hospital systems, the question is not “whether to pay the ransom” but “when.” Every hour of downtime is a real risk to patient health, and management knows this just as well as the attackers do.
In conversations with clients from the healthcare sector I regularly hear a similar narrative: “We are a small hospital, no one will attack us.” This is a false belief that can cost a great deal. Ransomware-as-a-service groups operate like industrial assembly lines — they scan the internet for unpatched systems, weak passwords and open RDP ports, then attack hundreds of targets simultaneously, selecting them not by size but by accessibility. A small district hospital running an unupdated Windows Server is just as attractive as a large clinical centre.
Consider the data: according to the IBM Cost of a Data Breach Report 2024, the healthcare sector has recorded the highest average cost of a data breach of all industries for the thirteenth consecutive year — over 9.7 million dollars per incident. By comparison, the financial sector comes second with approximately 6.1 million dollars. This difference stems directly from the unique value of medical data and the catastrophic operational consequences of a facility’s downtime.
Hospitals are targeted because they meet three conditions that are ideal for a cybercriminal: they hold data worth millions, they cannot afford downtime and they have historically invested significantly less in cybersecurity than other critical sectors.
There is yet another factor that has been growing for several years: geopolitics. Russian and Chinese APT (Advanced Persistent Threat) groups are actively attacking the critical infrastructure of NATO countries, and hospitals — as part of the civil defence system — are a natural target for destabilisation operations. In Poland, in the context of the conflict on our eastern border, this risk is particularly real and has been explicitly acknowledged in Poland’s National Cybersecurity Strategy.
📚 Read the complete guide: Cyberbezpieczeństwo: Kompletny przewodnik po cyberbezpieczeństwie dla zarządów i menedżerów
What medical data interests attackers, and how much is it worth on the black market?
A patient’s complete electronic medical record is not a single entry. It is a comprehensive portrait of a human being — their medical history, surgeries, genetic test results, psychiatric information, addictions, insurance affiliation and personal data all in one place. On the black market, on dark web services such as so-called carding forums and marketplaces dedicated to identity theft, such a record can be worth between 250 and even 1,000 dollars. By comparison, a stolen credit card number is worth around 5–20 dollars, because cards can be blocked within minutes. You cannot “block” a medical history. It remains valuable for years.
One hospital director once told me that he could not understand why anyone would want to steal his patients’ medical histories. This perspective is understandable — from a clinical point of view it is simply medical documentation. From a criminal point of view it is something entirely different. Medical data can be used for: sophisticated insurance fraud (so-called medical identity theft), blackmail of public figures who have sensitive medical histories, identity theft combined with fraudulent credit applications, sale to pharmaceutical and insurance companies (which constitutes a separate legal violation) and targeted phishing campaigns that exploit health status data.
A separate category is the data from clinical trials and the intellectual property of academic hospitals and research units. Theft of data from research into new drugs or medical procedures is a target of industrial espionage worth tens of millions of zlotys. Attacks of this type are far rarer but far more sophisticated — carried out by state-sponsored APT groups rather than by common cybercriminals.
Medical data has a value on the black market that is 50 times higher than credit card data. You cannot “cancel” it. It remains valuable for years after a breach.
A particular problem is the increasingly common combination of medical data with data from breaches of other services (credential stuffing). If a patient used the same password in a hospital patient portal as in a stolen database from a popular service, an attacker can automatically gain access to their medical data. This makes password policies and multi-factor authentication (MFA) a fundamental security requirement even in patient portals, which are often treated as relatively unimportant peripheral systems.
How does ransomware in a hospital endanger patients’ lives — real cases?
There is no need to resort to hypothetical scenarios. The documented cases of ransomware attacks on medical facilities form a chilling chronicle of the years 2019–2024. In 2020, an attack on Düsseldorfer Universitätsklinikum in Germany caused staff to work for several hours without access to IT systems, and a patient requiring immediate assistance had to be transferred to a hospital 35 kilometres away. The woman died. The public prosecutor’s office opened an investigation — for the first time in history examining a case as potential involuntary manslaughter resulting from a cyberattack. Although charges were ultimately not brought (it was established that the patient’s condition was too severe regardless of the circumstances), the case opened entirely new legal and ethical questions.
In 2021, the Irish Health Service Executive (HSE), the Polish equivalent of the NFZ, fell victim to an attack by the Conti ransomware group. The consequences were catastrophic: for several weeks, access to electronic medical records across 4,000 locations throughout Ireland was completely blocked. Thousands of oncology procedures, diagnostic consultations and chemotherapy sessions were cancelled. The cost of restoring systems exceeded 600 million euros. A year after the attack, some systems had still not been fully restored.
In Poland, the most widely publicised case was the attack on the Specialist Hospital in Otwock in 2021, and in 2023 the attack on the Children’s Health Centre in Warsaw, which deprived staff of access to IT systems for several days. There were significantly more such incidents in Poland — a considerable proportion never reaches the media due to the absence of an obligation to publicly disclose them (which the NIS2 directive will change) and concerns about the reputational consequences of exposing vulnerabilities.
The mechanism by which ransomware endangers patients’ lives is multi-layered. The direct effect is the loss of access to electronic medical records — a physician in the emergency department must act without knowledge of a patient’s allergies, blood type, medications and medical history. The indirect effect is the paralysis of diagnostics: encrypted PACS systems mean no access to CT and MRI images. Blocked LIMS means laboratory results are suspended. In intensive care units, where treatment decisions are made based on test results performed every few dozen minutes, this is a dramatic impediment.
Ransomware in a hospital is not merely an IT problem. It is the paralysis of diagnostics, loss of access to medical histories, cancellation of procedures and a real threat to patients’ lives. Hospital management boards bear responsibility for this — both legally and morally.
Research published in 2021 in the journal Health Affairs (Ransomware Attack Associated With Disruptions at Adjacent Hospital When System Down) demonstrated a statistically significant increase in mortality at hospitals affected by a ransomware attack and — particularly alarmingly — at neighbouring hospitals that received redirected patients without being prepared for the influx. A cyberattack on one hospital can therefore overload the entire regional healthcare system.
What regulations (NIS2, KRI, GDPR, the Medical Activity Act) apply to medical facilities?
The regulatory landscape for cybersecurity in healthcare has undergone a fundamental transformation in recent years. Medical facilities today operate at the intersection of four separate legal regimes that complement and reinforce each other. A management board that treats cybersecurity solely as a technical problem rather than a matter of legal compliance exposes itself to serious consequences — ranging from financial penalties to personal criminal liability.
The NIS2 Directive and the Polish Act on the National Cybersecurity System. The NIS2 Directive (implemented in Poland through an amendment to the Act on the National Cybersecurity System) classifies hospitals as “essential entities” — a category subject to the most stringent requirements. This means an obligation to implement a risk-analysis-based security management system, to maintain business continuity plans, to report incidents to the CSIRT within 24 hours (initial notification) and 72 hours (detailed report), and above all — the direct accountability of the governing body. Penalties for violations can reach 10 million euros or 2% of global turnover. Crucially, NIS2 explicitly states that managers may be temporarily suspended from their managerial functions in the event of gross negligence.
GDPR. Medical data belongs to the so-called “special categories of personal data” subject to the strictest protection. Hospitals process this data on a mass scale and must ensure its protection through appropriate technical and organisational measures. A breach of patient data entails an obligation to notify the Polish Data Protection Authority (UODO) within 72 hours and potential fines of up to 20 million euros or 4% of global turnover. In 2023, the UODO imposed fines on several medical entities for inadequate protection of patient data.
The KRI Regulation (National Interoperability Framework). The KRI, although dedicated to public entities, imposes specific requirements on the IT systems of entities performing public tasks, including public hospitals. It requires the implementation of an information security management system based on the ISO 27001 standard or an equivalent approach, and the managers of the entity must ensure and keep updated the security documentation.
The Medical Activity Act. Although this regulation is not a typical cybersecurity statute, it contains provisions relating to the maintenance and protection of medical records. Since 2020, medical records in Poland have been required by law to be kept in electronic form (EDM), which means that securing them has become a direct legal requirement. Failure to secure EDM and its loss or unauthorised access may be treated as a violation of the Act.
Hospital management bears responsibility for cybersecurity today not only morally but also legally. NIS2 introduces the personal liability of directors — potentially up to suspension from their functions. This is not a matter of choice; it is a condition of lawful operation.
It is worth emphasising that these four legal regimes do not exist in isolation — they create cumulative obligations. A ransomware incident that locks a hospital’s systems and causes a patient data breach can simultaneously result in a violation of NIS2, GDPR and the Medical Activity Act. Supervisory authorities in Poland — the UODO, the national CSIRT and, in the future, the body supervising NIS2 — can impose penalties independently of each other. A comprehensive approach to compliance that treats these regulations as a coherent system rather than separate checklists is the only rational approach.
How do you secure HIS, PACS systems and network-connected medical equipment?
A hospital’s IT ecosystem is one of the most complex computing environments I work with. In a typical district hospital, there is a HIS from a Polish or European supplier (often with a long history of technical debt), PACS systems from diagnostic equipment manufacturers, a dozen or several dozen different specialist systems (laboratory, pharmacy, bed management, staff scheduling), and on top of that, hundreds of IoMT devices — from infusion pumps to cardiac monitors — running on operating systems that manufacturers stopped updating many years ago.
Securing the HIS begins with the relationship with the supplier. The contract with the company providing the HIS should contain clauses covering: regular security updates and their delivery schedule, the procedure for handling discovered vulnerabilities, responsibility for the security of data stored in the system (particularly in SaaS and cloud models), the right to conduct a security audit of the system and the guaranteed system recovery time objective (RTO) and maximum permissible data loss (RPO). Many older contracts do not contain these provisions — renegotiation is a necessity.
At the technical level, the HIS should be deployed in accordance with the principle of least privilege: each user has access only to those modules and data that are necessary for their work. A ward nurse does not need access to the financial and billing system. A specialist physician does not need to view the complete records of patients from other wards. Detailed logging and auditing of user activities should be standard — not only for security purposes but also for GDPR compliance.
Securing the PACS is a separate category of challenges. Diagnostic imaging archiving systems store enormous amounts of data (large hospitals generate terabytes of new imaging data annually) and often run on old, unupdated software versions due to dependencies with diagnostic equipment from specific manufacturers. Key measures include: isolating the PACS in a separate network segment, implementing a dedicated backup and recovery policy for imaging data (which is often not covered by the standard backup policy for clinical data), regular recovery testing, encryption of data at rest and implementing an access control system with full auditing.
Medical equipment (IoMT) is a category where the “traditional” approach to patching and updates simply does not work. A CT scanner running Windows 7 with expired manufacturer support cannot be upgraded to a newer operating system without risking the loss of CE and FDA certification. This is not hospital negligence — it is a systemic problem within the industry that requires a different approach to security. Instead of trying to secure the device itself (which is often impossible), the focus is on controlling its environment: compensating security controls in the network environment surrounding the device, monitoring for anomalies in the network traffic generated by the device, and implementing Network Access Control (NAC) solutions that automatically profile every device connected to the network.
Outdated medical equipment cannot be safely updated. Instead of securing the device itself, secure its environment — isolate it at the network level, monitor for anomalies and control access.
An integral part of the security of clinical systems is Privileged Access Management (PAM). Administrator accounts for HIS, PACS or database systems are the “keys to the kingdom” — their compromise gives an attacker immediate access to everything. Password rotation, multi-factor authentication for privileged access and recording of administrative sessions are the absolute minimum.
Why is network segmentation critical in a hospital environment?
Imagine a building without interior doors. The reception area, operating theatres, pharmacy, server room and canteen are connected by open corridors. Anyone who enters the building has access to everything. That is precisely what the “flat” network architecture that I still encounter in many Polish hospitals looks like — one large network in which the HIS, cardiac monitors, patient Wi-Fi, reception desk printers and patient data servers all communicate directly with each other.
Network segmentation is the architectural solution to this problem. It consists of dividing a single flat network into separate, logically and physically isolated segments (VLANs or microsegments), between which traffic is controlled and filtered by firewalls or Zero Trust rules. If an attacker compromises one segment — for example by infecting a computer at a reception workstation via an infected USB drive — network isolation prevents them from moving laterally to the segment in which clinical systems operate.
In a hospital environment, proper segmentation should separate at least the following zones: the clinical network (HIS, RIS, PACS, laboratory systems) — accessible only to devices and users with verified identity; the IoMT device network (medical equipment) — isolated from the rest of the network with only the necessary traffic to integration systems permitted; the administrative network (finance, HR, email) — separated from the clinical network; the guest and patient network (Wi-Fi in wards) — completely isolated from internal networks; the infrastructure management network (switches, servers, backup systems) — accessible only to administrators via dedicated, secured connections.
In conversations with clients from the healthcare sector I frequently encounter concern that network segmentation “will complicate work and hinder treatment.” This is an understandable concern, but it stems from a misunderstanding of the purpose of segmentation. Properly designed and implemented segmentation is invisible to clinical staff — physicians and nurses still have access to all the systems they need, but connections between segments are monitored and authorised. It is like card-access doors in a hospital — they do not impede the work of authorised personnel, but they control access for the unauthorised.
The key technology complementing segmentation is Network Access Control (NAC). A NAC system automatically identifies every device attempting to connect to the hospital network, verifies its identity and state (whether it has the required updates installed, whether it has active antivirus software) and assigns it to the appropriate network segment or denies access. In an environment where hundreds or thousands of devices are connected to the network — from physicians’ laptops to cardiac monitors and portable diagnostic devices — NAC is the only scalable way to maintain control over what is connected to the network.
A flat hospital network is a motorway for ransomware. Network segmentation is the single most effective investment in limiting the impact of an attack — it turns a potential catastrophe into an isolated incident.
An additional dimension of segmentation that is rarely discussed in the hospital context is the separation of production environments from test and development environments. Medical software suppliers regularly require access to a hospital’s test environments in order to deploy updates or resolve problems. The test environment should be physically or logically separated from the production environment and should not contain real patient data (anonymisation or pseudonymisation of test data is a GDPR requirement). Violation of this principle is surprisingly common and creates serious security risks.
How do you build an incident response plan for a medical facility?
An Incident Response Plan (IRP) is a document that every medical facility should have and most do not. In a conversation with one director of a regional clinical hospital I heard: “We have procedures for fire, epidemic and structural disaster. We never thought about a procedure for a cyberattack.” This is changing, driven by NIS2 and growing risk awareness, but the changes are still too slow.
A cybersecurity incident response plan for a hospital must differ from a typical corporate IRP in several key respects. Above all, it must include “fall-back” procedures for paper mode — what specifically do we do when there is no access to the HIS? Who is responsible for transcribing key patient data onto paper forms? What does communication between wards look like without access to systems? These procedures must be implemented, tested and known to clinical staff, not only to the IT department.
The second key element is a clear decision-making and communication structure for the duration of an incident. Who makes the decision to shut down systems in order to contain the attack (which may mean hours without access to the HIS)? Who informs patients and the media? Who contacts the CSIRT and supervisory authorities? Who decides on potential evacuation and patient redirection? In a crisis there is no time for deliberation — every decision must have a pre-designated owner.
The structure of a typical incident response plan for a hospital encompasses six phases: preparation (documentation, training, testing), identification (incident detection, initial assessment), containment (halting the spread of the attack), eradication (removal of malicious software and the cause of the incident), recovery (restoring systems from backups) and lessons learned (analysis of the response and improvement of procedures).
The recovery phase deserves particular attention. A backup is only as good as the last tested restoration process. Hospitals regularly create backups but rarely carry out full, realistic tests of restoring the HIS from a backup. How long does it take to restore a system from a backup? One hour, eight hours, three days? Does the backup contain all the components needed for a full system restart? Is the backup stored in an isolated location where ransomware will not be able to encrypt it? Hospital management should know the answers to these questions — and should not be discovering them for the first time during an actual attack.
In accordance with the requirements of NIS2, hospitals as essential entities are obliged to report serious incidents to the national CSIRT (CERT Polska) within 24 hours of detection (preliminary warning) and 72 hours (detailed report). The response plan should contain ready-made templates and procedures for these notifications, along with contact lists and the scope of information required in each report. A delay in notification can in itself constitute a violation of NIS2 provisions and result in the imposition of a penalty.
What minimum security measures should every hospital implement?
The table below presents a cybersecurity maturity model for medical facilities, organised into three levels: basic (legally required), advanced (recommended) and optimal (for facilities with a high risk profile or resources). Every hospital should honestly assess its current level and plan a path to achieving at least the basic level — which is in effect the minimum requirement under NIS2 and GDPR.
| Area | Basic level | Advanced level | Optimal level |
|---|---|---|---|
| Risk management | Critical assets identified, risk analysis conducted, information security policy documented | Formal risk management system (ISMS), risk register updated annually, risk owner for each risk | Continuous risk management, integration with strategic decisions, automated risk scoring |
| Identity and access protection | Strong passwords (min. 12 characters), unique accounts for each user, account lockout policy | MFA for all clinical systems and remote access, PAM for privileged accounts, quarterly access reviews | Zero Trust Architecture, continuous identity verification, UEBA (behavioural anomaly detection), JIT access |
| Network segmentation | Separate clinical and administrative networks, separate network for guests/patients, basic firewall rules | Full segmentation into VLANs (HIS, PACS, IoMT, administration, guests), NAC for new devices, NGFW with SSL inspection | Microsegmentation, Software-Defined Networking, Zero Trust Network Access, automated quarantine |
| Backup and recovery | Daily backups, backup stored offsite, documented recovery plan | 3-2-1 backup (3 copies, 2 media, 1 offsite), immutable/air-gapped backup, quarterly recovery testing | Cloud backup with immutable storage, automated recovery testing, RTO < 4h, RPO < 1h |
| Threat detection | Antivirus/EDR on all workstations, central syslog, basic network monitoring | SIEM with event correlation, NDR for anomaly detection, IDS/IPS, dark web monitoring for leaks | 24/7 SOC (own or MDR), Threat Intelligence, Threat Hunting, automated response (SOAR) |
| Incident response | Documented IRP, defined roles in IR team, fall-back procedures for paper mode | Regularly tested IRP (annual tabletop exercise), contract with external IR provider, playbooks for key scenarios | IR firm retainer, regular Red Team/Blue Team exercises, continuous improvement based on incidents |
| Training and awareness | Mandatory basic training for all new employees, policy for safe IT use | Regular phishing simulations, dedicated training for groups (physicians, nurses, administration), management training | Continuous security awareness programme, gamification, training effectiveness measurements |
| Regulatory compliance | Basic GDPR documentation, records of processing activities, appointed DPO | NIS2/KSC compliance audit, DPIA for key systems, documented incident reporting procedures | Automated compliance monitoring, regular external audits, ISO 27001 certification |
| Supply chain security | Security assessment of key suppliers (HIS, IT infrastructure), security clauses in contracts | Formal security questionnaires for all suppliers, supplier monitoring and audits, security SLAs | Continuous third-party risk monitoring, supplier penetration testing, SBOM for medical software |
An honest self-assessment based on this table often reveals that many Polish hospitals do not reach even the basic level in several key areas — particularly in network segmentation, recovery testing and access management. This is not a cause for shame — it is a starting point for investment planning.
How do you finance cybersecurity in healthcare — grants, subsidies, NFZ budget?
Financing cybersecurity in Polish hospitals is a topic that arises in every conversation with directors of public facilities. “We have no budget” is the answer I hear most often — and I understand that it is not an excuse but a hard reality. Public hospitals in Poland are chronically underfunded, and IT and cybersecurity compete for budget against the purchase of medical equipment, ward renovation and staff remuneration. At the same time, ignoring the problem is becoming an increasingly expensive option — both legally (NIS2 penalties) and operationally (costs of recovery after an attack).
The good news is that in recent years several significant funding sources have appeared specifically dedicated to cybersecurity in healthcare.
The National Programme “Health for Poland” (KPO) provides funds for the digitalisation of the healthcare system, including components for IT system security. Hospitals can apply within the framework of e-health measures, where securing IT infrastructure is increasingly a sine qua non condition for receiving digitalisation funding. It is worth monitoring calls announced by the Centre for e-Health and by marshal offices (voivodeship administrations).
The National Cybersecurity Centre (within KPRM/MC) runs support programmes for essential entities implementing KSC/NIS2 requirements. Some of these programmes include free or subsidised security audits, advisory services and tools for public entities.
The NFZ and the contract with the National Health Fund. Since 2021, the NFZ has introduced elements relating to IT security into accreditation standards and contracting requirements. Hospitals applying for accreditation or negotiating new contracts with the NFZ should check the current requirements, which are regularly expanded.
Regional Operational Programmes (ROP) from EU funds for the years 2021–2027 provide support for the digitalisation of public entities, including healthcare facilities. Digital security priorities are one of the key criteria for project evaluation. It is worth contacting the marshal office of the relevant voivodeship.
Capital budget versus operational budget. Beyond external grants, hospitals should incorporate cybersecurity into both capital budgets (one-off equipment purchases, software licences, implementations) and operational budgets (subscription-based security services, training, penetration tests). The subscription model, offered by companies such as nFlo in the form of Managed Detection & Response (MDR) or SOC as a Service, makes it possible to avoid large one-off capital expenditures and spreads costs into fixed monthly payments that can be more easily incorporated into a hospital’s operational budget.
Hospitals that have difficulty financing cybersecurity from their own budget should check the KPO and ROP programmes and support from the Centre for e-Health. The SOC as a Service model makes it possible to avoid large one-off investments while maintaining full protection.
One practical note: the cost of implementing cybersecurity should always be compared to the cost of an incident. Restoring systems after a ransomware attack in a medium-sized hospital costs from several to several dozen million zlotys, not counting operational losses, compensation to patients and any regulatory fines. A well-planned cybersecurity programme is a fraction of these costs — and an argument worth presenting to the hospital board or the founding body when applying for an increase in the IT budget.
How does nFlo support medical facilities in building cyber resilience?
The healthcare sector is one of the key areas in which nFlo delivers projects. We understand the specifics of this environment — the tension between clinical operational continuity and the necessity of implementing security measures, the budgetary constraints of public entities, the complexity of IT ecosystems with multiple suppliers and stringent regulatory requirements. Working with over 200 clients and on over 500 projects across various sectors, we have developed an approach that works in environments where security must go hand in hand with availability.
Our engagement in a healthcare project typically begins with a comprehensive security audit, which is the foundation of all subsequent work. The audit covers assessment of network architecture (identification of flat networks and absence of segmentation), review of the configuration of key systems (HIS, PACS, infrastructure), evaluation of identity and access management, analysis of backup and recovery procedures and an initial assessment of compliance with NIS2, GDPR and KRI. The result of the audit is a prioritised list of recommendations — not a generic checklist, but a concrete action plan that takes into account the budgetary and operational realities of the facility.
We specialise in the design and implementation of network segmentation in hospital environments. A segmentation project in an operating hospital requires exceptional planning in order not to disrupt the continuity of ward operations. Every change to the network architecture must be tested in a laboratory environment, deployed in stages and with the possibility of immediate rollback. Our team has carried out segmentation deployments in hospitals operating 24 hours a day, without any interruption to their functioning.
We carry out penetration tests of hospital infrastructure in a controlled manner adapted to the requirements of the clinical environment. Our tests are designed so as not to interfere with operating critical systems — we focus on identifying vulnerabilities without actively exploiting them in a way that could disrupt hospital operations. Test results are presented in a form comprehensible to management — not merely as a list of CVEs, but as a map of business risks with recommended remediation actions.
Our SOC team provides security monitoring services in the MDR (Managed Detection and Response) model with a guaranteed response time of less than 15 minutes from threat detection. For a hospital where every minute counts, such a response time is significant. 98% of our clients who have used SOC services renew their contract — which is for us a measure of the real value we deliver.
We also assist in preparing for ISO 27001 certification and NIS2 compliance audits, developing security policies, incident response procedures and business continuity plans. We have experience working with the founding bodies of public hospitals (local governments, the ministry of health) and understand the documentation and reporting requirements that are specific to the public sector.
FAQ — frequently asked questions
Is a small district hospital also subject to NIS2 requirements?
Yes, if the hospital is classified as an essential entity under the Act on the National Cybersecurity System (the amendment implementing NIS2). The classification criterion is primarily the role in the healthcare system — the majority of hospitals providing inpatient health services will be covered by the requirements. It is worth contacting the supervisory authority or seeking legal advice to confirm the classification.
What happens if a hospital does not implement NIS2 requirements on time?
The supervisory authority may impose financial penalties (up to 10 million euros or 2% of turnover), order a security audit at the entity’s expense, order the implementation of specific technical or organisational measures and, in extreme cases, suspend the ability to hold managerial positions for the persons responsible for the omission.
How much does a basic cybersecurity programme for a hospital cost?
The cost depends on the size of the facility, the current state of its security measures and the scope of the project. As a rough indication, a comprehensive security audit for a medium-sized hospital costs 30,000–80,000 PLN. Implementing network segmentation and basic security measures is 100,000–500,000 PLN as a one-off investment, plus operational costs. The MDR/SOC as a Service model for a hospital most commonly amounts to several dozen thousand PLN per month depending on scale. By comparison, the cost of recovery after a ransomware attack is a multiple of these amounts.
Is patient data in the cloud safe?
It depends on the specific solution and how it is implemented. Reputable cloud providers (Microsoft Azure, AWS, Google Cloud) meet very high security standards and hold relevant certifications (ISO 27001, SOC 2, HIPAA for the American market). However, it is crucial to ensure that access configuration, encryption, key management and backups are properly implemented on the hospital’s side — because this is the most common source of incidents in cloud environments.
How do you convince the hospital board to invest in cybersecurity?
The most effective arguments are: the specific costs of incidents at similar facilities (examples from HSE, Otwock, the Children’s Health Centre), the amounts of fines for NIS2 and GDPR violations, the cost of operational downtime calculated in terms of lost NFZ contracting and the personal legal liability of management board members. Presenting the results of a security audit that exposes specific vulnerabilities “on one’s own doorstep” is often more persuasive than general industry statistics.
Related concepts
Explore the key terms related to this article in our cybersecurity glossary:
- Ransomware — Ransomware is a type of malicious software (malware) that blocks access…
- Cybersecurity — Cybersecurity is a set of techniques, processes and practices for protecting IT systems,…
- Network segmentation — Network segmentation is the division of network infrastructure into isolated zones…
- SOC 2 — SOC 2 is an AICPA audit standard assessing security, availability controls…
- Business continuity plan — A business continuity plan (BCP) is a set of procedures and documents…
Learn more
Explore related articles in our knowledge base:
- Cybersecurity in the healthcare sector: How to protect patient data and critical hospital infrastructure?
- NIS2 for the healthcare sector: Specific requirements and implementation deadlines
- How is the NFZ raising cybersecurity standards in Poland?
- Personal liability of management for cybersecurity in the light of NIS2
- The 3-2-1 backup rule — foundations of a secure IT infrastructure
Check our services
Do you need cybersecurity support for a medical facility? See:
- Security audits - comprehensive assessment of the state of security
- Penetration testing - identification of vulnerabilities in infrastructure
- SOC as a Service - round-the-clock security monitoring with a response time of under 15 minutes
Sources
- IBM Security, Cost of a Data Breach Report 2024, IBM Corporation, 2024. Available at: https://www.ibm.com/reports/data-breach
- Halpern, S.D. et al., Ransomware Attack Associated With Disruptions at Adjacent Hospital When System Down, Health Affairs, vol. 40, no. 4, 2021.
- European Union Agency for Cybersecurity (ENISA), Health Threat Landscape 2023, ENISA, 2023. Available at: https://www.enisa.europa.eu/publications/health-threat-landscape
- Directive of the European Parliament and of the Council (EU) 2022/2555 of 14 December 2022 on measures for a high common level of cybersecurity (NIS2 Directive), OJ EU L 333/80, 2022.
- Act of 5 July 2018 on the national cybersecurity system (Journal of Laws 2018, item 1560) as amended.
- Regulation of the European Parliament and of the Council (EU) 2016/679 (GDPR), OJ EU L 119/1, 2016.
- Regulation of the Council of Ministers of 12 April 2012 on the National Interoperability Framework (KRI), Journal of Laws 2012, item 526.
- Perlroth, N., This Is How They Tell Me the World Ends: The Cyberweapons Arms Race, Bloomsbury Publishing, 2021.
- CERT Polska, Security landscape of the Polish internet — CERT Polska report 2023, NASK, 2024. Available at: https://cert.pl/publications/
- Europol, Internet Organised Crime Threat Assessment (IOCTA) 2023, Europol, 2023. Available at: https://www.europol.europa.eu/publications-events/main-reports/iocta-report
Need expert support? nFlo team can help secure your organization:
Related topics
See also:
