Resources · Sample deliverables

Sample deliverables for IEC 62304 and cybersecurity.

Silurus Software publishes nine example artefacts of the kind a notified body, an FDA reviewer or your own QA lead asks to see: SOUP inventory, traceability matrix, CycloneDX SBOM, STRIDE threat table and a test case template, an FDA Pre-Submission outline and three clinical AI records for hospitals. All nine are illustrative and written for a fictional device.

Artefacts: 9, in HTML, no download form
Content: Fictional, illustrative
Example device: Fictional home use monitor, software safety class B
Standards: IEC 62304:2006+A1:2015 · ISO 14971:2019 · IEC 81001-5-1:2021

Context

Records, shown as records.

A supplier review for a regulated device asks for the records themselves, and a description of a process does not answer it.

Examples 01 to 06 are excerpts of records for medical device software under IEC 62304:2006+A1:2015, ISO 14971:2019, IEC 81001-5-1:2021 and the FDA guidance on cybersecurity in medical devices. Examples 07 to 09 are records a hospital uses when it selects and validates a clinical AI tool. Each shows a few rows or fields of the full record. The rows are written for this page. They do not come from a client project, and no client data, product name or document number appears in them.

The example device is fictional: a connected home use monitor with a sensor unit running FreeRTOS, a Linux gateway with a touch display and a cloud upload, software safety class B under IEC 62304. The open source components in the SOUP inventory and the SBOM are real projects with real version numbers, so every entry can be checked.

The IDs connect the five records. A requirement in the traceability matrix points to a risk control, a threat in the STRIDE table points to a requirement and a test, and a SOUP item points to its SBOM entry.

Structure

What every example shares.

A unique ID per row

Every row of the device records carries an ID that the other records reference, so an auditor can follow one requirement from the specification to the test result.

A version or a build

Every SOUP item is pinned to a version, and every test result to the build it ran on.

A link to the risk file

Every row of the SOUP inventory, the traceability matrix and the threat table points to a hazard, a threat or a risk control in the ISO 14971 risk management file, or states why it has none.

Trace

How the first five records connect.

The five records form one chain, held together by the IDs in the traceability matrix.

The SOUP inventory and the SBOM describe the same third party components for two readers. The SOUP record carries the IEC 62304 view with the purpose, requirements, published anomalies and risk. The SBOM carries the machine readable view that a vulnerability scanner and an FDA submission use.

The STRIDE table feeds the requirements. Each control becomes a security requirement with its own ID, and that requirement appears in the matrix next to the risk control and the test that verifies it.

The test case template is the format behind the test column. Each executed test case records the build, the result and the anomaly it raised.

Example 01

SOUP inventory excerpt.

Example, fictional, illustrative content. Five third party components of the fictional device, identified under IEC 62304 clause 8.1.2, with the requirements of clause 5.3.3 and the anomaly review of clause 7.1.3.

