Labelling Requirements in Your Technical Documentation

Labelling is a technical file component, not just a packaging task

Most teams think of labelling as something the regulatory affairs team hands off to marketing or operations once the technical work is done. Under EU MDR, that separation creates problems. Annex II requires the technical file to include labelling and instructions for use — meaning labelling is not adjacent to the technical file, it is part of it. A Notified Body reviewing your technical file will check the labelling against the requirements in Annex I, Section 23, and any mismatch between what the label says and what the rest of the technical file says is a finding.

The labelling requirements in Section 23 of Annex I are detailed. MDR introduced several requirements that did not exist under MDD, and devices transitioning from MDD certification often have labelling that simply does not meet the new standard. If your device was CE-marked under MDD and the labelling has not been reviewed against Section 23 of Annex I, it is worth doing that review before your next Notified Body interaction.

What Section 23 of Annex I requires

Section 23 lists mandatory information that must appear on the label, on the packaging, or in the instructions for use — depending on the item. The requirements that catch teams most often:

UDI carrier on the label Every device that requires a label must carry a UDI (Unique Device Identifier) in human-readable and machine-readable form. The UDI carrier requirements differ by device class and packaging level. Class III implantable devices require UDI on every unit of packaging, including sterile barrier packaging, and the UDI-DI must also be included in the implant card. Teams that label at the sales unit level but not at the sterile barrier level often miss this.

Reference to the Summary of Safety and Clinical Performance Class III devices and implantable devices are required to have a reference on the label (or in the IFU) to the SSCP, once published on EUDAMED. This is a relatively new requirement and one that many technical files do not yet reflect. The SSCP itself must be part of the technical file.

Symbol standards If you use symbols on the label — and almost all medical device labels do — each symbol must be defined by reference to a recognised standard (typically ISO 15223-1). The MDR explicitly requires that symbols not defined in a recognised standard must be explained in the IFU. Finding a symbol on a label that is not from a recognised standard, with no explanation in the IFU, is a straightforward audit finding.

Language requirements Labelling and IFU must be in the official language(s) of the EU member state(s) where the device is placed on the market. This is not new, but teams expanding into new EU markets sometimes update distribution arrangements without checking whether the labelling covers the required language.

Electronic IFU Under Commission Regulation (EU) 207/2012, certain non-implantable devices can provide IFU electronically rather than in paper form. Doing this requires meeting specific conditions and notifying the competent authority. If your device uses an eIFU and this has not been properly authorised, that is a technical file gap.

Where labelling and the technical file need to align

The thing that generates the most findings is not missing mandatory information — it is inconsistency between what the labelling says and what the rest of the technical file says. Specific points to check:

Intended purpose and indications for use The intended purpose statement on the label (and in the IFU) must match the intended purpose in Section 1 of Annex II. If the IFU describes indications or uses that are not in the intended purpose as documented in the technical file, or if the technical file uses a different formulation, that inconsistency will be flagged. This sounds obvious, but in practice the IFU and the technical file often go through different revision cycles and drift apart.

Contraindications and warnings Warnings and contraindications in the IFU should be traceable to the risk management file. If a risk control in the risk management file takes the form of a user warning, that warning needs to appear in the IFU. If it does not, the risk management file says a risk has been controlled but the labelling does not implement that control.

Device variants and accessory listings If the technical file covers multiple device variants or accessories, the labelling needs to be consistent with what is covered. A label that references an accessory not documented in the technical file — or a technical file that includes variants with no corresponding labelling — creates a scope mismatch.

The version alignment problem

Labelling tends to go through its own change management process, separate from the technical file. The result is a common situation: a label is at version 4, but the technical file includes version 2 labelling because no one updated the technical file when the label was revised. If the labelling revision changed something substantive — an indication, a warning, a symbol — and the technical file does not reflect that, there is a real gap.

The fix is procedural: your change control process for labelling should include a step that checks whether the technical file labelling section needs to be updated, and that generates a documented outcome — either an updated technical file or a recorded rationale for why no update was needed.

What to verify before a Notified Body review

If you are preparing for a technical file submission or surveillance audit, the labelling check is worth doing methodically:

• Pull the current label and IFU versions and compare them with the versions referenced in the technical file.
• Check every symbol against ISO 15223-1 or another recognised standard and confirm each one is listed in the IFU if not from a recognised source.
• Check that the UDI carrier is present at the required packaging levels for your device class.
• Compare the intended purpose statement in the IFU with the intended purpose in the device description.
• Check that all risk management controls implemented as user warnings appear in the IFU.
• Verify the language coverage against the markets where the device is distributed.

None of these checks is technically complex. But teams that do not have a structured process for keeping labelling and the technical file in sync find gaps that are straightforward for an auditor to spot — and straightforward to fix, if you catch them before the audit.