Kravet står i kundens leverandørpolitik: sådan læser I det

En leverandørpolitik er skrevet til alle, kunden køber af: rengøringsfirmaet, revisoren, driftsleverandøren og jer. Derfor passer ordene ikke altid præcist på et SaaS-produkt. Jeres opgave er at finde de sætninger, der handler om sikkerhedstest, oversætte dem til produktet og få kunden til at bekræfte, at oversættelsen holder.

Læs politikken med fire spørgsmål for øje: hvad skal testes, hvor ofte, af hvem, og hvilken dokumentation skal kunden have. Hvor politikken er uklar eller ikke passer, er det kunden, der skal fortolke den, ikke jer alene.

En politik til alle leverandører, også jer

Større kunder har tit én samlet politik for leverandører med adgang til deres data eller systemer. Den kan være delt i niveauer efter, hvor kritisk leverandøren er, og kravene skærpes op gennem niveauerne. Find først ud af, hvilket niveau kunden har placeret jer i. Det afgør, hvilke afsnit der overhovedet gælder.

Spørg også, hvilken version af politikken der gælder for jeres aftale, og om den bliver en del af kontrakten. En politik, der henvises til i kontrakten, kan ændre sig undervejs, og så kan kravene til jer ændre sig med den. → Testklausulen i jeres kundekontrakt

Krav om test står ikke altid samlet. De kan gemme sig i afsnit om sårbarhedsstyring, om sikker udvikling, om leverandørens kontroller eller om kundens ret til at kontrollere leverandøren. Gennemgå hele politikken og saml hver sætning, der nævner test, scanning, vurdering, revision eller dokumentation.

Læg dem i en kort oversigt med politikkens egen nummerering og en kolonne med jeres forståelse af hver sætning. Så kan I senere henvise præcist, når I svarer kunden, og kunden kan se, at I har læst teksten og ikke bare et resumé.

Hvad skal testes?

Politikker kan tale om leverandørens systemer, leverandørens miljø eller de løsninger, der behandler kundens data. For et softwarehus kan det betyde produktet, den infrastruktur, produktet kører på, eller også kontornettet, hvor medarbejderne arbejder. Det er tre forskellige testopgaver.

Skriv jeres forståelse ned og send den til kunden: for eksempel at kravet gælder produktet og den platform, det driftes på, men ikke kontorets egne systemer. Får I et ja, har I et grundlag at teste efter. → Produktet eller hele virksomheden?

Læg også mærke til ordvalget. Penetrationstest, sårbarhedsscanning og sikkerhedsvurdering er ikke det samme, og nogle politikker skelner skarpt mellem dem. Hvis politikken kræver en penetrationstest, kan en automatisk scanning af produktet næppe stå alene som svar, selv om den er nyttig i det daglige arbejde. Hvis politikken kun kræver en vurdering, kan der være flere veje, men så er det endnu vigtigere at få kundens bekræftelse af, hvad der er godt nok.

Tænk også på de dele af produktet, kunden ikke bruger. Har kunden kun købt et enkelt modul, kan det være rimeligt at foreslå, at kravet gælder det modul og den fælles platform under det.

Hvor ofte og efter hvilke ændringer?

Krav om hyppighed er tit formuleret som et fast interval, som test efter væsentlige ændringer, eller som begge dele. Nogle politikker låner formuleringer fra kendte standarder. PCI DSS krav 11.4 nævner for eksempel både test mindst hver tolvte måned og test efter væsentlige ændringer i infrastruktur eller applikation, for de miljøer standarden gælder.

For et produkt med hyppige releases er ordet væsentlig det vanskelige. Spørg kunden, hvad der regnes for en væsentlig ændring, eller foreslå selv en beskrivelse, som passer til jeres udvikling. Så undgår I, at hver release kan blive læst som en anledning til en ny test. → Et årshjul for sikkerhedstest

Hvem må teste?

Politikken kan kræve en uafhængig tester, en ekstern part, bestemte certificeringer eller en tester, kunden har godkendt. Uafhængighed kan læses snævert, som en ekstern virksomhed, eller bredt, som en person uden ansvar for det, der testes. Spørg, hvilken læsning kunden bruger, før I vælger tester. Har I egne sikkerhedsfolk, som tester produktet løbende, er det især vigtigt at vide, om kunden regner deres arbejde med, eller om der skal en ekstern part til. → Sådan vælger I tester til kunderapporten

Hvis politikken giver kunden ret til selv at teste jeres produkt, er det et særskilt spørgsmål, der skal have sine egne regler. → Kunden vil selv teste jeres produkt

Hvilken dokumentation og hvornår?

Se efter, om politikken kræver hele rapporten, et resumé, en erklæring eller blot en bekræftelse. Se også efter frister: skal dokumentationen sendes ved kontraktens start, årligt, efter hver test eller på forespørgsel? Og står der noget om, hvor hurtigt alvorlige fund skal være håndteret?

Netop krav om rettefrister kan være svære at opfylde for et lille udviklingsteam. Læs dem særligt grundigt, og tag dem op med kunden, før kontrakten underskrives. → Rettefrister i kontrakten

Når politikken ikke passer til produktet

Nogle krav giver ingen mening for et SaaS-produkt, eller de forudsætter adgange, I ikke kan give, fordi produktet deles af mange kunder. Det er ikke et brud at sige det. Skriv, hvilket krav det drejer sig om, hvorfor det ikke passer, og hvad I gør i stedet. Kunden kan så tage stilling til, om jeres løsning er acceptabel.

Et begrundet forbehold giver som regel en bedre dialog end et stille ja, som ingen kan holde. Gem kundens svar sammen med kontrakten. Når politikken bliver opdateret, eller en ny person hos kunden overtager sagen, er det jeres dokumentation for, hvad der blev aftalt. → Kompenserende foranstaltninger

Det skal I lade være med

At læse kun det afsnit, der hedder test · Kravene kan stå spredt i hele politikken.
At fortolke uklare ord alene · Kundens læsning tæller, så få den på skrift.
At svare ja til alt for at komme videre · Et krav, I ikke kan opfylde, følger med ind i samarbejdet.
At overse rettefrister · De binder udviklingen i hele aftalens løbetid.
At glemme politikkens version · En opdateret politik kan ændre kravet uden varsel.

Hvad kan og ikke kan konkluderes

En grundig læsning af politikken kan give jer et præcist billede af, hvad kunden forventer, og et skriftligt grundlag for, hvordan kravene gælder produktet. Det gør det lettere at bestille en test, der passer.

Læsningen afgør ikke, om kunden accepterer jeres fortolkning. Det gør kunden. Teksten er ikke juridisk rådgivning, og kontraktens bindende betydning bør vurderes af den, der normalt varetager jeres aftaler.