ID	Component and version	Source and licence	Purpose in the device	Requirements on the item	Published anomalies	Risk and justification	SBOM entry
SOUP-001	FreeRTOS kernel V11.3.1	freertos.org, MIT	Task scheduling on the sensor unit	Runs the 10 ms measurement task without missed deadlines. Stack overflow detection enabled.	Release notes and issue tracker for the Cortex-M4 port reviewed, last review 2026-09-30. No open item affects the scheduler functions in use.	Contributes to HAZ-04 (delayed alarm). Controlled by the hardware watchdog RC-07.	Sensor unit SBOM, pkg:github/FreeRTOS/FreeRTOS-Kernel@V11.3.1
SOUP-002	OpenSSL 3.5.9 (LTS)	openssl.org, Apache 2.0	TLS for the cloud upload on the gateway	TLS 1.2 or higher only, pinned server certificate with a backup pin, no renegotiation.	Security advisories reviewed monthly, last review 2026-09-30, after the update from 3.5.8. LTS branch supported until 8 April 2030.	Mitigates THR-03. A failure blocks the upload, data stays on the gateway.	Gateway SBOM, pkg:github/openssl/openssl@openssl-3.5.9
SOUP-003	SQLite 3.53.4	sqlite.org, public domain	Local storage of measurement records on the gateway	Atomic commit in WAL mode with synchronous=FULL, integrity check at every start.	Release log and CVE list reviewed, last review 2026-09-30. Fixes up to 3.53.4 included, no open item for the functions in use.	Contributes to HAZ-09 (lost records). Controlled by RC-09, verified by the power loss test STC-044.	Gateway SBOM, pkg:generic/sqlite@3.53.4
SOUP-004	zlib 1.3.2	zlib.net, zlib licence	Compression of log archives before upload	Lossless round trip of archives up to 50 MB, the largest daily log in the load test LT-02.	Changelog and CVE list reviewed, last review 2026-09-30. None affects the deflate functions in use.	No contribution to a hazardous situation, justified in the SOUP assessment.	Gateway SBOM, pkg:github/madler/zlib@v1.3.2
SOUP-005	nlohmann/json 3.12.0	github.com/nlohmann/json, MIT	Parsing of the configuration file	Rejects malformed input with an exception, never returns a partial parse.	Issue tracker reviewed, last review 2026-09-30. None applicable.	Contributes to HAZ-06 (wrong alarm limit). Controlled by range check RC-11.	Gateway SBOM, pkg:github/nlohmann/json@v3.12.0

Example, fictional, illustrative content. Fictional device, real open source components. A full inventory also lists the hardware and software each item requires (IEC 62304 clause 5.3.4).

Example 02

Traceability matrix excerpt.

Example, fictional, illustrative content. Requirement to design, code, test and risk, including the risk control traceability of IEC 62304 clause 7.3.3.

Requirement	Text	Design	Code unit	Test	Risk	Status
SRS-014	The device shall raise a high priority alarm, audible and visual, within 10 s when the measured value exceeds the configured limit, and keep it latched until acknowledged.	SDD-3.2 Alarm manager	alarm/alarm_manager.c	STC-031, STC-033	HAZ-04, RC-07	Passed, build 2.4.0
SRS-021	Measurement records shall survive a power loss during a write.	SDD-4.1 Record store	storage/record_store.cpp	STC-044	HAZ-09, RC-09	Passed, build 2.4.0
SRS-030	The gateway shall upload only over TLS 1.2 or higher with a pinned server certificate.	SDD-5.3 Cloud link	net/tls_client.cpp	STC-052, PEN-03	THR-03, RC-12	Passed, build 2.4.0
SRS-037	The sensor unit shall accept a firmware image only with a valid signature.	SDD-6.2 Image verification	boot/verify_image.c	STC-060, STC-061	THR-05, RC-14	Open, anomaly PR-118 blocks the release
SRS-042	The gateway display shall show the last value together with its age.	SDD-2.4 Home screen	ui/HomeView.qml	STC-070, UE-05	HAZ-11, RC-16	Passed, build 2.4.0

Example, fictional, illustrative content. UE-05 is a usability evaluation under IEC 62366-1. PEN-03 is a penetration test case. STC-033 verifies RC-07 by fault injection. With the alarm task stopped, the watchdog must reset the sensor unit and sound the backup buzzer within 3 s. Build 2.4.0 is the release candidate, and the open anomaly PR-118 blocks its release.

Example 03

CycloneDX SBOM excerpt.

Example, fictional, illustrative content.

