CDSCO Medical Device Software Guidance 2026: MDSW Classes, Portals & Change Protocols

Digital health developers, artificial intelligence (AI) medtech innovators, and multinational medical device manufacturers entering the Indian healthcare market face an evolving regulatory environment. On 21 July 2026, the Central Drugs Standard Control Organization (CDSCO), under the Ministry of Health and Family Welfare (MoHFW), Directorate General of Health Services, Government of India, released its comprehensive 62-page guidance document: Guidance Document on Medical Device Software (Document No. CDSCO/MD/GD/MDSW/01/2026).

For regulatory affairs (RA), quality assurance (QA), and digital product leads, the immediate question is whether this publication represents a new software statute, how standalone software (SaMD) and hardware-driving software (SiMD) are classified across Classes A through D, which online portals manage test versus commercial filings, and whether an Algorithm Change Protocol (ACP) is mandatory like an FDA Predetermined Change Control Plan (PCCP).

The Core Direct Answer: CDSCO's Guidance Document on Medical Device Software (CDSCO/MD/GD/MDSW/01/2026) is not a new regulatory control or standalone software law. Section 2.0 explicitly clarifies that the document reflects current regulatory practices under the Drugs and Cosmetics Act, 1940 and the Medical Devices Rules, 2017 (MDR-2017). The document's legal notice establishes that it is intended for public awareness and guidance, while statutory obligations remain rooted in MDR-2017.

Under the 2026 CDSCO framework:

• MDSW Scope: Medical Device Software (MDSW)—which includes in vitro diagnostic (IVD) software—covers any software intended by its manufacturer for a medical purpose (diagnosis, prevention, monitoring, treatment, or alleviation of disease or physiological processes). General wellness, fitness, and lifestyle apps are excluded only if they have no medical intended purpose; software measuring, estimating, or analyzing physiological parameters for clinical screening, diagnosis, or monitoring is regulated MDSW. Hospital Information Systems (HIS), Laboratory Information Systems (LIS), and Electronic Health Records (EHR) remain non-device health IT unless they execute medical algorithms, image analysis, or automated clinical decision support.
• Classification: All MDSW is classified under the First Schedule. If standalone, Table 2 may be referred (treatment/diagnosis vs drive vs inform, against critical/serious/non-serious). Software that drives or influences hardware takes that hardware's class. If several First Schedule rules apply, the strictest class governs. Standalone MDSW for non-clinical users in a "serious" situation, without specialised professional support, may be considered as used in a "critical" situation.
• Two-Portal Architecture: All applications for Test Licences (Form MD-12/MD-13 for domestic manufacturing; Form MD-16/MD-17 for import) must be submitted via the National Single Window System (NSWS). All other manufacturing, import, clinical-investigation, and sale-or-distribution applications must be submitted via the Online System for Medical Devices (cdscomdonline.gov.in).
• Licensing Authorities: Central Licensing Authority (CLA) oversees all test licences, all import licences (Class A–D), clinical investigations, and Class C/D domestic manufacturing. State Licensing Authorities (SLA) govern Class A/B domestic manufacturing and sale/distribution. Class A non-sterile and non-measuring devices are licence-exempt and need Chapter IIIB registration for commercialisation; do not generalise that exemption to measuring software or to Class B–D.
• Algorithm Change Protocols (ACP): An ACP may be devised, wherever applicable, based on the nature and risks associated with the MDSW, and may be placed in the Risk Management File. Unlike the US FDA Section 515C PCCP, CDSCO's ACP is not written as a mandatory pre-authorization for every AI/ML device.
• Costs: There is no separate "CDSCO MDSW fee." Government fees are strictly those established in the Second Schedule of MDR-2017 for the corresponding statutory forms. Authorized Indian Agent (AIA) representation, technical dossier authoring, Software Bill of Materials (SBOM) maintenance, and cloud hosting represent independent operational and engineering costs.

This operating manual breaks down the 62-page official PDF: qualification boundaries, the Table 2 standalone classification matrix, portal routing rules, Table 5 authority divisions, the Chapter IIIB registration trap, cybersecurity and SBOM expectations, the ACP framework, and post-market surveillance duties.

---

Status Summary: 2026 CDSCO Medical Device Software Framework

Dimension	Regulatory Position under CDSCO/MD/GD/MDSW/01/2026
Official Document	CDSCO Guidance Document on Medical Device Software, Doc No. CDSCO/MD/GD/MDSW/01/2026
Publication Date	Listed on CDSCO Medical Device & Diagnostics portal on 21 July 2026 (62 pages + Annexure A)
Statutory Authority	Drugs and Cosmetics Act, 1940 & Medical Devices Rules, 2017 (MDR-2017)
Legal Character	Interpretive operational guidance. Section 2.0 states it is not a new regulatory control
IVD Scope	MDSW encompasses IVD medical device software across all sections unless explicitly noted
Test Licence Portal	National Single Window System (NSWS) for Form MD-12/13 and MD-16/17
Commercial Portal	Online System for Medical Devices (cdscomdonline.gov.in) for all commercial & clinical filings
Classification Model	Table 2 (Significance of Info × Healthcare Situation) for SaMD; hardware class for SiMD
Lay User Elevation	Standalone MDSW used by laypersons in serious conditions may be treated as critical (higher class)
Class A Exemption	Class A Non-Sterile, Non-Measuring (NSNM) devices require Chapter IIIB registration only; measuring software requires licensing
AI/ML Change Control	Algorithm Change Protocol (ACP) may be devised, wherever applicable, in the Risk Management File
Government Fees	Standard MDR-2017 Second Schedule statutory fees; no standalone CDSCO software tariff
QMS & Standards	Fifth Schedule QMS; Rule 7 BIS-then-ISO/IEC-then-manufacturer hierarchy; Table 3 standards may be applicable (including IS/ISO/IEC 62304, IS/ISO 14971, IEC 81001-5-1)

