What does an auditor check for IEC 62304?
IEC 62304 — Notified Body and ISO 13485 audit perspective
The short answer
Auditors check that your software lifecycle processes exist, are followed in practice, and produce the required records for your software safety class. The most common finding areas are SOUP management, traceability, software safety classification rationale, and problem resolution. Auditors verify outputs — not your methodology or tool choices.
What auditors specifically request
- Software Development Plan (current version)
- Software safety classification document — with explicit IEC 62304 §4.3 rationale
- SOUP register with anomaly evaluation for each SOUP item
- Traceability matrix linking requirements to test cases (Class B/C)
- Test records with pass/fail status, linked to requirements
- Problem resolution records — showing all bugs tracked and resolved
- Software release records for the current version
- Software Architecture Document (Class B/C)
- Unit verification records (Class B/C)
- Software Design Specification per unit (Class C)
Most common IEC 62304 audit findings
- Software safety classification not formally documented: Class assigned informally without a written document referencing IEC 62304 §4.3 and the underlying risk management rationale
- SOUP register incomplete or without anomaly evaluation: Libraries listed without version information, or with anomalies listed but not evaluated for impact
- Traceability matrix missing or not maintained: Matrix created once and not updated to reflect current requirements and tests; or matrix absent for a Class B/C system
- Test records not linked to requirements: Test results exist but cannot be linked to specific software requirements
- Problem resolution process not followed: Bug fixes made without problem records; GitHub commits without corresponding issue records
- Architecture document too high-level for Class C: Shows system blocks but not software item partitioning; cannot serve as basis for Class C design specifications
- Software changes not impact-assessed: Changes deployed without documented impact analysis; significance assessment under MDCG 2020-3 missing
Audit readiness checklist
- Software safety classification document exists, is dated, and references §4.3 + ISO 14971
- SOUP register is current (matches current release versions)
- All SOUP items have anomaly evaluations with assessed impact on device function
- Traceability matrix is current and complete (bidirectional, all classes B/C)
- Test evidence is linked to requirements (not just CI pass/fail status)
- All known bugs (including open ones) are in the problem resolution system with status
- Software Architecture Document exists and partitions software into named items
- Software release records exist for the current deployed version
- Software Development Plan is current and reflects actual development practices
What auditors do NOT require
- A specific development methodology (Agile, Waterfall, SAFe — your choice)
- Specific document formats or templates
- Specific tools (Jira vs GitHub vs Polarion — your choice, as long as records are kept)
- 100% code coverage in tests
- Zero open bugs at release time (deferred bugs must be justified and documented)
Frequently asked questions
What is the difference between a NB audit and an ISO 13485 audit for software?
An ISO 13485 QMS audit checks that your overall quality management system is functioning — it will include software development as one process within the QMS. A Notified Body technical documentation review under MDR Annex IX goes deeper into the IEC 62304 lifecycle records for a specific device. Both can result in findings against IEC 62304 compliance.
How does a first audit differ from a surveillance audit?
A first (initial) certification audit reviews the full QMS and selected technical documentation in depth. A surveillance audit (typically annual) samples processes and records to verify ongoing compliance. Surveillance audits commonly focus on areas where findings were raised previously, plus any changes made since the last audit.
How do I respond to a major finding?
A major finding requires a documented Corrective Action with: root cause analysis (not just the correction), corrective action plan with timelines, and evidence of implementation. The NB will verify closure before issuing or maintaining a certificate. Do not describe only the correction — you must demonstrate that the root cause has been addressed so the issue cannot recur.