An excerpt of the SBOM for the gateway firmware of the fictional device, in CycloneDX 1.6 JSON, written by hand in the structure a Syft scan of build 2.4.0 produces. A scan assigns its own bom-ref values, here they are set to the SOUP IDs. The vulnerabilities block is not scanner output, an engineer adds it after the reachability check. Four components are shown. The full file lists every component, the operating system and the transitive dependencies. Each bom-ref is the SOUP ID of the component, so the SOUP inventory and the SBOM point to each other. The hashes are the ones the projects publish for their source releases (SHA3-256 of sqlite3.c for SQLite), and the vulnerability ID is a placeholder. In a real SBOM the hashes come from the build and describe the files that ship.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:e23dacfd-0f57-4635-9536-2fda9115f806",
  "version": 7,
  "metadata": {
    "timestamp": "2026-09-30T08:00:00Z",
    "authors": [{ "name": "Software team, fictional manufacturer" }],
    "tools": { "components": [{ "type": "application", "name": "syft", "version": "1.52.0" }] },
    "component": { "type": "firmware", "bom-ref": "gateway-fw",
                   "name": "example-gateway-firmware", "version": "2.4.0" }
  },
  "components": [
    { "type": "library", "bom-ref": "SOUP-002",
      "supplier": { "name": "OpenSSL project", "url": ["https://openssl-library.org"] },
      "name": "openssl", "version": "3.5.9",
      "purl": "pkg:github/openssl/openssl@openssl-3.5.9",
      "licenses": [{ "license": { "id": "Apache-2.0" } }],
      "hashes": [{ "alg": "SHA-256", "content": "603f5602e2eef00d77fbd429d34dcd5822bb301757a1bc9cdb24c670f1eb859a" }] },
    { "type": "library", "bom-ref": "SOUP-003",
      "supplier": { "name": "SQLite project", "url": ["https://sqlite.org"] },
      "name": "sqlite", "version": "3.53.4",
      "purl": "pkg:generic/sqlite@3.53.4",
      "licenses": [{ "license": { "id": "blessing" } }],
      "hashes": [{ "alg": "SHA3-256", "content": "67f423e9ebbbdc473cbc4772c872ee6b89f31fde4ed0279a5c25d5f65c043a16" }] },
    { "type": "library", "bom-ref": "SOUP-004",
      "supplier": { "name": "zlib project", "url": ["https://zlib.net"] },
      "name": "zlib", "version": "1.3.2",
      "purl": "pkg:github/madler/zlib@v1.3.2",
      "licenses": [{ "license": { "id": "Zlib" } }],
      "hashes": [{ "alg": "SHA-256", "content": "bb329a0a2cd0274d05519d61c667c062e06990d72e125ee2dfa8de64f0119d16" }] },
    { "type": "library", "bom-ref": "SOUP-005",
      "supplier": { "name": "Niels Lohmann", "url": ["https://github.com/nlohmann/json"] },
      "name": "nlohmann-json", "version": "3.12.0",
      "purl": "pkg:github/nlohmann/json@v3.12.0",
      "licenses": [{ "license": { "id": "MIT" } }],
      "hashes": [{ "alg": "SHA-256", "content": "42f6e95cad6ec532fd372391373363b62a14af6d771056dbfc86160e6dfff7aa" }] }
  ],
  "dependencies": [
    { "ref": "gateway-fw", "dependsOn": [ "SOUP-002", "SOUP-003", "SOUP-004", "SOUP-005" ] }
  ],
  "vulnerabilities": [
    { "id": "CVE-YYYY-NNNNN",
      "affects": [{ "ref": "SOUP-002" }],
      "analysis": { "state": "not_affected", "justification": "code_not_reachable",
                    "detail": "The affected function is not called. Reachability checked on the call graph of build 2.4.0, record VA-012, threat THR-03." } }
  ]
}

The vulnerabilities block records the analysis of each known vulnerability against the device. Here the affected function is never called, the reachability check is kept as record VA-012, and the entry points to the threat it belongs to. This is the VEX information a reviewer asks for next to the SBOM.

The SBOM is generated from the build, so it changes with every release. The SOUP inventory above is reviewed by an engineer when a component, its version or its role changes, and at every monthly vulnerability review.

Example 04

STRIDE threat table excerpt.

Example, fictional, illustrative content. Seven threats of the fictional device across all six STRIDE categories, from the threat model the FDA premarket cybersecurity guidance expects, with security risk management under IEC 81001-5-1.

