Product Integrity Spotlight: Data Centres

When nobody owns the whole system, who owns the evidence?

Product Integrity Spotlight examines how Product Integrity changes across major industries: where product evidence fragments, where responsibility crosses organisational boundaries, and whether existing governance can reconstruct the product account when it matters. Data Centres is the first report in the series.

On 15 July 2026, a three-millisecond voltage drop upstream of a regional data centre in the Netherlands triggered a sequence that disrupted Google Cloud services for almost fifteen hours.

Both utility feeds were affected.

One backup-power path transferred successfully. On the other side, a DRUPS failed to assume the load following electrical component failures.

A third equipment row then lost both redundant feeds after an overload-protection breaker tripped.

At almost the same time, a chiller controller dropped offline. The chilled-water pumps stopped and did not automatically restart. The redundant cooling source was unavailable because of known construction work at the facility.

Data-hall temperatures reached 44°C.

Equipment was shut down to protect it.

During recovery, pumps were manually switched from automatic to hand mode and an interim portable UPS was deployed to support the chiller controllers.

And one part of the account remained open. Google's published incident report said the overload conditions that caused the loss of power to Row 3 still required further investigation, with corrective investigation continuing into August.

This was not merely an equipment failure. It was a Product Integrity event.

The actual operating state was produced by electrical infrastructure, backup power, cooling equipment, controller behaviour, load deployment, temporary construction conditions, protection logic, software, human intervention and products controlled by different organisations.

And nobody manufactured the whole thing.

The designed system is not necessarily the system that exists

Data centres are designed around redundancy:

N+1. 2N. Independent feeds. Backup generation. Redundant cooling.

Those architectures are fundamental to resilience.

But an incident does not occur inside an architecture diagram. It occurs inside the system as it exists at that moment.

In the July event, a redundant cooling resource was unavailable because construction was under way. Pumps were later moved manually into hand mode. An interim UPS was introduced during recovery. Load deployment was relevant to a still-open part of the electrical failure sequence.

Those conditions were not peripheral to the system.

At that moment, they were the system.

That creates a different executive question: can the organisation reconstruct not merely what the facility was designed to be, but what it actually was when something happened?

Why data centres create an unusual Product Integrity problem

Four characteristics make the sector particularly revealing.

First, there is no single manufacturer of the complete facility. The operating environment combines utility infrastructure, switchgear, UPS and DRUPS equipment, batteries, cooling systems, pumps, controls, monitoring platforms, servers, storage, networking and software. Around them sit operators, colocation providers, OEMs, integrators, service organisations, utilities and customers.

Second, the evidence boundary can run directly through the failure path. Google's reporting describes engineers working with a third-party facility provider to restore power and cooling, while Google separately recovered infrastructure, workloads and services. The evidence explaining the facility condition and the evidence explaining the compute and service state were therefore held across organisational boundaries.

Third, configuration change is not an exceptional event. Loads move, capacity increases, software changes, control logic evolves, firmware is updated, equipment is replaced and customers continually reconfigure deployments. An original as-built record may remain historically accurate while no longer describing the system that is actually operating.

Fourth, construction and operation can coexist. Expansion and retrofit happen inside live environments. In the July incident, a redundancy resource that existed in the architecture was unavailable because construction was in progress.

That combination makes the Product Integrity problem more difficult than simple document control.

The question is not whether every individual activity has a process.

It is whether the combined operating state remains reconstructable.

The customer boundary is part of the system too

The July outage affected 24 private clouds belonging to 20 distinct VMware Engine customers. Nine Bare Metal Solution customers were affected, and all six relevant NetApp clusters were shut down as temperatures rose.

Those numbers make the boundary problem tangible.

The facility provider held part of the physical infrastructure state. Google held part of the compute, networking and service state. Customers held their own workload, architecture and resilience decisions.

The same physical event therefore existed simultaneously as a facility event, an equipment event, a cloud-platform event and a customer-operating event.

Each party could hold an accurate record.

No single record necessarily described the complete event.

Recovery becomes part of the future evidence record

Incident recovery creates another Product Integrity problem because recovery itself changes the system.

In July, pumps were moved from automatic to hand control. A portable UPS was introduced to support chiller controllers. Systems were restarted in controlled sequences while facility stability was being restored.

Those decisions were operationally necessary.

But after the incident, a different set of questions begins. How long did the pumps remain in hand mode? Who authorised the temporary configuration? Where was the portable UPS recorded? When was it removed? Which configuration documents were changed? Which risk assessment captured the temporary condition? Did every organisation holding part of the technical account update its own version of the system state?

