Most NIS2 material is written for IT departments. A meaningful share of what the directive asks a terminal operator to demonstrate is not an IT control at all. It is whether your operational history can answer for itself.
Almost certainly yes, and as an essential entity rather than an important one. NIS2 Annex I lists energy as a sector of high criticality, and inside the oil subsector it names oil transmission and storage operators, pipeline operators, and central oil stockholding entities. An operator at or above the size threshold, broadly 250 employees, or turnover above EUR 50 million, lands in the essential tier.
The distinction matters more than it first appears. Essential entities are subject to proactive supervision: authorities may inspect, request evidence and conduct security audits without an incident having occurred. Important entities are supervised reactively, after something goes wrong.
In practice this means the question is not whether you could produce evidence following an incident. It is whether you can produce it on a Tuesday, because someone asked.
Article 21(1) requires "appropriate and proportionate technical, operational and organisational measures" reflecting the state of the art, scaled to the entity's exposure, size, and the likelihood and severity of incidents. Article 21(2) then sets a floor of ten measures, on an all-hazards basis.
The directive is deliberately outcomes-based: it states what must be achieved, not which product to buy. Below, the ten measures with the part that tends to be underestimated at a terminal.
| Art. 21(2) | Measure | Where terminals underestimate it |
|---|---|---|
| (a) | Risk analysis and information system security policies | Policy exists; the asset inventory it depends on is a spreadsheet nobody owns. |
| (b) | Incident handling | Handling is competent. Reconstructing the handling months later, with a timeline, is not. |
| (c) | Business continuity, backup management, disaster recovery | Backups are tested. Whether the restore contains what you think it contains is rarely verified. |
| (d) | Supply chain security, including direct suppliers | The hard part is knowing which suppliers touch which systems, and where each contract stands. |
| (e) | Security in acquisition, development and maintenance | Applies to operational technology and vendor-maintained gauging and CMMS systems, not just to IT. |
| (f) | Policies to assess effectiveness of the measures | "Assess effectiveness" requires a record over time. This is the one most often absent entirely. |
| (g) | Cyber hygiene and training | Straightforward, provided attendance and content are evidenced, not just delivered. |
| (h) | Cryptography and encryption policies | Genuinely an IT control. Own it there. |
| (i) | Human resources security, access control, asset management | Access control across OT, contractors and shift staff is harder than the equivalent in IT. |
| (j) | Multi-factor or continuous authentication | Genuinely an IT control. Own it there. |
Two of the ten are pure IT. The rest are operational, and they are demonstrated with records.
A significant incident triggers three deadlines: an early warning within 24 hours of becoming aware of it, indicating whether it is suspected to be malicious or to have cross-border impact; an incident notification within 72 hours updating that warning with an initial severity and impact assessment plus any indicators of compromise; and a final report within one month of the notification, describing the incident, its severity, impact and root cause.
The 24-hour deadline is the one that catches operators, and rarely for the reason they expect. Twenty-four hours is enough time to notice an incident and to act on it. It is frequently not enough time to establish what state the operation was in when it started, which tanks were affected, what maintenance was open, which counterparty commitments the affected assets served.
That reconstruction is trivial if the operational record is already joined. It is a multi-day exercise if it means pulling four systems together while the clock runs.
NIS2's predecessor treated cybersecurity as an organisational obligation. NIS2 attaches it to people. Management bodies must approve the risk-management measures, oversee their implementation, and follow specific training. They can be held personally liable for failures.
Administrative fines for essential entities reach a maximum of at least EUR 10 million or 2% of total worldwide annual turnover, whichever is higher.
This shifts the internal conversation. A board that must personally approve measures will ask to see the basis for them, and "our operations team has it in hand" stops being an adequate answer when the person asking carries the liability.
Strip out (h) and (j), and most of what remains is answered from operational history rather than from network configuration:
An operator can hold every technical control the directive asks for and still fail an inspection, because the evidence of operating them is distributed across a CMMS, a gauging historian, a shift log, an HSSE spreadsheet and a contracts drawer that have never been introduced to each other.
The compliance gap at most terminals is not missing controls. It is that proving the controls operated takes days of assembly, and an inspector asked on Tuesday.
Scope follows where services are provided, not solely where the entity is headquartered. An operator running terminals inside the EU generally falls in scope for those operations, and non-EU entities providing in-scope services may be required to designate an EU representative. Confirm your specific position with counsel: group structure and national transposition both affect the answer.
It helps considerably and maps onto much of Article 21, but it is not equivalence. NIS2 adds obligations ISO 27001 does not impose in the same form: statutory incident reporting on the 24/72/one-month clock, management-body accountability with personal liability, and sector-specific supervision. Treat the certification as a strong foundation, not as a discharge.
Broadly, one that has caused or is capable of causing severe operational disruption or financial loss to the entity, or considerable material or non-material damage to others. Note that it covers incidents capable of causing that harm, not only those that did: a near-miss with sufficient potential can qualify, which is why near-miss records matter more under NIS2 than they did before.
Squarely on the evidence side, and nowhere near the perimeter. It does not replace network security, endpoint controls, MFA or your ISMS. What it addresses is the reconstruction problem: making incident, maintenance, tank and contract history queryable as one record with an attributable audit trail, so that demonstrating a measure operated takes minutes rather than days. Anyone selling you a dashboard as NIS2 compliance is selling you something that does not exist.
This guide reflects Directive (EU) 2022/2555 (NIS2): Article 21 on cybersecurity risk-management measures, Article 23 on reporting obligations, and Annex I on sectors of high criticality. National transposition varies by member state and determines your competent authority, reporting channel and specific thresholds.
Take one past incident and rebuild its operational context from your current systems. If that takes days, the Shadow Pilot measures the same thing against your real exports: in thirty days, without touching production.