Spørgsmål om hosting og underleverandører i skemaet

Felterne om hosting og underleverandører ser enkle ud, men de er dem, hvor softwarehuse lettest kommer til at svare for bredt eller på andres vegne. Et holdbart svar bygger på en skarp opdeling: hvad jeres egen test og jeres egne kontroller dækker, og hvad I alene kan henvise til i leverandørernes dokumentation.

I praksis betyder det, at hvert felt får et svar, der siger, hvem der står bag, hvilken dokumentation der findes, og hvem der ejer den. Skemaet er ikke stedet at forklare hele leverandørkæden. Den samtale hører til, når kunden stiller opfølgende spørgsmål, og den er beskrevet i → Kunden spørger til hosting og underleverandører i jeres kæde

De spørgsmål, der kan stå i skemaet

Formuleringerne varierer, men de samme få spørgsmål går igen i skemaerne:

Hvor hostes produktet · hos hvilken udbyder, i hvilke lande eller regioner og med hvilken type tjeneste.
Hvilke underleverandører har adgang til kundedata · navn, rolle og placering.
Hvordan vurderer I leverandørerne · ved valget og løbende.
Er leverandørerne certificeret eller revideret · og kan dokumentationen fremvises.
Indgår hosting og leverandører i jeres sikkerhedstest · og i givet fald hvilken del.
Får kunden besked ved skift · og med hvilket varsel.

Det sidste spørgsmål handler om kontrakten og ikke om test. Svar kun med det, I faktisk har aftalt, og henvis til aftalen. → Sikkerhedsbilaget til kundekontrakten

Hold jeres egen test adskilt fra leverandørens papirer

Det farligste felt er det, der spørger, om hosting og underleverandører er penetrationstestet. Et ja er sjældent dækkende. Jeres test kan have afprøvet produktet, jeres egen opsætning af cloudmiljøet og den måde, produktet kalder en mailtjeneste eller en betalingstjeneste på. Den har ikke afprøvet udbyderens datacenter eller betalingstjenestens egen platform.

Skriv derfor svaret i to sætninger. Den første beskriver, hvad jeres test omfattede af hosting og integrationer, med datoen for testen. Den anden beskriver, hvilken dokumentation leverandørerne selv stiller til rådighed, fx certifikater eller revisorerklæringer, og hvor kunden kan finde den. Hvis cloudopsætningen ikke var med i omfanget, så sig det, og skriv, om den kommer med næste gang. → Infrastrukturen bag produktet

Vær også præcis om placeringen. Hvis produktet kører i én region, men backup eller logning ligger et andet sted, hører begge steder med i svaret. Kunden kan spørge om placering af hensyn til egne regler, og et svar, der kun nævner den primære region, kan senere vise sig at være ufuldstændigt. Har I ikke overblik over, hvor hver tjeneste behandler data, er det det første, der skal på plads, før skemaet sendes.

Gør aldrig en leverandørs certifikat til jeres eget. At udbyderen har en ISO 27001-certificering, siger noget om udbyderens styring, ikke om jeres konfiguration af de tjenester, I har købt.

Listen over underleverandører som bilag

Mange skemaer har et fritekstfelt, hvor kunden forventer en liste. Et fritekstfelt er et dårligt sted til en liste, der ændrer sig. Hav i stedet en dateret oversigt, I kan vedlægge eller henvise til, med disse oplysninger pr. leverandør:

Navn og rolle · hvad leverandøren gør for produktet.
Datatyper · om leverandøren behandler kundedata, og hvilke.
Placering · land eller region for behandlingen.
Dokumentation · certifikat, erklæring eller egen vurdering, med dato.
Ejer hos jer · den person, der holder øje med leverandøren.

Oversigten skal svare til det, kunden spørger om. Hvis skemaet kun spørger til leverandører med adgang til kundedata, så send ikke hele listen over regnskabsprogram og mødebooking med. Lægger I oversigten i jeres svarbibliotek, får den samme ejer og dato som de øvrige svar. → Et svarbibliotek