A restored facility is not necessarily the same evidential state that existed before the event.

That distinction matters because the incident can end while the lifecycle history created by its recovery persists for years.

Everyone can control their part and still lose the whole account

A mature data-centre ecosystem can contain excellent functional controls.

The UPS manufacturer may maintain rigorous product records. The cooling supplier may preserve detailed service history. The operator may have extensive telemetry. Integrators may hold commissioning evidence. Software teams may preserve release histories. Customers hold workload configuration. Procurement holds supplier records. Cybersecurity teams hold vulnerability information.

Nothing in that picture needs to be negligent or unmanaged.

Yet a later investigation may still require somebody to connect those records across technical and organisational systems that were never designed to produce one common account.

That is evidence fragmentation.

The evidence exists, but proving that it belongs together becomes the investigation.

A court has already confronted the integration boundary

A US data-centre case shows why that distinction matters.

In Continental Casualty Co. v. Vertiv Services, Inc., No. 2:20-cv-4880 (S.D. Ohio, 6 September 2023), The Markley Group provided real estate, power and cooling for customers' computing equipment. It had purchased a UPS system from Vertiv. A capacitor manufactured by SBE formed part of that UPS.

The system later failed, causing what the court described as a thermal event. The heat triggered the facility's fire-prevention system, and water damaged the facility. The insurer brought claims including product-liability claims against Vertiv and SBE.

The court's treatment of SBE is especially interesting.

Vertiv had supplied SBE with the exact specifications for the capacitor, and a Vertiv engineer had overseen the design team that developed that type of capacitor. The claimant's own allegation was that the component was not properly rated for the completed system. The evidence did not establish that the component was independently defective outside that integration, and SBE had not substantially participated in designing or assembling the completed UPS. The component-parts doctrine therefore protected SBE from the relevant product-liability claims, while no party had sought summary judgment on the product-liability claims against Vertiv itself.

The alleged problem therefore sat at an important boundary:

component specification, component integration and finished-system design were not legally interchangeable.

That is a Product Integrity issue because defending the boundary depends upon evidence showing who specified what, who designed what and what contribution each economic actor actually made.

The contractual boundary sat somewhere else again. The same judgment held that SBE had a duty to indemnify Vertiv, including litigation costs, under their agreement. Tort exposure and contractual allocation therefore did not fall in exactly the same place. The court also rejected successor-liability claims against a later company that acquired certain SBE assets and intellectual property after SBE wound down.

This is US law and is not precedent for Directive (EU) 2024/2853. Its value is structural: a component sat inside a product, the product sat inside mission-critical infrastructure, and the event propagated into another protection system. Multiple parties held different parts of the technical and contractual story, and the court had to determine where those boundaries legally sat.

The revised European Directive draws its own component boundary.

Article 11(1)(f) allows a component manufacturer to escape liability where it proves that the defectiveness of the product into which its component was integrated or interconnected is attributable to the design of that product or to instructions given by that product's manufacturer.

That defence is itself evidential. Years later, the component manufacturer may need to prove what specification or instruction it received. The legal right can exist on paper; its practical value depends on whether the evidence still exists and can still be connected to the relevant product.

The PLD does not turn every data-centre outage into a liability claim

This limitation matters.

Directive (EU) 2024/2853 is not a general business-interruption regime.

Article 6 covers death and personal injury, specified property damage and destruction or corruption of data that are not used for professional purposes. Property used exclusively for professional purposes is excluded from that property-damage head.

That means the predominant consequences of a conventional commercial data-centre outage, such as downtime, interrupted business activity and professional-data loss, should not simply be described as PLD-compensable damage.

There is also a further Article 6 distinction relevant to integrated systems: damage to a product caused by a defective component integrated or interconnected with that product by its manufacturer, or within that manufacturer's control, is excluded from the relevant property-damage head.

The argument is therefore not that every future data-centre outage becomes a PLD case.

It does not.

The stronger point is that the products and software operating inside these facilities increasingly exist in exactly the long-lived, technically complex and multi-party environments where future questions of defectiveness, causation and economic-operator responsibility can be difficult to reconstruct.

Where qualifying damage does arise, the quality of that reconstruction matters.

The data centre is therefore useful not because it guarantees a PLD claim.

It is useful because it exposes the evidence architecture problem at extreme scale.

After 8 December: three different things can happen

The corrigendum to Directive (EU) 2024/2853, published as OJ L, 2026/90364, 7 May 2026, corrected the application provision so that the Directive applies to products placed on the market or put into service after 8 December 2026. In practical terms, the first newly placed or commissioned products inside that application boundary are those entering on 9 December 2026.

