审计记录核对表：留哪些记录、存多久、谁能查

审计记录真正难的地方，不是系统里有没有日志，而是三个问题同时说得清，哪些记录必须留，留到什么时候，出了事谁能查。IBM《2025年数据泄露成本报告》显示，由恶意内部人员引发的数据泄露平均成本为492万美元，高于其他初始攻击媒介。事件发生后，企业如果拿不出完整的登录、消息、文件和权限变更记录，定责、止损和对外说明都会被动。

《网络安全法》第二十一条已经把底线写明，网络运营者要采取监测、记录网络运行状态和网络安全事件的技术措施，并留存相关网络日志不少于六个月。放到企业即时通讯场景， 六个月只是网络日志的底线，不等于所有审计记录都只存半年。

下面按三条线展开，先看留哪些记录，再看每类记录存多久，最后看谁能查、怎么留审批痕迹。后半部分给出四类企业即时通讯方案的审计能力边界，以及一套可以按季度跑的核对流程。

先给结论，三句话记住核对重点

核对问题	直接结论	主要依据
留哪些记录	身份、登录、消息、文件、群组权限、管理员操作、审计访问、安全事件、会议共享、备份销毁，十类记录至少覆盖前六类	等保2.0对审计记录内容的要求
存多久	网络日志不少于六个月，一般审计记录建议十二个月，高风险记录建议三年，诉讼和监管调查期间先保全	网络安全法第二十一条、个人信息保护法第五十六条
谁能查	系统管理员、安全管理员、审计管理员分权，合规法务按事由审批调阅，外部监管依法定程序	最小必要、职责分离、查询留痕

这张表是核对的总览，具体字段和期限还要往下拆。不同行业、不同规模的组织，可以把表中的建议期限改成自己的制度期限，但底线来源要写清楚。

留哪些记录，先分清行为记录和内容记录

审计记录不是把所有聊天内容复制一份。审计要还原的是谁在什么时间、从哪里、做了什么、结果如何。内容记录回答说了什么，行为记录回答谁动了什么。两者都要有边界，不能混成一锅。

等保2.0对审计记录的要求不只是有日志，还要覆盖每个用户的重要行为，记录事件时间、用户、事件类型和结果，并且定期备份、防止被意外删除或覆盖。落到企业即时通讯场景，记录清单可以按下面十类展开。

六类基础记录，缺一类就断链

记录类别	至少要留的字段	常见来源	核对要点
身份与账号	账号、姓名、部门、角色、开通与停用时间、操作人	后台账号管理	离职账号是否及时停用
登录与认证	时间、账号、IP、设备、成功或失败、认证方式	登录日志、LDAP认证日志	异地和异常时段登录能否筛出
消息流转	发送人、接收人或群、时间、消息类型、消息ID	即时通讯服务端	内容留存范围是否有制度
文件传输	文件名、大小、哈希、上传下载人、时间、接收范围	文件服务、客户端日志	文件行为和文件内容是否分开管
群组与权限变更	建群解散、成员增减、管理员变更、外部联系人	后台与群管理日志	外部群和跨组织群是否重点留
管理员操作	参数修改、审计策略变更、数据导出、备份恢复	后台操作日志	管理员能否删除自己的日志
审计访问	谁查了审计、查了谁、何时、导出多少条、审批单号	审计系统自身日志	查审计这件事是否也被记录
安全事件	告警时间、类型、涉及账号、处置动作、关闭时间	安全告警、工单	是否与复盘报告关联
会议与共享	会议时间、参会人、共享屏幕、录制文件访问	会议服务	录制文件是否按敏感资料管理
备份与销毁	备份时间、范围、存放位置、恢复演练、到期销毁	运维台账	是否只备份不验证

这十类记录里，身份、登录、消息、文件、权限变更和管理员操作是基础盘。会议、备份、销毁和安全事件记录按业务敏感度补齐。资源有限时，先保证基础盘能拼出时间线，再补其他类型。

如果企业用的是即时通讯系统，还需要把消息审计的记录字段和后台日志对上。站内这篇 即时通讯软件的安全审计把审什么、和聊天监控的区别讲得更细，可以作为扩展阅读。

