Does NIS2 apply to our transport operation, and what does it cost us to comply?
NIS2 covers the air, rail, water and road subsectors of transport listed in Annex I, but only operators that meet the size-cap rule of Article 2 are in scope. Once an operator is in scope, its status as essential or important depends on its size and its category under Article 3. No certificate of compliance is issued under NIS2. Your national competent authority oversees compliance through inspections, audits, scans and information requests, and the national transposition law in each Member State where you provide services determines the details. Start by confirming, with your legal team and your national authority's guidance, which subsector your activities fall into and whether you exceed the medium-sized enterprise ceilings in Recommendation 2003/361/EC. You can read the sector list in the NIS2 Directive text on EUR-Lex.
Cost and timeline depend on three factors: the size and number of systems that support operations (such as operational technology, ticketing, booking, signalling interfaces and corporate IT), whether your activities are already covered by a sector-specific EU act that may displace NIS2 under Article 4(1), and whether your operation is also designated as a critical entity under the CER Directive. Each of these changes which measures you must implement and which authority you deal with. Cost has several components: internal staff time for governance and policy ownership, technology work to close gaps, external assessment or auditing, and recurring operating costs such as monitoring, patching, backups and training. The one-time work is usually the gap analysis and the first remediation cycle, while monitoring and evidence collection recur every year. When you request quotes, ask for a written scope listing the subsectors, sites, systems and evidence to be delivered, and ask the vendor which items are fixed and which are charged on a time basis.
Responsibility is split clearly. Your organization owns its controls and the decisions behind them, and management remains accountable under Article 20. DeployOpen can plan, implement, harden and document the open-source platforms and the evidence that support your Article 21 measures inside your own infrastructure. DeployOpen does not judge compliance and does not issue reports or certificates. Only your national competent authority or an independent assessor it recognizes can judge whether your measures meet the requirement, so plan your evidence so that an outside reviewer can test it without help from the implementation team.
Which transport entities fall in scope under the size cap
NIS2 lists air, rail, water and road transport as Annex I sectors, so the size test decides scope before the subsector does. The cards below walk through the subsectors, the Article 2(1) test, and how essential and important status follows from it.
Air transport subsector
Annex I covers air carriers, airport managing bodies, airports, and traffic management control operators within the air subsector. Operators must first meet the Article 2(1) test: medium-sized or larger under Recommendation 2003/361/EC and providing services or carrying out activities in the Union. Confirm with your national competent authority which air entity types your Member State has named, since the Annex defines them by function and transposition details vary.
Rail transport subsector
The rail subsector in Annex I covers infrastructure managers, railway undertakings, and operators of ancillary services such as traffic management. Each category needs its own size check, because a group may contain entities of very different sizes. Map each legal entity separately, then confirm the classification against how your Member State transposed the subsector definitions.
Water transport subsector
Inland, sea and coastal passenger and freight water transport companies fall within the Annex I water subsector, along with managing bodies of ports and operators of vessel traffic services. Many port and ferry operators are small, so the Article 2(1) size test often settles scope early. Check national definitions of port facilities and vessel traffic services, which can narrow or widen the entity list.
Road transport subsector
The road subsector in Annex I covers road authorities responsible for traffic management, and operators of intelligent transport systems. Road authorities may fall under public administration rules instead, depending on how the Member State organizes them. Confirm which road bodies are in scope with your national authority before applying the size test.
Size test and service in the Union
Article 2(1) brings an Annex I entity into scope only if it meets or exceeds the medium-sized enterprise ceilings in Recommendation 2003/361/EC and provides services or carries out activities in the Union. Headcount and turnover or balance sheet totals are assessed at group level for partner and linked enterprises, so ask counsel to confirm how the ceilings apply to your corporate structure.
Essential or important status
An in-scope Annex I transport entity is essential when it exceeds the medium-sized ceilings under Article 3(1)(a). Other in-scope Annex I entities are important, unless another Article 3(1) category, such as CER critical entity status, makes them essential. Essential status brings ex ante supervision under Article 32, so this classification drives the audit exposure.
How essential status changes supervision and fines
Essential status changes how a transport operator is supervised, not what it must do. An essential entity falls under ex ante supervision, meaning the national competent authority can act before any failure occurs. Under Article 32, the authority can carry out on-site inspections and off-site supervision, including random checks, run regular and targeted security audits performed by an independent body or by the authority itself, order ad hoc audits, and run security scans. For an air carrier, a rail undertaking, a port operator or a road operator classed as essential, the practical implication is that the authority may arrive at a depot, control room or terminal with little notice and ask to see the evidence behind its Article 21 measures.
Important entities in the same transport subsectors face ex post supervision under Article 33. The authority acts after it has evidence that an entity may not be meeting its obligations, for example following an incident, a complaint or a regulator's information request. The obligations themselves are the same. Both essential and important transport operators must apply the Article 21 risk-management measures and meet the Article 23 reporting deadlines, including the early warning within 24 hours of becoming aware of a significant incident. Operators should therefore plan on the assumption that the same evidence will be needed in either case, and confirm with their national authority how it intends to apply Articles 32 and 33 to them.
Buyers should confirm the exact fine ceilings and enforcement measures in their own national transposition law, because Article 34 and the national rules set them and this page does not restate them. Before scoping any audit readiness work, management should ask its counsel and its authority which enforcement measures apply, whether the operator's sector-specific act displaces any NIS2 provisions under Article 4(1), and how the national authority coordinates with the CER competent authority where the operator is also identified as a critical entity.
How CER Directive critical entity status interacts with NIS2
Transport operators can sit under two EU regimes at once: the NIS2 Directive for cyber risk and the CER Directive for physical resilience. The cards below explain how a critical entity designation links the two, what changes in practice, and what to confirm with your national authorities.
Critical entity status points to essential
Recital 30 of NIS2 says entities identified as critical entities under the CER Directive (Directive (EU) 2022/2557) should be considered essential entities under NIS2. A transport operator that has been designated critical should therefore plan for essential status and the ex ante supervision that comes with it, even if its size alone would have made it important. Confirm the designation status in writing before setting your supervision assumptions.
Cooperation between two authority sets
The NIS2 competent authorities and the CER competent authorities are expected to cooperate and exchange information without undue delay. For a transport operator, this means a cyber incident and a physical disruption may reach two regulators from one event. Ask your national authorities which bodies hold each role, and whether a single point of contact is designated for information exchange.
Physical and cyber risks in one assessment
Physical resilience and cyber resilience often share the same assets, such as signaling, ticketing, vessel or fleet telemetry, and operations centers. A single risk assessment that covers both, with one register of threats and dependencies, avoids two sets of conflicting controls. Map where a physical outage could start with a cyber event, and the reverse, before you write the risk treatment plan.
Shared business continuity and recovery
Backups, redundancy, alternate sites and recovery time objectives serve both the Article 21 measures and the resilience duties for critical entities. Test recovery for systems that run physical operations, not only IT, and record the results as evidence. Ask whether your CER resilience plan and your NIS2 continuity documentation use the same asset inventory and the same recovery targets.
Incident reporting under both regimes
Early warning under NIS2 must be submitted without undue delay and within 24 hours of becoming aware of a significant incident. A transport operator that is also a critical entity should check whether a physical incident triggers CER notification duties in parallel. Build one incident intake that records the time of awareness, the affected services and the authorities to notify, so the clock is not lost between teams.
Confirm CER identification with authorities
Whether an operator is identified as a critical entity under the CER Directive is decided by the national authority, not by the operator's own view of its importance. Ask the authority in writing whether your organization, or a specific site or service, has been identified, and what that means for your NIS2 classification. Keep the answer in your compliance file, because supervisors will ask how essential status was determined.
How the staged incident reports run for a transport operator
The staged sequence gives the national authority an early signal, then a fuller picture, then a final account, while letting the operator contain the incident and keep affected service recipients informed. Each stage produces a specific record that the operator must be able to produce on demand.
Detect and classify the incident
The operator's security or operations team identifies an event affecting network and information systems and decides whether it is a significant incident under the criteria that apply to the operator. This is the point at which the 24-hour clock in Article 23(4)(a) starts, because the obligation runs from becoming aware of a significant incident. Confirm with your national competent authority or sectoral supervisor how they expect significance to be judged for air, rail, water and road operations, and record the time you became aware. The output is a dated incident record with the classification decision and the name of the person who made it.
Activate the incident playbook and contacts
Once the incident is classified, the incident lead activates the pre-approved playbook, which should name who decides on reporting, who drafts the notices and who is authorized to speak for the operator. The playbook and contact list must already exist and be tested before an incident occurs, because the early warning is due within a fixed window and cannot wait for documents to be drafted. Confirm which national authority and reporting channel apply to each transport subsector you operate in. The output is an activated incident file with a named reporting owner and the reporting channel confirmed.
Submit the early warning
The operator submits the early warning to the competent authority without undue delay and in any event within 24 hours of becoming aware of the significant incident, as set out in Article 23(4)(a) of NIS2. The early warning is deliberately brief. It establishes that a significant incident exists, and it may indicate whether the incident could be caused by unlawful or malicious acts or could have cross-border impact. The output is a timestamped submission receipt and a copy of the early warning stored in the incident file.
Notify the authority with the incident assessment
Following the early warning, the operator sends an incident notification that updates the authority with a more detailed assessment, including severity, impact and indicators of compromise where they are known. Article 23 sets this notification as the next stage of the sequence. The content should be accurate and marked as preliminary where facts are still being established, and any change from the early warning should be explained. The output is a second dated submission that reflects the current understanding of the incident and a log of what changed since the early warning.
Inform affected service recipients where required
Where the incident is likely to adversely affect the provision of the operator's services, Article 23 requires the operator to inform the service recipients without undue delay. For a transport operator, these may be passengers, freight customers, port users or other businesses relying on the service. The notice should describe the impact, the steps taken and any measures recipients can take themselves, and it should be issued through channels the operator has agreed in advance. The output is a recorded notice to each affected group and a list of the channels used and the time each was sent.
Prepare and submit the final report
Within one month of the incident notification, the operator submits a final report to the competent authority. The report should cover a detailed description of the incident, its severity and impact, the likely type of threat or root cause, the mitigation measures applied and, where relevant, the cross-border impact. If the incident is still ongoing at that point, the operator submits a progress report and then a final report once it is resolved. The output is a final report with a root cause analysis and a list of corrective actions, linked to the incident file.
Close the file and feed lessons back
After the final report is accepted or the authority has no further questions, the operator closes the incident file and records the lessons learned against its risk-management measures. Findings should update the playbook, contact lists and the operator's supplier and continuity arrangements where they contributed to the incident. The output is a closed incident record, a dated list of corrective actions with owners, and a revised playbook version that the next exercise will test.
Who owns the controls, who prepares evidence, and who issues findings
The transport operator remains the regulated entity. Under NIS2 the obligations for risk management, incident reporting and supervisory cooperation attach to the operator, and the management body must approve and oversee the Article 21 measures under Article 20. Outsourcing a task never moves the accountability for it. The operator decides what is significant, what is reported and to whom, and which risks it accepts.
- Controls ownership: the operator defines the control set, assigns owners for operational technology and IT, and decides how physical and cyber measures fit together.
- Management body accountability: board or executive members approve the risk-management measures, oversee their implementation and complete the cybersecurity training that Article 20 requires.
- Reporting decisions: the operator's own incident response team makes the call on significance and submits the early warning, notification and final report within the deadlines in Article 23.
- Supplier oversight: the operator selects and monitors any implementation partner, managed provider or cloud service, and keeps the contracts and evidence for each.
- Regulator contact: the operator answers information requests and inspections from its competent authority.
Before engaging anyone, confirm with your national competent authority and any sector-specific rules which obligations apply to your subsector and where your reporting lines lead.
An implementation partner such as DeployOpen works inside the operator's environment to prepare the systems, documentation and evidence that the operator's controls depend on. Its role is technical and documentary. It can build and harden self-hosted open-source platforms, configure logging and backup, run security testing and write the procedures that show how controls operate. It does not decide the operator's risk appetite, does not sign off the operator's compliance position and does not issue any report or certificate.
- Systems preparation: deploying, configuring and hardening the platforms that support access control, monitoring, backup and patching, within the operator's own cloud accounts or data centers.
- Documentation and evidence: producing configuration baselines, procedures, test records and log exports that the operator can present to an assessor or supervisor.
- Testing: running application, infrastructure and incident-response exercises, then reporting the findings to the operator so it can decide on remediation.
- Fixed scope: the work is agreed in writing with defined deliverables, so the operator knows which controls the partner touched and which remain its own.
- Ongoing support: where the operator chooses, retainers cover upgrades, continuous testing and evidence refresh after the initial work.
Ask any partner to state in writing which deliverables it provides and which decisions stay with your management body.
The national competent authority supervises compliance with NIS2 and its transposition law. For essential entities, supervision happens before problems are found, through inspections, off-site supervision, security audits, ad hoc audits and security scans described in Article 32. For important entities, supervision is ex post and is triggered by evidence of non-compliance, as Article 33 provides. Where an authority or an independent body carries out a security audit, that body issues its own findings. NIS2 creates no certificate of compliance, so no document can be presented as an official NIS2 certification.
- Inspections and scans: the authority can inspect premises, request information and run security scans, and it sets the depth of those checks.
- Independent audits: security audits may be carried out by an independent body or by the authority itself, and the operator must cooperate with either.
- Findings and enforcement: the authority issues findings, sets remedial deadlines and can impose the administrative fines and measures set out in Articles 32 to 34.
- No certificate: an assessor's report describes what was tested, but it is not a NIS2 certificate, and vendors cannot grant one.
- Sector overlap: where a sector-specific EU act applies instead, a different authority may be the one that inspects you.
Confirm with your national authority which body audits transport operators in your country, how audits are scheduled and what evidence format it expects.
What a transport operator should have ready before an inspection
Transport operators under NIS2 are judged on evidence, not intent. The five items below connect the inventory, the Article 21 measures, the reporting path, the supplier base and management oversight, so that each one can be traced to the others during an inspection.
Asset and system inventory across OT and IT
Signalling, train control, vessel and port systems, flight operations and ticketing often run on separate networks that were never documented together. Build one inventory that lists operational technology and IT assets, their owners, locations, network zones and whether they support a service that is essential to the operator. Check it against your own environment by sampling a control room, a depot or a terminal and confirming that every connected device appears in the list. Ask whether vendor-maintained systems are included, because supervisors commonly look for them first.
Documented Article 21 risk-management measures
Supervisors expect a written set of measures that covers the ten minimum areas in Article 21(2), each tied to the systems in your inventory and to a named owner. For transport, the risk assessment should reflect safety-relevant operations as well as data protection. Confirm that each measure has a current status, a review date and a reference to the evidence that proves it runs. A policy that no one can connect to a system will not satisfy an inspector.
Incident response playbook with the 24-hour path
Article 23(4)(a) requires an early warning without undue delay and in any event within 24 hours of becoming aware of a significant incident. The playbook should show who decides that an incident is significant, who submits the early warning to the competent authority, which template is used and how the clock is recorded. Test the path with a tabletop exercise that includes out-of-hours shifts and the operational staff who see the first signs of an incident. Confirm with your national competent authority which portal and contact details apply.
Current supplier list with security criticality
Transport operators depend on maintenance contractors, signalling vendors, cloud hosts, telecom carriers and managed security providers. Keep a list that names each supplier, the service it provides, the systems it can reach, whether it has remote access and how its contract covers security and incident notification. Mark the suppliers whose failure would disrupt an essential service. Verify the list by comparing it with active remote access accounts and recent purchase orders, since gaps usually appear where a contractor was added outside procurement.
Evidence of management body oversight
Article 20 makes the management body responsible for approving and overseeing the risk-management measures, and it requires members to follow cybersecurity training. Prepare minutes that show the board reviewed the risk assessment, approved the measures and received incident and audit results, along with a record of training completed by each member. Check that the dates in these records match the dates on the policies they approved. Missing approval records are a common reason an otherwise sound programme is marked as weak.
Physical and cyber resilience link to CER
Operators identified as critical entities under the CER Directive are to be treated as essential entities under NIS2, and the two sets of authorities are expected to exchange information. Prepare a single register that records which assets are designated as critical under CER, how physical protection and cyber controls cover the same sites and which authority receives each report. Confirm your designation status with your national authority, because the answer determines which supervisory regime applies to you.
Questions transport operators ask about NIS2
Is a small rail or bus operator under the size cap still in scope for NIS2?
It depends on whether the operator is in an Annex I transport subsector and whether it exceeds the medium-sized enterprise ceilings. Article 2(1) brings in Annex I and II entities that qualify as medium-sized or larger and that provide services in the Union, so an operator at or below those ceilings is generally outside the general rule. Size-independent categories can still apply, and a national authority may designate an entity regardless of size. Confirm the headcount and turnover tests with your national transposition law and the NIS2 Directive text before deciding. Written scope from DeployOpen starts from the same determination, made with your legal team.
Does NIS2 or a sector-specific act govern a transport operator?
Sector-specific Union acts can displace NIS2 when they require cybersecurity risk-management measures or significant incident notification with at least equivalent effect. Under Article 4(1), the matching NIS2 supervision and enforcement provisions then do not apply to those entities. Aviation, maritime and rail rules each have their own status, so the answer differs by mode and by activity. Read the Article 4 text and the Commission guidelines on Article 4 with counsel. Ask your competent authority which regime supervises you, and get that answer in writing before any control work is scoped.
What drives the cost of NIS2 readiness for a transport operator?
DeployOpen does not publish a price list. A quote follows from written scope, and the main cost drivers are the number of systems in scope, the state of existing controls, the number of sites and operational technology networks, and how much evidence must be produced for the supervisor. Costs fall into one-time work such as gap analysis, architecture changes, hardening and documentation, and recurring work such as monitoring, testing, backups and upgrades, which are usually retainers. Ask any provider for an itemized quote that separates these, names who performs each task, and states assumptions about your environment.
How long does NIS2 readiness take for a transport operator?
No general duration applies because readiness depends on your starting point. The main factors are how mature your current security program is, how many networks and legacy systems must be covered, how quickly management approves policies, and whether reporting processes need building from scratch. Fixed-scope engagements agree deliverables and timelines in writing before work starts, so the schedule should follow the scope rather than a template. Ask for milestones tied to evidence, such as tested incident reporting and approved risk-management measures, and confirm how dependencies on your suppliers affect the plan.
Can a transport operator run NIS2 readiness in-house?
Yes, many operators can do part of the work in-house, especially governance, asset inventories and policy ownership. Management remains accountable for approving and overseeing the risk-management measures, so those decisions cannot be outsourced. Specialist work such as hardening self-hosted platforms, building monitoring, testing, and preparing evidence often benefits from outside help when internal teams are small or stretched. Decide which tasks you keep by listing each Article 21 measure, the owner, and the skills required, then compare that list against your team's capacity. An implementation partner prepares systems and evidence, while only an independent auditor or assessor issues reports.
What will a supervisor ask a transport operator to show?
A supervisor will ask for evidence that the Article 21 measures exist, are approved by management, and operate in practice. Typical requests include an asset and network inventory, a documented risk assessment, incident response and reporting procedures, backup and recovery test records, access control records, supplier security arrangements, and logs showing monitoring. Essential entities face inspections, security audits and scans under Article 32, while important entities are supervised after the fact under Article 33. Prepare an evidence index that maps each measure to where its proof lives, and confirm with your authority which formats it accepts.
Where an implementation partner fits in a transport NIS2 program
An implementation partner prepares the systems and evidence that a transport operator needs for the Article 21 measures and the reporting playbook, but the operator keeps ownership of its controls, its risk decisions and its regulator relationship. In practice, fixed-scope work for a transport entity tends to cover hardening of operational technology and IT systems that support timetabling, booking, ticketing, traffic management or vessel and fleet tracking, along with centralized logging, tested backups, access control configuration and the written procedures that show how those systems are run. Scope, deliverables and timelines should be agreed in writing before work starts, and the operator should ask the partner to list each Article 21(2) area it touches, the systems in each area, and the evidence each one produces.
The reporting side is where transport operators most often find gaps. A useful partner scope includes a reporting playbook that maps who classifies a significant incident, who drafts the 24-hour early warning, and how the operator's assets, logs and timestamps are preserved so that the 72-hour notification and one-month final report can be written from facts. Confirm with your national competent authority which entity types in your subsector are covered and which sector-specific rules may apply, because those answers decide which deadlines and templates you actually use. Where critical entity status under the CER Directive is in play, ask how the partner will keep physical resilience records and cyber records consistent for the same systems.
DeployOpen prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and only the competent national authority or an independent body it designates can assess compliance. Hiring a partner does not guarantee a supervisory outcome, and a clean technical build does not replace management approval of the measures under Article 20. Ask any provider to state in writing what it will deliver, what remains the operator's responsibility, and how the evidence will be handed over so that your own staff and auditors can test it without the partner present.
How DeployOpen scopes and prepares NIS2 evidence for transport operators
DeployOpen works on NIS2 for transport operators as an implementation partner: we help prepare systems, controls and evidence inside your own infrastructure. The organization keeps ownership of its controls, and only an independent auditor or competent authority assesses compliance.
How we scope
- We confirm which transport subsector and entity type applies, and whether a sector-specific EU act may displace NIS2 provisions.
- We record in writing which systems, operational technology links and third-party services fall inside the agreed scope.
- Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before any work starts.
How we build
- We implement and harden self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks.
- We configure logging, access control, backup and incident workflow tooling so that the records a supervisor would request already exist.
- We run security testing against the in-scope systems and document findings and remediation status for the risk-management file.
How we hand over
- We deliver the documentation, configuration baselines and evidence set agreed in the written scope, mapped to the Article 21 measures.
- We walk your security and operations staff through the reporting procedure for the 24-hour, 72-hour and one-month deadlines.
- Your management body and named owners receive the handover pack, and they decide which residual risks to accept.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can cover platform patching, backup restore checks and periodic evidence refresh ahead of supervisory or audit requests.
- Before engaging, ask us to confirm in writing which authority, sector rules and auditor requirements apply to your entity.