But not every later intervention has the same legal effect.

A repair or ordinary operation that does not amount to a substantial modification does not create the same position as a new product. Recital 39 makes clear that economic operators carrying out repairs or other operations that do not involve substantial modifications should not become liable under the Directive merely because of that work.

A substantial modification is different. Article 4(18) defines that concept by reference first to relevant Union or national product-safety rules and, where those provide no threshold, to changes concerning original performance, purpose, type and risk. Under Article 8(2), a person who substantially modifies a product outside the original manufacturer's control and subsequently makes it available on the market or puts it into service can be treated as a manufacturer of that product for the purposes of the Directive. Software updates or upgrades can also become relevant where the substantial-modification threshold is actually met.

And a genuinely new product entering the facility after the application boundary starts its own lifecycle inside the revised regime.

That distinction changes the data-centre accumulation argument.

A controller replacement, firmware release, battery intervention, UPS retrofit and complete new power system cannot safely be treated as legally equivalent.

The engineering and product-governance question is therefore not simply:

What changed?

It is also:

What kind of change was it?

That assessment may be made in engineering, quality, product management or operations.

Its consequences may later be legal.

The estate begins accumulating different evidence clocks

A facility operating in 2031 may contain original equipment from 2024, new products commissioned after December 2026, repairs that did not substantially modify a product, and products that may have undergone substantial modification.

Operationally, those assets continue to function as one connected environment.

Legally and evidentially, their histories may differ.

Article 17 establishes a ten-year expiry period running from placement on the market or putting into service, or from the relevant post-modification availability or putting into service of a substantially modified product. In cases where latency of personal injury prevents proceedings within ten years, that period can extend to twenty-five years.

Article 16 adds another dimension: its three-year limitation period does not begin until the injured person knew, or should reasonably have known, the damage, defectiveness and identity of the relevant economic operator that can be held liable.

In a multi-party infrastructure environment, identifying the relevant economic operator can itself require technical reconstruction.

The evidential horizon can therefore be much longer than the operational memory of the organisation.

People move. Suppliers change. Companies are acquired. Systems migrate. Software repositories change. Service providers disappear.

The physical facility remains.

That is why lifecycle evidence cannot be designed around the assumption that the people who made the decision will still be available when somebody eventually asks why it was made.

Software makes product state harder to freeze

The revised Directive includes software within its product framework.

That does not mean every cloud service or every data-centre application automatically becomes a defective-product claim.

But it means reconstruction does not necessarily stop when the hardware serial number has been identified.

A relevant product state may also involve firmware, controller logic, software version, update history, configuration and interconnected digital functionality.

The hardware can be identifiable while the state that determined its behaviour is not.

This is particularly important in facilities where software changes far more frequently than the physical infrastructure around it.

Article 9: disclosure can require more than finding a document

Article 9 addresses disclosure of relevant evidence.

Under Article 9(1), a claimant who presents facts and evidence sufficient to support the plausibility of a claim can seek disclosure of relevant evidence at the defendant's disposal. Article 9(2) provides a reciprocal mechanism for defendants in defined circumstances. Article 9(3) requires disclosure to remain necessary and proportionate, while the succeeding provisions protect legitimate interests including confidential information and trade secrets. Under Article 9(6), courts may require evidence to be presented in an accessible and understandable form where appropriate and proportionate.

Recital 42 contains the more consequential point for Product Integrity.

It expressly contemplates relevant evidence including documents that must be created ex novo by compiling or classifying evidence already available to the defendant.

That distinction matters.

A company can possess every underlying record and still be required to construct an intelligible joined account from them.

Record retention asks whether the information still exists. Evidence architecture asks whether the organisation can show how that information belongs together.

Article 9's proportionality controls matter too. They are an important protection against unreasonable disclosure burdens.

But they also create an uncomfortable governance question.

If compiling the relevant product account requires extraordinary effort because the evidence was never designed to connect, is that merely the cost of litigation, or evidence of an architecture that was never capable of explaining the product efficiently in the first place?

Article 10: fragmented evidence can change the procedural position

Article 10(1) preserves the fundamental rule: the claimant must prove defectiveness, damage and causal link.

The Directive does not create a universal reversal of the burden of proof.

It does, however, provide defined presumptions where specified conditions are met. Under Article 10(2)(a), defectiveness is presumed where a defendant fails to disclose relevant evidence in accordance with Article 9(1). Article 10 also contains presumptions connected to applicable safety requirements, obvious malfunction and defined causal circumstances.