---

Is CDSCO/MD/GD/MDSW/01/2026 a New Software Law, or a Map of MDR-2017?

A frequent misconception across trade press and industry commentary is that CDSCO created a new statutory category or a separate software approval pathway on 21 July 2026. This is legally incorrect.

The official PDF's opening public notice states:

"This guidance document is aimed only for creating public awareness about Regulations of Medical Device Software and is not meant to be used for legal or professional purposes. The readers are advised to refer to the statutory provisions of Drugs and Cosmetics Act and the Medical Devices Rules, 2017 and respective Guidelines/Clarifications issued by CDSCO from time to time for all their professional needs."

Section 2.0 (Scope) then states:

"This Guidance Document reflects current practices under the MDR-2017 and should not be misconstrued as a new regulatory control on MDSW (including In vitro Diagnostic (IVD) MDSW)."

Layer	What it is	What it is not
Drugs and Cosmetics Act, 1940	Statute that defines a medical device (including Section 3(b)(iv) notified devices)	A software-specific approval pathway
Medical Devices Rules, 2017	Subordinate legislation: First Schedule (class), Second Schedule (fees), Fourth Schedule (dossier), Fifth Schedule (QMS), Chapter IIIB (Class A NSNM registration), and the licence forms	Optional guidance that can be ignored because a 2026 PDF exists
CDSCO/MD/GD/MDSW/01/2026 (listed 21 July 2026)	Official map of how those rules apply to MDSW: portals, Tables 1–5, optional ACP, SBOM, and post-market notes	A new software statute or a separate "2026 MDSW approval"

The document is an official technical and procedural interpretation of how existing MDR-2017 provisions apply to software. Manufacturers do not apply for a "2026 MDSW Approval"; they apply for statutory MDR-2017 manufacturing licences, import licences, test licences, or Chapter IIIB registrations using the forms and portals mapped in the guidance.

For broader context on how India regulates medical hardware and IVDs, see India CDSCO Medical Device Registration Guide and the empirical market landscape in India CDSCO Medical Device Market & Approved Devices Analysis.

---

Which Software Is MDSW, and When Are Wellness, HIS, LIS, or ERP Out of Scope?

Qualification is the first gate in the CDSCO digital health lifecycle. Software is classified as Medical Device Software (MDSW) when it meets two cumulative criteria:

1. It is software intended by the manufacturer to be used for one or more medical purposes specified in Section 3(b) of the Drugs and Cosmetics Act, 1940 and MDR-2017; and
2. It performs functions such as diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease, injury, disability, or physiological processes.

MDSW encompasses standalone software (Software as a Medical Device, or SaMD), software embedded in or driving a physical device (Software in a Medical Device, or SiMD), and in vitro diagnostic medical device software (IVD MDSW).

Question	If yes	If no
Does the manufacturer intend a medical purpose that meets the medical-device definition (diagnosis, prevention, monitoring, treatment, or related limbs)?	Continue: it is MDSW if the definition is met.	Out of scope, provided it is not intended for a medical purpose.
Does the software drive or influence hardware that is itself a medical device?	Classify in the same class as that hardware (First Schedule).	If standalone, Table 2 may be referred in addition to the First Schedule.
Is it general wellness, fitness tracking, ERP, or HIS/LIS/IMS with no medical function?	Out of scope under Section 5.2, subject to the notes below.	If HIS/LIS/IMS adds image analysis as an aid in diagnosis, quantification of physiological parameters, or similar medical functions, it may be a device.

The General Wellness Boundary

Section 5.2 and Section 2.0 draw a strict boundary between regulated medical software and unregulated general wellness products:

Software Category	Core Characteristics	Regulatory Status under CDSCO
General Wellness & Fitness	Tracks general activity (steps, distance), encourages hydration, logs exercise routines, general relaxation, or non-clinical sleep duration tracking without medical claims.	Out of Scope (Non-medical device)
Physiological Parameter Monitoring	Measures, estimates, or records heart rate variability, SpO2, blood pressure, ECG waveforms, or glucose trends intended for screening, disease detection, or clinical alerting.	MDSW (Regulated Device)
Administrative Health IT (HIS/LIS/EHR)	Patient registration, bed management, billing, inventory control, basic appointment scheduling, archiving, and transmission of lab results without interpretive algorithms.	Out of Scope (Non-medical device)
Diagnostic & Decision-Support IT	LIS/EHR modules that execute algorithmic diagnostic scoring, interpret genomic variants, flag abnormal imaging lesions, or recommend drug dosages.	MDSW (Regulated Device)
Digital Therapeutics (DTx)	Software providing evidence-based cognitive behavioral therapy for clinical psychiatric conditions, rehabilitation protocols, or automated insulin dosing.	MDSW (Regulated Device)

A critical enforcement principle emphasized by CDSCO is that disclaimers do not override functionality or marketing claims. Labeling an application as "for fitness purposes only" will not exempt it from regulation if the software analyzes ECG rhythms to detect atrial fibrillation or calculates clinical risk scores for cardiovascular events.

For international comparisons of software qualification boundaries across the FDA, European Union, and other jurisdictions, see What Is Software as a Medical Device? and Software as a Medical Device Regulation Compared Globally.

---

Recommended Reading

MHRA Ambient Voice Technology 2026: When an AI Scribe Is a Medical Device in Great Britain

