Cybersecurity and software lifecycle deliverables under TR-007

1. Key takeaways

Technical reference file TR-007, Software and Cybersecurity for Medical Devices, was updated on 1 September 2025, when a Chinese version was issued for the first time. Its scope covers both standalone software that is itself a medical device and devices that contain software components. The documentation to be delivered at application runs along two lines: the software lifecycle line, covering requirements, design, verification, release, change and retirement, and the cybersecurity line, covering threat modelling, vulnerability management, patch strategy and incident response. Delivering cybersecurity documents without lifecycle documents, or the reverse, leads to a request for further information.

The two lines are not alternatives. They answer different questions: whether the software was built under control, and whether it remains secure while in use. A reviewer needs both answers before the file can be considered complete.

• Two documentation lines, both mandatory. Lifecycle evidence and cybersecurity evidence are assessed together.
• Scope includes software in a device. Embedded software is not outside TR-007 simply because the product is hardware.
• Version change is a regulatory question. Software updates have to be assessed against GN-10 before release.
• Cybersecurity continues after listing. Threat modelling is a pre-market duty; vulnerability tracking is a post-market one.
• AI products carry a second layer. TR-008 applies cumulatively, and the documentation should be organised as separate volumes.

2. Legal basis

TR-007 supplies the software lifecycle and cybersecurity requirements. TR-008 governs artificial intelligence medical devices and applies on top of TR-007 where the product contains algorithms. TR-004 supplies the Essential Principles that both serve. GN-10 governs changes to listed medical devices and determines whether a software update is a major or a minor change. MDD announced the TR-007 update and the release of the Chinese version through its news page on 1 September 2025.

The pairing with GN-10 is the part applicants underestimate. TR-007 defines what evidence a software product must have; GN-10 defines what must be done when that product changes after listing. Read separately, each looks manageable. Read together, they impose a continuous obligation that begins before the first listing and does not end at approval.

3. Expert insights

The Chinese version changed the compliance cost structure for manufacturers in the Chinese mainland. Before its release, applicants for software devices had to work through TR-007 in English. With a Chinese version available, terminology alignment and internal training become materially cheaper, and that in itself is a policy action that lowers the barrier to entry. The benefit is real but limited: the obligation is unchanged, only the cost of understanding it has fallen.

Software version changes are tied directly to change management under GN-10. Algorithm iterations, interface updates and vulnerability fixes all raise the question of whether they amount to a major change. Software products change more often than hardware, so the rules for that determination have to be written in advance; otherwise every release becomes an improvised judgement made under commercial pressure. Applicants that define the boundary in their quality system decide the question once, and apply the decision thereafter.

Cybersecurity is a continuous obligation spanning pre-market and post-market. Before listing, the applicant submits threat modelling and a vulnerability management plan. After listing, the applicant tracks vulnerabilities and handles them in line with post-market surveillance requirements. A listing decision does not end the cybersecurity obligation, and a manufacturer that treats approval as the finish line is exposed at the first serious vulnerability disclosure.

With artificial intelligence the documentation roughly doubles. A product containing algorithms has to satisfy TR-007 and TR-008 at the same time, and the documentation should be assembled into separate volumes keyed to the two technical reference files, so that the reviewer can match each requirement to its evidence without hunting through a combined document.

Retirement is part of the lifecycle. The lifecycle line named in TR-007 includes retirement, which means the plan for end-of-support, data migration and user notification is a document the applicant should be able to produce. It is the item most often missing from an otherwise complete file.

4. Practical recommendations

• Build two documentation lists. One list for the lifecycle line and one for cybersecurity, each recording the document name and version.
• Define the change rule in advance. State in the quality system what kind of software update counts as a major change, then apply the notification or prior approval procedure in GN-10 accordingly.
• Put the patch strategy into the post-market process. Connect vulnerability response, patch release and adverse event reporting into one workflow rather than three disconnected ones.
• Keep version traceability records. Requirements, changes and verification records for each released version should be retrievable, so that they can be produced during an MDD inspection.
• Separate the AI volume. Where algorithms are present, maintain a distinct volume mapped to TR-008 alongside the TR-007 volume.

5. Verification checklist

• □ The current version of TR-007, updated 1 September 2025, and the availability of the Chinese version have been confirmed.
• □ Software lifecycle documents covering requirements, design, verification, release, change and retirement are complete.
• □ Cybersecurity documents covering threat modelling, vulnerability management, patch strategy and incident response are complete.
• □ A rule for determining whether a software update is a major change has been defined.
• □ The patch and vulnerability response process is connected to the post-market surveillance system.
• □ Products containing algorithms have a separate volume prepared under TR-008.

Regulatory information verified as at 29 October 2026. The legislation, guidance and effective dates described in this article are limited to the content published by the official sources listed under legal basis on that date; where those sources are updated, the latest published version prevails.

How GRZAN can help. GRZAN provides medical device and IVD registration, quality system, authorised representative and local testing support for Hong Kong, China. Our team prepares MDACS-compliant dossiers, coordinates evidence of reference approvals and ISO 13485 certificates, and supports post-market vigilance obligations. Business enquiries: info@grzanglobal.com