文档操作日志要保存多久？谁能删、能不能改？

先定日志范围与期限依据，再逐层核对查阅、删改和到期处置权限。

“日志保存多久、谁能删、能不能改”经常在同一场选型会上被问到，却不能用一个天数和一句“只读”一起回答。业务人员想知道半年前的一次文件流转能否追溯，审计人员关心证据是否完整，运维人员还要负责存储、备份和到期处理。三方谈的可能不是同一份记录。

评估企业私有化文档系统时，建议把答案写成有条件的承诺：

• 只有明确日志对象和适用依据，保存期限才有意义。文件内容的归档期、文档操作记录的留存期、系统管理日志的留存期，应分别确认；其他产品的套餐天数不能代替本项目要求。
• 只有明确权限所在的层级，“不能删改”才有可核查范围。查询页面没有删除入口，说明该入口的能力边界；底层存储、归档副本和备份仍需各自核对管理权限。
• 只有实际取回所需记录并核对内容，“保留了”才对调查有用。配置里写着保存时间、导出任务显示成功，都需要后续的查阅验证；尚未观察到的完整保存周期应保留为待验证项。

先把“哪一类日志”写进需求

用一句具体问题替代“支持审计日志”：某个授权账号在指定时间对文件执行了一次下载，日后能否找到该事件，并解释当时的操作对象和结果？这里的下载只是待确认的目标事件，不意味着任何部署版本都已记录它。采购和试点阶段应先拿到该版本的事件清单，再决定验证哪一项。

文档正文的历史版本用于回看内容变化，系统升级记录用于追踪管理变更，两者都不能自动回答“谁下载了文件”。如果事件本来没有采集，延长保存时间也补不回来。企业尚未确定整体职责分工时，可先阅读私有化文档安全的分层责任，再为本次需要追溯的事件单独建立保留规则。

遇到以下答复时，还需要确认什么

得到的答复	能够说明的范围	继续索取的证据
管理页面只读	该页面不提供修改、删除操作	页面对应的日志类型；存储和副本的权限分工
页面可查最近一段时间	当前入口的查询窗口	更早记录的保存位置、检索方式和读取权限
日志已经导出	产生了一份输出文件	时间范围、筛选条件、分页或条数限制，以及打开后的内容核对记录
到期会自动清理	存在一项待核验的处理约定	起算时间、清理触发条件、例外保全和副本处置办法

保存期限与查询窗口要分别验收

保存期限先交由企业合规和业务负责人确认：适用要求针对哪些事件、从哪个时点起算、是否有调查或争议期间的保全安排。本文不提供适用于所有企业和日志类型的统一天数，也不把某个地区的监管要求套用到另一地区。确认后的要求，应再与拟交付版本的能力及部署方案逐项对照。

这里容易漏掉两个时间。一个是操作实际发生的时间，另一个是日志被采集或写入保存系统的时间。异步处理可能使两者不同；如果期限按入库时间计算，而查询按事件时间筛选，临界日期的结果就需要解释。核查表应写明使用哪个时间、采用什么时区，以及迟到记录如何处理。没有对应字段或说明时，记录缺口，不自行假定二者相同。

查询窗口也要单独记录。页面默认只显示近期内容，不足以证明历史记录已经删除；相反，某次能够查到很早的记录，也不足以证明未来始终按同一规则保留。出现空结果时，先核对时间和筛选条件、查询角色及事件是否在采集范围内，再排查采集失败与到期清理，避免把“当前查不到”直接写成“已销毁”。

用一张表把责任和证据留在同一处

下表可复制到项目验收文档，每一种日志单独填写一份。在表头先填“日志名称、来源系统、环境、版本、负责人、核查日期”。同一格里不要只写“支持”，而应填具体值、证据位置和确认人。未知项保留“待确认”，附责任方和约定补齐日期。

日志保留策略核查表（空白项由项目实际填写）