Digital Health & AI SaMD2026-08-27 · 37 min read

How Does Table 2 Classify Standalone MDSW, and When Does Software Take the Hardware's Class?

India's MDR-2017 establishes four risk classes under Rule 4:

• Class A: Low risk.
• Class B: Low-moderate risk.
• Class C: Moderate-high risk.
• Class D: High risk.

Section 7.1 requires all MDSW to be classified using the First Schedule. Software intended for driving or influencing hardware takes that hardware's class. If the MDSW is standalone, Table 2 may be referred in addition to the First Schedule. Table 2 is a classification aid, not a substitute for Rule 4 or the CLA's published lists.

CDSCO Table 2: Risk classification of standalone MDSW

State of healthcare situation or condition	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

Source: CDSCO/MD/GD/MDSW/01/2026, Table 2. The table's own note states that standalone MDSW intended for non-clinical users in a "serious situation or condition," without support from specialised professionals, may be considered as used in a "critical situation or condition."

Standalone MDSW (SaMD) Classification via Table 2

For standalone software, CDSCO Table 2 uses a two-dimensional matrix that is structurally similar to the International Medical Device Regulators Forum (IMDRF N12) framework. Table 2 is still an Indian First Schedule aid, not an instruction to copy N12 as Indian law:

1. State of the Healthcare Situation or Condition:

   • Critical Condition: Life-threatening, irreversible deterioration, or requiring urgent intervention (e.g., stroke triage, acute myocardial infarction, malignant neoplasm detection).
   • Serious Condition: Major impact on health, moderate progression, or requiring timely clinical management (e.g., chronic kidney disease staging, diabetic retinopathy screening, non-critical fractures).
   • Non-Serious Condition: Mild, self-limiting, or slowly progressing conditions where accurate intervention is not immediately time-critical (e.g., mild dermatological tracking, basic posture assessment).

2. Significance of the Information Provided by the MDSW:

   • Treat or Diagnose: The software output directly initiates clinical treatment, guides therapeutic intervention, or establishes a definitive primary diagnosis.
   • Drive Clinical Management: The software output guides the next clinical step, aids in triage, optimizes treatment dosing, or flags urgent diagnostic referrals.
   • Inform Clinical Management: The software aggregates, formats, or presents reference data, standard guidelines, or general clinical information to assist healthcare professionals.

The Non-Clinical Lay User Escalation Rule

The Table 2 note, quoted, is:

Standalone MDSW intended to be used by non-clinical users in a "serious situation or condition" as described here, without the support from specialized professionals, may be considered as a MDSW used in a "critical situation or condition". It may, hence, influence the risk classification of the MDSW.

If that note applies, the class may move with the critical column of Table 2:

• Inform clinical management in a serious situation: Class A → Class B.
• Drive clinical management in a serious situation: Class B → Class C.
• Treat or diagnose in a serious situation: Class C → Class D.

Software in a Medical Device (SiMD) and the Strictest Rule

For software that is incorporated into, drives, controls, or directly influences a physical medical device (SiMD):

1. The Hardware Rule: The software automatically inherits the risk classification of the physical hardware medical device as determined under the First Schedule of MDR-2017.
2. The Strictest Rule: If multiple classification rules within the First Schedule apply to different functions or modules of a software system, the highest (strictest) resulting classification governs the entire product.
3. Dynamic Classification Confirmation: CDSCO maintains dynamic classification lists on the Online System for Medical Devices. If a novel software product is not listed, the applicant must submit an application via cdscomdonline to obtain formal CLA classification confirmation before commercial filing.

---

Do Test Filings Go to NSWS and Commercial Filings to cdscomdonline?

One of the most consequential operational directives in the 2026 guidance is the strict separation of digital portal routes. Submitting an application through the wrong portal results in administrative rejection and launch delay.

Filing objective	Portal	Application → licence	MDR-2017 rule cited in the guidance
Manufacture small quantities for clinical investigation, test, evaluation, demonstration, or training (not commercialisation)	NSWS (www.nsws.gov.in)	Form MD-12 → MD-13	Rule 31; fee in the Second Schedule
Import small quantities for the same test/evaluation purposes	NSWS	Form MD-16 → MD-17	Rule 40; fee in the Second Schedule
Commercial manufacture, Class A and B	cdscomdonline	Form MD-3 (loan MD-4) → MD-5 (loan MD-6)	SLA
Commercial manufacture, Class C and D	cdscomdonline	Form MD-7 (loan MD-8) → MD-9 (loan MD-10)	CLA
Commercial import, all classes	cdscomdonline	Form MD-14 → MD-15	CLA
Clinical investigation of an investigational medical device	cdscomdonline	Form MD-22 → MD-23	CLA
Clinical performance evaluation of a new IVD	cdscomdonline	Form MD-24 → MD-25	CLA
Sale and distribution	cdscomdonline / State	Table 5 assigns SLA for all classes	Not a test-licence filing

The Two-Portal Routing Framework

1. National Single Window System (NSWS - www.nsws.gov.in):

   • Exclusively for Test Licences.
   • Domestic Software Testing & Evaluation: Application in Form MD-12 to obtain a Test Licence in Form MD-13 under Rule 31 of MDR-2017.
   • Import for Testing, Evaluation, Demonstration, or Clinical Investigation: Application in Form MD-16 to obtain an Import Test Licence in Form MD-17 under Rule 40 of MDR-2017.

