Leverandør til hospitaler, klinikker og sundhed

En leverandør af journalsystem, bookingløsning, laboratorieintegration eller drift til et hospital eller en klinik kan få et krav om sikkerhedstest, der henviser til NIS2. Før I svarer, er det værd at vide, hvilke regler kunden selv er under, og hvilken myndighed kunden svarer til. Svaret hviler på NIS 2-lovens bilag 1, pkt. 5, om sundhed, og på bekendtgørelse nr. 620 af 2. juni 2025, der gør Sundhedsdatastyrelsen til kompetent myndighed for sektoren og for regionerne.

Det følgende er skrevet til leverandøren. Køberens side af en test i sundhedssektoren er beskrevet generelt på penetrationtest.dk. Teksten er ikke juridisk rådgivning.

Hvem kunden er efter loven

Bilag 1, pkt. 5, nævner flere typer enheder under sundhed, bl.a. sundhedstjenesteydere, EU-referencelaboratorier, enheder, der forsker i og udvikler lægemidler, enheder, der fremstiller farmaceutiske præparater, og enheder, der fremstiller medicinsk udstyr, som anses for kritisk i en folkesundhedsmæssig krisesituation.

Regionerne som kunde. Regionerne står under offentlig forvaltning i bilag 1, pkt. 10. Styrelsen for Samfundssikkerhed skriver i sin vejledning om anvendelsesområdet, at alle regioner forventes at være omfattet som væsentlige enheder, og at hele regionens CVR-nummer er omfattet, også de dele, der ikke har med sundhed at gøre. Leverer I til en regional administration eller institution uden for hospitalerne, kan kravet derfor have samme grundlag som på et hospital.

At en kunde er en sundhedstjenesteyder, gør den ikke automatisk omfattet. Lovens §§ 4 og 5 knytter status som væsentlig eller vigtig enhed til bl.a. antal ansatte, omsætning og balance, med visse undtagelser. En mindre klinik kan derfor stå uden for loven og alligevel stille krav, fx ud fra databeskyttelsesreglerne eller egen risikovurdering. Spørg, hvad kravet bygger på. → Selv omfattet eller kun kunden?

Producenter af medicinsk udstyr generelt står i bilag 2, pkt. 5, litra a, og har også Sundhedsdatastyrelsen som myndighed efter bekendtgørelsens § 4, nr. 2. Det er et emne for sig. → Leverandør til producenter af medicinsk udstyr

Lægemiddelvirksomheder. Enheder, der forsker i og udvikler lægemidler, og enheder, der fremstiller farmaceutiske råvarer og præparater, står i bilag 1, pkt. 5. Fordi typen er nævnt i bilag 1, kan sådan en kunde blive væsentlig enhed alene på grund af sin størrelse efter § 4, stk. 1. For en leverandør til en lægemiddelproducent kan det være produktionens styringssystemer, laboratoriesystemerne og fjernsupporten, kunden er afhængig af, og testen skal planlægges, så den ikke forstyrrer produktionen. → Produktionsudstyr og OT

Myndigheden bag kravet

Efter bekendtgørelse nr. 620, § 4, nr. 1, er Sundhedsdatastyrelsen kompetent myndighed for enheder i sektoren for sundhed. Efter § 2, nr. 1, er den også myndighed for regionerne. Et hospital, der drives af en region, og en privat klinik kan altså have samme myndighed, selv om de står forskellige steder i bilaget. → Hvem fører tilsyn med jeres kunde?

Kravet til jer bygger på lovens § 6, stk. 1, nr. 4, om forsyningskædesikkerhed. Kunden skal tage stilling til sikkerheden i forholdet til direkte leverandører og tjenesteudbydere og kan derfor bede jer dokumentere, at det, kunden er afhængig af, er afprøvet.

Hvad kunden kan være afhængig af hos jer

En leverance til sundhed kan bestå af flere dele, og hver del kan have sin egen betydning for kunden:

