Hva inngår i en sikkerhetsgjennomgang av bedriften?

I en sikkerhetsgjennomgang av bedriften må du skille mellom den organisatoriske delen, som vurderer ansvar, tilganger, sikkerhetskopier og hendelseshåndtering, og den tekniske delen, som undersøker systeminnstillinger, sårbarheter og kode. Prisen avhenger av hvor mange systemer som skal undersøkes, og hvor grundig arbeidet skal være: vår automatiserte sikkerhetssjekk koster 89–890 € avhengig av omfanget, mens en manuell ekspertgjennomgang er tilgjengelig fra 3 500 €. Avklar først hvilken del du trenger, og hvilken dokumentasjon du forventer, for en undersøkelse av nettstedet, en vurdering av bedriftens sikkerhetsstyring og en sertifisering er forskjellige oppdrag med forskjellige resultater.

Se for deg at en kunde sender et krav om sikkerhetsgjennomgang før kontrakten skal signeres, mens vedlegget inneholder spørsmål om både de ansattes tilgangsrettigheter og teknisk testing av systemet. Det holder ikke å videresende kravet til utvikleren: du må avklare om kunden forventer en rapport om nettstedet, dokumenterte bedriftsprosesser eller et sertifikat fra et uavhengig organ, og hvilke systemer eller deler av virksomheten denne bekreftelsen skal dekke. Vi anbefaler å ta vare på den nøyaktige ordlyden i forespørselen og avklare formålet før du velger leverandør og godtar prisoverslaget.

To oppgaver med samme navn

De to delene besvarer forskjellige spørsmål. Den organisatoriske delen undersøker hvordan bedriften tar og gjennomfører sikkerhetsbeslutninger, mens den tekniske delen undersøker hvordan et bestemt system fungerer, og om beskyttelsen kan omgås. Derfor ser det samme temaet helt forskjellig ut i de to delene: ved en vurdering av rutinene for tilgangsrettigheter ber revisoren om å få se hvem som godkjenner en ansatts rettigheter, og hvordan de trekkes tilbake, mens vedkommende i en applikasjonstest forsøker å utføre handlinger med en vanlig konto som kontoen ikke har tillatelse til. Det er nyttig å lese begge resultatene samlet, men det ene erstatter ikke det andre: en ryddig tilgangspolicy beviser ikke at applikasjonen følger den, og en sikker applikasjon beviser ikke at noen har stengt kontoen til en ansatt som har sluttet.

Derfor sier ordet «gjennomgang» alene lite i en bestilling. Vi anbefaler å legge til to ting: kriteriene arbeidet skal vurderes etter, og dokumentasjonen du forventer i rapporten. For en sårbarhetsvurdering er dette prioriterte funn, for penetrasjonstesting en konkret beskyttelsesmekanisme eller handlingsbegrensning som skal forsøkes omgått, og for en organisatorisk samsvarsrevisjon et sett med krav som dokumenter og daglig praksis skal sammenlignes med.

Hvis du bare velger en innledende vurdering av mangler, bør du også kalle resultatet det, framfor sertifisering, og allerede i oppdragsbeskrivelsen avtale hvem som skal lese dokumentet, og hvilken beslutning som skal tas. Ved sertifisering er det viktig å vite hvem som skal utstede bekreftelsen: ISO sertifiserer ikke selv bedrifter, og forklarer sertifisering som en skriftlig bekreftelse fra et uavhengig organ på at bestemte krav er oppfylt. I den samme forklaringen opplyser ISO at akkreditering bekrefter sertifiseringsorganets kompetanse, men ikke er obligatorisk; derfor ville det være upresist å hevde at bare et akkreditert organ kan sertifisere. Hvis kunden din krever akkreditert sertifisering, bør du avklare dette vilkåret før kontrakten inngås og kontrollere akkrediteringen til det valgte organet, slik at du senere ikke står med en bekreftelse kunden ikke har sagt seg villig til å godta.

