NIS2 Annex II, Section 3: 5 Compliance Priorities for Postal and Courier Operators Before Their First Incident Report

In December 2025, a DDoS attack by the pro-Russian group NoName057(16) knocked La Poste’s Colissimo parcel tracking portal offline for several days during peak Christmas season. [4] In January 2023, LockBit ransomware encrypted Royal Mail’s Heathrow sorting hub, halting all UK international exports for six weeks and costing £10 million in remediation. [3][7] In April 2026, attackers exfiltrated 468,000 customer records from CTT — Portugal’s national postal carrier — including parcel tracking numbers that map each package’s route from warehouse to doorstep. [5]

Each of these incidents would qualify as a “significant incident” under Article 23 of the NIS2 Directive, triggering a 24-hour early warning obligation for any EU-regulated postal or courier operator.

Postal and courier services entered the NIS2 scope for the first time under Annex II of the directive that took effect in October 2024. The sector generates approximately €79 billion in annual EU revenue and employs over 1.7 million people. Despite this scale, most operators approach NIS2 as a documentation exercise rather than a risk management programme calibrated to their specific operational environment.

This guide identifies five compliance priorities specific to postal and courier operations. Unlike generic Article 21 checklists, these priorities map directly to where postal sector incidents actually occur: parcel tracking systems, sorting facility automation, delivery apps, customs API integrations, and incident classification before the 24-hour Article 23 clock starts.

Who Does Annex II, Section 3 Cover? A Scope Decision Framework for Postal Operators

Annex II, Section 3 of the NIS2 Directive covers “postal service providers within the meaning of Article 2(1a) of Directive 97/67/EC, including providers of courier services.” [1] The cross-reference to Directive 97/67/EC — the EU Postal Services Directive — anchors the definition to the EU’s existing postal regulatory framework, meaning the NIS2 scope tracks the same operator definitions used by national postal regulators across member states.

What qualifies as a covered postal activity?

Coverage applies to operators providing at least one step in the postal delivery chain: clearance, sorting, transport, distribution, or pick-up services. [1] This deliberately broad formulation captures operators who do not run the full chain. A parcel sorting facility that subcontracts final delivery is covered. An automated parcel locker network handling pick-up is covered. A regional last-mile courier operating as a subcontractor to a national operator is covered — provided it meets the size threshold.

What is excluded: transport operations not connected to a postal delivery chain step. A road freight hauler moving pallets between factory and warehouse — with no clearance, sorting, or distribution function — falls outside Annex II, Section 3. [9]

Size thresholds: who must comply?

The default rule applies the EU’s standard SME threshold. Operators become Important Entities under NIS2 if they have 50 or more employees and annual turnover (or balance sheet total) of €10 million or more. [1][10] Smaller operators may still fall in scope if they are sole providers of a service critical to societal functions, but this is a narrow exception that requires verification with a qualified legal professional.

Two operator categories are typically in scope regardless of the threshold debate:

• Universal service providers (USPs) — national postal operators designated under EU law (Deutsche Post, La Poste, Poste Italiane, PostNL, and equivalents) — almost certainly qualify as Important Entities and may be classified as Essential Entities in certain member states depending on their systemic significance.
• Commercial courier services — DHL, DPD, GLS, UPS, FedEx operating in the EU — covered where they meet the size thresholds and perform at least one postal delivery chain function.

An important supervisory distinction

Important entities under NIS2 are subject to ex post supervision — regulators investigate after incidents occur, not before. [9] This does not reduce substantive obligations: auditors will examine your practices retrospectively when an incident occurs. Comprehensive documentation from day one is the defence.

Operator type	Qualifying activity	Size threshold	NIS2 status
National postal operator (USP)	Full postal chain	N/A (systemic importance)	Important Entity (possibly Essential)
Commercial courier (>50 staff, >€10M turnover)	Sorting + last-mile delivery	Meets threshold	Important Entity
Regional last-mile contractor	Pick-up + distribution	Meets threshold	Important Entity
Parcel locker network operator	Pick-up services	Meets threshold	Important Entity
Road freight hauler (no sorting or pick-up)	Transport only	—	Not covered
Small courier (<50 staff, <€10M)	Any postal step	Below threshold	Likely exempt (unless sole provider)

Article 23 Trigger — What Makes a Postal Sector Incident Significant, and the Penalty Exposure You Face

