CDSCO Medical Device Software Guidance 2026: Detailed Compliance Update
Understand CDSCO's 2026 medical device software guidance on classification, licensing, QMS, AI validation, cybersecurity, labelling and PMS duties in India.
Schedule a Call Back
2,100+ CDSCO medical device assignments since 2018
Clients include Endolite India, Mankind Pharma, Ossur India, ADK Health Care, Credence Prosthetic India, V2U Physio Asia, International Electro Medical Company, Radimage Healthcare India, Istok New Hearing AID, Simpladent Implant Solutions, Starkey Laboratories India, Gentec Medical (12 of 1,100+ served since 2018).
A few more clients we've served in this industryHide the list
- Pharma and healthcare
- Endolite India · Mankind Pharma · Ossur India · ADK Health Care · Credence Prosthetic India · V2U Physio Asia · International Electro Medical Company · Radimage Healthcare India · Istok New Hearing AID · Simpladent Implant Solutions · Starkey Laboratories India · Gentec Medical · Cureesse Pharma · Hygiene Medicus · Nexus Surgical and Medicare
- More clients
- Meditronix Corporation · Nilkamal · Haesi GHL · GHL · Servotech Power Systems · Elektrocraft India · Happy Medicare · Anantaa Gsk Innovations · Cogmac Technologies · Aficionados Tech · Superceuticals · Truevis Technologies · 1008 Digital Health · BDS Services · Evoq Imaging Technologies · Premier Medical Systems and Devices · Riransa · Vitrag Infra Projects · Insta Biotech · Digital Acoustics · Artificial Learning Systems India · Nfilade Security Solutions · Humors Tech · K2O Consulting
Introduction
The CDSCO medical device software guidance 2026 explains how software for medical purposes is regulated in India under the Drugs and Cosmetics Act, 1940, and the Medical Devices Rules, 2017 (MDR-2017). The Central Drugs Standard Control Organization (CDSCO) issued the final guidance through a circular dated 21 July 2026. It covers standalone, embedded, connected, mobile, cloud-based, Software-as-a-Service (SaaS), artificial intelligence and machine-learning software, including in-vitro diagnostic (IVD) medical device software.
The document is important for manufacturers, overseas manufacturers, Indian authorized agents, importers, developers, innovators, researchers, sponsors and compliance teams. It explains the regulatory boundary, risk classification, licensing authority, application forms, Quality Management System (QMS), Device Master File content, clinical evidence, cybersecurity, labelling, software changes and post-market duties.
The guidance does not announce a new law, a new licensing start date or a separate compliance deadline. CDSCO expressly states that it reflects current practice under MDR-2017 and should not be treated as a new regulatory control. Businesses must therefore read it together with the Act, MDR-2017, later amendments, approval conditions and CDSCO clarifications.
Notification at a Glance
| Particular | Verified details |
| Issuing authority | Central Drugs Standard Control Organization, Medical Devices Division, Directorate General of Health Services, Ministry of Health and Family Welfare, Government of India |
| Document type | Circular issuing a final guidance document; clarificatory and awareness-oriented, not a new statutory rule |
| Date of issue | 21 July 2026 |
| Effective date | Not expressly specified |
| Governing framework | Drugs and Cosmetics Act, 1940; Medical Devices Rules, 2017; circular also refers to Gazette Notification S.O. 648(E) dated 11 February 2020 |
| Earlier consultation | Draft guidance published under File No. MED-16028/2/2024-eoffice dated 21 October 2025; stakeholder comments were reviewed before finalisation. |
| Products covered | Software that meets the medical-device definition, including standalone, embedded, connected, mobile, cloud/SaaS, AI/ML and IVD medical device software |
| Main stakeholders | Manufacturers, importers, authorised agents, developers, innovators, researchers, sponsors, laboratories, healthcare providers and procuring agencies |
| Main stakeholders | One consolidated explanation of classification, standards, QMS, licensing, technical documentation, clinical evidence, labelling, change control and PMS |
| Compliance deadline | No new general deadline. Underlying MDR-2017 timelines, license conditions and the 15-day reporting requirements described in the guidance continue to apply. |
| Nature of requirement | A mix of statutory MDR-2017 duties, CDSCO submission expectations, recommendations and good practices; each should be read according to its wording |
The Regulatory Framework and Legal Status
CDSCO's role
CDSCO is India's national regulatory authority for medical devices. Under MDR-2017, the Central Licensing Authority (CLA) handles all import licenses, all test licenses, clinical investigation and clinical performance permissions, investigational or new IVD permissions, and manufacturing licenses for Class C and Class D devices. State Licensing Authorities (SLAs) handle manufacturing licenses for Class A and Class B devices, as well as sale and distribution functions, subject to the Rules.
Why the final guidance was issued
Its stated purpose is to create a consistent understanding of regulatory submissions while supporting patient safety, product quality and market access.
What the guidance can and cannot do
What it helps clarify is: how CDSCO would like applications on MDSW to be submitted, which pathway to choose for MDSW, and how to organize the dossier and manage the lifecycle.
- What it does not replace is: The Drugs and Cosmetics Act, MDR-2017, statutory schedules, later amendments, conditions of license or CDSCO’s decisions.
- What it does not create is: an effective date, transition period, fee schedule or penalties.
What it does have is mixed language, where some items are mandatory as stated in MDR-2017, and others use "should," "may," "ideally," or "good practice."
What the Final Guidance Clarifies - and What It Does Not Change
The final document should be viewed as a compliance map rather than an amendment, as it integrates certain software-related expectations into a single document.
| Compliance area | Position clarified by the final guidance | Business meaning |
| Regulatory boundary | Medical purpose and manufacturer-intended use determine whether software is MDSW; administrative, transfer-only, and general wellness functions may remain outside the scope. | Product claims, IFU, websites and promotional material must be aligned before classification. |
| Software formats | Standalone, embedded, mobile, cloud, SaaS, AI/ML, COTS and connected software can be MDSW when they meet the definition. | Technology format does not remove a medical-purpose product from regulation. |
| Risk classification | Standalone MDSW may be assessed based on the significance of the information and the seriousness of the healthcare situation, subject to the First Schedule and confirmation under the CLA. | Classification should be supported by a documented rationale, not chosen only for commercial convenience. |
| Dossier expectations | The guidance sets out detailed content on software description, architecture, SRS, SDS, verification, validation, clinical evidence, cybersecurity, and traceability. | A generic hardware-device dossier is unlikely to adequately explain the software lifecycle. |
| AI and Indian context | Dataset composition, bias, generalisability, robustness and Indian clinical applicability should be addressed. | Developers need evidence that goes beyond model accuracy reported in a foreign or laboratory-only setting. |
| Lifecycle control | Versioning, change control, PAC, drift monitoring, vulnerabilities, FSCA, adverse-event reporting and RWE are treated as connected controls. | Regulatory work continues after the initial license or permission is granted. |
No new general obligation or deadline is stated. The guidance repeatedly sends applicants back to MDR-2017 for fees, statutory timelines, exemptions, schedules and conditions of license.
Scope and Applicability: Is the Software an MDSW?
The first test is the manufacturer's intended purpose. Software is an MDSW when it meets the medical-device definition and is intended for one or more medical purposes such as diagnosis, prevention, monitoring, treatment, alleviation, investigation of anatomy or physiology, life support, disinfection of devices, or control of conception. The guidance also recognizes the mitigation and prediction of disease or pathological conditions as medical purposes.
Software covered by MDR-2017
| Software type | Coverage position | Relevant condition |
| Standalone software | Covered | Performs a medical purpose without needing to be part of a hardware medical device. |
| Embedded software or firmware | Covered | Necessary for a hardware medical device to perform its intended use. A separate license may not be needed when licensed with the parent device; separate sale can require a separate license. |
| Device-control software | Covered | Operates, controls, or adjusts a medical device through a physical or wireless interface, such as Bluetooth or Wi-Fi. |
| Mobile, cloud or SaaS software | Potentially covered | Technology platform is irrelevant if the software has a regulated medical purpose. |
| AI/ML software | Potentially covered | Triage, screening, diagnosis, prediction, treatment, or other medical-purpose functions meet the boundary test. |
| COTS or OTS component | Depends on function | A medical-purpose COTS product can be MDSW; a non-device component inside an MDSW framework needs an impact justification. |
| Veterinary software | Covered when medical-purpose | The definition and examples include software intended for animal medical purposes. |
| IVD analyser software | Covered | Pre-installed software may be part of the analyser; separately supplied software that operates or influences it may be a distinct IVD. |
Software generally outside the guidance
- Enterprise resource planning and other software used only to manage design, manufacturing, labelling, distribution, complaints or the quality system.
- Software that only encrypts or transfers medical-device data, monitors servicing equipment, or changes data presentation for cosmetic or compatibility purposes without a medical purpose.
- Teaching, training, or educational software that is solely intended for education.
- Systems limited to storage, archive, communication, formatting, compression or simple search.
- Hospital, clinical, laboratory or image-management systems limited to administrative, storage, workflow or communication functions.
- General wellness software that supports a healthy lifestyle without disease or disorder claims and without medical or clinical measurement, screening, diagnosis, monitoring, alerting or management.
A mixed-function product needs careful separation. Non-device functions may remain outside regulatory review, but CDSCO expects clarification on whether those functions can affect the safety or effectiveness of the regulated MDSW function. An HIS, LIS, or image-management platform may become an MDSW if it adds diagnostic analysis, physiological quantification, or real-time clinical monitoring.
The Intended Use Statement Drives the Entire Pathway
The intended use statement connects the product claim to scope, risk class, evidence, labelling and post-approval change control. CDSCO says it should be clinically meaningful and clearly explain the software's role, such as decision support, device control, definitive diagnosis, or treatment recommendation.
| Element | What the applicant should define |
| Medical purpose | Diagnosis, prevention, screening, triage, monitoring, mitigation, prediction, treatment or another defined purpose. |
| Disease or condition | The specific condition and, where relevant, whether it is acute, chronic, critical, serious or non-serious. |
| Patient population | General or defined groups, including paediatric, geriatric, age, ethnicity or other relevant characteristics. |
| Intended user | Patient, caregiver, non-clinical user, technician, nurse, radiologist, physician or specialist. |
| Use environment | Home, virtual care, primary care, hospital, emergency room, operating theatre or speciality clinic. |
| Contraindications and limitations | Conditions, comorbidities, medicines, image quality or analyte variants that may produce erroneous results. |
| Inputs and outputs | Source and format of inputs; diagnostic, predictive, workflow, measurement, image or control outputs; and the clinical action they support. |
| Clinical workflow | Whether the output informs, drives or replaces a clinical action and who receives it. |
| Platform | Consumer device, cloud network, embedded system or connected hardware. |
| IVD-specific detail | Analyte, specimen, diagnostic level, limitations, qualitative or quantitative result, and self-testing or near-patient use. |
The intended use, as approved, should not change throughout the application, IFU, software user interface, website, and promotion. A new clinical claim, a new intended use, or any substantial change in the input could be considered a major change in the future.
Risk-Based Classification of Medical Device Software
MDSW is classified as Class A, B, C or D according to increasing risk. The intended use and the First Schedule of MDR-2017 control the result. Software that drives or influences a hardware medical device follows the hardware device's class. For standalone MDSW, the guidance provides a matrix that combines the seriousness of the healthcare situation with the significance of the information provided.
| Healthcare situation | Treatment or diagnosis | Drive clinical management | Inform clinical management |
| Critical | Class D | Class C | Class B |
| Serious | Class C | Class B | Class A |
| Non-serious | Class B | Class A | Class A |
How the two classification dimensions work
- Treatment or diagnosis: the output triggers or directly supports immediate or near-term treatment, prevention, mitigation, diagnosis, screening or detection.
- Drive clinical management: the output aids treatment or diagnosis, triages a patient, identifies early signs, or guides the next diagnostic or treatment intervention.
- Inform clinical management: the output provides options or aggregated clinical information without triggering an immediate or near-term action.
- Critical condition: potentially life-threatening, urgent, or involving an intervention, including vulnerable patients and specialized interventions.
- Serious condition: appropriate response is necessary to prevent unnecessary intervention or irreparable damage; however, it is not usually an urgent situation.
- Non-serious condition: progression is slow or predictable, intervention is minor, and an erroneous recommendation is more likely to be detected.
Standalone MDSW used by a non-clinical user in a serious condition without specialist support may be treated as operating in a critical situation. If several MDR-2017 rules apply, the strictest rule producing the higher class applies. CDSCO confirms the final class after reviewing intended use and design characteristics. If the software is not included in the published classification list, the applicant may seek classification through the MD Online portal.
Applicable Standards and Conformity Strategy
MDR-2017 standard hierarchy: use standards published by the Bureau of Indian Standards (BIS), or notified by the Ministry of Health & Family Welfare, India; else, use ISO, IEC or other accepted pharmacopoeial standards; failing that, use validated standards of the manufacturer. The applicability will depend on the product, its life cycle, and the associated risk.
| Standard | Main compliance role |
| IS/ISO 13485 | Quality management systems for regulatory purposes |
| IS/ISO 14971 | Application of risk management to medical devices |
| IEC/TR 80002-1 | Applying ISO 14971 to medical device software |
| IS 16124 | Systems and software engineering - software lifecycle processes |
| IS/ISO/IEC 62304 | Medical device software lifecycle processes |
| IS/IEC 82304-1 | General product-safety requirements for health software |
| IEC 81001-5-1 | Security activities across the health-software product lifecycle |
| IEC 62366-1 | Usability engineering for medical devices |
| IS 16458 / ISO/IEC 16085 | Systems and software engineering risk management |
| IS/ISO/IEC 23894 | AI risk-management guidance |
| IS/ISO/IEC 42001 | AI management systems |
| IS/ISO/IEEE 11073 | Point-of-care medical-device communication |
| ISO 24291 | Machine learning in imaging and other medical applications |
| IS/ISO/IEC 27001 | Information-security management requirements; see the source-accuracy note below regarding the title printed in the guidance |
| IS/ISO 15223-1 and 15223-2 | Symbols used with medical-device labels and information |
| IS/ISO/TR 24971 | Guidance on applying ISO 14971 |
| Other current standards | The guidance also cites IS/ISO/TS 82304-2, ISO/TR 62366-2, ISO 20417, and IS 18376/ISO/TR 20416 as examples. |
It is an indicative list and not an exhaustive one. There should be a matrix for each product attribute and risk that shows the applicable version, evidence of conformity, and any deviations.
Quality Management System and Total Product Lifecycle Controls
Manufacturers are required to have a QMS that encompasses organizational structure and the entire life cycle of the software used, including planning, design, development, configuration, installation, maintenance, and decommissioning. As far as domestic manufacturers are concerned, there will be an undertaking regarding compliance with the Fifth Schedule in a manufacturing license application.
Core QMS records for MDSW
- Software architecture, Software Requirements Specification (SRS) and Software Design Specification (SDS).
- Source code management, version control, and build and release management procedures.
- Software lifecycle, configuration, verification, validation and defect-management records.
- Risk-management plan and report integrated with change management and post-market monitoring.
- A Bill of Materials, including an SBOM for third-party, open-source and commercial components, with vulnerability monitoring.
- Procedures for performance degradation, algorithm drift, unintended outcomes, cybersecurity vulnerabilities and corrective actions.
- Evidence of performance across relevant populations, healthcare settings and deployment environments.
Cybersecurity, privacy and digital-health integration
The recommendations call for encryption of data in transit and at rest, access control, audit trails, traceability, and patient data confidentiality and integrity. Secure-by-design architecture should provide for attack surface identification, trust boundaries, and external interfaces, including API and interoperability points. Secure default configurations should deactivate any unnecessary services, ports, debugging, and interfaces. At the same time, the system should be able to operate safely during partial loss of connectivity, denial-of-service attacks, and integrity failures.
Wherever MDSW involves the creation, exchange, or display of health data, its designers and implementers must align with the guidelines of the Ayushman Bharat Digital Mission (ABDM), which include standardized exchange, consent-based access, secure information exchange, privacy in the AI lifecycle, and auditable traceability. It is also mentioned that MDSW must comply with the Digital Personal Data Protection Act, 2023.
Cloud, SaaS and on-premises deployment
- For SaaS, cloud hosting risk is assessed on a case-by-case basis. Applicants should state whether the service uses a Ministry of Electronics and Information Technology-empanelled cloud server.
- Hosted environments should have baseline controls to protect the confidentiality, integrity, and availability of safety-relevant data and functions.
- On-premises risk assessments should address local infrastructure, network security, system maintenance, access controls, backup and recovery, and software updating.
- The dossier should explain data flows, storage, network interaction, interoperability, operating systems and the degree of software autonomy.
Regulatory Pathway, Forms and Licensing Authorities
The route depends on product stage, predicate status, IVD status, risk class and whether the business manufactures in India or imports. Test-license applications are processed through the National Single Window System (NSWS); other permissions and licenses are processed through the CDSCO MD Online portal.
| Purpose | Application | Outcome | Authority | Portal |
| Manufacture for test, evaluation, demonstration, training or clinical work. | MD-12 | MD-13 | CLA | NSWS |
| Import for test, evaluation, demonstration, training or clinical work | MD-16 | MD-17 | CLA | NSWS |
| Clinical investigation of investigational MDSW | MD-22 | MD-23 | CLA | MD Online |
| Clinical performance evaluation of new IVD MDSW | MD-24 | MD-25 | CLA | MD Online |
| Import/manufacture investigational MDSW without predicate | MD-26 | MD-27 | CLA | MD Online |
| Import/manufacture new IVD MDSW | MD-28 | MD-29 | CLA | MD Online |
| Manufacture Class A or B | MD-3 | MD-5 | SLA | MD Online |
| Loan license, Class A or B | MD-4 | MD-6 | SLA | MD Online |
| Manufacture Class C or D | MD-7 | MD-9 | CLA | MD Online |
| Loan license, Class C or D | MD-8 | MD-10 | CLA | MD Online |
| Import Class A, B, C or D | MD-14 | MD-15 | CLA | MD Online |
Class A non-sterile and non-measuring devices are exempt from licensing and require registration under Chapter IIIB, as stated in the guidance. Fees are payable in accordance with the Second Schedule, but the guidance does not specify the amounts. Statutory processing timelines must be checked in MDR-2017 rather than inferred from the circular.
Test Licenses, Clinical Studies and Novel Software
Test license before commercialization
Small quantities of MDSW for testing, evaluation, demonstration, training or clinical work require the relevant test license. For software, quantity can be expressed as installations, copies or intended deployments and should be justified. A multi-site deployment request may run in parallel with the clinical-investigation application. Test-license material must not be used for commercial purposes.
Clinical investigation and IVD performance evaluation
Clinical testing of an investigational MDSW cannot be carried out without the approval of the CLA by completing the MD-23 form. A new IVD MDSW cannot carry out clinical performance testing on samples of human origin without the MD-25 form. Applications for these forms are submitted with all necessary documentation and fees in accordance with MDR-2017. Exemptions may be granted in Chapter VII, subject to the satisfaction of CLA about safety, performance and materiovigilance information, as well as lack of any probable performance difference in India.
Permission before marketing a device without a predicate
For a non-IVD investigational MDSW without a predicate device, permission is obtained via Form MD-27 following an application submitted via MD-26, before manufacture/importation for marketing. For a new IVD, MD-28 to MD-29 applies. If the investigation or performance testing took place in India, the generated data will be submitted together with the application.
Technical Documentation and Device Master File
This provides the software-specific format for the Device Master File (DMF). Each item must be justified based on its intended use, risk control, and evidence. If any of the items in Annexure A is not relevant to the case, then the justification of its non-relevance has to be provided.
Executive summary and software description
- Software name, version and the meaning of each version field.
- Operational features, programming language and compiler versions, hardware platform, operating system, COTS/OTS components and development lifecycle.
- Intended user, patient population, use environment, analytical method and degree of autonomy.
- Input source and format, output type and format, output recipient, data flow, network interaction, cloud storage and interoperability specifications.
- Clinical workflow role, limits on the output and the healthcare professional's remaining responsibility.
- Usability and human-factor validation reflecting Indian workflows, languages, user training and infrastructure constraints.
- Installation, update, correction and change-management infrastructure, including autonomous or externally controlled learning.
Predicate comparison
Where a predicate exists, the comparison should be tabular and cover intended use, risk class, architecture and algorithm, platform, input data, output, intended users and environment, training methodology, standards, performance metrics, safety, effectiveness and cybersecurity. Differences need scientific justification showing that they do not adversely affect safety, performance or effectiveness. No suitable predicate may place the product on the investigational or new IVD route.
Architecture, SRS, SDS and traceability
Architecture diagrams should show modules, layers, relationships, external products, IT infrastructure, peripherals, APIs and data flows. The SRS describes what the software must do; the SDS shows how the design implements those requirements. The documents should trace to intended use, risk management, safety, effectiveness, verification and validation. Version history should record the tested version, date, and changes from the previous version, so that affected users can be located during a Field Safety Corrective Action (FSCA).
Verification and validation
- Provide the software design and development process, and evidence validating the finished device version.
- Explain any difference between the tested version and released version and assess the safety and effectiveness impact.
- Report verification, validation, and testing across all labelled hardware configurations and operating systems.
- Validate interoperability where the MDSW works with other devices or systems.
- Verify that cybersecurity controls align with documented design requirements before release.
When using AI for MDSW, details on the composition, demographics, geographic locations, patient diversity, and the nature of the dataset used for training, validation, and testing must be provided.
Risk Management and Algorithm Change Protocol
MDSW can result in both direct and indirect harm. In the case of indirect harm, the output is incorrect, late, or misleading, leading to a harmful decision, rather than a failure of the physical device itself. Risk assessment in this regard requires consideration of a wide range of factors.
Risk domains to address
- Incorrect diagnosis, false positives or negatives, treatment recommendations, control failures and delayed care.
- Bias, poor generalisability, lack of explainability, model drift, AI hallucination and unsafe algorithm updates.
- Poor-quality or unrepresentative data, data corruption, sensor integrity and privacy breaches.
- User misuse, poor training, UI/UX errors, installation failures and workflow disruption.
- Cybersecurity vulnerabilities, cloud outages, interoperability failures and hardware-software integration problems.
- Performance variation across populations, facilities, operating systems and resource-constrained settings.
When an Algorithm Change Protocol is useful
For software that is modified or retrained, the manufacturer may include an Algorithm Change Protocol (ACP) in the risk-management file. The guidance describes five useful components: a data management plan; a performance evaluation and monitoring plan; a retraining plan; a software update plan; and a rollback plan. The ACP does not remove post-approval change obligations. A major change still requires approval and a minor change still requires notification to the licensing authority.
Clinical Evidence and Validation for Indian Use
The evidence for the software should demonstrate its scientific validity and technical/analytical performance with respect to its intended use. The following types of evidence could be used: technical standards, literature, guidelines, systematic reviews, clinical investigations, clinical performance studies, clinical data, and secondary data analyses.
- Scientific validity or clinical association: show that the output corresponds to the disease, condition, indication, analyte or parameter in the intended purpose.
- Technical or analytical performance: show that the software accurately, reliably and precisely produces the intended output from the specified input.
- Performance in clinical context: demonstrate relevance of the output to the clinical context.
- Applicability in India: explain why foreign-developed or foreign-validated models are being used, and when relevant, complement with validation in the Indian context.
- Equity and robustness: consider clinical differences across demographic, geographic, language and health-care system contexts.
- RWE: real-world evidence or post-market study evidence can provide support for safety/performance when available.
For AI-enabled MDSW, accuracy alone is not enough. The dossier should address dataset provenance, population representation, bias, robustness, drift and the relationship between the model output and actual clinical workflow.
Software Labelling, e-IFU and Version Traceability
The DMF should contain labels, instructions for use, user or prescriber manuals, product brochures and promotional material required by Chapter VI of MDR-2017. The software must be identifiable through version, revision level and build or release date.
| Labelling element | Guidance expectation |
| Product identity | MDSW name and hardware-device name where applicable. |
| Version control | Version/build number and manufacturing or release date. |
| Responsible entity | Manufacturer name and address; license or registration details. |
| Use information | Intended use, indications, IFU, limitations, storage or handling conditions where relevant. |
| Physical supply | Each packaging level bears the required particulars when supplied on media such as CDs or DVDs. |
| Digital supply | Electronic IFU may be accessible through the software, a web address or another clear route. |
| App stores | Regulatory particulars may be shown on the landing page or via a link, and reflected in the app store screenshot. |
| No user interface | Middleware should be able to transmit label information via an API. |
Downloadable software should include an installation guide or procedure and a reliable download route. Access-right controls and version-control systems should enable timely tracing of the installed version for each user or deployment.
Post-Approval Changes: Major vs Minor
Software modifications are made continuously during maintenance. The licensee shall determine the type of modification and file the relevant post-approval change (PAC) via MD Online. The Sixth Schedule provides the statutory guidance.
| Change type | Examples in the guidance | Regulatory treatment |
| Major | New clinical claim; new intended use; new data-input type; design or version change affecting safety, effectiveness, risk controls or performance; relevant entity/site change; most label changes; quality-affecting process or test change. | Prior approval from the CLA or SLA, as applicable. |
| Minor | Non-quality-affecting design/process/test changes; bug fixes and security patches that do not affect intended use, safety or performance; version changes without such impact; performance re-tuning within validated ranges. | Notification to the CLA or SLA, as applicable. |
| Change in firm constitution | Treated as a major change in the guidance. | Notify within the MDR-2017 timeline and submit a fresh application for a new license. |
| Change under an approved ACP | Algorithm or software change within the planned protocol. | Still requires a PAC approval request or notification; the ACP is not an automatic exemption. |
Impact assessment, which shall be documented, shall link all modifications to intended use, hazards, clinical data, validation, cybersecurity, labelling, and installed software versions. It doesn’t matter what the developer names this version - major or minor. The main thing is modifying the safety and performance profile.
Post-Market Surveillance, Vigilance and Recall
After commercialization, companies will need to assess direct/indirect risks, reduced effectiveness, and security vulnerabilities. The PMS program needs to be commensurate with the risk class and should address complaints, adverse events, patches, AI drift, and cybersecurity.
Controls expected in the PMS system
- Continuous monitoring of safety, effectiveness, accuracy, and clinical performance.
- Logging of model drift, error rates, false outputs, hallucinations, clinical safety signals and user feedback for AI/ML products.
- Procedures for nonconforming software, correction, corrective action, preventive action and containment of affected versions.
- Indian real-world evidence collection where feasible and performance checks across intended populations and settings.
- Mechanisms for customer and user feedback, field safety corrective action, software patches, cyber alerts and product recall.
- Ability to halt distribution and uninstall or decommission affected software across relevant channels, networks or devices.
Important reporting timelines are stated in the guidance
- The license holder must inform the SLA or CLA of a suspected unexpected serious adverse event and the action taken, including recall, within 15 days after it comes to the license holder's notice.
- An importer must inform the licensing authority within 15 days of an overseas administrative action arising from an adverse reaction, such as withdrawal, restriction, cancellation or a not-of-standard-quality determination.
- The manufacturer or importer must immediately inform the SLA or CLA where there is reason to believe marketed MDSW may be unsafe for patients.
The vigilance protocol must cover serious adverse events and malfunctions contributing to death or serious injury. Manufacturers may also report through the Materiovigilance Programme of India. Products approved after clinical investigation may require Periodic Safety Update Reports under MDR-2017, covering new safety information, exposure, global authorization status, and proposed changes to product information.
Annexure A: Application-Specific Document Checklists
Annexure A has 15 checklists from A to O. They do not form one universal dossier. Each appropriate checklist will be determined by whether the application relates to medical devices or IVDs, manufacturing or importing, testing or marketing, and predicates and risk classification.
| Checklist | Application | Purpose |
| A | MD-12 | Test license to manufacture medical device |
| B | MD-12 | Test license to manufacture IVD |
| C | MD-16 | Test license to import medical device |
| D | MD-16 | Test license to import IVD |
| E | MD-22 | Clinical investigation of investigational medical device |
| F | MD-24 | Clinical performance evaluation of new IVD |
| G | MD-26 | Import/manufacture medical device without predicate |
| H | MD-28 | Import/manufacture new IVD without predicate |
| I | MD-3 | Manufacture Class A medical device, excluding Class A non-sterile and non-measuring |
| J | MD-3 | Manufacture Class B medical device |
| K | MD-3 | Manufacture Class A or B IVD |
| L | MD-7 | Manufacture Class C or D medical device |
| M | MD-7 | Manufacture Class C or D IVD |
| N | MD-14 | Import medical device |
| O | MD-14 | Import IVD |
Recurring document groups
- Covering letter, legal form, fee challan and constitution documents.
- Plant or Site Master File, premises information, organization chart and qualified-personnel details where applicable.
- QMS undertaking, quality manual, document and record controls, internal audit, nonconformity and CAPA records.
- DMF, intended use, specifications, essential-principles checklist, risk analysis, design, verification, validation, clinical evidence and PMS data.
- Labels, IFU, product insert and software version release certificate, release note or release report.
- Import-specific Power of Attorney, authorised-agent documents, site registration, Free Sale Certificate, inspection/audit records and QMS certificates, as applicable.
- Analytical Performance Characteristics for IVD, Specificity, Sensitivity, Reproducibility, Stability, Performance Evaluation & Batch Information, as applicable.
Two Annexure notes matter: a non-applicable item needs a detailed reason, and cybersecurity verification or human-factor validation documents may be placed within the verification-and-validation section. The applicant should also check the current portal checklist and Tooltips because the guidance directs users to those operational sources.
Impact on Businesses
| Stakeholder | Immediate impact | Operational or cost effect | Priority concern |
| Indian manufacturers | More software-specific QMS, DMF, lifecycle and PMS evidence | Development, quality, clinical and regulatory teams must work from one traceability model | Correct scope, class and license route |
| Overseas manufacturers and Indian agents | Import dossier, authenticated PoA, QMS and global regulatory evidence | Coordination across legal manufacturer, site and authorised agent | Consistency of versions, labels and certificates |
| AI/ML developers | Dataset disclosure, bias, robustness, drift and change-control expectations | Additional validation, monitoring and governance work | Indian applicability and safe model updates |
| Cloud and SaaS providers | Hosting, security, availability and data-flow risks enter the dossier | Architecture, vendor, backup and access-control documentation | MeitY empanelment status and safety-relevant controls |
| IVD software businesses | Separate CPE, new-IVD and analytical evidence pathways | More specimen, performance and laboratory documentation | Correct MD-24/25 and MD-28/29 routes |
| Hospitals and procurers | Implementation, interoperability, consent and traceability influence safe deployment. | Procurement and IT controls must match the approved use environment | Avoid deploying unlicensed or materially changed versions |
| MSMEs and startups | Earlier regulatory planning becomes more important | Specialist evidence and QMS work can increase time and resource needs | Do not code to launch before fixing intended use and classification |
The likely commercial effect is a greater burden of documentation and lifecycle governance, especially for adaptive AI, multi-platform, and cloud products. The same structure can reduce avoidable filing gaps, support safer releases, and make responsibilities clearer across engineering, clinical, quality, and regulatory teams. These are likely implications, not guaranteed outcomes.
Challenges, Benefits and Business Opportunities
Likely implementation challenges
- Translating a product narrative into a precise intended use without unintentionally expanding the risk class.
- Building traceability across requirements, design, code, hazards, tests, clinical evidence, labels and deployed versions.
- Generating representative evidence for Indian populations and care settings.
- Maintaining an SBOM and vulnerability process for open-source and third-party components.
- Separating regulated and non-regulated functions in a mixed software platform.
- Classifying frequent releases, bug fixes, security patches, retraining, and model re-tuning as major or minor changes.
Genuine benefits of the clarified approach
- A clearer boundary between general health, administration and medical-purpose software.
- A transparent relationship between intended use, risk class, evidence and licensing authority.
- More consistent expectations for AI/ML, cloud, interoperability, cybersecurity and post-market monitoring.
- A software-specific DMF structure that can be built alongside development rather than after launch.
- Stronger version traceability during patching, field safety action or recall.
Business opportunities created
The document may increase demand for medical-device regulatory consulting, software QMS implementation, clinical and analytical validation, cybersecurity verification, human-factors validation, cloud risk assessment, technical writing, PMS systems and testing coordination. These are service opportunities created by clearer expectations; the guidance does not promise market size, revenue, or approval.
What Businesses Should Do Next
- Freeze a precise intended-use statement and align it across product requirements, IFU, interface, website, and promotional claims.
- Document why the product is or is not MDSW, including the effect of any COTS, administrative or non-device functions.
- Build a risk-classification rationale under the First Schedule and check CDSCO's published software classification list; seek CLA classification where needed.
- Map the product stage and business model to the correct form, outcome, authority and portal before paying fees or preparing certificates.
- Run a dossier gap assessment covering legal documents, Site/Plant Master File, QMS, DMF, standards, risk management, cybersecurity, usability, verification, validation, clinical evidence and labelling.
- For AI/ML, document dataset provenance, representation, use of synthetic data, bias, robustness, Indian applicability, drift controls, and retraining governance.
- For cloud or connected products, document architecture, data flows, SBOM, vulnerabilities, secure defaults, access control, backup and recovery, availability, and interoperability.
- Create a release and PAC decision process that classifies every change, keeps validation evidence, and links deployed versions to users or sites.
- Operate a risk-based PMS and vigilance system with the 15-day and immediate reporting triggers stated in the guidance.
- Before submission, reconcile the final dossier with the current MDR-2017 text, portal checklist, Tool Tips, and any subsequent CDSCO clarifications.
How Corpseed Can Help
Corpseed can support manufacturers, importers, authorized agents, and software developers that need a medical device regulatory consultant for an India market-entry or lifecycle-compliance project. The engagement should begin with product scope and evidence, not with a promise of approval.
- MDSW applicability and medical-purpose assessment, including mixed-function and general-wellness boundary review.
- Risk-classification rationale and CDSCO classification-query support.
- Manufacturing, import, test-license and investigational/new-IVD pathway mapping.
- CDSCO application and legal-document coordination for the relevant MD form.
- QMS and compliance gap assessment for software lifecycle, versioning, CAPA and PMS controls.
- DMF, intended-use, predicate comparison, risk-management and technical-document review.
- Testing, clinical/performance evidence and laboratory coordination where the selected pathway requires it.
- Cybersecurity, SBOM, cloud risk, AI/ML evidence, and post-approval change readiness review.
Corpseed's role is to help organize the regulatory pathway, evidence and submission package. The licensing authority decides classification, permissions and licenses, and may request further information or impose conditions.
For medical device compliance services linked to MDSW, businesses can request a document-specific assessment covering the product's intended use, risk class, deployment model, evidence and planned India route.
About the Author
Mahek Sancheti
Content WriterMahek Sancheti, BAJMC graduate with a deep passion for writing. As a content writer, video content creator, creative content creator, and scriptwriter, I bring stories to life through words and visuals. I honed my skills by working with a prominent news agency, where I excelled in crafting compelling narratives and engaging content. Coming from a journalism and mass communication background I have skills to craft engaging narratives that captivate audiences. With a keen interest in writing and creativity, I aim to deliver impactful and meaningful content that resonates with diverse audiences.
https://www.linkedin.com/in/mahek-sancheti-837196212