The Visibility Gap, Part 4

The Visibility Gap is a four-part investigation into how product safety signals are detected, interpreted, escalated and made visible before harm occurs. This final part examines what organisations must build internally to close the gap.

Before information reaches regulators, public alerts, recall notices or product safety databases, it usually passes through a less visible system.

The organisation itself.

A customer complaint may remain a service issue. A warranty trend may remain a Quality issue. A software defect may remain an Engineering issue, while a cybersecurity observation stays within the security team.

Each label may be accurate.

The problem begins when no one recognises that the separate issues may be describing the same emerging risk.

Eventually, someone must decide whether the organisation is looking at something larger than any one function can see. That is the internal translation layer: the point at which fragmented signals become shared evidence, and shared evidence becomes an organisational decision.

A quality system is not automatically a visibility system.

Signals rarely arrive already labelled

Serious product safety issues do not always announce themselves through a fire, injury or confirmed dangerous product.

Many begin as fragments: a small number of complaints, a repeated repair trend, an unusual failure mode, a supplier deviation, an intermittent software anomaly or a pattern beginning to emerge in warranty data.

Each fragment may appear explainable on its own. One complaint lacks statistical weight. One field failure looks isolated. One software behaviour appears configuration-specific. One vulnerability is managed as a cybersecurity issue rather than a possible product safety concern.

The challenge is therefore not whether the organisation has information. It is whether the organisation can recognise when separate pieces of information are beginning to describe the same risk.

That requires more than data collection. It requires a mechanism for connecting information that arrives through different functions, systems and professional languages.

Customer Service sees complaints and customer behaviour. Field Service sees repairs and operating conditions. Quality sees nonconformities and trend data. Engineering sees design assumptions and failure modes. Cybersecurity sees vulnerabilities and exploitation paths. Regulatory sees notification thresholds, while Legal sees liability, evidence and privilege.

Each perspective is legitimate. None is complete.

Product safety authority should not be assumed to sit within Quality, Engineering, Regulatory or Legal by default. It must be assigned deliberately. Otherwise, interpretation may fall to whichever function has the strongest organisational voice, rather than the clearest view of the emerging risk.

The internal translation layer

The internal translation layer combines the processes, decision rights, escalation thresholds and governance routines through which an organisation determines what a signal means.

It must establish whether an issue is real, repeatable, isolated or systemic; whether the use was reasonably foreseeable; whether the risk is theoretical or demonstrated; and whether internal escalation, external notification or corrective action is required.

Those are necessary questions. They can also create delay when no one owns the answer.

Translation fails when signals are ignored, but it can also fail when they are over-discussed, under-owned, misclassified or held too long at the wrong organisational level. That second form of failure is often harder to detect because it can resemble diligence.

Consider how the same situation looks when the translation layer is working.

A connected product begins generating a small number of complaints after a software update. A designated reviewer notices that the complaints involve a safety-relevant function, repeated field observations and a recent product change. Those conditions meet the organisation’s defined escalation threshold and trigger cross-functional review within days rather than weeks.

Product Safety convenes Engineering, Quality, Cybersecurity, Regulatory and Customer Support. The team records what is known, identifies the missing evidence, assigns ownership of the technical investigation and agrees the conditions that would require further action.

The decision may still be to continue monitoring.

The difference is that the signal has been consciously assessed, the assumptions are documented and one accountable owner is responsible for revisiting the decision when new evidence appears.

Its purpose is to assemble the available evidence, identify what remains unknown and support a deliberate decision before uncertainty becomes delay. Some signals will still be judged not to constitute safety events.

Regulation is testing the same capability

This internal translation challenge is becoming more urgent because several regulatory regimes are testing the same organisational capability from different directions.

Under the General Product Safety Regulation, a manufacturer that considers or has reason to believe that a product it placed on the EU market is dangerous must take corrective action, inform consumers and notify the relevant market-surveillance authorities, under Article 9(8) and Article 9(9). Product-related accidents are separately reportable under Article 20. Article 27 establishes the Safety Business Gateway as the route through which those notifications are made.

