Kunder, der vurderer et SaaS-produkt, leder efter de samme oplysninger igen og igen: testes produktet, hvornår skete det sidst, og hvem kan man kontakte om sikkerhed? En tillidsside samler svarene ét sted, så de kan findes før det første møde. Svaret på, hvad der må stå der, hviler på en tredeling: noget kan vises frit, noget kræver en anmodning og en aftale om fortrolighed, og noget hører slet ikke hjemme uden for huset. Siden skal være præcis, aktuel og aldrig sige mere, end dokumenterne bag den kan bære.
Hvad en tillidsside er
En tillidsside, på engelsk et trust center, er en offentlig side på jeres websted om produktets sikkerhed. Den kan være en enkel tekstside eller en portal, hvor kunder kan anmode om dokumenter. Formålet er det samme: at give kunder og kommende kunder et fælles udgangspunkt, så spørgeskemaet ikke skal besvare de grundlæggende ting hver gang.
Siden er ikke en salgsside. Den er en reference, som sælgere, kundeansvarlige og sikkerhedsansvarlige kan henvise til, og som en kundes sikkerhedsfolk kan læse kritisk. Derfor skal formuleringerne være lige så omhyggelige som i et svar til et skema. → Et svarbibliotek
Det, der kan stå offentligt
Det meste af det, der står på en god tillidsside, er beskrivelser af praksis, ikke resultater.
- At produktet testes · af en uafhængig tester, og efter hvilken plan, fx årligt og efter større ændringer.
- Datoen for den seneste test · måned og år, og hvilke dele af produktet testen dækkede.
- Hvad kunder kan få · fx et resumé eller en kundeversion af rapporten efter aftale.
- Kontaktvejen for sårbarheder · en adresse eller formular og en politik for, hvordan rapporter modtages.
- Certificeringer og erklæringer · med henvisning til, hvor kunden selv kan kontrollere dem.
- Sikkerhedsmeddelelser · en oversigt over meddelelser til kunderne, hvis I udsender dem.
Undgå at skrive resultater som “ingen kritiske fund” på siden. Et resultat hører sammen med sine forudsætninger, og de kan ikke gengives kort nok til en offentlig side. → Formidl et godt resultat ærligt
Det, der kræver en anmodning
Dokumenter med detaljer om produktet bør kun udleveres til navngivne modtagere, og gerne efter en aftale om fortrolighed. Det gælder resuméet af testen, en kundeversion af rapporten, et erklæringsbrev fra testeren og revisorerklæringer, som kun må gives videre efter deres egne vilkår.
Tillidssiden kan forklare, hvordan man anmoder om dem, og hvad der skal til. Det gør processen forudsigelig for kunden og giver jer et spor over, hvem der har fået hvad.
Beskriv også, hvem der kan anmode. En kunde med en underskrevet aftale har et andet behov end en kommende kunde, der er tidligt i en vurdering, og I kan med god grund give de to forskellige dokumenter. Skriv, hvor lang tid I forventer at bruge på at svare, hvis I kan holde det, og hvem anmodningen går til. En portal, hvor kunden selv kan downloade dokumenter efter en godkendelse, kan være praktisk, men den skal stadig registrere, hvem der har hentet hvad, og den skal kunne lukke adgangen igen, når en aftale ophører. → Kunden skal skrive under på fortrolighed
Det, der ikke hører hjemme på siden
Den fulde pentestrapport skal ikke ligge på en offentlig side, heller ikke bag et simpelt link, som kan sendes videre. Det samme gælder oplysninger om åbne fund, tekniske detaljer om opsætningen og navne på interne systemer. Den slags kan hjælpe en angriber mere, end det hjælper en kunde.
Vær også varsom med mærker og logoer. Et logo for en standard eller ordning hører kun på siden, hvis I har ret til at bruge det, og den organisation, der ejer ordningen, tillader det. Henvis i stedet til ejerens eget register, hvor det findes. Så kan kunden selv se, om oplysningen er gyldig, og I slipper for at holde en kopi ved lige. Cloud Security Alliance har for eksempel et offentligt STAR-register, hvor leverandører kan være opført med en status, som kunden selv kan se. → CSA STAR og cloudkunders krav
Kontaktvejen for sårbarheder
En tillidsside er et naturligt sted at vise, hvordan man rapporterer en sårbarhed. NCSC i Storbritannien anbefaler, at kontaktvejen er let at finde, fx på sider om sikkerhed og i filen security.txt. RFC 9116 beskriver den fil og kræver blandt andet, at den angiver en kontaktvej og en udløbsdato.
Siden kan linke til jeres politik for ansvarlig offentliggørelse, så forskere og kunder kan se, hvad de kan forvente. Hold denne vej adskilt fra den vej, kunderne bruger til andre sikkerhedsspørgsmål, men vis begge. → Ansvarlig offentliggørelse
Hold siden aktuel
En tillidsside med en testdato fra for to år siden skader mere, end den gavner. Kunden ser, at oplysningerne ikke vedligeholdes, og begynder at tvivle på resten. Gør det til en fast opgave at opdatere siden efter hver test, efter hver ændring i certificeringer og mindst ved hver planlagt gennemgang af jeres sikkerhedsdokumentation.
Skriv en dato for seneste opdatering på siden. Det er en lille ting, men den viser kunden, hvor gamle oplysningerne er, og minder jer om at holde dem ved lige. Giv én person ansvaret, så opdateringen ikke afhænger af, hvem der husker den. → Et årshjul for sikkerhedstest
Et tænkt eksempel
Et softwarehus med et system til booking af lokaler får de samme fem spørgsmål fra næsten hver ny kunde. De beslutter at lave en tillidsside med en kort beskrivelse af testplanen, datoen for den seneste test og de dele af produktet, den dækkede, en kontaktadresse for sikkerhed og en henvisning til politikken for sårbarheder. Siden forklarer også, at et resumé af testen kan udleveres efter aftale om fortrolighed.
Næste spørgeskema henviser sælgeren til siden for de grundlæggende svar og sender resuméet til kundens sikkerhedsansvarlige efter underskrift. Kunden har kun to opfølgende spørgsmål, begge om et modul, som testen ikke dækkede.
Det skal I lade være med
- Lægge rapporten frit tilgængeligt · den hører til en kontrolleret udlevering.
- Skrive resultater uden forudsætninger · et kort udsagn kan læses som en garanti.
- Bruge logoer, I ikke har ret til · henvis til ejerens register i stedet.
- Lade datoerne forælde · en gammel side svækker tilliden.
- Love mere end dokumenterne bærer · kunden kan bede om beviset.
Hvad kan og ikke kan konkluderes
En tillidsside kan gøre jeres sikkerhedsarbejde synligt og spare både jer og kunderne for gentagne spørgsmål. Den kan vise, at I tester, og hvordan kunder får adgang til dokumentationen. Den kan ikke i sig selv dokumentere, at produktet er sikkert, og den erstatter ikke de dokumenter, en kunde skal bruge i sin vurdering.
Kilder
- NCSC (UK): Vulnerability Disclosure Toolkit: kontaktvejen for sårbarheder skal være let at finde, fx på sider om sikkerhed og i security.txt.
- RFC 9116: A File Format to Aid in Security Vulnerability Disclosure: felterne Contact og Expires skal altid være til stede i security.txt.
- Cloud Security Alliance: STAR Registry: offentligt register over leverandører med status for deres opførelse.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om pentestrapporten
Læs også: Hel rapport, resumé eller erklæring · Et fast kontaktpunkt for sikkerhed
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest af SaaS hos Nielco IT
