Pentestrapport

Når jeres software selv er medicinsk udstyr: sikkerhedstest i MDR‑dokumentationen

Når jeres software selv er medicinsk udstyr: sikkerhedstest i MDR-dokumentationen

Et softwarehus, hvis produkt er medicinsk udstyr, står med en pentest, der skal bruges to steder: i den tekniske dokumentation efter forordningen om medicinsk udstyr (MDR) og over for de hospitaler og klinikker, der køber produktet. Svaret på, hvad testen skal kunne, hviler på forordningens krav til software i bilag I og bilag II og på vejledningen MDCG 2019-16 om cybersikkerhed fra Medical Device Coordination Group, som Europa-Kommissionen offentliggør. Vejledningen nævner penetrationstest som en af metoderne til at verificere sikkerheden. Teksten her er ikke juridisk eller regulatorisk rådgivning.

I er fabrikanten

Efter MDR artikel 2, nr. 1, kan software selv være medicinsk udstyr, når den ifølge fabrikanten er bestemt til et medicinsk formål, fx diagnosticering, monitorering eller behandling. Er det jeres produkt, er I fabrikant med de pligter, forordningen giver, og testen er en del af jeres egen dokumentation, ikke et svar på en kundes krav.

Det adskiller jer fra en leverandør, der leverer en komponent eller en tjeneste til en anden fabrikant, og fra hospitalets IT-afdeling, der skal have udstyret til at fungere sikkert på sit netværk. Den sidste vinkel er beskrevet på penetration-test.dk.

Lægemiddelstyrelsen fører tilsyn med medicinsk udstyr i Danmark, men godkender ikke udstyret. For udstyr over den laveste klasse skal et bemyndiget organ medvirke i vurderingen, før CE-mærkningen.

Kravene til software i bilag I

Bilag I indeholder de generelle krav til sikkerhed og ydeevne. Fire punkter vedrører sikkerheden i software direkte:

  • Punkt 17.2 · software udvikles og fremstilles efter det aktuelle tekniske niveau under hensyn til udviklingslivscyklus, risikostyring, herunder informationssikkerhed, verifikation og validering.
  • Punkt 17.4 · fabrikanten fastlægger mindstekrav til hardware, IT-netværksegenskaber og IT-sikkerhedsforanstaltninger, herunder beskyttelse mod uautoriseret adgang.
  • Punkt 18.8 · udstyr designes, så der i videst muligt omfang beskyttes mod uautoriseret adgang, som kan hindre det i at fungere efter hensigten.
  • Punkt 23.4, litra ab · brugsanvisningen skal indeholde de samme mindstekrav som i 17.4.

Forordningen nævner ikke penetrationstest. Den kræver verifikation og validering, der tager højde for informationssikkerhed. Hvordan I verificerer, er op til jer som fabrikant at begrunde.

Det, MDCG 2019-16 siger om test

MDCG 2019-16 er Medical Device Coordination Groups vejledning om cybersikkerhed for medicinsk udstyr. Den gældende udgave er revision 1 fra juli 2020. Vejledningen er ikke juridisk bindende.

Afsnit 3.7 knytter verifikation og validering til punkt 17.2 og siger, at det primære middel til at verificere og validere sikkerheden er test. Som metoder nævnes test af sikkerhedsfunktioner, fuzztest, sårbarhedsscanning og penetrationstest. Derudover nævnes analyse af kildekode og af de open source-komponenter, produktet bruger.

Vejledningen taler også om fælles ansvar. Afsnit 2.6 understreger, at fabrikanter, leverandører, sundhedsvæsenet, integratorer og andre har hver sin del af ansvaret for et sikkert miljø, og afsnit 4.3 beskriver de oplysninger, fabrikanten kan give sundhedsvæsenet om det miljø, udstyret skal fungere i. → Kundernes eget ansvar

Testen i den tekniske dokumentation

Bilag II beskriver den tekniske dokumentation. Punkt 6 kræver resultater og kritiske analyser af al verifikation og validering, der skal vise, at udstyret opfylder de generelle krav. Under punkt 6.1, litra b, står softwareverifikation og validering: en beskrivelse af softwaredesign og udviklingsproces og dokumentation for validering af softwaren, som den anvendes i det færdige udstyr, herunder de hardwarekonfigurationer og styresystemer, fabrikanten angiver.