Vi tilbyr teknisk testing av websystemer, og i den organisatoriske delen kan vi hjelpe med å utarbeide sikkerhetspolicyer, men vi sertifiserer ikke bedrifter og driver ikke et ledelsessystem for informasjonssikkerhet på dine vegne, og denne avgrensningen bør også stå i bestillingen. Hvis oppdraget omfatter både undersøkelse av nettstedet og vurdering av bedriftens styring, må du avtale hvem som utarbeider den tekniske dokumentasjonen, hvem som sammenligner den med de valgte kravene, og hvem som har ansvaret for sluttvurderingen, ellers kan du forvente en vurdering av styringsprosessen fra oss og en test du ikke har bestilt fra den organisatoriske revisoren. Den organisatoriske delen utføres vanligvis av en rådgiver innen informasjonssikkerhetsstyring eller en ISO/IEC 27001-revisor, mens sertifikatet utstedes av et sertifiseringsorgan.

Den organisatoriske delen: dokumentene må sammenlignes med praksis

Det er lett å få alt til å se bra ut på papiret, så i den organisatoriske delen bør du undersøke om det finnes en ansvarlig person, nødvendige ressurser og dokumentasjon på gjennomføring for det sikkerhetspolicyen fastsetter, og om det er planlagt tiltak for problemene risikovurderingen beskriver; ENISAs veiledning for små og mellomstore bedrifter dekker ledelsens ansvar, ansattes medvirkning og opplæring, sikkerhetspolicyer, leverandørstyring, tilgangsbeskyttelse og en plan for hendelseshåndtering. Suppler samtalene med ledelsen og de ansatte med gjennomgang av dokumenter og konkrete eksempler fra arbeidet, slik at vurderingen skiller mellom planlagte rutiner og faktisk gjennomføring, og oppgir hvilken dokumentasjon revisoren ikke fikk tilgang til, og som fortsatt må utarbeides.

Når det gjelder tilgang, ser en god revisor både på hvordan kontoer tildeles og stenges, om flerfaktorautentisering brukes, og hvilke rettigheter leverandører har, så eksemplene som undersøkes bør omfatte en ansatt som slutter, eller et leverandørbytte: det er nettopp da kontoer ofte blir glemt. Det samme gjelder sikkerhetskopier, for svaret «vi tar sikkerhetskopier» sier lite. En sikkerhetskopi som ingen noen gang har prøvd å gjenopprette, kan vise seg å være ufullstendig når en hendelse oppstår, og det oppdager man først når nettstedet allerede er nede. Oversikten over systemer og enheter trenger ansvarlige personer, hendelsesloggene trenger rutiner for gjennomgang, og planen for hendelseshåndtering trenger en navngitt person som tar beslutninger og kommuniserer med de involverte, ellers forblir planen et dokument ingen følger når hendelsen oppstår.

Som kriterier kan du bruke ISO/IEC 27001:2022, som stiller krav til et ledelsessystem for informasjonssikkerhet; med ordet «system» menes her styringen, ikke bare applikasjonen som undersøkes; BSIs forklaring av standarden beskriver 93 informasjonssikkerhetstiltak og fire områder: organisatoriske, personellrelaterte, fysiske og teknologiske. Avtal hvilke krav revisjonen skal vurdere, og hvilken dokumentasjon som skal brukes, for en henvisning til standarden i et prisoverslag sier ennå ikke om du bestiller en vurdering av ledelsessystemet eller bare en teknisk undersøkelse som senere skal inngå i en bredere revisjon; skriv ned dette valget før arbeidet starter.

Et annet grunnlag er CIS Controls v8.1 med 18 grupper av kontrolltiltak, som dekker alt fra oversikt over bedriftens ressurser til penetrasjonstesting og til sammen omfatter 153 beskyttelsestiltak. CIS beskriver CIS Implementation Group 1 (IG1) som et grunnleggende nivå av cybersikkerhet med 56 beskyttelsestiltak, så presiser også hvilken gruppe som er valgt i bestillingen, ikke bare navnet på rammeverket. Be om at rapporten knytter hvert vurderte krav til mottatt dokumentasjon og den påviste mangelen, slik at du etter utbedringene kan kontrollere nøyaktig det samme forholdet framfor å sammenligne to generelle vurderinger.

Når loven krever en sikkerhetsrevisjon

