PLD 2024: Vulnerability management and CVE handling.

What "reasonable diligence" means, which timescales can be defended in court, what can and cannot be transferred to the client.

Fourth article in the series on the PLD 2024 and Italian software houses.

Epistemic note: a reconstruction of the text of the directive, applied to typical operating models. It is not legal advice.

In the first three articles of the series I mapped the structural shifts, the development scenarios and the ten-year timeline. Within that framework, in the second article, I introduced the three cross-cutting operational situations every software house faces during the decade of liability: what to do when a CVE emerges, what to do if the client refuses the patch, what to do if an open-source component is abandoned.

That introduction was about what to do. This article is about with what rigour, on what timescales, and how far it can be put into a contract. Three dimensions that decide whether a software house's CVE handling can be defended in court or is exposure built up without noticing.

The first dimension is the legal standard of "reasonable diligence" as a PLD parameter. It is not a stance, it is not "we did what we could": it is an objective standard that the judge reconstructs ex post on the basis of documented industry practice.

The second dimension is time. The directive does not give numbers. Practice does. And they are numbers that the emerging case law will use as a yardstick for diligence, regardless of what the software house would have liked to do.

The third dimension is the scope of what can be transferred. Part of the vulnerability management work can legitimately be placed on the client by contract. Part cannot, and a clause that tries to will not stand against the injured person in court. The boundary is in Art. 15 of the directive, and you need to know it before writing your next commercial offer.

"Reasonable diligence" is not "good will"

The manufacturer's exemption from liability under the PLD runs through two main articles of Directive 2024/2853. Article 11 sets out the cases in which the manufacturer is exempt — including, at point (e), the case where "the objective state of scientific and technical knowledge at the time when the product was placed on the market was not such that the defectiveness could be discovered", known in legal scholarship as the development risks defence. Article 10 governs the burden of proof: in PLD litigation there is a system of presumptions that helps the injured person, and it is the manufacturer that must prove it falls within one of the exemptions.

The point where Italian practice tends to go wrong is the concrete meaning of the term "reasonable diligence". It is not a figure of speech. It is an objective standard, which the judge can reconstruct ex post on the basis of documented industry practice. It means two things at once.

First: diligence is not what the manufacturer intended to do. It is what the manufacturer actually did, shown by documentary evidence. A software house that handles CVEs "carefully" with no documentary trace of the process has not handled CVEs — it has handled them in a way that cannot be proven, which for PLD purposes is the same as not having handled them.

Second: the level of diligence required is not the one the manufacturer considers proportionate to its own structure. It is the one that can be expected of a competent operator in the sector. A small Italian software house does not defend itself by showing it did what small Italian software houses do. It defends itself by showing it did what can reasonably be expected of anyone developing software in that market segment at European level, according to the available state of the art.

This distinction has direct practical consequences. If the software house's reference segment is immature in vulnerability management — as is the case for the Italian SME software development segment — reasonable diligence is not the segment average. It is the standard of practice available to a competent operator, which is significantly higher. The diligent software house is the one that exceeds the segment average, because the segment average sits structurally below the threshold for meeting PLD obligations.

The state of the art as a measurable parameter

The state of the art is not an abstract concept. It is built from recognisable operational frameworks and the public technical references the security sector adopts as current practice. For vulnerability management there are four families of reference that define the concrete standard.

ISO/IEC 27001:2022 includes specific controls on the subject. Control A.5.7 (Threat intelligence), new in the 2022 revision, requires information about security threats to be collected and analysed in a structured way. Control A.5.30 (ICT readiness for business continuity) requires the capacity to respond to security events to be maintained. Control A.8.8 (Management of technical vulnerabilities) is the specific reference: the manufacturer must identify the technical vulnerabilities of its systems, assess their risk, and take appropriate measures. A software house certified to ISO 27001:2022 has a strong documentary reference. A software house that is not certified can still show it follows equivalents, but it must have the process structured and tracked.

NIS2 (Directive (EU) 2022/2555), where applicable to the software house or its clients, sets specific obligations for cyber risk management and incident reporting. Even for software houses not directly subject to it, NIS2 helps build the state of the art because it defines practices that the European regulator has classed as the minimum standard for critical sectors.

CVSS (Common Vulnerability Scoring System), developed by FIRST, is the standard scoring system for vulnerabilities. Each CVE receives a CVSS score that measures its severity from 0.0 to 10.0. It is the reference the judge will use to establish whether a vulnerability was critical, high, medium or low at the time of publication.

The CISA Known Exploited Vulnerabilities (KEV) catalog, maintained by the US cybersecurity agency, lists the vulnerabilities for which active exploitation in the wild is documented. A CVE in the KEV catalog is not a theoretical vulnerability: it is one being actively exploited. Ignoring it for weeks is not management: it is knowing exposure. ENISA, the European Union Agency for Cybersecurity, publishes advisories and guidelines that serve as a parallel reference at European level.