For pentesten betyder det:

  • Version · rapporten skal kunne knyttes til den softwareversion, der indgår i udstyret.
  • Konfiguration · testmiljøet skal svare til de konfigurationer, I angiver i dokumentationen.
  • Sammenhæng med risikostyringen · omfanget skal kunne forklares ud fra jeres risikovurdering.
  • Fund og rettelser · status på fund skal kunne følges til den version, der frigives.

En rapport, der kun beskriver en webportal i produktionsmiljøet, kan være for løs til det formål. → Version og testdatoer

Hvorfor Cyber Resilience Act ikke gælder for udstyret

Forordning (EU) 2024/2847 om cyberrobusthed gælder efter artikel 2, stk. 2, litra a, ikke for produkter, som MDR finder anvendelse på. Sikkerhedskravene til jeres medicinske software kommer derfor fra MDR. Sælger I også produkter, der ikke er medicinsk udstyr, fx et administrationsværktøj uden medicinsk formål, skal de vurderes for sig. → Cyber Resilience Act

Samme test over for hospitaler og klinikker

Hospitaler og klinikker kan bede om dokumentation for test, inden de tager produktet i brug. De har ikke brug for hele den tekniske dokumentation, men for at vide, hvad der er testet, hvilken version det gjaldt, og hvad de selv skal sørge for i deres miljø.

Planlæg derfor to udtræk af samme test. Den fulde rapport hører til den tekniske dokumentation. En kundeversion eller et resumé går til kunderne sammen med jeres mindstekrav til netværk og sikkerhed efter punkt 17.4. Så hænger testen, brugsanvisningen og svaret til kunden sammen. → Kundeversionen af rapporten

Test aldrig med rigtige patientdata. → En kunde i sundhedssektoren vil se dokumentation

Efter MDR artikel 83 skal I også overvåge udstyret, når det er bragt i omsætning. Nye sårbarheder i komponenter eller nye fund kan kræve en ny vurdering og en ny test af en ny version. Planlæg derfor, hvordan resultater fra overvågningen fører tilbage til risikostyringen og til næste test, så dokumentationen ikke stopper ved lanceringen.

Tjekliste før testen bestilles

  • ☐ Den softwareversion, der skal indgå i udstyret, er fastlagt.
  • ☐ Testmiljøet svarer til de konfigurationer, dokumentationen angiver.
  • ☐ Omfanget er begrundet i jeres risikovurdering.
  • ☐ Det er aftalt, at rapporten skal kunne bruges i den tekniske dokumentation.
  • ☐ Der laves et udtræk til hospitaler og klinikker.
  • ☐ Testdata er opdigtede.
  • ☐ Status på fund kan følges til den frigivne version.

Det skal I lade være med

  • At skrive, at produktet er MDR-godkendt efter en pentest · testen er en del af verifikationen, ikke en godkendelse.
  • At henvise til CRA for det medicinske udstyr · artikel 2, stk. 2, undtager det.
  • At teste en anden version end den, der frigives · dokumentationen skal vise den version, der indgår i udstyret.
  • At sende den fulde rapport til hospitalet · send et udtræk og jeres mindstekrav.
  • At bruge MDCG 2019-16 som bindende krav over for kunden · vejledningen er ikke juridisk bindende.

Hvad kan og ikke kan konkluderes

MDR kræver verifikation og validering af software med hensyn til informationssikkerhed, og MDCG 2019-16 peger på test, herunder penetrationstest, som det primære middel. En pentest kan vise, hvad en tester kunne gøre mod en bestemt version i en bestemt konfiguration. Den viser ikke, at udstyret opfylder forordningen. Det er jeres vurdering som fabrikant, et bemyndiget organs vurdering, hvor det medvirker, og myndighedernes tilsyn.

Kilder

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler om pentestrapporten

Læs også: Open source og tredjepartskomponenter · Retest efter rettelser i en ny release

→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest af SaaS hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Kræver kunden en pentestrapport?

Skriv kort, hvilket krav kunden har stillet, og hvornår dokumentationen skal ligge klar. Så vender jeg tilbage. Testen og rådgivningen er uvildige og uafhængige, og Nielco IT har ikke indgået forhandleraftaler med leverandører.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.