核查项	填写内容	接受结果前要看的证据
期限及依据	要求保存：____；适用事件：____；依据及批准人：____	经确认的制度、合同或适用要求及其版本
起算口径	事件时间：____；入库时间：____；起算字段、时区、迟到处理：____	字段说明与一条可关联的测试记录；未提供字段应注明
实际保存安排	保存位置：____；约定期限：____；配置责任人：____	对应部署版本的书面说明、获准查看的配置或实施记录
查询窗口	入口：____；可查范围：____；筛选和数量限制：____	相同条件的查询回执；早于窗口的记录如何读取
应用层权限	查询角色：____；导出角色：____；管理界面删改权限：____	权限说明与授权、未授权测试账号的实际表现
存储与副本权限	主存储、归档、备份的管理人：____；变更审批人：____	权限清单、操作审批及变更留痕方式
到期与例外	触发条件：____；保全批准人、范围及解除条件：____；副本处理：____	获准测试范围内的处理记录；未覆盖的真实周期明确列出
导出后读取	受控位置：____；读取人：____；查找方式：____；完整性依据：____	打开文件、定位指定事件和核对范围的记录，附失败项

这张表也能暴露交付边界。例如，应用管理员可以查询，却没有导出权限；归档管理员负责文件保存，却没有业务身份映射资料。单独看每个岗位都完成了工作，调查时仍可能无法解释事件。应让负责人沿着同一条测试记录走一遍，确认缺的是权限、说明、工具还是记录本身。

从一条合成记录开始，不拿生产证据试删

下面是一种验收设计，并非已完成的实验：在获准测试环境准备一份名为“演练方案”的虚构文件，由测试账号执行一次当前版本明确支持记录的操作。记录操作时间、文件标识和预期事件，再由具备查询权限的另一位人员寻找它。文件名只是合成样本，不代表产品字段或真实客户资料。

如果项目已经确认可导出，让执行者保留查询范围、筛选条件和导出说明，核对是否只导出当前页、是否存在数量上限。随后在受控位置打开输出文件，检查指定事件的主体、对象、时间和结果是否足以回答原问题。格式能打开与内容覆盖完整分别记录；不要用一条样本通过，宣称全部历史记录均已验证。

归档检查可以使用获准保存的测试副本，交给未来实际承担调查工作的人员，按记录的读取方法寻找该事件，并与保存时的基准信息核对。如果使用文件摘要校验，应将基准值及其访问权限独立管理；摘要相符只能支持与该基准一致，不能单独证明事件真实、采集完整或具备法律效力。这一动作是归档副本的受控读取，不代表产品支持日志回灌，也不等于恢复整个数据库。

到期处理只在批准的测试范围内验证，并先确认不会影响生产证据。测试周期与正式周期不一致时，应分别记录“测试规则表现”和“正式周期尚待观察”，由负责人安排后续核验。需要延长保全时，明确原因、事件范围、批准人、复核日期和解除条件；解除后按重新确认的规则处理主存储与副本，不能把一次调查变成永久保存所有记录的理由。

产品说明要落实到具体入口和版本

以石墨办公套件私有部署的部署运维文档“操作日志”为例，已核实的说明针对系统中的管理操作，包括配置更新、版本升级、服务重启等；该页面为只读查询，不支持修改或删除日志记录。文档也说明只记录已接入审计的操作，数量可能受环境保留策略影响。这些信息不等于所有文档查看、编辑、下载事件都已覆盖，也不能证明底层管理员无法变更数据。

如果本项目需要文档流转审计，应另外请交付方确认事件范围、查询与导出能力、保存安排和各层管理权限；不能据此页面承诺任意天数配置或绝对不可篡改。把前面的核查表带入试点评审，先补齐关键事件与期限依据，再验证查询、受控读取和到期处置。每项结论都对应一份证据，未确认的条件明确留在验收记录中。需要按本单位要求逐项核对时，可以预约演示，也可以先看私有化部署方案，了解部署形态与交付范围。