记录字段要能拼成一条时间线

判断一条审计记录有没有用，看它能不能和其他记录拼成时间线。只有一张聊天截图，证明不了发送人身份、发送时间和内容有没有被改过。把消息ID、发送人账号、接收范围、服务端时间、文件哈希和登录IP放在一起，才能还原一次完整行为。

我在做企业审计核对时，通常先要求系统能按人和按时间两个维度检索，再看能不能导出带时间戳和操作人的记录。如果系统只能按关键词搜聊天内容，却查不到谁在什么时候导出过文件，这样的审计能力是不完整的。

内容检索解决业务问题，行为追溯解决定责问题，两件事不能互相替代。审计核对时，两类记录要分别抽样，不能只看其中一类。

审计记录和聊天记录不是一回事

很多企业把聊天记录当成审计记录，真出事时才发现只有内容，没有登录IP、没有文件下载记录、没有权限变更记录。聊天记录能说明说了什么，审计记录还要说明谁说的、从哪登录、发给了谁、有没有被转发或下载。

另一个常见问题是只留结果不留过程。比如只记录一次文件外发成功，却没记录谁审批、审批时间、审批意见。审计核对时，过程记录往往比结果记录更能说明责任边界。

图1 审计记录的六个基础层，身份、登录、消息与文件、权限变更、管理员操作、审计访问要能互相串联。

存多久，六个月是底线，不是统一答案

把六个月当成所有记录的统一期限，是审计核对里最常见的偷懒做法。六个月来自《网络安全法》对网络日志的要求，覆盖的是网络运行状态和网络安全事件相关日志。消息内容、文件、管理员操作、审计访问记录，期限要看行业监管、诉讼风险、档案要求和内部制度。

三类期限要分开定

记录类型	底线或参考	建议管理期限	触发延长的情形
网络运行与安全日志	不少于六个月，网络安全法第二十一条	十二个月	等保测评、监管检查、事件调查
登录、消息、文件、权限变更、管理员操作	无统一法定年限，按行业和制度	十二个月，敏感岗位可到三年	金融、能源等强监管行业，以及国企，涉及诉讼
个人信息保护影响评估报告和处理记录	至少三年，个人信息保护法第五十六条	三年	处理活动持续或发生变更
会计凭证、会计账簿等会计档案	三十年，会计档案管理办法	三十年	年度财务会计报告永久保存
安全事件与处置记录	无统一年限	三年	重大事件、监管调查、诉讼
会议录制与共享文件	按内容敏感度定	六个月到十二个月	涉及合同、投资、人事等敏感议题

表中的十二个月和三年是管理建议，不是法定统一要求。法定底线只有网络日志六个月、影响评估记录三年等明确条款，其他期限要结合行业监管和企业制度确定。如果审计范围涉及财务凭证，期限要按会计档案管理办法走，不能套用六个月的网络日志标准。

这张表可以直接改成企业自己的留存期限表。做法是先定每条记录的底线来源，再定管理期限，最后定触发延长的条件。底线来源写法规或行业规定，管理期限写内部制度，触发条件写事件、诉讼、监管检查。三栏都写清楚，审计时才能解释为什么留这么久。

六个月、一年、三年怎么选

六个月是法定底线，适合网络运行日志和一般安全日志。一年适合大多数企业的消息、文件、权限变更和管理员操作记录，能覆盖一次年度审计和一次跨年度事件回溯。三年适合高风险记录，比如涉及敏感个人信息、财务审批、重要合同、核心研发资料的操作记录。 六个月是法定底线，一年是多数企业的管理线，三年留给高风险记录。

更稳妥的做法是不要所有记录都存三年。存储成本只是一部分，更大的问题是权限扩散和删除义务。留得越久，能查的人越多，泄露和误用的概率也越高。

到期删除也要有记录。很多企业只写留存期限，不写到期怎么处理，结果日志越堆越多，最后没人敢删。审计核对时，除了看留存策略，还要看销毁审批、销毁记录和备份副本是否同步清理。

诉讼和监管调查期间，先保全再谈期限