An incident becomes reportable under Article 23 of the NIS2 Directive when it meets either of two criteria [2]:

• (a) The incident “caused or is capable of causing severe operational disruption of services or financial loss for the entity”
• (b) The incident “affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage”

The phrase “capable of causing” is a deliberate expansion from NIS1, which required actual harm to materialise before an incident was reportable. [6] Under NIS2, ransomware detected and contained before it disrupts operations may still be reportable if it was capable of causing severe disruption. This matters in practice: the classification decision cannot wait for harm to confirm itself.

What does “significant” look like for a postal operator?

The directive provides no sector-specific numerical thresholds for postal services. [6] Member states set these in their national transposition legislation. In practice, you need an internal classification rubric before the first incident — not after it occurs.

Scenario	Criteria met	Likely significant?
Ransomware encrypts sorting hub systems (Royal Mail 2023 precedent)	(a) Severe operational disruption	Yes — report within 24h
DDoS takes parcel tracking portal offline for 3+ days during peak season (La Poste Dec 2025)	(a) + (b) — customers unable to track, deliveries cascaded	Yes
Data breach exposing 468K customer records + tracking codes (CTT Portugal 2026)	(b) Considerable non-material damage to persons	Yes — GDPR intersection also applies
Tracking API unavailable for 4 hours, 50,000 customers affected	(a)/(b) — borderline	Consult your national CSIRT
Phishing attack on staff accounts — all blocked, no data exfiltration confirmed	Neither criterion met if contained	Likely not — document for audit trail

The reporting clock and what it requires

Once you become “aware” of a significant incident [2]:

• Within 24 hours: File an early warning with your national CSIRT, indicating whether a malicious cause is suspected and whether cross-border impact is likely
• Within 72 hours: Submit a full incident notification with updated severity assessment and indicators of compromise
• Within 1 month: Deliver a final report covering root cause, applied mitigations, and cross-border impact

Penalty exposure and personal liability

Important entities that fail their NIS2 obligations face administrative fines of up to €7 million or 1.4% of global annual turnover, whichever is higher. [1] Under Article 20 of the directive, members of management bodies can be held personally liable for negligence in overseeing cybersecurity. This extends to CISOs, IT directors, and board members — not only to the organisation as a legal entity.

Priority 1: Classify Parcel Tracking Systems as Dual-Risk Infrastructure

Parcel tracking systems are the most distinctive risk asset class in the postal sector — and the most underweighted in generic NIS2 guidance.

Every tracking system holds two categories of sensitive data simultaneously: customer personal data (name, delivery address, phone number, email) and logistics routing data (origin facility, transit points, delivery agent identity, GPS timestamps). This dual nature makes tracking systems double the liability of a standard customer database. The La Poste DDoS in December 2025 specifically targeted the Colissimo tracking portal — because disrupting tracking disrupts customer trust, delivery coordination, and contractual service commitments at the same time. [4]

The CTT Portugal breach in April 2026 illustrates the dual-risk precisely. Attackers exfiltrated 468,000 customer records alongside parcel tracking numbers, which “can be used to retrieve the tracking history of the parcel.” [5] Armed with a recipient’s name, phone number, and accurate knowledge of a parcel’s current location, attackers can run convincing delivery-notification phishing campaigns — the kind that achieve high click rates because the message demonstrates real knowledge of the recipient’s package status.

What Article 21 requires for tracking systems

Under Article 21(2)(a), your risk analysis documentation must explicitly cover parcel tracking infrastructure — including the API endpoints that expose tracking data to customers, third-party logistics partners, and e-commerce platforms. [1] Under Article 21(2)(i), access control policies must specify who has administrator access to the tracking database, how credentials are managed, and what logging exists for privileged access. Under Article 21(2)(h), customer data within the tracking system must be encrypted in transit and at rest.

Practical actions

• Classify your parcel tracking platform as a high-criticality asset in the information asset register
• Map all external API integrations that receive tracking data (e-commerce platforms, delivery partners, customs systems)
• Implement field-level encryption for customer PII within the tracking database
• Audit admin access to tracking infrastructure: any admin account without MFA and role-based access control is an Article 21(2)(j) gap

Priority 2: Apply OT Security Principles to Sorting Facility Automation

Sorting facilities are the operational heart of postal networks — and they contain a class of assets that generic NIS2 guidance largely ignores: operational technology (OT).

