mcpField
A
audit-follow-up-verify

audit-follow-up-verify

github.com/mukul975安全32342 次安装32 周前更新
代码仓库

关于 audit-follow-up-verify

面向审计人员的隐私审计技能，用于核实管理层是否有效处理审计发现。内容涵盖按严重程度安排跟进、独立测试、关闭标准、升级处理和报告。

主要功能

  1. 01按严重程度安排跟进
  2. 02独立验证整改的方法
  3. 03审计发现关闭标准
  4. 04状态流程与升级规则
  5. 05个案及定期报告指引

适用场景

  1. 01按发现严重程度设置跟进日期
  2. 02测试整改是否解决根本原因
  3. 03升级逾期或多次验证失败的发现

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/mukul975/privacy-data-protection-skills --skill audit-follow-up-verify

安装后在 Claude Code 中输入/audit-follow-up-verify确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

assets/
template.md
references/
standards.md
workflows.md
scripts/
process.py

详细介绍

审计跟进与验证

概述

审计跟进是指审计职能监控并验证管理层是否已有效落实针对审计发现的整改措施。IIA Standard 2500 要求首席审计执行官建立并维护一套系统，用于监控已向管理层传达的结果的处理情况。跟进不只是追踪措施是否已完成，还要求独立验证整改是否真正解决了根本原因，并将已识别的风险降低到可接受的水平。

在隐私审计中，有效跟进至关重要，因为未整改的审计发现意味着持续违反法规。未能履行 GDPR Art. 5(2) 问责义务、未修补的同意机制，或持续延误的 DSAR 处理，都会使组织面临监管机构执法、数据主体投诉和声誉受损的风险。

跟进安排

跟进时间由审计发现的严重程度决定：

严重程度首次跟进部分完成时重新测试最多延期次数
严重目标日期后 30 天15 天1 次（需经 CPO 批准）
高目标日期后 60 天30 天2 次（需经 DPO 批准）
中目标日期后 90 天45 天2 次
低目标日期后 180 天90 天3 次
建议下一次计划审计不适用不适用

验证测试方法

重新执行

审计人员独立重复执行控制活动，以验证其是否产生预期结果。用于程序性控制（例如，重新执行 DSAR 回复流程，以验证其是否满足 30 天期限要求）。

检查

审计人员检查整改后生成的记录、文件或系统配置，以验证控制是否按设计运行。用于文档类控制（例如，检查更新后的 DPA 是否符合 Art. 28 要求）。

观察

审计人员实时观察整改后的流程，以验证其是否正常运行。用于运营控制（例如，在桌面演练期间观察更新后的违规通知工作流）。

询问与佐证

审计人员询问流程负责人有关整改后控制的情况，并通过独立证据佐证其陈述。适用于无法实际直接测试的情况。

数据分析

审计人员分析整改后的数据，以验证控制是否产生预期结果。用于可量化的控制（例如，分析整改后 DSAR 的响应时间，以验证是否有所改善）。

关闭标准

只有满足以下所有条件，才能关闭审计发现：

  1. 已完成整改措施：整改负责人已将所有计划措施记录为完成
  2. 已提供证据：整改负责人提供证明措施已完成的书面证据
  3. 已独立验证：验证负责人（审计人员或独立方）通过测试确认措施有效
  4. 已解决根本原因：验证确认根本原因已解决，而非仅消除表面症状
  5. 可持续：修复已融入持续运行的流程（而非一次性手动纠正）
  6. 已记录：工作底稿记录验证程序、已审查的证据和结论

审计发现状态生命周期

New → In Progress → Remediation Complete → Pending Verification → Closed
                                                    ↓
                                              Partial Pass → Re-remediation → Pending Verification
                                                    ↓
                                                  Fail → Reopened → Escalation

未补救发现的升级处理

触发条件升级级别措施
发现逾期 30 天以上（严重）CPO 和 CISO必须在 5 天内召开管理层会议
发现逾期 45 天以上（高）审计委员会提交至下一次审计委员会会议
发现连续两次未通过验证DPO 和 CPO必须开展根因审查并修订计划
发现未关闭 12 个月以上（任何严重级别）董事会审计委员会纳入年度审计意见
重复发现（相同根因，出现 3 次以上）审计委员会调查系统性问题

报告

单项发现跟进报告

每次验证活动后生成：发现项参考编号、验证方法、审查的证据、测试结果、结论（通过／部分通过／未通过）以及建议的后续步骤。

定期跟进摘要

每月向 DPO 和 CPO 提交报告，汇总：按严重级别统计的未关闭发现总数、逾期发现、期间内已关闭的发现、验证通过率、存续时间分析以及升级状态。

对年度审计意见的影响

年末尚未补救的发现将纳入年度审计意见考量。持续存在的严重或高等级发现可能导致评级为“不满意”或“需要改进”。

集成点

  • audit-remediation-program：跟进工作用于验证补救计划所管理的补救措施是否有效
  • audit-evidence-collect：跟进工作需要按照相同的质量标准收集新证据
  • audit-report-writing：跟进结果将纳入定期和年度审计报告
  • records-of-processing：跟进工作可能会验证 ROPA 条目的更正

评论

支持 Markdown