From the notified body auditor perspective, an MDR audit is not a search for mistakes — it is a structured test of whether a manufacturer's quality system and technical documentation can defend the safety and performance of a specific device against Annex I and the rest of the Regulation. Auditors look for traceability, structure, and honesty first. Volume, polish, and confidence come last, and are often warning signs.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • From the notified body auditor perspective, the three things that matter most are traceability between requirements and evidence, the structure of the technical documentation, and whether the QMS described on paper matches what actually happens in the company.
  • Auditors are bound by MDR Article 52 and Annex VII, which set the rules for how conformity assessment bodies must operate, and by Annex IX when they run the full QMS and technical documentation assessment.
  • A three-person company in Lower Austria finished a first audit with zero nonconformities because every requirement traced cleanly to a document, and every document traced back to a specific clause of Annex I or Annex II.
  • The worst files auditors see are not thin — they are thick, disorganised, and structured around internal project history instead of Annex II. Auditors call this a "treasure hunt" and it is where nonconformities cluster.
  • Audits are not policing. They are a collaborative mechanism designed to produce safer medical devices. Founders who approach the audit as a shared problem get better audits.

Why the auditor's perspective is worth understanding

I started in this field with the sentence "How hard could it be to certify a medical device?" Fifteen years later, I know the answer, and I know it from both sides of the table. I am a Notified Body lead auditor, and I have founded four MedTech companies, including Flinn.ai. That combination is unusual. Most auditors have never sat in the founder's chair when the cash runs low and the certificate is late. Most founders have never sat in the auditor's chair at eight in the morning looking at a technical file for the first time and trying to figure out where Annex II section 2 lives.

Both perspectives matter because the audit is the single most expensive moment in your certification timeline when it goes wrong, and the single cheapest moment when it goes right. The difference between those two outcomes is almost never talent or budget. It is the degree to which the founder understood, in advance, what the person across the table is actually looking for.

This post is the view from that chair. Not what auditors are stereotyped to look for. What they actually do, in what order, and why.

What the auditor is legally required to check

Before anything else, the auditor is a professional operating under a legal framework. That framework is set out in MDR Article 52, which specifies the conformity assessment procedures available by device class, and in Annex VII, which lays down the requirements a notified body itself has to meet — independence, competence, procedures, personnel, and quality system. An auditor who deviates from those rules puts the notified body's designation at risk. This matters to you because it explains why audits feel rule-bound: they are. (Regulation (EU) 2017/745, Article 52; Annex VII.)

For most Class IIa, IIb, and III manufacturers, the conformity assessment route runs through Annex IX, which is the full quality management system and technical documentation assessment. Annex IX tells the auditor what to check and in what sequence: the QMS first, then a sample of technical documentation at a depth that depends on the class. Certificates issued at the end are governed by Article 56. Nothing the auditor does is improvised. Every finding must trace to a specific provision of the Regulation, a harmonised standard, or the manufacturer's own declared procedures. (Regulation (EU) 2017/745, Annex IX; Article 56.)

Practically, this means an auditor cannot write up a nonconformity because they "do not like" something. They write it up because a specific clause is not met. If you ever receive a finding that cannot be traced to a specific clause, you have the right, and in most notified bodies the encouragement, to ask for the clause. Good auditors welcome this question. It sharpens the finding or retires it.

What the auditor actually looks at first

The first thing I look at on any audit is not the technical file. It is the quality manual and the process map. I want to understand what the company claims to do, in which order, with which responsibilities, before I look at whether they did it. EN ISO 13485:2016 + A11:2021 gives the structure, and the manufacturer's own QMS gives the specifics. This is a ten- to twenty-minute read, and it sets the mental model for the entire rest of the audit.

Then I look at the design and development file, because that is where most of the risk lives. The question is not "do you have a design file?" — everybody has a design file. The question is: does the file let me trace a user need to a design input, a design input to a design output, a design output to a verification, and a verification to a validation, without losing the thread? If the trace holds, the audit gets easier. If the trace breaks, every following section becomes suspicious.

