Kraftberedskapsforskriften kapittel 6 og 7: tilgangsstyring som tilsynsobjekt

Forskrift om sikkerhet og beredskap i kraftforsyningen (FOR-2012-12-07-1157) er fastsatt av NVE med hjemmel i energiloven §§ 9-1, 9-2, 9-3 og 10-6. Forskriften ble endret i 2026 med ikrafttredelse 1. juli 2026. Endringen gjelder etter det vi har kunnet bringe på det rene § 4-1 om reparasjonsberedskap, altså ikke kapitlene om informasjonssikkerhet og driftskontrollsystem — men det betyr også at enhver henvisning til «gjeldende versjon» i internkontrolldokumentasjonen bør kontrolleres mot Lovdata før den brukes i en tilsynssammenheng.

Denne artikkelen går gjennom de bestemmelsene i kapittel 6 og 7 som treffer identitets- og tilgangsstyring direkte, hva de faktisk krever av dokumentasjon, og hvor de typiske hullene ligger i en Microsoft-basert IT-plattform.

§ 6-2: kraftsensitiv informasjon er en tilgangsstyringskategori, ikke en dokumentmerking

Forskriften § 6-2 definerer kraftsensitiv informasjon som underlagt taushetsplikt etter energiloven § 9-3: «konkrete og detaljerte opplysninger om kraftforsyningen, herunder klassifiserte anlegg og system, som kan utnyttes til å skade kraftforsyningen». Definisjonen har en punktliste som blant annet omfatter opplysninger om driftskontrollsystemet, kartfesting av kabeltraseer, sårbarhetsbeskrivelser og beredskapsplaner.

Den praktiske konsekvensen blir ofte oversett: kraftsensitiv informasjon ligger sjelden bare i et dokumentarkiv. Den ligger i SharePoint-områder, i Teams-kanaler, i postkasser, i delte OneDrive-mapper, i vedlegg i saksbehandlingssystemer. Tilgangen til alt dette styres av gruppemedlemskap i Entra ID.

Det betyr at spørsmålet «hvem har tilgang til kraftsensitiv informasjon» i praksis er spørsmålet «hvem er medlem av disse gruppene, og hvordan ble de det». Hvis svaret på siste del er «det vet vi ikke», har virksomheten et § 6-3-problem.

§ 6-3: kravet som ikke lar seg oppfylle med en policy alene

Ordlyden i § 6-3 er kort og konkret: «Virksomheter som har eller behandler kraftsensitiv informasjon skal etablere, opprettholde og videreutvikle system og rutiner for effektiv avskjerming, beskyttelse og tilgangskontroll for kraftsensitiv informasjon.»

Tre ord fortjener oppmerksomhet.

«System og rutiner». Ikke enten-eller. Rutine alene er ikke tilstrekkelig — det skal finnes et system. Dette speiler NSMs grunnprinsipp 2.6.3, som eksplisitt ber om «et sentralisert og automatiserbart verktøy for å styre kontoer, tilganger og rettigheter».

«Effektiv». Kravet er ikke at det finnes en prosess, men at avskjermingen faktisk virker. En prosess som forutsetter at en person husker å fjerne et gruppemedlemskap når noen bytter rolle, er ikke effektiv i forskriftens forstand når den etterprøves mot faktiske data.

«Videreutvikle». Statisk etterlevelse er ikke nok. Det forventes at ordningen forbedres over tid, hvilket innebærer at man må kunne måle hvordan den fungerer.

§ 6-7: personkontroll — og leverandørene

§ 6-7 pålegger KBO-enheter å gjennomføre bakgrunnssjekk av personer før ansettelse, og gir hjemmel til å kreve kredittsjekk for personer som skal få tilgang til anlegg, system eller annet i klasse 2 og 3. Personer som er sikkerhetsklarert og autorisert etter sikkerhetsloven, er unntatt.

Bestemmelsen leses ofte som en HR-bestemmelse. Den er også en IT-bestemmelse, av en enkel grunn: kontroll på hvem som er kontrollert, forutsetter kontroll på hvem som har tilgang. En virksomhet som ikke kan produsere en presis liste over hvilke identiteter — inkludert gjestekontoer, konsulentkontoer og tjenestekontoer — som har tilgang til systemer i klasse 2 og 3, kan heller ikke dokumentere at personkontrollkravet er oppfylt for alle disse.

Erfaringsmessig er det gjestekontoene som feiler her. En B2B-gjest invitert av en prosjektleder i 2023, som fortsatt er medlem av en Teams-kanal der det ligger sårbarhetsvurderinger, er både et § 6-3- og et § 6-7-problem — og ingen i organisasjonen vet at kontoen finnes.

§ 7-4: kontroll med brukertilgang, med årlig gjennomgang

Kapittel 7 gjelder beskyttelse av driftskontrollsystemet. § 7-4 lyder: «Virksomheter skal kontrollere at kun rettmessige brukere har tilgang til driftskontrollsystemet. For dette skal det være kontrollordninger for tildeling, endring og sletting av brukertilgang… Kontrollordningene skal gjennomgås minimum årlig.»

To presiseringer er viktige for å bruke denne bestemmelsen riktig i en IT-diskusjon.

For det første gjelder § 7-4 driftskontrollsystemet. Et driftskontrollsystem er normalt ikke integrert med Entra ID, og skal som hovedregel ikke være det. Det er ikke slik at en Entra-basert løsning «oppfyller § 7-4».

