Should You Audit Your Own Technical Documentation?
A common dilemma in a world where we’re all busy, and there is already a demanding QMS audit schedule is:
“Does Technical Documentation need to be audited?”
”The Notified Body/UK Approved Body (NB)/(UKAB) audit it, so do we really need to?”
Thanks for reading The Other Consultants: MedTech Quality & Regulatory Insights! Subscribe for free to receive new posts and support my work.
Look, these questions are fair and the answer as always is it depends, right.
But, yes you should be auditing your technical documentation.
Many NBs/UKABs only give manufacturers three opportunities to effectively close Technical Documentation deficiencies before you are considered “failed review” and start all over again. In the grand scheme of the QMS, your technical documentation is absolutely worth spending some time on as it is a significant part of your passport to the market.
Many manufacturers stay away from it as the NB cover this, so everything should be fine. However, NB/UKAB reviews are a snapshot in time. They’ll check your documentation against the relevant regulatory requirements, but that doesn’t take away your responsibility to keep technical documentation complete, accurate, and integrated into your QMS. If you wait until the NB flags issues, you’re creating problems for yourself.
One thing that is extremely hard to account for with UKABs and NBs is the difference in review competency, personal preference and expectations. Some reviewers are really focused on biocompatibility, other reviews will raise deficiencies on your List of Applied Standards (LOAS), some will dig into your clinical data very deeply to understand whether the subjects match your target population.
Auditing your own technical documentation puts you in control. You can use this to put different specialities on the review, so one time you can get someone who has much more of an engineering focus, and next time perhaps more of a QMS person.
It means you find the gaps first, not the regulator - which is all that any regulatory body is looking for. That you know about gaps before they do.
When to Audit Technical Documentation
You don’t need to do a full-blown audit every month, but you should build technical documentation checks into your internal audit plan. Times to pay special attention include:
Before NB surveillance or FDA inspections
After design or intended use changes
When implementing new standards or guidance (e.g., ISO 14971:2019, MDCG docs)
In response to complaints, PMS/PMCF findings, or CAPAs
When new critical suppliers come on board and others have been terminated
If it is a device that has been on the market for some time (caution: Not necessarily a legacy device)
If you have several devices, you can base Technical Documentation audits on risk factors such as device classification, sales/usage or deficiencies previously raised.
Like any other audit in the audit schedule, it should consider the status and importance of the processes and area to be audited, as well as the results of previous audits.
Important note: Technical Documentation audits are not always standalone. You can weave it into larger system audits — for example, when you’re auditing design controls, risk management, or PMS, it makes sense to check that the outputs are properly captured and aligned in the technical documentation.
Who Should Audit the Technical Documentation?
This is where many companies are unfortunately their own undoing sometimes.
With the best intent in the world, if you want an audit to be effective, in line with clause 8.2.4 of ISO 13485:
The selection of auditors and conduct of audits shall ensure objectivity and impartiality of the audit process. Auditors shall not audit their own work.
Now that is pretty clear, so if you scheduled a Technical Documentation audit, and it is on your audit schedule, this really applies.
To really get the most out of Technical Documentation audits, the person conducting audits should have some distance from authoring, reviewing and approving the particular Technical Document at hand.
A few practical tips:
Use auditors who understand MDR/IVDR/FDA requirements but aren’t directly responsible for the product or file.
Always document auditor independence in your audit records. It shows you’ve thought about impartiality.
If your team is small and independence is impossible, bring in an external resource.
(And if that’s your situation — talk to me)…
How to Conduct a Technical Documentation Audit?
Here are the areas I always recommend focusing on:
Intended Purpose: Is it consistent throughout the Technical Documentation?
List of Applied Standards: Is this up to date with everything recent?
Traceability: Can you follow the chain from design inputs → outputs → risk controls → verification/validation evidence?
GSPR compliance: Is every requirement supported by clear and current evidence?
Clinical/Performance evaluation: Is it up to date, device-specific, and linked with PMS/PMCF?
Risk management: Are residual risks justified, monitored post-market, and consistent with clinical data? Does the RMF evolve with complaints and PMS or is it standalone?
Labeling and IFU: Do they match the claims in the file? Is UDI and symbol use compliant?
EUDAMED Registration: Is the device registered in EUDAMED?
Manufacturing validations: Are sterilization and packaging validations still current and device-specific?
Software and cybersecurity (if relevant): Do you meet IEC 62304 and current cybersecurity expectations?
PMS/PSUR/PMPF - Are plans available and in place, in line with the requirements?
Common Gaps I See
Hazard analysis’ in risk management that don’t effectively consider the introduction of hazards as a result of risk controls
Poor clarification and justification on the “lifetime” of a device - simply saying 10 years without substantiating material degradation, or servicing etc.,
Lack of effective usage data for PSURs
Outdated references in the GSPR checklist
CERs that haven’t been properly updated with new PMS data
IFUs that say something different to the technical file
Contraindications, warnings, claims or side-effects that appear to come from nowhere as opposed to resulting from clinical evaluation(s)
Lack of an assessment of the state of the art for therapeutic alternatives
PMS outputs that don’t feed back into risk or clinical
Best Practices
Build a checklist that follows MDR Annex II/III or FDA 21 CFR 820.181.
Use a risk-based approach — spend time where it matters most (high-risk devices, legacy files or those devices that change more (AI/SAMD)).
Involve the right functions (RA, QA, clinical, design, manufacturing).
Keep references current with the latest harmonized standards and MDCG guidance.
Document independence of the auditor every time.
And if you don’t have anyone independent — get outside help.
Closing thoughts
Auditing technical documentation isn’t about duplicating the notified bodies work. It’s about staying in control, catching problems early, and showing regulators and management that you’re serious about compliance.
As I said earlier, you only get around 3 chances to close technical documentation deficiencies, so if you fail these rounds, and don’t have adequate time for a fresh submission, you may all of a sudden be faced with a device that can’t be placed on the market.
If your team doesn’t have someone independent to audit your technical documentation, reach out to The Other Auditors. We can provide experienced, independent reviews that keep you ahead of your NB/UKAB, reduce audit findings, and give you the confidence that your files are truly inspection-ready.