Then I look at risk management, because EN ISO 14971:2019 + A11:2021 is where the GSPR conversation lives in practice. I want to see risks identified, controls applied, residual risks evaluated, and — this is the part most startups skip — benefit-risk analysis done against the intended purpose. Annex I of the MDR requires this, and I read Annex I section 1 to section 8 with the risk file open next to it.

Only after these three anchors do I go into the rest of the technical documentation. By then I already know how disciplined the team is. The rest of the audit is mostly confirmation.

What good looks like: the Lower Austria three-person story

A few years ago I audited a three-person company in Lower Austria. First audit. Everyone on the team was wearing multiple hats — the CEO also ran the QMS, the engineer was also the PRRC, and the third person handled operations and administration. By conventional wisdom, this is a recipe for a rough audit.

It was the opposite. The technical documentation followed Annex II section by section. Every Annex II requirement was a named chapter. Every chapter had a short introduction explaining what was in it and why. Every claim was followed by a cross-reference to the evidence file that backed it. The risk file cross-referenced the design file, which cross-referenced the clinical evaluation, which cross-referenced the PMS plan. Nothing fancy. No bloat. Just clean, structured, honest work.

The audit finished with zero nonconformities. Three people outperformed organisations ten times their size. The reason had nothing to do with luck or leniency. The reason was that the documentation had been built for the auditor's mental model, not the internal project history. When I opened the file, I knew exactly where to look for everything, because the structure matched the Regulation. That is what good looks like, and it is achievable at any size.

What bad looks like: the treasure hunt file

The opposite of that experience is the file I sometimes call the treasure hunt. On paper it looks substantial — often hundreds of pages, sometimes more than a thousand. In practice the structure follows how the company built the product, not how Annex II is organised. The design inputs are in one folder, the clinical evaluation is in another, the risk management is in a third, and the links between them exist only in the head of the engineer who wrote them.

When an auditor opens a treasure hunt file, two things happen. First, the audit slows down dramatically, because every question requires the manufacturer to find the answer in real time. Second, the auditor's confidence in the overall file drops, because a structure that the author cannot navigate is a structure the author cannot have checked. The result is almost always a bundle of nonconformities, not because the underlying work was bad, but because the work could not be demonstrated in the time available.

The lesson from this pattern is blunt: more documentation is not more quality. I repeat this sentence in every startup engagement because it has to override a founder's instinct. Structure beats volume. A 250-page Annex II file that is logical and cross-referenced will pass where a 900-page file that is chronological and unlinked will fail.

What auditors wish more founders understood

Audits are not policing. They are about working together to produce safer medical devices. Founders who arrive defensive, who treat every question as an attack, and who try to "win" the audit, almost always get worse outcomes than founders who arrive calm, curious, and willing to say "we don't know yet, let us check." The auditor is not trying to catch you. The auditor is trying to produce a file they can defend in the internal notified body review that follows the audit.

This matters because the auditor's report is not the last step. Every finding, every sampled document, every decision is reviewed inside the notified body by a second reviewer. If the audit trail is weak, the reviewer sends it back. If it is strong, the certificate under Article 56 issues. The auditor's job is to build a defensible file, and your job is to make that easy. Those two jobs are not in conflict — they are the same job, viewed from two chairs.

Personally, I don't love the MDR. I love the challenge of overcoming it efficiently. The same is true of most auditors I know. The ones who last in this profession are not the ones who enjoy finding nonconformities. They are the ones who enjoy seeing a small team solve a hard regulatory problem with discipline and clarity.

Common mistakes that shape the auditor's first impression

  • Structuring the technical documentation around the product history instead of Annex II. The file should be readable by someone who has never met the product. If it isn't, the auditor is already suspicious before the first question.
  • Writing the QMS procedures to impress the auditor rather than to describe reality. If the procedure says something the team does not actually do, the process interviews will expose it within minutes, and the entire QMS section becomes doubtful.
  • Putting the PRRC, the QMS manager, and the CEO in a meeting where only the CEO speaks. Auditors learn more from what the engineers and the QMS lead know unprompted than from the CEO's polished summary. If the team cannot answer, the CEO's fluency becomes a red flag, not a comfort.
  • Confusing volume with rigour in the risk file. A risk file with 500 entries, most of which are copy-pasted or theoretical, tells the auditor that the team did not actually sit down and think. A risk file with 80 entries, each one specific and traced to a control, tells the auditor the opposite.
  • Hiding uncertainty. If the clinical evaluation has a gap, say so and explain the mitigation. Auditors respect this. Pretending the gap is not there invites a forensic reading of the entire clinical file.

