3 Real Cases of Regulatory Control Failure — and How to Avoid Them

Regulatory failures rarely start with a warning letter, a rejected submission, or a failed audit. They usually start much earlier, with small assumptions, unclear ownership, or requirements that nobody realised they were responsible for.

The following cases are based on real patterns observed in audits, MDR reviews, and industry practice. The companies are anonymous and composite, but the situations are entirely realistic.

Case 1: The Requirement Nobody Owned

The situation

A mid-sized European manufacturer was preparing MDR certification for a Class IIb device.

The project was well organised:

• RA was responsible for the submission

• QA managed the QMS

• Clinical handled CER and PMCF

• Engineering handled design and risk

From a project perspective, everything looked under control.

The hidden flaw

The organisation had an Applicable Requirements List, but it was structured around departments rather than requirements.

Post-Market Surveillance (PMS) and PMCF were mentioned, but ownership was never explicitly defined.

RA assumed QA owned PMS implementation.

QA assumed RA owned interpretation of regulatory requirements.

No one owned the translation of the regulation into operational controls.

The moment it broke

During the notified body review, one question triggered the problem:

“Please demonstrate traceability between PMS requirements and implemented controls, including responsibilities, frequency, and outputs.”

The team produced SOPs and plans, but the links were unclear:

• PMS outputs were not clearly feeding risk management

• PMCF activities were not clearly linked to clinical evaluation updates

• Responsibilities were spread across procedures but not controlled centrally

The issue was not that activities did not exist.

The issue was that regulatory control was fragmented.

Impact

The review was paused.

The company spent months rebuilding PMS documentation and traceability.

The planned launch slipped by nearly a year.

How to avoid this

Regulatory requirements must be owned as requirements, not as departmental tasks.

That means:

• Assigning ownership at requirement level

• Maintaining traceability from requirement to control to evidence

• Verifying coverage before submission, not during review

Case 2: The Cybersecurity Gap That No One Saw

The situation

A manufacturer developed a connected medical device with mobile connectivity and cloud integration.

The device passed verification and validation. Risk management was complete. Software lifecycle documentation was in place.

From a traditional medical device perspective, the project was well executed.

The hidden flaw

Cybersecurity was treated as an IT matter rather than a regulatory requirement.

Engineering addressed software safety.

IT addressed infrastructure security.

QA maintained standard QMS procedures.

But no one systematically assessed cybersecurity expectations from a regulatory perspective.

There was no structured mapping of:

• Cybersecurity guidance

• Secure update requirements

• Vulnerability monitoring expectations

• Post-market cyber surveillance

The moment it broke

During technical documentation review, the assessor asked:

“How do you monitor vulnerabilities in software components once the product is on the market?”

There was no clear answer.

Processes existed informally, but they were not integrated into regulatory documentation or QMS controls.

What had seemed complete was suddenly incomplete.

Impact

The submission was placed on hold.

Additional procedures, documentation, and testing had to be developed.

Certification was delayed by several months.

How to avoid this

Regulatory scope is no longer limited to a single regulation or discipline.

Manufacturers need to:

• Treat cross-domain requirements as part of the regulatory baseline

• Identify applicable guidance and standards alongside regulations

• Ensure cybersecurity, data, and software obligations are integrated into compliance processes

Case 3: The Legacy Product That Drifted Out of Compliance

The situation

A company had a mature product that had been on the market for years.

The device was stable, complaints were low, and audits had always gone well. The regulatory baseline had been defined long ago and was considered “complete”.

The hidden flaw

The Applicable Requirements List was static.

Over time:

• Standards were updated

• Regulatory expectations evolved

• Documentation requirements expanded

But the regulatory baseline was not systematically reviewed or updated.

Changes were handled reactively, one at a time, without reassessing the full compliance scope.

The moment it broke

During preparation for recertification, the team realised that several expectations had changed:

• Clinical evidence requirements had increased

• PMS expectations had expanded

• Usability documentation requirements were stricter

The gap between current expectations and existing documentation was far larger than expected.

What had seemed like a routine recertification became a major remediation project.

Impact

Certification timelines slipped.

Resources were diverted from development projects.

Some markets were temporarily deprioritised.

How to avoid this

Regulatory baselines must be living structures, not static documents.

That means:

• Monitoring regulatory changes continuously

• Periodically reassessing applicability

• Linking change control to regulatory impact assessment

The Pattern Behind All Three Cases

Although the situations differ, the underlying causes are remarkably similar:

• Requirements were not fully identified

• Ownership was unclear

• Compliance scope was underestimated

• Regulatory control was reactive instead of systematic

None of these organisations intended to be non-compliant. They simply lacked a clear and continuously maintained view of what actually applied.

A Practical Lesson

Regulatory complexity is increasing across all domains:

• Clinical evidence

• Post-market surveillance

• Cybersecurity

• Data protection

• Environmental requirements

Managing this landscape manually or with static lists is becoming increasingly difficult.

The organisations that succeed are not necessarily those with the largest regulatory teams. They are those with the clearest regulatory control structures.

A Structural Perspective

Regulatory documentation can appear complete — while the underlying applicability structure remains fragmented.

We are currently opening early access to a structured regulatory operating system built around continuously maintained Applicable Lists, called Compliance Studio.

If you want to move from reactive remediation to defensible regulatory control, you can join the early access list below.