扫码报修要收集哪些个人信息？维修小程序最小必要清单

一、先把报修流程拆成不同处理目的

把扫码后的动作分为识别设备、确认报修人、联系沟通、远程判断、安排上门、维修记录、交付和售后。每个字段都应能回答“用于哪个动作、没有它能否提供基本服务、由谁使用、保存多久”，不能用一句笼统的“改善体验”承接所有收集。

《个人信息保护法》要求处理目的明确、合理并与目的直接相关，采取对个人权益影响最小的方式，收集限于实现目的的最小范围。必要性应按具体服务判断：门店送修与上门维修所需地址不同，企业资产报修与个人客户报修的联系人和授权关系也不同。

二、把必填、条件必填和可选字段分开

设备码、故障描述和一种可联系渠道常用于建立报修与后续沟通，但仍要结合是否支持匿名咨询、企业统一联系人或无需回访等情况判断。服务地址应只在需要上门、取送或寄回时按必要范围收集；照片和视频用于辅助判断时，应允许客户先了解用途再选择上传。

精确定位、身份证照片、人脸、通讯录、相册全量权限和与维修无关的职业、生日等信息，不应因为技术上可以获得就设为普通报修必填。确有额外核验或高风险业务需要时，应单独说明目的、必要性和影响，并采用与风险相称的处理方式。

• 基础联系：优先只要求能够完成本次服务的一种有效渠道。
• 设备与故障：设备标识、报修原话、出现时间和必要附件。
• 履约条件：仅在上门、取送或寄回时收集所需地址与时段。
• 可选信息：用于便利或分析但不影响基本报修的字段应明确可跳过。

三、提交前的告知要能被看见和理解

在用户提交信息前，应以显著、清晰易懂的方式告知个人信息处理者名称和联系方式、处理目的与方式、信息种类、保存期限，以及用户行使查阅、更正、删除等权利的方式。隐私规则要便于访问和保存，不能只藏在多层菜单或用模糊同意概括。

如果后续把报修信息改用于营销、画像或与原目的不一致的用途，不能把最初的维修提交当然当作覆盖。处理目的、方式或信息种类发生变化时，应按适用要求重新评估告知、同意或其他处理依据。

四、照片、设备信息和位置也可能关联到个人

故障照片可能拍到人脸、家庭或办公环境、快递面单、账号页面、聊天内容和客户资料。上传入口应提示只拍故障相关区域，并允许预览、删除和重新选择；维修人员也不应把客户图片转发到无关群聊或个人设备长期保存。

设备序列号、二维码和维修历史单独看未必都能直接识别人，但与手机号、账号、地址或使用人关联后，可能构成与可识别自然人有关的信息。系统应按关联后的实际风险设置访问、导出、日志和展示范围，而不是因为字段名叫“设备信息”就排除保护。

五、内部权限和第三方处理要有边界

客服可查看联系方式和预约信息，维修人员只获取完成工单所需内容，财务按结算需要查看费用和主体信息，普通员工不应默认导出全部客户。管理员权限、批量导出、搜索和附件下载应记录账号、时间、范围和结果，并定期回收离职或转岗权限。

如果云服务、短信、地图、客服或外包团队受托处理个人信息，应明确处理目的、期限、方式、信息种类、保护措施和双方责任，并监督其在约定范围内处理。不能用“第三方提供服务”替代对接收方和实际数据流向的梳理。

六、保存期限不能等于系统永久保存

为履行维修合同、质量责任、结算或争议处理可能需要保存部分工单，但联系方式、定位、原始照片、日志和统计数据的必要期限可能不同。应按字段和目的设定期限，到期后删除、匿名化或停止除存储与必要保护外的处理，而不是因为存储便宜就无限保留。

还要提供可操作的查阅、更正、删除和撤回入口，并记录请求、核验、处理结果与无法立即删除的理由。账号注销不能自动替代工单与法定留存判断，也不能成为拒绝处理其他个人信息权利请求的理由。

七、上线前用六类场景验证最小必要

至少测试门店送修、上门维修、企业统一联系人、客户拒绝可选字段、撤回照片和申请更正删除六类场景。验证不提供非必要信息时仍能完成基本报修，只有选择上门时才出现地址字段，附件可预览删除，告知内容与后台实际字段和第三方调用一致。

再以客服、维修人员、财务、管理员和离职账号分别登录，检查可见范围、导出、日志和权限回收。上线后的字段、SDK、接口或营销用途变化，都应重新做数据流与必要性复核；监管通报持续关注未公开规则、超范围收集、第三方披露和权利入口缺失等问题。