These four references — ISO 27001:2022, NIS2, CVSS+KEV, ENISA — together build the state of the art of vulnerability management against which the judge will measure the software house's reasonable diligence. A software house that does not know them is not doing vulnerability management in the PLD-relevant sense. It is doing something else, which will be judged for what it is: the absence of a process.

Defensible timescales: how fast is "timely"

The directive does not quantify response times to vulnerabilities. Practice does. And the timescales practice considers defensible are drawn from the reference frameworks, calibrated by severity. They are worth making explicit, because they are the numbers the judge will reason with.

Four operational classes, based on the combination of CVSS score and KEV flag.

Class 1 — Critical, actively exploited. CVSS 9.0 or above, and the CVE is in the KEV catalog (documented active exploit). This is the most urgent scenario. The defensible timescales are: formal notification to the client within 24-48 hours of the CVE's publication, a technical mitigation (workaround, defensive configuration) made available within 7 days, patch applied within 30 days. A software house that handles a Class 1 scenario in two weeks with no interim mitigation is exposed. A software house that documents action within 48 hours with an audit trail can defend itself.

Class 2 — Critical or High. CVSS 7.0-8.9, or CVSS 9.0+ not in KEV. A serious vulnerability but with no documented active exploit. Timescales: notification to the client within 5 working days, patch available within 60-90 days depending on how complex the patch is to develop.

Class 3 — Medium. CVSS 4.0-6.9. Notification in the regular communication cycle (monthly or quarterly depending on the contract), patch in the scheduled maintenance cycle.

Class 4 — Low. CVSS below 4.0. Routine handling, documented in the same cycles as Class 3. PLD relevance is marginal, but a documentary trace is still required.

These classes are not rigid rules. They are indicative parameters that reflect practice in the security sector. Context can change them: a Class 3 CVE on a healthcare system in production may require Class 1 timescales; a Class 2 CVE on a component not exposed to the internet may tolerate longer ones. The point is not to apply the numbers as a table: the point is to have written parameters and to document adherence, or a reasoned deviation.

An essential note on documentation. Defensible timescales are defensible in court. That means the software house must be able to produce: when the CVE was published (date and source), when the internal assessment of its relevance to the client's system took place (date and person responsible), when the client was notified and what the notification said (formal, written), when the mitigation and the patch became available (and the related communication to the client), when they were actually applied (and, if the client refused, the refusal documented in writing). Without this documentary chain, the timescales cannot be proven. And if they cannot be proven, in court it is as if they had never been met.

What can legitimately be transferred to the client

Contractual freedom has room to move. Not all of the vulnerability management work has to be carried by the software house free of charge. Part of the work can legitimately be transferred to the client as a separate service, or as operations the client takes on with its own team.

The technical execution activities that follow the notification can be transferred to the client as a separate, paid service. Applying the patch in the client's environment, testing in production, rolling back in case of regressions, structured communication to the client's end users: these are delivery services, they have a specific cost, and they can be contracted. The distinction that matters is: the software house, as manufacturer, makes the patch and the technical instructions available; execution in the client's environment is a separate professional service, to be paid for if not covered by an active maintenance contract.

The informed decision not to apply the patch, with all its consequences, can be transferred to the client as a responsibility. A client that, after formal notification including severity, specific risk, window of vulnerability and an operational proposal, decides not to proceed with the patch takes on the risk of its own refusal. A software house that has documented the notification + obtained the formal refusal + (ideally) the client's countersignature accepting the risk has put itself in a position of exemption with respect to damage arising from the unpatched CVE. It is not automatic, but it is the necessary condition.

In specific scenarios, the operation of deploying patches can be transferred to the client. A frequent case in the enterprise market: the client has its own IT team that deploys patches in its own environments, according to its own change management procedures. This can be contracted, and in some cases it is necessary, because the software house has no operational access to the client's production environments. What is transferred is the operational deployment. The software house remains responsible for the upstream acts.

All these transfers are legitimate if they meet two conditions: they are written into the contract explicitly (not implied, not inferred from practice), and they do not go beyond the limit the directive places on contractual freedom.

What CANNOT be transferred to the client: Article 15

Article 15 of Directive 2024/2853 is the limit. It provides that the manufacturer's liability towards the injured person cannot be limited or excluded by contract, and that any clause to that effect is void. It is an old principle — it was already in the 1985 directive — but with the PLD 2024 it gains new weight because the scope of the product, and therefore of the manufacturer, has been extended to software.

Applied to vulnerability management: between the software house and the client, the parties can agree who pays for the delivery services (executing the patch, deploying, testing). Between the software house and the injured end consumer, the manufacturer remains the manufacturer. A clause stating that "CVE monitoring is the client's responsibility" or "assessing the relevance of vulnerabilities is the client's responsibility" or "notifying relevant CVEs to the end customer is the client's task" is a clause that tries to exclude acts of the manufacturer. It cannot be relied upon against the end consumer, and in court the manufacturer answers as if the clause did not exist.