Hvordan I beskriver vurderingen af leverandørerne

Spørgsmålet om, hvordan I vælger og følger op på leverandører, er et spørgsmål om proces. Kunden vil se, at der findes en fast fremgangsmåde: hvad I kigger efter, før en ny tjeneste tages i brug, hvem der godkender den, og hvor ofte I ser dokumentationen igen.

Det britiske NCSC har udgivet en vejledning om sikkerhed i leverandørkæden med tolv principper for, hvordan en organisation får og bevarer kontrol over sine leverandører. Vejledningen er skrevet til større organisationer og offentlige myndigheder i Storbritannien, så den er ikke et krav til jer. Den kan alligevel være nyttig at kende, fordi kundens egne spørgsmål kan bygge på samme tankegang: kend leverandørerne, stil krav, og følg op.

Beskriv jeres proces, som den er, også hvis den er enkel. Et lille softwarehus, der gennemgår to eller tre centrale leverandører én gang om året og notatet ligger i en mappe, har et svar, der kan dokumenteres. Et svar om en omfattende leverandørstyring, der ikke findes, har I ikke. → Svar, I ikke kan dokumentere

Et tænkt eksempel

Et softwarehus med en platform til vagtplanlægning i plejecentre får et skema fra en privat kæde af plejecentre. Feltet lyder: “Er jeres hostingmiljø og underleverandører omfattet af regelmæssig penetrationstest?”

Svaret: “Vores årlige penetrationstest omfatter platformen, dens API og vores egen opsætning af cloudmiljøet, herunder adgangsstyring og netværksregler. Seneste test blev afsluttet i marts. Den underliggende platform drives af cloududbyderen, som selv udgiver certificeringer og revisorerklæringer; vi henviser til udbyderens egen dokumentation og har ikke adgang til udbyderens test. Underleverandører med adgang til kundedata fremgår af vedlagte oversigt, dateret og med angivelse af dokumentation for hver leverandør.”

Svaret skelner mellem det, softwarehuset har afprøvet, og det, andre står inde for, og det lover ikke noget, softwarehuset ikke kan vise.

Det skal I lade være med

Svare ja til test af hele kæden · Jeres test dækker jeres del, ikke leverandørens platform.
Låne leverandørens certifikat · Skriv, at det er leverandørens, og hvad det dækker.
Skrive listen direkte i fritekstfeltet · En dateret oversigt er lettere at holde ajour.
Sende flere leverandører, end der spørges om · Det væsentlige drukner.
Love underretning, der ikke står i kontrakten · Henvis til det aftalte.
Glemme leverandører, der kun har supportadgang · De kan også se kundedata.

Hvad kan og ikke kan konkluderes

Et præcist svar viser kunden, hvem der står for hvad, og hvilken dokumentation der findes for hver del. Det gør det muligt for kunden at vurdere kæden uden at gætte. Svaret kan ikke dokumentere leverandørernes sikkerhed ud over det, deres egen dokumentation siger, og jeres test viser kun, hvordan jeres del så ud på testtidspunktet. → Produktet hostes hos en cloududbyder

Tjekliste til felterne om leverandører

☐ Er det klart, hvad jeres egen test omfattede af hosting og integrationer?
☐ Er leverandørernes dokumentation omtalt som deres og ikke jeres?
☐ Findes der en dateret oversigt over underleverandører med adgang til kundedata?
☐ Har hver leverandør en ejer hos jer?
☐ Kan jeres proces for vurdering af leverandører beskrives, som den faktisk er?
☐ Svarer oplysninger om underretning til det, kontrakten siger?

Kilder

NCSC (UK): Supply chain security guidance: tolv principper for at få og bevare kontrol over leverandørkæden, skrevet til større organisationer og offentlige myndigheder.

Senest gennemgået: oktober 2026.