条款定位：ISO 9001:2015 第8章”运行”下的第3节，专门针对产品或服务存在设计开发活动的组织。第三方审核员在审核前需先判断：该组织是否开展设计开发？若适用，则 8.3 是重点审核区域。
一、条款结构速览
ISO 9001:2015 第 8.3 条分为六个子条款，构成设计开发的完整闭环：
| 子条款 | 要求核心 | 审核侧重 |
|---|---|---|
| 8.3.1 总则 | 策划并实施设计开发过程 | 是否建立系统性的 D&D 流程 |
| 8.3.2 设计和开发策划 | 确定阶段、评审/验证/确认安排、职责 | 计划文件是否可操作 |
| 8.3.3 设计和开发输入 | 识别功能要求、法规要求、类似设计信息、潜在失败后果 | 输入是否完整、是否已评审 |
| 8.3.4 设计和开发控制 | 执行评审、验证、确认活动，控制问题 | 三类活动是否独立、记录是否完整 |
| 8.3.5 设计和开发输出 | 输出满足输入要求、包含监视测量准则、满足放行规定 | 输出可追溯性、生产/交付信息是否充分 |
| 8.3.6 设计和开发更改 | 识别、控制、评审更改，防止不良影响 | 更改记录是否完整、是否重新评审/验证 |
二、进入审核前的关键判断
8.3 是否适用？ 是审核员首先要确认的问题。
适用情形（不能删减）：
- 组织自主研发产品，而非完全按客户图纸/规范生产
- 提供方案型服务（如软件定制开发、工程设计服务、咨询方案设计）
- 产品规格由组织与客户共同确定，存在设计转化过程
常见误判提示：
有些组织以”按客户规格生产，没有设计”为由删减 8.3，但实际上工艺路线设计、配方优化、夹具设计等均属设计开发范畴。审核时需核实删减依据是否充分。
审核提问示例：
- “你们的产品规格由谁制定？有没有从客户需求转化为工程参数的过程？”
- “新产品开发时，有没有图纸或技术规范的设计输出？谁来审批？”
三、8.3.2 策划——看”计划”是否落地
策划是整个设计开发的框架，审核重点在于计划是否真实指导了工作，而非纸面文件。
应覆盖的内容：
- 设计开发阶段的划分（概念→方案→详细设计→验证→批产）
- 每个阶段的评审、验证、确认安排
- 各阶段的职责与权限
- 所需的内外部资源
- 需要参与的相关方（客户、供应商、法规机构）
审核提问示例：
- “上一个新产品开发项目，有没有一份设计计划？给我看一下。”
- “计划里的评审节点，实际执行了吗？有记录吗？”
- “设计计划更新过吗？更新的触发条件是什么？”
常见问题：
计划过于笼统，只有”开发阶段”但无具体时间节点、责任人，导致实际执行完全脱离计划。
四、8.3.3 设计输入——看”需求”是否转化到位
设计输入是设计工作的起点，决定了后续输出的方向。
标准要求的输入类型：
| 输入类型 | 典型内容 | 审核关注点 |
|---|---|---|
| 功能和性能要求 | 技术指标、使用工况 | 是否来自客户需求的系统转化 |
| 适用的法律法规 | 强制性标准、认证要求 | 是否识别齐全、是否有查阅记录 |
| 以往类似设计信息 | 历史 FMEA、历史失效教训 | 是否有效利用经验教训 |
| 潜在失败的后果 | 安全风险、失效影响 | 高风险输入是否重点管控 |
审核提问示例：
- “这份设计输入清单，哪些来自客户需求？哪些是法规要求？是怎么识别的？”
- “有没有参考过以前类似产品开发时遇到的问题？在哪里体现？”
- “设计输入有没有经过评审？谁来确认输入是充分完整的？”
五、8.3.4 设计控制——评审、验证、确认的区别是关键
这是审核中最容易出现不符合项的部分，因为很多组织混淆了三个概念。
概念辨析：
| 活动 | 定义 | 典型问题 |
|---|---|---|
| 评审（Review） | 检查设计是否满足规定要求，发现问题并采取措施 | 评审只是走内部会签，没有独立评审人员 |
| 验证（Verification） | 确认设计输出满足设计输入要求（自己对自己） | 把测试报告当作验证，实际未与输入逐条对照 |
| 确认（Validation） | 确认产品满足预期使用要求（客户或最终用户视角） | 完全没有确认活动，或确认与验证混同 |
审核员关键问题：“你们的验证和确认分别在什么时候做？有什么区别？能分别给我看看对应的记录吗？”
评审的独立性：
参与设计的人员不应是评审的唯一负责人。审核时注意审查评审记录中的签字人员是否包含设计以外的相关方（质量、客户代表等）。
六、8.3.5 设计输出——看”成果”是否完整
设计输出需满足：
- 充分响应设计输入的每项要求
- 包含监视和测量的准则（即什么叫做”合格”）
- 规定产品特性（对生产、交付、服务提供有用的信息）
- 包含产品安全和正确使用的必要信息
审核提问示例：
- “设计图纸/技术规范里，有没有明确检验方法和接收准则？”
- “设计输出有没有和设计输入做逐条对照确认？”
- “设计输出是否经过了授权发布？发布前有没有评审？”
七、8.3.6 设计更改——最容易被忽视的控制点
产品在量产后的设计变更，是不符合项的高发区，因为很多组织做了更改但没有走正式评审流程。
审核关注点：
- 更改是否有书面申请/记录（变更申请单或 ECN）？
- 更改是否经过评审——包括对已交付产品的潜在影响分析？
- 更改是否重新经过了验证/确认（视更改影响程度）？
- 更改后的文件版本控制是否及时？
审核提问示例：
- “最近一次设计变更是什么时候？是什么原因变更的？有没有变更申请记录？”
- “变更影响了哪些在用产品？有没有评估客户那里已发货产品的影响？”
- “变更后有没有重新做验证？验证结果记录在哪里？”
八、常见不符合项案例
| 不符合项描述 | 违反条款 | 审核证据获取 |
|---|---|---|
| 设计输入清单未识别适用法规要求（如强制性国标） | 8.3.3 | 查设计输入清单，对照产品适用标准目录 |
| 设计评审记录中签字人员均为设计部门内部，无独立评审人 | 8.3.4 | 查评审记录的参与人员列表 |
| 验证活动仅有测试报告，未与设计输入逐条比对确认 | 8.3.4 | 抽查验证报告，核对是否覆盖全部输入项 |
| 量产阶段发生两次工程变更，均无书面变更记录 | 8.3.6 | 查 BOM 版本历史、图纸版本记录 |
| 产品设计输出无检验接收准则，生产依靠”经验”判断 | 8.3.5 | 查作业指导书和检验规程是否有明确合格判定标准 |
九、审核准备清单
审核该条款前，建议提前索取以下资料：
- [ ] 近12个月的新产品开发项目清单
- [ ] 最新版本的设计和开发程序文件
- [ ] 任意一个项目的完整设计开发档案（输入→计划→评审记录→验证/确认报告→输出）
- [ ] 近期工程变更记录（ECN 或变更申请单）
- [ ] 设计失败/返工案例（如有）的根因分析记录
十、整合审核视角
在开展 ISO 27001 或 ISO 20000-1 整合审核时，8.3 的对应关系：
| ISO 9001 8.3 设计控制 | ISO 27001 对应要求 |
|---|---|
| 设计输入识别安全要求 | A.14.1 安全性系统开发要求 |
| 设计验证/确认 | A.14.2 系统开发生命周期中的安全性 |
| 设计更改控制 | A.14.2.4 软件包修改限制 |
整合审核时，可将同一款软件产品的开发过程作为同一条证据链，分别对照两个标准的要求进行验证，提高审核效率。
审核要点提炼：第 8.3 条款的审核核心是”有证据的闭环”——从客户需求（输入）→设计策划→过程控制（评审/验证/确认）→交付文件（输出）→变更管理，每个环节都需要可查的记录。不符合项往往不是因为没有做，而是因为没有记录，或记录流于形式。