En kunde i sundhedssektoren vil se dokumentation for test

En klinik, en privat sundhedsvirksomhed eller en leverandør til sundhedsvæsenet, der vil bruge jeres produkt, ser anderledes på sikkerheden end en almindelig kunde. Data om patienter og helbred er særligt følsomme, og kunden skal kunne forklare, hvorfor det er forsvarligt at lægge dem hos jer.

Svaret hviler på to ting: at testen dækker de dele af produktet, der beskytter de følsomme oplysninger, og at hverken testen eller rapporten selv kommer til at omfatte rigtige patientdata. Når de to ting er på plads, kan dokumentationen bruges i kundens egen vurdering.

Følsomme data skærper spørgsmålene

Databeskyttelsesforordningen behandler helbredsoplysninger som en særlig kategori af personoplysninger i artikel 9. Artikel 32 kræver, at den, der behandler personoplysninger, har et sikkerhedsniveau, der passer til risikoen, og nævner blandt andet en procedure for regelmæssig afprøvning, vurdering og evaluering af, om foranstaltningerne virker.

For kunden betyder det, at spørgsmålet om test ikke kun er et indkøbskrav, men en del af kundens egen vurdering af risikoen. Derfor kan spørgsmålene være mere præcise, og kunden vil vide, hvad testen faktisk har afprøvet. En kunde, der selv skal kunne vise en procedure for regelmæssig afprøvning, kan også være interesseret i, hvor ofte I tester, og hvordan I vurderer nye funktioner mellem to test. Et svar med en fast rytme og en praksis for releases kan derfor være lige så vigtigt som selve rapporten. Teksten er ikke juridisk rådgivning, og det er kunden, der vurderer sine egne pligter. → GDPR artikel 32 og regelmæssig afprøvning

Det, kunden gerne vil vide om produktet

Kundens spørgsmål kredser om, hvem der kan se hvad. Forbered svar, der hver især kan underbygges af testen eller af anden dokumentation:

Adgangsstyring · hvordan login og adgang til de følsomme oplysninger er beskyttet.
Roller · om en medarbejder kun ser det, rollen giver adgang til, også i eksport og rapporter.
Adskillelse · om en klinik kan komme i nærheden af en anden kundes oplysninger.
Revisionsspor · om kunden kan se, hvem der har set eller ændret oplysninger.
Jeres egen adgang · hvordan jeres supportmedarbejdere får adgang, og hvordan det registreres.

Svarene bør kunne genkendes i rapporten, så kunden kan se, at de hviler på noget, der er afprøvet. Hvis testen ikke har dækket et af punkterne, så sig det. En kunde i sundhedssektoren vil hellere have et ærligt hul end en rapport, der læses bredere, end den kan bære. → Roller og rettigheder i produktet

Testen skal dække det, der beskytter oplysningerne

Når testen planlægges, bør omfanget afspejle kundens bekymringer. Adskillelsen mellem kunder, rollerne inden for den enkelte kunde og de funktioner, der giver adgang til mange oplysninger på én gang, som søgning, eksport og rapporter, er oplagte at tage med. → Multi-tenant: test af adskillelsen

Tag også de administrative funktioner med, som jeres egne medarbejdere bruger. Det gælder både supportadgangen og de værktøjer, der bruges til at oprette kunder, flytte data eller lukke en konto. En kunde, der har ansvar for patientdata, vil vide, om softwarehusets egen adgang er afgrænset og sporbar. Hvis produktet giver kunden et revisionsspor, kan testen også se på, om sporet registrerer det, det lover. → Logning og revisionsspor

Ingen rigtige patientdata i testen

Testen bør foregå med opdigtede testdata i et miljø, hvor rigtige patientoplysninger ikke er til stede, eller i testkunder, der er helt adskilt fra rigtige kunder. Det beskytter patienterne, og det betyder, at testeren ikke ser oplysninger, testeren ikke har brug for. Aftal det med testeren før start, og beskriv i rapporten, hvor testen blev gennemført.