Modern sorting facilities run barcode scanners, conveyor belt programmable logic controllers (PLCs), automated guided vehicles (AGVs), and warehouse management systems (WMS) — all networked, programmable, and increasingly integrated with corporate IT. These are not conventional IT assets, but they fall within Article 21(2)(e)’s requirement for “security in network and information systems acquisition, development and maintenance.” [1]

The Royal Mail LockBit attack in January 2023 demonstrates the consequence of inadequate OT/IT segmentation. Ransomware reached the Heathrow Worldwide Distribution Centre — a 25-acre facility handling virtually all of the UK’s international mail — and encrypted operational systems. Full export service was not restored until 21 February: six weeks after the attack. Remediation cost the parent company £10 million. [3][7]

The OT challenge specific to postal operations

Many sorting PLCs and barcode readers are 10 to 15 years old, run firmware that cannot be updated without vendor involvement, and were not designed for network exposure. [8] They cannot host endpoint detection agents. Patching requires taking the sorting line offline — which 24/7 postal operations make difficult or impossible during peak periods. This combination — networked but unpatched, integrated but unmonitored — is precisely the attack surface that Royal Mail’s £10 million remediation had to address.

Under Article 21(2)(c), operators must maintain business continuity plans including backup management. [1] For sorting facilities, this requires a documented manual sorting procedure: what happens operationally when the automated line goes offline? Most operators have informal fallbacks; NIS2 requires a written, tested procedure.

Practical actions

• Build an OT asset inventory for each sorting facility: PLC models, firmware versions, network connectivity status
• Implement network segmentation between sorting OT systems and corporate IT (separate VLANs, firewall rules, DMZ for any required integration points)
• Define a patching policy for OT assets — a documented annual review with justified deferrals satisfies Article 21(2)(e) better than no policy at all
• Document manual sorting fallback procedures as part of your business continuity plan under Article 21(2)(c)
• Run a tabletop exercise simulating sorting facility outage: at what point does manual capacity become overwhelmed, and what is the Article 23 reporting trigger?

Priority 3: Secure the Last-Mile Delivery App as an Article 21(2)(j) Asset

For postal operators running their own delivery networks, the last-mile delivery app is the least-scrutinised asset in the NIS2 scope — yet it operates on thousands of devices distributed entirely outside the corporate perimeter.

Delivery apps authenticate drivers, display daily route data, capture proof of delivery (including customer signatures and location photographs), and communicate in real time with central order management systems. Each driver’s mobile device is a network endpoint. If the app is compromised — through credential theft, an unpatched API vulnerability, or a malicious update — the attacker gains access to real-time route data, customer delivery addresses, and potentially the credentials the app uses to access backend systems.

Article 21(2)(j) requires “the use of multi-factor authentication or continuous authentication solutions, where appropriate.” [1] A driver app authenticating to backend systems with username and password alone is a straightforward Article 21(2)(j) gap. The “where appropriate” qualifier provides limited room: for a system handling customer personal data and connected to order management infrastructure, MFA is almost certainly appropriate.

Article 21(2)(e) extends to the mobile application itself: does your delivery app undergo regular security testing? Are third-party libraries tracked for known vulnerabilities? [1]

Practical actions

• Audit whether driver app authentication uses MFA — if not, assess whether single-factor is defensible under “where appropriate” or whether remediation is needed
• Implement mobile device management (MDM) for driver devices that handle customer delivery data
• Apply session timeout and re-authentication requirements to the delivery app (an unlocked device left in a vehicle is an open session)
• Include delivery app API endpoints in your vulnerability disclosure programme under Article 21(2)(e)
• Add phishing awareness for field delivery staff to your Article 21(2)(g) training programme — drivers receive high volumes of external email and are targeted by delivery notification phishing

Priority 4: Map Customs and Border Agency API Integrations as Article 21(2)(d) Supply Chain Risk

Article 21(2)(d) requires operators to address “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.” [1] For most sectors, this means mapping IT vendors and cloud providers. For international postal operators, it also means mapping something most NIS2 guides never mention: government agency API integrations.

