Hva er penetrasjonstesting, og når bedriften trenger det

Sårbarhetskartlegging, gjennomgang og penetrasjonstesting er tre ulike jobber med tre ulike priser. Hvilken av dem svarer på spørsmålet ditt, og hva norsk regelverk faktisk krever.

Du ber om et tilbud på sikkerhet for nettstedet og får tre stykker som skiller seg med en faktor på ti, og på det ene står det «sårbarhetskartlegging», på det andre «sikkerhetsgjennomgang», på det tredje «penetrasjonstest», men i alle tre står det samme ordet «sikkerhet», som ikke sier noe av det som faktisk skiller dem. Det er ikke én jobb i tre trinn og ikke tre priser for det samme, men tre ulike jobber som svarer på tre ulike spørsmål, så det første steget er ikke å sammenligne priser, men å skjønne hvilket av de tre spørsmålene du faktisk vil ha svar på.

Denne artikkelen svarer på to: hva penetrasjonstesting er, og om det er det din bedrift trenger. Det andre spørsmålet er det viktigste, fordi de fleste norske små og mellomstore bedrifter ikke er pålagt penetrasjonstesting av noe regelverk, og et tilbud som tier om det, selger deg riktig tjeneste på feil tidspunkt.

Vi skriver dette mens vi selger sikkerhetsgjennomgang, og det er ingen motsetning i det, fordi en gjennomgang med rom for manuell kontroll og den penetrasjonstestingen et regelverk krever når det krever en, ikke er samme jobb — men en virksomhet som kjøper den andre når den trengte den første, betaler mer og får vite mindre.

Tre jobber som selges under like navn

Begrepene i bransjen er rotete her, men under dem ligger det en klar grense som standardiseringsorganet formulerer best: NIST SP 800-115 definerer penetrasjonstesting som sikkerhetstesting der testerne etterligner reelle angrep for å finne veier rundt systemets beskyttelse, og peker på at den leter etter kombinasjoner av sårbarheter, ikke enkeltfunn. Samme publikasjon beskriver sårbarhetskartlegging som en teknikk for å identifisere ressurser og de kjente sårbarhetene som hører til dem.

I praksis betyr det fire ulike jobber som er verdt å navngi hver for seg. Sårbarhetskartlegging er automatisk, og der sammenligner et verktøy systemet ditt med en database over kjente sårbarheter og leverer en liste. Verifisering og prioritering av funn er den samme listen etter at et menneske har kontrollert og rangert den, som regel uten å utnytte noen av sårbarhetene som ble funnet. Penetrasjonstesting er menneskestyrt arbeid der de svake punktene som er funnet, blir utnyttet og koblet i en kjede, for å avklare hvor langt en angriper faktisk kommer. Etterlevelsesrevisjon svarer på et helt annet spørsmål: om systemet oppfyller en navngitt standard eller norm.

Grensen mellom de tre første formuleres klarest av betalingskortstandarden, som gjør det ikke med en definisjon, men med et mål: PCI-rådets veiledning for penetrasjonstesting skiller penetrasjonstesting fra sårbarhetskartlegging etter hensikten: kartleggingen identifiserer, rangerer og rapporterer sårbarheter; testen leter etter måter å utnytte dem på for å omgå systemets beskyttelse. Samme råd tilføyer begge kantene i selve standarden: kartlegging alene er ikke penetrasjonstesting, og en test som bare forsøker å utnytte skannerens funn, er heller ikke tilstrekkelig.

Derfor er spørsmålet «trenger du penetrasjonstesting» ikke et spørsmål om budsjett, men om hva du vil ha svar på: om systemet ditt har kjente svakheter, eller om noen faktisk kan få til noe med dem.

Hva hver av dem svarer på, og hva de ikke sier

Sårbarhetskartlegging svarer raskt og billig, og det svake punktet er konteksten, fordi verktøyet ikke vet hvilken av de hundre markerte radene som sitter i betalingsskjemaet ditt og hvilken som sitter i et testmiljø ingen når fra internett, og det vet heller ikke at to hver for seg harmløse feil til sammen gir tilgang til databasen — derfor er listen starten på et arbeid, ikke resultatet av det.

