“Is Your Platform Qualified?” Is the Wrong Question

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

These documents prove the platform was qualified at a point in time. They don’t prove it’s qualified right now. Between the last qualification report and today, the platform has had dozens of deployments, configuration changes, and infrastructure updates. Each one is an opportunity for drift.

Continuous compliance monitoring is the practice of verifying GxP platform validation status continuously rather than periodically. DnXT’s OQ Dashboard is how we do this for ourselves.

The Six Compliance Agents

The OQ Dashboard runs six automated agents, each responsible for a category of compliance checks:

1. Infrastructure Agent

Monitors Azure Container Apps health: container state, replica counts, resource usage, volume mount integrity. Detects issues like the “WorkLoad Profile Full” error that occurs when stale revisions consume all available resources — a real incident pattern we’ve experienced multiple times.

2. Security Agent

Checks authentication service health, authorization enforcement, and certificate expiry. Verifies that session management is working correctly across single-replica services (Publisher, authentication-service, and globalservices must run single-replica because they store session state in memory).

3. Data Integrity Agent

Verifies audit trail completeness and tenant isolation. Checks that the SHA-256 hash chain in audit records is unbroken. Confirms that TenantScopedQuery is enforcing mandatory tenant parameters on all database queries.

4. Performance Agent

Monitors response times, throughput, and error rates across services. Baseline comparison against known-good performance profiles to detect degradation before users notice it.

5. Deployment Agent

CI/CD gate enforcement. Verifies that deployed images match committed code (git hash comparison), that Docker images were built with --platform linux/amd64 (Azure requirement), and that pinned image tags haven’t been overridden.

6. Compliance Agent

The broadest agent, running eight daily checks:

  1. Quarterly re-qualification due — 14-day and 7-day alerts before the next quarterly OQ is required
  2. Annual revalidation due — 30-day alert before annual full validation
  3. Stale change request — flags unsigned deployments older than 30 days (change control gap)
  4. Open deviation — unresolved failures older than 14 days (compliance risk)
  5. Backup verification — alerts if no successful backup in the last 24 hours
  6. DR test tracking — alerts if the last disaster recovery test was more than 90 days ago
  7. SOC 2 control status — maps DnXT’s controls to SOC 2 Trust Service Criteria and reports coverage gaps
  8. Audit trail completeness — detects gaps exceeding 1 hour (which could indicate the audit service was down)

The OQ Framework: @OQTest Annotation

Beyond monitoring, we use a test qualification framework that links test cases to regulatory requirements:

  • Test case ID — unique identifier (e.g., OQ-TC-GS-001)
  • Linked requirement — which requirement this test validates (e.g., REQ-AUTH-001)
  • Expected behavior — testable statement of what should happen
  • Risk level — CRITICAL, HIGH, MEDIUM, LOW
  • Regulatory references — 21 CFR Part 11, EU Annex 11, etc.
  • Module — which service this covers (GlobalServices, Publisher, Reviewer, etc.)

The OQ extension for JUnit 5 generates audit-defensible reports: execution metadata (timing, duration), unique execution IDs, and a SHA-256 hash chain for report integrity. An auditor can verify that the test results haven’t been tampered with after generation.

What We Catch (Because That’s the Point)

Monitoring is only useful if it catches real issues. Some examples from our operational history:

  • Stale revision resource exhaustion — After deploying new revisions, old ones weren’t deactivated. Azure’s WorkLoad Profile reached capacity. The Infrastructure Agent detected the replica count pattern and flagged it before services started failing.
  • Audit trail gap — During a db-service redeployment, the audit service lost connectivity for approximately 45 minutes. The Compliance Agent detected the gap in audit timestamps. We identified the deployment window and documented it as a known gap in our compliance records.
  • Image tag override — A manual deployment used a tag that didn’t match the pinned production tag for db-service. The Deployment Agent flagged the mismatch. We rolled back before the inconsistency could affect data operations.

These aren’t catastrophic incidents. They’re the kind of drift that accumulates silently and shows up during audits. Continuous compliance monitoring catches them in days instead of quarters.

Honest Limitations

Transparency requires acknowledging what we haven’t finished:

  • Not all 8 daily checks are fully automated. The DR test tracking check, for example, currently relies on a manually updated timestamp rather than automated DR test execution. We plan to automate DR testing, but it’s not there yet.
  • Agent coverage isn’t uniform. The Infrastructure and Compliance agents are the most mature. The Performance agent has basic response time monitoring but doesn’t yet have comprehensive throughput baselines for all 29 services.
  • Monitoring doesn’t prevent incidents. It detects them faster. A misconfigured deployment will still happen — the dashboard shows you it happened within hours instead of at the next quarterly review.
  • Customer visibility is limited. Today, the OQ Dashboard is internal to DnXT. We plan a customer-facing read-only portal where tenants can see their qualification status, but it’s not available yet.

The shift from periodic to continuous GxP platform validation isn’t about being perfect. It’s about reducing the time between when something goes wrong and when you know about it. Periodic validation tells you the platform was qualified three months ago. Continuous monitoring tells you whether it’s qualified right now.

For Organizations Evaluating Platform Compliance

When you ask a vendor about their qualification status, consider asking:

  • “Can you show me your compliance status right now, or do you need to schedule a report?”
  • “How quickly do you detect infrastructure drift after a deployment?”
  • “What happens when a compliance check fails? Who is notified, and what’s the remediation SLA?”
  • “Can I see the audit trail for your last 5 deployments, including 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.