ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
An IVDR GSPR checklist is the table that proves your in vitro diagnostic device meets every general safety and performance requirement in Annex I of Regulation (EU) 2017/746. Notified bodies expect it in your technical documentation, and a weak one is among the fastest ways to generate questions during review.
This guide explains how Annex I is organized, how to structure the checklist, how to justify requirements that do not apply and how to link each row to evidence. It is written for regulatory and quality teams at IVD manufacturers. The regulation and its transition rules have been amended, so confirm the current consolidated text and your notified body’s expectations before you finalize anything.
Free gap assessment
How much of ISO 13485 could you evidence today?
Score clauses 4 to 8, free, with the FDA QMSR and EU MDR duties kept separate so you can see what is the standard and what is the regulator.
Run the free ISO 13485 gap assessment → or View premium report sample
Annex I of the IVDR sets out the general safety and performance requirements that an IVD must meet. The annex contains 20 numbered requirements arranged in three chapters: general requirements, requirements regarding performance, design and manufacture, and requirements regarding the information supplied with the device. Manufacturers demonstrate conformity by showing, requirement by requirement, how they meet each one or why it does not apply.
That demonstration is the IVDR GSPR checklist, sometimes called a conformity matrix. It sits in the technical documentation and is one of the first things a notified body reviewer opens. Our overview of the EU IVDR and the guide on IVDR technical documentation show where the checklist fits.
The first chapter covers general requirements: devices must achieve their intended performance, be safe, and have risks reduced as far as possible through a documented risk management system. The second chapter covers performance, design and manufacture, including analytical and clinical performance, chemical, physical and biological properties, infection and contamination, measurement, radiation protection, software, energy sources and self-testing devices where relevant. The third chapter covers labels, instructions for use and other information supplied with the device.
Read the requirements in the regulation itself, not in a summary. For specific points such as the detailed content of labels or instructions, follow the sub-paragraphs in chapter III and check for applicable standards and common specifications.
Work from the regulation text and your device’s intended purpose. The steps below give a reliable sequence.
| Checklist column | What to write | Example |
|---|---|---|
| Requirement | The Annex I requirement number and text | Requirement on risk management |
| Applicable? | Yes or No, with justification for No | Yes, device is software-driven |
| Method of compliance | Standard, common specification or own solution | Risk management standard, verification tests |
| Evidence | Document reference and version | Risk management report, version 3 |
| Location | Where it sits in technical documentation | Annex II, section 4 |
| Status | Complete, open, or not applicable | Complete |
Every row that you mark as not applicable needs a short, specific reason. “Not relevant” is not enough; reviewers ask why. A good justification refers to the device characteristic that removes the requirement, for example that the device contains no software, no energy source or no biological material.
Be consistent between documents. If the checklist says the device has no software but the technical documentation includes software verification, the reviewer will notice. Have a second person check applicability against the device description before release.
The strength of the checklist lies in its links. For each requirement, name the specific document and section that demonstrates compliance: risk management file, design verification, analytical performance, stability studies, usability engineering, labeling review or clinical evidence. Include the version so the reviewer can find exactly what you mean.
Performance requirements connect to the performance evaluation; see IVDR performance evaluation for how scientific validity, analytical performance and clinical performance are evidenced. Information requirements connect to labeling and to identification under the system described in unique device identification.
The IVDR applies with transitional periods that depend on risk class, extended by later amending regulation. One industry summary reports that the extended transitional periods run to 31 December 2027 for Class D, 31 December 2028 for Class C and 31 December 2029 for Class B and sterile Class A devices, provided conditions are met, including notified body applications by set dates. It also reports that the Commission proposed a simplification package in December 2025 that does not amend the transitional periods. Confirm the current status in the official sources; see IVDR transition deadlines for our guide and the Seleon overview of IVDR 2026 transition periods for the summary.
The practical point is that your checklist must be ready when your notified body starts review. Legacy devices moving to the IVDR need a fresh checklist, because the old directive’s essential requirements are not a one-to-one match. The differences are described in IVDR vs IVDD.
Notified bodies look for completeness and traceability. Ask yours early whether it has a preferred checklist format, how it wants evidence referenced and how it handles updates. Our guide to the IVDR notified body process explains the review. Prepare for questions by making sure each row can be answered from your technical file without hunting.
After certification, keep the matrix alive. Post-market data, complaints and vigilance information can change the benefit-risk balance, so feed them back using the process described in IVDR post-market surveillance.
A good template saves time and avoids missing rows. The EU IVDR Toolkit includes an Annex I checklist and supporting technical documentation templates consistent with the regulation as consolidated, so you fill in your evidence links instead of building the structure.
A template does not decide applicability or supply evidence; those remain your responsibility. If you make in-house devices, read IVDR in-house devices for the specific conditions that apply to health institutions.
Consider a software-driven immunoassay analyzer. For the requirement on software and programmable systems, the row would state that the requirement applies because the analyzer runs embedded software and the manufacturer also ships data management software. The method of compliance would cite the software life cycle standard used and the usability engineering process. The evidence column would list the software requirements specification, the verification and validation report, the cybersecurity risk assessment and the release record, each with its version number and location in the technical documentation. The status would read complete only when every referenced document is approved and current. Example content like this is illustrative; your own rows must reflect your device.
Give the checklist a single owner, normally regulatory affairs, and require contributions from the functions that hold the evidence: design, software, clinical, quality and labeling. Review it at every design change and before every submission, and record the review. A checklist owned by nobody tends to drift out of date, and the drift is usually discovered by the notified body rather than by you. A short change log at the top of the document makes it easy to see what moved and when.
When a referenced standard is updated, review every row that cites it. Check whether the new edition changes the requirements you rely on, whether a transition period applies and whether your test reports still cover what the notified body expects. Record the assessment of each change so it is clear why a row stayed the same or was revised. This routine protects the checklist from becoming a snapshot of an earlier year.
Before you submit, run a last consistency check. Confirm that every document referenced in the matrix exists in the file, that the versions match, that the intended purpose in the matrix is identical to the one on the label and in the performance evaluation, and that every not-applicable justification still holds. Ask a colleague to pick ten rows at random and trace each to its evidence within a few minutes. If they cannot, the reviewer will not be able to either, and the rows need clearer references or better organized files.
The usual errors are listing standards without showing how they were applied, marking items not applicable without reasons, referencing documents without versions and not updating the checklist after design changes. Another is copying an MDR template, which uses different requirements. Review the checklist with a fresh pair of eyes before submission, ideally someone who has not worked on the device.
It is a conformity matrix in the technical documentation showing how the device meets each Annex I requirement of Regulation (EU) 2017/746, or why a requirement does not apply.
Annex I contains 20 numbered requirements, organized in three chapters, with sub-paragraphs that must be addressed individually.
Not directly. The MDR and IVDR annexes have different requirements. Use the IVDR text as the basis.
The notified body reviews it as part of technical documentation assessment for devices that need one. Internal reviewers should check it first.
Whenever the design, intended purpose, risk assessment, standards or regulatory requirements change.
October 1, 2026
