--- title: Oppdrag vi sier nei til description: Noen forespørsler får nei uansett hvem som spør og hva de betaler. Her står hvilke, hvorfor «kunden har bestilt det» ikke er nok, og hva vi tilbyr i stedet. updated: 2026-08-16 sources_checked: 2026-08-16 canonical: https://glippen.no/oppdrag-vi-sier-nei-til author: Erik Nilsen --- # Oppdrag vi sier nei til Det kommer forespørsler vi ikke tar. Som regel ikke fordi arbeidet er vanskelig, men fordi det ikke er lovlig, eller fordi den som spør ikke kan gi tillatelsen på vegne av den som eier systemet. De står her med begrunnelse, slik at dere slipper å bruke tid på å spørre og vi slipper å bruke tid på å avslå. De fleste av dem har et brukbart alternativ. Én av dem har det ikke. ## Tilgang til kontoen til noen andre Den vanligste henvendelsen som ikke er et oppdrag, handler om kontoen til en ekspartner, en tidligere kollega eller et familiemedlem. Den kommer sjelden rett fram. Den kommer som at kontoen egentlig er felles, at innholdet uansett tilhører den som spør, eller at det bare gjelder å få bekreftet noe man allerede vet. Svaret er nei, og vi ber ikke om detaljer. Å skaffe seg tilgang til et datasystem uten å ha rett til det er straffbart i Norge, og det gjelder også når det er kontoen til noen du kjenner godt, og også når motivet er forståelig. Dette er den ene der vi ikke har noe å tilby i stedet. Er du redd for at noen andre har tilgang til dine egne kontoer, er det et helt annet spørsmål, og det hjelper vi gjerne med. Handler det om et pågående forhold der noen følger med på deg, hører det hjemme hos politiet og ikke hos en leverandør av sikkerhetstesting. ## Systemer dere ikke eier Vi tester aldri en tredjepart. Ikke med samtykke fra den som bestiller, ikke etter avtale, ikke i det hele tatt. Det eneste vi rører er ressurser dere selv eier. Det gjelder også når begrunnelsen er god. En konkurrent som ser slurvete ut. En leverandør dere vurderer å kjøpe fra. Et system dere er integrert mot og er oppriktig bekymret for. Bekymringen kan være helt reell, og den gir likevel ingen rett til å teste. Er dere bekymret for en leverandør, er den riktige veien å be leverandøren om dokumentasjon: hva som er testet, når, av hvem, og hva som ble rettet etterpå. Det spørsmålet har dere full rett til å stille, og svaret er som regel et bedre beslutningsgrunnlag enn en test fra utsiden ville gitt. ## Hvorfor «kunden har bestilt det» ikke er nok En bestilling gir oss myndighet over bestillerens egne systemer. Den gir ingen myndighet over noen andres. Tillatelsen må komme fra den som eier systemet, og ingen kan gi den på vegne av en annen. Straffeloven § 204 rammer den som ved å bryte en beskyttelse eller ved annen uberettiget fremgangsmåte skaffer seg tilgang til datasystem eller del av det. Strafferammen er bot eller fengsel inntil to år. Ordet som avgjør er «uberettiget», og det er eierens tillatelse som gjør en handling berettiget. Ikke bestillerens, og ikke vår vurdering av at hensikten var god. Når dere bestiller, bekrefter dere at dere har vurdert at det er lovlig for oss å teste systemene som er oppgitt, og at det er i orden med en eventuell leverandør eller driftspartner. Vi arbeider i god tro på grunnlag av det dere oppgir. God tro er utgangspunktet, ikke et fripass. Virker noe uklart, spør vi på nytt, og vi setter ikke i gang før det er avklart. Sidene her finnes blant annet for at den samtalen skal gå fortere. ## Når dere vil teste noe dere leier Dette er den vanskeligste, og den kommer oftest. Dere bruker et fagsystem, et CRM eller en nettbutikkplattform som noen andre eier og drifter. Dere vil vite om det holder, og kanskje sier et krav fra en av kundene deres at det skal testes. Grensen går ved eierskap. Leietakeren deres, dataene deres, oppsettet deres og rettighetsstyringen deres er fortsatt deres, og det kan testes. Selve plattformen til leverandøren er aldri målet, uansett hvem som ber om det og uansett hva de betaler. Samtidig treffer trafikken vår leverandørens infrastruktur, og leverandørens vilkår avgjør hva som er tillatt der. Derfor trenger vi leverandørens egen tillatelse før noe kjøres. Den tillatelsen gjør ikke plattformen til et mål. Den gjør det lovlig å teste deres del av den. Slik skaffer dere den, og vi hjelper gjerne til underveis: - Let først i avtalen og i vilkårene. Mange leverandører har allerede en setning om sikkerhetstesting, og noen har et eget skjema for det. - Spør skriftlig, og be om skriftlig svar. Oppgi hva som skal testes, i hvilket tidsrom, fra hvilken IP-adresse, og at det ikke gjøres destruktive tester eller tjenestenektangrep. - Regn med betingelser. Testmiljø i stedet for produksjon, avtalt tidsvindu, tak på antall forespørsler i sekundet, eller at bare deres egen leietaker inngår. Alt dette kan vi arbeide innenfor. - Får dere nei, be om rapporten deres i stedet. En leverandør som ikke slipper kunder til, har som regel testet selv, og et sammendrag derfra dekker ofte nettopp det kravet dere skulle oppfylle. - Send oss gjerne utkastet til forespørselen. Det tar ti minutter å se over, og det løser saken oftere enn folk tror. > Vi setter ikke i gang før dette er avklart. Derfor står det som et krav i bestillingen, og ikke som en detalj langt nede i vilkårene. ## Testing uten at driftsleverandøren vet om det Ligger systemet hos en driftsleverandør eller en skyleverandør, skal de vite at testen pågår. Det er ikke bare høflighet. Trafikken treffer deres infrastruktur, deres vilkår gjelder for hva som er tillatt, og vaktordningen deres kan ende med å bruke natten på å håndtere noe dere selv har betalt for. Det finnes en god grunn til å ville teste uten at de vet det: dere vil finne ut om de faktisk oppdager noe. Det er et helt legitimt mål, og svaret er ofte det mest nyttige i hele rapporten, fordi det gjelder alle framtidige hendelser og ikke bare denne ene feilen. Løsningen er ikke at ingen vet. Løsningen er at én person vet. Én kontaktperson hos leverandøren som kjenner tidsvinduet og IP-adressen vår, som ikke varsler vaktlaget på forhånd, og som kan stoppe en eskalering hvis den kommer. Da måler dere fortsatt deteksjonen, og ingen bruker natten på en øvelse. At ingen i det hele tatt er varslet, sier vi nei til. Da tester vi ikke lenger bare dere. ## Å hente tilbake en konto noen har mistet Noen spør om vi kan hjelpe dem inn igjen i noe som er deres eget. En gammel e-postadresse, en bedriftsside på et sosialt nettverk, en nettbutikk der den forrige daglige lederen var eneste administrator og ikke lenger svarer. Vi sier nei, av to grunner. Vi kan ikke kontrollere at kontoen faktisk er deres, og vi har uansett ingen avtale med plattformen som eier systemet. Veien inn ville gått gjennom noe vi ikke har lov til å røre, og da spiller det ingen rolle hvem som har rett i saken. Riktig vei er plattformens egen prosess for gjenoppretting eller eierskifte. For bedriftskontoer finnes den nesten alltid, den krever som regel firmaattest og legitimasjon, og den er tregere enn dere håper. Den virker likevel, og den etterlater et spor dere kan vise til. Er det underliggende problemet at én person satt med alle nøklene, er det verdt å rette for framtiden. Hvem som har administratorrettigheter, hvor mange som har dem, og hva som skjer når en av dem slutter, er en fast del av gjennomgangen av Microsoft 365 og Azure. ## Ting som aldri gjøres, uansett pris Noen grenser henger ikke sammen med hvem som eier systemet. De gjelder uansett hva som bestilles og hva som betales. - Tjenestenektangrep, eller bevisst forsøk på å ta ned en tjeneste. Dette gjør vi aldri, uansett hva som bestilles. - Bevisst destruktive handlinger, sletting eller endring av produksjonsdata. - Fysisk inntrengning eller angrep mot maskinvare. Alt arbeid gjøres eksternt. - Uthenting av personopplysninger ut over det som er nødvendig for å dokumentere et funn. - Alt som ikke står i det signerte scope-dokumentet. > Dette er ikke unntak en større bestilling låser opp. De står likelydende i scope-dokumentet dere signerer, slik at nettsiden og avtalen sier det samme. ## Slik sier vi nei Et nei kommer skriftlig, samme dag, med begrunnelsen. Vi skriver hva vi ikke kan gjøre og hvorfor, og vi skriver hva vi eventuelt kan gjøre i stedet. Vi later ikke som om noe er teknisk umulig når det egentlig er ulovlig, og vi bruker ikke et nei som inngang til å selge noe annet. Forskjellen betyr noe for den som spør, og den er billig å opprettholde. Er saken at tillatelsen mangler og kan skaffes, sier vi det og hjelper med å skaffe den. Er saken at tillatelsen ikke kan skaffes, sier vi det også, og da er det slutt på den samtalen. Vi fører ingen liste over hvem som har spurt om hva. ## Det som ikke er avklart Grensene over er klare nok. Det som ikke alltid er klart, er hvem som har myndighet til å gi en tillatelse, og hvor langt tillatelsen rekker når den først er gitt. - Leverandørkjeder. Leverandøren deres sier ja, men leverandøren deres leier igjen av noen andre. Vi ber om at tillatelsen dekker det som faktisk skal testes, og vi vet at det ikke alltid lar seg oppklare helt ned i kjeden. - Hvem som kan si ja hos en leverandør. Vi ber om skriftlig tillatelse fra en navngitt person. Om den personen faktisk hadde fullmakt internt, er ikke noe vi kan kontrollere, og det er en av grunnene til at ansvaret for at testen er lovlig ligger hos dere. - Offentlige bug bounty-programmer er en stående tillatelse, men bare innenfor sitt eget og ofte snevre omfang. Vi behandler dem ikke som grunnlag for et betalt oppdrag, og vi kjenner ikke til norsk rettspraksis som avklarer hvor langt en slik tillatelse rekker. ## Kilder - [Straffeloven § 204, innbrudd i datasystem (Lovdata)](https://lovdata.no/lov/2005-05-20-28/%C2%A7204)