Penetrasjonstesting svarer saktere og dyrere, og verdien ligger nettopp i kjeden, fordi testeren ikke leter etter «finnes det en sårbarhet her», men etter «hva kan jeg gjøre med den» — om man fra det offentlige skjemaet kan nå administratorrettigheter, om man fra én kundekonto kan se en annen kundes data, om man fra testmiljøet kan nå produksjonsdatabasen. Svaret på det spørsmålet er det direktøren forstår uten oversettelse.

Etterlevelsesrevisjon gjør verken det ene eller det andre, fordi den kontrollerer om systemet oppfyller en norm, og resultatet er et svar på om normen er oppfylt, ikke en liste over tekniske svakheter; nettopp derfor kan en virksomhet gå gjennom en etterlevelsesrevisjon og bli hacket samme uke, og det er ingen motsetning i det, fordi to dokumenter svarer på to ulike spørsmål.

Ingen av disse jobbene erstatter de andre, og ingen av dem er «bedre» enn de andre, så det eneste meningsfulle spørsmålet er hvilket av dem som akkurat nå svarer på det du faktisk trenger å vite.

Uklarheten i ordene er ikke knyttet til ett språk, og det ser du når du sammenligner markeder: i Finland, Sverige og Norge selger markedet to jobber — sårbarhetskartlegging og penetrasjonstesting — og mellomvarianten har ikke noe navn; den regnes som et resultat av kartleggingen, ikke som en egen tjeneste. I Tyskland er det motsatt, fordi ett ord der gjerne dekker alle tre jobbene, inkludert selve testen, og nettopp derfor er navnet det svakeste mulige holdepunktet når du sammenligner tilbud, mens det eneste trygge spørsmålet forblir om de sårbarhetene som er funnet, faktisk vil bli utnyttet.

Om loven faktisk krever det av deg

Her er det verdt å være presis, fordi det er her tilbudene oftest overdriver: i Norge er det ingen plikt til penetrasjonstesting ved navn for et vanlig bedriftsnettsted, og det som finnes av navngitte plikter, gjelder ikke hver virksomhet som har et nettsted.

Digitalsikkerhetsloven, som trådte i kraft 1. oktober 2025 og gjennomfører EUs direktiv 2016/1148, pålegger tilbydere av samfunnsviktige tjenester og digitale tjenester å vurdere risiko, iverksette tiltak og varsle om hendelser. Penetrasjonstesting er ikke nevnt ved navn i noen paragraf. Direktiv (EU) 2022/2555, NIS 2, er ennå ikke gjennomført i norsk rett.

Det regelverket som faktisk bruker ordet, er sikkerhetsloven § 6-5 om inntrengingstesting av skjermingsverdige informasjonssystemer, i kraft siden 1. januar 2019. Der kan virksomheten be Nasjonal sikkerhetsmyndighet om å forsøke å trenge inn — det er en mulighet, ikke et pålegg om å kjøpe en kommersiell test, og det gjelder bare systemer som behandler skjermingsverdig informasjon eller har avgjørende betydning for grunnleggende nasjonale funksjoner. Tilsynsmyndigheten kan i andre tilfeller gi pålegg om tiltak, og digitalsikkerhetsforskriften stiller teknologiske krav til tilbydere av samfunnsviktige tjenester, uten å navngi en penetrasjonstest.

Det er to vilkår samtidig, ikke ett: en virksomhet som ikke er tilbyder etter digitalsikkerhetsloven, får ingen plikt derfra, og en virksomhet uten skjermingsverdig system får heller ingen plikt til inntrengingstesting etter sikkerhetsloven, så det første steget er ikke å be om et tilbud, men å vurdere om du i det hele tatt er omfattet.

Hvordan du finner ut om du er omfattet

Digitalsikkerhetsloven lister ikke selskaper ved navn, men beskriver sektorer og terskler, og plikten til å vurdere egen status ligger på virksomheten selv, noe som i praksis betyr to spørsmål: faller aktiviteten din inn under en av sektorene loven nevner, og treffer virksomheten den fastsatte terskelen. Begge må du svare på selv, og svaret skal dokumenteres — nettopp derfor er den første utgiften på dette feltet som regel juridisk rådgivning, ikke en teknisk tjeneste.