一旦进入诉讼、仲裁、监管调查或重大事件复盘，相关记录的期限就不再按日常策略走。先把涉及人员、时间段的记录做只读保全，记录保全人、保全时间、哈希值和存放位置，再按程序决定后续处理。先删后补，往往补不回来。

保全范围要写清楚，是只保全某个账号，还是某个群、某段时间、某类文件。范围写得太宽，成本和隐私风险都会上升。范围写得太窄，关键记录可能漏掉。比较稳妥的做法是由法务或合规牵头，IT和安全配合，一次把范围定清楚并留审批记录。

图2 审计记录的四层留存期限，法定底线、常规管理、高风险记录和事件保全要分开设置。

谁能查，权限设计比功能清单更重要

审计记录一旦集中存放，最大的风险就从丢失变成越权查看。系统管理员能改配置，安全管理员能看告警，审计管理员能查记录，这三个角色如果由同一个人兼任，审计就失去了独立性。

三类管理员要分权

角色	可以做什么	不应该做什么	关键控制
系统管理员	账号开通、系统配置、备份恢复	不查看消息内容，不修改审计记录	操作留痕、双人复核
安全管理员	安全策略、告警处置、IP限制、水印	不删除审计日志，不单独导出	策略变更审批
审计管理员	查询、导出、审计报告	不管理账号，不修改业务数据	只读账号、导出审批
合规法务	按案件或检查需要调阅	不日常浏览员工聊天	一案一批、范围限定
业务负责人	查看本部门必要记录	不跨部门查询	部门边界、时间边界
外部监管或司法	依法定程序调取	不直接接触系统	法务对接、交接记录

三权分立的目的是让改配置的人看不到内容，看内容的人改不了配置，查审计的人删不掉记录。做不到完全分离的小团队，至少要把账号管理、日志查看和导出审批拆给不同的人，并且保留操作记录。

查询要带审批，导出要能追

审计查询不能只靠一句口头同意。比较稳妥的做法是一事一批，申请里写清楚查谁、查什么时间段、查什么类型的记录、用途是什么、谁批准。查询账号用只读权限，导出文件加密，打开时带水印，导出记录写进审计日志。

查审计这件事本身也要被审计。谁在什么时候查了谁、导出了多少条、有没有下载附件，这些信息要单独留存。否则，审计管理员自己成了新的风险点。

导出后的文件要有编号和回收机制。文件发给谁、什么时候归还、有没有二次转发，最好在审批单上留一行。审计记录的价值在于可追溯，导出文件如果出了审批范围就失控，前面的权限设计也会被绕开。

员工知情和隐私边界要提前写清楚

企业可以为了信息安全和合规管理留存必要的审计记录，但不等于可以无边界查看员工聊天内容。制度里要写清楚哪些记录会留、留多久、什么情况下会查、谁有权批准，并在员工入职或系统上线时告知。

涉及敏感个人信息、自动化决策或对外提供个人信息时，还要按《个人信息保护法》做影响评估，评估报告和处理记录至少保存三年。审计记录里如果包含个人信息，保存期限、访问权限和删除流程都要一并设计，不能只按IT运维的习惯处理。

实际操作中，业务负责人是最容易越界的角色之一。他们出于管理目的想看下属聊天记录，但如果没有具体事件、没有审批、没有范围限定，这种查询很容易变成日常监控。把业务负责人的权限限制在本部门、必要时间段和必要记录类型，能减少很多争议。

图3 审计权限的三层分离与审批路径，系统管理、安全管理、审计管理各自守住边界，查询和导出都要经过审批。

把核对表落到系统里，四类企业即时通讯方案怎么选

制度定了，最后要落到工具上。企业即时通讯的审计能力，不能只看有没有日志页面，还要看记录字段是否完整、留存策略是否可配、权限是否能分、导出是否有审批、备份是否能恢复。下面按四类常见方案说明能力边界，方便对照自己的约束。

喧喧IM，适合把数据留在企业内的组织