ID	Element	STRIDE	Threat	Effect on the device	Control	Verification	Residual risk and rating
THR-01	BLE link, sensor to gateway	Spoofing	A nearby device poses as the sensor and sends readings.	False values shown to the user.	LE Secure Connections with out of band pairing data (MITM protection), as the sensor unit has no display, bonded devices only.	PEN-01	Low (likelihood low, impact high), accepted
THR-02	Record store on the gateway	Tampering	Stored records are altered or replayed on the file system.	Altered history shown to the clinician.	HMAC per record with a sequence number, key in the secure element.	STC-045	Low (likelihood low, impact medium), accepted
THR-03	Cloud upload	Information disclosure	Traffic between gateway and cloud is intercepted.	Health data disclosed.	TLS 1.2 or higher, pinned server certificate with a backup pin for rotation.	STC-052, PEN-03	Low (likelihood low, impact high), accepted
THR-04	Configuration change	Repudiation	An alarm limit is changed and nobody can say by whom.	The change cannot be traced in a complaint investigation.	Signed audit log with user and time, copied to the cloud at every upload.	STC-081	Low (likelihood low, impact medium), accepted
THR-05	Firmware update	Tampering	A modified image is installed on the sensor unit.	Loss of essential performance.	Signed images, secure boot, rollback counter.	STC-060, STC-061	Medium (likelihood medium, impact high), open until PR-118 is closed
THR-06	Cloud API	Denial of service	A flood of requests blocks the upload endpoint.	Delayed data at the clinic. The local alarm is not affected.	Rate limits, 72 h local buffer on the gateway, three days of data at the highest sampling rate.	LT-03 (buffer capacity test)	Low (likelihood medium, impact low), accepted
THR-07	USB service port	Elevation of privilege	A debug shell is reachable on a production unit.	Full control of the device.	Debug interfaces disabled in release builds, JTAG locked.	STC-090, release checklist	Low (likelihood low, impact high), accepted

Example, fictional, illustrative content. Likelihood and impact are rated on the scales of the cybersecurity risk management plan, and a named risk owner accepts each residual risk. Each control becomes a security requirement in the traceability matrix. THR-03 appears there as SRS-030.

Example 05

Test case template, filled in.

Example, fictional, illustrative content. A software system test case for SRS-014, with the record contents of IEC 62304 clause 5.7.5.

Field	Content
Test case ID	STC-031
Title	High priority alarm when the measured value exceeds the limit
Traces to	SRS-014, HAZ-04. The risk control RC-07 is verified separately by STC-033.
Test level and safety class	Software system test, software safety class B under IEC 62304 clause 4.3. A software failure that delays the alarm is caught by RC-07, a hardware watchdog outside the software that resets the sensor unit and drives the backup buzzer directly. With RC-07 in place the worst outcome is a non-serious injury, which gives class B.
Preconditions	Gateway and sensor unit paired, alarm limit set to 120, measurement running for at least 60 s.
Test environment	Sensor unit hardware rev C with firmware 2.4.0, gateway image 2.4.0, signal simulator SIM-2 with calibration record CAL-207, timer resolution 0.1 s.
Steps	1. Feed 110 for 30 s. 2. Feed 120, the limit itself, for 30 s. 3. Raise to 121 and start the timer. 4. Hold for 20 s. 5. Lower to 110 and wait 10 s. 6. Acknowledge the alarm.
Expected result	No alarm in steps 1 and 2. High priority alarm, audible and visual, within 10 s of step 3. In step 5 the alarm condition ends and the alarm signal stays latched until the acknowledgement in step 6.
Pass and fail criteria	Pass when in each of 10 repetitions there is no alarm at the limit, the alarm starts within 10 s above it and stays latched until acknowledged. Any deviation in any repetition fails the test.
Actual result	No alarm at 120 in 10 of 10. Alarm after 6.2 s to 7.9 s, mean 7.1 s, in 10 of 10. Latched until acknowledged in 10 of 10. Single times in the run log of build 2.4.0.
Result	Passed
Executed by, date, build	[tester], [date], build 2.4.0
Anomalies raised	None
Reviewed by	[reviewer], [date]

Example, fictional, illustrative content. Names and dates are left as placeholders.

Example 06

FDA Pre-Submission outline.

Example, fictional, illustrative content. The structure of a Pre-Submission package in the FDA Q-Submission program, prepared by our FDA consultants, with the specific questions the agency is asked to answer.

