"产品注册资料其他部分都过关，偏偏卡在网络安全描述文档上：审评员一口气问了11条——数据流图没画远程维护场景、现成软件清单缺版本信息、渗透测试报告与申报版本不一致……"
随着医疗器械与网络的深度融合，网络安全已成为软件类器械注册的高频发补区。现行核心依据是国家药监局器审中心2022年3月发布的《医疗器械网络安全注册审查指导原则（2022年修订版）》（2022年第7号通告），它取代了2017版，并与《医疗器械软件注册审查指导原则（2022年修订版）》配套使用。本文将按"先判定、再架构、后编写"的逻辑，把网络安全资料的写法一次讲透。
判定逻辑非常简单：Ⅱ类或Ⅲ类器械 + 具备以下三种功能之一 = 必须提交网络安全资料。
触发功能 | 定义 | 典型例子 |
电子数据交换 | 基于网络或存储介质的单向/双向数据传输 | DICOM影像传输、HL7对接HIS、U盘导出数据 |
远程访问与控制 | 基于网络的实时/非实时访问与控制 | 厂商远程维护、云端远程诊疗、远程升级 |
用户访问 | 基于软件界面、电子接口的人机交互 | 账号密码登录、USB接口、蓝牙连接 |
注意：即使产品"不联网"，只要有USB/蓝牙等电子接口或用户访问界面，同样适用。存储介质（光盘、U盘、移动硬盘）也在覆盖范围内。
文档类型 | 适用情形 | 内容深度 |
网络安全描述文档 | 产品注册、许可事项变更中的重大网络安全更新 | 完整八章节 |
常规安全补丁描述文档 | 轻微网络安全更新（仅修补漏洞、不改变功能性能） | 精简：补丁说明+测试计划+缺陷修复验证 |
重大/轻微的判定核心：是否改变产品的电子接口类型、数据交换协议、网络安全架构、访问控制机制。改了架构 → 重大更新 → 需许可事项变更注册；仅打安全补丁 → 轻微更新 → 质量体系内部控制 + 下次延续注册时说明。
三、网络安全描述文档怎么写
（1）软件信息：名称、型号规格、发布版本、软件安全性级别（轻微/中等/严重，与软件指导原则一致）。版本号必须与注册检验样品、软件研究资料完全一致。
（2）数据架构：这是审评员最先看、也最容易发补的部分。要求提供每个使用场景下的网络环境图和数据流图，包括：
临床使用场景（设备↔HIS/PACS↔云端）
远程维护与升级场景（最易遗漏！）
数据流向、接口类型、协议、端口、数据类型（医疗数据/设备数据）
写作要领：图上每一个数据流箭头，都要在文字中说明"传什么数据、走什么协议、是否加密、谁授权访问"。
（3）数据描述：区分医疗数据（含敏感/非敏感，如患者身份信息、生理数据）与设备数据（日志、配置、校准参数），逐项说明存储位置、传输方式、访问权限。
网络安全风险管理必须与ISO 14971风险管理报告联动而非孤立：
针对保密性、完整性、可得性（CIA三性）分别识别威胁场景；
每项网络安全风险控制措施，要能对应到风险管理报告中的条目；
剩余风险的可接受性判定要有依据。
说明产品的网络安全设计，对标22项网络安全能力（源自指导原则，参考YY/T 1843-2022《医用电气设备网络安全基本要求》）：
能力类别 | 代表能力 | 文档中要写什么 |
识别 | 资产清单、威胁识别 | 硬件/软件/数据资产梳理 |
防护 | 访问控制、自动注销（ALOF）、数据加密、隔离 | 身份鉴别机制、加密算法与密钥管理、网段隔离设计 |
探测 | 日志审计、入侵探测 | 日志内容与留存、异常检测机制 |
响应 | 应急响应、告警 | 安全事件响应流程 |
恢复 | 数据备份、灾难恢复 | 备份机制、恢复时间目标 |
写作要领：并非所有产品都要具备全部22项能力，但每一项"不具备"都要给出基于风险分析的合理性论证，不能沉默跳过。
验证活动 | 要求 |
漏洞评估 | 自测（需具备工具、人员资质、完整记录）或委托第三方（推荐） |
渗透测试 | 覆盖已识别接口与威胁场景，记录工具、方法、发现、修复与复测 |
测试版本 | 必须为申报的发布版本，或论证测试版本与申报版本的一致性 |
雷区：渗透测试只测业务端口，不测远程维护通道 → 发补。
说明网络安全资料与软件研究资料、风险管理报告、产品技术要求之间的关联关系，形成"威胁→风险→控制措施→设计实现→验证证据"的闭环链条。
2022版的新增重点：产品需具备为用户提供全部现成软件清单（SBOM）的能力。文档中须列出：
操作系统、中间件、开源库、商用组件的名称、供应商、版本；
已知漏洞评估（对照CVE等漏洞库，说明每个现成软件的风险处置）；
许可证合规性建议一并考虑。
说明书必须包含：用户访问控制机制、电子接口清单（类型/数据/协议）、网络安全特征配置说明、数据备份与灾难恢复方法、运行环境（硬件/外部软件/网络）、安全软件兼容性清单（杀毒软件等）、网络安全更新方式。说明书内容与网络安全描述文档必须一字不差地互相印证。
说明上市后网络安全维护承诺：漏洞监测渠道、补丁发布流程、响应时限、用户通知机制、维护期限。
序号 | 雷区 | 典型发补表述 | 预防要点 |
1 | 数据流图漏画远程维护场景 | "请补充远程维护与升级场景的网络环境图" | 立项时列全使用场景清单 |
2 | SBOM不完整/无版本信息 | "请提供全部现成软件清单及已知漏洞评估" | 开发期即用SCA工具自动生成SBOM |
3 | 渗透测试版本与申报版本不符 | "请论证测试样品的代表性" | 版本冻结后再测，或做版本差异论证 |
4 | 加密声称无落地证据 | "请说明加密算法、密钥管理机制及验证情况" | 密码设计文档+测试记录同步留存 |
5 | 22项能力"沉默跳过" | "请逐项说明网络安全能力或论证不适用的合理性" | 做能力对照矩阵，不适用项写论证 |
6 | 网安风险未并入风险管理报告 | "请补充网络安全风险分析及与控制措施的对应关系" | 风险管理计划中预设网络安全章节 |
7 | 说明书与描述文档不一致 | "请核对并统一电子接口描述" | 提交前做交叉一致性审查 |
8 | 日志功能缺失或描述空泛 | "请说明日志内容、留存与审计机制" | 设计阶段落实日志需求 |
9 | 无线连接（蓝牙/WiFi）配对机制未说明 | "请补充无线接口的身份鉴别与加密设计" | 无线接口单独成节论证 |
10 | 维护计划照抄模板 | "请明确漏洞响应时限与用户通知方式" | 结合企业实际售后体系写可执行承诺 |
阶段 | 动作 |
立项期 | 判定适用性；将网络安全纳入风险管理计划与软件需求 |
设计期 | 绘制全场景数据流图；设计访问控制/加密/日志；建立SBOM管理 |
验证期 | 版本冻结 → 漏洞评估 → 渗透测试 → 修复复测 |
编写期 | 按八章节成文；同步更新说明书网络安全章节 |
内审期 | 一致性交叉审查（版本号、接口清单、数据描述） |
序号 | 自查项 | 确定 |
1 | 所有使用场景（含远程维护/升级）均有网络环境图和数据流图 | □ |
2 | 软件发布版本在描述文档、检验报告、软件研究资料中一致 | □ |
3 | 医疗数据/设备数据分类完整，敏感数据标明 | □ |
4 | 每项网安风险控制措施可追溯至风险管理报告 | □ |
5 | 22项能力逐项对照，不适用项有论证 | □ |
6 | SBOM含名称/供应商/版本，且完成已知漏洞评估 | □ |
7 | 渗透测试对象为申报版本或有一致性论证 | □ |
8 | 说明书网络安全内容与描述文档完全一致 | □ |
9 | 维护计划含漏洞响应流程与时限 | □ |
10 | 重大/轻微更新判定规则已写入体系文件 | □ |
医疗器械网络安全资料的写作逻辑，一句话概括：
判定适用范围 → 画清数据架构 → 用风险管理驱动设计 → 用22项能力对照自查 → 用漏洞评估和渗透测试验证 → 用SBOM管住供应链 → 用说明书告知用户 → 用维护计划承诺上市后。
它与软件研究资料、风险管理报告、产品技术要求、说明书构成一个互相咬合的证据网络——任何一处描述不一致，都会成为发补的突破口。最关键的心法是：网络安全资料不是申报前"写"出来的，而是开发过程中"做"出来、最后"整理"出来的。从立项第一天就把CIA三性和22项能力融入需求与设计，申报时自然水到渠成；反之，临阵补文档，漏洞和矛盾一定会被审评员看见。
2026-09-14
快速检索
微信公众号
官方百家号
官方头条号
官方微博
