NIS2 relevant suppliers:
the ACN tightening on subcontractors and intra-group

What happened on 18 May

On 18 May 2026, ACN (Italy’s National Cybersecurity Agency) published a second block of FAQs — FRN.5 to FRN.10 — on the listing of relevant suppliers introduced by determination 127437/2026. The first four FAQs (FRN.1 – FRN.4) had been released in April; this new block deals with more specific and less intuitive scenarios: foreign suppliers, foreign branches of Italian NIS entities, subcontractors, intermediated supply chains, intra-group relationships and the technical handling of CPV codes.

The operational milestone is 31 May 2026: by that date essential and important entities must complete the annual update of information on the ACN platform. It sits alongside the categorization of activities and services required by determination 155238/2026, but it follows its own timing and logic.

FRN.8: the intermediated-supply knot

FAQ FRN.8 tackles the most common scenario in digital supplies: the contractual supplier (A) is not the same entity that actually delivers the service (B). Think of an organization buying SaaS licences through a local reseller, or an SME using cloud delivered by a partner that itself relies on a hyperscaler. Who must be listed as a relevant supplier? ACN distinguishes two configurations — and a third, hybrid one, that changes a lot of things.

• 1A is the contractor, B the subcontractor. When A holds the contract and uses B as a subcontractor, the general rule is to list A. The subcontractor B is also relevant only when its contribution is overt: a substantive assessment, not a numerical threshold. If B runs a critical component without which A’s service would not work, B must be listed; if B is a third-tier supplier that is fungible and replaceable, there is no need to list it separately.
• 2A is a commercial intermediary. If A is only a broker, distributor or reseller that facilitates the purchase (order, invoicing, contract) without playing any role in delivery, A’s relevance is marginal and you list B, the actual provider.
• 3The hybrid case: A also handles application management. If A, in addition to reselling B’s service, also manages the application layer — configuration, administration, essential technical support, integration with the customer’s systems — A is no longer a simple broker. In that case, both must be listed. This is a frequent pattern in «cloud + managed services» models and clearly changes the list to be filed.

For anyone compiling the list, the operational message is clear: contracts alone are not enough. For every relevant supply you must understand who actually delivers it, who manages it functionally and who would have administrative access to the systems. These questions involve three business functions: procurement (contractual structure), IT (technical architecture) and cyber security (impact on continuity).

FRN.9: intra-group suppliers are not exempt

FAQ FRN.9 answers a question that many corporate groups have preferred not to ask explicitly: must a subsidiary, a shared-services company or the parent that delivers ICT supplies to the NIS entity be listed as a relevant supplier? ACN’s answer is unambiguous: yes. Belonging to the same corporate group is not an exclusion criterion, and the assessment must be carried out using the same criteria applied to third-party suppliers.

In structured groups, several critical functions are usually centralized: data centres run by the parent, cloud governance handled by a shared-services company, an internal group SOC, pooled network infrastructure. If these supplies fall under Annex I, points 8 and 9, of Italian Legislative Decree 138/2024 (ICT categories) or if their disruption would significantly impact NIS operations, they must be listed even if the relationship sits within the consolidated perimeter.

Beyond filing the platform, this has a governance consequence: recognising an intra-group entity as a relevant supplier means governing it with the same tools used for third parties — SLAs, security contractual clauses, continuity plans, incident reporting flows, and assessments where needed. For many groups, it is the opportunity to formalise internal relationships so far regulated by informal arrangements based on the corporate hierarchy.

The methodological frame: BIA and TPRM

Reading the FAQ block as a whole, an implicit methodological message emerges: the list of relevant suppliers cannot be built with an administrative approach. It requires two tools that risk practitioners know well — Business Impact Analysis (BIA) and Third Party Risk Management (TPRM).

• BIA — Business Impact Analysis. Answers the question: what would be the impact on my NIS operations if this supplier stopped or was compromised? Without this analysis, you cannot tell a contractually important supplier from an operationally critical one. The two sets do not coincide.
• TPRM — Third Party Risk Management. Qualifies, monitors and governs suppliers based on the risk they introduce. A supplier identified by the BIA cannot remain in informal monitoring: it must be managed with periodic assessments, adequate contractual clauses, incident reporting flows and — where needed — shared continuity plans.
• Non-fungibility verified in practice. In its earlier FAQs, ACN had already clarified that a supplier’s non-fungibility must be assessed in operational reality: it is not enough that an alternative exists on the market, it must be activatable within timelines compatible with the continuity of the NIS service. A check that requires data, not perceptions.

The other FAQs in the block: FRN.5, FRN.6, FRN.7, FRN.10

FAQs FRN.8 and FRN.9 sit in the context of the other new ACN FAQs, which clarify recurring cases in real supply chains:

• 5FRN.5 — foreign suppliers. Foreign suppliers, including non-EU tech giants like US or Asian cloud providers, must be listed if they meet the relevance criteria. Nationality or size are not exclusion criteria.
• 6FRN.6 — foreign branches of Italian NIS entities. If a foreign branch is part of the Italian NIS entity, the supplies enabling its operations must still be considered.
• 7FRN.7 — subcontractors (general rule). The contractual supplier must be listed, with an additional assessment of the subcontractor when its contribution is overt. This is the rule that FRN.8 develops for concrete cases of intermediated supply.
• 10FRN.10 — multiple CPV codes. If the same supplier delivers services tied to several CPV codes (Common Procurement Vocabulary), a separate row must be entered for each code, repeating the supplier’s name. A technical clarification that avoids ambiguities during data collection.

What to do by 31 May

To reach the deadline with a defensible picture, we suggest a four-step path, optionally with the support of a specialist partner:

• 1Review the list already compiled in light of FRN.8. Are there listed suppliers that are actually only commercial intermediaries? Are there unlisted entities playing a relevant application or technical management role? The distinction between broker and functional manager is the real methodological shift introduced by the new FAQs.
• 2Map intra-group entities (FRN.9). Verify whether any group companies deliver ICT supplies or critical services to the NIS entity, applying the same relevance criteria used for third parties. An exercise that clears up technological dependencies that are often opaque.
• 3Check the correct association of CPV codes (FRN.10). For every supplier, verify that CPV codes are associated to the actual supplies, with the right level of granularity. If the same supplier delivers heterogeneous services (e.g. cloud + managed security) you need separate rows with the correct CPVs.
• 4Document your choices (even if not formally required). ACN does not formally require you to retain the reasoning behind every inclusion or exclusion, but doing so is a defensible governance practice: during inspections, audits or verification proceedings, having a trace of the reasoning is a tangible advantage compared to reconstructing it after the fact. Cybersecurity services.

How AtWorkStudio supports the mapping

AtWorkStudio works alongside SMEs and groups on the NIS2 path with a hands-on approach: we start with a security posture assessment based on NIST CSF 2.0, run the ICT supply-chain mapping using BIA and TPRM, support the filing on the ACN platform and integrate decisions into contracts and continuity plans. For clients that choose us as a qualified supplier, operating under ACN QC1 qualification for SaaS cloud services reduces the compliance friction on the client side.

We have been operating from Piacenza (Italy) since 2000. We are certified ISO/IEC 27001, 27017, 27018 and ISO 9001, ACN-qualified for SaaS cloud services, members of Clusit (Italian Association for Information Security) and associated with Confindustria Piacenza in the RICT cluster.