NIS2 & MARITIME PORTS
How Salvador Technologies Supports NIS2 Cyber Resilience Requirements
Executive summary
NIS2 places maritime ports squarely inside the EU cybersecurity regime. Annex I identifies transport as a sector of high criticality and expressly includes managing bodies of ports, their port facilities, and entities operating works and equipment within ports. For in-scope entities, Articles 20, 21 and 23 establish governance, cybersecurity risk-management and significant-incident reporting obligations.
A strong direct alignment
Article 21(2)(c) requires “business continuity, such as backup management and disaster recovery, and crisis management.” Salvador Technologies directly supports the backup-management and disaster-recovery elements for critical OT/ICS endpoints through automated backups, isolated recovery copies, integrity verification, centralized recovery-readiness visibility and rapid full-system recovery.
For a port, this is particularly relevant to systems where loss of a Windows-based HMI, engineering workstation, SCADA server or related operational endpoint can stop crane, gate or other terminal operations. Salvador is designed to complement preventive and detective controls, not replace firewalls, EDR, SOC/SIEM, identity security, supply-chain governance or workforce training.
Important legal boundary
Salvador Technologies does not “make a port NIS2 compliant” by itself. NIS2 obligations attach to the entity and must be implemented through a combination of governance, policies, people, processes and technical controls. This document identifies where Salvador provides a direct control, supporting evidence, or only a partial contribution. National transposition law and sector-specific requirements in the port’s Member State must also be checked.
1. Why NIS2 applies to maritime ports
NIS2 applies to public or private entities of a type listed in Annex I or II that meet the Directive’s size criteria, with additional cases where entities can be brought into scope regardless of size. Article 3 then distinguishes “essential” and “important” entities. Large entities of a type listed in Annex I are generally treated as essential entities; other in-scope Annex I or II entities are generally important entities, subject to the detailed rules in Articles 2 and 3 and national designation.
Annex I, Sector 2(c) - Transport / Water
The Directive explicitly includes “Managing bodies of ports … including their port facilities … and entities operating works and equipment contained within ports.” This is why a European port operator should treat NIS2 as directly relevant to both its digital services and the networked operational systems used to deliver port services.
The European Commission’s Article 4 guidance reinforces that Article 21(1) applies to all operations and services of the entity concerned, “not only to specific information technology (IT) assets or critical services.” For a port, that supports an enterprise view that includes OT/ICS where those systems are used in operations or service delivery.
Member States were required by Article 41 to adopt and publish transposition measures by 17 October 2024 and apply them from 18 October 2024. Because NIS2 is a directive, the port should validate the exact obligations, regulator, thresholds and enforcement rules under the national law of the Member State in which it operates.
2. The NIS2 obligations most relevant to port resilience
- Article 20 - Management accountability: Management bodies must approve the Article 21 cybersecurity risk-management measures and oversee implementation. The Directive also requires management-body training. Salvador can provide resilience posture and recovery-readiness evidence to support oversight, but governance approval and training remain the port’s responsibility.
- Article 21(1) - Appropriate and proportionate measures: The entity must take technical, operational and organizational measures appropriate to the risk, considering exposure, size, incident likelihood and severity, including societal and economic impact. In a port, the business impact of unavailable crane, gate, terminal or control systems should therefore feed directly into backup and recovery priorities.
- Article 21(2) - Minimum control areas: The “all-hazards” measures must include ten control areas, from risk analysis and incident handling to business continuity, supply-chain security, effectiveness testing, asset management and authentication. Salvador contributes most strongly to incident handling, business continuity, recovery testing and OT asset/recovery visibility.
- Article 23 - Significant incident reporting: A significant incident includes one that causes or can cause severe operational disruption or financial loss. The notification sequence is an early warning within 24 hours, an incident notification within 72 hours, and a final report generally within one month. Salvador’s logs, alerts, backup status, integrity findings and recovery activity can support the evidence base for reporting, but the port remains responsible for classification and notification.
3. Salvador capabilities relevant to a port’s NIS2 program
| Capability | Functions | NIS2 relevance |
|---|---|---|
| Management Console | Centralized visibility across sites and protected OT endpoints; backup and recovery posture; integrity status; site-level analytics and resilience reporting; SOC/SIEM integration; on-premises deployment option for isolated environments. | Supports oversight, incident handling, effectiveness evidence and asset/recovery visibility. |
| OT Endpoint Management / Agent | Scheduled backups, backup process automation, monitoring of backup data and recovery control. The current product manual states that the agent can autonomously disconnect the Salvador disk when a cyberattack is detected. | Supports backup management, incident response workflow and recovery readiness. |
| Cyber Recovery Unit (CRU) | Dedicated hardware with three NVMe backup and recovery copies. Only one backup disk is powered/connected at a time while the other two are physically air-gapped. Recovery can boot a full OT system from a trusted image without relying on the production network. | Supports isolated backup architecture, recovery from compromised systems and operational continuity during network disruption. |
| Backup Integrity & Recovery Validation | Backup integrity verification and recovery-readiness monitoring, restoration testing and audit-ready reporting. | Supports Article 21(2)(f) effectiveness assessment and evidence that recovery points are usable. |
| Centralized backup / offsite option | The platform supports centralized storage as an additional architecture for broader endpoint coverage, including offsite backup where required by the customer. | Supports layered backup and disaster-recovery architecture; design should follow the port’s RTO/RPO and segmentation requirements. |
4. Detailed NIS2-to-Salvador control mapping
The status labels below are deliberately conservative: Direct support means the capability implements a meaningful part of the stated requirement; Supporting evidence means it contributes evidence or operational capability but does not satisfy the requirement by itself; Outside platform scope means the requirement must be met through other controls and governance.
| NIS2 | Requirement | Status | Salvador Technologies contribution | Boundary / residual responsibility |
|---|---|---|---|---|
| Art. 20(1) | Management approval and oversight of Article 21 measures. | Supporting evidence | Management Console provides centralized resilience, backup integrity and recovery-readiness views and reporting that can be used in management oversight. | Approval, accountability, policy ownership and liability remain with the port. |
| Art. 20(2) | Management-body cybersecurity training. | Outside platform scope | No direct platform control. | Address through the port’s training and governance program. |
| Art. 21(1) | Appropriate and proportionate technical, operational and organizational measures to manage risk and minimize incident impact. | Direct support | Purpose-built OT backup, recovery readiness and rapid recovery reduce the operational impact of endpoint compromise or failure. | Must be part of a broader risk-based control set. |
| Art. 21(2)(a) | Risk analysis and information-system security policies. | Supporting evidence | Site/asset visibility, resilience posture, backup status and risk scoring can inform risk analysis and policy assurance. | Does not replace enterprise risk assessment or security policy. |
| Art. 21(2)(b) | Incident handling. | Direct support | Attack-aware backup protection, recovery workflow, integrity information and SOC/SIEM integration support containment/recovery decisions. | Not a replacement for EDR, NDR, SIEM, SOC or incident command. |
| Art. 21(2)(c) | Business continuity, including backup management and disaster recovery. | Direct support - strongest fit | Automated backups, multiple isolated recovery points, verified integrity, recovery testing, full-system recovery and network-independent CRU operation directly address backup and disaster-recovery capability for protected OT assets. | Crisis management, enterprise BCP ownership, dependencies and manual procedures remain with the port. |
| Art. 21(2)(d) | Supply-chain security. | Outside platform scope | Salvador is itself a direct supplier to be included in the port’s supplier-risk process. | Supplier selection, contractual controls, third-party risk and subcontractor governance are port responsibilities. |
| Art. 21(2)(e) | Security in acquisition, development and maintenance, including vulnerability handling. | Supporting evidence | Trusted recovery points and recovery validation reduce operational risk when systems fail or are corrupted during maintenance/change. | Does not replace secure development, patch governance or vulnerability disclosure processes. |
| Art. 21(2)(f) | Assess effectiveness of cybersecurity risk-management measures. | Direct support | Backup integrity verification, recovery-readiness monitoring, restoration testing and audit-ready reporting provide evidence that recovery controls are functioning. | Overall control-effectiveness testing must cover the full cybersecurity program. |
| Art. 21(2)(g) | Cyber hygiene and cybersecurity training. | Outside platform scope | No direct platform control. | Address through policies, hardening, patching, awareness and role-based training. |
| Art. 21(2)(h) | Cryptography and encryption policies. | Outside / limited scope | Salvador should be configured consistently with the port’s encryption and key-management policies, but this is not the platform’s primary NIS2 contribution. | Port defines cryptographic policy and coverage. |
| Art. 21(2)(i) | HR security, access control policies and asset management. | Supporting evidence | The Management Console provides site and protected-endpoint visibility relevant to OT asset/recovery management. | Does not replace IAM, HR security or the authoritative asset inventory/CMDB. |
| Art. 21(2)(j) | MFA/continuous authentication and secure communications where appropriate. | Outside platform scope | No claim that Salvador satisfies this control area. | Use the port’s identity, privileged-access and secure-communications controls. |
| Art. 21(3) | Consider vulnerabilities and cybersecurity practices of direct suppliers/service providers. | Supporting evidence | Salvador should be included in the port’s supplier due diligence; company materials state alignment with ISO 27001 and product compliance/certification information is available for review. | Due diligence and acceptance are the port’s responsibility. |
| Art. 23(3)-(4) | Significant-incident classification and staged notification. | Supporting evidence | Timestamped alerts, backup/integrity status, asset context, recovery actions and SIEM/SOC integration can support incident reconstruction and impact evidence. | The port must determine significance, notify the competent authority/CSIRT and meet deadlines. |
5. What this means operationally for a European port
A port should translate NIS2 into a risk-based recovery architecture that starts from operational impact. The key question is not simply whether a system is backed up, but whether the port can demonstrate that a trusted recovery point exists, that it is isolated from the incident path, and that the asset can be restored within the operationally acceptable recovery time.
- Identify critical OT endpoints whose unavailability can stop or materially degrade cargo handling, gate operations, crane operation, terminal control or other essential port services.
- Define RTO and RPO targets from operational impact, then assign the recovery architecture accordingly. The CRU is most relevant to the highest-criticality endpoints where network-independent rapid recovery is required.
- Automate backup schedules and continuously monitor backup health, integrity and recovery readiness rather than relying on manual backup procedures.
- Keep trusted recovery points isolated from the production attack path. Salvador’s CRU architecture maintains multiple copies with hardware-enforced air-gap states documented in the current user manual.
- Test recovery periodically and retain evidence. NIS2 Article 21(2)(f) makes effectiveness assessment an explicit requirement; restoration tests and integrity reports are practical evidence for the recovery-control portion of that obligation.
- Integrate recovery status and incident signals with the port SOC/SIEM so that recovery activity forms part of incident handling and post-incident reporting.
- Retain separate controls for identity, network security, vulnerability management, supplier governance, training and secure communications. Salvador complements these layers.
6. Supporting Article 23 incident reporting
Article 23 requires notification of significant incidents. It defines significance in terms that are especially relevant to ports: severe operational disruption or financial loss, or considerable harm to others. The reporting workflow is time-sensitive, so recovery telemetry and evidence should be available before an incident occurs.
| Stage | NIS2 timing | What the port needs | How Salvador can support |
|---|---|---|---|
| Early warning | Within 24 hours | Awareness of the event, likely malicious nature and possible cross-border relevance. | Console alerts, protected-asset context and backup-integrity status can contribute to the initial fact base. |
| Incident notification | Within 72 hours | Initial severity/impact assessment and available indicators of compromise. | Recovery posture, asset status, backup manipulation findings and SOC/SIEM integration can support impact assessment. |
| Final report | Generally within 1 month | Detailed incident description, severity/impact, likely root cause, mitigation actions and cross-border impact where applicable. | Backup/recovery history, integrity reports and restoration activity can evidence the recovery and mitigation portion of the record. |
7. Maritime deployment evidence
Salvador’s published maritime case study describes deployment on critical port endpoints including ABB HMI terminal crane computers running Windows 10 and a Siemens Windows Server 2012 system with SIMOCRANE CMS. The case study states that the solution performs scheduled frequent full backups of operating systems, configurations and data files, provides Management Console visibility, and demonstrated recovery during the proof of concept.
Why the example matters for NIS2
It demonstrates the type of operational control Article 21(2)(c) is concerned with: a repeatable backup and recovery mechanism for systems used to deliver an essential port service. It should be used as evidence of technical capability, not as proof that a particular port or deployment is NIS2 compliant.
8. Recommended NIS2 evidence package for a port deployment
For each protected critical asset or asset group, the port should retain a concise evidence set that can be used for management oversight, internal audit, competent-authority requests and post-incident analysis:
- Asset/site identification and operational criticality classification.
- Approved backup frequency and recovery objective (RPO/RTO).
- Current backup status and last successful backup timestamp.
- Backup integrity / recovery-readiness status and exceptions.
- Evidence of recovery testing and test outcome.
- Recovery procedure and designated operational roles.
- Incident and recovery event history, including timestamps and mitigation actions.
- SOC/SIEM integration records where used.
- Supplier due-diligence records for Salvador as a direct technology supplier.
Supervisory evidence matters
Article 32 gives competent authorities powers that include requests for documented cybersecurity policies, data and information, and evidence of implementation. A well-maintained recovery-readiness record therefore supports more than operations: it helps demonstrate that the port’s backup and recovery policy is actually implemented.
9. Scope boundaries and implementation notes
- This document maps Salvador capabilities to the EU-level NIS2 Directive. It is not legal advice and should be read together with the national NIS2 transposition law and regulator guidance applicable to the specific port.
- NIS2 is an entity-level obligation. Product deployment alone is not compliance, certification or a substitute for documented policies, risk assessment, governance and evidence.
- Salvador’s primary role is OT/ICS operational resilience: backup management, backup integrity, recovery readiness, rapid recovery and centralized visibility.
- Preventive and detective cybersecurity controls remain necessary. Salvador’s own FAQ explicitly states that the platform is not designed to replace prevention/detection tools such as firewalls and EDR.
- Claims in a procurement or compliance submission should be limited to the functions actually licensed, configured and validated in the port’s deployment.
References and validation sources
- Directive (EU) 2022/2555 (NIS2), consolidated text, EUR-Lex Source
- Directive (EU) 2022/2555, Annex I - Transport / Water, EUR-Lex Source
- European Commission Guidelines on Article 4(1) and (2) of NIS2 (2023/C 328/02) Source
- Salvador Technologies - Operational Resilience for Industrial Operations Source
- Salvador Technologies - Management Console Source
- Salvador Technologies - Compliance & Resilience Source
- Salvador Technologies - Cyber Recovery Unit Source
- Salvador Technologies - Maritime Case Study Source
- Salvador Technologies - FAQ Source