Systemet · den løsning, personalet bruger, med roller, adgang til oplysninger og eventuel patientadgang.
Integrationerne · forbindelser til andre systemer hos kunden, fx laboratorie, billeddiagnostik eller fakturering. → Integration med kunden
Supportadgangen · den vej, jeres medarbejdere bruger, når de hjælper kunden eller opdaterer systemet. → Jeres supportadgang til kunden
Udstyret · apparater, som I installerer, servicerer eller overvåger på afstand.
Driften · servere eller cloudmiljøer, I driver på kundens vegne.

Testen bør tage udgangspunkt i, hvilke af delene kunden faktisk spørger til, og hvad kunden er afhængig af. Det er ikke givet, at alle dele skal testes på én gang. En plan, der viser, hvornår hver del bliver testet, kan være et bedre svar end en stor test, der forsøger at nå det hele. Fortæl kunden, hvilken del I starter med, og hvorfor netop den del er vigtigst for kunden.

Data og drift under testen

To forhold kræver særlig omtanke, når testen gælder en sundhedsleverance.

Det første er oplysningerne. Systemet kan rumme helbredsoplysninger, og en test i produktion kan give testeren adgang til dem. Aftal derfor, om testen kan ske i et testmiljø med fiktive data, og hvis ikke, hvordan testeren håndterer oplysninger, der bliver synlige, og hvad der må stå i rapporten. → Scope og fortrolighed

Det andet er driften. Har kunden døgndrift, findes der ikke et tidspunkt, hvor systemet ikke bruges. Aftal med kunden, hvornår testen er mindst forstyrrende, hvem der kan stoppe den, og hvordan kunden får besked, hvis noget går galt. Dele, der styrer udstyr i brug, bør kun afprøves efter særskilt aftale med en driftsansvarlig hos kunden.

Dokumentationen til en sundhedskunde

Kunden har brug for at kunne vise sin egen ledelse og eventuelt sin myndighed, at leverandørforholdet er vurderet. Det kræver ikke nødvendigvis hele rapporten. Et resumé kan dække behovet, hvis det indeholder:

Omfanget · hvilke af leverancens dele der var med, og hvilke der ikke var.
Tidspunktet · hvornår testen blev udført, og om den gjaldt den version, kunden bruger.
Resultatet · de væsentligste fund i almindelige ord, med en vurdering af alvoren.
Opfølgningen · hvad der er rettet, og hvad der står åbent med en plan.

Har I flere sundhedskunder på samme system, kan den fælles del dokumenteres én gang. Kundespecifikke dele, fx en integration, der kun findes hos én kunde, skal beskrives særskilt. Oplysninger, der kan pege på en anden kunde, hører ikke hjemme i resuméet. → Fire oplysninger om testen

Et tænkt eksempel

En leverandør af et bookingsystem til privathospitaler får et spørgeskema fra en ny kunde med spørgsmål om test, fjernadgang og hændelser. Leverandøren har en test af bookingsystemet, men testen er lavet i et miljø med rigtige patientdata fra en anden kunde, og rapporten rummer skærmbilleder fra det miljø. Leverandøren sender ikke rapporten, men et resumé uden skærmbilleder, og aftaler, at den næste test sker i et testmiljø med fiktive data. Supportadgangen kommer med i den næste test, fordi kunden spurgte særskilt til den.

Det skal I lade være med

At antage, at alle sundhedskunder er under NIS 2-loven · størrelse og type afgør det.
At teste med rigtige patientdata, når et testmiljø kan bruges · det skaber unødige risici for oplysningerne.
At sende rapporter med oplysninger fra andre kunder · et resumé kan svare på kundens spørgsmål.
At teste dele, der styrer udstyr i brug, uden særskilt aftale · driften hos kunden går forud.
At svare uden at kende kundens myndighed · Sundhedsdatastyrelsen kan have sit eget sprog for kravene.

Hvad kan og ikke kan konkluderes

En test af det, sundhedskunden er afhængig af, kan vise, hvad der kunne lade sig gøre i systemet, integrationerne og supportadgangen på testtidspunktet. Den kan ikke afgøre, om kunden overholder NIS 2-loven eller databeskyttelsesreglerne, og den siger ikke noget om dele, der ikke var med. Kunden vurderer selv, om dokumentationen er tilstrækkelig.