4. 审计计划制定：确定审计范围与目标，组建审计团队，制定审计计划与时间表
审计计划，说白了就是整个安全审计的「作战地图」。
我见过不少团队，上来就拿着工具扫漏洞，结果扫了一堆，老板问「你到底要审什么？」答不上来。这就是典型的计划没做好。今天咱们就聊聊，怎么把审计计划做得扎实、落地。
4.1 确定审计范围与目标
审计范围，就是你要审什么、不审什么。审计目标，就是你希望通过这次审计达到什么效果。
这两件事，必须在动手之前就定死。否则后面全是扯皮。
核心原则：审计范围要「收得紧」，审计目标要「打得准」。
范围太宽，资源不够，什么都审不透；范围太窄，漏掉关键风险，审计白做。
4.1.1 审计范围的三个维度
我个人习惯，从三个维度来框定审计范围：
| 维度 | 说明 | 示例 |
|---|---|---|
| 业务维度 | 涉及哪些业务系统、产品线、业务流程 | 支付系统、用户中心、数据中台 |
| 技术维度 | 涉及哪些技术栈、基础设施、网络区域 | 云环境（AWS/Azure）、K8s集群、数据库 |
| 合规维度 | 需要满足哪些法规、标准、行业要求 | 等保2.0、GDPR、PCI-DSS、ISO 27001 |
举个例子。我之前做过一个金融App的审计，业务维度锁定了「交易系统」和「用户认证模块」，技术维度锁定了「后端API」和「数据库层」，合规维度锁定了「等保三级」和「支付牌照要求」。三个维度一交叉，范围就清晰了。
4.1.2 审计目标的SMART原则
审计目标不能写「提升安全性」这种废话。得具体、可衡量。
- S（Specific）：具体。比如「发现支付接口的越权漏洞」。
- M（Measurable）：可衡量。比如「覆盖所有API端点，至少发现5个高危漏洞」。
- A（Achievable）：可实现。别定一个「一个月内审完整个公司」这种目标。
- R（Relevant）：相关。目标要和业务风险挂钩。
- T（Time-bound）：有时限。比如「两周内完成现场审计」。
我的经验：审计目标最好和业务方、合规方一起过一遍。我曾经吃过亏，自己定了个目标，结果审到一半，法务说「这个合规要求你没覆盖到」——得，返工。
4.2 组建审计团队
审计不是一个人的事。团队搭得好，事半功倍；搭不好，内耗严重。
4.2.1 团队角色与职责
一个标准的审计团队，至少需要这几类角色：
| 角色 | 职责 | 建议人数 |
|---|---|---|
| 审计负责人 | 统筹全局，把控进度，对外沟通 | 1人 |
| 技术审计员 | 执行技术测试、代码审查、配置检查 | 2-3人 |
| 合规审计员 | 检查文档、流程、制度是否合规 | 1-2人 |
| 业务接口人 | 协调被审计方，提供资料和访问权限 | 1人（被审计方出） |
你想想看，如果团队里全是技术大牛，没人懂合规，那审出来的结果可能全是技术漏洞，但合规层面的问题全漏了。反过来也一样。
4.2.2 团队组建的避坑指南
- 避免「利益冲突」：审计员不能审自己开发的系统。我曾经见过一个团队，让开发组长去审自己写的代码——结果你懂的，全是「低风险」。
- 确保「技能互补」：要有懂网络安全的、懂应用安全的、懂合规的。别全是搞渗透的。
- 明确「汇报关系」：审计团队最好直接向CISO或董事会汇报，避免被业务方「压住」。
注意：审计团队必须保持独立性。如果审计员和被审计方有利益关系，审计结果就失去了公信力。这是底线，不能碰。
4.3 制定审计计划与时间表
计划是审计的「骨架」。没有计划，审计就是一团乱麻。
4.3.1 审计计划的五个阶段
我一般把审计计划分成五个阶段：
- 准备阶段：收集资料、了解业务、确定范围。
- 现场阶段：执行测试、访谈、检查。
- 分析阶段：整理发现、分析根因、评估风险。
- 报告阶段：撰写审计报告、提出整改建议。
- 跟踪阶段：跟踪整改落实情况。
每个阶段都要有明确的交付物和时间节点。
4.3.2 时间表的制定方法
时间表不是拍脑袋定的。我习惯用「倒推法」：
- 先定死报告交付日期（比如月底前必须出报告）。
- 然后倒推每个阶段需要多少天。
- 再给每个阶段留出20%的缓冲时间。
举个例子：
| 阶段 | 任务 | 天数 | 交付物 |
|---|---|---|---|
| 准备阶段 | 收集资料、访谈、确定范围 | 3天 | 审计范围确认书 |
| 现场阶段 | 技术测试、合规检查 | 5天 | 测试记录、检查清单 |
| 分析阶段 | 整理发现、风险评估 | 2天 | 发现清单（初稿） |
| 报告阶段 | 撰写报告、评审 | 3天 | 审计报告（终稿） |
| 跟踪阶段 | 整改跟踪 | 持续 | 整改跟踪表 |
你看，总共13天，加上缓冲，我一般会定15天。这样即使中间出点幺蛾子，也不至于延期。
4.3.3 审计计划的核心要素
一份完整的审计计划，至少包含以下内容：
- 审计背景：为什么要做这次审计？
- 审计范围：审什么？不审什么？
- 审计目标：要达到什么效果？
- 审计方法：用什么工具？什么流程？
- 团队分工：谁负责什么？
- 时间表：什么时候做什么？
- 风险与假设：可能遇到什么风险？怎么应对？
我的习惯：审计计划写完后，我会发给所有相关方（业务方、合规方、被审计方）确认。别怕麻烦，这一步能省掉后面80%的扯皮。
4.4 审计计划的知识体系
下面这张图，把审计计划的核心逻辑串起来了。你可以对照着看，确保自己没漏掉什么。
4.5 审计计划中的常见坑
做了这么多年审计，我踩过不少坑。挑几个典型的说说：
坑一：范围「大而全」
我曾经接过一个项目，客户说「把整个公司都审一遍」。结果审了三个月，什么都没审透，报告写出来全是「建议加强安全意识」这种废话。后来我学乖了，每次先问「你最担心什么？」——把范围收窄，反而效果更好。
坑二：时间表「理想化」
你想想看，审计过程中一定会遇到意外：系统宕机、资料不全、关键人员请假。如果时间表排得太满，一点缓冲都没有，那延期就是必然的。我现在的习惯是，每个阶段至少留出20%的缓冲时间。
坑三：团队「偏科」
有一次审计，团队里全是搞渗透测试的，结果合规层面的问题一个都没发现。客户拿到报告后问「我们的GDPR合规呢？」——尴尬了。所以我现在组团队，一定会配一个合规专家。
4.6 小结
审计计划制定，说白了就是三件事：
- 定范围：审什么？不审什么？从业务、技术、合规三个维度框死。
- 搭团队：角色要全，技能要互补，独立性要保证。
- 排计划：分阶段、定时间、留缓冲。
计划做得越细，执行起来越顺。别嫌麻烦，这一步省下来的时间，后面十倍百倍地还给你。