Gå til innhold
Legiscope
Meny
Personvern

Grunnleggende IT-sikkerhet: prioriter tiltak etter faktiske svakheter

Prioritert sikkerhetsplan. Praktisk veiledning med avgrensninger, arbeidssteg og dokumentasjon for norske virksomheter.

Også tilgjengelig på:Italiano·Português·Svenska·Lietuvių·Dansk·Suomi

Grunnleggende IT-sikkerhet bør begynne med svakhetene som kan gi størst skade i virksomhetens faktiske drift. Et lite team trenger en tydelig prioritering av tilganger, oppdateringer, sikkerhetskopier og hendelseshåndtering. En lang liste med anbefalinger er mindre nyttig dersom ingen vet hvilke tiltak som skal gjennomføres først eller hvordan resultatet kontrolleres.

Når viktige grunnkontroller er på plass, vurder om en avgrenset penetrasjonstest er en egnet måte å undersøke gjenværende svakheter på. Avtal omfang og oppfølging ut fra risikoen.

NSMs grunnprinsipper for IKT-sikkerhet gir et norsk faglig utgangspunkt, men må tilpasses den enkelte virksomheten. De er ikke en garanti mot angrep eller en generell bekreftelse på at alle lovkrav er oppfylt. For behandling av personopplysninger krever artikkel 32 i GDPR et egnet sikkerhetsnivå vurdert mot risikoen. Denne veiledningen viser hvordan dere kan gjøre anbefalinger om til en gjennomførbar arbeidsplan.

Finn det dere ikke kan miste eller være uten

Be fagansvarlige beskrive hvilke tjenester og opplysninger som har størst betydning. Spør hva som skjer hvis opplysningene blir utilgjengelige, feil eller kjent for uvedkommende. Disse konsekvensene kan være forskjellige for samme system. Et kunderegister kan være viktig for drift og samtidig inneholde informasjon som krever begrenset tilgang.

Bruk systemoversikten til å identifisere eier, leverandør og avhengigheter. Ta med tjenester kjøpt av fagavdelinger og arbeidskopier utenfor hovedsystemet. En prioritert plan som bare dekker maskiner administrert av IT, kan overse en skytjeneste med omfattende kundedata og svakt kontooppsett.

Avklar hvem som kan beslutte og gjennomføre

Gi hvert tiltak en faglig eier og en utførende rolle. En ekstern IT-leverandør kan gjennomføre oppdatering eller konfigurere innlogging, men virksomheten må fortsatt bestemme hvilke tjenester som er viktige og hvilke avbrudd som kan aksepteres. Avklar også hvem som kan stanse en usikker arbeidsmåte mens en varig løsning etableres.

Knytt ansvar til informasjonssikkerhetspolicyen. I en liten organisasjon kan én person ha flere roller, men det må være tydelig når vedkommende handler som systemeier og når tekniske oppgaver utføres. Dokumenter stedfortreder for viktige beslutninger. Sikkerhetsarbeidet bør ikke stoppe fordi én person er utilgjengelig.

Undersøk tilganger før dere kjøper flere verktøy

Finn administratorer, gamle brukere, delte kontoer og tilganger for leverandører. Kontroller om de fortsatt er nødvendige og om noen mangler eier. En konto med brede rettigheter kan være en større svakhet enn mangel på et nytt analyseverktøy. Start med tilganger som gir kontroll over identitet, sikkerhetskopier eller store mengder personopplysninger.

Følg passordpolicyen og autentiseringsarbeidet. Undersøk hvordan kontogjenoppretting skjer, ikke bare hvordan vanlig innlogging fungerer. Kontroller også tjenestekontoer og integrasjonsnøkler. En tidligere konsulent kan ha mistet sin personlige konto samtidig som en delt nøkkel fortsatt gir tilgang til systemet.

Få kontroll på oppdateringer og støttet programvare

Lag en oversikt over systemer som trenger sikkerhetsoppdatering, og hvem som har ansvaret. Avklar hvor dere får informasjon om alvorlige svakheter og hvordan hasteendringer håndteres. Skill mellom maskiner som er oppdatert, maskiner som venter på omstart og enheter som ikke har vært tilgjengelige for kontroll.

For eldre systemer bør planen beskrive hvorfor de fortsatt brukes og hvilke begrensninger som reduserer eksponeringen. En planlagt utskifting langt frem i tid er ikke alene et tiltak mot dagens risiko. Vurder midlertidig tilgangsbegrensning, redusert funksjonalitet eller andre praktiske alternativer mens en varig løsning gjennomføres.

Kontroller at sikkerhetskopier kan brukes