Digitalsikkerhetsloven (lov 20. desember 2023 nr. 108), som trådte i kraft 1. oktober 2025, og digitalsikkerhetsforskriften (forskrift 20. juni 2025 nr. 1131) pålegger verken en tilbyder av samfunnsviktig tjeneste eller en tilbyder av digital tjeneste en generell plikt til å bestille ekstern revisjon med jevne mellomrom. Tilsyn føres av sektormyndigheten som ansvarlig departement utpeker, eller av Nasjonal sikkerhetsmyndighet (NSM) hvis ingen er utpekt. Tilsynsmyndigheten kan kreve opplysninger og tilgang til lokaler og utstyr, bruke bistand fra andre og pålegge retting av overtredelser. For tilbydere av digitale tjenester kan tilsyn bare gjennomføres når myndigheten har mottatt opplysninger om overtredelser og finner tilsyn nødvendig. «Overvåking, revisjon og testing» i lovens § 10 er momenter ved vurderingen av sikkerhetsnivået for disse tilbyderne; bestemmelsen fastsetter verken et intervall eller krav om uavhengig revisor. Der annen lov stiller tilsvarende eller strengere sikkerhetskrav, gjelder disse i stedet for digitalsikkerhetslovens krav. For virksomheter som omfattes av sikkerhetsloven, er tilsyn som hovedregel en systemrevisjon utført av sikkerhetsmyndigheten eller den utpekte sektormyndigheten, som kan samle inn teknisk informasjon med automatiserte metoder. Virksomheten kan be sikkerhetsmyndigheten om å teste sikkerheten ved å forsøke å trenge inn i et skjermingsverdig informasjonssystem. For datasenteroperatører gjelder en særskilt adgang: Nasjonal kommunikasjonsmyndighet (Nkom) kan pålegge sikkerhetsrevisjon av hele eller deler av virksomheten når innhentede opplysninger eller gjennomført tilsyn ikke avklarer nødvendige sikkerhetsspørsmål. Revisjonen skal utføres av en uavhengig, kvalifisert tredjepart, og resultatet skal sendes til Nkom; operatøren dekker kostnadene. Får du tilbud om en obligatorisk revisjon, bør du spørre hvilken lov og hvilken status tilbudet bygger på.

Digitalsikkerhetsforskriften § 6 krever at en tilbyder av samfunnsviktig tjeneste har et dokumentert sikkerhetsstyringssystem som virksomhetens leder godkjenner og gjennomgår minst én gang i året. Dette er en intern gjennomgang uten krav om innsending til NSM. Forskriften har ingen ordning med innsendt egenvurdering og felles rapporteringsfrist og ingen generell plikt til å bestille penetrasjonstesting med faste intervaller. Virksomheter som omfattes av sikkerhetsloven, må minst årlig vurdere om styringssystemet for sikkerhet er egnet; lederen skal også årlig gjennomgå det forebyggende sikkerhetsarbeidet samlet. Behovet for en ny helhetlig risikovurdering skal vurderes årlig. Informasjonssystemer som skal behandle sikkerhetsgradert informasjon, må godkjennes før bruk. Virksomheten kan be sikkerhetsmyndigheten teste systemet ved å forsøke å trenge inn i det; dette er ikke et krav om å kjøpe en slik test med faste intervaller. For finansielle enheter har DORA gjeldt i Norge siden 1. juli 2025. Finanstilsynet utpeker hvilke foretak som skal gjennomføre trusselbasert penetrasjonstesting (TLPT), og fastsetter testhyppigheten. Utgangspunktet i DORA artikkel 26 er minst hvert tredje år for de utpekte foretakene, men Finanstilsynet kan øke eller redusere hyppigheten. Norges Bank godkjenner hvilke funksjoner testen skal omfatte, koordinerer testen og utsteder attesten; Finanstilsynet følger opp funnene og utbedringsplanen. Norges Banks kostnader ved TLPT belastes de utpekte foretakene. Finansielle enheter, med unntak av svært små bedrifter, skal dessuten ha regelmessig internrevisjon av rammeverket for IKT-risikostyring, med en hyppighet som står i forhold til IKT-risikoen og uten ett felles lovfestet intervall. Når du mottar et tilbud om å gjennomføre en «obligatorisk revisjon», bør du derfor be om at den konkrete plikten og din status blir angitt: tilbyder av samfunnsviktig tjeneste, tilbyder av digital tjeneste, virksomhet under sikkerhetsloven, datasenteroperatør eller finansielt foretak utpekt av Finanstilsynet for TLPT. Årlig ledelsesgjennomgang, tilsyn, tredjepartsrevisjon pålagt av Nkom og TLPT for utpekte foretak er forskjellige oppgaver og må ikke behandles som ett og samme oppdrag.