Er svaret «nei», treffer ikke digitalsikkerhetsloven deg, men skjermingsverdige systemer hører under sikkerhetsloven og er et eget spørsmål, ikke en underkategori av det å være tilbyder. Er svaret «ja», følger pliktene i digitalsikkerhetsloven uten at det i seg selv utløser inntrengingstesting. Bestemmelsen som navngir inntrengingstesting sitter i sikkerhetsloven og er knyttet til skjermingsverdige informasjonssystemer, ikke til tilbyderstatus; en virksomhet kan være omfattet av den ene loven uten å være det av den andre.

Det finnes også en tredje vei, som ikke krever verken tilbyderstatus eller klassifisert system: tilsynsmyndigheten kan gi pålegg om tiltak som er nødvendige for å ivareta lovens formål. Det er ikke en plikt du kan planlegge etter kalenderen, men det er en grunn til å vite hvem hos deg som ville svart på et slikt pålegg.

De øvrige tersklene navngir testing, ikke penetrasjonstesting

Personvernforordningen artikkel 32 krever en prosess for regelmessig testing, analysering og vurdering av hvor effektive behandlingens tekniske og organisatoriske sikkerhetstiltak er, og omfanget er knyttet til risikoen. Det er ikke det samme som en plikt til å bestille penetrasjonstesting én gang i året, og et tilbud som framstiller artikkel 32 som det, gjenforteller forordningen løsere enn den er skrevet. Plikten til å kunne vise at testing i det hele tatt skjer, er reell; plikten til å velge akkurat denne testformen følger ikke av artikkel 32.

Betalingskortstandarden PCI DSS krav 11.4 navngir penetrasjonstesting direkte, én gang hver tolvte måned og etter vesentlige endringer, men det er en kontraktsfestet plikt og gjelder måten du tar imot kort på. En nettbutikk som sender betalingen helt videre til en betalingsleverandør og selv ikke behandler kortdata, og de øvrige, der kortdata faktisk havner i miljøet, svarer på dette kravet ulikt. Det er et spørsmål kortinnløseren din svarer på, ikke en artikkel.

I finanssektoren krever forordning (EU) 2022/2554, gjennomført i DORA-loven fra 1. juli 2025, jevnlig testing, og trusselbasert penetrasjonstesting (TLPT) er forbeholdt de foretakene tilsynet særskilt har pekt ut. Standarden ISO/IEC 27001 krever sårbarhetshåndtering og sikkerhetstesting, uten å kreve penetrasjonstesting ved navn; påstanden om at sertifisering ikke utstedes uten den, er utbredt og står ikke i standarden.

Gjelder ingen av disse tersklene deg, har du ingen rettslig plikt til å bestille penetrasjonstesting, og det betyr ikke at det ikke er noe å gjøre, men at det som skal gjøres, er noe annet.

Når ingen terskel er overskredet

For en virksomhet som ikke er tilbyder, ikke behandler kortdata og ikke driver i finanssektoren, er det mest meningsfulle arbeidet som regel det som skjer jevnlig, ikke en engangsjobb hvert tredje år. Det er oppdateringer som har en ansvarlig og en frist; sikkerhetskopier som noen faktisk har gjenopprettet og forvisset seg om at de virkelig lar seg gjenopprette; flerfaktorautentisering (MFA) på administratorkontoer, som digitalsikkerhetsforskriften krever som sterk autentisering hos tilbydere av samfunnsviktige tjenester og som er like nyttig for alle andre; og jevnlig sårbarhetskartlegging hvis resultater noen faktisk leser.

Dette er ikke et mindre svar, men en annen type arbeid. De fleste innbruddene vi jobber med, starter ikke med et raffinert angrep, men med en uoppdatert komponent eller et passord som også passet et annet sted, og penetrasjonstesting som skjer hvert tredje år, verner ikke mot det. Har nettstedet ditt allerede vært rammet, er rekkefølgen en annen, og den er beskrevet i en egen artikkel om hvordan du gjenoppretter et hacket nettsted.

Penetrasjonstesting blir begrunnet når det finnes noe å tape, og når tapet er større enn prisen på testen: et system som rommer andres data, en integrasjon som rører ved penger, eller en oppdragsgiver som krever bevis. Fram til det punktet er det riktig jobb i feil rekkefølge.

Hva som skjer under testen

Arbeidet starter med å avklare omfanget og slutter med en rapport, og mellom dem ligger tre faser som er verdt å forstå før du sammenligner tilbud, fordi det nettopp er de som forklarer hvorfor én test koster det den koster, og hvorfor en annen for det samme systemet koster en tiendedel.

