Choosing an eQMS for ISO 13485: a buyer's checklist for device makers
What to test in a trial, what validation evidence to ask a supplier for, and how to protect your data on the way in and the way out when you choose an eQMS for ISO 13485.
You are a device manufacturer with somewhere between ten and two hundred people, an ISO 13485 certificate, and a quality system that lives in a shared drive, a few spreadsheets and a lot of goodwill. The last surveillance audit went fine, but it took two people a week to pull the evidence together, and the training matrix was out of date by the time it was printed. You have decided to look at an electronic quality management system. This article gives you a buyer's checklist for an eQMS under ISO 13485: what to test during a trial, how much validation the standard actually expects, what documentation to ask the supplier for, how to protect your data on the way in and on the way out, and how to move off paper without carrying the mess with you.
What ISO 13485 expects of the software itself
Before looking at any product, be clear about what the standard asks of the tool, because it shapes everything else.
Clause 4.1.6 of ISO 13485:2016 requires documented procedures for validating the application of computer software used in the quality management system. Validation happens before first use and, as appropriate, after changes to the software or its application, and the approach has to be proportionate to the risk associated with the use of the software. Records of that work must be kept. An eQMS sits squarely inside this clause: it will hold your controlled documents, your CAPA records and your training evidence.
Clause 4.2.4 (control of documents) and 4.2.5 (control of records) set the functional floor. Documents must be reviewed and approved before issue, changes identified, current revisions available at the point of use, and obsolete documents prevented from unintended use. Records must stay legible, identifiable and retrievable, and be kept for at least the lifetime of the device as you define it, and never less than two years from release. If you sell into the EU, Article 10(8) of the EU MDR (Regulation 2017/745) adds that technical documentation and the declaration of conformity must be available for at least 10 years after the last device is placed on the market, and 15 years for implantables. Your eQMS contract and your exit plan need to cover those periods, which will almost certainly outlast the contract itself.
Finally, a cloud eQMS is a purchased service, so clause 7.4 (purchasing) applies to the supplier just as it applies to a moulding house. You need documented criteria for evaluating and selecting them, and the controls you apply should be proportionate to the risk.
Run the trial on your own processes
Most demos show the happy path with sample data. A trial is worth something only if you run your own scenarios, with your own people, and try to break things. Pick three or four real events from the last year and replay them. The table below is a starting set.
| Area | What to try | What good looks like |
|---|---|---|
| Document control (4.2.4) | Revise an existing SOP: draft, review by two people, approve, set a future effective date | The old version stays effective until the new date, then is withdrawn from use automatically; the change reason and approvers are visible on the record |
| Document control | Ask someone to open an obsolete revision from a bookmarked link | They either cannot, or it is clearly marked as superseded |
| Training (6.2) | Make the SOP revision above effective | Everyone whose role requires that SOP gets a training task; the matrix shows who is overdue without a manual update |
| CAPA (8.5.2) | Raise a CAPA from a supplier nonconformity, record root cause, add actions with owners and due dates, then record an effectiveness check | You can show the whole chain in one place: trigger, investigation, actions, verification that the actions did not adversely affect the device's ability to meet requirements, and closure |
| Audit trail | Change a due date and a root-cause field, then look at the history | You can see who changed what, when, the old and new values, and the reason, without asking an administrator |
| E-signatures | Approve a document, then try to edit it | The signature shows the signer's name, date and time, and its meaning ("approved", "reviewed"); an edit after signing forces a new revision or invalidates the signature |
| Reporting | Produce the list of open CAPAs older than 90 days, and training completion for one department | It takes minutes and does not need a spreadsheet export to finish |
Two tests catch more weak systems than any other. The first is the effective-date handover: plenty of tools approve a document perfectly well and then leave both versions live. The second is the audit trail on a record you have edited several times. If the history shows only "record updated" with no field-level detail, your auditor will see the same thing.
Involve a document author, a CAPA owner on the shop floor and whoever runs internal audits. If the people who will use the system every day find it slow, they will work around it, and the workarounds are what turn up at audit.
How much validation is enough
Clause 4.1.6 says proportionate to risk, and that is the most useful phrase in it. A configured, commercial eQMS is a long way from bespoke software, and treating it like bespoke software produces binders of screenshots that nobody reads.
The GAMP 5 approach from ISPE is a sound way to structure the thinking even though it was written for pharmaceutical GxP systems. It classes most eQMS products as configured software (category 4), and its second edition (2022) puts weight on critical thinking and on making use of the supplier's own testing, rather than repeating it. In practice that gives you a validation pack along these lines:
- An intended-use statement: which ISO 13485 processes the system supports and which it does not.
- A short set of user requirements, written against your own processes.
- A risk assessment that marks which requirements could affect product quality, regulatory compliance or record integrity if they failed.
- Your own tests for the high-risk, configured parts: your document workflows, your approval routes, your CAPA states, your role permissions.
- A reliance statement for the rest, backed by supplier evidence you have actually reviewed.
- A validation summary report, and a procedure for assessing each new release.
That last point matters more than it used to. A cloud eQMS changes under you several times a year. Decide now how you will hear about releases, how you will assess their impact, and when a change triggers retesting. A release that alters the approval workflow needs testing; a new colour scheme does not.
What to ask the supplier for
Supplier evaluation under 7.4 needs evidence, and the supplier's answers are also the raw material for your reliance statement. Ask for these in writing:
- A description of their software development lifecycle and the quality system it runs under, with any certificates and their scope.
- Release notes for the last few releases, and their change-notification policy, including how much notice you get.
- A summary of their internal testing for core functions such as audit trail, electronic signatures and access control.
- A description of what the audit trail records and whether anyone, including their own administrators, can alter it.
- Hosting location, a list of subprocessors, and how they handle backups and restore testing.
- A recent independent security assessment summary.
- Their willingness to sign a quality agreement and to accept a supplier audit, remote or on site.
- Their documented exit process and the export formats they support.
Read the answers for specificity. A supplier who sends a two-line reply to item 4 has probably not thought about it. A supplier who sends a document describing exactly which events are logged, with sample output, has.
Data location, retention and exit
Ask where your data sits, including backups and support access. For UK and EU manufacturers, keeping quality records in the EU or UK simplifies your GDPR position and avoids awkward questions from customers who audit you in turn.
The harder question is exit. Your records must outlive the contract by years, and you need to be able to produce them for a notified body or competent authority long after you stop paying. During the trial, run an export and open it. Check that it includes:
- Every document revision, including the superseded ones, in a readable format.
- Attachments in their original file format.
- Audit trail entries and signature details (who signed, when, and what the signature meant) alongside the records they belong to.
- Training records with dates and the document revision each person was trained on.
If the export is a set of database tables that only the supplier can interpret, your records are only retrievable while the supplier exists and cooperates. Put the export format, the timescale for a full export at termination, and the date your data will be deleted into the contract.
Moving off paper and spreadsheets
The temptation is to migrate everything. Resist it. Moving fifteen years of superseded procedures and closed CAPAs into a new system costs a lot of time, adds validation work for the migration itself, and gives an auditor nothing they could not see in your existing archive.
A cleaner approach for most small and mid-sized manufacturers is to set a cut-over date and treat it like any other controlled change. Bring in current effective documents, each with a reference to its prior revision history in the old archive. Let open CAPAs and deviations close where they started, unless they are long-running, in which case migrate them with a note of their history to date. Load the current training matrix and the training status against current revisions, and keep historical training records in the archive. Check a sample of migrated records against the originals, record the check, and confirm nothing was altered in value or meaning on the way across.
Then protect the archive. The paper files and the old shared drive are still quality records under 4.2.5, with the same retention period. Make them read-only, record where they live, and add them to your records procedure.
Plan for a short hybrid period, and keep it short. Running two document systems in parallel for months is how the wrong revision ends up on the line.
The takeaway
The eQMS worth buying is the one that passes your own scenarios; the length of its feature list tells you very little. Test the effective-date handover, the field-level audit trail and the export before you sign; ask for evidence that lets you rely on the supplier's testing; and write the exit terms into the contract while you still have bargaining power. A system chosen this way will cost you less validation effort and hold up better at your next audit.
If you would like to put these scenarios to a system built for device manufacturers, the InnoQualis approach for medical devices covers document control, training, CAPA, deviations and internal audits with an append-only audit trail and EU hosting.
