Short version: yes. Devices get CE marked and FDA cleared every year on technical files built entirely in Word and Excel, and no regulation anywhere names a tool. The honest answer is longer, because the regulations name outcomes instead: traceability, version control, approval evidence. Here is what it takes to meet them in Office, where that setup breaks down, and how to tell when it's time to move.
The most common QMS tool in small medical device companies is SharePoint. The second most common is SharePoint plus Excel. That's not a criticism; it's just what we see. When you're three people trying to get a product built and certified, evaluating compliance software is not where your head is, and the pricing of most serious tools assumes you already have revenue and an IT budget. So teams use what's on hand: a document library, a spreadsheet risk register, an email approval chain, held together with good intentions.
And it works. Regulators genuinely do not care what software your technical file lives in. Notified bodies review Word documents and Excel matrices every week, and they issue certificates against them.
But "can you" has two halves, and the second half is the one that costs money. The regulations don't name tools; they name outcomes. Every outcome they name is something Word and Excel can produce and none of them is something Word and Excel will maintain for you. The rest of this guide is that second half: what the rules actually ask for, what an Office-based file has to do to deliver it, the point where it stops delivering, and how to make the stay-or-switch call deliberately instead of having complexity make it for you.
Three sets of rules matter for most device companies, and none of them mentions software for authoring your file.
EU MDR defines the content of technical documentation in Annexes II and III, and adds one requirement about form: the documentation must be presented in a "clear, organised, readily searchable and unambiguous manner." Read that again from a reviewer's chair. Searchable and unambiguous is a property your file either has on the day of review or does not, whatever it was written in.
ISO 13485 is where the operational obligations live. Clause 4.2.4 requires documents to be reviewed and approved before use, revision status to be identifiable, current versions to be available where they're used, and obsolete ones to be kept from unintended use. Clause 4.2.5 requires records to stay legible, identifiable and retrievable for their retention period. And clause 4.1.6, the one small teams most often miss, requires documented validation of computer software used in the QMS. Your trace matrix with its lookup formulas is, formally, such software.
The FDA QMSR, in force since February 2026, incorporates ISO 13485 into US law, so the same obligations now carry on both sides of the Atlantic (we've written a separate guide to what changed under the QMSR). Design controls add the demand that ties everything together: requirements trace to risk controls, to verification and validation evidence, and to the released design.
Here is the honest how-to. If you run your technical file in Office, these six disciplines are what stand between you and the findings reviewers actually write. Every one of them is achievable with software you already own.
| Obligation | What it takes in Word and Excel |
|---|---|
| Document control | A master document register: every controlled document with its ID, title, current version and status. A naming convention that encodes ID and version. One agreed storage location, and a hard rule that copies in inboxes and desktop folders are not the document. |
| Approval evidence | A signature page or approval record for every controlled document: who approved, in what role, on what date. Wet ink on a printed page still works. If approvals happen by email, those emails are QMS records and need to be filed and retained like one. |
| Traceability | A trace matrix, usually in Excel: one row per requirement, linked by ID to its risk controls, design outputs and test evidence. The links are text in cells, so someone has to re-check them at every single change. |
| Change control | A change request record, an impact assessment that names every affected document, and re-review and re-approval of each one. The impact assessment is the hard part: nothing in the file system tells you what a change touches. |
| Record retention | Records legible and retrievable for the required period: under the MDR, at least ten years after the last device is placed on the market, fifteen for implantables. That outlives several laptops, a server migration and probably a few employees. |
| Software validation | Documented validation of the spreadsheets doing QMS work (ISO 13485, 4.1.6): the trace matrix, the risk scoring workbook. Proportionate to risk, but it has to exist, and reviewers have learned to ask for it. |
None of this is exotic. Teams run exactly this setup through certification, and if you're one of them, running it well is the whole game. But look at what every row has in common: a person, doing the connecting by hand, every time anything changes. The setup is free; the discipline is a part-time job. In practice it rests on one or two people who care, and it is exactly as strong as their busiest week.
The breaking point rarely announces itself. It usually arrives with growth: the product gets more complex, a few more people start editing documents, and suddenly the questions that used to have instant answers start taking real effort. Which version of the risk analysis is current? Who approved the change to the design spec, and when? Does requirement 4.2 still trace to a passing test?
Then one of three moments makes it visible.
Here is the part that deserves more honesty than it usually gets. Word and Excel are the cheapest option at the start and get more expensive every month, quietly, in maintenance hours and accumulated inconsistency. A dedicated system is the opposite: a real cost up front, then the bookkeeping happens by construction. The curves cross earlier than most teams expect, but that isn't even the trap.
The trap is when the switch happens. Teams almost never migrate on a calm quarter. They migrate when the pain becomes undeniable, and the pain becomes undeniable exactly when the stakes are highest: an audit on the calendar, a submission deadline approaching, the product at its most complex. Migrating then means rebuilding the register, re-importing requirements, reconstructing trace links and revalidating your process while the file is under active review. It's rebuilding a foundation while the house is already occupied.
Good compliance infrastructure, in whatever tool, is much easier to build early than to fix later. The version of this that hurts least is the one you choose on your own schedule.
An honest guide should be able to argue both directions, so here are the criteria we'd actually use.
The worst option is the one most teams actually take: drift. Staying without the discipline, moving without a plan, deciding by not deciding. If you stay, stay on purpose and run the six disciplines. If you'll need to move, move before the file is under review, not during.
Everything in section three still has to happen; that's fixed by the regulations. What a purpose-built system changes is who does the remembering.
Requirements, risks and tests stop being paragraphs in separate documents and become records that reference each other. Traceability stops being a cell someone updates and becomes a link that either exists or doesn't, so the matrix is a view of the data rather than a document about it. Versioning and approval evidence attach to every record by construction, and when a requirement changes, everything that depends on it is visibly affected instead of silently stale. The audit question that took an afternoon of archaeology becomes the click it always should have been.
In other words: the part of the job that made Word and Excel fragile, the manual synchronisation of things that ought to be connected, is the part that stops being a job at all. What that's worth depends on where you are on the curve from the last two sections. If you're three people in feasibility, possibly not much yet. If you recognised more than one bullet in the list above, probably more than you're currently paying in quiet maintenance hours.
If you're starting from zero either way, our step-by-step guide to your first technical file walks the structure itself, whatever tool you build it in.
Regulation (EU) 2017/745 (MDR), consolidated text - Annexes II and III (technical documentation), Article 10 (retention periods).
ISO 13485:2016, Medical devices - Quality management systems - clauses 4.1.6 (software validation), 4.2.4 (control of documents) and 4.2.5 (control of records).
FDA Quality Management System Regulation, final rule - 21 CFR Part 820 incorporating ISO 13485, in force 2 February 2026.
FDA guidance: Part 11, Electronic Records; Electronic Signatures - Scope and Application.
The Threeqa newsletter, once a month. New guides, product updates, and what we're learning about device documentation.
Threeqa keeps requirements, risks, tests and documents connected by construction, so a change in one place is visible everywhere and the audit answer is a click, not an afternoon. Book a 30-minute walkthrough against your own artifacts.