International postal operators query customs systems, border agency databases, and address validation services as standard operational infrastructure. A courier processing EU cross-border parcels may query customs authority APIs at multiple points per parcel — checking commodity codes, import duties, restricted item classifications, and recipient identity. If those APIs become unavailable — through cyber attack, maintenance failure, or government system outage — the international delivery chain breaks. Under Article 21(2)(d), this is a supply chain dependency that must be documented and risk-assessed. [1]

The obligation applies even when the “supplier” is a government body. The directive’s language — “suppliers or service providers” — is not qualified by sector or ownership structure. Your contractual leverage over a national customs API is limited, but NIS2 still requires you to assess the risk, document your dependency, and plan a fallback procedure.

Practical actions

• Build a complete map of external API dependencies: customs authority integrations, address validation services, parcel management platform APIs, and delivery partner APIs
• Classify each dependency by criticality — if this API is unavailable for four hours, what is the operational and financial impact?
• For critical API dependencies, document fallback procedures (manual processing workflows, alternative data sources, escalation contacts with the API provider)
• Include API security requirements in contractual language with commercial suppliers, covering incident notification obligations, access controls, and vulnerability disclosure
• Coordinate with your data protection officer to verify that handling customs data complies with GDPR alongside NIS2 obligations

For a comprehensive implementation guide on building an Article 21(2)(d) programme, see our guide on NIS2 Supply Chain Security: Requirements and Implementation Guide.

Priority 5: Build Incident Detection and Classification Before Your Liability Deadline

The 24-hour early warning deadline under Article 23 runs from the moment you “become aware” of a significant incident. [2] This single phrase is the most consequential in the directive for postal operators — because what constitutes “becoming aware” determines when your clock starts.

Consider a SIEM alert that fires at 11pm on a Saturday: sorting facility network traffic is anomalous. Is this a significant incident? You have 24 hours from the moment you decide it is — but if your IT team does not escalate until Monday morning, that is already 36 hours. If no one has authority to make a classification decision outside business hours, the 24-hour window closes before your incident response process begins. Article 20 of the NIS2 Directive holds management bodies personally accountable for exactly this kind of organisational gap.

Three capabilities required before the first incident

Article 21(2)(b) requires documented incident handling policies and procedures. [1] For postal operators, three specific capabilities must exist and be tested before an incident occurs:

1. Detection coverage: Does your monitoring cover all five risk areas — tracking systems, sorting OT, delivery apps, supply chain API integrations, and corporate IT? A monitoring gap is a classification gap.
2. Classification decision tree: A written rubric mapping incident characteristics to a significance determination, with postal-specific scenarios for each infrastructure type.
3. Reporting procedure: A named individual responsible for contacting the national CSIRT; a template for the 24-hour early warning submission; a documented process for gathering indicators of compromise by hour 72.

The Saturday night ransomware tabletop

The most revealing exercise for postal operators is this: ransomware hits a sorting hub at 9pm on a Saturday. Work backwards through Article 23:

• Who decides this qualifies as significant, and under what authority?
• When does the 24-hour clock start — when the SIEM fires, when IT confirms malicious activity, or when the CISO is woken?
• What information can you assemble and submit within 24 hours? Do you have the national CSIRT contact saved?

Under Article 21(2)(f), operators must regularly assess the effectiveness of their cybersecurity risk-management measures. [1] An annual tabletop exercise simulating a sorting centre outage is the most relevant test for this sector. Run it. Log the gaps it reveals. Fix the gaps before the next run.

Incident type	Duration / scope	Data impact	Likely determination
Ransomware / system encryption at sorting facility	Any	Any	Significant — report within 24h
Parcel tracking portal DDoS / outage	>4 hours, >50K customers affected	None confirmed	Likely significant — consult CSIRT
Delivery app credential compromise with confirmed backend access	Any	Customer data	Significant
Data breach involving customer PII + tracking codes	N/A	Any volume	Significant — GDPR notification also required
Customs API unavailable (third-party outage)	>8 hours, international deliveries halted	None	Borderline — assess financial loss criterion
Phishing attack, staff accounts blocked, no exfiltration confirmed	N/A	None	Likely not significant — document for audit

Compliance Roadmap: Where to Start

With five priorities identified, sequencing matters. The order below reflects urgency, not effort level. Priority 5 — incident classification — is listed first because the Article 23 deadline is live in jurisdictions that have transposed NIS2, and the 24-hour clock does not wait for your risk assessment to complete.

