Where Your Out-of-the-Box eQMS is Probably Underbuilt
A few of the configuration gaps we see that cause compliance problems later, and where to close them.
We’ve been seeing a specific situation pretty regularly: a growing clinical-stage firm discovers that the eQMS it bought maybe two years ago doesn’t actually meet Part 11 requirements. The vendor oversold an underbuilt system, and there wasn’t anyone around to realize it.
But eventually, someone with systems and compliance experience finally takes a close look and the gaps are obvious. And even more worrying, they’ve been open the whole time.
The eQMS platforms themselves aren’t the whole problem here. Many of them work well enough. The problem is what happens during implementation. A small, early-stage team buys a system, installs whatever comes in the default configuration, and starts using it without doing any fit-for-purpose work. The salesperson's demo looked great, but it was in a developed environment. What you get out of the box is something different.
Here’s where most companies that are getting started with their first eQMS need to do work they haven’t done yet based on what we’re seeing in the field.
Audit trails
This is the one that in our exeerience creates the most regulatory exposure.
Part 11 requires that electronic records maintain a complete audit trail: who made a change, what was changed, when it happened, and why. Most eQMS platforms will tell you they support audit trails. Technically, some of them do. But “supports audit trails” and “produces Part 11-compliant audit trails in the default configuration” are different claims.
In practice, companies assume they have coverage because, again, the vendor said so during the sales process. When someone reviews what the system is actually tracking, the trail is either incomplete, logging the wrong events, or using a definition of “audit trail” that doesn’t match what a regulator expects.
We’ve seen companies go through quality reviews and find that their internal understanding of what counted as an audit trail had little relationship to the industry standard. If an investigator pulls a document and asks for the change history, you need to be able to produce a record that shows every modification, the user who made it, the timestamp, and the justification. If the system doesn’t generate that automatically, you don’t have what the regulation asks for.
Check whether the system tracks every change to every controlled document, including metadata.
Check whether the trail captures the user, the previous value, the new value, the timestamp, and the reason.
Try pulling a complete audit trail report for a document and reading it the way an inspector would. If the answer to any of those is “I think so” rather than “yes, here it is,” the configuration needs work.
Access controls
Most out-of-the-box configurations are too permissive. In practice, that usually looks like all (or at least too many) users in the system having the same level of access to modify a document title, change a form field label, rename a file, or overwrite metadata, etc.
We’ve seen eQMS implementations where a user could change “Due Date” to “Date Due” on a controlled form, and the system wouldn’t flag it, block it, or log it. Over time, small changes like that accumulate across hundreds of documents, and nobody notices until someone does a QC review and the records don’t match what the team remembers approving.
After configuration, the system should have tiered access.
Read-only users who can view documents but not change them.
Workflow-level users who can execute within defined processes.
Administrative users who can make structural changes.
Each tier should require training before access is granted. Higher tiers should require demonstrated competency within the system before permissions are upgraded.
If your eQMS has one access level for all users right now, fix that first. It’s the fastest path to a data integrity exposure you didn’t intend to create.
Document lifecycle workflows
The default document lifecycle in most eQMS platforms (especially “smaller” ones) is generic. It covers the basics (draft, review, approve, release), but usually doesn’t reflect how your organization actually manages documents.