From 11 September 2026, the Cyber Resilience Act reporting obligations require manufacturers of products with digital elements to notify actively exploited vulnerabilities and severe security incidents. The process includes an early warning within 24 hours, a fuller notification within 72 hours and subsequent final reporting within the applicable period.

Member States must transpose the revised Product Liability Directive by 9 December 2026. Following the corrigendum of 7 May 2026, the revised liability rules apply to products placed on the market or put into service after 8 December 2026. The Directive expressly treats software as a product and addresses software updates and related services within the liability framework. Operationally, that increases the importance of preserving evidence capable of explaining product decisions over time.

Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on 27 July 2026. Article 1(40)(b) moves the application of Annex III high-risk obligations to 2 December 2027 and Annex I high-risk obligations to 2 August 2028. Article 1(39)(b) separately inserts Article 111(4), requiring providers of AI systems, including general-purpose AI systems, that generate synthetic audio, image, video or text content and were placed on the market before 2 August 2026 to comply with Article 50(2) by 2 December 2026.

The dates changed. The underlying governance challenge did not. Organisations still need systems capable of connecting technical performance, monitoring evidence, risk management and human oversight across the lifecycle.

These regimes do not share the same scope, thresholds or reporting routes. But they increasingly test the same capability: whether an organisation can recognise when a fragment of information has become significant.

That is not a background trend. It is a calendar.

Organisations that treat each regime as an isolated compliance project may construct separate translation layers for Product Safety, Cybersecurity, AI Governance and Liability Readiness. Organisations that recognise the common capability can design one connected system that serves several legal, regulatory and governance needs.

What a mature translation layer looks like

Medical-device vigilance offers the clearest existing model.

It uses shared terminology, defined manufacturer assessment responsibilities and structured routes for incident reporting, field-safety corrective action, field-safety notices, trend reporting and periodic summary reporting. The current framework includes the mandatory MIR 7.3.1 manufacturer incident report form and supporting structured data files, alongside templates for field-safety corrective actions, field-safety notices, trend reports and periodic summary reports.

None of that removes judgement. What it removes is interpretive friction.

When terminology is shared, two functions describing the same event describe it the same way. When assessment responsibility is assigned in advance, no one has to negotiate ownership while the clock runs. When evidence fields are standard, the record of a decision is built during the decision rather than reconstructed afterwards.

The transferable lesson is that common language, explicit ownership, standard evidence fields and repeatable decision routes reduce the distance between detecting a signal and deciding what it means.

Why software makes translation harder

Software changes the internal translation problem because software-related risks do not behave like traditional manufacturing defects.

A physical defect may be visible, repeatable and traceable to a batch, process or supplier. A software issue may be intermittent, configuration-dependent, update-dependent or influenced by connectivity, data and external services.

It may also move between organisational categories. A vulnerability can begin as a cybersecurity issue and later reveal a foreseeable product safety consequence. A performance anomaly can appear to be a support issue until field data shows that it affects a safety-relevant function. A remote update may remove the immediate symptom before the organisation has established what happened and whether the same condition could return.

The investigation must therefore ask more than what failed. It must determine what the product did, what the user could reasonably expect it to do, what changed and whether that change could create foreseeable harm. It must also preserve enough evidence to reconstruct the decision later.

Software-related product safety requires translation by design, not translation by accident.

A quality system is not automatically a visibility system

Many organisations already operate mature quality systems, with complaint-handling procedures, corrective and preventive action processes, design controls, supplier-quality programmes, risk registers, audit schedules and management reviews.

Those systems are essential. But a process can be compliant and still fail to connect weak signals.