Første fase er rekognosering, der testeren samler alt som kan leses om systemet utenfra — hvilke adresser som er offentlige, hvilke teknologier og versjoner som er synlige, hvor innloggingsskjemaene sitter, hvilke filer som er tilgjengelige uten autorisasjon. I denne fasen blir ennå ingenting utnyttet, men det er nettopp her de funnene oftest ligger som ingen hadde ventet: et glemt testmiljø, en åpen kataloglisting, en sikkerhetskopi som ligger under en forutsigbar adresse.

Andre fase er selve undersøkelsen, der automatiske verktøy kjøres for ikke å hoppe over det kjente, men beslutningene tar et menneske, som sjekker om funnet er ekte, forsøker å utnytte det og ser hva det gir. Her oppstår kjeden — tilgang til én konto, derfra tilgang til en funksjon som ikke skulle vært nåbar, derfra tilgang til data. Hvert steg for seg er udramatisk; sammen er de en historie.

Tredje fase er å bevise og skrive ned, fordi hvert funn må etterlate et bevis som kan gjentas: hvilken forespørsel som ble sendt, hva svaret var, hva som endret seg. Uten det er rapporten en mening, og utvikleren som tar imot den, bruker en dag på å skjønne hva testeren egentlig så.

Derfor er også fristene slike som de er: testen av ett lite nettsted er noen dager, mens et system med flere roller, integrasjoner og betalinger er uker, og et tilbud som lover full penetrasjonstesting på én dag, beskriver ikke en test, men sårbarhetskartlegging.

Hvorfor tilbudene skiller seg med en faktor på ti

Når to tilbud på det samme nettstedet skiller seg med en faktor på ti, ligger forskjellen nesten aldri i fortjenestemarginen, og nesten alltid i omfang og metode: det ene tilbyr automatisk sårbarhetskartlegging med et verktøy som startes på en time og hvis rapport det samme verktøyet genererer, mens det andre tilbyr en uke med menneskelig arbeid der verktøyene bare er starten, og nettopp denne forskjellen er det navnet «sikkerhetskontroll» skjuler i begge tilfellene.

Den andre prisfaktoren er systemets kompleksitet, og den kan du vurdere før samtalen starter: ett offentlig nettsted uten brukerkontoer er én jobb, mens et system med flere roller, betalinger, en ekstern integrasjon og data som tilhører kundene, er noe helt annet, fordi hver rolle er en egen grense som skal prøves og hver integrasjon er et sted der to systemer stoler mer på hverandre enn de burde.

Det tredje er det du får etter testen, og hvor lenge utføreren blir værende: en rapport uten prioriteringer, uten bevis og uten ny kontroll koster mindre fordi den er mindre arbeid, og for virksomheten som deretter skal rette funnene, er det nettopp disse tre tingene som avgjør om dokumentet blir en oppgaveliste eller en mappe ingen lenger åpner.

Derfor kan du bare sammenligne tilbud etter pris når omfanget er skrevet likt, og den enkleste måten å få til det på er å skrive omfanget selv og be alle tilby på det, i stedet for å la hver utfører definere sitt eget.

Når testen eldes

Resultatet av en penetrasjonstest beskriver et konkret system på en konkret dato, noe som er innlysende, og likevel er det nettopp her det meste av misforståelsen mellom utfører og oppdragsgiver oppstår, fordi en rapport som er et år gammel, beskriver kode som siden har endret seg titalls ganger.

De kalenderfristene som faktisk finnes, innrømmer det selv: i DORA står minst hvert tredje år for trusselbasert penetrasjonstesting, og tilsynet kan endre hyppigheten, og i betalingskortstandarden står «etter vesentlige endringer» ved siden av tolv-månedersintervallet, slik at kalenderen i begge tilfeller bare er et minimum, mens den egentlige grunnen til å teste er en endring.

I praksis betyr det at en ny grunn til å teste er en endring som flytter angrepsflaten: en ny offentlig funksjon, en ny integrasjon mot et eksternt system, endret autentisering, flytting til et annet webhotell, en ny brukerrolle med videre rettigheter. Et fargeskifte eller en tekstrettelse blir ikke en slik grunn, uansett hvor synlig det er.