Four acts of vulnerability management belong structurally to the manufacturer and cannot be transferred by contract.

The first is active CVE monitoring of the components of the product placed on the market. It is an act of post-market surveillance that the directive requires of the manufacturer as part of diligence. It cannot be offloaded onto the client — in many cases the client does not even have full technical visibility of the components incorporated.

The second is assessing the relevance of the CVE to the specific client installation. It is a technical assessment by the manufacturer, which knows the product, the architecture, the dependencies. A client does not have the elements to make this assessment, and a clause that requires it shifts onto the client a responsibility it cannot in practice discharge.

The third is the formal notification to the client, describing the specific risk, severity, time window, and mitigation options. It is an act of communication by the manufacturer to its own client, it is documentary, and it is the basis of any later defence of diligence.

The fourth is making the patch or the mitigation instructions available when technically possible. If the patch exists upstream (released by the component's vendor), the manufacturer makes it available to the client. If the patch has to be produced by the manufacturer itself (a fork, a custom component, its own integration), the manufacturer produces it within the timescales of the severity class. A clause stating that "the availability of patches depends on the manufacturer's discretion and is not an obligation" is a clause that excludes a structural act of the manufacturer. Unenforceable against the injured person.

The scope of what can be transferred, in other words, is operational delivery. The scope of what cannot be transferred is surveillance and structured communication. The distinction needs to be written into contracts so the separation is clear. Without it, you risk writing clauses you think are transfer clauses and are in fact exclusion clauses — void in court.

The case of the enterprise client with its own IT

The most frequent practical case where correctly contracting what can be transferred applies is the enterprise client with an internal IT team. The client has system administrators, a change management process, regulated maintenance windows, and wants to manage patch deployment internally.

The software house can make operational deployment the client's responsibility. But the structure of the process needs to be written carefully. The sequence that holds up is this.

The manufacturer keeps: continuous CVE monitoring of the product's components, a relevance assessment for every published CVE, formal notification to the client within the timescales of the severity class, and making available the patch or complete technical mitigation instructions (versions, dependencies, prerequisites, expected regression tests).

The client takes on: acknowledging the notification within a defined time, deploying the patch in its own maintenance windows, testing in the client environment, reporting the outcome to the manufacturer (patch applied, problems encountered, reasons for not applying it where relevant). The client can refuse deployment, but formally assumes the risk.

What is NOT written into this contract: that the client is responsible for monitoring, assessment or notification. These remain with the manufacturer. If the client has enough internal expertise to want raw monitoring data as well, this can be provided as additional information — but the formal monitoring, the act itself, belongs to the manufacturer.

In addition, there should be a clause ending maintenance in case the client systematically refuses patches. At some point, a manufacturer that keeps its liability active on a system the client does not update is building exposure it has no way of reducing. The correct clause provides that after N formal refusals (of Class 1 in particular), the manufacturer can declare active maintenance ended for that specific system, with formal notice and with the client assuming the residual risk. This is the contractual symmetry that protects the manufacturer from a structurally uncooperative client.

Three questions for the GM

First question: do you have an audit trail of the CVE process for the last 12 months? If the answer is no — if CVE handling is scattered across emails, conversations, informal decisions — your standard of diligence cannot be proven. In court, cannot be proven means does not exist.

Second question: do you have written timescale parameters by severity, and do you apply them? If the answer is no — if reaction times depend on developer availability, client pressure, overlap with other projects — the judge will reconstruct the timescales from the reference frameworks, not from your software house's intentions. And the reference frameworks are the numbers I set out above.

Third question: are your CVE clauses inside or outside Art. 15 PLD? If you don't know, they are probably outside. Reviewing Italian software houses' standard clauses against the Art. 15 criterion brings to light, in most cases, wording that tries to transfer the manufacturer's structural acts to the client. Those clauses do not protect. They can be declared void, and in court they leave the software house exposed as if the clauses did not exist.

Closing thought

Reasonable diligence is not a stance. It is a structured process, with set timescales, documented in an audit trail, and supported by contracts that respect the scope of Art. 15. Software houses that today handle CVEs as case-by-case reactions are building exposure that will only show itself over the following decade. Software houses that adopt a structured process and correct contracts come out of the PLD regime as operators that can defend themselves.

The operational level is the one covered in this article. The architectural level — how a system is designed so that vulnerability management is possible and traceable in production — is another matter, addressed by other voices in the European debate. The two levels meet in real projects: the architecture creates the conditions for exercising diligence, the operational process carries it out, the contracts define its scope. A software house that thinks it has only a technical problem, or only a legal problem, or only a process problem, is underestimating the scope. It has three at once, and the three talk to each other.

The next article in the series addresses the RACI as an internal governance tool for the software house: how much formally assigning responsibility to roles really protects, and how much is instead an illusion that dissolves in the first real PLD lawsuit.