Section	Content
Cover letter	Request for a Pre-Submission meeting for a connected home use monitor, the preferred meeting format (teleconference) and the contact person.
Device description	Sensor unit with firmware, Linux gateway with a touch display and cloud upload, how the parts work together, the measured parameter and the alarm function, with a system diagram.
Proposed indications for use	Draft wording of the intended use and the indications for use, the patient population and the use environment (home).
Regulatory history	No previous FDA submissions for this device. CE marking under the EU MDR in preparation.
Planned regulatory route	510(k) with a proposed predicate device, and a short comparison of intended use and technological characteristics.
Planned testing	Basic safety and essential performance under IEC 60601-1, EMC under IEC 60601-1-2, alarms under IEC 60601-1-8, home use under IEC 60601-1-11, software verification under IEC 62304, usability under IEC 62366-1, and the cybersecurity documentation for section 524B of the FD&C Act.
Question 1	Does the agency agree that the proposed predicate is appropriate for the intended use in the proposed indications for use?
Question 2	Does the agency agree that the planned alarm performance testing is sufficient to support substantial equivalence?
Question 3	Does the agency agree that the planned penetration testing of the gateway and the cloud connection is sufficient to support the cybersecurity documentation of this submission?

Example, fictional, illustrative content. The questions are written for the fictional device.

Example 07

Clinical AI use case ranking.

Example, fictional, illustrative content. The first result of a readiness assessment for a hospital: use cases ranked by benefit, evidence and the conditions they depend on, including one to leave alone for now.

ID	Use case	Department	Benefit	Evidence	Main condition	Rank
UC-01	Fracture detection on emergency X-rays	Radiology, emergency	High	Strong, CE marked products	Integration with PACS	1
UC-04	Mammography screening support	Radiology, screening	High	Strong, published studies	Local validation first	2
UC-02	Drafting of discharge letters	Internal medicine	High	Limited, pilot data	Pilot with local measurement	3
UC-03	Booking assistant for the contact centre	Front desk	Medium	Limited	Integration with scheduling	4
UC-05	Sepsis prediction from the record	Wards	Uncertain	Weak external evidence	Not started	Leave for now

Example, fictional, illustrative content. A fictional hospital. Ranked by benefit first, then by the strength of the evidence, then by the effort of the main condition. The benefit is estimated from the hospital's own volumes and staff time.

Example 08

AI vendor scoring matrix.

Example, fictional, illustrative content. Three fictional products compared against criteria the hospital agreed in advance, as input to the tender decision.

Criterion	Weight in %	Vendor A	Vendor B	Vendor C
Knock-out: intended use covers the planned use	Pass or fail	Pass	Pass	Pass
Knock-out: CE marked for this intended use	Pass or fail	Pass	Pass	Pass
Clinical evidence on comparable populations	30	3	4	2
Integration with PACS, RIS and record	20	4	2	4
Data protection and hosting in the EU	20	5	3	4
Monitoring and change information from the vendor	15	3	4	2
Total cost over three years	15	3	4	4
Weighted score	100	3.60	3.40	3.10

Example, fictional, illustrative content. A product that fails a knock-out criterion is not scored. Scores from 1 to 5 against a written scale per criterion, weights agreed with the hospital before the evaluation.

Example 09

Local validation report summary.

Example, fictional, illustrative content. The summary of a local validation of a fictional AI tool on a hospital's own studies, measured by subgroup before go live.

Field	Content
Tool and version	[product], fictional CE marked fracture detection tool, version 2.1
Intended use checked	Detection of fractures on adult extremity X-rays, as decision support for the reader
Data set	Retrospective, 1,200 studies, 380 with a fracture, from two departments, two X-ray systems, one year. Subgroups: system A 640, system B 560, patients over 75 years 210 (70 with a fracture).
Reference standard	Consensus of two radiologists, a third in case of disagreement, blinded to the tool output
Acceptance criteria	Fixed in the validation plan before the measurement: sensitivity at least 0.90 and specificity at least 0.85, overall and in every subgroup
Result, overall	Sensitivity 0.92 (95% CI 0.89 to 0.94), specificity 0.88 (0.86 to 0.90)
Result, by subgroup	System A 0.93 (0.89 to 0.96) and 0.89 (0.86 to 0.92). System B 0.91 (0.86 to 0.94) and 0.87 (0.83 to 0.90). Over 75 years 0.89 (0.79 to 0.94) and 0.84 (0.77 to 0.89)
Conclusion	Criteria met overall and for both X-ray systems. Not met for patients over 75 years, recorded as deviation DV-03. The tool is not used for this group until a revalidation on a larger set, decided by the hospital's AI oversight board
Monitoring plan	Monthly sensitivity on a sample, override rate per ward, threshold for review agreed