The Subtract to Ship approach to the auditor's perspective

Subtract to Ship applied to the audit means: build the technical documentation and the QMS so that every single element traces to a specific MDR clause, and cut everything that does not. The test is the same test the auditor will apply. If a document cannot be traced to Annex I, Annex II, Annex IX, or EN ISO 13485:2016 + A11:2021, it is either in the wrong place in the file or it should not be there at all.

This is not laziness. It is alignment. You are writing the file for the audit. The audit is structured around the Regulation. Therefore the file should be structured around the Regulation. Everything else is noise that will cost you time in the room and confidence in the reviewer's office afterwards.

The subtraction move startups find hardest is cutting "nice to have" documents that were written in good faith but do not serve a specific clause. If it does not serve a clause, it dilutes the file. Remove it, or move it out of the technical documentation and into an internal engineering archive where it cannot confuse the auditor.

Reality Check — Where do you stand?

  1. If an auditor opened your technical file cold tomorrow morning, could they find the response to each GSPR in Annex I without asking a question?
  2. Does your technical documentation follow the structure of Annex II, or the structure of your internal project folders?
  3. For every sentence in your QMS procedures, is the described behaviour what actually happens in your company this week?
  4. Can every person with a role in the QMS answer basic questions about their role without the CEO stepping in?
  5. Is your risk file sized by the actual risks of the device, or by the apparent need to look thorough?
  6. Have you ever had someone outside your team read the technical file cold and tell you where they got lost?
  7. If the auditor asked you to trace a single design input from user need to post-market surveillance, could you do it in under five minutes?

Frequently Asked Questions

What do notified body auditors look for first in an MDR audit? The first two things I look at are the quality manual and the process map, because they tell me what the company claims to do. Then I look at the design and development file and the risk management file, because that is where most of the device risk lives. The rest of the audit is largely confirmation or correction of the picture formed in the first hour.

Are MDR audits adversarial? No. Audits are about working together to produce safer medical devices. A good auditor wants the manufacturer to succeed, because a certificate that can be defended under Article 56 is the shared goal. Founders who treat the audit as a fight almost always get worse outcomes than founders who treat it as a collaborative technical review.

Why do small, disciplined companies often outperform larger ones in first audits? Because the audit rewards traceability and honesty, not headcount. I have personally audited a three-person company in Lower Austria that finished a first MDR audit with zero nonconformities, while much larger organisations struggled on the same device class. Small teams with disciplined documentation beat large teams with sloppy documentation every time.

Is more documentation better during an audit? No. More documentation is not more quality. A 250-page technical file structured around Annex II will outperform a 900-page file structured around internal project history, because the auditor can navigate it. If the auditor cannot find your evidence, it might as well not exist.

Can an auditor write a nonconformity for something they "do not like"? No. Every nonconformity must trace to a specific clause of the MDR, a harmonised standard like EN ISO 13485:2016 + A11:2021 or EN ISO 14971:2019 + A11:2021, or the manufacturer's own declared procedures. If a finding is issued without a clause reference, you have the right to ask for the clause, and a good auditor welcomes the question.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices — Article 52 (conformity assessment procedures), Article 56 (certificates of conformity), Annex I (general safety and performance requirements), Annex II (technical documentation), Annex VII (requirements to be met by notified bodies), Annex IX (conformity assessment based on a quality management system and on assessment of technical documentation). Official Journal L 117, 5.5.2017.
  2. EN ISO 13485:2016 + A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes.
  3. EN ISO 14971:2019 + A11:2021 — Medical devices — Application of risk management to medical devices.

This post is part of the MDR Fundamentals & Regulatory Strategy series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister — a lead auditor and founder partnership bringing both sides of the audit table into a single perspective for resource-constrained MedTech startups.