2. Online System for Medical Devices (cdscomdonline - www.cdscomdonline.gov.in):

   • For all Commercial, Clinical, and Sale/Distribution Filings.
   • Commercial Import (Class A, B, C, D): Application in Form MD-14 to obtain an Import Licence in Form MD-15.
   • Domestic Commercial Manufacturing:
     • Class A & B: Application in Form MD-3 (or loan licence MD-4) to obtain Form MD-5 (or MD-6) from the State Licensing Authority.
     • Class C & D: Application in Form MD-7 (or loan licence MD-8) to obtain Form MD-9 (or MD-10) from the Central Licensing Authority.
   • Clinical Investigations & Performance Evaluations: Application in Form MD-22 (Investigation) or Form MD-24 (IVD Performance Evaluation) leading to Form MD-23 or Form MD-25.
   • Registration for Sale & Distribution: Wholesale/distribution registration applications.

---

When Is CLA the Licensing Authority, and When Is SLA?

Section 11.0 and Table 5 define the precise division of regulatory jurisdiction between the Central Licensing Authority (headed by the Drugs Controller General of India, CDSCO HQ, New Delhi) and the respective State Licensing Authorities across India's states and union territories.

Table 5: Licensing Authority Division for Medical Device Software

Regulatory Activity	Device Risk Class	Regulatory Authority	Application Form	Granted Licence Form	Governing Portal
Manufacture for Test/Evaluation	Class A, B, C, D	CLA	Form MD-12	Form MD-13	NSWS
Import for Test/Evaluation	Class A, B, C, D	CLA	Form MD-16	Form MD-17	NSWS
Commercial Domestic Manufacture	Class A & Class B	SLA	Form MD-3	Form MD-5	cdscomdonline
Commercial Domestic Manufacture	Class C & Class D	CLA	Form MD-7	Form MD-9	cdscomdonline
Loan Licence (Domestic)	Class A & Class B	SLA	Form MD-4	Form MD-6	cdscomdonline
Loan Licence (Domestic)	Class C & Class D	CLA	Form MD-8	Form MD-10	cdscomdonline
Commercial Import	Class A, B, C, D	CLA	Form MD-14	Form MD-15	cdscomdonline
Clinical Investigation (Medical Device)	Class A, B, C, D	CLA	Form MD-22	Form MD-23	cdscomdonline
Performance Evaluation (New IVD)	Class A, B, C, D	CLA	Form MD-24	Form MD-25	cdscomdonline
Sale and Distribution	Class A, B, C, D	SLA	Confirm current State sale-registration form	Confirm current State sale-registration form	cdscomdonline / State

Key takeaways from Table 5:

• CLA maintains exclusive jurisdiction over all import licences, all test licences, and clinical investigation / new-IVD performance-evaluation permissions, for every class.
• SLA grants Class A and Class B domestic manufacturing licences. Class C and Class D domestic manufacturing sits with CLA.
• Sale and distribution sit with SLA for every class. Table 5 itself does not print form numbers for sale; wholesale/premises registration commonly uses Form MD-41 leading to MD-42 under the later MDR-2017 sale-registration overlay. Confirm the current state process rather than treating MD-41/42 as a Table 5 row.
• Table 5 also assigns MSC/NCC, free-sale certificates (manufacturing), and special/neutral/risk-classification codes; those are not a substitute for the manufacturing or import licence.

---

Recommended Reading

ISO 80369 Small-Bore Connector Conversion: 510(k), FDA Windows & Particular Parts

Regulatory 510(k)2026-08-29 · 23 min read

Is Class A Non-Sterile Non-Measuring Software Licence-Exempt Registration Only?

A critical operational distinction in Indian medical device law is the regulatory relief provided under Chapter IIIB (Rules 19A through 19F) of MDR-2017.

The Chapter IIIB Exemption and the "Measuring" Trap

Table 5 NOTE (ii) states:

"Class A (non-sterile and non-measuring) medical device is exempted from the Licensing requirements, only registration is required as per Chapter IIIB of MDR-2017 for its commercialization."

Chapter IIIB (inserted by G.S.R. 777(E) dated 14 October 2022) is a registration regime, not a manufacturing or import licence. The MDSW PDF does not describe "instant" auto-issuance or a waiver of Device Master File / Plant Master File upload. Treat the exemption as limited to Class A devices that are both non-sterile and non-measuring.

Class A software fact pattern	Next filing	Why
Non-sterile and non-measuring (for example, a basic viewer with no measurement or diagnostic algorithm)	Chapter IIIB registration for commercialisation	Table 5 NOTE (ii)
Measuring, calculating, estimating, or reporting physiologic values for screening, diagnosis, monitoring, alerting, or management	Full licence: Form MD-3/MD-5 (domestic) or Form MD-14/MD-15 (import)	Wellness NOTE (ii) in the PDF; measuring function is not NSNM
Class B, C, or D	Full statutory licence; Chapter IIIB is not available	Table 5 NOTE (ii) is Class A NSNM only

Why Most Digital Health Software Cannot Use Chapter IIIB

Manufacturers frequently make the mistake of assuming that all Class A standalone software qualifies for Chapter IIIB registration. This is incorrect:

1. Measuring Functionality: If software measures, calculates, estimates, or quantifies any physiological parameter (e.g., calculating heart rate variability, measuring Cobb angles on digital spine X-rays, estimating lesion dimensions), it possesses a measuring function.
2. Mandatory Licensing: Class A software with a measuring function is not exempt from licensing. It must undergo full licensing via Form MD-3 (domestic manufacture) or Form MD-14 (import), including complete technical documentation review.
3. Class B, C, and D Software: All Class B, C, and D software products require full statutory licensing and cannot use Chapter IIIB under any circumstances.

---

Is an Algorithm Change Protocol Mandatory Like an FDA PCCP?

