From decision to executed change: the traceability requirement in petroleum regulation, applied to the identity platform

There is no ICT security section, and that's worse than if there were one

A common question from IT leaders in petroleum activities: which section of the Norwegian Ocean Industry Authority's regulations governs ICT security?

The answer is that there isn't one. The HSE regulations for petroleum activities — the Framework Regulations, the Management Regulations, the Activities Regulations and the Facilities Regulations — do not have a dedicated digital security regulation equivalent to the Digital Security Act (digitalsikkerhetsloven). ICT security is handled through the general management requirements, supplemented by the industry standard Offshore Norway (Offshore Norge) 104, which § 34a of the Facilities Regulations references in its guidance.

This feels like a relief. It's the opposite. An explicit section would have given you a bounded list to tick off. The general management requirements instead set an expectation that ICT security is handled with the same rigour as everything else safety-critical — barriers that are identified and have known performance, nonconformities that are registered and root-cause analysed, data that is collected and used.

That's a higher standard, not a lower one.

For context: the regulator changed its name from the Petroleum Safety Authority (Petroleumstilsynet / Ptil) to the Norwegian Ocean Industry Authority (Havtil) with effect from 1 January 2024, subordinate to the Ministry of Energy.

The four provisions that actually apply

Management Regulations § 5, "Barriers." Requires that barriers be established to identify and prevent conditions that could lead to failures, hazards and accidents. Barriers must be known — what function they have, what performance they are meant to have, and who is responsible.

Applied to identity: if access control on a system path leading into safety-critical systems is a barrier, it must be treated as a barrier. It must have a defined performance level. Failures in it must be registered as barrier failure. In most organisations, access control in Entra ID is not included in barrier management at all, because it is administered as an administrative IT service.

Management Regulations § 6, "Management of health, safety and the environment." Requires that management cover the necessary activities, resources and processes. The processes must be described, and the described processes must be the ones actually followed. The gap between described and actual practice in access management is often substantial — because the described process is the formal request flow, while the actual one is a Teams message to a colleague with the right permissions.

Management Regulations § 19, "Collection, processing and use of data," and § 20, "Registration, investigation and analysis of situations of hazard and accident." Data must be collected, processed and used — not just exist. An audit log that technically contains everything but from which nobody can extract anything meaningful within a reasonable time does not meet the intent.

Management Regulations § 22, "Nonconformity handling." Requires registration, follow-up, root cause analysis and corrective or compensating measures. This is the most demanding in practice: root cause analysis presupposes that you know what actually happened, in what order, and on what decision.

Three trails that have to be pieced together manually

Consider what a specific nonconformity requires in the way of documentation in a traditional setup. An internal audit finds that a person had access to a system they shouldn't have had, for four months.

To handle this as a nonconformity under § 22, you have to establish:

1. When was the access granted? Source: the Entra audit log. Problem: the default retention period in Entra is 30 days with P1 or P2, and if the event is older than that and hasn't been exported to external storage, the answer no longer exists.

2. Who granted it? Same source. Gives you an account identifier, not a decision.

3. On what basis? Source: the case management system, if a case was opened. Otherwise email. Otherwise nothing.

4. Who approved it? Source: email, or a field in the case management system, if the approval was recorded there and not given verbally in a meeting.

5. Was what was approved the same as what was executed? This is the question nobody can answer precisely, because it requires comparing a free-text description in a case against a set of technical events in a log, and judging whether they match.

Point five is the crux. In a model where a person with administrator privileges manually carries out an approved change, there is always a gap between decision and action. The gap is usually empty — the technician did what was agreed. But it cannot be proven without manual correlation, and under an investigation, "we assume it's correct" is not an answer.

What a single connected order does about this

Entra Logic's model is to make decision and execution the same object. A change in Entra ID originates as a request with a business justification, receives an approval decision with a name and a timestamp, and is then carried out mechanically by a central engine that runs PowerShell against Microsoft Graph. The result of the execution — including errors — is written back to the same record.

The consequence for the five questions above: all five are answered from a single source, and question five is answered structurally instead of by judgement. What was approved is what was executed, because there is no manual intermediate step where something else could have happened.

