Kyrgyzstan Medical Device Software and Cybersecurity: Registration, Versioning and Change Control

1. Key takeaways

Law No. 216 of Kyrgyzstan states expressly within the definition of a medical device that it includes dedicated software. Standalone software (SaMD) therefore qualifies as a device in Kyrgyzstan, follows national registration, and requires no additional argument about its legal nature. The real difficulties arise at two later points: how the software version is recorded and amended in the registration dossier, and whether an algorithm update triggers an amendment or a new registration. The simplified pathway can waive documents concerning software, but it does not waive the downstream obligations attached to the software attribute. Software manufacturers should treat version governance as a regulatory design decision made at first registration, not as an afterthought once updates begin to ship.

2. Legal basis

1. Law No. 216, Article 3: the definition of a medical device expressly includes dedicated software.
2. Law No. 216, Article 14: when device data and information change, the reporting obligation falls on the manufacturer or its authorized representative.
3. Resolution No. 513 of the Cabinet of Ministers, dated August 27, 2024, Annex 1: procedures for state registration, amendments to the registration dossier, and suspension or revocation of the registration certificate.
4. Resolution No. 513, paragraph 2 of Article 2: general safety and effectiveness requirements follow Council Decision No. 27 dated February 12, 2016 (with item 63 excluded).
5. Scope of documents waivable under the simplified pathway: includes documents concerning contained medicinal substances, sterilization and software (applicable to devices holding approvals from the eight reference jurisdictions).
6. Multilateral country survey report (Japan International Cooperation Agency, November 2025): when a model is changed or improved, a re-registration application must be submitted.

3. Expert insights

Insight 1: The law has already answered whether software is a device, moving the question to how versions are managed.

By writing dedicated software into the definition, Law No. 216 removes the classification argument entirely. But the follow-on question becomes acute: to what level is the software version recorded in the registration dossier? Major version, minor version, or revision number, and which change requires a formal amendment? This determines the pace at which the product can iterate in Kyrgyzstan and the compliance cost of each release. We recommend confirming the granularity of version recording with the authorized representative at first registration, before the first release cadence is set.

Insight 2: Software changes are the situation most likely to trigger a new registration rather than an amendment.

The multilateral country survey records that changes or improvements to a model require a re-registration application. For software, the boundary of improvement is blurry: does fixing defects count, does optimizing the interface count, does updating an algorithm count? We recommend setting decision rules in advance within the change management procedure: where functions and intended purpose are unchanged and only defects are fixed, process as an amendment; where new functions are added, the algorithm changes, or the intended purpose changes, assess a new registration (see article 35 of this series). Documented rules prevent inconsistent internal decisions under release pressure.

Insight 3: Embedded software (SiMD) and standalone software (SaMD) are organized differently in evidence.

For active devices carrying software, the software evidence is normally submitted as part of the technical file of the complete unit; for standalone software, the software itself is the object of registration. The two situations occupy different positions in the dossier, but both require version identification, a functional description, the operating environment and an algorithm description. We recommend a dedicated software section in the dossier table of contents in either case, so the reviewer always knows where to find it.

Insight 4: What the safety and effectiveness requirements under Decision No. 27 mean for software.

Decision No. 27 is the source of the general safety and effectiveness requirements. For software, safety and effectiveness cannot be proven through dimensions or electrical parameters; they can only be demonstrated through a traceability chain from requirements to design to verification to validation. We recommend providing a requirements traceability matrix in the software evidence, mapping every requirement to design outputs, verification activities and validation activities, in line with the statutory definitions of verification and validation in Annex 1 to Resolution No. 513.

Insight 5: The iteration frequency of software conflicts structurally with the end of the transition period.

Article 11 of this series explains that for certificates obtained on the national track, dossier amendments can only be processed under national rules until December 31, 2028. For frequently iterating software, this means that every version update after 2029 may trigger a full migration to the Union track. This is a risk that software products must price into pathway selection from the very beginning of the project.

4. Practical recommendations

First, confirm the version recording granularity at first registration. Record in the dossier the software version naming convention and the major version, and provide in the change management procedure that a major version change requires a formal amendment, while minor version and revision changes are handled under internal change management.

Second, set decision rules in advance for amendment versus new registration. Decide along three dimensions: whether functions are added, whether the algorithm changes, and whether the intended purpose changes. If none of the three applies, process as an amendment; if any one applies, assess whether a new registration is required.

Third, create a dedicated software section in the dossier. Include: software name and version; functional description; operating environment and dependencies; algorithm description; requirements traceability matrix; verification and validation reports; and cybersecurity measures.

Fourth, give software product lines priority assessment of the Union track. Given the conflict between iteration frequency and the end of the transition period, assess software products separately during pathway selection (see article 11 of this series).

Fifth, link release management with compliance checkpoints. Add a compliance checkpoint to the software release process: before every release, determine whether the change triggers a formal amendment, and retain the record of that determination.

5. Verification checklist

• □ Confirmed that dedicated software is a device under Article 3 of Law No. 216 and follows national registration;
• □ Version recording granularity confirmed at first registration (major version / minor version / revision);
• □ Decision rules for amendment versus new registration set in advance along three dimensions (functions, algorithm, intended purpose);
• □ A dedicated software section exists in the dossier, containing the requirements traceability matrix and verification / validation reports;
• □ Software product lines have completed a dedicated pathway assessment, pricing in migration risk after 2028;
• □ A compliance checkpoint exists in the release process, determining before each release whether the change triggers an amendment.

Regulatory information verified as of October 29, 2026.

Our services cover: pre-market pathway selection and feasibility assessment, registration dossier preparation and submission, authorized representative arrangements, local testing and clinical trial organization, manufacturing site inspection coordination, quality management system compliance support, post-market surveillance and device vigilance system setup, import and distribution compliance, and fee calculation and project budget management.

The GRZAN regulatory team consists of professionals with many years of hands-on experience in Eurasian Economic Union registration. We maintain a stable local cooperation network in Bishkek, Almaty, Tashkent and Moscow, work in Chinese, Russian and English, and provide executable solutions for foreign manufacturers on the issues most commonly encountered in CIS markets: authorized representative arrangements, notarization and legalization chains for powers of attorney, technical documentation localization, and inspection readiness. GRZAN supports manufacturers, importers and authorized representatives throughout the Kyrgyzstan registration lifecycle.

We adhere to one principle: every regulatory conclusion we publish must rest on verifiable official sources. Any figure or timeframe that cannot be verified is labeled as a practical estimate and is never presented as a legal requirement.

For project consultation on market access in Kyrgyzstan or the Eurasian Economic Union, please contact us at info@grzanglobal.com.

GRZAN | Global Medical Device Regulatory Registration and Compliance Services