WorkBuddy 实战软件行业 ISO 内审员合规工作流900127001 合并内审摘要软件公司做 ISO 内审最累的不是“写报告”而是跨系统收证据需求/缺陷/代码评审在 Git 与项目管理工具信息安全证据在 IAM、日志、漏洞扫描、备份与事件系统体系文件又在知识库。本文用 WorkBuddy 作为内审办公枢纽搭一套“文审→检查表→证据抽取→不符合项初稿→整改跟踪→管理评审输入”的 PDCA 工作流覆盖ISO 9001:2015 软件研发质量与ISO/IEC 27001:2022 ISMS双体系并给出可复制提示词、样表与合规边界。AI 只做整理和初稿最终判定由内审员负责。文章目录WorkBuddy 实战软件行业 ISO 内审员合规工作流900127001 合并内审[toc]一、软件行业 ISO 内审的痛点与范围1.1 常见痛点1.2 建议内审范围可裁剪二、整体工作流架构三、WorkBuddy 工作区与知识库配置四、内审检查表自动生成900127001 双视角4.1 提示词合并检查表4.2 样例输出节选五、证据抽取与缺项扫描5.1 提示词文审缺项六、不符合项报告与根因初稿6.1 提示词不符合项起草6.2 样例七、整改跟踪与管理评审输入7.1 整改台账提示词八、Python 辅助证据完整性校验脚本九、合规边界与内审员避坑一、软件行业 ISO 内审的痛点与范围1.1 常见痛点证据分散质量记录在项目管理工具安全记录在 IAM/SIEM/漏洞平台体系文件在知识库内审前全靠人工拼。标准叠加ISO 9001 看研发过程、变更、测试、客户验收ISO 27001 看访问控制、风险评估、事件、加密、第三方两套都做重复劳动。条款抽象标准写“按策划进行评审/按风险实施控制”落到软件研发要判断“代码评审覆盖率、变更审批链、生产账号权限、日志留存”是否够。AI 乱编风险直接用通用大模型写不符合项常出现条款号错、证据无来源、严重度乱判。1.2 建议内审范围可裁剪体系软件行业重点过程典型证据ISO 9001:2015 研发质量需求管理、设计评审、编码规范、单元测试、集成/系统测试、缺陷闭环、版本发布、客户验收、配置管理PRD/用户故事、评审记录、测试报告、缺陷库、发布单、配置库权限、客户签收ISO/IEC 27001:2022 ISMS信息安全方针、资产与研发环境、访问控制与特权账号、安全开发、漏洞与补丁、日志与监控、备份、事件响应、第三方/云、风险评估与SoA安全开发规范、IAM 账号清单、代码安全扫描、渗透/漏扫报告、访问评审、备份演练、事件单、供应商评估、风险登记表/SoA共用过程文件控制、记录、内部审核、管理评审、纠正措施、培训能力质量手册/ISMS 方针、培训记录、内审计划、CAPA 台账、管理评审纪要版本说明ISO 9001:2015 现行有效ISO/IEC 27001:2022 为最新版2013 版已废止过渡期至 2025 年 10 月内审工作流应明确采用版本。ISO 27001:2022 条款 9.2 要求内审策划间隔开展覆盖 4–10 章与适用控制措施审核员应保持独立、不审自己负责的过程发现按组织程序分级严重/一般/观察/改进机会并跟踪纠正措施至关闭。条款 10.1 要求采取与不符合影响相适应的纠正措施管理评审条款 9.3应纳入内审结果。ISO 9001:2015 条款 9.2 同样要求独立、留成文信息、作为管理评审输入。二、整体工作流架构体系文件/程序文件/历史内审WorkBuddy 工作区知识库研发证据:需求/PR/测试/发布/配置安全证据:IAM/漏扫/日志/备份/事件/第三方文审:条款覆盖/文件引用/职责分配生成检查表:9001研发27001控制现场/远程取证:抽样核对证据抽取缺项:缺失记录/版本不一致/控制未执行不符合项初稿:事实条款等级根因纠正整改跟踪CSV/Excel:责任人/期限/验证内审报告管理评审输入人工终审/签字:AI不替代判定原则规则引擎做确定检查必交记录、到期日历、版本号LLM 做语义整理把现场笔记转规范不符合项、把多份报告聚成趋势人工做判定与签字。三、WorkBuddy 工作区与知识库配置本地/工作区目录建议iso-audit-workspace/ ├── standards/ # 受控标准摘要按公司采用版本 │ ├── iso9001_2015_notes.md # 4-10章要点、软件研发映射 │ └── iso27001_2022_notes.md # 4-10章适用控制项清单 ├── systemdocs/ # 质量手册/ISMS方针/程序文件 │ ├── qm.md │ ├── isms_policy.md │ ├── sdlc_procedure.md │ ├── access_control_proc.md │ └── incident_proc.md ├── auditplan/ # 年度计划、本次范围、准则、独立声明 │ ├── annual_program.md │ └── audit_scope_2026Q4.md ├── evidence/ # 抽样证据脱敏 │ ├── jira_export/ # 需求、缺陷、变更 │ ├── git_pr/ # 评审记录、合并请求 │ ├── test_reports/ # 单元/集成/系统/验收 │ ├── iam/ # 账号清单、权限评审、离职回收 │ ├── security/ # 漏扫、SAST/DAST、渗透、补丁 │ ├── logs_backup/ # 日志策略、备份演练 │ └── thirdparty/ # 云厂商、外包、供应商评估 ├── prompts/ # 内审专家提示词 ├── output/ # 检查表/不符合项/整改/报告 └── logs/audit_log.jsonl # 留痕文件、模型、版本、审核人操作建议新建 WorkBuddy 任务绑定iso-audit-workspace把本次范围文件加入上下文。上传历史内审报告让模型先提取“高频问题”作为本次重点。所有客户名、生产主机名、真实员工账号先脱敏敏感安全证据只在受控工作区处理。输出统一进output/不把未复核结论直接发受审核部门。四、内审检查表自动生成900127001 双视角4.1 提示词合并检查表# 角色 你是软件企业ISO内审员助手。依据用户上传的体系文件、年度内审计划、范围声明生成检查表。 本次标准ISO 9001:2015 ISO/IEC 27001:2022若公司采用其他版本以用户指定为准。 审核对象研发部/运维安全/项目管理/QA/配置管理可采用合并审核。 # 输入 - standards/ 与 systemdocs/ 为受控准则 - auditplan/ 给出范围、部门、周期、独立审计员 - 若未说明标准版本、范围、软件生命周期模型先提问不臆造 # 输出检查表 按“过程/控制域—标准条款—审核要点—抽样证据—记录要求—常见不符合”列表 1) 需求与变更需求评审、变更审批、追溯对应9001:2015 8.3/8.5.627001:2022 8.25/8.32 2) 设计与代码设计评审、编码规范、代码评审覆盖率、静态扫描27001:2022 8.25 3) 测试与发布单元/集成/系统/验收、缺陷闭环、发布审批、回滚9001:2015 8.6/8.727001:2022 8.32 4) 配置与版本分支策略、标签、受控库、权限9001:2015 7.527001:2022 5.12/8.9 5) 访问与特权IAM、最小权限、特权账号、离职回收、CI/CD密钥27001:2022 5.15/5.18/8.2 6) 安全运维漏扫/补丁、日志、备份、加密、漏洞管理27001:2022 8.8/8.15/8.13 7) 事件与风险事件登记、根因、风险评价、SoA27001:2022 5.24/8.16/8.7 8) 供应商与云外包研发、云资源、数据处理协议9001:2015 8.427001:2022 5.19/8.30 9) 体系通用文件控制、培训、内审、管理评审、CAPA # 约束 - 条款号严格按用户提供的标准版本映射不凭训练数据硬编 - 每条给出可抽样证据文件名/系统/时间段 - 不输出“合规通过”结论只输出“待现场验证项”4.2 样例输出节选过程标准映射审核要点抽样证据常见不符合代码评审9001:2015 8.327001:2022 8.25PR 是否全部评审、评审意见是否闭环、有无强制门禁Git 合并记录、评审意见、SAST 报告、近90天抽样20个PR评审流于形式、未修复安全问题即合并特权账号27001:2022 5.15/5.18/8.2管理员、DBA、CI/CD 服务账号是否纳入季度评审离职是否24h回收IAM 账号清单、权限评审表、离职工单、CI 密钥台账离职人员保留VPN/云控制台、CI 服务账号未定期轮转发布变更9001:2015 8.5.6/8.627001:2022 8.32发布是否有审批、回滚、测试报告、生产影响评估发布单、变更单、测试报告、监控告警、回滚演练紧急发布补审批、未做安全回归ISO 27001:2022 内审资料应保留审计方案、单次计划、检查表、分级发现、纠正措施及关闭证据通常覆盖当前认证周期。五、证据抽取与缺项扫描5.1 提示词文审缺项基于 iso-audit-workspace 做文审不写最终结论。 1. 对照本次范围列出9001:2015与27001:2022条款覆盖矩阵缺条款标注“无对应程序/无证据计划”。 2. 检查体系文件相互引用手册→程序→记录表单编号是否一致发现断号、旧版本、职责未分配列出。 3. 从 evidence/ 抽样 - Jira/PR/测试随机抽取N个需求核对评审、用例、缺陷闭环、发布关联 - IAM/安全特权账号评审、离职回收、漏扫修复SLA、备份恢复演练 - 事件近6个月事件单是否有关因、整改、管理评审引用 4. 输出“缺项清单”文件编号/条款/缺失证据/建议补交材料/严重度初判仅建议 5. 所有结论标注来源路径无证据不说违规只说“未提供可验证证据”。要点AI 适合做“记录断档、版本不一致、抽样不匹配”是否构成不符合由内审员按客观证据定。六、不符合项报告与根因初稿6.1 提示词不符合项起草你根据以下现场事实起草不符合项初稿不替代内审员判定。 输入事实时间、地点、系统、对象、具体记录编号、观察结果。 输出JSON { finding_id:NC-YYYYMMDD-01, fact:客观事实含时间/对象/证据编号, applicable_standard:ISO9001:2015/ISO27001:2022, clause:由用户确认或建议条款需注明依据版本, category:严重/一般/观察/改进机会(建议), impact:对研发质量或信息安全风险的影响, root_cause_options:[流程未定义,执行偏离,工具未配置,职责不清,培训不足], immediate_correction:立即纠正建议, corrective_action:消除根因建议5Why/8D简版, evidence_ref:[路径/编号], auditor_review_required:true } 要求事实可复核不编造条款号严重度仅给建议并注明需内审组长确认。6.2 样例输入事实2026-09-20 审计研发GitLab抽样30个生产相关合并请求其中11个无安全扫描结果即合并SAST策略要求阻断高危问题但实际仅出报告不阻断CI日志见job id CI-8821~8850。模型初稿{finding_id:NC-20260920-01,fact:2026-09-20抽查30个生产相关MR11个合并前无SAST结果CI-8821~8850显示安全阶段仅报告不拦截与《安全开发程序》5.2‘高危必须阻断’不符。,applicable_standard:ISO/IEC 27001:2022ISO 9001:2015,clause:建议27001:2022 8.25安全开发建议9001:2015 8.3设计开发控制,category:建议一般不符合内审组长确认,impact:高危代码可能进入主干增加注入/密钥泄露风险缺陷后期修复成本上升。,root_cause_options:[CI门禁配置未启用阻断,开发考核仅看合并效率,SAST漏报规则未维护],immediate_correction:对11个MR补安全复扫高危未修复暂停相关发布。,corrective_action:5Why为何未阻断→策略仅report→未设enforce→DevOps职责未含安全门禁→修订CI基线30天内完成规则、培训、复核。,evidence_ref:[gitlab:MR列表,ci:8821-8850,sdlc_procedure.md#5.2],auditor_review_required:true}该写法对齐 ISO 27001:2022 发现要求条款/控制、事实证据、影响、纠正、根因、责任人期限最终分类与签字由人定。七、整改跟踪与管理评审输入7.1 整改台账提示词将output中的不符合项汇总为整改跟踪表字段 编号,事实摘要,标准/条款,等级,根本原因,立即纠正,纠正措施,责任人,计划完成,验证方式,状态(待整改/进行中/待验证/关闭),复发风险。 规则 - 状态不自动置“关闭”必须有验证证据路径 - 逾期按计划完成日期标红 - 往年内审同类型问题重复出现标注“系统性”建议管理评审专题 - 输出Markdown表Excel可复制CSVISO 27001:2022 条款 10.1 要求纠正措施与影响相适应管理评审9.3应纳入内审结果。9001:2015 同理。八、Python 辅助证据完整性校验脚本用于内审前自动查“必交材料是否齐全”再交给 WorkBuddy 做语义文审。frompathlibimportPathimportpandasaspd WORKSPACEPath(iso-audit-workspace)EVIDENCEWORKSPACE/evidence# 软件安全内审必交证据清单按本次范围裁剪路径需按实际调整REQUIRED{jira_export/requirements.csv:需求与变更抽样,jira_export/defects.csv:缺陷闭环,git_pr/pr_review.csv:代码评审记录,test_reports/system_test.xlsx:系统测试报告,test_reports/acceptance.xlsx:客户/验收测试,iam/privileged_accounts.csv:特权账号清单,iam/access_review_2026Q3.csv:访问评审,security/sast_scan.xlsx:SAST扫描,security/pentest_2026.pdf:渗透/漏扫,logs_backup/backup_drill.md:备份恢复演练,thirdparty/vendors.xlsx:供应商/云评估,}rows[]forrel,descinREQUIRED.items():pEVIDENCE/rel rows.append({evidence:rel,desc:desc,exists:p.exists(),size_kb:round(p.stat().st_size/1024,1)ifp.exists()else0,})dfpd.DataFrame(rows)missingdf[~df[exists]]print(f必交{len(df)}项缺失{len(missing)}项)print(missing[[evidence,desc]].to_string(indexFalse))df.to_csv(WORKSPACE/output/evidence_readiness.csv,indexFalse)再让 WorkBuddy 读evidence_readiness.csv对“已存在但内容异常”做二级检查例如访问评审未覆盖 CI 服务账号、SAST 报告时间早于抽样 PR、备份演练无恢复验证记录。九、合规边界与内审员避坑独立性开发负责人不审自己团队研发过程安全运维负责人不审自己 IAM/事件可交叉或请外部。ISO 27001:2022 条款 9.2 明确要求内审独立。不靠口头所有发现要有文件/系统/日志/访谈交叉证据AI 不得把“应该如此”当事实。条款不硬编9001/27001 不同版本条款号不同提示词里让用户传“公司采用版本程序文件映射”模型只引用受控文本。严重度人工定AI 可建议严重/一般/观察但最终按影响、系统性、重复发生判定。数据脱敏代码仓库、IAM、生产日志含敏感信息工作区不对外共享第三方证据签保密。AI不签字内审报告、不符合项、管理评审输入由内审员/管理者代表签字WorkBuddy 出初稿、出台账、出趋势。持续更新每次平台规则、标准换版、云架构变化后回流rules/standarddocs避免检查表过期。