This is a documentation property, not just a security property. For § 22 handling, it means root cause analysis can start from facts instead of reconstruction. For § 19, it means data is actually in a form that can be processed and used. For § 5, it means the barrier has a measurable performance — number of changes, number of rejected requests, number of execution failures — that can be reported.

A point worth stressing for anyone who has worked on investigations: automated execution also removes the entire category of nonconformity caused by a technician under time pressure doing something slightly different from what was agreed. Bulk operations during reorganisations are the classic example — a freehand script that hits the wrong group. Structured bulk requests where every individual change still gets its own accountable order remove that failure mode without removing the efficiency.

A factor that wrecks more investigations than people think: retention period

The default retention period for audit and sign-in data in Entra ID is 30 days for tenants with Entra ID P1 or P2, and 7 days for Entra ID Free. Organisations that don't actively export this data to longer-term storage — a log analytics platform, a SIEM or similar — have a lookback window of one month.

The arithmetic is uncomfortably concrete. An unwarranted access arrangement is rarely discovered within 30 days. When discovery happens through an internal audit, a coincidence, or preparation for an audit by the authority, months have typically passed. By then, the answer to "when and by whom was this access granted" isn't just hard to find — it no longer exists.

The consequence for § 22 handling is that root cause analysis has to rely on assumptions. That's not an acceptable starting point in a regulatory framework built on the premise that causes must be understood for corrective measures to hit the mark.

A continuously synchronised copy of directory state, with associated change history tied to orders, addresses this differently from log storage: instead of storing events from the platform, it holds the state itself and the decisions that changed it. For documentation purposes, that's often what's actually needed — not every single technical call, but who decided what, when, and what the result was.

Where the boundaries lie

Three clarifications, because overselling in this industry backfires fast.

Entra Logic covers the Microsoft estate. Changes in systems outside Entra ID and the associated Microsoft services do not get this audit trail. For an operator with a dozen line-of-business systems, the identity platform is one source among many.

The product is not an attestation or certification tool. It does not run periodic campaigns where managers have to confirm that their subordinates' access is still correct, and it does not do segregation-of-duties analysis. If the organisation's management system requires this, it has to be covered elsewhere.

Barrier management is an organisational exercise. No vendor can define which of your technical controls are barriers, or with what performance. That work has to be done internally. What the software can do is deliver measurable figures about the barrier once it has been defined.

Three questions to ask at the next management system review

1. Is access control in the identity platform included in the barrier description, with defined performance and an accountable owner, or is it treated as an administrative IT service?

2. For a randomly chosen access change from last quarter, can we document justification, approver and actual execution — from a single source, in under ten minutes?

3. How long is audit data on identity changes actually retained, and is the retention period matched to how long a nonconformity typically goes undetected?

Question three usually uncovers a gap of several months.

Sources

• Microsoft, Microsoft Entra data retention (30 days for P1/P2, 7 days for Free) — https://learn.microsoft.com/en-us/entra/identity/monitoring-health/reference-reports-data-retention
• Havtil, the Management Regulations (§§ 5, 6, 19, 20, 22) — https://www.havtil.no/globalassets/regelverk/gjeldende-regelverk-2022/styringsforskriften_n.pdf
• Havtil, the Framework Regulations § 11 — https://www.havtil.no/en/regulations/all-acts/the-framework-regulations3/II/11/
• Havtil, the Facilities Regulations § 34a (references ON 104 in the guidance) — https://www.havtil.no/en/regulations/all-acts/the-facilities-regulations3/V/34a/
• Havtil on the name change from Petroleumstilsynet, effective 01.01.2024 — https://www.havtil.no/en/about-us/role-and-area-of-responsibility/our-history/
• Offshore Norway (Offshore Norge), guidelines overview (ON 104) — https://www.offshorenorge.no/en/faginnhold/guidelines/guidelines/
• DNV GL for Ptil/Havtil, Regulations and supervisory methodology — ICT security — https://www.havtil.no/globalassets/fagstoff/prosjektrapporter/ikt-sikkerhet/dnv-gl—regelverk-og-tilsynsmetodikk.pdf