Example, fictional, illustrative content. All figures are invented for this example.

Client work

The same records, written for clients.

These record types are part of the products we work on. In the case studies below we wrote them for the client, under the client's quality system and document control.

Record	Written in client work	Case study
Traceability matrix, as in example 02	End to end from user needs to verified test results, and per change from requirement to verification	Lab device refactoring, IEC 62304 feature development, QA and DevOps for a regulated portfolio
Test cases and test reports, as in example 05	Verification plan and test reports, and regression test evidence for every release	Lab device refactoring, QA and DevOps for a regulated portfolio
Software requirements specification	Requirements written down in a form a validation can rest on	Lab device refactoring
Risk assessment per change	ISO 14971 risk assessment as part of each change, traced to its verification	IEC 62304 feature development
Gap analysis report	Prioritised findings against IEC 62304, FDA and MDR expectations, with a remediation recommendation each	Embedded firmware gap analysis

The client documents stay with the clients and are not shown here.

Scope

What the examples show, and what they are not.

What they show

The fields and IDs each record carries
How the five records reference each other
The level of detail of a single row
Real open source components with real versions

What they are not

Copies of a client document or excerpts from one
A template that replaces the formats of your QMS
Evidence of a submission outcome
A complete record. Each one is an excerpt.

FAQ

Questions about the examples.

How do a SOUP list and an SBOM differ?

The SBOM lists every software component with version, supplier, licence and hash in a machine readable format such as CycloneDX or SPDX, for vulnerability monitoring. For IEC 62304, the SOUP record adds why the component is used, the requirements it has to meet, the review of its published anomalies and its contribution to risk. A device needs both, and the two share the component identifiers.

Which SBOM format do you deliver?

CycloneDX JSON, as in the example, or SPDX where the client's tooling expects it. The format follows the scanner and the submission route, the content stays the same.

Do you write to our templates or to yours?

To yours, where your QMS defines them. The examples show the content a record needs, and the same content goes into your formats and under your document control.

Can we see a complete artefact from a real project?

No. Client documents belong to the client and stay confidential under our agreements. The examples on this page show the structure, and a call is the place to go through how a record of this kind is built for your device.

Which standards do these records answer to?

IEC 62304 for the SOUP inventory, the traceability matrix and the test record, ISO 14971 for the risk links, IEC 81001-5-1 and the FDA premarket cybersecurity guidance for the threat table and the SBOM, and IEC 62366-1 for the usability evaluation referenced in the matrix.

Related work and pages.

Client names are withheld unless the client has agreed to be named.

Case study

IEC 62304 gap analysis of safety-critical surgical device firmware

Two people reviewed a safety-critical surgical device's firmware, documents and process against IEC 62304, FDA and MDR in three weeks. The remediation was then contracted to Silurus Software.

Case study

Lab device refactoring and IEC 62304 documentation

Desktop application and firmware of a Dutch university medical centre's lab device refactored to be testable, with IEC 62304 documentation, in three months.

Case study

IEC 62304 feature development in a large .NET codebase

Senior developers inside a European manufacturer's lifecycle, QMS and review workflow, over several years.

Case study

QA and DevOps for a regulated software portfolio

Ten specialists running nightly regression and signed builds inside a European manufacturer's release process, over several years.

Retrospective IEC 62304 documentation Verification and validation Quality and standards How we work FAQ

Talk to us

Need these records for your device?

Send the requirements and the current documentation. The first call goes through which records exist and which are missing.

Send your requirements Book a 30 minute technical call