喧喧IM是禅道软件（青岛）集团有限公司自主研发的企业级即时通讯与协同平台，核心路线是 私有化部署。系统部署在企业自己的服务器上，数据留在企业内，适合对数据边界、信创适配和研发协同有要求的组织。它的架构和部署相对轻量，聊天、音视频、文件协同等能力并不因此减配。客户端覆盖Windows、macOS、Linux和移动端。

审计相关能力上，喧喧IM提供消息审计、组织隔离、界面水印、IP登录限制和LDAP认证等安全控制，通讯采用全链路加密，服务端文件采用AES 256位加密存储，消息在数据库中加密存储。 通讯安全能力页面把这些控制放在一起说明，适合拿来和企业的审计字段逐项对照。对国企、事业单位、金融和研发团队来说，这些能力能覆盖审计记录里的身份、登录、权限和消息流转几个关键环节。

从审计核对的角度看，私有化部署的好处是记录存放在企业可控的服务器上，备份、留存期限和销毁流程可以由企业自己定。需要提前核对的是版本差异，数据库消息加密存储、界面水印、IP登录限制、LDAP认证等高级安全能力要结合专业版或具体页面确认，不能默认所有版本都一样。它支持 信创适配，适配银河麒麟、统信UOS、Deepin等国产操作系统，以及申威、鲲鹏、飞腾、龙芯、海光、兆芯等国产CPU。对研发团队来说，与禅道集成还能把项目沟通和任务记录放在一个工作流里，减少沟通记录和业务记录对不上的情况。它的边界也很清楚，私有化路线需要企业自己承担服务器、备份和运维责任，追求公有云开箱即用生态的组织要权衡这部分投入。

公有云协同平台，审计能力有，但数据边界要算清楚

飞书、钉钉、企业微信这类公有云协同平台，管理后台通常提供成员管理、登录记录、操作日志和一定的审计能力。对已经深度使用其文档、会议、审批和外部协作生态的组织来说，上手成本低，日常管理也方便。

需要算清楚的是数据边界。公有云模式下，消息和文件存放在厂商的云环境中，企业能拿到多少日志、日志能留多久、能不能导出、导出后能不能作为独立证据，往往和套餐、版本、管理权限有关。涉及敏感数据、信创要求或强监管行业时，要提前确认私有化版本是否存在、能力是否完整、成本是否可接受。

这类方案更适合对数据驻留要求不高、已经围绕其生态建立工作流的组织。如果企业的核心诉求是审计记录必须留在自己机房、权限必须自己分、留存期限必须自己定，就要把私有化部署方案放在同一张核对表上比较，而不是只看功能页面。

信创私有化IM，适合高安全和大组织场景

蓝信、信源密信、360智语、致信、蓝凌KK这类产品，普遍强调私有化部署、信创适配和组织级安全管控，在党政军、国企、金融等场景有较深积累。它们的审计能力通常和组织架构、分级权限、专网部署结合得比较紧，适合管理层级多、数据不能出内网、需要统一管控的大型组织。

这类方案的能力边界也要看清楚。部分产品与OA、门户或特定生态绑定，独立部署能力和接口开放程度要单独确认。高安全场景往往伴随较高的实施成本、较长的部署周期和更复杂的运维要求，审计记录的字段、导出格式、留存策略、权限分离能不能按企业制度配置，需要在测试环境里逐项验证。

如果企业需要的是大型组织的统一管控、专网环境和完整信创栈，这类方案值得进入候选。如果只是希望把日常沟通记录留在企业内、审计权限能分清楚，未必要为用不到的重型能力买单。选型的判断标准还是三个问题，记录是否完整、期限是否可控、权限是否可审计。

开源IM，自由度高，合规责任也在自己

Mattermost、Rocket.Chat、Zulip、Element这类开源即时通讯方案，可以自行部署、自行改造，数据放在自己的服务器上，扩展和集成空间大。对有技术团队、希望掌握源代码和部署主动权的组织来说，这是一条可行路线。

审计能力要靠自己补齐。消息记录、登录日志、管理员操作日志、文件传输记录、审计访问记录，哪些默认有、哪些要装插件、哪些要改代码，都要在选型时确认。留存期限、备份恢复、防篡改、权限分离和导出审批也需要企业自己设计，厂商不会替你承担合规责任。

