Specific Obligations for Operators of Vital Importance

1. Where OVIs Fit in the Cybersecurity Framework

In many European and national cybersecurity laws inspired by NIS2 (the EU Directive on measures for a high common level of cybersecurity, which entered into force in 2023 and must be implemented by Member States by October 2024), entities are grouped by criticality.

For this module, we focus on Operators of Vital Importance (OVIs) in ICT‑heavy environments (e.g., national cloud providers, major ISPs, critical data center operators). OVIs are typically:

• More critical than standard essential entities (their disruption can seriously affect national security, economy, or public safety).
• More tightly regulated, with stricter cybersecurity obligations, especially around governance, risk management, and incident response.

You should already know from previous modules that all essential and OVI operators must:

• Implement baseline cybersecurity measures (e.g., access control, patching, incident reporting).
• Cooperate with ANCI (the central cybersecurity authority) and CSIRTs.

What is special about OVIs?

Compared to other obliged entities, OVIs usually face:

• Higher security standards (e.g., closer alignment with ISO/IEC 27001 and related standards).
• Tighter incident reporting deadlines and more detailed reporting.
• Stronger documentation and audit expectations.
• More frequent and intrusive supervision by ANCI and sectoral authorities.

In the next steps, you will see how these stricter obligations translate into a practical Information Security Management System (ISMS) for an ICT operator classified as an OVI.

2. OVI-Specific ISMS Requirements: Going Beyond the Baseline

An Information Security Management System (ISMS) is the structured set of policies, procedures, roles, and controls that manage information security risks.

For OVIs, the ISMS is not just "nice to have"; it is typically a legal obligation and must meet higher maturity and formality standards than for ordinary entities.

Key OVI-specific ISMS expectations (aligned with current best practice and NIS2-style national laws):

1. Formal ISMS Scope and Governance

• Clearly defined scope covering all networks, information systems, and critical data that support vital services.
• Documented governance structure: roles like CISO, incident manager, risk owner, system owner.
• Board-level oversight with explicit approval of the security policy and risk appetite.

1. Mandatory Risk-Based Approach

• Systematic risk identification, assessment, and treatment for all critical ICT assets.
• Regularly updated risk register with likelihood–impact analysis.

1. Policy & Procedure Depth

• Detailed procedures for change management, backup & recovery, vulnerability management, access control, supplier management, etc.
• Evidence that these procedures are applied in practice (logs, tickets, records).

1. Continuous Improvement

• Periodic internal audits of the ISMS.
• Management reviews with documented decisions and action items.

In short: for OVIs, the ISMS must be systematic, documented, and auditable, not informal or ad hoc.

3. Thought Exercise: Scoping an OVI ISMS for an ICT Operator

Imagine you are the security manager of a national cloud and hosting provider that has just been classified as an OVI.

Task: Write down (mentally or on paper) what you would include in your ISMS scope statement.

Use this structure:

1. Business services covered

Example: "Provision of cloud infrastructure (IaaS), platform (PaaS), and managed hosting services to public-sector and critical private-sector clients."

1. Assets and environments covered

Think of:

• Data centers A, B, C
• Core network infrastructure
• Virtualization platforms
• Storage clusters
• Management and monitoring systems

1. Exclusions (if any)

Are there systems that are explicitly outside the ISMS scope? (For OVIs, exclusions are usually limited and must be justified.)

1. Key interfaces

• Connections to telecom operators
• Links to government networks
• Third-party security monitoring providers

After drafting, ask yourself:

• Would this scope allow ANCI or an auditor to clearly see what is protected?
• Are all vital services and supporting systems included?

If not, refine your mental draft before moving on.

4. Risk Identification for OVIs: What Can Go Wrong?

OVIs must perform systematic risk identification that is more detailed and frequent than for ordinary entities.

For ICT-heavy OVIs, risk identification typically includes:

1. Asset-Based View

• Networks: core routers, firewalls, VPN gateways, DNS, load balancers.
• Systems: hypervisors, application servers, identity providers, monitoring tools.
• Data: customer data, configuration data, logs, cryptographic keys.

