Kontrakten skal fornyes, og kunden vil se den nyeste rapport

En fornyelse, der burde være ren formalitet, kan gå i stå, fordi kunden beder om den nyeste pentestrapport, og den seneste er fra før en stor release. Løsningen hviler på planlægning: når I kender fornyelsesdatoerne for de største kunder, kan testen ligge, så rapporten er klar, før indkøberen spørger.

Kort sagt skal I vide tre ting i god tid: hvornår de vigtigste kontrakter fornyes, hvad hver kunde forventer at få at se, og hvornår jeres næste test realistisk kan være afsluttet og rettet. Hænger de tre datoer ikke sammen, er det bedre at sige det til kunden måneder før fornyelsen end ugen før.

Hvorfor fornyelsen skærper spørgsmålet

Ved første salg accepterede kunden måske en rapport, der var et par måneder gammel, eller en plan for en kommende test. Ved fornyelsen har kunden et andet udgangspunkt. Kunden har brugt produktet i en periode, har set releases komme, og har måske selv fået nye krav fra egne revisorer eller myndigheder. Spørgsmålet er nu, om sikkerheden er fulgt med.

Nogle kunder genbruger desuden deres leverandørvurdering ved fornyelsen. Det betyder, at jeres svar fra sidste år bliver læst igen og sammenlignet med det, I svarer nu. Står der i det gamle svar, at I tester hvert år, forventer kunden at se en ny rapport. → Samme skema hvert år: hvad ændrer I i svarene?

Saml fornyelsesdatoerne ét sted

Lav en liste over de kunder, hvis fornyelse afhænger af sikkerhedsdokumentation. For hver kunde noteres fornyelsesdatoen, kontaktpersonen hos kunden, de krav, der står i kontrakten eller kundens leverandørpolitik, og hvilken dokumentation kunden fik sidst. Listen ejes af en bestemt person, typisk den, der også ejer kundekravene om test i øvrigt. → Hvem i softwarehuset ejer kundekravet om test?

Når listen findes, bliver det tydeligt, om fornyelserne klumper sig sammen. Et tænkt eksempel: Et softwarehus med et lønsystem ser, at de fire største kunder alle fornyer i første kvartal. En test i efteråret, med tid til rettelser og retest inden jul, dækker dem alle. En test i februar ville komme for sent til to af dem.

Læg testen bagud fra datoen

Regn baglæns fra den tidligste vigtige fornyelse. Kunden skal have dokumentationen nogle uger før forhandlingen, så deres sikkerhedsfolk kan nå at læse den. Før det skal rapporten være færdig, de vigtigste fund rettet og helst efterprøvet. Før det igen skal testen gennemføres, og før det skal den være bestilt og afgrænset. Hvor lang tid hvert trin tager, afhænger af produktet, testerens kalender og jeres egen kapacitet til rettelser, så spørg både testeren og udviklingsteamet.

Indregn jeres egen udgivelsesplan. Ligger der en større release kort før fornyelserne, bør testen så vidt muligt dække den, ellers vil kunden spørge, om rapporten stadig er dækkende. → Et årshjul for sikkerhedstest i et softwarehus · → Lanceringsdato og testvindue

Når rapporten ikke er klar til tiden

Sker det alligevel, at den nye rapport ikke er klar, så skriv til kunden i god tid. Forklar, hvad I har (den forrige rapport og status på dens fund), hvad der er bestilt, og hvornår kunden kan forvente den nye dokumentation. Spørg, om fornyelsen kan gennemføres med en aftale om at eftersende rapporten, eller om kunden har brug for noget andet i mellemtiden.

Nogle kunder kan leve med en kort forsinkelse, hvis de ved det i forvejen og har en dato at skrive i deres egen sag. Det, de har svært ved, er at opdage forsinkelsen selv. Overhold den dato, I giver, og send dokumentationen uopfordret, når den er klar.

Hvad fornyelsen er en anledning til

Fornyelsen er også et naturligt tidspunkt at se på, hvad kunden faktisk bruger. Har kunden taget nye moduler i brug, er det rimeligt at spørge sig selv, om de var med i seneste test. Hvis ikke, skal enten testen udvides, eller kunden skal have en klar besked om, hvad rapporten dækker. → Rapporten dækker ikke det modul, kunden køber

Se også på kontraktens tekst om test, før den fornyes. Står der et krav om årlig test, som er svært at holde, eller en formulering, der kan læses på flere måder, kan fornyelsen være stedet at få den præciseret. → Kontrakten kræver årlig test

Endelig kan fornyelsen bruges til at aftale, hvordan kunden fremover får dokumentationen. Hvis kunden hvert år skal have den nyeste rapport eller et resumé, kan det skrives ind som en fast leverance med en omtrentlig måned. Så skal ingen af parterne huske at spørge, og I kan lægge testen efter en dato, I selv har været med til at sætte.

Hvem hos kunden læser rapporten denne gang

Ved første salg var det måske kundens IT-chef, der godkendte jer. Ved fornyelsen kan sagen ligge hos en indkøbsafdeling, en ny sikkerhedsansvarlig eller en leverandørstyringsfunktion, der ikke kender historikken. De læser rapporten uden at vide, hvad der blev aftalt for et år siden.

Spørg derfor jeres kontaktperson, hvem der skal godkende dokumentationen, og om kravene er ændret siden sidst. Send en kort følgeskrivelse med rapporten, der forklarer, hvilken version og hvilke moduler testen dækker, hvad der er sket med fundene fra forrige test, og hvem hos jer der kan svare på spørgsmål. Det sparer en runde opfølgende mails og gør det lettere for en ny læser at sammenligne med sidste års dokumentation. → Opfølgende spørgsmål fra kundens sikkerhedsteam

Det skal I lade være med

Vente på, at kunden spørger · Fornyelsesdatoerne er kendt, og spørgsmålet kommer.
Sende den gamle rapport uden kommentar · Kunden ser datoen og spørger alligevel.
Teste lige før fornyelsen · Så er der ikke tid til rettelser, før kunden læser rapporten.
Love en dato, I ikke kontrollerer · Testerens kalender og jeres rettelser skal begge kunne holde.
Lade hver sælger håndtere egen kunde · Uden fælles liste opdager ingen, at fornyelserne klumper sig.

Hvad kan og ikke kan konkluderes

En ny rapport til fornyelsen viser, at produktet er afprøvet i en bestemt version på et bestemt tidspunkt. Den viser ikke, at alle kundens krav er opfyldt, og den sikrer ikke fornyelsen. Om dokumentationen er tilstrækkelig, afgør kunden ud fra sine egne krav, og dem skal I kende, før testen bestilles.