Den tekniske delen: fra offentlige adresser til kode

Oppgi offentlige adresser, DNS-poster, åpne tjenester og TLS-innstillinger i den tekniske oppdragsbeskrivelsen, sammen med server- eller skykonfigurasjon, webapplikasjoner og kildekode du tillater at undersøkes, og angi for hver del om leverandøren får tilgang til innstillingene eller bare skal vurdere det som er synlig utenfra, for dette er forskjellige oppgaver. NISTs inndeling av metoder for sikkerhetstesting skiller gjennomgang av dokumenter, logger og konfigurasjon fra identifisering og analyse av testmål og fra bekreftelse av sårbarheter; denne inndelingen kan du bruke til å beskrive valgte metoder og forventet resultat mer presist i prisoverslaget.

For webapplikasjoner gir OWASP Top 10:2025 et felles språk: ti risikokategorier, der de to første er svikt i tilgangskontroll og usikker konfigurasjon. Listen tester ingenting i seg selv, så en god revisor gjør hver kategori om til et spørsmål om applikasjonen din: for tilgangskontroll innebærer det å forsøke handlinger som tilhører én rolle med en konto som har en annen rolle, mens kategorien usikker utforming innebærer å velge en forretningsprosess der noen kan omgå reglene. Suppler henvisningen til OWASP med undersøkelsens omfang, slik at begge parter vet hvilke funksjoner og brukerroller som faktisk inngår i arbeidet.

For e-post bør du inkludere vurdering av SPF-, DKIM- og DMARC-innstillingene og knytte oppgaven til systemene bedriften sender meldinger fra: Googles krav til avsendere har siden 1. februar 2024 krevd at alle som sender til Gmail-kontoer, setter opp SPF eller DKIM, mens de som sender mer enn 5 000 meldinger daglig, må sette opp både SPF, DKIM og DMARC. DMARC-policyen kan være «none», men for direkteutsendelser må domenet i From-feltet samsvare med SPF- eller DKIM-domenet; be derfor om at både innstillingene og utsendelsesveiene du bruker blir vurdert, framfor bare en avkrysning for at domenepostene finnes.

Det vanligste funnet i våre gjennomganger er manglende oppdateringer av PHP, kjernen i innholdsstyringssystemet og programvarerammeverk. Derfor anbefaler vi å inkludere en oversikt over versjoner, utvidelser og avhengigheter i den tekniske oppdragsbeskrivelsen, og å kreve at funnbeskrivelsen angir den konkrete komponenten og nødvendig handling, slik at utvikleren får en oppgave som kan utføres, framfor en generell merknad om et utdatert nettsted. Hvis det viktigste for deg er hva brukerne har lov til å gjøre i systemet, er ikke en versjonsoversikt nok: da trengs også tester av tilgangskontroll og testing av forretningslogikk. Vi har opplevd kritiske feil som gjorde det mulig for enhver bruker å få administratorrettigheter, og utbedringen endte med at hele systemkjernen måtte skrives om; en versjonsoversikt ville ikke ha avdekket en slik feil.

Spørsmålet om hva brukeren har lov til å gjøre, er et annet enn spørsmålet om installerte versjoner, og begge trenger egen dokumentasjon i rapporten. NIST definerer sårbarhetsskanning som en metode for å identifisere vertsmaskiner, egenskapene deres og tilknyttede sårbarheter, mens skanning er ett av trinnene i det tekniske arbeidet i vår automatiserte sikkerhetssjekk. Penetrasjonstesting kjennetegnes ifølge NIST av at reelle angrep etterlignes for å finne muligheter til å omgå beskyttelsen, ofte også kombinasjoner av sårbarheter som gir utvidet tilgang. Valget av selve testen går vi nærmere inn på i artikkelen om penetrasjonstesting; i bestillingen av gjennomgangen er det vesentlig å angi hvilke svakheter leverandøren bare skal lete etter, hvilke leverandøren innenfor avtalte grenser skal forsøke å påvise praktisk utnyttelse av, og hvilke handlinger som bevisst skal holdes utenfor arbeidet.