Spør hvilke data, konfigurasjoner og systemer som faktisk omfattes. Kontroller hvor kopiene ligger og hvem som kan slette eller endre dem. Hvis samme kompromitterte konto kan ødelegge både produksjon og alle sikkerhetskopier, er gjenopprettingsmuligheten svakere enn en grønn rapport om vellykket kopiering kan gi inntrykk av.

Gjennomfør en avgrenset gjenoppretting og la fagansvarlig bekrefte at resultatet kan brukes. Bruk gjenopprettingsplanen til å beskrive rekkefølge og mål. Kontrollen bør omfatte nødvendige vedlegg og sammenhenger mellom opplysninger. At en fil kan åpnes, viser ikke alltid at tjenesten kan fortsette.

Prioriter nettverk og sikre grunnoppsett

Kartlegg tjenester som er tilgjengelige utenfra og administrasjonsgrensesnitt som bør være begrenset. Vurder om maskiner og tjenester har funksjoner de ikke trenger. Et kontrollert normaloppsett gjør det lettere å finne avvik og reduserer vedlikeholdsarbeidet. Se herding av Windows og Linux for en metode som skiller maskinroller og dokumenterte unntak.

Endringer må prøves i et egnet omfang før de påvirker kritisk drift. Avklar tilbakeføring og hvem som følger opp resultatet. En anbefaling som gjennomføres uten forståelse av avhengigheter, kan skape et avbrudd virksomheten ikke er forberedt på. Sikkerhetstiltaket bør derfor knyttes til både teknisk kontroll og faglig funksjon.

Arbeidsark for prioriterte tiltak

Felt Spørsmål som gir en gjennomførbar oppgave
Svakhet Hva er observert, og hvilket system gjelder det?
Konsekvens Hvem eller hvilken tjeneste kan bli rammet?
Tiltak Hva skal faktisk endres?
Eier Hvem bestemmer og følger opp?
Utføring Hvem gjør arbeidet og hvilke avhengigheter finnes?
Kontroll Hvordan bekreftes at svakheten er redusert?
Frist Når må tiltaket være på plass ut fra risikoen?
Restrisiko Hva står fortsatt igjen etter gjennomføring?

Et tiltak bør være konkret nok til at en annen person kan forstå når det er ferdig. «Bedre sikkerhetskopi» gir lite styring. «Demonstrere gjenoppretting av kundesystemets database og vedlegg i et kontrollert miljø» beskriver en observerbar leveranse. Fristen må begrunnes av risiko og praktiske avhengigheter, ikke automatisk være lik for alle funn.

Bygg en enkel evne til å oppdage hendelser

Velg noen få hendelser dere trenger å fange opp, for eksempel uventede administrative endringer eller bortfall av sikkerhetskopiering. Bestem hvem som mottar varselet og hva vedkommende gjør først. En samling logger er ikke tilstrekkelig hvis ingen har ansvar for oppfølging.

Bruk rutinen for sikkerhetslogger til å avklare innhold, tilgang og oppbevaring. Kontroller at relevante kilder faktisk leverer hendelser. En tjeneste kan fortsette å fungere selv om logginnsamlingen stopper. Dokumenter også hvordan vakthold og leverandørkontakt fungerer utenfor vanlig arbeidstid dersom risikovurderingen tilsier at dette er nødvendig.

Gi ansatte korte og brukbare instrukser

Ansatte trenger å vite hvordan de melder fra om mistenkelig e-post, feil mottaker, mistet utstyr og uventede innlogginger. Forklar hvilke opplysninger de skal gi og hvilken kanal som brukes hvis kontoen er sperret. Unngå å gjøre varsling avhengig av at den ansatte først klassifiserer hendelsen juridisk eller teknisk.

Bruk praktiske situasjoner i opplæringen. En ansatt som godkjente en uventet innloggingsforespørsel, bør raskt kunne få hjelp uten å skjule feilen. Erfaringene kan brukes til å forbedre systemet og instruksene. Bevar detaljer om enkelthendelser begrenset, slik at læring ikke blir en unødvendig deling av opplysninger om ansatte.

Hypotetisk eksempel: et lite firma velger tre første tiltak

En tenkt virksomhet med ekstern IT-drift finner tre tydelige svakheter: to gamle administratorkontoer, manglende kontroll av gjenoppretting og en skytjeneste uten registrert eier. Den prioriterer å avklare kontoene, demonstrere tilbakeføring av den viktigste tjenesten og kartlegge skytilgangen. Tiltakene velges fordi de reduserer konkrete usikkerheter.