Step	Action	Article reference	Effort
1	Confirm scope: 50+ employees and/or €10M+ turnover; postal chain activity verified	Art. 2	Low
2	Identify your national CSIRT and build the 24-hour early warning template	Art. 23	Low
3	Draft incident classification rubric with postal-specific scenarios	Art. 21(2)(b)	Low
4	Classify parcel tracking as high-criticality; audit admin access and encryption	Art. 21(2)(a), (i), (h)	Medium
5	Conduct OT asset inventory across sorting facilities	Art. 21(2)(e)	Medium
6	Audit last-mile delivery app authentication; implement MDM for driver devices	Art. 21(2)(j), (e)	Medium
7	Map all external API dependencies; classify by criticality and document fallbacks	Art. 21(2)(d)	Medium
8	Document manual BCP for sorting facility outage; run Saturday night tabletop	Art. 21(2)(c), (f)	High

NIS2 does not require perfect compliance on day one. It requires proportionate, documented risk management with evidence that the organisation has identified and is actively addressing its cybersecurity risks. [1] Steps 1–3 give you the minimum viable compliance posture while the technical controls are built out.

For a full breakdown of all ten Article 21 cybersecurity risk management measures, see our guide on NIS2 Requirements: The 10 Cybersecurity Risk Management Measures Explained.

Frequently Asked Questions

Does NIS2 apply to a courier that only does last-mile delivery with no sorting facility?

Yes, if you meet the size threshold (50+ employees, €10M+ turnover). Pick-up and distribution are qualifying postal chain steps under Annex II, Section 3. [1][9] The absence of a sorting facility reduces your OT risk profile but does not remove scope. Your obligations under Article 21 still apply, with particular weight on parcel tracking systems, delivery app security, and supply chain risk management.

What if my national government has not yet transposed NIS2?

The October 17, 2024 transposition deadline has passed. Several EU member states transposed late; some implementing regulations continue to be finalised. The directive’s obligations are legally effective in member states where transposition is complete. Verify your country’s implementation status with a qualified legal professional — as a directive rather than a regulation, NIS2 requires national transposition before it becomes directly enforceable in each jurisdiction.

Are postal operators subject to GDPR as well as NIS2 for data breaches?

Yes. GDPR and NIS2 are parallel, not alternative, frameworks. A breach involving customer personal data in a parcel tracking system may trigger both a 72-hour NIS2 incident notification to your national CSIRT (Article 23) and a 72-hour GDPR data breach notification to your national data protection authority (GDPR Article 33). The two bodies are typically different. Coordinate your response plan to cover both obligations simultaneously.

Does a DDoS attack against our tracking portal always qualify as significant?

Not automatically. The significance test asks whether the attack caused or was capable of causing severe operational disruption or considerable damage to others. [2] A brief DDoS affecting a small percentage of users for under an hour may not meet the threshold; a multi-day outage during peak season affecting hundreds of thousands of customers almost certainly does. The classification table in Priority 5 above provides guidance, but you need a pre-built decision rubric rather than a case-by-case determination made under pressure.

What is the difference between the NIS2 CSIRT notification and the GDPR DPA notification?

NIS2 notification goes to your national Computer Security Incident Response Team (CSIRT) and covers cybersecurity incidents affecting your network and information systems — whether or not personal data is involved. GDPR notification goes to your national data protection authority (DPA) and applies specifically when personal data is breached. Some incidents require both; some require only one. [1] Your incident response procedure should document the trigger conditions for each.

---

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. Directive (EU) 2022/2555 (NIS2 Directive) — EUR-Lex
2. “NIS2 Directive Article 23: Reporting Obligations” — nis-2-directive.com
3. “Royal Mail spent £10m on cyber measures after LockBit attack” — Computer Weekly
4. “Pro-Russian hackers claim attack on French postal service operator” — The Record
5. “CTT Data Breach” — Have I Been Pwned
6. ”Defining the reporting threshold for a cybersecurity incident under NIS” — Journal of Cybersecurity, Oxford Academic (tyad009/7160387)
7. “Royal Mail Ransomware Attack: Impact, Victims, Recovery” — Huntress
8. “NIS2 for Logistics and Transportation Requirements” — nFlo
9. “NIS2 directive requires postal providers to take measures on cybersecurity” — Cullen International
10. “NIS2 for Transport & Logistics — Guide 2026” — Plan Be Eco