With the rapid expansion of artificial intelligence, machine learning (AI/ML), and adaptive algorithms in healthcare, regulatory agencies worldwide have grappled with post-market algorithm updates.

In the United States, the Food and Drug Administration established the formal Predetermined Change Control Plan (PCCP) under Section 515C of the Food, Drug, and Cosmetic Act (FD&C Act), which allows manufacturers to pre-authorize specific planned modifications and retraining protocols without submitting new 510(k) or PMA supplements.

Following the release of CDSCO's guidance, several trade press articles published headlines asserting that CDSCO "formalized a mandatory AI update program." A careful textual reading of the official 62-page guidance demonstrates that this claim overstates the legal reality.

Feature	CDSCO ACP (MDSW/01/2026)	FDA PCCP (FD&C Act Section 515C)
Legal home	Guidance text in the risk-management section of an MDR-2017 map	Statutory provision plus FDA final guidance
Whether it must exist	"may be devised, wherever applicable"	Optional to submit; binding for the authorized modifications once FDA authorizes it
Where it sits	"may be submitted as part of the Risk Management File, if applicable"	Marketing submission (510(k), De Novo, or PMA) as a standalone authorized plan
If written, what it must cover	The PDF says the ACP shall include an overview of procedures so that modifications do not compromise safety and intended use, and may contain a data-management plan, performance-evaluation and monitoring plan, algorithm retraining plan (if applicable), software-update plan, and rollback plan	FDA's tripartite structure: Description of Modifications, Modification Protocol, and Impact Assessment
Does it waive later change filings?	No. Modifications that may affect safety, intended purpose, clinical performance, or risk profile still need validation, documentation, and regulatory assessment under MDR-2017. Sixth Schedule post-approval change rules remain	Authorizes only the pre-specified modifications inside the authorized PCCP

The Exact Language of CDSCO's ACP

The guidance addresses algorithm modifications in the risk-management and change-control section. The operative sentences, quoted in order, are:

"In this regard, an Algorithm Change Protocol (ACP) may be devised, wherever applicable, based on the nature and risks associated with the MDSW. The ACP shall include an overview of all the procedures to be followed so that any changes/modifications made in the MDSW do not compromise its safety and intended use."

"The ACP may be submitted as part of the Risk Management File, if applicable."

The PDF then lists five contents the ACP may contain: a data-management plan; a performance-evaluation and monitoring plan; an algorithm retraining plan (if applicable); a software-update plan; and a rollback plan. An AI-based SaMD example appears later in the same section as an illustration of dataset-selection documentation, not as a statement that every AI/ML MDSW must file an ACP before the first commercial licence.

An ACP therefore does not grant blanket immunity from MDR-2017 major-change requirements. The PDF separately states that any modification that may affect safety, intended purpose, clinical performance, or risk profile should be validated, documented, and assessed under MDR-2017. Sixth Schedule post-approval change rules remain the legal overlay.

For a detailed analysis of FDA's authorized change protocols, see FDA Predetermined Change Control Plan (PCCP) Guide for AI/ML.

---

Technical File Architecture: QMS, SBOM, Cybersecurity, and Cloud Infrastructure

CDSCO's 2026 guidance aligns Indian documentation expectations with global standards under the International Medical Device Regulators Forum (IMDRF) and Bureau of Indian Standards (BIS) hierarchy.

The Standards Hierarchy (Section 8.0 & Table 3)

MDR-2017 Rule 7, restated in Section 8.0 of the MDSW PDF, sets this hierarchy:

1. BIS standards, or standards notified by the Ministry of Health and Family Welfare.
2. ISO, IEC, or other pharmacopoeia standards if no such BIS or notified standard is available.
3. Validated manufacturer standards if those are also unspecified.

The PDF does not insert European (EN) standards as a separate third rung. Table 3 then lists standards that "may be applicable" to MDSW, including:

• IS/ISO 13485 — quality management systems.
• IS/ISO 14971 — risk management; IEC/TR 80002-1 and IS/ISO/TR 24971 as related risk-management guidance.
• IS/ISO/IEC 62304 — medical device software life-cycle processes; listing it does not make IEC 62304 Edition 2 automatically mandatory in India.
• IS/IEC 82304-1 — health software product safety.
• IEC 81001-5-1 — health software and health IT security activities in the product life cycle (separate from IS/ISO/IEC 27001).
• Additional Table 3 entries cover usability (IEC 62366-1), AI risk and management-system standards (IS/ISO/IEC 23894, IS/ISO/IEC 42001), labelling symbols (IS/ISO 15223), and others. IEC 60601-1 and IEC 61010-1 are not in Table 3.

For deep dives into software standards, see IEC 62304 Edition 2 Software Lifecycle Update Guide and Medical Device Cybersecurity Standards.

Software Bill of Materials (SBOM) Requirements

Section 9.0 states that manufacturers should maintain and periodically update a bill of materials including an SBOM. The SBOM "should ideally cover third-party, open-source, and commercial software components," and manufacturers should implement processes for monitoring, assessing, and mitigating known vulnerabilities associated with those components throughout the software lifecycle as part of risk management. That is a should/ideally expectation in guidance, not a separately gazetted MDSW SBOM statute.

To structure an SBOM aligned with international regulatory expectations, refer to Software Bill of Materials (SBOM) Medical Device Guide.

Cloud Hosting and Digital Data Protection Overlay (Table 4)

Table 4 summarises a digital-health overlay (interoperability, consent-based data governance, secure exchange, privacy, and digital traceability). It points to the Digital Personal Data Protection Act, 2023 and to ABDM privacy materials. Those overlays do not replace an MDR-2017 device licence.