Article 10(4) is particularly relevant to technically complex systems. Even after disclosure under Article 9, a national court is to apply specified presumptions where, taking all relevant circumstances into account, the claimant faces excessive difficulty because of technical or scientific complexity and demonstrates the likelihood required by that provision.

Disclosure therefore does not necessarily end the evidential problem; the records can be produced and the reconstruction can still remain technically difficult.

That is an important distinction for data centres.

Having evidence is not necessarily the same as having an explainable system account.

And Article 10(5) completes the balance: the defendant has the right to rebut the presumptions in Article 10(2), (3) and (4).

That defence again depends on evidence.

Business as usual may be the real risk

Data-centre leadership is understandably focused on growth: power availability, AI capacity, density, cooling, speed of deployment, capital efficiency and uptime.

Product Integrity rarely reaches the executive room with comparable revenue or margin numbers attached.

Instead, it appears to be a problem that somebody already owns.

Engineering controls engineering. Operations controls the facility. OEMs control their products. Service organisations control maintenance. Cybersecurity controls digital risk. Procurement manages suppliers. Legal manages disputes.

Each statement can be true.

The organisation can still be unable to reconstruct one material event across all of them.

That makes one particular message dangerous:

We already have this covered.

Without testing the joins, that statement describes confidence rather than capability.

Product Integrity cannot be demonstrated by adding a responsibility to a title, publishing a policy or pointing to an organisation chart.

It has to be demonstrated through evidence.

The 72-hour test

A better readiness test is to take a real material event and attempt to reconstruct it within 72 hours:

What exact equipment and component revision were present?
What software, firmware and control configuration were active?
What temporary condition or construction activity existed?
What had changed, and was it a repair, modification or substantial modification?
Who made the relevant decisions, and what evidence supported them?
What supplier, field or telemetry information existed beforehand?
Which organisation holds each part of the record?
Can those parts be connected into one defensible account of the system state?

The objective is not to force every record into one database.

It is to prove that the architecture can reliably reconstruct the account when required.

That is the difference between possessing records and possessing Product Integrity.

When Legal arrives, the history already exists

Legal becomes essential when a serious dispute arises.

But by that point, the engineering decisions have already been made. Supplier changes have occurred. Software has been released. Equipment has been serviced. Temporary configurations may have come and gone. People may have changed roles. IT platforms may have migrated.

Legal can use and challenge the evidence that exists. It cannot retrospectively create lifecycle connections that were never preserved.

The revised Directive makes that distinction more visible because disclosure, presumptions, component defences, expiry periods and economic-operator identification all depend upon the ability to demonstrate historical facts accurately.

Today's operational record can become tomorrow's liability evidence long after the business regarded the underlying decision as closed.

What is the industry really scaling?

The data-centre sector is scaling extraordinary capability.

More capacity means more revenue opportunity. Higher density enables new computing workloads. Cooling innovation allows facilities to support equipment that would previously have been impossible to operate economically. Automation increases efficiency. New suppliers and technologies expand what can be built.

But the evidence architecture scales too.

Every additional product creates another lifecycle. Every software layer creates another state history. Every supplier creates another evidence boundary. Every retrofit creates another decision record. Every temporary intervention creates another version of operating reality.

And every acquisition, service-provider change or system migration creates another opportunity for continuity to be lost.

After 8 December 2026, new products begin entering this ecosystem under the revised European Product Liability Directive while older products and infrastructure remain in service. Substantial modifications can create their own legally relevant lifecycle points. Article 17 can make those histories consequential for ten years, or in defined latent-personal-injury cases considerably longer.

So the executive question is not simply:

Are we ready for the Product Liability Directive?

It is more difficult:

If a material event occurred here five years from now, could we reconstruct the exact operating state that existed when it happened, across equipment, software, configuration, construction, temporary intervention, suppliers and organisational boundaries?

Or would the reconstruction begin only after the incident?

A data centre can have world-class redundancy and still possess fragmented evidence.

The next layer of resilience may therefore have nothing to do with another generator, UPS or cooling loop.

It may be the ability to prove what the system actually was.

Next in Product Integrity Spotlight
Life Safety - how long-lived installed systems preserve, or lose, the evidence needed to explain what changed across decades of service, software, component and organisational change.

Editorial note: This article is published for general informational and analytical purposes. It does not constitute legal advice. Legal and regulatory obligations depend on the specific product, economic operator, jurisdiction and facts, and organisations should obtain appropriate legal advice where required.