“Is Your Platform Qualified?” Is the Wrong Question

When a pharmaceutical company asks a vendor “is your platform qualified?”, they usually expect a PDF. An Installation Qualification protocol from last year. An Operational Qualification report from the original deployment. Perhaps a Performance Qualification summary from a load test.

Those documents prove the platform was qualified at a moment in time. They do not prove it is qualified now. Between that report and today there have been dozens of releases, configuration changes and infrastructure updates. Each one is an opportunity for things to drift.

Continuous compliance monitoring means checking GxP platform validation status continuously rather than periodically. Our Compliance Monitoring Dashboard is how we do that for ourselves.

Six Automated Checks, Running Continuously

The dashboard runs six automated monitors, each responsible for a category of compliance:

1. Infrastructure

Watches the health of the platform itself: what is running, how much capacity is in use, and whether stored information is intact. Catches problems such as old versions never being shut down and gradually consuming all available capacity — a pattern we have genuinely experienced more than once.

2. Security

Checks that sign-in is working, that permissions are being enforced, and that security certificates have not expired. Confirms sessions behave correctly across every part of the platform.

3. Data Integrity

Verifies that the audit trail is complete and that customers remain properly separated. Confirms that the chain of fingerprints protecting audit records is unbroken, and that every request for information is still restricted to the customer who asked.

4. Performance

Monitors response times and error rates, comparing them against known-good levels so that a slowdown is noticed before users feel it.

5. Release Control

Confirms that what is actually running matches what was approved and released, that it was built for the right environment, and that a deliberately fixed version has not been quietly replaced with something else.

6. Compliance

The broadest monitor, running eight checks every day:

  1. Re-qualification due — alerts at fourteen and seven days before the next quarterly qualification is required
  2. Annual revalidation due — a thirty-day warning before full annual validation
  3. Stale change request — flags releases that went out without a signature more than thirty days ago
  4. Open deviation — unresolved failures older than fourteen days
  5. Backup verification — alerts if there has been no successful backup in twenty-four hours
  6. Disaster recovery testing — alerts if the last test was more than ninety days ago
  7. SOC 2 control status — maps our controls to the SOC 2 criteria and reports any gaps
  8. Audit trail completeness — detects any gap longer than an hour, which would suggest audit recording was interrupted

Linking Every Test to Its Requirement

Beyond monitoring, every test we run is linked to the requirement it exists to prove:

  • A unique test reference for traceability
  • The requirement it validates
  • The expected behaviour, stated so it can actually be tested
  • A risk level — critical, high, medium or low
  • Regulatory references — 21 CFR Part 11, EU Annex 11, and so on
  • Which part of the platform it covers

Reports are generated with the timing of each run, a unique reference, and the same chain of fingerprints used elsewhere in the platform — so an auditor can confirm the results have not been altered after the fact.

What It Actually Catches

Monitoring is only worth anything if it catches real things. Some examples from our own history:

  • Capacity quietly running out. After releasing new versions, the old ones were not shut down and gradually consumed the available capacity. The infrastructure monitor spotted the pattern and flagged it before anything started failing.
  • A gap in the audit trail. During a planned update, audit recording lost connectivity for roughly forty-five minutes. The compliance monitor detected the gap. We identified the window and documented it as a known gap in our compliance records.
  • A version mismatch. A manual release used a version that did not match the one fixed for production. The release monitor flagged it, and we reverted before any inconsistency could affect anything.

None of these are catastrophes. They are the kind of drift that accumulates quietly and then surfaces during an audit. Continuous monitoring catches them in days rather than quarters.

Honest Limitations

Transparency requires acknowledging what is unfinished:

  • Not all eight daily checks are fully automatic. Disaster recovery tracking currently relies on a manually updated date rather than an automatically run test. We plan to automate it; we have not yet.
  • Coverage is uneven. The infrastructure and compliance monitors are the most mature. Performance monitoring covers response times but does not yet have complete baselines for every part of the platform.
  • Monitoring does not prevent problems. It finds them faster. A misconfigured release will still happen — the difference is learning about it within hours rather than at the next quarterly review.
  • Customers cannot see it yet. The dashboard is currently internal. We plan a read-only view where customers can see their own qualification status, but it is not available today.

The shift from periodic to continuous GxP platform validation is not about being perfect. It is about reducing the time between something going wrong and somebody knowing. A periodic report tells you the platform was qualified three months ago. Continuous monitoring tells you whether it is qualified right now.

For Organisations Evaluating a Vendor

When you ask about qualification status, consider also asking:

  • “Can you show me your compliance status right now, or do you need to schedule a report?”
  • “How quickly do you detect drift after a release?”
  • “What happens when a compliance check fails? Who is told, and how quickly must it be fixed?”
  • “Can I see the audit trail for your last five releases, including the change control documentation?”

This article was written by the DnXT Solutions team. We’ve tried to be transparent about both what we monitor and what we haven’t finished building. Questions welcome at se******@***********ns.com.