MeitY cloud empanelment is narrower than a commercial-licence hosting mandate. In the test-licence notes, the PDF says SaaS cloud-hosting risk assessment may be conducted on a case-by-case basis, and the applicant should provide information on whether the SaaS is hosted on a Ministry of Electronics and Information Technology (MeitY) empaneled cloud server. That is a test-licence information request, not a statement that every commercial MDSW must sit on a MeitY-empaneled node.

---

Recommended Reading

SBOM for Medical Devices: FDA Section 524B, EU CRA, and NTIA Guide

Cybersecurity Digital Health & AI2026-04-17 · 16 min read

Post-Market Surveillance, PSUR, Materiovigilance, and Software Recalls

Regulatory duties do not conclude upon licence issuance. Section 12.5 maps PMS, vigilance, recall, and PSUR against MDR-2017 rather than creating a software-only statute.

Post-market duty	What the MDSW PDF actually says	Legal overlay
PSUR	MDSW approved for marketing after clinical investigation(s) (such as devices without a predicate) should be closely monitored; the manufacturer/importer shall furnish PSURs as per MDR-2017	Seventh Schedule / Rule 65: every six months for the first two years after marketing, then annually for the next two years, unless CLA extends the duration. Submit each report within 30 calendar days of the period end
SUSAR / unexpected serious events	The licence holder shall inform SLA or CLA of any suspected unexpected serious adverse event (SUSAR) and action taken, including any product recall, within 15 days of the event coming to the licence holder's notice	Rule 65(d) uses the same 15-day SUSAR clock for no-predicate permissions. This is not a 15-day clock for every bug or complaint
MvPI	Manufacturers may report adverse events to the Materiovigilance Programme of India; document that reporting in the vigilance system	IPC MvPI
Software recall	Subject to MDR-2017, recall of MDSW may mean a complete or partial halt in distribution and/or uninstalling/decommissioning the software from some or all channels, networks, and hardware	Field Safety Corrective Action may be initiated when the manufacturer/importer becomes aware of nonconformities through post-market monitoring

Periodic Safety Update Reports (PSUR)

Section 12.5 specifies that PSURs apply to MDSW approved for marketing after clinical investigation(s) (such as medical devices that do not have a predicate device). The PDF does not invent a software-only cadence. MDR-2017 Seventh Schedule and Rule 65 require PSURs every six months for the first two years after marketing, then annually for the subsequent two years, with CLA discretion to extend the total duration. Each report is due within 30 calendar days of the last day of the reporting period. The PDF's PSUR purpose list is: new information from appropriate sources; relating those data to patient exposure; summarising market-authorisation status and significant safety variations; and indicating whether product information will change.

Materiovigilance Programme of India (MvPI) and Adverse Event Reporting

The licence holder shall inform the SLA or CLA, as the case may be, of any suspected unexpected serious adverse event (SUSAR) and action taken, including any product recall, within 15 days of the event coming to the licence holder's notice. Importers also have a 15-day clock to report foreign administrative action (market withdrawal, restriction, cancellation, or "not of standard quality" findings). Serious events and malfunctions that lead to or contribute to death or serious injury must be reported to the licensing authority; manufacturers may also report through the Materiovigilance Programme of India operated by the Indian Pharmacopoeia Commission. Do not treat every software bug as a 15-day SUSAR.

Executing Software Recalls and Field Safety Corrective Actions

In digital health, a "device recall" rarely involves physical retrieval. Under CDSCO guidance, software recalls and Field Safety Corrective Actions (FSCA) comprise:

1. Immediate issuance of Field Safety Notices (FSN) to hospitals, diagnostic centers, and clinicians.
2. Temporary suspension of software downloads, API access, or cloud processing.
3. Rapid deployment of validated emergency security patches or algorithmic bug fixes.
4. Remote deactivation, uninstallation, or decommissioning of compromised software versions.

---

What Does India MDSW Cost: Second Schedule Government Fees versus AIA, Dossier, and Internal QMS?

Budgeting for India medical device software compliance requires a strict distinction between statutory government fees paid to the treasury and third-party commercial or engineering expenses.

Cost bucket	What it is	Source basis
Government fees	Second Schedule amounts for the actual form (test, manufacture, import, clinical investigation, performance evaluation). There is no separate CDSCO "MDSW user fee"	G.S.R. 78(E) dated 31 January 2017, Second Schedule; the MDSW PDF only points to that Schedule
Provider / internal costs	Authorized Indian Agent retainer, Fourth Schedule dossier authoring, SBOM tooling, penetration testing, cloud hosting, and optional ACP work	Commercial or internal; not a government tariff
US MDUFA	FDA user fees	Do not attach to a CDSCO licence

Statutory Government Fees (MDR-2017 Second Schedule)

There is no separate CDSCO user fee for "medical device software." Government fees are those in the Second Schedule of MDR-2017 (G.S.R. 78(E), 31 January 2017) for the actual application. Import site and per-device fees are gazetted in US dollars; manufacturing and most investigation fees are gazetted in Indian rupees. Confirm the current portal challan before paying—later amendments can change a row without changing the MDSW PDF.

