Anyone leading a PMO at a mid-to-large Italian or EU-facing company has likely seen headlines about the Cyber Resilience Act, NIS2, and the 2026 obblighi (obligations). Most can't tell whether these rules apply directly to their role. The problem isn't a lack of information — it's fragmentation. The two regulations stem from different logics, target different subjects, and are often cited together imprecisely, as if they were interchangeable. For a PMO, the real stakes are the dati di progetto — budget, roadmap, risks, decisions — that live inside everyday project tools.
For those responsible for selecting and governing the tools that hold project data — budget, schedule, risks, and decisions — the real question is more concrete. Do these 2026 regulatory obligations touch the PMO software used every day, or do they stay confined to IT and product teams? Answering that requires separating two distinct perimeters before looking for points of overlap.
Two regulations, two different addressees
The Cyber Resilience Act obligates manufacturers, importers, and distributors of products with digital elements. This category explicitly includes standalone software, not just hardware or IoT devices (source: Agenda Digitale, Cyber Resilience Act, obblighi e scadenze per le aziende). It's a regulation aimed at those who produce and place software on the market — not at those who use it to manage projects.
NIS2 follows the opposite logic. It obligates essential and important entities operating in the 18 sectors identified by Italian Legislative Decree 138/2024. This designation comes from Agenda Digitale's overview of the directive (source: Agenda Digitale, NIS2, come adeguarsi ai nuovi obblighi cyber: i punti chiave). It does not target software vendors as such. It's an organizational regulation, imposing cyber risk management requirements and incident notification obligations on entities operating in critical sectors — energy, healthcare, transport, digital infrastructure, among others. These obligations apply regardless of which software the organization uses.
CRA and NIS2 target different subjects. The CRA covers software and hardware manufacturers. NIS2 covers essential and important organizations. Yet both converge on PMO tools, because these tools hold sensitive project data — budget, roadmap, risks, decisions. In 2026, the priority for a PMO isn't to 'become compliant.' It's to map which obligations fall on the PMO itself. Then map which fall on the software vendor. And which are passed down contractually along the supply chain.
Where the two perimeters intersect
The point of contact isn't regulatory in the strict sense — it's practical. A PMO tool that manages budget, schedule, risks, and decision logs handles data that, for a NIS2-covered entity, falls within the scope of organizational cyber risk management. And if that same tool is standalone software sold by a third-party vendor, that vendor may fall within the CRA's scope as a manufacturer of a product with digital elements.
A recurring line of reasoning among PMO teams goes something like this: 'The CRA is about IoT and hardware. NIS2 is about energy and healthcare. Our project management tool has nothing to do with it.' This isn't quantified in any public survey, but it remains a plausible and widespread pattern of thinking. It's an intuitive conclusion, but it rests on two incomplete premises. First, the CRA also covers standalone software. Second, NIS2's supply-chain clauses push essential and important entities to demand security guarantees from all their suppliers, including PMO tools. This holds even when the supplying company doesn't fall directly within the 18 regulated sectors.
This second mechanism — contractual propagation along the supply chain — is often the most underestimated. A company doesn't become a 'NIS2 entity' simply by selling to a regulated client. It can, however, still find itself having to meet specific security requirements imposed by contract, because its client is obligated to manage risk across its own suppliers too.
A three-level framework for mapping obligations
Before asking 'are we compliant?', a PMO leader should answer a simpler question: at which of the following three levels does the organization sit, with respect to each regulation? These three categories aren't mutually exclusive — a company can find itself at more than one level at once.
- Direct obligations of your own: does your company produce, import, or distribute software with digital elements (CRA)? Does it operate in one of the 18 NIS2 sectors as an essential or important entity?
- Obligations resting with your PMO software vendor: is the company that sells you the tool you use for budget, schedule, and risk the manufacturer subject to CRA obligations on that product?
- Obligations transferred by contract: is one of your clients a NIS2-covered entity that requires you, through a contract or a security questionnaire, to provide guarantees on the project data you share with them?
The CRA also sets out precise timelines that are worth distinguishing carefully so they aren't confused. Incident reporting obligations under Article 14 apply from September 11, 2026. These include an early warning within 24 hours, full notification within 72 hours, and a final report within 14 days for actively exploited vulnerabilities, or within one month for severe incidents. Full essential cybersecurity requirements, by contrast, only take effect from December 11, 2027 (source: ICT Security Magazine, Cyber Resilience Act obblighi 2026). These are two distinct deadlines, not interchangeable, and they cover different phases of the regulation's rollout.
The contractual propagation mechanism
The practical link between NIS2 and PMO tools almost never runs through a direct obligation, but through a contractual mechanism. Essential and important entities must manage cyber risk along their own supply chain. Operationally, this translates into concrete requests to suppliers: contractual clauses on data security, due-diligence questionnaires, notification obligations in case of an incident involving shared data. A supplier of services to a NIS2 entity does not itself become a 'NIS2 entity', but may still end up having to meet equivalent requirements through negotiation.
Illustrative simulation — Simulated scenario
An engineering firm providing R&D services to a client in the energy sector (a NIS2 essential entity) receives a security questionnaire from the client. The questionnaire asks which PMO tool is used to manage shared project data, how access to budget and roadmap is controlled, and what process exists to notify an incident involving that data. No regulation directly obligates the engineering firm as such, but the contract with the regulated client does. This is a constructed scenario for explanatory purposes, not a documented real case.
Practical steps for mapping in 2026
- Inventory all software tools that manage project data - budget, schedule, risks, decisions - and identify who is the manufacturer or supplier for CRA purposes.
- Check whether your company operates in one of the 18 NIS2 sectors identified by Legislative Decree 138/2024, or whether it supplies a client that does.
- Ask your PMO tool vendor for documentation on their CRA compliance path: vulnerability handling, notification process, product conformity declaration.
- Review contracts and security questionnaires received from NIS2-regulated clients, to understand which guarantees on project data are being requested contractually, independently of any direct regulatory obligation.
- Involve legal and compliance before externally declaring a 'compliance' status, distinguishing operational readiness from formal legal certification.
On the NIS2 side, some sources place full operability of incident-notification obligations in Italy (Legislative Decree 138/2024) at 1 January 2026. The same sources set the deadline for implementing baseline security measures for essential and important entities at 31 October 2026. These are specific deadlines derived from a 2024 decree. They require verification against the updated legal text before being treated as definitive (source: Agenda Digitale, NIS2, come adeguarsi ai nuovi obblighi cyber: i punti chiave).
The sanctions regime must also be kept distinct. NIS2 sanctions in Italy reach up to €10 million or 2% of global turnover for essential entities. For important entities, the cap drops to €7 million or 1.4% of turnover. This is a separate framework from the one set out under the CRA, and the two should not be cited interchangeably (source: Agenda Digitale, NIS2, come adeguarsi ai nuovi obblighi cyber: i punti chiave).
What this framework does not replace
Trade-off
- Benefit: Mapping the three levels of obligation allows for a timely, well-documented response to security questionnaires from regulated clients, instead of scrambling to answer last-minute requests without ready documentation.
- Cost: Requires coordination between the PMO, procurement, legal, and the software vendor, often without a budget explicitly allocated to this activity.
- Risk: Treating the mapping as a one-off exercise, without updating it as suppliers, contracts, or the client base change, produces a false sense of security.
- Prerequisite: A decision log and project-data traceability that are already structured, allowing documentation of who accessed what and when.
- Limit: No software tool determines or certifies legal compliance with the CRA or NIS2: that assessment remains the responsibility of the company's legal/compliance officer. ControlRoom, for example, deterministically centralizes budget, schedule, risks, and decision log with native audit trail. This kind of traceability can serve as useful material for a readiness analysis or for answering a security questionnaire. But it does not replace a legal assessment, and it does not calculate or attest to any compliance.
This framework covers exclusively the intersection between the CRA, NIS2, and PMO project data. It does not address the specific obligations of the EU AI Act of August 2026 for project management, nor ISO 42001 certification for AI governance. Nor does it cover AI decision traceability or the topic of hallucinations in reporting: these are distinct topics, covered in other dedicated articles in the cluster.
Before closing out 2026: three questions to ask
The three-tier framework helps you orient yourself, but a PMO leader doesn't need a complete compliance plan to get started. What's needed is answering, with the right subject-matter experts, a few concrete questions that close the loop between what has been mapped and what still needs verification.
- Can you identify, for every tool that handles project data, who the manufacturer or supplier is that may be subject to CRA obligations, and have you requested the relevant documentation?
- Have you checked whether your main client operates in one of the 18 NIS2 sectors identified under Italy's D.Lgs. 138/2024, and whether this translates into specific contractual clauses covering shared project data?
- Are your decision log and access traceability for budget, schedule and risk data well structured? Could you respond quickly to a security questionnaire without having to reconstruct everything after the fact?
- Is there a designated legal or compliance contact who validates any readiness statement before it is communicated to a client or included in a commercial proposal?
None of these questions require 'becoming compliant' in the sense of obtaining a certification. What they require is knowing, precisely, which of the three tiers - your own obligations, your supplier's obligations, or obligations transferred through contract - each part of your activity falls under. It also means having the documentation ready to demonstrate this when asked.
CRA and NIS2 will keep being cited together in the coming months, often imprecisely. For a PMO handling sensitive project data, the most concrete safeguard isn't chasing every regulatory headline. It's keeping the three-tier map described in this article up to date, revisiting it whenever software suppliers, contracts with regulated clients, or the scope of served sectors change.