1. Threats and Vulnerabilities

• Threats: DDoS attacks, ransomware, insider misuse, supply-chain compromise, cloud misconfiguration, zero-day exploits.
• Vulnerabilities: unpatched software, weak network segmentation, over-privileged accounts, outdated cryptography.

1. Business Process Mapping

• Map each critical business process (e.g., provisioning VMs, customer portal access, incident handling) to the ICT assets that support it.
• Identify where a single point of failure could disrupt a vital service.

1. Legal and Regulatory Context

• Incorporate current regulatory requirements (e.g., national NIS2 implementation, data protection laws like GDPR, sector-specific rules) as sources of risk (compliance risk).

OVIs are expected to show that this risk identification is:

• Documented (e.g., asset inventory, threat catalogs, architecture diagrams).
• Repeatable (not a one-off; updated at least annually or after major changes/incidents).

5. Quick Check: Risk Identification Focus

Test your understanding of OVI risk identification priorities.

6. Risk Assessment: Likelihood, Impact, and OVI-Specific Criteria

Once risks are identified, OVIs must assess them using structured likelihood–impact analysis.

Typical OVI-oriented risk assessment characteristics:

1. Defined Scales

• Likelihood: e.g., Rare / Unlikely / Possible / Likely / Almost certain.
• Impact: must explicitly consider:
• Service continuity (downtime, degraded performance).
• Safety and public order (if relevant).
• Economic and societal impact (number of users affected, critical sectors impacted).
• Legal and regulatory consequences (fines, sanctions, supervisory measures).

1. Risk Matrix

• Risks are plotted in a risk matrix (likelihood vs impact) to determine risk level (e.g., Low, Medium, High, Critical).
• OVIs often have lower tolerance for high-impact risks that could disrupt vital services, even if likelihood is moderate.

1. Scenario-Based Thinking

• Example scenarios:
• Ransomware encrypting hypervisors in the primary data center.
• BGP misconfiguration causing national-scale connectivity loss.
• Compromise of identity provider leading to unauthorized access to government tenants.

1. Regulator-Driven Minimums

• National NIS2-style rules often require OVIs to treat certain categories of risk (e.g., supply-chain risks, remote access, privileged accounts) as priority areas, regardless of initial scoring.

The output of this step is a documented risk register with:

• Risk description
• Likelihood and impact ratings
• Overall risk level
• Risk owner
• Links to controls (existing or planned)

7. Example: Risk Assessment Entry for an OVI Cloud Provider

Below is a simplified example of a risk register entry for an OVI-classified cloud provider.

```text

Risk ID: R-2026-07

Risk Title: Ransomware infection of virtualization management platform

Assets Affected:

• vCenter cluster for Data Center A
• Backup management server
• Administrative jump hosts

Threat:

• Targeted ransomware campaign exploiting a 0-day vulnerability in remote management interface.

Vulnerabilities:

• Delayed application of security patches on management servers.
• Shared admin accounts without MFA.

Potential Impacts:

• Loss of control over tenant VMs in Data Center A.
• Multi-day service outage for government and healthcare tenants.
• Breach of regulatory uptime requirements for vital services.

Likelihood (1–5): 3 (Possible)

Impact (1–5): 5 (Severe)

Overall Risk Level: Critical

Risk Owner: Head of Infrastructure

Existing Controls:

• Network segmentation between management and tenant networks.
• Daily offline backups of tenant data.

Required Treatment (OVI-level):

• Implement MFA and unique accounts for all admin access within 2 months.
• Patch management SLA: critical patches on management servers within 72 hours of release.
• Implement application allowlisting on management servers.

Target Residual Risk Level: Medium

Target Date: 30 June 2026

Status: In progress

```

This example shows the OVI emphasis on:

• Detailed asset and impact description (vital services, regulated uptime).
• Clear time-bound treatment actions.
• Explicit residual risk target and accountability.

8. Risk Treatment and Higher OVI Standards

OVIs are expected not only to identify and assess risks, but to treat them according to stricter standards and timelines.

Common OVI-specific risk treatment expectations:

1. Mandatory Controls for High/Critical Risks

