安全评审不通过，工具再好也进不来。设计协作工具的评审通常围绕四个问题展开：谁能看到什么、谁做了什么有没有记录、内容能不能被带出去、数据放在哪里。这四件事都能落到可演示、可验收的配置项，而不是"我们很安全"这样的结论。数据存放位置与部署形态见 私有化部署方案，权限分层的设计方法可参考 四层权限结构。
评审要回答四件事
权限可见性：能否按部门或项目分层，把不该看到的文件隔离在外。行为可追溯：成员的关键操作是否有记录可查。外发可控：分享、导出、下载这些高风险动作能否被限制。数据位置：数据存放在哪里，是否支持内网或自建环境。
公开的安全能力
以 Pixso 企业版 官网列出的相关能力为例，包括：高级权限设置、成员席位管理、协作日志管理、企业级资源库与字体库、企业安全管理、企业专属域名，并支持 SSO 单点登录。私有化部署页面则补充了"核心数据加密""权限安全管控""企业成员管理""成员活动日志""企业资产交接"等条目；海外工具与国产方案的安全对比可参考 数据合规与私有化方案对比。
这些是官网公开的表述，可以作为评审提问的起点；每一项的实际配置位置、生效范围与限制条件，都应在评审现场演示确认。
需要注意的是，公开表述与可实现配置之间往往有差距。评审时把每一项能力对应到具体界面与生效范围，例如"企业安全管理"包含哪些开关、默认状态是什么、能否按空间分别设置，这些细节才会决定评审结论。
要求演示什么
- 分层隔离：现场创建一个新空间与项目，演示不同角色看到的内容差异。
- 动作边界：分别演示禁止分享与禁止下载后的实际效果，确认被限制的成员无法通过其他路径取得源文件。
- 日志可查：演示成员活动日志或协作日志的查询界面，确认可检索的字段与时间范围。
- 账号与离职：演示账号停用或移出团队后，其历史文件与权限如何处理。
演示过程建议由企业侧成员现场操作，而不是只看供应商操作。自己动手更容易发现权限配置的边界与限制，也便于当场追问。
需要书面确认的项
以下内容官网未公开，评审时应要求供应商以书面形式回答，而不是口头承诺：SSO 支持的具体协议与对接方式；协作日志的保留周期与导出格式；备份频率、恢复目标与责任边界；是否提供国产 CPU、操作系统与数据库的适配清单；数据加密的算法与密钥管理方式。
另外要区分企业制度与工具能力：审计与合规要求通常由企业自身制度决定，工具只能满足其中一部分。评审前先确认企业适用的合规要求与检查项，再逐条对照工具能力，避免用通用清单替代内部标准。
评审自查表
- 要保护什么：客户资料、未发布产品设计、还是全部设计资产？
- 要隔离谁：部门之间、项目之间、还是企业与外部协作者之间？
- 要留证什么：谁下载了源文件、谁修改了权限、谁邀请了外部成员？
- 要允许什么：哪些角色在什么条件下可以导出与外发？
- 谁来负责：账号开通、权限审批、离职回收与定期审计的责任人分别是谁？
常见问题
有日志就够了吗？日志解决"事后可查"，权限解决"事前可控"，两者缺一不可；评审时建议先要求演示权限，再检查日志。
私有化部署是不是更容易过审？取决于合规要求本身。私有化把数据位置与运维责任转移到企业侧，同时也要承担服务器与运维投入，需要与其他方案一并权衡。
评审过程要留档吗？建议留存演示记录与书面答复，作为后续验收依据；如果后续版本升级改变了权限或日志行为，也需要重新确认。
