I stopped counting the number of times a notified body auditor pointed to a single empty cell in our GSPR spreadsheet and called it a major non-conformity. To be fair, they were right: Annex I is one thing, but Annex II makes you explain every omission. A GSPR checklist that’s anything less than one row = one requirement, one justification, one evidence link is asking for trouble.
Why one row per requirement matters
Annex I (General Safety and Performance Requirements) is long and granular. Annex II (technical documentation) expects you to show how you meet each requirement — and, crucially, to justify any omission. In practice this means the Technical File is not a summary; it’s a traceability map.
Notified bodies routinely treat a missing justification or a dangling evidence link as an Annex II issue. The reason is simple: a missing justification suggests you either didn’t consider the requirement, or you considered it and have nothing to show. Either way, that’s a gap in your risk control thinking and your documentation.
How I structure the GSPR checklist (the working template)
I work from a simple, enforced template. Every row is a clause from Annex I, no paraphrase. Columns are:
- Clause reference (Annex I paragraph number)
- Requirement text (exact wording or brief extract)
- Applicability (Applicable / Not applicable)
- Justification (if Not applicable, say why; if Applicable, state how)
- Evidence link (document name, version, location, and anchor point)
- Responsible owner (who signs off)
- Review date & version trace
A couple of practical rules I follow:
- Never use “N/A” without a short, explicit justification. “N/A — device has no electrical parts” is better than “N/A”.
- Evidence link must include the document version and section (e.g. RMF v3.2, section 4.1). Link to a living repository entry, not a desktop path.
- The owner must be someone who can defend both the technical and regulatory rationale (engineer + RA sign-off in practice).
What an acceptable justification looks like
A justification is not a legal boilerplate. It must show thought and traceability.
Examples I use often:
- “Not applicable — device does not contain latex or natural rubber components; supplier declarations on materials provided (SupplierXYZ Material Cert v1.1, folder /Suppliers/SupplierXYZ).”
- “Applicable — addressed by design control: see Design History File, DHF v2.0, Test Report TR-123 section 2.3 and Risk Management File RMF v4.0, hazard H-12.”
- “Not applicable — safety functionality is redundant due to passive mechanical design; assessment in RMF v3.9, FMEA item 7.”
Notice the pattern: short rationale + pointer to specific evidence.
Evidence links — the rules that save audits
A lot of what trips teams up is sloppy linking. Fix these:
- Always cite document name, version, and location. “Clinical Evaluation Report” alone is not enough.
- Cross-reference by anchor (page, section, or clause). Auditors should find the supporting paragraph in under a minute.
- Keep supplier evidence accessible. If it’s behind an NDA, note where and why, and provide a redacted extract where possible.
- Mind translations. If the evidence is in another language, state that and reference the authorised translation.
Automated traceability helps here. A connected workflow that ties the requirement row to the RMF item, the test report, and the IFU reduces human error. An eQMS with native workflow integration and reviewability is not a luxury for this task.
Common traps that become major non-conformities
- Vague justifications: “Covered by risk management” with no link. That’s not a justification.
- Wrong versions: pointing to an obsolete test report while the current device matches a newer drawing.
- Missing owners: nobody can explain the rationale in an audit.
- Over-reliance on standards without demonstrating applicability: citing a harmonised standard is helpful, but you must explain how it maps to the requirement.
- Splitting evidence across multiple places with no single anchor: the auditor can’t see the whole argument quickly.
A single missing justification is often escalated by notified bodies because it indicates a gap in your overall conformity assessment system — not a clerical issue.
Keeping the checklist live: process tips
- Include the GSPR checklist in change control. Any design change that affects a clause must trigger a checklist review and, if needed, a CAPA-driven risk assessment.
- Make the checklist part of management review traceability. ISO 13485 expects top-level oversight; don’t hide this in a drawer.
- Use periodic check cycles aligned to risk: high-risk clauses reviewed quarterly, lower risk annually.
- Where helpful, automate reminders and attachments in your QMS so owners get nudged before audits.
AI-assisted triage can help locate candidate evidence when you’re under time pressure, but validation is essential. The justification is a judgement, not something you can outsource entirely.
Final practical thought
Treat the GSPR checklist like defensible casework, not a filing exercise. Each row should let a competent regulator answer: yes, we considered this, here is why it’s met or not applicable, and here is the evidence.
How are you organising your GSPR checklist so a notified body auditor can verify every row in under an hour?
Top comments (0)