Slik går gjennomgangen fra oppdragsbeskrivelse til ny test

Begynn med en skriftlig beskrivelse av omfanget av revisjonen som angir systemene, applikasjonene, adressene og brukerrollene som skal undersøkes, og tydelig sier hva som ikke skal undersøkes i dette oppdraget, og legg til formålet og grensene for arbeidet: hvilke handlinger du tillater, hvilket miljø de skal utføres i, hvem som kan stoppe undersøkelsen, og hvem som skal kontaktes hvis noe uforutsett oppstår; for et bestillingssystem bør du for eksempel avtale særskilt hvordan handlinger som ellers ville opprettet en reell bestilling, skal testes. Også driftsleverandøren din må lese denne avtalen, slik at tillatte handlinger, tilganger og kontaktpersoner er avklart før det tekniske arbeidet starter.

Før arbeidet starter, må du klargjøre dokumenter og personer for samtaler i det omfanget oppdraget krever: for den organisatoriske delen policyer, eksempler på tildeling av tilgang, dokumentasjon av gjenoppretting fra sikkerhetskopier og en plan for hendelseshåndtering, og for den tekniske delen en systembeskrivelse og avtalte tilganger, samtidig som du markerer det du ennå ikke har. Hvis en kopi skal testes, bør du beskrive forskjellene fra systemet som brukes til daglig, og avtale hvordan de skal framgå av rapporten, slik at leseren senere kan forstå hvilket miljø resultatene gjelder, og hvilke spørsmål som står åpne fordi dokumenter, tilgang eller den aktuelle funksjonen ikke var tilgjengelig. Avtal konkrete testtidspunkter og kommunikasjonsrutiner for det tekniske arbeidet, og sett en frist for når kollegene dine kan sende inn presiseringer til dokumentvurderingen, slik at resultatet tydelig skiller det som er undersøkt, fra det som ennå ikke er bekreftet.

Hvis leverandøren finner et vesentlig problem underveis, bør du kreve at det meldes fra om etter avtalt rutine mens resten av arbeidet fortsetter, uten å vente til leveringsdatoen for hele rapporten. Avtal også hvem som beslutter om testingen på dette punktet skal fortsette, og hvordan mottatte tillatelser eller begrensninger skal dokumenteres, for disse beslutningene blir nødvendige når det skal forklares hvor langt det enkelte funnet kunne bekreftes.

Tidsplanen må også gi rom for utbedringer

En gjennomgang med systemet vårt tar noen dager, mens selve arbeidet med en manuell gjennomgang tar 1–3 uker avhengig av omfanget av revisjonen, og det kan være ventetid før oppstart fordi denne avhenger av revisorens kapasitet. Tjenestesiden oppgir en samlet leveringstid på 1–60 dager, så ikke oppfatt disse beskrivelsene som én garantert frist, og avtal oppstartsdato, overlevering av rapporten og ny test før du bestiller. Hvis du har en dato fastsatt av en kunde eller en anbudskonkurranse, må du også planlegge tid til å gjennomgå og utbedre funnene og til at teamet ditt kan svare på spørsmål, for datoen undersøkelsen er ferdig, og datoen du ønsker å ha rettet manglene innen, er forskjellige punkter i planleggingen.

Tilbudet vårt om manuell ekspertgjennomgang omfatter en ny test innen 30 dager etter utbedringene. For å få nytte av den bør du ved overlevering av rapporten avtale hvem som utbedrer hvert funn, hvem som melder fra når arbeidet er ferdig, og hvilken dokumentasjon leverandøren skal kontrollere på nytt; omfanget av og betalingen for selve utbedringene må avklares separat, for prisen på gjennomgangen er ikke en avtale om all videre utvikling. Du kan la ditt eget team gjøre utbedringene og oss kontrollere dem etterpå, eller overlate dem til oss som et eget oppdrag vi beregner etter rapporten. Be om at rapporten etter den nye testen skiller mellom utbedrede mangler og mangler som er utsatt eller ennå ikke testet på nytt, og oppgir hvilken tilstand systemet var i under testen, slik at teamet ditt og rapportmottakeren får ett forståelig svar om hvert opprinnelige funn.

