Før eller siden møder et softwarehus et krav fra en kunde, som produktet ikke opfylder på den måde, kravet er skrevet. Begrebet kompenserende foranstaltning dækker over et andet tiltag, der giver en tilsvarende beskyttelse, og det hviler på, at I kan forklare, hvilken risiko kravet skulle dække, og hvordan jeres tiltag dækker den samme risiko.
Kort sagt: en kompenserende foranstaltning er ikke en undskyldning for et manglende krav. Den er en dokumenteret begrundelse for, at risikoen alligevel er håndteret, og kunden afgør selv, om begrundelsen er god nok.
Begrebet, kort og præcist
NIST bruger i sin ordliste betegnelsen compensating security control om et ledelsesmæssigt, driftsmæssigt eller teknisk tiltag, som en organisation bruger i stedet for et anbefalet tiltag, og som giver tilsvarende eller sammenlignelig beskyttelse. Definitionen er skrevet til offentlige informationssystemer i USA, men tanken er den samme, når en kunde stiller krav til jeres produkt.
Tre ting skal være til stede, før et tiltag kan kaldes kompenserende:
- Formålet er kendt · I ved, hvilken risiko det oprindelige krav skulle begrænse.
- Tiltaget er på plads · det findes og virker i dag, ikke kun på en plan.
- Beskyttelsen er sammenlignelig · tiltaget begrænser samme risiko i en grad, der kan forsvares.
Mangler et af de tre, er der tale om en mangel med en plan, ikke en kompenserende foranstaltning.
Hvorfor sælgeren skal kende begrebet
Ordet kan dukke op i to situationer. Den ene er i kundens spørgeskema, hvor der står “Hvis nej, beskriv kompenserende foranstaltninger”. Den anden er på et møde, hvor kundens sikkerhedsfolk spørger, hvad I gør i stedet. I begge tilfælde kan det være sælgeren eller den kundeansvarlige, der først skal svare.
Sælgeren behøver ikke kende de tekniske detaljer, men skal vide, at et svar på spørgsmålet kræver en begrundelse fra udviklingen eller driften. Et improviseret svar på et møde kan blive opfattet som et løfte. Det er bedre at sige, at I vender tilbage med en beskrivelse. → Salgsteamet og sikkerhedsspørgsmål · → Ja, nej eller delvist
Tænkte eksempler på begrebsniveau
Eksemplerne her viser tankegangen, ikke en løsning. Om et tiltag er tilstrækkeligt, afhænger af produktet og af kundens vurdering.
- Kravet er årlig ekstern test af hele virksomheden · produktet testes eksternt, mens kontornettet, som ikke har adgang til kundedata, er adskilt og overvåges. Risikoen for kundedata er dækket af testen af produktet og adskillelsen.
- Kravet er tofaktorlogin for alle brugere · produktet understøtter login via kundens egen identitetsløsning, hvor kunden selv styrer kravet om ekstra faktor.
- Kravet er, at et bestemt fund rettes inden en frist · rettelsen kræver en større ombygning, og indtil da er den berørte funktion begrænset til færre brugere og overvåget tættere.
I hvert eksempel er det oprindelige krav ikke opfyldt, men en del af risikoen er dækket på en anden måde. Kunden kan være enig eller uenig.
Sådan beskriver I foranstaltningen
En god beskrivelse er kort, ærlig og dokumenterbar. Den kan følge en fast form, så den er let at genbruge i flere skemaer:
- Kravet · hvad kunden spørger om, med kundens egne ord.
- Afvigelsen · hvad I ikke opfylder, og hvorfor.
- Risikoen · hvilken risiko kravet skulle begrænse.
- Tiltaget · hvad I gør i stedet, på begrebsniveau.
- Dokumentationen · hvad I kan vise, fx en rapport, en politik eller et skærmbillede af en indstilling.
- Udløb · om tiltaget er midlertidigt, og hvornår det tages op igen.
Hold de tekniske detaljer ude af selve skemaet. Hvis kunden vil se mere, kan det ske på et møde eller i en udlevering under fortrolighed. → Sikkerhedsmødet med kunden
Når pentesten kan bruges som dokumentation
En pentest kan i nogle tilfælde understøtte en kompenserende foranstaltning. Hvis I påstår, at to dele af systemet er adskilt, kan en test, der har forsøgt at krydse grænsen uden held, være et argument. Hvis I påstår, at en funktion er begrænset til færre brugere, kan testen have bekræftet, at begrænsningen virker.
Testen skal dog have haft netop det med i omfanget. En rapport, der ikke nævner adskillelsen, kan ikke bruges som bevis for den. Derfor er det en god idé at fortælle testeren om de foranstaltninger, I regner med at henvise til over for kunder, så de kan blive afprøvet og beskrevet. → Bestil testen, så rapporten kan bruges over for kunder
Når kunden ikke accepterer forklaringen
Kunden kan sagtens læse beskrivelsen og alligevel sige nej. Kundens egne regler kan kræve præcis det tiltag, der står i skemaet, eller kundens sikkerhedsfolk kan vurdere, at jeres tiltag dækker for lidt. Det er ikke et tegn på, at beskrivelsen var dårlig, men på at kunden vægter risikoen anderledes.
Spørg i så fald, hvad kunden har brug for for at kunne acceptere. Nogle gange er svaret en tidsplan for, hvornår kravet bliver opfyldt fuldt ud. Andre gange kan en ekstra afprøvning ved næste test, eller en skriftlig bekræftelse fra ledelsen, være nok. Og nogle gange er kravet ufravigeligt, og det bliver en forretningsmæssig beslutning, om I vil ændre produktet for at vinde kunden. Den beslutning hører ikke hjemme hos sælgeren alene. → Forhandling af sikkerhedskrav
Notér under alle omstændigheder kundens svar sammen med jeres beskrivelse. Når samme krav kommer fra næste kunde, ved I så, hvordan forklaringen blev modtaget sidst, og om det er tid til at opfylde kravet i stedet for at kompensere for det.
Det skal I lade være med
- Kalde en plan for en foranstaltning · Et tiltag, der ikke findes endnu, kompenserer ikke for noget.
- Bruge begrebet til at undgå et nej · Kunden skal stadig kunne se, at kravet ikke er opfyldt.
- Beskrive tiltag, I ikke kan vise · Kunden kan bede om dokumentation.
- Lade sælgeren formulere den tekniske del · Beskrivelsen skal godkendes af dem, der kender tiltaget.
- Glemme udløbet · En midlertidig foranstaltning, der aldrig bliver taget op igen, bliver til en permanent mangel.
Hvad kan og ikke kan konkluderes
En beskrevet kompenserende foranstaltning viser, at I kender risikoen og har gjort noget ved den. Den siger ikke, at kravet er opfyldt, og den forpligter ikke kunden til at acceptere den. Teksten er ikke juridisk rådgivning, og hvis kravet står i en kontrakt eller en standard, kan der være særlige regler for, hvordan afvigelser skal dokumenteres og godkendes.
Tjekliste før I henviser til en kompenserende foranstaltning
- ☐ Kender I formålet med det oprindelige krav?
- ☐ Findes tiltaget i dag, og virker det?
- ☐ Kan I dokumentere det over for kunden?
- ☐ Er beskrivelsen godkendt af udvikling eller drift?
- ☐ Er tekniske detaljer holdt ude af skemaet?
- ☐ Er det aftalt, hvornår tiltaget tages op igen?
Kilder
- NIST CSRC ordliste: compensating security control: tiltag, der bruges i stedet for et anbefalet tiltag og giver tilsvarende eller sammenlignelig beskyttelse.
Senest gennemgået: oktober 2026.
Næste skridt
- Ja, nej eller delvist: når svaret ikke passer i skemaet
- Forhandling af sikkerhedskrav: hvad kan I sige nej til?
Del af: Artikler om pentestrapporten
Læs også: Svar, I ikke kan dokumentere · Skemaet spørger til åbne fund
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest af SaaS hos Nielco IT