Application	Form	Second Schedule amount (G.S.R. 78(E))	Authority / portal
Manufacturing test licence, each distinct device	MD-12	INR 500 (Rule 31(1))	CLA via NSWS
Import test licence, each distinct device	MD-16	USD 100 (Rule 40(2))	CLA via NSWS
Import, Class A other than IVD — one site / each device	MD-14	USD 1,000 / USD 50	CLA via cdscomdonline
Import, Class B other than IVD — one site / each device	MD-14	USD 2,000 / USD 1,000	CLA via cdscomdonline
Import, Class C or D other than IVD — one site / each device	MD-14	USD 3,000 / USD 1,500	CLA via cdscomdonline
Import, Class A or B IVD — one site / each device	MD-14	USD 1,000 / USD 10	CLA via cdscomdonline
Import, Class C or D IVD — one site / each device	MD-14	USD 3,000 / USD 500	CLA via cdscomdonline
Domestic manufacture, Class A or B — one site / each device	MD-3	INR 5,000 / INR 500	SLA via cdscomdonline
Domestic manufacture, Class C or D — one site / each device	MD-7	INR 50,000 / INR 1,000	CLA via cdscomdonline
Pilot clinical investigation	MD-22	INR 100,000 (Rule 51(2)(a))	CLA via cdscomdonline
Pivotal clinical investigation	MD-22	INR 100,000 (Rule 51(2)(b))	CLA via cdscomdonline
Clinical performance evaluation (new IVD)	MD-24	INR 25,000 (Rule 59(2))	CLA via cdscomdonline

Source basis: official gazette Second Schedule, independently extracted 2026-08-30 from G.S.R. 78(E). Class A and Class B import site fees are not the same amount. The INR 25,000 row is performance evaluation of a new IVD, not a Class A/B clinical-investigation discount. Overseas-site inspection (USD 6,000) and licence-retention rows are separate Second Schedule items and are not an MDSW surcharge.

Commercial and Engineering Expenses

Beyond statutory fees, manufacturers must budget for operational implementation:

1. Authorized Indian Agent (AIA): Overseas manufacturers must appoint an in-country Authorized Indian Agent holding a valid wholesale medical device licence (Form MD-41/MD-42). Annual retainer fees vary based on representation scope.
2. Technical Dossier Authoring (CSDT/DMF): Compiling Fourth Schedule technical dossiers, cybersecurity architecture documentation, and clinical evaluation reports.
3. Cybersecurity & Penetration Testing: Third-party vulnerability assessments, static application security testing (SAST), and dynamic application security testing (DAST).
4. Cloud infrastructure: Hosting and security costs for whatever architecture the product actually uses. MeitY empanelment is a test-licence information item, not a CDSCO software tariff.
5. US MDUFA Fees Do Not Apply: United States Medical Device User Fee Amendments (MDUFA) user fees belong strictly to US FDA submissions and have no bearing on Indian regulatory licensing.

---

30/60/90-Day India Medical Device Software Action Plan

Window	Work	What not to do
Days 1–30	Audit intended use against Sections 2.0 and 5.2; classify via First Schedule plus Table 2 or the hardware class; apply the non-clinical-user note only where it fits; appoint an Authorized Indian Agent and execute a Power of Attorney (Fourth Schedule Part I — not a Form MD-43)	Do not treat the 2026 PDF as a new statute, and do not assume every Class A product is Chapter IIIB
Days 31–60	Open NSWS (test) and cdscomdonline (commercial) profiles; assemble the Fourth Schedule dossier, including IS/ISO/IEC 62304 lifecycle records where applicable; compile an SBOM; devise an ACP only where the nature and risks support it	Do not delay a first licence waiting for an FDA-style PCCP that the PDF does not require
Days 61–90	Complete V&V and cybersecurity work; if SaaS is in a test-licence file, state whether hosting is on a MeitY-empaneled cloud; file MD-12/16 on NSWS or MD-3/7/14 on cdscomdonline; stand up SUSAR/MvPI and, where Rule 65/Seventh Schedule apply, a six-month-then-annual PSUR calendar	Do not file a test licence on cdscomdonline

Days 1–30: Qualification, Classification, and Legal Representation

• Audit all clinical claims, user interface text, marketing brochures, and website copy to establish intended medical purpose under Section 2.0.
• Classify standalone software using Table 2; determine if the lay-user rule elevates serious conditions to critical.
• If software controls physical hardware, confirm that the hardware risk classification governs under First Schedule rules.
• Appoint an Authorized Indian Agent holding a valid wholesale licence (commonly Form MD-41/MD-42) and execute a Power of Attorney authenticated as required by Fourth Schedule Part I. There is no Form MD-43 in MDR-2017.

Days 31–60: Technical Dossier Compilation and Portal Setup

• Register company credentials on both NSWS (www.nsws.gov.in) and the Online System for Medical Devices (www.cdscomdonline.gov.in).
• Assemble the Fourth Schedule technical dossier: software architecture charts, verification and validation (V&V) reports, and clinical evaluation data.
• Generate and validate a complete Software Bill of Materials (SBOM) listing all third-party libraries, OSS licenses, and CVE status.
• If the nature and risks of the MDSW support it, devise an Algorithm Change Protocol and place it in the Risk Management File; do not treat ACP as a mandatory pre-licence PCCP.

Days 61–90: Verification, Submission, and Vigilance Alignment

• Complete third-party cybersecurity vulnerability scans. If the product is SaaS in a test-licence file, state whether it is hosted on a MeitY-empaneled cloud; do not treat that note as a commercial-licence exemption or a universal hosting mandate.
• Submit Form MD-12 or MD-16 on NSWS if local testing, evaluation, demonstration, or clinical validation requires a test licence.
• Submit the commercial licensing dossier (Form MD-3/MD-5, Form MD-7/MD-9, or Form MD-14/MD-15) on cdscomdonline.
• Establish vigilance SOPs for the 15-day SUSAR clock and, where Rule 65 / Seventh Schedule apply, a six-month-then-annual PSUR calendar.

---

Recommended Reading

MDCG 2026-5 UDI Assignment: Manufacturer vs Distributor Decision Tree