Hva du bør kreve i rapporten

Be om en oversikt i starten av rapporten som ledelsen kan forstå, med undersøkelsens formål, systemene den omfatter og de viktigste funnene, slik at beslutninger om arbeid og ressurser kan tas uten å lese alt det tekniske materialet, og be om at begrensningene ved arbeidet oppgis samme sted. Hvis kildekoden ikke var tilgjengelig eller en brukerrolle ikke ble undersøkt, bør dette sies direkte, framfor at leseren må gjette hva den korte vurderingen av systemets tilstand betyr; vurder en slik oversikt etter om lederen din kan bruke den til å angi neste beslutning, en ansvarlig person og spørsmålet som fortsatt er ubesvart.

For hvert teknisk funn bør du kreve plasseringen i systemet, omstendighetene det ble oppdaget under, brukerrollen som ble brukt, en beskrivelse av hvordan handlingene kan gjentas, og dokumentasjon av resultatet, mens organisatoriske avvik bør angi dokumentet eller arbeidseksemplet vurderingen bygger på, sammen med henvisningen til kravet. Utbedringsanbefalingen må gjøre det forståelig hva som konkret skal endres, så presiser formuleringen «rydde opp i tilganger» til de bestemte rettighetene og funksjonen utvikleren din må endre, og oppgi forventet oppførsel etter utbedringen, slik at rapporten kan brukes både til overlevering av oppgaven og til senere kontroll uten at hver nye leser må tolke revisorens hensikt på nytt.

Hvis rapporten bruker CVSS, bør du også be om versjonsnummeret: FIRST publiserer CVSS, inkludert versjon 4.0, der betegnelsene på alvorlighetsskalaen er «ingen» (0,0), «lav» (0,1–3,9), «middels» (4,0–6,9), «høy» (7,0–8,9) og «kritisk» (9,0–10,0); bruken av disse språklige betegnelsene er valgfri. Be om en begrunnelse og en forklaring knyttet til driften av bedriften din i tillegg til tallet, for eksempel hvilken handling eller hvilket datasett funnet berører, og hvorfor det anbefales å utbedre det i denne rekkefølgen, slik at prioriteringen kan diskuteres ut fra de beskrevne omstendighetene og ikke bare tallet.

Vi bruker erfaringen med slike kritiske feil til å kreve en tydelig beskrivelse av konsekvensene, framfor å hevde at alle nettsteder trenger ombygging: rapporten må kunne skille en konkret utbedring fra et problem som krever at systemets grunnleggende virkemåte vurderes på nytt. Hvis rapporten anbefaler omfattende omarbeiding, bør du be om å få se hvilken dokumentasjon anbefalingen bygger på, hva som kan utbedres separat, og hvilket spørsmål som forblir uløst hvis bedriften bare velger deler av det foreslåtte arbeidet.

Be om skannerens rå resultatfil som vedlegg hvis det tekniske teamet trenger den, men knytt godkjenningen av rapporten til dokumentasjonen, prioriteringene og gjennomførbare utbedringsanbefalinger du forventer i bestillingen; ikke bruk antall linjer som kvalitetsmål. Be leverandøren forklare ett funn fra begynnelse til slutt: hvordan det ble oppdaget, hva resultatet bekrefter, hvordan det berører systemet ditt, og hvordan det etter endringene skal kontrolleres at problemet er utbedret, og dessuten angi alt i konklusjonen som fortsatt er antakelser; en slik gjennomgang gir et konkret grunnlag for å godkjenne rapporten og fordele det videre arbeidet.

Hvorfor prisene på gjennomganger varierer så mye

