NIS2 compliance means healthcare organizations must now prove that cybersecurity risk is managed at every level: internal systems, suppliers and reporting lines. That requirement is pulling security out of the IT department and into the boardroom. The organizations struggling most aren't the ones lacking tools. They're the ones lacking people who can connect law, controls and clinical operations.

For years, healthcare cybersecurity ran on NEN 7510, the Dutch standard for information security in healthcare. That standard hasn't disappeared. But the legal duty of care around it has become sharper, and with it comes a set of roles that most healthcare organizations simply don't have on the payroll yet. This isn't a story about new software. It's a story about who gets hired next.

Healthcare providers, pharmaceutical companies and medical-device manufacturers that meet certain size thresholds now fall under a formal duty of care, an incident-reporting duty, and an obligation to inform affected parties during serious threats. This applies regardless of whether the organization feels ready for it.

The size threshold is not trivial. Organizations with at least 50 employees, or those exceeding roughly €10 million in turnover and balance-sheet total according to Dutch government guidance, generally fall in scope. That covers a lot more than hospitals. Software vendors, hosting providers and medical-device suppliers are pulled in too, depending on their size and activities.

NEN 7510 still matters. In fact, NEN itself has advised organizations to build on their existing NEN 7510 approach rather than start from scratch. But NEN 7510 was always about information security. The new legal framework adds governance, continuity and supply-chain accountability on top. Those are different skills.

NEN 7510 protects patient data and information systems. The broader legal duty goes further: it also covers organizational resilience, supplier risk and demonstrable management oversight. An organization can be fully aligned with NEN 7510 and still fall short on the governance side.

That distinction is not academic. Certification under NEN 7510 isn't automatically a legal requirement on its own, but organizations still need to show the relevant controls are in place and working, as NEN explains. That means audit trails, control testing and evidence packs, not just a policy document sitting in a shared drive.

The current standard consists of two parts: NEN 7510-1 for the management system and NEN 7510-2 for the actual security controls, with an amendment to the controls part expected in 2026. Someone in the organization has to actually own this mapping between the standard and the new legal duty. In most healthcare organizations, nobody does yet.

Organizations must assess digital dependencies and risks involving suppliers and other parties in the chain, rather than limiting controls to their own networks.

That supplier clause is where a lot of healthcare organizations get caught out. Outsourcing your hosting, your EHR platform or your medical devices does not outsource your responsibility. If a supplier gets breached, the healthcare organization is still accountable for having assessed that risk in advance.

Recruiting for cybersecurity used to mean finding a solid security analyst or a network engineer with a security focus. That's no longer enough. The roles healthcare organizations need now sit at the intersection of law, technology and clinical operations.

A few profiles are becoming genuinely critical. A healthcare-focused CISO who can translate risk into board language. A NEN 7510 or ISO 27001 compliance lead who can turn control frameworks into legal evidence. A third-party risk manager who can actually challenge a cloud vendor or a device manufacturer on their security posture, not just tick a box on a questionnaire.

None of these are entry-level hires. They require someone who understands legacy medical devices that can't simply be patched, clinical workflows that can't tolerate downtime, and a regulatory framework that keeps evolving. If you're building a security team around information security analysis, this is the layer above that role: someone who owns the whole risk picture, not just the technical controls.

The scarcity here isn't really about a shortage of cybersecurity people. It's about a shortage of cybersecurity people who also understand healthcare operations, audit requirements and supplier negotiation. That combination is rare.

Healthcare also competes for this talent against sectors with deeper pockets. Banks and defense contractors can often pay more and offer faster technical environments. A healthcare organization pitching a governance-heavy compliance role against a bank's cybersecurity engineering role isn't always winning that comparison on salary alone.

There's a third factor: legacy complexity. Hospital networks run on systems that were never designed with today's threat model in mind. Candidates need real experience with connected medical devices, older infrastructure and the privacy constraints that come with patient data. That raises the experience bar significantly, which shrinks the pool even further.

A short one to sit with:

Consultants can't own accountability.

External advisory firms can speed up an assessment or help build a framework. But once the engagement ends, someone internal has to remain accountable for the risk. That's not a role you can permanently outsource, no matter how good the advisory firm is.

Healthcare buyers are going to ask harder questions of their suppliers. Expect procurement cycles to slow down as buyers request NEN 7510 evidence, penetration-test summaries, incident histories and subcontractor details before signing anything.

For vendors and suppliers to healthcare, that's a real shift. Security used to be a line item you could underfund without immediate consequence. Now it's part of the sales conversation. A vendor that can walk into a tender with a documented security program has a genuine edge over one that can't.

This also changes the shape of engineering teams inside vendors. Product-security specialists and secure-development engineers stop being a nice-to-have and start being a condition for winning healthcare contracts. If you're already building out engineering capacity, roles like a senior software engineer with security-aware development experience or a senior AI engineer working on data-sensitive healthcare products both need to understand this shift, even if security isn't their formal title.

We've seen this pattern before with other regulatory shifts. It looks a lot like what happened around the Cyber Resilience Act pushing compliance hiring into product teams, and it echoes the skills gap we've tracked in OT security hiring under NIS2. Regulation creates demand for hybrid profiles faster than the market can produce them.

Our approach is straightforward. We don't start sourcing until the intake makes clear what the role actually needs: technical depth, regulatory literacy, or both. That intake conversation often surfaces that a client thinks they need a security engineer when they actually need a GRC analyst, or the other way around. Getting that wrong wastes months.

We're not engineers ourselves. We're recruiters who've spent enough time in this market to ask the right questions before we start sourcing. That's the whole point of a structured process: fewer wrong hires, less wasted interview time, and candidates who actually know what they're walking into.

NIS2 compliance did more than add paperwork to healthcare. It created a set of roles that barely existed a few years ago: hybrid profiles that understand law, controls, suppliers and clinical operations all at once. Healthcare organizations that treat this as a hiring problem, not just a policy problem, will be in a much stronger position when the next audit or incident comes.

If you're trying to figure out which of these roles you actually need first, that's exactly the kind of intake conversation we're built for.

1. Cyberbeveiligingswet in de zorg: bouw voort op NEN 7510
2. NEN 7510: informatiebeveiliging in de zorg
3. Cyberbeveiligingswet | Data voor gezondheid
4. Voor wie is NEN 7510? - ICT in de zorg
5. [PDF] kst-27529-353.pdf - Overheid.nl > Officiële bekendmakingen
6. Cbw (NIS2) Control Framework uitgebreid: sector zorg en ...

Written by our AI, read by a flesh-and-blood recruiter.