EU MDR / IVDR Labeling & UDI2026-08-25 · 26 min read

Frequently Asked Questions (FAQs)

Did CDSCO create a new SaMD approval pathway on 21 July 2026?

No. The guidance document (CDSCO/MD/GD/MDSW/01/2026) is an interpretive operational map of existing practices under the Drugs and Cosmetics Act, 1940 and the Medical Devices Rules, 2017. Section 2.0 explicitly clarifies that it should not be misconstrued as a new regulatory control. Statutory applications remain Form MD-3, MD-7, MD-14, etc., under MDR-2017.

Is a fitness app that mentions a chronic disease automatically MDSW?

No. General wellness and lifestyle software that encourages general fitness or healthy habits without providing clinical diagnosis, treatment recommendations, or physiological disease monitoring is out of scope. However, if the app estimates clinical parameters (e.g., detecting arrhythmias, calculating clinical cardiovascular risk scores, or guiding insulin titration), it is regulated as MDSW regardless of wellness disclaimers.

If our software drives an analyser, do we classify the software independently under Table 2?

No. Software that drives, influences, or controls physical medical device hardware (SiMD) automatically assumes the risk classification of the hardware device under the First Schedule of MDR-2017. Table 2 is used exclusively for standalone software (SaMD).

Can we file a test licence application on cdscomdonline.gov.in?

No. Test licences (Form MD-12 for domestic manufacturing test licences and Form MD-16 for import test licences) must be submitted through the National Single Window System (NSWS - www.nsws.gov.in). All commercial manufacturing, import, and clinical investigation applications are submitted through cdscomdonline.gov.in.

Does every AI/ML MDSW need an Algorithm Change Protocol before commercial licensing?

No. CDSCO guidance states that an Algorithm Change Protocol "may be devised, wherever applicable, based on the nature and risks associated with the MDSW" and "may be submitted as part of the Risk Management File, if applicable." If written, the ACP shall include an overview of procedures so modifications do not compromise safety and intended use. That is optional, product-specific risk-file content, not a mandatory FDA-style PCCP for every AI/ML licence.

Is there a CDSCO user fee specifically for medical device software?

No. There is no unique "MDSW tariff." Government fees are strictly those established in the Second Schedule of MDR-2017 for the corresponding statutory form (e.g., Form MD-14 import fees, Form MD-7 manufacturing fees). Third-party Authorized Indian Agent fees, dossier authoring, SBOM tooling, and cloud hosting are separate commercial and internal engineering costs.

---

How Pure Global Supports India and Global Medical Device Compliance

Bringing digital health platforms, AI-driven diagnostic software, and medical devices into India requires seamless coordination across technical dossier authoring, regulatory strategy, and local authorized representation. Pure Global delivers end-to-end regulatory affairs, quality engineering, and compliance management for medical device manufacturers expanding into India and worldwide.

Key support areas include:

• India Market Access & Regulatory Strategy: Strategic classification, portal navigation across NSWS and cdscomdonline, and complete dossier compilation via the India Market Access Practice.
• Software as a Medical Device (SaMD) Compliance: Qualification audits, Table 2 risk classification, IEC 62304 lifecycle documentation, and cybersecurity file preparation through Software as a Medical Device (SaMD) advisory services.
• Authorized Indian Agent (AIA) Solutions: Serving as the legally designated Authorized Indian Agent holding valid regulatory licences and managing CDSCO communications.
• AI/ML & Algorithm Change Management: Structuring Algorithm Change Protocols (ACP) and Risk Management Files compliant with CDSCO and international standards.

To structure your India digital health submission or audit your software classification strategy, contact Pure Global.

Pure Global provides independent regulatory, quality assurance, and market-access consulting services. Pure Global is not the Central Drugs Standard Control Organization (CDSCO), the Drugs Controller General of India (DCGI), a State Licensing Authority (SLA), or a notified body, and does not issue statutory government licences or approvals.

---

Sources

1. Guidance Document on Medical Device Software (Doc No. CDSCO/MD/GD/MDSW/01/2026) — Central Drugs Standard Control Organization, Ministry of Health and Family Welfare, Government of India (Published 21 July 2026).
2. Medical Device & Diagnostics Guidelines Listing — CDSCO (Listing date 21 July 2026).
3. Medical Devices Rules, 2017 (MDR-2017) — Ministry of Health and Family Welfare, Government of India.
4. Online System for Medical Devices (Approved Risk Classification Lists) — CDSCO.
5. National Single Window System (NSWS) — Government of India.
6. Drugs and Cosmetics Act, 1940 — Legislative Department, Ministry of Law and Justice, Government of India.
7. Digital Personal Data Protection Act, 2023 — India Code (Act No. 22 of 2023).
8. Ayushman Bharat Digital Mission (ABDM) — National Health Authority, Government of India.
9. Materiovigilance Programme of India (MvPI) — Indian Pharmacopoeia Commission (URL as cited in CDSCO/MD/GD/MDSW/01/2026).
10. Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations (IMDRF/SaMD WG/N12FINAL:2014) — International Medical Device Regulators Forum. Contrast only; Table 2 is the CDSCO aid.
11. Medical Devices Rules, 2017 — Second Schedule fees — G.S.R. 78(E), 31 January 2017. Fee rows in this article were independently extracted from that gazette Second Schedule on 2026-08-30; confirm the current portal challan before paying.
12. IS/ISO/IEC 62304: Medical Device Software — Software Life Cycle Processes — Bureau of Indian Standards / International Electrotechnical Commission.
13. Predetermined Change Control Plans for Machine Learning-Enabled Device Software Functions — U.S. Food and Drug Administration (contrast only; not Indian law).