Forhandling af sikkerhedskrav: hvad kan I sige nej til?

Kundens kontraktudkast kommer med et sikkerhedsbilag, og sælgeren vil gerne svare ja til det hele, så aftalen kan blive underskrevet. Svaret på titlens spørgsmål hviler på én skelnen: I kan sige nej til krav, I ikke kan opfylde, dokumentere eller holde ved lige for alle kunder, og I bør sige ja til det, der allerede passer til jeres måde at arbejde på. Et nej med en begrundelse og et alternativ kan være lettere for kunden at acceptere end et ja, der senere viser sig ikke at holde.

Teksten er ikke juridisk rådgivning. Den handler om, hvordan softwarehuset forbereder sig på forhandlingen, ikke om, hvordan bestemte kontraktvilkår skal formuleres.

Hvorfor et ja til alt er dyrt

Et sikkerhedskrav i en kontrakt er et løfte, der gælder hele aftalens løbetid. Hvis I accepterer en frist, en testhyppighed eller en rapportform, som I ikke har i forvejen, skal den opfyldes for netop den kunde, også når udviklingsteamet har travlt med noget andet.

Problemet vokser med antallet af kunder. Ti kunder med hver deres frister og testkrav giver ti forskellige forpligtelser i det samme produkt. Det er det, der gør et ukritisk ja dyrt, og det er samme mekanisme som ved for store svar i et spørgeskema. → Svar, I ikke kan dokumentere

Krav, I bør kunne sige ja til

Nogle krav er nemme at acceptere, fordi de beskriver noget, I allerede gør. Gennemgå udkastet med jeres egen praksis ved siden af.

Test med jævne mellemrum · hvis I allerede tester produktet efter en fast plan, er kravet en bekræftelse af den.
Dokumentation af testen · hvis I har en kundeversion eller et resumé klar, kan I udlevere den form.
Besked om alvorlige sårbarheder · hvis I har en proces for meddelelser til kunderne, kan kravet henvise til den.
En navngiven kontakt for sikkerhed · hvis rollen findes, koster kravet ikke noget nyt.

Ja til den slags krav gør forhandlingen kortere og viser kunden, at I har styr på grundlaget.

Krav, der kræver forhandling

Andre krav kan ikke accepteres uden ændringer. Det gælder især krav, der binder jer til noget, som afhænger af andre end jer selv, eller som skal opfyldes særskilt for én kunde.

Faste rettefrister for alle fund · en frist kan være realistisk for nogle fund og umulig for andre, fx hvis rettelsen afhænger af en underleverandør. → Rettefrister i kontrakten
Kundens egen tester i produktionen · test fra én kunde kan berøre de andre kunder i samme løsning. → Testklausulen i jeres kundekontrakt
Den fulde rapport til alle · den fulde rapport kan rumme detaljer om svagheder, der ikke bør spredes.
Test af kundens særlige opsætning hvert år · det er en ekstra opgave, der skal planlægges og prissættes.
Garanti for, at produktet er uden sårbarheder · ingen test kan dokumentere det.

Det sidste krav fortjener et klart nej. En test viser, hvad testeren fandt i et bestemt omfang på et bestemt tidspunkt, og intet softwarehus kan love mere end det.

Sådan siger I nej uden at miste aftalen

Et nej virker bedst, når det er kort, begrundet og følges af et forslag. Kunden har en grund til kravet, og forhandlingen handler om at finde en anden måde at opfylde den grund på.

Spørg til formålet · hvad skal kravet beskytte, og hvem i kundens organisation har stillet det?
Forklar begrænsningen · hvorfor kravet ikke kan opfyldes som skrevet, uden at gå i detaljer om svagheder.
Foreslå et alternativ · fx en kundeversion i stedet for den fulde rapport eller en frist, der afhænger af alvorligheden.
Henvis til jeres faste vilkår · hvis I har fælles sikkerhedsvilkår, er de et naturligt udgangspunkt. → Jeres egne sikkerhedsvilkår

Når kunden ikke kan få præcis det, kravet beskriver, kan andre tiltag være med til at dække risikoen. Det kræver, at I kan beskrive dem præcist. → Kompenserende foranstaltninger

Fælles sprog gør forhandlingen lettere

Uenighed om sikkerhedskrav kan handle om ord. Kunden skriver “fuld sikkerhedstest”, og I forstår en test af applikationen, mens kunden mener alt fra kontornettet til hostingmiljøet. Jo mere præcist kravet er formuleret, jo lettere er det at se, om I kan opfylde det.

En henvisning til et kendt kravsæt kan hjælpe. OWASP beskriver sit ASVS-projekt som et grundlag for at specificere krav til verifikation af applikationssikkerhed i kontrakter. Et krav, der peger på en sådan ramme og et aftalt omfang, er lettere at forhandle end en løs formulering. → OWASP ASVS

Et tænkt eksempel

Et softwarehus med en løsning til vagtplanlægning får et kontraktudkast fra en større kunde. Bilaget kræver test hver tredje måned, rettelse af alle fund inden for få dage, at kundens egen tester må teste i produktionen, og at den fulde rapport udleveres.

Den sikkerhedsansvarlige gennemgår kravene med sælgeren. Softwarehuset tester én gang om året og efter større ændringer, og det tilbydes i stedet for de faste kvartaler. Frister foreslås efter alvorlighed, med en pligt til at give besked, hvis en frist ikke kan holdes. Kundens egen test henvises til et særskilt miljø efter softwarehusets testpolitik. Rapporten tilbydes som kundeversion med mulighed for at gennemgå de tekniske detaljer på et møde.

Kunden accepterer det meste og beder om en kortere frist for de alvorligste fund. Den kan softwarehuset holde, og den bliver skrevet ind.

Det skal I lade være med

Sige ja i salget og forhandle bagefter · når kontrakten er underskrevet, er kravet jeres.
Love et produkt uden sårbarheder · det kan ingen test bekræfte.
Acceptere særkrav, som ikke kan holdes for alle kunder · så får I en forpligtelse, der kun gælder én.
Sige nej uden at forklare · så mister kunden grunden til at finde en anden løsning.
Lade sælgeren forhandle alene · den, der skal opfylde kravet, bør være med til at vurdere det.
Glemme at registrere, hvad I har lovet · aftalte afvigelser skal kunne findes igen ved næste test.

Hvad kan og ikke kan konkluderes

En gennemgang af kundens krav før forhandlingen kan vise, hvad I kan holde, hvad der kræver ændringer, og hvad I bør afvise. Den kan ikke afgøre, om et bestemt vilkår er rimeligt i juridisk forstand, og den kan ikke sikre, at kunden accepterer jeres alternativ. Teksten er ikke juridisk rådgivning.