• High or critical risks affecting vital services typically cannot be accepted without strong justification and regulator awareness.
• They must be mitigated or transferred (e.g., through architecture changes, additional controls, or contractual arrangements).

1. Time-Bound Remediation

• National rules often prescribe deadlines (e.g., apply critical security patches within X hours/days, remediate high vulnerabilities within Y days).
• OVIs must track these deadlines and be able to prove compliance during audits.

1. Defense-in-Depth

• Multiple layers of security for critical functions:
• Strong authentication (MFA),
• Network segmentation,
• Endpoint protection,
• Logging and monitoring,
• Backup and recovery.

1. Supply-Chain and Outsourcing Controls

• OVIs must manage third-party risk more strictly:
• Security requirements in contracts (e.g., incident notification times, audit rights).
• Verification of suppliers’ security posture (certifications, SOC reports, penetration tests).

1. Documented Risk Acceptance

• When a risk is accepted (rather than mitigated), OVIs must document:
• Rationale (e.g., mitigation not technically feasible, cost vs benefit).
• Approval at an appropriate senior level.

All of this must be embedded into the ISMS processes: change management, project governance, procurement, and operations.

9. Translating OVI Obligations into ISMS Procedures

Use this activity to connect OVI obligations with practical ISMS components.

Task: For each OVI obligation below, decide which ISMS procedure or document it should primarily influence. Think it through before checking the suggested mapping.

1. Obligation: Apply critical security patches on internet-facing systems within a strict deadline (e.g., 72 hours).

• Your guess: Which procedure or document?
• Suggested mapping: Vulnerability and Patch Management Procedure + Change Management Procedure (to ensure urgent patches can bypass normal long change cycles while still being controlled).

1. Obligation: Report major incidents to ANCI and the national CSIRT within short timelines (e.g., initial notification within hours, final report within days).

• Your guess: Which procedure or document?
• Suggested mapping: Incident Management Procedure + Regulatory Incident Reporting Work Instruction (detailing who notifies ANCI/CSIRT, what information must be included, and how deadlines are tracked).

1. Obligation: Maintain evidence of security activities (e.g., risk assessments, control checks, training) for audits.

• Your guess: Which procedure or document?
• Suggested mapping: Documentation and Record-Keeping Policy + specific sections in each operational procedure describing what records to keep, where, and for how long.

1. Obligation: Ensure suppliers critical to service continuity meet defined security standards.

• Your guess: Which procedure or document?
• Suggested mapping: Supplier Management / Third-Party Risk Management Procedure with security clauses in procurement templates and periodic supplier assessments.

Reflect: Which of these areas would be weakest in a typical small ICT company, and how does OVI classification force them to improve?

10. Documentation and Record-Keeping for OVIs

Because OVIs are subject to intensive supervision, documentation is a central obligation.

Typical OVI documentation and record-keeping requirements include:

1. Core ISMS Documents

• Information Security Policy
• Risk Management Methodology
• Asset Inventory
• Risk Register
• Statement of Applicability (for controls)

1. Operational Records (Evidence of Doing)

• Change records (who approved, what was changed, when).
• Patch logs (dates applied, systems affected, exceptions).
• Incident tickets and post-incident reports.
• Access reviews and privilege change logs.
• Backup and restore test results.

1. Governance Records

• Management review minutes and decisions.
• Internal audit reports and follow-up actions.
• Training records for staff and contractors.

1. Regulatory Interaction Records

• Notifications and reports sent to ANCI and CSIRTs.
• Correspondence and remediation plans agreed with sectoral authorities.

Retention:

• National rules often specify minimum retention periods (e.g., several years) for logs, incident records, and audit evidence.
• OVIs must ensure records are integrity-protected (tamper-evident) and retrievable on request.

In practice, this means OVIs need a documented information management approach—often supported by ticketing systems, log management platforms, and secure document repositories.

11. Check Understanding: What Distinguishes OVIs?

Confirm that you can distinguish OVI obligations from general ones.

12. Flashcards: Key Terms for OVI Obligations

Use these flashcards to reinforce the core concepts from this module.