A complaint process may close individual cases without identifying a cross-market pattern. A CAPA system may correct a local issue without recognising systemic exposure. A software-change process may approve an update without assessing its product safety implications. A cybersecurity process may manage a vulnerability without connecting it to foreseeable physical harm.

Legal review may protect legitimate privilege while unintentionally slowing the movement of operational information. Management review may receive completed metrics without seeing unresolved uncertainty.

The failure does not necessarily occur inside any one process.

It occurs in the space between them.

That is why the existence of a quality system should not be confused with the existence of a visibility system. A visibility system asks whether information can move across functions, whether unresolved risk remains visible to leadership and whether the organisation can recognise a pattern before each component has independently become conclusive.

Evidence is part of the decision

The internal translation layer is also an evidence system.

When a product safety issue later becomes visible, scrutiny extends beyond whether the organisation acted to what it knew, when it knew it, how the information was interpreted and why a particular decision was made.

If the evidence trail is fragmented across Customer Service platforms, Quality systems, Engineering records, software tools, cybersecurity logs and Legal files, reconstructing the basis of the decision can become difficult.

Product safety governance therefore becomes a form of organisational memory.

A defensible decision record should show what signal was received, who assessed it, what evidence was available, what information was missing, what assumptions were made and why escalation, notification or corrective action was chosen or deferred.

Not every signal will become reportable. But every significant signal should leave a coherent decision trail.

By the time a product safety issue becomes public, the organisation may already be judged by the quality of decisions made much earlier.

What leadership must build

The internal translation layer is ultimately a leadership responsibility.

Leaders determine whether Product Safety has clear authority, whether Quality is involved early enough, whether Engineering can raise uncertainty without penalty and whether Cybersecurity is connected to product safety decision-making.

They also determine whether Legal is integrated without becoming the sole gatekeeper, whether commercial pressure can override caution and whether unresolved risks remain visible at the level where action can be authorised.

Readiness therefore requires more than knowing where to submit a notification. It requires clear escalation thresholds, cross-functional review, connected software and cybersecurity governance, documented decision-making and leadership visibility over unresolved risk.

The practical test is whether those arrangements answer five questions:

• Who owns the emerging signal?
• Which functions must review it?
• What threshold triggers escalation?
• Who can make the final decision?
• What evidence must be preserved?

Without explicit answers, ownership remains assumed, escalation becomes negotiable and evidence is assembled only after the event.

An organisation that waits to design its escalation path until the first ambiguous signal arrives has already lost the time required to interpret that signal well.

The internal translation layer reveals how the organisation behaves when facts are incomplete, risk is uncertain and the decision is inconvenient.

Final thought

The signals already exist.

They appear in complaints, service records, engineering investigations, supplier data, warranty claims, software logs, cybersecurity findings and post-market feedback.

The harder question is when an organisation decides those signals have become significant, and whether it can later demonstrate that the decision was considered rather than convenient.

That is where product safety governance stops being a compliance function and becomes a test of institutional character.

This concludes The Visibility Gap, a four-part investigation into how product safety signals are detected, interpreted, escalated and made visible before harm occurs.

The next Implementation Monitor continues the work, tracking the regulatory developments, implementation signals and executive decisions shaping product readiness across Europe. Subscribe to The Readiness Directive to receive the monthly Monitor and future investigations.

Earlier in the series

Part 1: What product safety reporting systems were designed to do

Part 2: From signal to alert

Part 3: What the public data shows, and what it still hides

Sources and references

Regulation (EU) 2023/988, General Product Safety Regulation

Regulation (EU) 2024/2847, Cyber Resilience Act

European Commission, Cyber Resilience Act reporting obligations

Directive (EU) 2024/2853, revised Product Liability Directive

Corrigendum to Directive (EU) 2024/2853, 7 May 2026 — OJ L, 2026/90364

Regulation (EU) 2024/1689, Artificial Intelligence Act

Regulation (EU) 2026/1744, Digital Omnibus on AI

European Commission, post-market surveillance and vigilance reporting forms