我最近一次做 ERP 权限复核，是在一家年 GMV 约 4.2 亿的跨境卖家那里。HR 系统显示这位运营总监 47 天前已经离职，但 ERP 里他的账号状态还是“在职”，并且仍然持有三个亚马逊站点的广告花费导出权限。更麻烦的是，导出记录只保留了“有人导出过”这一条，没有记录导出的是哪个店铺、哪张报表、多少行数据。
这家公司的 ERP 权限页面做得相当漂亮：角色、菜单、按钮、数据范围，四个标签页一应俱全。问题不在于“有没有权限管理功能”，而在于没有一个可考核、可取证、可复算的指标体系。当时他们对权限能力的自评是 85 分，我用 12 项指标实测下来是 43 分。
这就是我想在这篇文章里说清楚的事：跨境电商 ERP 的能力清单里，权限管理这一项不能写成“支持角色权限配置”六个字糊过去。它需要一套分层的指标体系，覆盖从账号身份、角色权限、数据范围、审批流程到审计证据的完整链条。下面我按“结论，背景，误区，判断逻辑，指标体系，案例，清单，验收，建议，取舍，路线”的顺序展开，全部口径都写成可以直接拿去对表的形式。
结论第一条：权限管理不是 ERP 的一个功能模块，而是一条五层证据链。身份与组织层回答“他是谁、属于哪个主体”，角色与权限层回答“他能调用哪些功能”，数据与范围层回答“他能看到哪些数据”，流程与审批层回答“他的权限怎么来、怎么变、怎么走”，审计与证据层回答“出了事能不能证明”。五层缺一层，整条链就断。
结论第二条：指标必须同时满足可考核、可取证、可复算三个条件。“支持数据权限”不是指标，“跨店铺越权访问拦截率”才是指标；“有操作日志”不是指标，“敏感操作日志完整率≥99%、按人按单可检索”才是指标。
结论第三条：跨境场景会把权限问题的破坏力放大 3 到 5 倍。因为多组织、多店铺、多平台、外部协作、数据出境这五个变量叠加在一起，任何一处权限设计偷懒，都会在跨国主体之间产生不可逆的连带风险。
结论第四条：不要追求角色数量多。我见过一个卖家有 380 多个自定义角色，其中 210 个只有一个账号在用，权限复核时根本没人说得清哪个角色该保留。角色爆炸本身就是一种权限风险。
下面这张表是我在实际验收中用的五层总览，你可以直接拿去当对表模板。
| 层级 | 回答的核心问题 | 代表指标 | 主要审计证据 |
|---|---|---|---|
| 身份与组织层 | 账号属于谁、归属哪个法人主体 | 账号实名覆盖率、离职权限冻结时效、僵尸账号数 | 账号台账、HR 离职单、冻结记录 |
| 角色与权限层 | 能调用哪些功能、是否越权 | 最小权限符合率、职责分离冲突数、越权访问尝试次数 | 角色矩阵、越权告警流水 |
| 数据与范围层 | 能看到哪些店铺、字段、报表 | 数据隔离测试通过率、敏感字段脱敏率、导出审批覆盖率 | 隔离测试报告、导出审批单 |
| 流程与审批层 | 权限怎么授予、变更、回收、复核 | 权限变更留存率、定期复核覆盖率、临时权限过期率 | 审批流日志、复核记录、到期回收日志 |
| 审计与证据层 | 出事后能不能还原事实 | 日志完整率、日志留存周期、审计报告出具时长 | 审计报表、取证包、事件响应记录 |
如果只做国内电商，权限模型通常三层就够了：公司，部门，岗位。但跨境电商几乎一定会遇到多法人主体、多平台店铺、海外仓、代运营、外币结算这五个变量。每加一个变量，权限的组合空间不是线性增长，而是相乘。
我做过一个粗糙的估算：一个国内电商中台的权限组合大约是“组织数 × 角色数”，通常在几百到几千量级；而一个年 GMV 3 亿以上的跨境卖家，权限组合是“法人主体数 × 平台数 × 店铺数 × 角色数 × 数据对象数”，很容易突破十万量级。这不是理论推演，是我在三家不同规模卖家那边数过角色矩阵后的实际感受。
同一个人可能同时是香港主体和深圳主体的员工，他在两个主体下的权限边界完全不同。如果 ERP 只按“人”建模，不按“法人主体 + 任职关系”建模，那么他在 A 主体的权限会自动带到 B 主体，这在财务上就是串账风险。
亚马逊、Shopee、TikTok Shop 等平台的授权 Token，本身就是一种高价值凭证。一个 Token 往往绑定了店铺的核心数据读取权限，甚至包含广告、财务接口。如果 Token 由个人账号申请、存放在个人电脑上、没有有效期管理，那么 ERP 内部的权限做得再好，外部的门也是开的。
代运营、货代、海外仓、税务代理、独立站建站服务商，这些角色都需要登录 ERP 或平台后台。他们的特点是：临时性、流动性高、不属于公司 HR 体系、离职时没人通知 IT。我统计过自己在四个跨境项目里遇到的权限事故，外部账号相关的问题占了 42%，而这类账号在 ERP 里通常连“账号到期日”这个字段都没有。
当订单数据包含海外买家个人信息，而团队在国内操作时，权限日志就不再只是内控需要，而是合规需要。此时“谁在什么时候把哪些字段导出到了哪里”必须可回答，这和传统 ERP 只记录“操作了哪个菜单”完全不是一个量级。
下面六条不是从资料里抄的，是我在项目复盘会上反复听到、也反复被审计挑出来的问题。每一条都对应真实的钱或真实的时间损耗。
最常见的表述是“我们的权限管理没问题，新人入职当天就开号”。这句话只覆盖了权限生命周期的第一个环节。真正的成本发生在后面：岗位变更时权限没减、离职时权限没回收、项目结束后临时权限没关闭。权限管理的成本 80% 在回收阶段，而不是授予阶段。
角色爆炸的典型症状是：新建角色时找不到合适的，于是复制一个再改两个菜单，最后没人敢删。一个 380 角色的体系，其实际可维护性低于一个 25 角色的体系。我的经验阈值是：单个法人主体下的活跃角色数控制在 30 个以内，超出部分必须有书面说明。
有日志、能打开、能看到一行文字，这和可审计差得很远。可审计要求：能按人查、能按订单查、能按店铺查、能按字段查、能导出、能证明日志未被篡改。我见过最多的情况是，日志存了 180 天，但只能按时间倒序翻页，一次取证要花两三天。
只要回收动作依赖“HR 发消息给 IT”，就一定会有漏网之鱼。我建议把这条做成硬指标：离职生效到全部系统权限冻结的时间差，中位数不超过 4 小时，最长不超过 24 小时。超过这个阈值的每一小时，都是可被内审直接写进意见的窗口期。
代运营账号最常见的配置是：给一个通用账号，权限对齐内部运营，没有到期时间。这个账号在合作结束后依然有效。正确做法是：一人一号、绑定身份证件或企业信息、设定到期日、限定店铺范围、禁止批量导出、禁用 API 调用。
数据出境评估、个人信息处理清单、跨境传输记录，这些工作如果等到审计前才补，成本会是设计阶段做的 5 到 8 倍。因为补的时候要回溯历史日志，而历史日志往往不全。
选型阶段时间有限，不可能把每个菜单都点一遍。我用三个问题做快速判断，基本能在两小时内给出结论。
这是最核心的一问。要求对方现场演示：选一个具体订单号，查出所有接触过它的账号、时间、动作、来源 IP、是否导出。如果只能查到“某账号在某个时间登录过”，说明数据层和审计层是断的。
关键在于“复算”：给我一个时间点，能不能还原那一刻某账号的完整权限快照？很多系统只存“变更前后差异”，不存完整快照，导致三个月前的权限状态无法还原。这一条在发生纠纷时价值极高。
例外路径包括：临时权限、紧急访问（break-glass）、管理员代登录、批量导入、API 直连。这五条路径是审计最关注的，也是最容易失控的。没有例外路径管控的权限系统，等于只有一扇装了锁的门，旁边开着五扇没装的窗。
下面这五层是我实际交付时用的结构。每层给出核心指标、建议口径、数据来源、阈值和常见失真点。你可以直接对照自己当前的 ERP 能力做勾选。
这一层是所有权限的地基。跨境场景下，身份模型必须包含两个维度：自然人身份和组织任职关系。同一个人在不同法人主体下的任职关系，必须能分开授权、分开回收。
核心指标建议如下表。注意“僵尸账号数”这一项，它是我判断一家公司权限治理水平的第一个信号。
| 指标 | 建议口径 | 数据来源 | 参考阈值 | 常见失真点 |
|---|---|---|---|---|
| 账号实名覆盖率 | 绑定真实身份的自然人账号数 / 全部启用账号数 | 账号台账 + HR 花名册 | ≥ 98% | 用邮箱当身份，一人多号未合并 |
| 离职权限冻结时效 | 离职生效时间到全部系统权限冻结完成的时间差 | HR 离职单 + 权限回收日志 | 中位数 ≤ 4 小时，最长 ≤ 24 小时 | 只冻结登录，未回收 API Token 与平台授权 |
| 僵尸账号数 | 连续 90 天无登录且无接口调用的启用账号 | 登录日志 + API 调用日志 | ≤ 总账号数 3% | 服务账号被误判为僵尸账号 |
| 外部账号占比与到期率 | 设置到期日的外部账号数 / 全部外部账号数 | 外部协作台账 | 100% 设置到期日 | 到期日填的是合同到期日而不是访问到期日 |
| 多主体归属清晰率 | 任职关系明确的主账号数 / 全部账号数 | 组织架构主数据 | ≥ 95% | 用部门字段代替法人主体字段 |
这一层的核心不是角色数量，而是最小权限符合率。做法是先为每个岗位定义一条权限基线，再抽检实际权限是否超出基线。
我建议把权限拆成四类分开管：功能权限（能不能进这个模块）、数据权限（能看哪些范围）、字段权限（能不能看手机号、成本价）、操作权限（能不能导出、能不能审批）。这四类混在一个角色里配置，是后期失控的主要原因。
职责分离（SoD）冲突数这一指标特别值得单独看。跨境场景下最典型的冲突是：同一个人既能改商品价格，又能审批折扣；既能创建供应商，又能审批付款。这两类冲突在审计里几乎是必查项。
国内 ERP 的数据权限通常按部门和门店划分，跨境要按“法人主体 × 平台 × 店铺 × 站点 × 仓库 × 币种”划分。维度一多，就必须靠规则继承而不是逐条配置，否则维护成本会失控。
这一层我建议重点看三个指标：数据隔离测试通过率、敏感字段脱敏率、导出审批覆盖率。其中导出审批覆盖率是最容易被忽略的一项。因为在跨境场景里，真正的数据泄露往往不是“看到了”，而是“导出去了”。
流程层的价值在于把权限从一个静态配置变成一个有始有终的过程。四个关键动作：授予、变更、复核、回收。每一个动作都要有触发条件、审批人、留痕和时间约束。
我最看重两个指标：定期复核覆盖率（建议按季度 100% 覆盖敏感角色）和临时权限过期率（临时权限应 100% 自动过期，不依赖人工关闭）。
这一层的指标看起来最“虚”，但它的缺失会把前四层的投入全部清零。日志完整率、日志留存周期、可追溯率、审计报告出具时长，这四个指标我建议直接写进 ERP 验收标准。
关于留存周期，跨境场景建议至少 12 个月，涉及资金与个人信息的关键操作建议 24 个月。理由很直接：一次跨境合规核查的回溯周期往往跨越自然年。
下面是我在项目里用的权限基线定义片段，可以直接作为配置模板的起点。
role_baseline:
role_id: ops_us_amazon
entity: US_ENTITY # 法人主体，必须显式声明
scope:
marketplaces: [US, CA]
store_groups: [brandA_us, brandA_ca]
warehouses: [LA_3PL]
allow:
order.view
order.export # 需二次审批
price.edit # 需财务审批链
deny:
payment.release
settlement.view
supplier.create # SoD 冲突项，硬禁止
field_mask:
buyer_email
buyer_phone
cost_price
constraints:
mfa_required: true
ip_allowlist: true
session_timeout_minutes: 30
export_row_limit: 5000
temp_grant_max_hours: 72
再给一段我在做离职冻结时效核算时用的 SQL 口径。这类口径最好固化进 BI 层，按周自动跑，而不是每次审计前临时统计。
-- 离职账号权限冻结时效（小时），输出超阈值的异常记录 SELECT u.user_id, u.entity, u.offboard_ts, MIN(p.revoked_ts) AS first_revoke_ts, MAX(p.revoked_ts) AS last_revoke_ts, ROUND((MAX(p.revoked_ts) - u.offboard_ts) * 24, 1) AS revoke_lag_hours, COUNT(*) FILTER (WHERE p.revoked_ts IS NULL) AS still_active_grants FROM hr_offboard u LEFT JOIN permission_grant p ON p.user_id = u.user_id AND p.entity = u.entity GROUP BY 1, 2, 3 HAVING revoke_lag_hours IS NULL OR revoke_lag_hours > 4 OR still_active_grants > 0;
讲到这里都是框架，容易显得抽象。我用一个具体的产品来落地说明，数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）。它是一个面向跨境电商的数据与经营分析平台，我在一个年 GMV 约 3 亿的卖家项目里，用它承接了多店铺数据汇总与经营看板的权限分层。
那次项目的现实约束是：业务 ERP 更换成本太高，短期内不可能重构。但审计意见已经下来了，要求六个月内有可验证的改进。于是我们做了一个折中方案：业务操作仍然在原 ERP 里，但把跨店铺、跨平台的经营数据汇总先收敛到数跨境这一层，在这层做数据范围隔离、字段脱敏和导出审批。
这个方案的好处是见效快。因为数据侧的权限改造不涉及业务流程变更，不需要运营团队改变操作习惯，落地阻力小得多。三周时间就完成了第一版分层。
我们把访问者分成四类，每类对应一套固定的数据范围规则：
这四类规则写进配置后，新增账号只要选择对应的角色模板，数据范围自动继承，不需要逐个店铺手工勾选。这一点非常关键，因为它把权限配置从“每次都要判断”变成了“默认正确”。
下面这组数据是该项目上线前后三个月的对比，属于项目实测数据，但为保护客户信息做了区间化处理，你可以把它当作一个量级参考，而不是精确统计。
| 指标 | 上线前 | 上线后 | 变化说明 |
|---|---|---|---|
| 僵尸账号数 | 37 个 | 4 个 | 清理了离职与转岗未回收账号，剩余 4 个为已登记的自动化服务账号 |
| 季度权限复核耗时 | 约 26 小时 | 约 6 小时 | 复核改为按规则模板比对，不再逐人翻菜单 |
| 单次审计取证耗时 | 约 18 小时 | 约 2.5 小时 | 可按账号、订单、店铺、字段四个维度组合检索并导出 |
| 数据导出审批覆盖率 | 41% | 98% | 超过 5000 行的导出强制走审批，剩余 2% 为系统自动报表 |
| 跨店铺越权访问尝试 | 无记录 | 约 23 次/月 | 并非风险上升，而是原本不可见的行为现在被记录并拦截 |
| 外部账号到期回收率 | 约 30% | 100% | 全部外部账号强制设置到期日，到期自动失效 |
有一个细节值得单独说：“跨店铺越权访问尝试从无记录变成 23 次/月”，这不是坏事，反而是治理生效的标志。因为在此之前，这些尝试要么被允许了，要么根本没被记录。很多企业在做权限治理时会因为“告警变多了”而怀疑方案有问题，其实方向正好相反。
通用 ERP 的权限清单通常止步于“角色，菜单，数据范围”，但跨境场景还有八类必须单独列出的事项。我把它们按“发生概率 × 影响程度”排了个序，你可以对照自查。
要求：Token 由公司主体统一申请，绑定到法人实体而不是个人账号；设置有效期与到期提醒；建立 Token 台账，记录授权范围、绑定的店铺、申请人、审批人；离职时必须同步回收 Token。
要求：一人一号、实名登记、设定到期日、限定店铺范围、禁止导出与 API 调用、合作结束后 24 小时内注销并留存注销记录。
要求：买家姓名、邮箱、电话、地址、支付信息列为敏感字段，默认脱敏；导出需审批；跨境传输需有合法性依据与记录；权限日志需支撑合规答复。
要求：创建付款与审批付款分离；退款额度分级授权；佣金调整独立审批；所有资金类操作强制双人复核并留存审批链。
要求：改价与审批折扣分离；广告预算调整设置阈值告警；大额投放变更需留痕；禁止同一人同时拥有投放与预算审批权限。
要求：海外仓与货代账号按仓库、按线路限定数据范围；库存调整类操作单独记日志；异常调拨需事后复核。
要求：财务权限按法人主体隔离，跨主体查看需单独授权；报表查看范围与任职关系绑定；税务申报相关操作独立留痕。
要求：自定义查询工具往往能绕过界面权限直接取数，必须单独做数据范围限制；看板的分享链接需控制有效期与访问范围。
其中第七和第八条是最容易被忽略的。自定义查询和分享链接是权限体系里典型的“旁路”，很多企业界面权限做得很好，但一个分享出去的看板链接就把数据范围限制全部绕过了。
选型阶段最有效的方式不是看 PPT，而是让对方在真实环境里做五件事。我在评标时基本都用这套流程，通常能在 90 分钟内分出高下。
给出三个场景，要求现场配置：场景一，同一人在两个法人主体下有不同权限；场景二，一个账号同时负责三个平台的五个店铺，需要看到汇总但不能看到其他店铺明细；场景三，一个临时账号 72 小时后自动失效且期间禁止导出。
指定一个订单号，要求查出：谁看过、谁改过、谁导出过、什么时间、什么 IP、导出了哪些字段。如果对方只能查到操作类型而查不到字段，直接扣分。
要求还原 30 天前某一时刻某个账号的完整权限列表。这一项是硬门槛，做不到意味着事后无法定责。
核对 SSO、SCIM 自动开停号、AD/LDAP 同步、API 权限粒度。其中 SCIM 自动开停号直接决定离职冻结时效能否做到 4 小时以内，属于必查项。
按下表打分，每项 1 到 10 分。我的经验是：总分低于 40 分的系统，不建议在没有额外补偿措施的情况下承载跨境多主体业务。
| 评分维度 | 权重 | 评分要点 |
|---|---|---|
| 数据范围隔离 | 20% | 能否按法人主体、平台、店铺、站点、仓库多层组合隔离 |
| 字段级权限与脱敏 | 15% | 敏感字段能否独立控制查看与导出 |
| 审计日志与取证 | 20% | 能否按人、按单、按店铺、按字段导出，能否还原历史快照 |
| 临时权限与到期回收 | 15% | 临时授权是否强制设置到期时间并自动回收 |
| 身份集成能力 | 15% | SSO、SCIM、AD/LDAP、API 权限粒度 |
| 外部账号治理 | 15% | 外部账号是否有独立生命周期、范围限制与注销记录 |
权限治理没有统一答案，取决于你的规模、主体数量和团队能力。下面按四种情况分别给建议，你可以直接对号入座。
这个阶段不需要复杂体系，重点做三件事：账号实名与一人一号、离职当天冻结、敏感字段默认脱敏。不建议此时投入做字段级权限矩阵，因为团队规模小，沟通成本低于配置成本，过度设计反而拖慢业务。
这个阶段的拐点是外部账号。建议优先做两件事：外部账号独立生命周期管理、导出审批与行数限制。同时开始定义岗位权限基线，把最小权限符合率做成季度指标。
这个阶段必须上指标体系。建议把本文第五节的五层指标全部纳入季度复盘，并配置至少一名专职的权限管理员（可以是兼职但要有明确职责）。同时开始做权限快照留存与审计报表自动化。
这个阶段建议把权限治理与合规体系合并管理。具体动作包括：数据出境评估前置、权限日志留存延长至 24 个月、建立跨主体的权限联合复核机制、把权限指标纳入内控评价体系。
另外提醒一点：不论什么规模，都不要把权限回收的触发条件只挂在 HR 流程上。合作终止、项目结束、岗位调整、长期休假，这四类情况同样需要触发权限复核，而它们通常不经过离职流程。
权限治理本质上是一组取舍。想全部都要，最后往往什么都做不实。下面是我在实际项目中最常做的四组取舍判断。
不要对所有角色都做字段级管控。我的做法是按敏感度分三级：高敏感角色（财务、资金、成本相关）做字段级 + 审批级管控；中敏感角色（运营、投放）做数据范围 + 导出限制；低敏感角色（客服、基础查询）只做数据范围。这样能把运维成本压缩到全量精细化方案的三分之一左右。
判断标准很简单：这个操作是否可逆。改价、退款、付款这类不可逆或高成本可逆的操作，必须走审批；查询、看板、报表这类可逆操作，用日志和告警代替审批。把审批加在可逆操作上，是权限治理里最常见的效率浪费。
我的经验是：法人主体在 2 个以内，标准产品的权限能力基本够用；超过 3 个主体，且主体之间需要严格数据隔离，往往需要一定的定制开发。这时候要评估的不是开发成本，而是后续每次产品升级时的回归测试成本。
不建议对所有日志统一留存 24 个月。可以分层：涉及资金、个人信息、权限变更的日志留存 24 个月；普通业务操作日志留存 12 个月；查询类日志留存 6 个月。这样既满足审计要求，也把存储成本控制在合理区间。
如果你现在就要动手，我建议按下面的节奏推进。这个节奏在三个项目里验证过，核心原则是先做看得见的、再做查得到的、最后做证明得了的。
第三阶段的模拟审计是最容易被跳过的一步，但它的价值最高。因为很多证据链的断点，只有真正被追问一次才会暴露出来。
回到开头那个离职 47 天的账号。它的存在不是某个人的失误，而是一套没有指标的体系必然的产物。当没有人统计“离职冻结时效”，这件事就不会有人负责；当没有人统计“导出审批覆盖率”，导出就永远是一个盲区。
我在这篇文章里坚持一个观点：跨境电商 ERP 的权限管理能力，不能用功能清单来验收，只能用指标体系来验收。因为功能清单回答的是“系统能不能做”，而指标体系回答的是“你的组织有没有真的做到”。前者可以靠采购解决，后者只能靠持续运营解决。
如果只能带走三句话，我希望是这三句：
下一步你可以做两件事。第一件，把本文第五节的五层指标表复制出来，对照自己的 ERP 逐项打勾，先找出缺项。第二件，挑一个你最有把握的指标，我建议从“离职权限冻结时效”开始，用一周时间把它算出来，看看真实数字是多少。
如果你希望更快看到数据侧的分层效果，可以先去数跨境（https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）看看它在多店铺数据汇总与权限隔离上是怎么组织的，用它做一个低成本的验证起点。业务系统的权限改造往往周期长，但从数据侧先把范围隔离和导出管控立起来，通常两三周就能看到可量化的变化。
权限治理不追求一次性做完，它追求的是每一个季度都有可测量的进步。只要指标在跑，风险就会在发生之前被看见，这才是能力清单里权限这一项真正的价值。
我们公司今年在做ERP选型，评分表里权限那一栏永远被写成“支持角色权限、支持操作日志”，评审会上谁也说不清这算不算够。我也不是安全出身，怕漏项又怕写太细没人看得懂。所以想先把框架定下来，再往里填条目。
建议按五层来搭，每层至少落3个可量化指标，缺一层就说明能力有洞。第一层身份与组织：账号覆盖率、实名率、多组织绑定准确率、僵尸账号数。第二层角色与权限：最小权限符合率、职责分离冲突数、角色复用率、越权访问尝试次数。第三层数据与范围：跨店铺/跨组织越权用例通过率、敏感字段脱敏覆盖率、导出审批率。
第四层流程与审批：权限变更留痕率、定期复核覆盖率、临时权限到期自动失效比例、异常授权闭环率。第五层审计与证据：日志完整率、日志留存周期、按人/按单/按店铺的可检索维度数、审计报告出具时长。判断标准很简单：每一层都要能回答“谁、在什么范围、对什么数据、做了什么操作、留下什么证据”。
如果某个产品只能给菜单和角色权限，另外四层全靠人工补，在跨境场景下基本不达标，因为你要同时管多店铺、多法人、外部代运营和多平台。
我们是铺货型卖家，亚马逊、独立站、TikTok Shop 加起来几十个店铺，还分了三个运营组和一个海外仓团队。以前只按“部门”分权限，结果运营能看到别人店铺的毛利和广告花费，出过两次内部争议。我想把数据权限单独做成指标，但不知道怎么设口径才算真的测过。
先定范围维度：店铺、站点、法人主体、仓库、供应商、财务科目，这六个维度要能自由组合授权，而不是只能二选一。然后按这四类指标考核。一是数据隔离测试通过率，口径是通过的跨店铺/跨组织越权用例数除以总用例数，建议把“店铺×组织×角色”做成测试矩阵，验收目标100%通过，只抽查几个账号就签字是没有意义的。
二是敏感字段脱敏覆盖率，敏感字段包括成本价、毛利、银行账号、收付款信息、买家姓名电话地址，口径是被策略覆盖的字段数除以盘点出的敏感字段总数。三是敏感操作审计覆盖率，口径是有完整操作记录的敏感操作数除以敏感操作总数，改价、退款、佣金调整、付款审批、批量导出都算敏感操作。
四是导出与下载控制率，口径是走审批流程的导出次数除以总导出次数，同时要看导出文件是否带水印、是否记录文件内容摘要。跨境还要额外加一条数据出境检查项：哪些字段会流出到境外系统或第三方工具，由谁审批、是否有评估记录。
这部分涉及个人信息和跨境传输，具体合规要求以企业适用法规和最新平台规则为准，需要法务或合规确认，不要在指标里写死结论。
我们是去年开始接代运营的，对方要开后台看数据，当时就给了个管理员子账号，也没写到期时间。后来运营离职两三个月，我才发现他的ERP账号还能登，广告账号也没解绑。这类事我觉得不是我们一家有，但真要做成指标又不知道抓哪几个数。
抓六个就够用，而且都能直接从系统里取数。一是账号覆盖率，口径是ERP里在用的账号数除以HR在册应开通人数，长期大于1说明有幽灵账号。
二是离职权限回收时效，口径是离职生效时间到全部系统（ERP、广告后台、支付、邮箱、店铺后台）权限冻结完成的最长时间差，目标建议当日完成、能自动化就压到分钟级，靠人工催的指标一定会漂。三是僵尸账号数，口径是连续90天无登录但仍持有有效权限的账号数量，每月盘点一次。
四是临时权限到期自动失效率，口径是到期自动回收的临时授权数除以临时授权总数，目标100%，要允许申请但必须写清用途和期限。五是外部协作账号合规率，口径是带明确期限、数据范围、可追溯ID（不能共用）且有NDA或合同依据的外部账号数除以外部账号总数，代运营、货代、外包客服都算进来。
六是API Token与密钥治理指标，口径是超期未轮换的Token数、权限超出业务所需的Token数、无绑定责任人的Token数。这几个指标的价值在于，它们不依赖任何人的自觉，只要数字难看，就说明流程上一定有地方在靠人兜底。
我们刚被一个平台要求提供某笔订单的操作记录，结果翻后台只看到“某某修改了订单”，改了什么、从什么改成什么、通过哪个IP改的都没有。IT说日志有，但导不出来。所以我现在特别看重“可审计”，可又怕被厂商一句“我们支持全量日志”糊弄过去。
日志类指标要写到“能被第三方复现”的程度，建议四个。一是日志完整率，口径是有完整操作记录的敏感操作数除以敏感操作总数，完整指至少包含操作人、时间、来源IP或设备、对象、操作前后值、结果，目标100%。
二是留存与不可篡改性，口径是可按配置保留的月数、是否支持只追加不删除、是否有导出校验值，具体留存期限按企业适用法规和平台规则确定，别照抄网上数字。三是可检索维度，口径是能否按人、按单号、按时间区间、按店铺、按字段、按IP六个维度组合查询并导出原始明细，只能看不能导等于不可用。
四是审计响应指标，口径是从提出取证需求到交付完整证据包的平均时长，以及异常操作的告警到闭环时长。选型验收阶段不要看厂商准备好的演示环境，直接提四个现场测试：一是用A店铺的账号尝试访问B店铺数据；二是导出一份含成本价的报表，看是否触发审批和留痕；三是走一遍离职流程，测全部系统权限冻结的真实耗时；
四是查一条历史订单的全链路操作记录，要求导出原始日志并现场比对字段是否齐全。厂商如果在这四步上含糊、只肯截图或只肯给PPT，基本可以判定权限能力停留在菜单层面。
读者评论
离职47天账号还在职这段太真实了。很多公司权限复核只看有没有角色配置，根本不看离职冻结时效。建议把HR离职单和ERP冻结记录做自动比对，否则人工通知一定有漏。
五层证据链这个提法比单纯罗列功能菜单实用。尤其数据范围层，跨店铺越权测试不做，光看页面上的数据权限勾选项根本发现不了串号。
外部账号治理自评70实测29，落差最大不意外。代运营、货代账号经常一人多店、无到期日，合作结束没人注销，出了事连责任人都难定位。
日志能存180天不等于可审计，按人、按单、按店铺、按字段检索才是关键。跨境涉及数据出境，取证翻两三天日志，合规答复时效肯定扛不住。