Prisene varierer først og fremst fordi tilbudene dekker forskjellig antall systemer og forskjellig grundighet i arbeidet: automatisert skanning og versjonsoversikt koster noen hundre euro, mens manuelle tester av tilgangskontroll, testing av forretningslogikk, kildekoderevisjon og ny test krever arbeidsdager fra en ekspert. I vår tjeneste for sikkerhetsgjennomgang av nettstedet koster den automatiserte sikkerhetssjekken 89–890 € avhengig av omfanget og er beregnet på WordPress-, Laravel-, Drupal-, Joomla- og Moodle-systemer. Tilbudet omfatter automatisert sårbarhetsskanning, kontroll av versjoner, utvidelser og avhengigheter, vurdering av konfigurasjon og serverinnstillinger og en rapport med funn og prioriteringer; bruk dette innholdet når du sammenligner prisen med andre tilbud, og avklar hvilke installasjoner hos deg som skal undersøkes. Se den laveste summen i intervallet i sammenheng med det avtalte omfanget, slik at du ikke overfører prisen for undersøkelse av ett nettsted til hele bedriftens systemsamling før leverandøren har vurdert grensene for denne.

Vår manuelle ekspertgjennomgang er tilgjengelig fra 3 500 € og omfatter manuell testing etter OWASP Top 10, tester av tilgangskontroll, testing av forretningslogikk, kildekoderevisjon og autorisert penetrasjonstesting. Kildekoderevisjon tilbys for Laravel, WordPress og skreddersydde løsninger, og i rapporten ordner vi funnene etter reell risiko og legger til en utbedringsanbefaling for hvert funn; tilbudet inkluderer også en ny test etter utbedringene. Ordene «fra» gjelder også når systemet ditt bare har én offentlig adresse, for funksjoner, roller og koden som skal undersøkes må fortsatt avklares før prisen kan beregnes.

En full sjekk med systemet vårt koster vanligvis 500–800 €. Det er beløpet vi oftest ser innenfor prisintervallet for den automatiserte sikkerhetssjekken, ikke en egen pris for en samlet vurdering av bedriftens styring, alle systemer og sertifisering, så knytt ordet «full» til det konkrete tekniske omfanget som vi har avtalt. For de fleste nettsteder anbefaler vi regelmessig automatisert sikkerhetssjekk, som kan gjentas ofte, og manuell ekspertgjennomgang når systemet behandler betalinger eller personopplysninger eller er kritisk for virksomheten, fordi feil i tilgangsrettigheter og omgåelse av forretningslogikk bare oppdages av et menneske; i praksis fungerer regelmessige automatiserte sikkerhetssjekker og en manuell gjennomgang én gang i året godt.

Denne forskjellen er også nyttig i budsjettsamtalen: hvis du trenger svar om nettstedets komponenter og innstillinger, bør du be om et overslag for den oppgaven, mens du bør inkludere relevante manuelle tester og la leverandøren beregne dette arbeidet separat hvis hovedspørsmålet gjelder omgåelse av brukerrettigheter eller forretningsregler.

Lag en felles beskrivelse av systemer, applikasjoner, brukerroller og, hvis den organisatoriske delen også trengs, bedriftens driftssteder som grunnlag for sammenligning, og be deretter om at automatiserte og manuelle handlinger oppgis separat. Se for deg ett prisoverslag for bare det offentlige nettstedet og et annet for det samme nettstedet sammen med kundeportal, administrasjon og kildekode: avklar grensene for hvert tilbud før du sammenligner beløpene. Noter også nødvendige tilganger, valgte samsvarskriterier og rapportmottakeren for hver del, for slik gir du leverandøren et konkret beregningsgrunnlag og deg selv muligheten til å oppdage en utelatt oppgave.

Avklar særskilt om prisen inkluderer forklaring av funnene til utvikleren din, kobling til kravene i den valgte standarden og ny test, og hvor gjennomgangen slutter og utviklingsarbeidet med utbedringene begynner, og vi anbefaler at budsjettet for gjennomgangen også tar høyde for en beslutning om å utbedre de påviste manglene. Hvis prisene fortsatt varierer vesentlig mellom tilbud med samme omfang, bør du be leverandørene forklare arbeidet og grensene for det med én konkret funksjon, for eksempel endring av en brukers tilgang, framfor med flere tjenestenavn; da kan du velge ut fra et konkret resultat og ansvar uten å støtte deg på et løfte om fullstendig sikkerhet.

Når bedriften trenger en sikkerhetsgjennomgang