For det andre er koblingen likevel reell og operativ. Personene som har brukertilgang i driftskontrollsystemet, er ansatte og innleide med identiteter i Entra ID. Når en av dem slutter, er den kritiske spørsmålet ikke bare om AD-kontoen deaktiveres, men om det finnes en prosess som utløser fjerning av tilgangen i driftskontrollsystemet også. I de fleste virksomheter er den koblingen en manuell sjekkliste eller en e-post.

Det er her identitetsstyring på IT-siden faktisk bidrar til § 7-4-etterlevelse: ikke ved å styre driftskontrollsystemet, men ved å levere det autoritative signalet — «denne personen er ute» — i en strukturert, sporbar form som kan utløse handling i alle nedstrøms systemer, og ved å produsere det datagrunnlaget den årlige gjennomgangen faktisk trenger.

§ 7-10 og § 7-7: ekstern tilkobling og hendelsesregistrering

§ 7-10 om ekstern tilkobling krever at kun godkjente brukere gis tilgang, at det finnes en oppdatert liste over godkjente brukere, og at tilkoblingen følger en forhåndsavtalt prosedyre. «Oppdatert liste over godkjente brukere» er en presis dokumentasjonsplikt — og den er nettopp den typen artefakt som råtner mellom revisjoner når den vedlikeholdes manuelt i et regneark.

§ 7-7 om håndtering av feil, sårbarheter og sikkerhetsbrudd pålegger registrering av alle sikkerhetsbrudd og sikkerhetshendelser, med varslings- og rapporteringsplikt til beredskapsmyndigheten ved umiddelbar risiko for driftskontrollsystemets funksjon.

Her er sammenhengen med identitetsstyring direkte: en betydelig andel av det som registreres som sikkerhetshendelser i praksis, er hendelser knyttet til kontoer og tilganger — mislykkede innloggingsforsøk, uventede rettighetsendringer, kontoer som brukes fra uventede lokasjoner. Kvaliteten på hendelsesregistreringen avhenger av om det finnes en referansetilstand å måle avvik mot.

Hva et tilsyn faktisk ber om

Basert på hvordan bestemmelsene er formulert, er dette dokumentasjonen som må kunne legges fram:

• Oversikt over hvilke systemer og informasjonsmengder som er klassifisert, og hvem som har tilgang til hver av dem — per i dag, ikke per siste opptelling.
• Beskrivelse av kontrollordningene for tildeling, endring og sletting av brukertilgang, og bevis for at de faktisk følges.
• Protokoll fra siste årlige gjennomgang av kontrollordningene.
• Oppdatert liste over godkjente brukere for ekstern tilkobling.
• Dokumentasjon på gjennomført personkontroll for personell med tilgang til klasse 2 og 3, inkludert innleide.
• Register over sikkerhetshendelser med håndtering.

Legg merke til at fem av seks punkter handler om å kunne vise en nåtilstand og en historikk. Det er en datatilgjengelighetsutfordring, ikke en policyutfordring.

Hvor Entra Logic bidrar — og hvor det ikke gjør det

Bidrar: En kontinuerlig synkronisert, søkbar kopi av Entra-boet gjør nåtilstanden tilgjengelig uten eksportjobber. Ordremodellen gjør at hver endring i tilgang bærer med seg begrunnelse, godkjenner og utførelsesresultat i samme post, slik at «kontrollordninger for tildeling, endring og sletting» ikke er et dokument som beskriver noe, men et system som gjør det. Kontinuerlige opprydningssjekker løfter fram foreldreløse enheter, ueide Autopilot-registreringer og uklassifiserte poster som en kort arbeidsliste, i stedet for som en etterslepsbunke som først oppdages i forkant av tilsynet.

Bidrar ikke: Entra Logic styrer ikke driftskontrollsystemet, og har ingen funksjon i OT-miljøet. Det gjennomfører ikke personkontroll — det viser bare hvem kontrollen skulle vært gjennomført for. Og det utfører ikke attestering eller rekertifisering av tilganger; den årlige gjennomgangen etter § 7-4 er fortsatt en aktivitet virksomheten selv må gjennomføre, med de dataene systemet leverer.

Den ærlige formuleringen er at Entra Logic flytter en betydelig del av tilsynsforberedelsen fra prosjektarbeid til uttrekk. Det er en reell gevinst, men det er ikke det samme som at forskriften er oppfylt.

Kilder

• Kraftberedskapsforskriften (FOR-2012-12-07-1157), §§ 6-2, 6-3, 6-7, 7-4, 7-6, 7-7, 7-10 (siste endring i kraft 01.07.2026 gjelder § 4-1) — https://lovdata.no/dokument/SF/forskrift/2012-12-07-1157
• Energiloven (LOV-1990-06-29-50) kapittel 9, §§ 9-1 til 9-3 — https://lovdata.no/dokument/NL/lov/1990-06-29-50/KAPITTEL_5
• NSM, Grunnprinsipper for IKT-sikkerhet v2.1, prinsipp 2.6 — https://nsm.no/getfile.php/1313975-1717589722/NSM/Filer/Dokumenter/Veiledere/NSMs%20Grunnprinsipper%20for%20IKT-sikkerhet%20v2.1.pdf
• KraftCERT/InfraCERT, sektorvist responsmiljø for kraftsektoren — https://www.kraftcert.no/no/