Testdata skal stadig ligne virkeligheden nok til, at testen giver mening. Hvis produktet har særlige felter til helbredsoplysninger, journalnotater eller vedhæftede dokumenter, bør testkunderne have opdigtet indhold i netop de felter. Ellers kan testen overse, hvordan produktet håndterer de oplysninger, kunden er mest optaget af.

Hvis kunden ønsker, at testen foregår med deres opsætning, skal det aftales med kunden, hvordan det sker uden rigtige data. En kopi af opsætningen med opdigtede patienter kan være en mulig vej, men den skal aftales, før testen går i gang. → Rigtige kundedata i testen

Rapporten må ikke selv blive et problem

En pentestrapport bør ikke indeholde personoplysninger om patienter. Hvis testeren alligevel støder på rigtige data, bør det beskrives uden at gengive dem. Gennemgå rapporten med det for øje, før den sendes videre. Det gælder også skærmbilleder og bilag, hvor oplysninger let kan snige sig med, selv når teksten er ren.

Overvej også, hvordan rapporten udleveres. En sundhedskunde vil måske selv have faste regler for, hvordan følsomme dokumenter modtages og opbevares, og det er nyttigt at spørge til dem i forvejen. → Læseadgang eller vedhæftet fil

Svaret til kunden

Saml jeres svar i en kort beskrivelse: hvad testen dækkede af de punkter, kunden spurgte om, hvor den blev udført, hvilken version den gjaldt, og hvordan fund er håndteret. Henvis til rapporten eller resuméet for detaljer. Beskriv også, hvordan I vurderer ændringer i produktet mellem to test, så kunden kan se, at afprøvningen ikke stopper ved én rapport. Hvis kunden har en sektorstandard eller egne krav, så svar efter dem, og lov ikke mere, end testen viser. → Sektorkrav hos kunderne

Datatilsynet har vejledning om behandlingssikkerhed, herunder et katalog over tekniske og organisatoriske foranstaltninger. Det kan være nyttigt at kende den, så I bedre forstår den sammenhæng, kundens spørgsmål kan komme fra.

Det skal I lade være med

At teste med rigtige patientdata · Opdigtede testdata i et adskilt miljø er udgangspunktet.
At lade rapporten gengive personoplysninger · Fund kan beskrives uden at vise data.
At skrive, at produktet opfylder GDPR · Det er kundens vurdering, og testen er kun en del af grundlaget.
At udelade jeres egen supportadgang · Kunden vil vide, hvem hos jer der kan se oplysningerne.
At skjule, hvad testen ikke dækkede · Et ærligt hul er bedre end en bred læsning.

Hvad kan og ikke kan konkluderes

En test, der dækker adgang, roller, adskillelse og administrative funktioner, kan give en sundhedskunde et dokumenteret grundlag for at vurdere produktet. Den kan indgå i kundens egen afprøvning af sikkerheden.

Den kan ikke afgøre, om kunden overholder databeskyttelsesreglerne, og den siger ikke noget om dele af produktet eller organisationen uden for omfanget.

Tjekliste før dokumentationen sendes

☐ Dækker testen adgang, roller, adskillelse og eksport?
☐ Er jeres egen supportadgang med i omfanget?
☐ Blev testen udført uden rigtige patientdata?
☐ Er rapporten gennemgået for personoplysninger?
☐ Er det aftalt, hvordan kunden modtager rapporten?
☐ Siger svaret tydeligt, hvad testen ikke dækkede?
☐ Undgår svaret løfter om kundens compliance?

Kilder

Databeskyttelsesforordningen (EU) 2016/679, artikel 9 og 32: særlige kategorier af personoplysninger og behandlingssikkerhed, herunder regelmæssig afprøvning, vurdering og evaluering af foranstaltningernes effektivitet.
Datatilsynet: Behandlingssikkerhed: vejledning om, hvordan behandling af personoplysninger sikres på et tilstrækkeligt niveau.

Senest gennemgået: oktober 2026.