更新时间：2026-09-20 09:32:57
中标的是A，接触数据的却是B：
信息化项目外包最容易漏审什么？
信息化项目外包很常见。
系统开发、运维、驻场服务、数据治理、接口对接……很多单位都会交给专业供应商完成。项目审计时，我们也习惯沿着合同、采购、付款、验收这条线往下查：采购程序合不合规？合同有没有超范围？人员有没有到岗？服务有没有完成？钱付得合不合理？
但最近审计署披露的一则案例，提醒了一个很容易被忽略的问题：
项目是外包给A公司的，真正能够登录系统、接触数据，甚至导出数据的人，可能已经不是A公司的人了。
2026年6月，审计署公布《中央部门单位2025年度预算执行等情况审计结果》。其中提到，2024年至2025年，某部门对1个政府购买服务项目履约监管不到位，中标单位将服务项目违规分包给民营企业和外资企业，并向分包企业开放非公开的系统数据权限，存在政务数据泄露风险，涉及合同金额258.6万元。
这个案例值得关注的，不只是“违规分包”。
真正值得信息化项目管理和审计人员警惕的是：
合同关系发生了一次转移，数据权限也跟着转移了。
01 信息化外包最容易漏审的，可能不是合同，而是“权限”
传统项目里，分包后最直观的问题通常是：到底是谁干的活？有没有转包？有没有偷工减料？
但信息化项目多了一层。
供应商为了开发、运维系统，往往需要接触数据库、接口、服务器、后台管理账号，甚至具备查询、修改、导出数据的权限。
因此，同样是“把一部分工作交给第三方”，信息化项目带来的后果可能完全不同。
一个普通服务项目发生分包，变化的主要是实际提供服务的人员；一个信息系统运维项目发生分包，变化的除了人员，还可能包括系统访问主体、数据处理主体和安全责任链条。
更关键的是，这些权限在技术上往往具有“可延伸性”。
一个账号可能被共享，一份数据可以被导出，一套接口权限可以持续调用。合同里写着“乙方负责”，并不能自动证明真正操作系统的人就是乙方。
所以，信息化外包审计如果只核合同、发票和验收单，可能恰恰漏掉了有风险的一层：
谁真正拿到了权限？
02 分包并不等于违规，问题在于“谁被允许接触数据”
这里有一个容易写错、也容易审错的地方。
政府采购项目并不是一出现“分包”两个字，就可以直接认定有问题。
《政府采购法》第四十八条明确，经采购人同意，中标、成交供应商可以依法采取分包方式履行合同。
也就是说，审计的重点不能停留在“有没有分包”，而应该继续往下追：
采购文件、投标文件和合同是怎么约定的？采购人是否知情并同意？实际承担工作的单位是谁？分包之后，原本授予中标供应商的系统权限、数据权限，是否也被直接转给了第三方？
这几个问题，才是信息化项目与一般服务采购真正不一样的地方。
尤其值得注意的是，前述审计报告提到了“民营企业和外资企业”，但风险点并不在企业所有制本身，而在于违规分包之后，非公开系统数据权限也被开放给了合同管理链条之外的主体。
如果把问题简单理解成“某一类企业接触数据就危险”，反而把真正值得审计的内容写偏了。
真正的问题是：
采购人原本批准A接触数据，A有没有权力再自行决定让B、C也接触？
03 外包的是服务，不代表数据控制权也一起交出去了
《数据安全法》第四十条其实已经把这个边界写得很清楚。
国家机关委托他人建设、维护电子政务系统，存储、加工政务数据，应经过严格的批准程序，并监督受托方履行相应的数据安全保护义务；受托方不得擅自留存、使用、泄露或者向他人提供政务数据。
如果项目涉及个人信息，《个人信息保护法》第二十一条又进一步规定：委托处理个人信息，应约定处理目的、期限、方式、种类、保护措施等，并监督受托人的处理活动；未经个人信息处理者同意，受托人不得转委托他人处理个人信息。
而自2025年1月1日起施行的《网络数据安全管理条例》进一步提出，重要数据的处理者在提供、委托处理、共同处理重要数据前，应按规定开展风险评估，评估接收方、合同约束和技术管理措施等能否有效防范数据安全风险。
这意味着，在信息化外包项目里：
“采购了服务”和“授权处理数据”，其实是两件相关但不同的事。
供应商中标，只能说明它取得了合同履行资格，并不意味着它天然取得了任意处理数据、转授权数据权限的权利。
换句话说：
开发、运维工作可以交出去，但数据能让谁看、看多少、怎么用、能不能再交给别人，仍然需要单独受控。
这恰恰是很多项目合同里容易写得比较笼统的一块。
常见的约定可能只有一句：
“乙方应做好数据保密工作。”
但谁可以申请账号？允许访问哪些库表？能不能导出？能不能下载到本地？分包人员能否登录？离场后多久销权？项目结束后备份数据如何处理？
如果这些都没有落到具体控制上，一条笼统的“保密条款”，很难替代真正的权限管理。
04 审计不能只看“谁签了合同”，还要把五条链对起来
对于这类项目，一个比较实用的思路，是把合同链、人员链、账号链、数据链、日志链放在一起核。
合同链解决“法律关系是谁”；人员链解决“实际干活的是谁”；账号链解决“谁拥有系统访问能力”；数据链解决“哪些数据被查询、下载、传输或提供”；日志链，则用来验证前面四条链到底是不是事实。
例如，审计核查时就可以关注这类“不一致”：
合同里约定A公司提供驻场人员，但堡垒机、代码仓库或者工单系统中，长期操作的却存在其他主体人员；项目已经结束，供应商VPN账号仍未注销；某运维岗位按职责只需维护服务器，却拥有大量业务数据查询或导出权限；人员已经离场，数据库账号和接口密钥仍然有效。
这些证据，往往比单纯看一份《人员到岗签到表》更接近项目的真实履约状态。
甚至在结算审计中，这种交叉核验还有另一个价值：
它可以反过来验证服务量。
如果合同按照驻场人数、工时、服务次数计费，那么真实账号操作记录、工单记录、代码提交记录，与考勤和结算工作量是否一致，本身就是成本真实性的重要证据。
对于定制软件开发类项目，还可以把人员和工时之外的“成果规模”单独拉出来核查。
比如梳理实际交付的功能清单，对软件功能规模进行度量，再结合行业基准数据判断开发费用是否合理。实际工作中，也可以借助软件造价喵辅助进行功能点识别、功能清单整理和费用测算。平台沉淀了10年行业基准数据，并整合70余项国家、行业及省市级软件和信息化项目造价标准。
这样，合同、人员、系统日志和软件成果规模可以相互印证，比单纯围绕“投入了多少人月”判断更有依据。
05 更容易被忽略的，是项目结束之后
很多项目对供应商权限的管理，容易“重申请、轻退出”。
项目实施时，账号申请流程做得很完整；等到项目验收，注意力转到付款和归档，原来的测试账号、VPN账号、数据库只读账号、接口密钥，却未必同步退出。
所以，信息化项目的“验收完成”，并不意味着数据安全责任也随之结束。
如果供应商曾经下载过数据，数据副本是否处理？离场人员账号是否关闭？共享账号密码是否更换？接口密钥是否轮换？测试环境、备份库里是否还保留生产数据？
这些事项很少出现在传统的财务审计清单里，却可能决定一个项目几年后的风险。
审计署2026年的同一份公告还披露了另一个值得对照的案例：
2024年至2025年，某管理局下属8家公司未经批准和安全评估，将管理的数据出售给外部单位，相关收入1881.49万元未上交给主管单位，其中2025年474.52万元。
这与前面的政府购买服务项目并不是同一种问题。
但它们指向了同一个值得重视的变化：
数据已经不再只是信息系统运行过程中“顺带产生的东西”。
它可以被复制、提供、加工，也可能脱离原项目继续产生价值。
因此，信息化审计如果还只围绕服务器多少钱、软件多少钱、合同付了多少钱展开，就很容易忽略一个越来越重要的审计对象：
数据本身，以及对数据的实际控制权。
06 真正要防的，是“权限失控”
对于采购人来说，这类问题其实不一定要等到审计发现后再整改。
更有效的做法，是把权限管理前移到采购、实施和退出三个阶段。
在采购和合同阶段，可以尽量把“谁可以接触数据、接触到什么程度”写得更具体。比如，项目是否允许分包、哪些工作可以分包、涉及数据处理的工作能否再次转委托；供应商哪些岗位需要开通系统账号、数据库权限、接口权限，是否允许下载、导出和留存数据等。相比一句笼统的“乙方应做好数据保密工作”，这些约定更容易在后续真正落地。
项目实施过程中，则可以把人员、账号和权限对应起来。供应商新增或更换人员时，不只是看人员名单有没有报备，还可以同步关注账号是否重新审批；对于数据库、后台管理、VPN、接口密钥等敏感权限，可结合岗位职责控制授权范围，并通过日志保留实际操作记录。
到了人员离场、合同终止或者项目验收阶段，还应把“权限退出”作为一个单独动作来处理：账号是否关闭、接口密钥是否更换、供应商留存的数据副本是否清理、测试环境是否仍保存生产数据，都可以形成相应的交接或确认记录。
说到底，防范这类风险，并不是完全不让供应商接触数据，而是让每一次数据访问都能够回答三个问题：谁在访问、为什么需要访问、权限什么时候收回。
如果这三个问题始终能够说清楚，很多风险其实在项目实施阶段就已经被挡住了，而不必等到审计时再去倒查。
结语
信息化项目外包，本身并不是问题。
真正需要警惕的，是项目外包以后，采购人只记得管合同，却没有继续追踪权限去了哪里、数据到了哪里、谁在实际操作。
所以，今后审一个信息化外包项目，或许值得多问一句：
中标的是谁，并不难查。
更重要的是——最后真正登录系统、接触数据的人，到底是谁？
外包可以转移工作，但不能简单转移责任。
授权可以满足履约需要，但不应演变成对数据控制权的失去。