Den andre grunnen er at omgivelsene har endret seg, ikke koden din: en sårbarhet i rammeverket du bruker, blir kjent etter testen, og en test som ikke nevnte den, har ikke tatt feil, fordi den den gang ennå ikke fantes. Derfor er jevnlig sårbarhetskartlegging og en oppdateringsprosess det som skjer mellom testene, og testen erstatter det ikke.

Uten eierens tillatelse er de samme handlingene ulovlige

Penetrasjonstesting skiller seg teknisk sett ikke fra et angrep, og det eneste som skiller dem, er et dokument: eierens tillatelse, der omfang, tid og grenser er navngitt, og som det er verdt å sette på papir også når loven ikke krever det direkte. Uten den er de samme handlingene de samme handlingene, og det har rettslige følger.

Praktisk betyr det at tillatelsen gis av den som eier systemet, ikke av den som drifter det. Kjører nettstedet ditt hos et webhotell, må også leverandøren vite at testen skjer, ellers vil vernesystemene hans stoppe den eller sperre kontoen din. Finnes det en tredjepartskomponent i systemet som du ikke styrer, hører den ikke hjemme i omfanget.

Omfangets grenser skal skrives før, ikke etter, og på den listen hører det hjemme hvilke adresser som er i omfanget og hvilke som ikke er det, om vi tester produksjonsmiljøet eller en kopi, hva som skjer hvis testen avbryter tjenesten, og hvem hos deg som er nåbar om natten; den samtalen tar én time og løser det meste av uenighetene som ellers oppstår midt i testen.

Hva testen ikke er: red team, bug bounty og etterlevelseskontroll

Ved siden av penetrasjonstesting finnes det flere jobber som gjerne kalles det samme, og forskjellene mellom dem er ikke akademiske, men praktiske — de avgjør hva du bestiller og hva du får.

Red team-oppdraget prøver ikke systemet, men forsvaret: om menneskene og prosessene dine oppdager angrepet og hva de gjør. Omfanget er videre, varigheten lenger, og en del av verdien ligger nettopp i at forsvarssiden ikke vet at det pågår en øvelse. For en virksomhet som ikke har noe å oppdage, fordi ingen leser logger, er denne jobben for tidlig.

Bug bounty er en modell, ikke en test: du publiserer regler og betaler for funn til dem som sender dem inn. Det kan finne det én tester overså, men det gir verken garanti for omfang, en frist eller en rapport du kan legge ved anskaffelsesdokumentene.

Trusselbasert penetrasjonstesting (TLPT) er en egen, regulert jobb i finanssektoren, og den er definert i EUs forordning, gjennomført i DORA-loven. Er virksomheten din ikke et finansforetak tilsynet har pekt ut, hører dette begrepet ikke hjemme i tilbudet ditt.

Én grense til som gjerne viskes ut, er den mellom «svart boks», «hvit boks» og «grå boks» — hvor mye testeren vet om systemet allerede fra starten. Det er en bransjeavtale, ikke et rettslig krav, og den har direkte virkning på prisen og på hva testen vil finne. En tester uten tilgang etterligner en fremmed; en tester med konto og dokumentasjon når lenger på samme tid. Ingen av variantene er den riktigste; spørsmålet er hva du er redd for.

Hva du får, og hvordan du leser det

Resultatet av testen er en rapport, og verdien ligger i prioriteringene, ikke i antallet funn, fordi en rapport med hundre rader der det ikke står hvilken du skal starte med, er like ubrukelig som en utskrift fra skanneren. En god rapport sier for hvert funn hva en angriper kan gjøre med det, hvor lett det er, og hva som konkret skal endres.

Det andre du bør kreve, er kontroll etter rettelsene, fordi et funn som er rettet, og et funn noen tror er rettet, skiller seg fra hverandre, og den eneste måten å avklare det på er å sjekke på nytt. Vi gjør det innen tretti dager etter rettelsene, og den fristen er det verdt å kreve av enhver utfører.

Det tredje er hva utvikleren din vil gjøre med rapporten. Et funn som er beskrevet med et CVE-nummer og uten kontekst, betyr leting for utvikleren; et funn som har med den konkrete forespørselen og stedet i koden, betyr en rettelse. Utfører én virksomhet utviklingen og en annen testen, er det denne forskjellen som avgjør om rettelsene blir gjort i løpet av en uke eller i løpet av et kvartal.

