En informasjonssikkerhetspolicy skal gjøre det klart hvem som bestemmer sikkerhetsnivået, hvilke regler som gjelder og hvordan virksomheten oppdager at reglene ikke følges. Den må kunne brukes når noen bestiller en tjeneste, gir en kollega tilgang eller velger mellom rask gjenoppretting og grundigere kontroll etter et angrep. Et dokument med generelle ambisjoner gir lite hjelp i disse situasjonene.
Denne veiledningen tar utgangspunkt i behovet for en praktisk policy i en norsk virksomhet. NSMs grunnprinsipper kan støtte valg av tiltak, men er ikke en sertifisering eller en generell erklæring om at alle rettslige krav er oppfylt. GDPR artikkel 32 krever et sikkerhetsnivå tilpasset risikoen. Kravet gjelder innenfor forordningens virkeområde; egne sektorregler og avtaler må vurderes separat. Se NSMs introduksjon og forordningen.
Start med beslutningene policyen skal styre
Skriv først ned tre til fem gjentakende beslutninger som skaper usikkerhet. Det kan være om en ny skytjeneste kan tas i bruk, hvem som kan eksportere kundedata, eller hvor raskt en kritisk sårbarhet skal håndteres. Bruk konkrete situasjoner fra driften uten å kopiere personopplysninger inn i arbeidsdokumentet. En policy bør redusere slik usikkerhet gjennom ansvar, prinsipper og henvisninger til gjennomførbare rutiner.
Skill policyen fra detaljert systemdokumentasjon. Ledelsen trenger å vedta prinsippet om at tilganger gis etter tjenstlig behov. IT trenger en separat rutine som forklarer hvordan dette utføres i hvert system. Hvis alle skjermbilder og innstillinger legges i policyen, blir dokumentet fort foreldet og tungvint å endre. Hvis policyen bare sier at sikkerhet er viktig, blir forbindelsen til handling for svak.
Et IT-reglement for ansatte kan oversette prinsippene til konkrete valg om deling, lagring og rapportering av feil i arbeidsdagen.
Avgrens informasjon, tjenester og mennesker
Angi hvilke virksomhetsdeler, informasjonstyper og arbeidsformer som omfattes. Ta med hjemmekontor, mobile enheter, leverandørtilgang og systemer som fagavdelinger kjøper direkte. Et felles dokument kan gjelde hele organisasjonen, men forskjeller i risiko bør komme frem. Lønnssystemet og en offentlig nettside trenger ikke identiske tilgangsregler eller samme gjenopprettingsmål.
En systemoversikt med eiere og avhengigheter gir grunnlag for denne avgrensningen. Beskriv også informasjon som ligger utenfor hovedsystemene: rapporteksporter, regneark, e-postvedlegg og lokale arbeidskopier. Det er ofte her regler om tilgang og sletting blir uklare. Eier skal identifiseres etter faktisk ansvar, ikke automatisk settes til IT fordi informasjonen er digital.
Fordel myndighet slik at beslutninger kan tas
Ledelsen fastsetter mål, prioriteringer og akseptabel restrisiko innenfor lovens rammer. Systemeier skal kjenne tjenestens betydning og godkjenne nødvendige tilganger. Teknisk drift gjennomfører konfigurasjon, oppdateringer og overvåking. Fagansvarlig vurderer om kontrollene støtter arbeidsprosessen. Personvernombudet, der virksomheten har et, gir råd og kontrollerer etterlevelse uten å overta ledelsens beslutningsansvar.
Beskriv hvem som kan stanse en behandling eller koble fra en tjeneste ved en hendelse. Angi stedfortreder og hvordan beslutningen dokumenteres hvis vanlig kommunikasjon er utilgjengelig. En ansvarstabell med fem navngitte roller er mer nyttig enn mange komiteer uten tydelig myndighet. Still samtidig krav om at ansvar overføres når personer slutter eller organisasjonen endres.
Arbeidsmal for policyens kjerne
| Del | Beslutning som må fremgå |
|---|---|
| Formål | Hvilke verdier og tjenester policyen skal beskytte |
| Omfang | Virksomhetsdeler, ansatte, leverandører og arbeidsformer |
| Klassifisering | Hvem som bestemmer beskyttelsesbehovet |
| Tilgang | Godkjenning, kontroll og avslutning av rettigheter |
| Endring | Hvordan nye systemer og vesentlige endringer vurderes |
| Hendelser | Varslingskanal, myndighet og samarbeid |
| Kontinuitet | Prioritering av tjenester ved driftsstans |
| Unntak | Begrunnelse, kompenserende tiltak og utløpsdato |
| Oppfølging | Hvilke bevis ledelsen mottar og hvem som vurderer dem |
Fyll ut tabellen med egen virksomhets språk. Formuleringen «tilgang skal godkjennes av systemeier før opprettelse» kan kontrolleres. Formuleringen «vi bruker høy sikkerhet» mangler både utførende rolle og observerbart resultat. Unngå absolutte løfter som organisasjonen ikke kan dokumentere, for eksempel at alle hendelser alltid oppdages umiddelbart.
Knytt prinsippene til gjennomførbare rutiner
Tilgangskapitlet bør vise til passordpolicy og autentisering, men også dekke godkjenning av roller og tjenestekontoer. En sterk innlogging hjelper lite hvis brukeren har unødvendig administratorrettighet. For hver hovedregel bør den ansvarlige kunne finne rutinen, kjenne sin oppgave og se hvordan gjennomføringen registreres.
Hendelseskapitlet må ha en forbindelse til sikkerhetslogger. Bestem hva virksomheten trenger å oppdage, hvem som undersøker varselet og hvem som kan få innsyn i loggene. Ikke gjør sikkerhetsovervåking til en generell tillatelse til å kontrollere ansattes produktivitet. Nye formål krever egen vurdering og kan utløse arbeidsrettslige spørsmål.
Behandle unntak uten å gjøre dem permanente
Et eldre fagsystem kan mangle en ønsket sikkerhetsfunksjon. Registrer begrensningen, berørte opplysninger, risiko og midlertidige tiltak. Beskriv hvorfor systemet fortsatt trengs, hvilke alternativer som er vurdert og når beslutningen skal tas opp igjen. Eier må godkjenne den faktiske risikoen med tilstrekkelig myndighet. Et skjema er ingen dispensasjon fra lovkrav.
Sett et sluttpunkt som kan kontrolleres: oppgradering, utfasing eller ny vurdering etter en konkret hendelse. Hvis unntaket fornyes, må begrunnelsen oppdateres. At samme formulering har stått der i flere år, viser ikke at risikoen er uendret. Ledelsen bør kunne se samlet belastning fra mange små unntak som rammer samme tjeneste.
Hypotetisk eksempel: kundestøtte kjøper en ny tjeneste
En tenkt virksomhet ønsker å samle kundesamtaler i en ny plattform. Policyen krever at fagansvarlig beskriver opplysningene og formålet, at systemeier godkjenner tilganger, og at innkjøp avklarer leverandørrollen. Teknisk drift undersøker autentisering og eksport. Personvernressursen vurderer informasjon til kunder og eventuelle overføringer. Ingen av disse oppgavene kan erstattes av leverandørens generelle sikkerhetspresentasjon.
Under gjennomgangen viser det seg at standardinnstillingen gir alle brukere tilgang til alle samtaler. Før oppstart endres rolleoppsettet og et begrenset utvalg kontrolleres. Behovet for videre lagring av lyd vurderes særskilt. Saken dokumenterer dermed at policyen påvirket en reell beslutning. Den er mer verdifull som kontrollbevis enn en signert erklæring om at alle ansatte har lest dokumentet.
Øv på avbrudd og mål faktisk gjennomføring
Bruk kontinuitetsplanen til å øve på situasjoner der vanlige verktøy ikke virker. Finn ut hvordan ledelsen kommuniserer, hvor kontaktlisten finnes og hvilke oppgaver som prioriteres. En øvelse bør avsluttes med konkrete forbedringer: manglende stedfortreder, utdatert kontaktinformasjon eller en avhengighet ingen hadde tatt med.
Velg noen få mål som sier noe om gjennomføring. Eksempler er andelen kritiske systemer med kontrollert eier, antall utløpte unntak og om gjenoppretting faktisk er demonstrert. Antall produserte dokumenter er mindre relevant. Resultatene bør forklares med omfang og begrensninger, slik at en god prosent ikke skjuler et lite undersøkt utvalg.
Vedta og vedlikehold dokumentet
La dem som skal følge policyen prøve den på konkrete saker før vedtak. Kontroller at en nyansatt finner riktig kontakt, at systemeier forstår godkjenningsoppgaven og at en leverandørhenvendelse kan håndteres. Rett uklare formuleringer mens dokumentet fortsatt er lett å endre. Vedtaket bør angi eier, versjon og hvordan nye regler blir kommunisert.
Revider ved vesentlige endringer og etter erfaringer som viser at reglene ikke fungerer. En planlagt gjennomgang er også nyttig, men datoen alene dokumenterer ingen forbedring. Samle beslutninger og kontrollresultater i et bevisregister for ansvarlighet. Da kan neste gjennomgang bygge på observerte problemer og effekt av tidligere tiltak.
Kontroller at policyen også fungerer hos leverandører
Når driften er satt ut, må dokumentet forklare hvilke oppgaver leverandøren utfører og hvilke beslutninger virksomheten beholder. En leverandør kan følge sin egen sikkerhetspolicy uten at den dekker kundens prioriteringer. Avklar derfor hvordan varsler mottas, hvem som godkjenner endringer, og hvilke rapporter som viser at avtalte tiltak er utført. Skill mellom leverandørens generelle beskrivelse og bevis som faktisk gjelder den kjøpte tjenesten.
Be om et gjennomgått eksempel på en relevant hendelse eller endring, med personopplysninger og konfidensielle detaljer fjernet. Undersøk om varslingskjeden og ansvaret stemmer med deres egen policy. Hvis leverandøren bruker et annet begrep for kritisk hendelse, må forskjellen avklares før den får betydning i en krise. Dokumenter også hvem som holder kontaktlisten oppdatert når avtalen fornyes eller kontaktpersoner byttes.
Gi ansatte en praktisk inngang
En kort introduksjon kan forklare hvor ansatte melder fra, hvordan de får godkjent en ny tjeneste, og hva de gjør hvis en enhet forsvinner. Den skal vise til gjeldende policy og rutiner. La ansatte stille spørsmål om situasjoner de faktisk møter; uklare svar avdekker ofte en regel som trenger presisering. Registrer at opplæringen er gjennomført, men vurder forståelsen gjennom enkle arbeidssituasjoner fremfor bare å telle klikk på et kurs.