An audit that strengthened the IT team instead of replacing it: a medical clinic ahead of NIS2

Context

The clinic has its own IT team that runs the practice systems, medical records and the network across two buildings. Upcoming NIS2 requirements and growing expectations from business partners led management to want an independent, technical picture of security and an action plan before someone from outside asked for it.

The clinic's IT team asked for support from someone with experience in large, regulated environments. Not to be replaced, but to work out together what is really a risk and what only looks alarming on paper, and which technical topics needed consultation or implementation.

Challenge

• A medical facility is not an officeAlongside computers there are diagnostic devices, practice systems and medical records, which external vendors also access. Downtime means cancelled appointments, and a breach concerns health data.
• NIS2 says what must be achieved, not howRisk analysis, business continuity, incident management, supply-chain security and access control had to be translated into a specific network, specific servers and specific people.
• The in-house team knows the environment but lacks distanceA partnership approach was needed: joint work without judgement and without a report that ends up on a shelf.

What we did

1Working rules

At the first meeting we agreed the roles: the clinic's IT team leads, we bring experience, questions and patterns from larger environments. Every finding goes to a shared risk list, and the clinic's management sets priorities based on the impact on patients and operations.

2Technical infrastructure review

Together we went through the network and its segmentation, servers and practice systems, medical records and backups, workstations and medical devices, user and vendor access, remote access, updates, event logging and incident procedures.

3A jointly agreed risk list

The areas that needed attention were those typical for medical facilities of this size: separating medical device and practice system traffic from the office part, confirming that medical record backups can be restored and how long it takes, controlling vendors' remote access, a second authentication factor for remote access and admin accounts, a NIS2-compliant incident procedure, and order in privileged accounts. The detailed findings remain confidential.

4An action plan ordered by patient impact

For each risk we agreed what to do, who does it (the clinic's team, us, a vendor), what it costs and what happens if it is postponed. Management could set priorities in the language of the facility's operations, not in technical terms.

5Implementing selected topics and handing over knowledge

Some actions the clinic's team carried out on its own, some we delivered together. Every solution was documented so the clinic's IT staff can maintain it without us.

Under the hood

• Method: technical review with the client's team, risk list rated by impact on patients and operations, action plan with owners and costs.
• Reference: NIS2 requirements for risk analysis, business continuity, incidents, supply chain and access control.
• Scope: two buildings, practice systems and medical records, networked medical devices, vendor access.
• Disclaimer: a technical assessment with recommendations, not a certification audit and not legal advice.

Result

• The clinic's management has a risk list in the language of patient impact and an action plan with order, cost and ownership.
• The clinic's IT team received support, not a verdict; the knowledge stayed with them.
• The most urgent technical topics were addressed together, and the remaining ones have an owner and a deadline.
• The clinic has a basis for NIS2 conversations with partners, insurers and auditors.

Why this matters for other companies

NIS2 will cover many healthcare providers, and readiness is not about buying a device or producing a report. It is about the people who know the facility from the inside having someone next to them who has seen how it is done in large, regulated organisations. That is the working model we call IT team support.

For confidentiality, detailed findings, figures and system names are omitted; the description of risk areas is generalised.