The CDSCO risk management file for SaMD is a structured document demonstrating how patient safety risks in a Software as a Medical Device are identified, assessed, controlled, and monitored across the software lifecycle. It must align with ISO 14971 adapted for software hazards, comply with IEC 62304, and specifically address cybersecurity threats, AI algorithm change protocols, and post-market vigilance under MDR 2017. It contains 10 core components and is prepared through a 5-step process. Unlike a static device risk file, the SaMD risk management file is a living document that must be updated with every software version or significant algorithm change.
Dr Meera Anand's healthtech startup had spent eighteen months building a clinical decision support application for sepsis detection in ICU settings. The algorithm had been trained on 2.3 million patient records. Internal validation showed 91% sensitivity. The clinical evidence was compelling. When her regulatory team submitted the CDSCO licensing dossier, the application was held at technical review for four months — not because of the algorithm's performance, but because of what the risk management file did not contain.
There was no cybersecurity threat model. The algorithm change protocol covered version updates but said nothing about what would happen if the model was retrained with new data. The residual risk evaluation did not include a scenario where the software produced a high-confidence false negative in a deteriorating patient with an atypical presentation. Each gap was individually manageable. Together, they told CDSCO that the team had treated the risk file as a documentation box to check rather than a clinical safety argument to make. The dossier was returned with a 14-point query. The launch delay cost the company its first hospital procurement cycle.
📑 Quick Navigation
- Purpose and Regulatory Basis of the CDSCO SaMD Risk Management File
- Scope and Applicability
- Standards Framework — ISO 14971, IEC 62304, and MDR 2017
- 10 Core Components of the CDSCO SaMD Risk Management File
- Cybersecurity Risk Requirements — 2026 Expectations
- AI and Machine Learning Algorithm Risk Requirements
- 5-Step Preparation Process
- Common Gaps That Generate CDSCO Queries
- Frequently Asked Questions
Purpose and Regulatory Basis of the CDSCO SaMD Risk Management File
The CDSCO risk management file for SaMD is not primarily a documentation exercise — it is a clinical safety argument. Its regulatory purpose is to demonstrate to CDSCO that every patient safety risk associated with the software has been systematically identified, that each risk has been assessed with appropriate rigour, that risk control measures have been implemented and verified, and that residual risks are clinically acceptable in light of the software's intended benefits.
Under India's Medical Devices Rules, 2017 (MDR 2017), all Software as a Medical Device products — whether standalone diagnostic tools, clinical decision support systems, AI-powered image analysis platforms, or embedded therapeutic software — require a risk management file as a mandatory component of the licensing dossier. CDSCO's guidance aligns this requirement with ISO 14971 principles, adapted specifically for the software context where hazards differ fundamentally from those of physical medical devices.
Scope and Applicability
The scope section of the CDSCO SaMD risk management file must explicitly define the boundaries of risk management activities for the specific software product. This is not a formality — reviewers use the scope definition to assess whether hazard identification has been comprehensive or whether it has been artificially constrained to exclude inconvenient risk categories.
The scope must specify whether the SaMD is standalone or operates as part of a connected ecosystem. It must identify the intended clinical environment — acute care ICU, outpatient primary care, home monitoring — because the same software carries materially different risks in different deployment contexts. It must clarify whether the software interacts with other medical devices, health information systems, or patient-facing applications, since each interface introduces interoperability and data integrity risks that must be addressed in the file. The scope must also explicitly state whether the product contains AI or machine learning components, because this triggers additional documentation requirements that do not apply to conventional rule-based software.
Standards Framework — ISO 14971, IEC 62304, and MDR 2017
| Standard | Role in SaMD Risk File | Key Contribution |
|---|---|---|
| ISO 14971:2019 | Primary framework | Hazard identification, risk estimation, risk evaluation, risk control, residual risk evaluation, and risk management review — adapted for software-specific hazards |
| IEC 62304:2006/AMD1:2015 | Software lifecycle | Software safety classification (Class A, B, C), software development lifecycle documentation, software system testing, maintenance, and problem resolution records |
| ISO 13485:2016 | QMS integration | Ensures risk management activities are integrated into the QMS — CAPA linkage, design controls, post-market surveillance, and document control |
| CDSCO MDR 2017 | India-specific | MDR 2017 risk classification for SaMD by intended use, Indian adverse event reporting timelines through SUGAM, and CDSCO's living technical file expectations for AI-enabled SaMD |
| IEC 81001-5-1:2021 | Cybersecurity | Health software cybersecurity for safety — threat modelling, security risk controls, and cybersecurity incident response documentation |
| ISO/IEC 25010 | AI/ML | Software quality characteristics relevant to AI-enabled SaMD — reliability, performance efficiency, and maintainability in the context of algorithm updates |
10 Core Components of the CDSCO SaMD Risk Management File
Every CDSCO SaMD risk management file must address each of the following ten components. The depth required for each scales with the device's risk classification under MDR 2017 — a Class C clinical decision support system requires proportionally more rigour than a Class B wellness monitoring application.
A detailed description of the SaMD — its medical purpose, CDSCO classification under MDR 2017, intended user profile, clinical environment, and software architecture. The description must clarify whether the SaMD is standalone, embedded, or part of a connected ecosystem. This section establishes the foundation for all subsequent hazard identification — an imprecise intended use definition creates gaps in hazard coverage that CDSCO reviewers specifically look for.
A structured plan defining responsibilities, lifecycle phases covered, risk assessment methodologies, and the criteria for risk acceptability. The plan must reference ISO 14971 and IEC 62304 explicitly and explain how risk management integrates with the QMS. CDSCO expects the risk management plan to address the full software lifecycle — from design inputs through post-market surveillance — not just the development phase. A plan that terminates at product release is immediately identifiable as incomplete.
Systematic identification of all potential hazards — functional errors, interface failures, data integrity issues, clinical misinterpretation risks, cybersecurity threats, and AI algorithm failure modes. The hazard identification must be exhaustive: every potential hazard must be listed even if subsequently evaluated as negligible, to demonstrate that the analysis was comprehensive. CDSCO reviewers look for hazard categories specific to the device's clinical domain — a sepsis detection algorithm must address the specific hazard of false negatives in atypical presentations.
For each identified hazard: severity assessment (impact on patient if the hazard leads to harm), probability estimation (likelihood of the hazard occurring and causing harm), and detectability evaluation (whether the failure would be identified before harming the patient). Risks are classified — minor, moderate, critical — with documented justification. For AI-enabled SaMD, probability must account for both technical failure rates and the statistical characteristics of the training and deployment data distributions.
Documented risk control measures for every hazard assessed as requiring mitigation — covering technical controls (validation testing, error handling, redundancy, output confidence thresholds), procedural controls (clinical workflow guidance, contraindication labelling, required oversight protocols), and cybersecurity controls. For AI-enabled SaMD, algorithm change protocols must be included as a risk control category. Each control measure must include a justification for why it is effective and proportionate to the risk being addressed.
Evidence that each risk control measure has been tested and confirmed effective. Verification evidence for software includes validation test reports, simulation results, clinical scenario test records, penetration test reports (for cybersecurity controls), and algorithm performance validation datasets. The file must contain a traceability matrix linking each identified hazard to its control measure and the verification evidence confirming the control's effectiveness. Incomplete traceability is the most common single finding in CDSCO SaMD risk file reviews.
Assessment of risks that remain after all risk control measures have been applied. For each residual risk, the file must justify why it is clinically acceptable — typically through a benefit-risk analysis that quantifies the clinical benefit of the software's intended use against the magnitude and probability of the residual harm. Residual risks must also be communicated to users through labelling, instructions for use, and clinical integration guidance. CDSCO expects transparency: residual risks that are not disclosed to users or that are present without documented benefit-risk justification generate major queries.
Procedures for monitoring patient safety risks after the SaMD is deployed in clinical use — including adverse event tracking, software defect monitoring, cybersecurity incident response, algorithm performance drift monitoring, and user complaint analysis. The post-market surveillance plan must be device-specific: the monitoring criteria, adverse event trigger thresholds, and reporting timelines must reflect the SaMD's specific risk profile. CDSCO's SUGAM portal reporting obligations for serious adverse events must be explicitly addressed, including the 2026 timelines for life-threatening events.
Documentation showing how risk management activities connect to the organisation's quality management system — specifically, the linkage between the risk file's CAPA triggers and the QMS CAPA system, how post-market risk findings flow into design reviews and algorithm update decisions, and how supplier and subcontractor software components are risk-qualified. The file must align with ISO 13485 and show that risk management is not a standalone documentation exercise but an operational process embedded in the QMS.
A structured traceability matrix connecting each identified hazard to its risk analysis, control measure, and verification evidence — the spine of the entire risk file. Supporting documentation referenced in the matrix must include software requirements specifications, system architecture diagrams, test records, validation reports, cybersecurity threat models, and algorithm validation datasets. Strong traceability is the quality indicator that CDSCO reviewers use as a proxy for the organisation's overall risk management maturity.
Cybersecurity Risk Requirements — 2026 Expectations
Cybersecurity is not an optional annex to the CDSCO SaMD risk management file — it is a mandatory risk category with its own hazard identification, risk analysis, control measures, and verification requirements. CDSCO's 2026 guidance has significantly raised expectations for cybersecurity documentation in SaMD applications, particularly for products deployed in hospital networks or that handle patient health information.
Cybersecurity threats that must be explicitly addressed include: unauthorised access to patient data processed by the SaMD; injection of malicious inputs designed to cause algorithm misclassification; denial of service attacks that could disrupt clinical workflows dependent on the SaMD output; supply chain attacks through third-party software components or open-source libraries; and integrity attacks on algorithm updates that could silently modify the software's clinical behaviour.
AI and Machine Learning Algorithm Risk Requirements
SaMD products that incorporate artificial intelligence or machine learning algorithms have risk profiles that differ fundamentally from rule-based software — and CDSCO's 2026 expectations for AI-enabled SaMD risk management files reflect that difference.
The Algorithm Change Protocol
The algorithm change protocol is the document that most frequently generates CDSCO queries in AI SaMD applications. Its absence is one thing — but even when present, it is often drafted to address only deliberate, version-controlled algorithm updates and fails to address the scenario of continuous learning models, where the algorithm's behaviour can change without a formal version increment. CDSCO expects the change protocol to explicitly address this scenario for any SaMD that incorporates adaptive learning components, and to define the safety boundaries within which adaptation is permitted without triggering a full re-validation cycle.
How to Implement an Effective CDSCO Medical Device QMS in 2026
The SaMD risk management file must be integrated into your QMS — connected to your CAPA system, design controls, and post-market surveillance processes. See how to build the QMS framework that makes this integration operational rather than just documented.
5-Step Preparation Process
Preparing a CDSCO SaMD risk management file that survives review is a disciplined analytical process, not a documentation assembly task. The five steps below describe the preparation pathway that produces a file CDSCO reviewers can use as the clinical safety argument it is intended to be.
Begin with a precise, complete description of the SaMD — its medical purpose, CDSCO classification under MDR 2017, target user population, intended clinical environment, and deployment architecture. Map the software's interactions with other systems, devices, and data sources. For AI-enabled SaMD, document the training data characteristics and the clinical context for which the algorithm has been validated. The intended use definition is the lens through which all hazard identification is conducted — ambiguity here cascades into gaps throughout the rest of the file.
Prepare a structured risk management plan explicitly referencing ISO 14971 and IEC 62304, with each ISO 14971 clause mapped to the corresponding section of the risk file. Define the risk acceptability criteria — what probability-severity combinations are acceptable, and why — before conducting any risk analysis. Specify how risk management activities connect to the QMS: which findings trigger CAPAs, how post-market surveillance data feeds back into the risk file, and how algorithm changes are evaluated for safety impact. Establish the team responsible for each section and the review schedule.
Using the intended use definition and system architecture as the basis, systematically identify every potential hazard — functional errors, interface failures, clinical misinterpretation scenarios, cybersecurity threats, AI algorithm failure modes including out-of-distribution inputs, and data integrity risks. Involve clinical advisors in identifying domain-specific hazards that engineering teams may underestimate. Every identified hazard is entered into the risk file even if the subsequent analysis concludes the risk is negligible — the completeness of hazard identification is what CDSCO reviewers assess, not just the hazards that made it into the risk controls section.
For each risk requiring control: document the specific control measure, implement it, test its effectiveness, and record the verification evidence. For cybersecurity controls, this means penetration test reports and security code review results. For algorithm controls, this means validation datasets and performance metric reports. Build the traceability matrix as you go — linking hazard to control to verification evidence — rather than reconstructing it at the end. A traceability matrix built retrospectively from a completed risk file consistently contains gaps that a matrix built concurrently with the file does not.
Finalise the post-market surveillance plan with device-specific monitoring criteria, adverse event trigger thresholds, algorithm performance drift indicators, and cybersecurity incident response procedures. Establish the process by which the risk management file will be maintained as a living document — which events trigger a file review (new software version, adverse event, CAPA closure, algorithm retraining), who is responsible, and what the review and approval process entails. CDSCO's expectation for AI-enabled SaMD is that the risk file reflects the current version of the algorithm — a file that was accurate at submission but has not been updated through three algorithm iterations is a compliance failure, not a documentation inconvenience.
Common Gaps That Generate CDSCO Queries
| Risk File Section | Common Gap | Prevention |
|---|---|---|
| Hazard identification | Cybersecurity threats absent; AI out-of-distribution failure modes not identified | Use a structured SaMD-specific hazard identification checklist covering all hazard categories including cyber and AI |
| Risk analysis | Probability assessments not grounded in data — generic "low/medium/high" labels without justification | Reference actual failure rate data, clinical literature, or structured expert elicitation with documented rationale |
| Risk controls | Algorithm change protocol absent or covers only version-controlled updates, not adaptive learning | Draft ACP to explicitly address continuous learning scenarios and define the adaptation safety boundary |
| Verification evidence | Traceability matrix links risks to controls but not controls to verification evidence | Build the matrix in three columns: hazard → control → verification evidence reference |
| Residual risk evaluation | Residual risks acknowledged but no benefit-risk analysis justifying their acceptability | For each residual risk, prepare a quantified benefit-risk statement referencing clinical evidence |
| Post-market surveillance | PMS plan generic — no device-specific monitoring criteria, no algorithm performance drift thresholds | Derive monitoring criteria directly from the residual risk register; define numerical performance thresholds for algorithm monitoring |
| Living file maintenance | File submitted for initial license has not been updated through subsequent software versions | Establish a formal change control trigger process that flags every software update requiring a risk file review |
Frequently Asked Questions
Does every SaMD product need a separate risk management file even if the same algorithm is used across multiple products?
Yes. The risk management file is specific to the SaMD's intended use, clinical environment, and deployment context — not just the algorithm. The same machine learning model used for ECG analysis in a hospital setting and in a consumer wellness application has materially different risk profiles because the patient populations, clinical contexts, and failure consequences differ. CDSCO requires separate risk management files for each licensed SaMD, even where the underlying algorithm is shared. A common algorithm risk analysis section can be referenced across files, but the hazard identification and residual risk evaluation must be product-specific.
How should the risk management file address data used from Indian patients versus international training data?
CDSCO's 2026 guidance specifically raises this question for AI-enabled SaMD. Where the training dataset does not include representative Indian patient data, the risk file must acknowledge this as a potential performance gap and document how it has been evaluated. This may include bridging studies using Indian clinical data, subgroup analysis demonstrating consistent performance across relevant demographic characteristics, or a documented rationale for why the training dataset is sufficient for the intended Indian clinical population. Ignoring the question entirely is the option most likely to generate a major query.
Is IEC 62304 mandatory for CDSCO SaMD licensing?
CDSCO's current guidance requires ISO 14971 compliance as the explicit standard for the risk management file, and expects IEC 62304 alignment for the software lifecycle documentation referenced in the file — particularly for software safety classification, unit testing records, and software maintenance procedures. While IEC 62304 compliance is not independently cited as mandatory in MDR 2017, its practical necessity arises from the fact that the software development lifecycle documentation it requires forms the verification evidence for the risk controls in the ISO 14971 risk file. Companies that do not follow IEC 62304 during development typically lack the verification evidence the risk management file requires.
What happens to the risk management file when a new software version is released?
Every software update that changes the clinical functionality, algorithm performance, interface, or security posture of the SaMD must trigger a risk management file review. The review must assess whether any new hazards have been introduced, whether any existing risk controls have been invalidated, and whether the residual risk profile remains acceptable. For AI-enabled SaMD, any algorithm retraining — even if it improves average performance — must be evaluated for whether it changes performance on specific subpopulations or edge cases. The updated risk file must be submitted to CDSCO as part of the variation application for the software update.
CDSCO Documentation for Medical Device Licensing in 2026
The SaMD risk management file is one of ten core document types required for CDSCO licensing. See how it fits into the complete documentation framework — alongside the Device Master File, Clinical Evaluation Report, and QMS certificates.
✓ Key Takeaways
- The CDSCO SaMD risk management file is a mandatory licensing document that must demonstrate continuous lifecycle risk management — it is a clinical safety argument, not a documentation formality
- It must align with ISO 14971 adapted for software hazards, IEC 62304 for software lifecycle documentation, and CDSCO MDR 2017's India-specific requirements
- Cybersecurity is a mandatory risk category — threat modelling, technical controls, penetration test evidence, and incident response procedures must all appear in the file
- AI-enabled SaMD requires additional documentation: algorithm transparency, validation datasets representative of the Indian patient population, bias mitigation evidence, and a formal algorithm change protocol
- The traceability matrix — linking every hazard to its control measure and verification evidence — is the primary quality indicator CDSCO reviewers use to assess risk management maturity
- The risk management file is a living document: every software version, algorithm retraining, or cybersecurity incident must trigger a file review and update
- Residual risks must be justified through quantified benefit-risk analysis — acknowledgement without justification generates major queries
- Post-market surveillance criteria must be device-specific — generic templates with no algorithm performance thresholds or cybersecurity monitoring procedures are immediately identifiable to experienced reviewers
Your Action Plan
The CDSCO risk management file for SaMD is where the clinical credibility of your software is established in regulatory terms. It is the document through which CDSCO assesses whether your organisation has genuinely grappled with the specific ways your software can harm patients — and whether you have done something meaningful about each of them.
The companies that navigate SaMD licensing efficiently in 2026 are those that treat the risk management file as a first-class engineering deliverable, not a retrospective documentation task. They involve clinical advisors in hazard identification. They build traceability concurrently with risk analysis rather than reconstructing it at the end. They treat cybersecurity and algorithm risk as equally important as functional failure risk. And they establish the living file processes that allow their risk management documentation to evolve with their software — because CDSCO's expectation is that it will.
Begin your hazard identification today. Define your algorithm change protocol before you need it. Build your cybersecurity threat model as part of your design process. The SaMD developers who prepare their risk management files with this level of discipline are the developers whose products reach Indian patients — on schedule and with the clinical credibility their software deserves.