开源不等于免运维。版本升级、安全补丁、日志存储扩容、灾备演练都要有人负责。小团队如果没有专职运维，开源方案的实际总成本可能高于预期。这类方案适合技术能力强、愿意自建、对数据主权要求高的组织。上线前建议先做一次小范围试点，把登录、消息、文件、权限变更和审计查询五条链路走通，再决定是否全域推广。

一张季度核对流程，五步就能跑起来

审计核对不是年底才做一次的大检查。按季度跑一遍，问题更容易早发现，整改也不会堆在一起。下面这套流程可以直接改成企业自己的核对表。

第一步，定清单和字段

把本文的十类记录改成企业自己的清单，逐条写清楚记录名称、字段、来源系统、责任人、留存期限和访问角色。字段不要贪多，先保证能拼出时间线。清单定完后，让系统管理员确认哪些字段能自动产生，哪些还要手工补。

第二步，抽查三条链路

每季度抽三条链路，一条登录异常，一条文件外发，一条权限变更。从告警或工单出发，反查登录IP、账号、消息、文件、审批和操作人，看能不能在十分钟左右拼出完整时间线。查不到的那一环，就是下一季度要补的字段。

第三步，核对权限和审批

把系统管理员、安全管理员、审计管理员、合规法务和业务负责人的账号列出来，核对是否存在兼任、越权、长期不用的账号。再抽三笔审计查询申请，看审批单、查询范围、导出记录和水印是否齐全。权限核对不要只看账号表，要在系统里实际点一遍。

第四步，验证备份和恢复

备份不等于可恢复。每季度至少做一次恢复演练，从备份里取一个时间段的审计记录，验证能不能打开、字段是否完整、时间戳是否一致。恢复失败的记录要写进整改清单，不能只写一句已备份。

第五步，留一份核对报告

核对结束后留一份简短报告，写清楚查了哪些记录、发现了什么问题、谁负责整改、什么时候复查。 核对报告本身就是审计记录的一部分。下一次核对时可以直接对照上一次的整改项。

参考资料

• 《中华人民共和国网络安全法》第二十一条
• 《中华人民共和国个人信息保护法》第五十六条
• 《信息安全技术 网络安全等级保护基本要求》GB/T 22239-2019
• 《会计档案管理办法》财政部、国家档案局令第79号
• IBM《2025年数据泄露成本报告》

常见问题

只存登录日志，不存消息和文件记录，能过审计吗

很难。登录日志只能说明谁进过系统，说明不了谁发了什么、传了什么、改了谁的权限。审计核对通常要求行为记录能互相印证，登录、消息、文件、权限变更至少要有三类能串起来。只留一类，遇到事件时很容易断链。

聊天记录能不能直接导出来当证据

能不能导出取决于系统能力和权限设计。即使能导出，也要看有没有发送人、接收人、时间戳、消息ID和完整性校验。单张截图证明力有限，完整的导出记录加上操作日志、审批单和哈希校验，才更接近可用的审计证据。

员工离职后，聊天记录还要留吗

离职不等于记录马上删除。涉及未结项目、财务往来、诉讼风险或监管检查的记录，要按原定期限继续留存。账号要及时停用，记录要保留原归属人和时间范围，避免因为账号回收导致记录断链。

小团队没有专职安全员，怎么分工

至少把三个动作拆开，账号管理、日志查看、导出审批。可以由不同岗位兼任，但不要让同一个人既管账号又能改日志还能单独导出。查询和导出都留审批记录，季度抽查一次，基本的分权就能建立起来。

公有云IM的审计日志算企业自己的记录吗

日志由企业申请、导出并保存，可以作为企业审计材料的一部分，但原始数据仍在厂商云环境中。涉及数据主权、监管检查或诉讼保全时，要确认厂商的日志留存期限、导出格式、配合调查的义务和数据删除规则，不能默认平台会永久保存。

审计记录被删了还能恢复吗

能不能恢复取决于备份和日志保护机制。如果管理员既能删日志又能改备份，恢复的可能性很低。更稳妥的做法是审计日志只读、定期备份、备份账号与系统管理员分离，并对删除操作单独告警。