Gjennomgangen av skytjenesten avdekker også en automatisk eksport til en tidligere samarbeidspartner. Denne håndteres som en egen sak. Virksomheten oppdaterer planen og registrerer hva som faktisk er endret. Eksemplet viser hvorfor en innledende kontroll kan gi større nytte enn å starte med en bred anskaffelse av sikkerhetsverktøy uten oversikt over eksisterende bruk.

Samarbeid med leverandøren om bevis

Be leverandøren beskrive hvilke oppgaver som inngår i tjenesten og hvilke kunden må utføre selv. Skill mellom at en funksjon tilbys, at den er aktivert og at resultatet er kontrollert. En rapport om «beskyttede enheter» trenger et kjent omfang for å være nyttig. Undersøk om alle relevante maskiner faktisk er med.

Avtal hvordan åpne funn følges opp og hvilke endringer som varsles. Bruk presise oppgaver fremfor generelle krav om høy sikkerhet. Hvis leverandøren ikke kan utføre et nødvendig tiltak, må virksomheten vurdere alternativ håndtering. Et kontraktsmessig ansvarsforhold erstatter ikke behovet for å kjenne den faktiske tilstanden.

Følg fremdrift gjennom redusert svakhet

Gjennomgå planen med jevne mellomrom og ved vesentlige endringer. Skill planlagte, utførte og kontrollerte tiltak. Et lukket arbeidspunkt bør vise hvilket resultat som ble bekreftet og hvilke begrensninger kontrollen hadde. Bevar åpne restproblemer synlig slik at de ikke forsvinner bak en samlet grønn status.

Resultatet bør være en håndterbar sikkerhetsplan som bygger på faktisk bruk, tydelige eiere og kontroll av gjennomføring. Når de første svakhetene er redusert, brukes erfaringene til å prioritere neste runde. Slik utvikles sikkerhetsarbeidet som en løpende del av driften med dokumenterte forbedringer.

L
Skrevet av
Legiscope
Legiscope

Sett veiledningen ut i praksis

Se hvordan Legiscope kobler personvernregistre, kildemateriale og kontrollert arbeid.

Bestill en tilpasset demo
Les videre

Relaterte artikler

01Personvern

AI Act-programvare 2026: verktøy for etterlevelse av KI-forordningen

AI Act-programvare kan organisere oversikt, vurderinger og dokumentasjon av KI-systemer. For en norsk virksomhet må valg av verktøy bygge på konkrete roller og bruksområder, samtidig som EU-frister…

4. juli 2026
02Personvern

Anonymisering: vurder om opplysninger fortsatt kan knyttes til personer

Anonymisering skal gjøre det slik at opplysninger ikke lenger kan knyttes til en identifiserbar person med midler som med rimelighet kan tenkes brukt. Å fjerne navn er ofte utilstrekkelig. Datoer,…

8. september 2026
03Personvern

Ansvarlighet i personvernarbeidet: dokumenter at tiltak virker

Ansvarlighet i personvernarbeidet betyr at virksomheten både skal følge reglene og kunne vise hvordan den gjør det. Dokumentasjonen bør knytte et konkret formål og en beslutning til faktisk…

8. september 2026
04Personvern

Arbeidsgivers innsyn i e-post: beslutning, varsel og protokoll

Før en arbeidsgiver åpner en ansatts e-postkasse, bør virksomheten kunne vise hvorfor innsyn er nødvendig, hvilke mindre inngripende alternativer som er vurdert, og hvordan den ansattes rettigheter…

8. september 2026
05Personvern

Artikkel 14: informer når opplysninger kommer fra andre

Når virksomheten får personopplysninger fra en samarbeidspartner, et offentlig register eller en kjøpt kontaktliste, har personen vanligvis ikke sett innsamlingsskjemaet deres. Informasjonsplikten…

8. september 2026
06Personvern

Automatiserte avgjørelser: identifiser terskelen i artikkel 22

Artikkel 22 i GDPR oppstiller som utgangspunkt et forbud mot visse automatiserte avgjørelser. Virksomheten må identifisere en avgjørelse, undersøke om den utelukkende bygger på automatisert…

8. september 2026
07Personvern

Avslutte databehandler: tilbakelevering og slettebekreftelse

Når en databehandleravtale avsluttes, må virksomheten vite hvor personopplysningene ender. Oppsigelse av abonnementet er ikke det samme som tilbakelevering eller sletting. En konto kan være stengt…

8. september 2026
08Personvern

Avvik og brudd på personopplysningssikkerheten (art. 33-34): 72-timersfristen 2026

Et brudd på personopplysningssikkerheten skal meldes til Datatilsynet uten ugrunnet opphold og senest innen 72 timer etter at den behandlingsansvarlige ble kjent med bruddet, med mindre bruddet…

4. juli 2026