Cybersecurity Risk Management for Software Medical Devices in Tanzania

1. Key takeaways

Tanzania embeds cybersecurity across the entire life cycle of software-driven medical devices, rather than treating it as a one-off submission topic. The 2024 Compendium of Guidelines for Marketing Authorization of Medical Devices, Diagnostics and Laboratory Equipment addresses this directly in Part X §3.3 (Cyber Risk Management), which states:

When managing cybersecurity risks, the principles described in ISO 14971 should also be followed.

In practical terms, manufacturers are expected to build four steps into their risk management plans: (i) identify all possible cybersecurity hazards; (ii) evaluate the associated risks; (iii) implement mitigation or control measures to reduce the risks to acceptable levels; and (iv) observe and evaluate the effectiveness of those mitigation measures. These steps mirror the familiar safety risk management loop, but applied to the threat landscape that surrounds connected and programmable devices.

The risk management process must be carried out continuously throughout the entire software life cycle and must be documented, for example in a report. The authority also names three elements that should be captured in the risk management plan: threat modelling, execution in parallel with safety (harm) risk management, and an ongoing plan for continued surveillance of threats and vulnerabilities. A submission that lacks any of these three pillars should be considered incomplete before it is even filed.

2. Legal basis

3. Expert insights

Insight one: the authority explicitly acknowledges the tension between security measures and patient safety, and gives a concrete example.

Part X §3.3 requires the cybersecurity risk management process to run in parallel with safety risk management. When security controls are introduced, overall patient safety must be considered so that the controls do not inadvertently cause patient harm. The official example: implementing multi-factor authentication before access to a CT scanner could delay device availability in an emergency, so an emergency access mode may be considered to address that safety risk. The lesson is that TMDA is watching for the side effects of security controls, not simply demanding that controls be as strict as possible.

Insight two: CVSS is named by the authority as an acceptable scoring methodology.

Under §3.3, when a new cybersecurity vulnerability is discovered, manufacturers are strongly encouraged to perform a vulnerability risk assessment covering the potential for patient harm and degraded device performance. The assessment can be analysed along two dimensions: (i) the exploitability of the vulnerability and (ii) the severity of harm to users or patients if the vulnerability is exploited. The guideline notes that this can be achieved by using established vulnerability scoring methodology such as the Common Vulnerability Scoring System (CVSS). The assessment must also take existing compensating controls and mitigations into account when judging whether the overall cybersecurity risk is an acceptable or unacceptable residual risk.

Insight three: vulnerability disclosure is written as a mandatory action, not a courtesy.

Where additional mitigations or compensating controls are judged necessary to reduce the risk, §3.3 provides that the manufacturer shall practice vulnerability disclosure to communicate to all affected users and stakeholders effectively. The disclosed information may include identification of the affected devices, the impact of the vulnerability, and the mitigations or compensating controls available. Manufacturers should therefore hold a ready-made disclosure template rather than drafting communications under time pressure during an incident.

Insight four: the monitoring obligation expressly covers third-party software.

The closing item of §3.3 requires monitoring all software (including 3rd party software) for new vulnerabilities and risks which may affect the safety and performance of the device. This brings off-the-shelf (OTS/COTS) commercial software and open-source components squarely within the surveillance scope, which makes SBOM (software bill of materials) management a practical necessity for any Tanzania submission involving software.

Insight five: premarket controls alone are not enough, and a post-market plan is explicitly required.

Section 3.5 opens by stating that it is therefore not possible to rely solely on premarket controls to mitigate all cybersecurity risks. Manufacturers must establish a comprehensive and structured cybersecurity risk management plan for the entire software life cycle and must proactively patrol for and detect potential threats. Key considerations include: monitoring all software, including third-party components, for new vulnerabilities and risks; and implementing processes for timely detection and analysis of vulnerabilities and threats, including impact assessment and follow-up actions such as threat containment, communication to affected parties, and vulnerability remediation.

Section 3.4 adds that implemented cybersecurity risk control measures must be verified and validated against design requirements or specifications before implementation, and that even with residual cybersecurity risks the features and characteristics of the device must remain operational for the intended use. Possible cybersecurity testing includes malware testing, structured penetration testing, and vulnerability scanning.

4. Practical recommendations

1. Merge cybersecurity risk management into the main ISO 14971 risk documentation instead of building a parallel system, because the guideline requires that ISO 14971 principles be followed.
2. Issue the threat modelling report as a standalone document, since threat modelling is specifically named as a key element of Part X §3.3.
3. Maintain a CVSS scoring register built on the exploitability and severity dimensions, and record the residual risk conclusion for each vulnerability.
4. Establish an SBOM and a third-party software monitoring mechanism covering OTS/COTS and open-source components.
5. Prepare a vulnerability disclosure template in advance covering affected devices, vulnerability impact, and mitigation or compensating measures.
6. Build malware testing, structured penetration testing, and vulnerability scanning into the verification stage and retain the reports.

5. Verification checklist

• □ Cybersecurity risk management is integrated into the ISO 14971 framework (Part X §3.3).
• □ Threat modelling has been completed and issued as a report.
• □ A CVSS (or equivalent) scoring register exists, including residual risk conclusions.
• □ A third-party software monitoring mechanism and an SBOM are in place.
• □ A vulnerability disclosure template and distribution process are ready.
• □ Malware testing, structured penetration testing, and vulnerability scanning have been performed (§3.4).
• □ A post-market plan for ongoing threat surveillance exists (§3.5).
• □ The patient-safety side effects of security controls, such as an emergency access mode, have been evaluated.

Regulatory information verified as of 29 October 2026. All provisions cited in this document were checked against the official TMDA published texts (the June 2024 Compendium, Part X §3.3, §3.4 and §3.5; GN. No. 315, Regulations 11(d) and 29(6)) and will be re-reviewed when the regulations are updated.

• Local resources in Tanzania: GRZAN can coordinate a licensed Local Responsible Person (LRP) and distributor resources, covering online submission, sample delivery, quality audit support, and port clearance.
• Service capabilities: classification determination, route selection between registration and notification, technical documentation (CSDT/STED) preparation and localization, GMDN coding and grouping strategy, clinical evidence organization, software and AI-enabled device submissions, change management, vigilance and PMS reporting, and annual retention fee and renewal management.
• Contact GRZAN for registration documentation and conformity support for the Tanzania market: info@grzanglobal.com.