Vi anbefaler å bestille en gjennomgang når bedriften må ta en konkret sikkerhetsbeslutning eller gi en bekreftelse som kan etterprøves, og allerede fra starten angi om beslutningen gjelder styring, teknisk tilstand eller begge deler. Hvis årsaken er NIS2, bør du først avklare statusen din og hvilke krav som gjelder, blant annet ved hjelp av artikkelen vår om NIS2 og hvem direktivet gjelder for, og deretter formulere oppdragsbeskrivelsen. Rekkefølgen er viktig her: avklar om kravet gjelder, og hvilken bekreftelse som trengs, før du velger tjeneste, slik at bestilling av en teknisk rapport ikke blir ditt eneste svar på et spørsmål der også bedriftens ansvar og prosesser må vurderes. Hvis nettstedet verken har brukerkontoer, betalinger eller behandling av personopplysninger, og ingen krever en bekreftelse, er en omfattende gjennomgang vanligvis unødvendig: installer først oppdateringene, så er en automatisert sikkerhetssjekk tilstrekkelig.

Hvis et forsikringsselskap eller en kunde krever undersøkelsen, bør du be om en presisering av forventet resultat og gi leverandøren selve kravteksten; skill for eksempel spørsmål om opplæring av ansatte eller testing av gjenoppretting fra sikkerhetskopi fra et krav om å teste applikasjonens tilgangsrettigheter, og klargjør relevant dokumentasjon til svarene. Hvis et leverandørskjema krever bekreftelse på en bredere sikkerhetsprosess enn den tekniske gjennomgangen din dekker, bør du avtale tilleggsinformasjonen med kunden og utpeke en person i bedriften som samler den inn, framfor å tillegge den tekniske rapporten en videre betydning; avklar samtidig om mottakeren forventer selve rapporten, svar på bestemte spørsmål eller en annen form for bekreftelse, og hvilken frist som gjelder.

Ved anbud bør du bevare kravene til undersøkelsestype og leverandørens kvalifikasjoner nøyaktig slik oppdragsgiveren har formulert dem, og avklare uklarheter før du ber om pris, slik at tilbudet ikke må skrives om etter at arbeidet har startet. Vi går nærmere inn på valget i artikkelen om sikkerhetsundersøkelsen som kreves i anbudet, og for å utarbeide den tekniske oppdragsbeskrivelsen kan du sende oss ordlyden i kravet og en systembeskrivelse. Oppgi også innleveringsfristen, tilgjengelig dokumentasjon og hvem på din side som skal utføre utbedringene, for samtalen om gjennomføringen må dekke både utarbeidelsen av rapporten og teamets mulighet til å arbeide med resultatene innen den nødvendige datoen.

Etter en hendelse og mellom planlagte undersøkelser

Etter en hendelse anbefaler vi å tilpasse oppdragsbeskrivelsen til det konkrete ubesvarte spørsmålet: om utbedringen løser det påviste problemet, om en lignende tilgangsfeil bør letes etter i en annen funksjon, og hvordan bedriften heretter skal kontrollere at den aktuelle rutinen følges. Gi leverandøren en beskrivelse av de kjente hendelsene og skill bekreftede fakta fra antakelser. Hvis du vil avklare hendelsesforløpet, bør du også definere dette som et eget arbeid og avtale resultatet, uten å anta at en generell sikkerhetsgjennomgang av nettstedet automatisk besvarer alle spørsmål om hendelsen; bevar samtidig koblingen mellom utbedringene som skal testes og de opprinnelige funnene, slik at du etter endringene kan si nøyaktig hvilket problem du testet på nytt, og hvordan.

Kundene våre bestiller vanligvis en gjennomgang én eller to ganger i året; det er en observasjon fra vår erfaring, ikke et intervall som er fastsatt for alle bedrifter. Vi anbefaler å føre opp både neste dato og endringer som skal utløse en ny vurdering av undersøkelsens omfang i planen din, for eksempel en ny brukerrolle, en omskrevet tilgangsfunksjon eller bytte av en leverandør med rettigheter i systemet. Gi den ansvarlige personen i oppgave å sammenligne disse endringene med omfanget av den forrige revisjonen og foreslå den konkrete delen som skal undersøkes, og ta med uløste funn fra den forrige rapporten i neste oppdragsbeskrivelse sammen med beslutningene om å utsette dem, slik at den nye undersøkelsen starter med den kjente situasjonen.