The NMPA issued “On-Site Inspection Guideline for Standalone Software of the Medical Device Production Quality Management Specification” on September 30, 2026. It is intended to strengthen production supervision and guide regulatory authorities in inspecting independent software registrants and manufacturers. Based on the new GMP, it integrates the appendix into the GMP framework and converts the requirements into inspection items. It contains 203 items: 41 critical (***), 95 major (**), and 67 general (*). Inspection types and result determination follow the general GMP inspection guideline.
For our comprehensive analysis on China’s regulatory approach to Software as a Medical Device (SaMD), click HERE
Click HERE for software company defects found in NMPA unannounced inspection
Click HERE for NMPA chief reviewers’ opinion on regulating AI medical devices
Scope and structure
The guideline is organized into 14 chapters, covering general provisions, quality assurance, organization and personnel, premises and facilities, equipment, document and data management, design and development, purchasing and raw material management, verification and validation, production management, quality control, entrusted production and outsourced processing, sales and after-sales service, and monitoring, analysis, and improvement. Each item is linked to the relevant GMP or Independent Software Appendix clause, making the inspection system more traceable and systematic.
Risk-based quality assurance
Risk management must run through the entire quality management system, and control measures must match product risks. Manufacturers must establish quality objectives, provide adequate personnel, premises, and equipment, maintain a documented quality assurance system, control changes, continuously improve, and regularly review lifecycle quality risk information. The new chapter on quality assurance gives these cross-cutting requirements a clearer place in inspections.
Organization and personnel
Production management and quality management heads may not be the same person. A quality management department must independently perform quality assurance and quality control and must have a veto right over product quality. Key personnel include the legal representative, main responsible person, management representative, production management head, quality management head, and product release reviewer. These key persons should generally be full-time employees. Software development, testing, and maintenance staff must have suitable knowledge, experience, and ability. User testers must have appropriate product experience or training. For black-box testing, the developer and tester of the same software item may not be the same person.
Premises, equipment, and software environment
Manufacturers must provide a suitable software development and testing environment, including hardware, software, tools, networks, virus protection, and data backup and recovery. The environment must be maintained, periodically verified, updated, and protected against viruses, with records kept. Equipment and instruments must match production and testing needs, be properly installed, maintained, and calibrated, and be re-qualified after major repair or modification. Computerized systems used in research, production, testing, or storage must be protected from interference.
Documents, data, and records
Quality manuals, procedure documents, technical documents, and records are required. Document control must cover drafting, revision, review, approval, distribution, withdrawal, copying, storage, and destruction. Records must be true, accurate, complete, timely, clear, and traceable. For electronic records and data, the guideline requires user permission management, authorized changes or deletions with retained records, backup, and compliance with electronic signature rules. These requirements reflect modern expectations for data integrity.
Design and development lifecycle
This is the most software-specific part. Manufacturers must define controls for software development planning, requirements analysis, design, coding, verification and validation, updates, risk management, defect management, traceability analysis, configuration management, document and record control, off-the-shelf software, cybersecurity, release, deployment, and retirement. Risk management must run through the software lifecycle. Quality assurance activities must match the software safety class. The safety class must be determined before risk control measures, based on intended use, use scenario, and core function, and can only be reduced by external risk control measures. Configuration management, traceability analysis, version control, testing, and change control must be documented and applied throughout the lifecycle.
Purchasing and off-the-shelf software
Manufacturers must establish procurement control procedures, classify suppliers, audit and re-evaluate them, and maintain a qualified supplier list. Key suppliers require quality agreements and quality files. Suppliers must notify changes in outsourced software functions, performance, core algorithms, architecture, external components, versions, development environment, key developers, quality standards, and testing methods. Manufacturers must assess the impact and may conduct on-site audits. Off-the-shelf software must be purchased under documented controls based on type, use, and impact on product quality.
Verification, validation, production, and quality control
Verification and validation must be based on risk. Premises, facilities, main equipment, special processes, and key processes must be qualified or validated. Changes to key materials, environment, processes, equipment, or test methods require verification or confirmation. Computer software affecting product quality must be confirmed before first use and after changes. Production requires process control, batch records, identification, label and instruction control, protection including cybersecurity, line clearance, nonconforming product control, traceability, and UDI. Release must include software version identification, installation and uninstallation testing, integrity checks, and authorized signature. Entrusted production requires both production release and market release.
Entrusted production and post-market duties
The entrusting party’s quality system must cover the full lifecycle, and the entrusted manufacturer’s system must cover the entrusted activities. Both parties must communicate effectively, sign quality agreements, and not transfer legal responsibilities. The entrusting party must assess and periodically audit the manufacturer. Production transfer, trial production, validation, change notification, joint evaluation, release, deviation reporting, and outsourced processing are specified. Sales, after-sales service, software retirement, installation and deployment, complaints, adverse events, data analysis covering software defects and cybersecurity incidents, corrective and preventive actions, recall, cybersecurity response, internal audit, and management review complete the closed-loop system.
Key Differences from the 2020 Version
The 2020 version was published in May 2020. It listed inspection clauses by broad chapters but did not assign explicit critical, major, or general risk levels, did not state a total item count, and was less directly mapped to the current GMP and Independent Software Appendix.
Risk classification and item count
The 2026 draft has 203 items with clear risk levels: 41 critical, 95 major, and 67 general ones. The 2020 version had no such systematic risk classification or total count.
Structure and GMP alignment
The new draft adds separate chapters on quality assurance, verification and validation, and entrusted production and outsourced processing. It integrates the Independent Software Appendix into the GMP framework and links each item to specific GMP or appendix clauses.
Stronger lifecycle and software-specific controls
The new version places much greater emphasis on full lifecycle risk management, change control, data integrity, electronic records, configuration management, traceability analysis, software safety classification, version control, defect management, cybersecurity, software release, deployment, retirement, UDI, production release and market release, and supplier change notification. The old version contained some related requirements, such as cloud service agreements and outsourced software quality agreements, but these were narrower and less integrated. Overall, the 2026 draft is more comprehensive, more software-specific, and more closely aligned with current regulatory expectations.