The Power Supply Preparedness Regulations chapters 6 and 7: access governance as a supervisory subject

The Regulations have just been amended, and most people haven't reread them

The Power Supply Preparedness Regulations (kraftberedskapsforskriften, FOR-2012-12-07-1157) are issued by the Norwegian Water Resources and Energy Directorate (NVE) pursuant to the Energy Act (energiloven) §§ 9-1, 9-2, 9-3 and 10-6. The Regulations were amended in 2026, entering into force on 1 July 2026. As far as we have been able to establish, the amendment concerns § 4-1 on repair preparedness, not the chapters on information security and operational control systems — but that also means any reference to the "current version" in internal-control documentation should be checked against Lovdata before it's used in a supervisory context.

This article goes through the provisions in chapters 6 and 7 that bear directly on identity and access governance, what they actually require by way of documentation, and where the typical gaps lie in a Microsoft-based IT platform.

§ 6-2: power-sensitive information is an access-governance category, not a document label

§ 6-2 of the Preparedness Regulations defines power-sensitive information as subject to the duty of confidentiality under § 9-3 of the Energy Act: "specific and detailed information about the power supply, including classified facilities and systems, that could be exploited to damage the power supply" (author's translation from the Norwegian). The definition includes a list of items covering, among other things, information about the operational control system, the mapping of cable routes, vulnerability descriptions and preparedness plans.

The practical consequence is often overlooked: power-sensitive information rarely sits only in a document archive. It lives in SharePoint sites, in Teams channels, in mailboxes, in shared OneDrive folders, in attachments in case-management systems. Access to all of this is governed by group membership in Entra ID.

That means the question "who has access to power-sensitive information" is, in practice, the question "who is a member of these groups, and how did they become one". If the answer to the second part is "we don't know", the organisation has a § 6-3 problem.

§ 6-3: the requirement a policy alone cannot satisfy

The wording of § 6-3 is short and specific: "Undertakings that hold or process power-sensitive information shall establish, maintain and further develop systems and routines for the effective segregation, protection and access control of power-sensitive information" (Norwegian original: "Virksomheter som har eller behandler kraftsensitiv informasjon skal etablere, opprettholde og videreutvikle system og rutiner for effektiv avskjerming, beskyttelse og tilgangskontroll for kraftsensitiv informasjon.").

Three words deserve attention.

"Systems and routines." Not either/or. A routine alone is not sufficient — there must be a system. This mirrors the Norwegian National Security Authority's (NSM) Basic Principle 2.6.3, which explicitly calls for "a centralised and automatable tool for managing accounts, access and privileges".

"Effective." The requirement is not that a process exists, but that the segregation actually works. A process that depends on someone remembering to remove a group membership when a person changes role is not effective in the sense of the Regulations once it's tested against actual data.

"Further develop." Static compliance is not enough. The arrangement is expected to improve over time, which means it must be possible to measure how it's performing.

§ 6-7: personnel screening — and the suppliers

§ 6-7 requires KBO entities to carry out background checks on individuals before employment, and provides a legal basis for requiring credit checks for individuals who are to be given access to facilities, systems or other assets in class 2 and 3. Individuals who are security-cleared and authorised under the National Security Act (sikkerhetsloven) are exempt.

The provision is often read as an HR matter. It is also an IT matter, for a simple reason: knowing who has been screened presupposes knowing who has access. An organisation that cannot produce a precise list of which identities — including guest accounts, consultant accounts and service accounts — have access to class 2 and 3 systems, also cannot document that the personnel-screening requirement has been met for all of them.

In practice, guest accounts are where this fails. A B2B guest invited by a project manager in 2023, who is still a member of a Teams channel containing vulnerability assessments, is both a § 6-3 problem and a § 6-7 problem — and no one in the organisation knows the account exists.

§ 7-4: control of user access, with an annual review

Chapter 7 concerns the protection of the operational control system. § 7-4 reads: "Undertakings shall verify that only legitimate users have access to the operational control system. For this purpose there shall be control arrangements for the granting, modification and deletion of user access... The control arrangements shall be reviewed at least annually" (Norwegian original: "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.").

Two clarifications matter for using this provision correctly in an IT discussion.

First, § 7-4 applies to the operational control system. An operational control system is not normally integrated with Entra ID, and as a general rule should not be. It is not the case that an Entra-based solution "satisfies § 7-4".

Second, the connection is nonetheless real and operational. The people who have user access in the operational control system are employees and contractors with identities in Entra ID. When one of them leaves, the critical question isn't only whether the AD account is disabled, but whether there's a process that also triggers removal of access in the operational control system. In most organisations, that link is a manual checklist or an email.

This is where identity governance on the IT side actually contributes to § 7-4 compliance: not by controlling the operational control system, but by delivering the authoritative signal — "this person is out" — in a structured, traceable form that can trigger action in every downstream system, and by producing the data that the annual review actually needs.

§ 7-10 and § 7-7: external connections and incident logging

§ 7-10 on external connections requires that only approved users be given access, that an up-to-date list of approved users exists, and that the connection follows a pre-agreed procedure. "Up-to-date list of approved users" is a precise documentation obligation — and exactly the kind of artefact that rots between audits when it's maintained manually in a spreadsheet.

§ 7-7 on handling faults, vulnerabilities and security breaches requires the logging of all security breaches and security incidents, with a duty to notify and report to the preparedness authority in the event of an immediate risk to the functioning of the operational control system.

Here the link to identity governance is direct: a significant share of what gets logged as security incidents in practice are incidents tied to accounts and access — failed sign-in attempts, unexpected privilege changes, accounts used from unexpected locations. The quality of incident logging depends on whether there's a baseline state to measure deviations against.

What an audit by the authority actually asks for

Based on how the provisions are worded, this is the documentation that must be ready to produce:

• An overview of which systems and information holdings are classified, and who has access to each of them — as of today, not as of the last count.
• A description of the control arrangements for granting, modifying and deleting user access, and evidence that they're actually followed.
• Minutes from the most recent annual review of the control arrangements.
• An up-to-date list of approved users for external connections.
• Documentation of completed personnel screening for staff with access to class 2 and 3, including contractors.
• A register of security incidents and their handling.

Note that five of the six points concern being able to show a current state and a history. That's a data-availability challenge, not a policy challenge.

Where Entra Logic contributes — and where it doesn't

Contributes: A continuously synchronised, searchable copy of the Entra estate makes the current state available without export jobs. The order model means every access change carries its justification, approver and execution result in the same record, so "control arrangements for granting, modifying and deleting" isn't a document describing something, but a system doing it. Continuous cleanup checks surface orphaned devices, unowned Autopilot registrations and unclassified records as a short worklist, rather than as a backlog that only gets discovered right before the audit.

Does not contribute: Entra Logic does not control the operational control system, and has no function in the OT environment. It does not carry out personnel screening — it only shows who the screening should have been carried out for. And it does not perform attestation or recertification of access; the annual review under § 7-4 is still an activity the organisation must carry out itself, using the data the system provides.

The honest formulation is that Entra Logic shifts a significant part of audit preparation from project work to a data extract. That's a real gain, but it isn't the same as the Regulations being satisfied.

Sources

• The Power Supply Preparedness Regulations (FOR-2012-12-07-1157), §§ 6-2, 6-3, 6-7, 7-4, 7-6, 7-7, 7-10 (the most recent amendment, in force 01.07.2026, concerns § 4-1) — https://lovdata.no/dokument/SF/forskrift/2012-12-07-1157
• The Energy Act (LOV-1990-06-29-50), chapter 9, §§ 9-1 to 9-3 — https://lovdata.no/dokument/NL/lov/1990-06-29-50/KAPITTEL_5
• NSM, Basic Principles for ICT Security v2.1, principle 2.6 — https://nsm.no/getfile.php/1313975-1717589722/NSM/Filer/Dokumenter/Veiledere/NSMs%20Grunnprinsipper%20for%20IKT-sikkerhet%20v2.1.pdf
• KraftCERT/InfraCERT, the sector-specific response environment for the power sector — https://www.kraftcert.no/no/