Det fjerde er det som ikke skal stå i rapporten: påstanden om at systemet nå er sikkert. Testen viser hva det i det konkrete omfanget på den konkrete datoen lyktes å få til. Den beviser ikke at det ikke finnes noe annet, og en utfører som lover det, selger deg trøst.

Det er én grunn til at denne samtalen er verdt å starte tidligere enn det føles nødvendig: en test som skjer uken før systemet settes i drift, finner det samme som den ville funnet tre måneder tidligere, men til å rette funnene er det verken tid eller budsjett igjen, og i praksis ender det med en liste som tas som risiko, ikke med rettelser, derfor er kravet om å teste før et system settes i drift skrevet slik det er i de regelverkene som har et slikt krav, og den samme logikken holder også for dem som ikke er bundet av det.

Og det siste som er verdt å si rett ut: penetrasjonstesting er ikke et bevis på at systemet er sikkert, men et bevis på at en kjent ferdighet på en konkret dato i et konkret omfang ikke fant vei lenger enn til noe konkret, og derfor er den verdifulleste delen av rapporten ofte ikke listen over funn, men beskrivelsen av det som ble forsøkt og ikke lyktes, fordi det nettopp er den delen som sier til neste tester om tre år hvor det ikke er verdt å starte fra null.

Hva du bør forberede før samtalen

For at et tilbud i det hele tatt skal være sammenlignbart, må utføreren kjenne omfanget, så lag en liste over adresser og systemer som hører med, oppgi om vi tester produksjonsmiljøet eller en kopi, si fra om det i systemet finnes noe som ikke må røres, og navngi et menneske som kan tillate at testen stanses.

Produksjonsmiljø eller kopi

Dette er spørsmålet som avgjør både pris og risiko, fordi en test i produksjonsmiljøet viser det som faktisk er tilgjengelig, og nettopp derfor kan den ødelegge noe: overbelaste, fylle databasen med testposter, sende ekte e-post til kunder eller sette seg fast i et vernesystem som blokkerer testeren og deretter også en del av brukerne dine.

En test mot en kopi er tryggere og samtidig ufullstendigere, fordi kopien sjelden er identisk: der mangler det gjerne de reelle integrasjonene, det reelle datavolumet og den reelle konfigurasjonen, og det er nettopp i konfigurasjonen problemet ofte sitter. Velger du en kopi, skriv ned hva den skiller seg fra produksjonsmiljøet med, fordi den listen også er listen over det testen ikke prøvde.

Mellomveien vi bruker oftest: leseoperasjoner i produksjonsmiljøet, skriveoperasjoner og potensielt ødeleggende — mot kopien, med et avtalt vindu på forhånd og et menneske som kan stanse. Det er ikke et kompromiss for prisens skyld, men en måte å få svarene fra begge variantene på uten å avbryte driften.

Den motsatte listen er også nyttig, altså det som ikke er i omfanget, fordi grenser som er tatt for gitt i stillhet, er de det senere strides om. Tredjepartstjenester du ikke selv drifter, hører ikke med, og å teste dem uten disse partenes tillatelse er det samme problemet forrige avsnitt handler om. Bruker nettstedet ditt et eksternt betalingsvindu, et eksternt samtalevindu eller et eksternt analyseverktøy, er det andres eiendom, og et tilbud som lover å «sjekke dem også», lover det som ikke er lov.

Si så hva som skjer med funnene etterpå: hvem som retter dem, innen hvilken frist, og om utføreren sjekker på nytt etter rettelsene. En test uten den avtalen ender ofte med et dokument ingen åpner, og det er den dyreste mulige versjonen: betalt for kunnskap som ikke brukes.

Si også hva du leter etter svar på, fordi «vi må oppfylle et krav» og «vi vil vite om noen kan nå kundedataene» er to ulike jobber med to ulike priser, og en utfører som ikke spør hvilken av dem som er din, vil tilby den som er behageligst for ham.

Er du usikker på hvilken side av terskelen du står på, er det der du bør starte. Den automatiske gjennomgangen svarer som regel på spørsmålet om de kjente svake punktene billigere og raskere enn manuelt ekspertarbeid, og resultatet sier også om penetrasjonstesting er neste steg. Samtalen om omfanget er det verdt å starte med en beskrivelse av prosessen, ikke med en teknologiliste, fordi omfanget avgjøres av det du taper hvis systemet svikter.