Hvem i softwarehuset skal svare på sikkerhedsspørgsmål?

Kundens sikkerhedsspørgeskema kan komme ind gennem salget, men næsten intet i det kan sælgeren svare på alene. Svarene skal komme fra dem, der kender hvert område, samles af én person og godkendes af nogen, der kan stå inde for helheden. Det er den fordeling, der afgør, om svarene bliver rigtige, ensartede og leveret til tiden.

I et lille softwarehus kan de samme to eller tre personer have alle rollerne. Det ændrer ikke på, at rollerne findes. Det betyder bare, at det er ekstra vigtigt at skelne mellem den, der skriver et svar, og den, der godkender det.

Fire roller i hvert skema

Tovholderen · modtager skemaet, afklarer frist og afgrænsning med kunden, fordeler spørgsmålene, samler svarene og holder kontakten.
Fagejerne · skriver udkast til de afsnit, de kender: udvikling, drift, support, personale og leverandører.
Godkenderen · læser helheden og står inde for, at svarene er rigtige og ikke lover mere, end I kan holde.
Sælgeren · kender kunden, forklarer, hvorfor skemaet er vigtigt for aftalen, og formidler svaret, men ændrer ikke i indholdet.

Tovholderen behøver ikke være teknisk, men skal kunne læse et spørgsmål og vide, hvem der kender svaret. I mange softwarehuse er det den sikkerhedsansvarlige, en produktchef eller en person i kundeservice med erfaring fra tidligere skemaer. Det afgørende er, at tovholderen har mandat til at rykke fagejerne for svar og til at bede kunden om mere tid, når det er nødvendigt. Uden det mandat ender skemaet hos den, der har mest travlt med at lukke aftalen.

Hvem ejer hvilke spørgsmål

Fordelingen følger skemaets emner. Udviklingsteamet svarer om sikker udvikling, kodegennemgang, håndtering af afhængigheder og adskillelse mellem kunder. Drift eller den, der har ansvaret for hostingen, svarer om backup, logning, overvågning og cloudopsætning. Den sikkerhedsansvarlige svarer om penetrationstest, sårbarheder og hændelser. Ledelsen eller HR svarer om politikker, ansættelse, uddannelse og fortrolighed. Spørgsmål om kontrakter, ansvar og forsikring hører hos ledelsen, eventuelt med hjælp fra en jurist. Når et spørgsmål falder mellem to områder, så giv det til den ene og bed den anden læse med.

Spørgsmål om penetrationstest bør ligge hos den person, der bestilte testen og fulgte op på fundene. Det er den person, der ved præcis, hvad der var med i testen, hvilke fund der er rettet, og hvornår næste test er planlagt. Hvis den viden kun findes hos udviklerne, så sørg for at få den skrevet ned, så svaret ikke afhænger af én persons hukommelse. → Spørgsmålet om penetrationstest i skemaet

Godkendelsen er ikke en formalitet

Hvert svar kan være korrekt for sig, men tilsammen tegne et billede, der ikke holder. Måske skriver udviklingen, at alle ændringer gennemgås, mens driften skriver, at der laves hurtige rettelser direkte i produktionen ved nedbrud. Godkenderen skal fange den slags uoverensstemmelser.

Godkenderen skal også vurdere, om svarene binder virksomheden. Når skemaet bliver en del af aftalegrundlaget, er et svar om rettefrister eller underretning et løfte, som ledelsen skal kunne stå inde for. I mindre softwarehuse kan godkenderen være direktøren eller den tekniske direktør. Hvis godkenderen selv har skrevet store dele af svarene, så lad en anden læse med. Det er svært at finde fejl i sin egen tekst, især når fristen nærmer sig, og man kender produktet så godt, at uklare formuleringer virker indlysende. → Svar, I ikke kan dokumentere

Sælgerens rolle

Sælgeren har den bedste forståelse af, hvad aftalen betyder for kunden, og hvor travlt kunden har. Det gør sælgeren vigtig som bindeled, men ikke som forfatter af tekniske svar. Den største risiko i fordelingen er, at sælgeren under tidspres udfylder felter selv for at holde salget i gang. Det sker ikke nødvendigvis af ond vilje, men fordi sælgeren ikke ved, at et lille ord som altid eller alle kan gøre et svar umuligt at dokumentere.

Giv sælgerne adgang til jeres godkendte svar, så de kan svare på de enkle spørgsmål selv og vide, hvornår de skal sende et spørgsmål videre. Klæd dem på til at sige “det vender vi tilbage med” i stedet for at gætte. → Salgsteamet og sikkerhedsspørgsmål · → Et svarbibliotek

Når skemaet kommer uventet

Et skema dukker ikke altid op på et belejligt tidspunkt. Det kan lande midt i en release eller i en ferieperiode, hvor fagejerne ikke er til stede. Aftal på forhånd, hvem der træder til, hvis en fagejer er væk, og hvor lang tid fagejerne skal have til at svare. Giv kunden besked tidligt, hvis fristen ikke kan holdes, frem for at sende et halvfærdigt skema.

En fast rutine gør det lettere. Brug den samme fordeling og de samme frister internt hver gang, og registrér hvert skema med dato, kunde og ansvarlige. Så kan I se, hvor meget tid skemaerne tager, og hvem der bærer mest af byrden. Den viden er nyttig, når ledelsen skal beslutte, om opgaven kræver flere ressourcer, eller om en fælles sikkerhedspakke til kunderne kan spare tid. → Sikkerhedsspørgeskema fra kunden

Et tænkt eksempel

Et softwarehus med en platform til ejendomsadministration modtager et skema fra en stor boligorganisation. Sælgeren videresender det til produktchefen, som er tovholder. Produktchefen deler skemaet i fire dele og sender dem til udviklingschefen, driftsansvarlig, den sikkerhedsansvarlige og direktøren. Svarene samles i et dokument, som direktøren læser igennem. Direktøren opdager, at et svar om rettefrister lover mere, end aftalen med driftsleverandøren tillader, og svaret justeres, før skemaet sendes. Sælgeren sender det til kunden med en kort følgemail.

Det skal I lade være med

Lade sælgeren udfylde tekniske svar · selv under tidspres.
Springe godkendelsen over, når skemaet haster · det er netop da, fejlene sniger sig ind.
Lade viden om testen ligge hos én person · skriv den ned.
Sende et halvfærdigt skema for at nå fristen · bed hellere kunden om mere tid.
Glemme at registrere, hvem der svarede · I skal kunne finde svaret og personen igen.

Hvad kan og ikke kan konkluderes

En klar fordeling af roller gør svarene mere præcise og ensartede, og den gør det tydeligt, hvem der har ansvaret for hvad. Den garanterer ikke, at svarene er rigtige, men den gør det sandsynligt, at fejl bliver opdaget, før kunden ser dem. Den erstatter heller ikke selve arbejdet med sikkerheden, som svarene beskriver.