Salget er godt i gang, og så sender kunden et regneark med en lang række spørgsmål om sikkerhed. Sælgeren videresender det til den udvikler, der virker mest teknisk, og udvikleren svarer efter bedste evne mellem to opgaver. Det giver to problemer. Svarene bliver en del af det, kunden lægger til grund, og næste kunde får formentlig andre svar. Løsningen er en fast arbejdsdeling mellem den, der kender produktet, og den, der ejer sikkerhedsledelsen, samt et fast sæt svar, der holdes ajour.
To slags spørgsmål i samme skema
Skemaet blander to ting. Den ene slags handler om produktet: hvor kører det, hvordan er data adskilt mellem kunder, hvem kan komme ind i produktionen, og hvordan bliver data taget i sikkerhed. Den anden slags handler om virksomheden: har I en sikkerhedspolitik, hvem er ansvarlig, hvordan uddannes medarbejderne, og hvad gør I ved en hændelse.
Før nogen begynder at svare, er det derfor nyttigt at markere hvert spørgsmål med, hvem der ejer det. Spørgsmålene om produktet hører til den tekniske leder eller CTO’en. Spørgsmålene om ledelse hører til den, der har ansvaret for sikkerheden, og i mindre virksomheder er det ofte en person i direktionen. Hvordan et skema håndteres som ledelsesopgave, er beskrevet under sikkerhedsspørgeskemaet fra kunden. Her handler det om de tekniske svar.
De tekniske svar, kunden leder efter
Fire områder går igen, og de kan forberedes én gang:
- Arkitektur. Hvilke dele består produktet af, og hvilke eksterne tjenester er det afhængigt af? Er kunderne på samme installation med adskilte data, eller har hver kunde sin egen? Svaret står bedst i en kort arkitekturbeskrivelse, som I kan vedlægge.
- Hosting og data. Hvilken cloududbyder bruger I, i hvilke lande ligger data, og hvor ligger sikkerhedskopierne? Her er det vigtigt, at svaret passer på hele kæden og også dækker logning og supportværktøjer, se hvor ligger data?.
- Adgang. Hvem hos jer kan se kundedata, hvordan får de adgang, og hvordan bliver den fjernet, når en medarbejder stopper? Kunden spørger ofte til totrinslogin og til, om adgangen bliver logget.
- Backup og gendannelse. Hvor ofte tages sikkerhedskopier, og er en gendannelse fra dem blevet afprøvet? Det sidste spørgsmål afslører, om jeres svar bygger på en prøve eller på en antagelse. Se kan I genskabe produktet?.
Hertil kommer driften, hvor kunden ofte beder om tal for oppetid. De tal hører sammen med det, I har lovet i aftalen, se SLA og oppetid.
Svar præcist, også når svaret er nej
Et ærligt nej med en plan er bedre end et ja, der ikke holder. Når udvikleren skriver “ja” til kryptering af alle data, fordi databasen er krypteret, mens logfilerne ligger åbent, står virksomheden med et svar, der kan vise sig forkert ved en revision eller efter en hændelse.
Der er reelt fire brugbare svar:
- Ja, med en kort beskrivelse af hvordan.
- Delvist, med præcis angivelse af hvad der er dækket.
- Nej, med en begrundelse eller en anden foranstaltning, der dækker samme risiko.
- Planlagt, med en periode, I kan holde.
Svar på det, der er sandt i dag. Svarene skal læses igennem af én person, der har overblikket, før de sendes, for de kan ende som bilag til kontrakten. Hvad I må forpligte jer til i en aftale, er et spørgsmål til advokat.
Byg et svarsæt, I kan genbruge
Første skema tager lang tid. Tredje skema bør gå hurtigt. Saml alle svar i ét dokument med spørgsmål, godkendt svar, hvem der ejer svaret, og hvornår det sidst blev kontrolleret. Når næste skema kommer, kopierer sælgeren eller projektlederen de kendte svar, og den tekniske leder bruger tiden på de nye spørgsmål.
Svarsættet skal have en ejer og en fast gennemgang, fx hvert kvartal og efter større ændringer i arkitekturen eller ved skift af leverandør. Et gammelt svarsæt er værre end intet, fordi det ser godkendt ud. Mange af punkterne kan også stå som fast dokumentation, I sender på forhånd, og det kan spare kunden for en del af skemaet.
Tænkt eksempel
Et lille SaaS-firma får samme uge skemaer fra to kunder. Direktøren tager spørgsmålene om politik og ansvar, lead developeren tager de tekniske, og begge bruger den samme fil. Tre spørgsmål kan ingen svare på med sikkerhed, fordi ingen har prøvet at genskabe produktet. Virksomheden svarer “planlagt” og sætter en prøve på den tekniske køreplan. Det svar er værdifuldt, for det har fundet et hul, inden en kunde gjorde det.
Hvis skemaerne vender tilbage med de samme huller, er det et produktspørgsmål, og det hører hjemme på den tekniske køreplan.
Det skal I lade være med
- At lade sælgeren svare ud fra hukommelsen · svaret bliver en forpligtelse, som andre skal holde.
- At skrive ja til noget, der kun er delvist sandt · det er det svar, der koster mest senere.
- At starte forfra ved hvert skema · det binder den tekniske leder uden at gøre svarene bedre.
- At kopiere svar fra en anden virksomheds skabelon · de beskriver ikke jeres produkt.
Det skal I kræve af den eksterne
- ☐ En klar deling af, hvem der ejer hvilke spørgsmål.
- ☐ Et svarsæt med ejer og dato for hvert svar.
- ☐ Ærlige svar, også hvor svaret er nej eller planlagt.
- ☐ Huller fra skemaerne omsat til punkter på køreplanen.
- ☐ En fast gennemgang af svarene efter større ændringer.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Kundens IT-arkitekt vil have et møde · Før kunden kræver en pentest af produktet
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
