合规与审计准备引擎
你的AI合规官。引导初创公司和成长型企业通过SOC 2、ISO 27001、GDPR、HIPAA和PCI DSS —— 从零到审计准备。无需咨询师。
第一阶段 — 合规发现
框架选择矩阵
| 框架 | 谁需要它 | 触发器 | 时间线 | 成本范围 |
|---|---|---|---|---|
| SOC 2类型I | 任何B2B SaaS | 企业前景询问 | 3-6个月 | $20K-$80K |
| SOC 2类型II | 成熟SaaS | 类型I之后，或直接 | 6-12个月 | $30K-$100K |
| ISO 27001 | 面向全球/欧盟的SaaS | 欧盟企业交易 | 6-12个月 | $40K-$120K |
| GDPR | 任何有欧盟用户的 | 如果欧盟数据从第一天开始 | 1-3个月 | $5K-$30K |
| HIPAA | 健康数据处理者 | 在第一个PHI之前 | 3-6个月 | $20K-$60K |
| PCI DSS | 支付处理器 | 在卡数据之前 | 3-9个月 | $15K-$50K |
| SOX | 公共公司 | IPO准备 | 12-18个月 | $100K-$500K |
准备评估简报
company_profile:
name: ""
industry: ""
employee_count: 0
annual_revenue: ""
data_types_handled:
- PII (姓名、电子邮件、地址)
- 金融（支付卡、银行账户）
- 健康（PHI、医疗记录）
- 儿童（COPPA范围）
- 生物特征
- 政府/机密
customer_segments:
- SMB
- 中端市场
- 企业
- 政府
geographic_scope:
- 仅限美国
- 美国+欧盟
- 全球
current_state:
existing_frameworks: []
security_team_size: 0
has_written_policies: false
has_asset_inventory: false
has_risk_assessment: false
has_incident_response: false
has_vendor_management: false
previous_audits: []
known_gaps: []
drivers:
- 客户要求
- 董事会/投资者要求
- 监管义务
- 竞争优势
- 保险要求
target_frameworks: []
target_date: ""
budget_range: ""
优先决策规则
- 客户要求SOC 2吗？ → 从那里开始（B2B SaaS中最常被要求）
- 欧盟客户？ → GDPR是不可谈判的，与SOC 2一起做
- 健康数据？ → 首先HIPAA，然后叠加SOC 2
- 支付数据？ → PCI DSS是法律要求的，立即做
- 多个框架？ → 映射共同控制（SOC 2和ISO 27001之间有40-60%的重叠）
第二阶段 — SOC 2深入研究
信任服务标准（TSC）
SOC 2建立在5个类别上。安全是强制性的。其他人是可选的，但通常预期。
CC1 — 控制环境（基础）
- [ ] 董事会/管理层对安全的监督
- [ ] 具有明确安全角色的组织结构
- [ ] 行为准则/可接受使用政策
- [ ] HR流程（背景调查、入职、离职）
- [ ] 绩效评估包括安全责任
CC2 — 通信与信息
- [ ] 向所有员工提供文档化的安全政策
- [ ] 外部通信渠道用于安全（状态页面，security@）
- [ ] 举报人/匿名报告机制
- [ ] 安全意识培训计划（每年+入职）
- [ ] 维护系统描述文档
CC3 — 风险评估
- [ ] 文档化的年度风险评估流程
- [ ] 维护风险登记册，具有可能性×影响评分
- [ ] 高/关键风险的风险处理计划
- [ ] 管理层批准的风险偏好声明
- [ ] 业务/技术变化触发风险重新评估
CC4 — 监控活动
- [ ] 持续监控控制（不仅仅是年度）
- [ ] 内部审计或自我评估程序
- [ ] 缺陷跟踪和补救
- [ ] 管理层审查监控结果
- [ ] 渗透测试（每年至少一次）
CC5 — 控制活动
- [ ] 逻辑访问控制（RBAC，最小权限）
- [ ] 物理访问控制（办公室、数据中心）
- [ ] 变更管理流程
- [ ] 系统开发生命周期（SDLC）
- [ ] 数据备份和恢复程序
CC6 — 逻辑与物理访问
- [ ] 用户配置和取消配置流程
- [ ] 所有关键系统强制执行MFA
- [ ] 密码政策（12+字符，复杂性，轮换）
- [ ] 访问审查（至少每季度一次）
- [ ] 敏感区域的物理访问日志
- [ ] 加密静态数据（AES-256）和传输中数据（TLS 1.2+）
- [ ] 每季度审查防火墙规则
- [ ] VPN或零信任网络访问
CC7 — 系统运营
- [ ] 监控和警报（正常运行时间，错误，安全事件）
- [ ] 事件检测和响应程序
- [ ] 漏洞管理（每周扫描，修补关键<72小时）
- [ ] 反恶意软件/端点保护
- [ ] 容量规划和性能监控
CC8 — 变更管理
- [ ] 正式的变更请求和批准流程
- [ ] 职责分离（开发≠生产部署）
- [ ] 生产部署前的测试
- [ ] 文档化的回滚程序
- [ ] 紧急变更流程，事后批准
CC9 — 风险缓解（供应商）
- [ ] 上线前进行供应商风险评估
- [ ] 带有关键性评级的供应商库存
- [ ] 年度供应商审查
- [ ] 与子处理器的BAAs/DPA
- [ ] 供应商退市流程
额外标准
可用性（A1）：
- [ ] 定义并监控SLA
- [ ] 每年测试灾难恢复计划
- [ ] 文档化的业务连续性计划
- [ ] 为关键系统定义RTO/RPO
- [ ] 关键基础设施的冗余
保密性（C1）：
- [ ] 数据分类方案（公共、内部、机密、限制）
- [ ] 每个分类级别的处理程序
- [ ] 与员工和供应商的保密协议（NDA）
- [ ] 数据保留和处置政策
- [ ] DLP控制敏感数据
处理完整性（PI1）：
- [ ] 输入验证控制
- [ ] 处理完整性和准确性检查
- [ ] 输出对账程序
- [ ] 错误处理和更正流程
隐私（P1）：
- [ ] 发布隐私通知
- [ ] 数据收集同意机制
- [ ] 数据主体权利程序（访问、删除、可移植性）
- [ ] 新功能隐私影响评估
- [ ] 数据泄露通知程序
SOC 2项目计划（16周冲刺）
| 周 | 阶段 | 关键活动 |
|---|---|---|
| 1-2 | 范围界定 | 定义系统边界，选择TSC，选择审计师 |
| 3-4 | 差距评估 | 根据TSC审计当前状态，记录差距 |
| 5-6 | 政策编写 | 起草所有所需政策（见下面政策列表） |
| 7-8 | 控制实施 | 部署技术控制，配置工具 |
| 9-10 | 流程实施 | 建立运营流程，培训团队 |
| 11-12 | 证据收集 | 收集所有控制的证据，内部测试 |
| 13-14 | 准备评估 | 模拟审计，补救调查结果 |
| 15-16 | 类型I审计 | 审计师现场工作，管理层回应，报告 |
所需政策文件
- 信息安全政策 — 主政策，范围，目标
- 访问控制政策 — 认证，授权，审查
- 变更管理政策 — SDLC，部署，紧急变更
- 事件响应政策 — 检测，响应，通知
- 风险管理政策 — 评估方法，处理，偏好
- 数据分类政策 — 级别，处理，保留，处置
- 可接受使用政策 — 员工责任，禁止行为
- 供应商管理政策 — 评估，监控，退市
- 业务连续性/DR政策 — 计划，测试，RTO/RPO
- HR安全政策 — 背景调查，入职，离职，培训
- 加密政策 — 标准，密钥管理，证书处理
- 物理安全政策 — 办公室访问，访客管理，清洁桌面
- 日志记录与监控政策 — 记录什么，保留，警报
- 密码与认证政策 — 标准，MFA要求
- 备份与恢复政策 — 时间表，测试，保留
政策模板
# [政策名称]
**版本：** 1.0
**所有者：** [姓名，职位]
**批准人：** [姓名，职位]
**生效日期：** [日期]
**下次审查：** [日期+1年]
**分类：** 内部
## 1. 目的
[为什么这个政策存在 — 2-3句话]
## 2. 范围
[这个政策适用于谁和什么]
## 3. 政策声明
[编号，可执行要求 — 不是期望的]
### 3.1 [主题]
- 必须[要求]
- 不得[禁止]
- 应该[建议]
## 4. 角色与责任
| 角色 | 责任 |
|------|---------------|
| [角色] | [他们必须做什么] |
## 5. 例外
[请求例外的流程 — 谁批准，多久，文档化]
## 6. 执行
[不遵守的后果]
## 7. 定义
[政策中使用的技术术语]
## 8. 相关文件
[链接到相关政策、标准、程序]
## 9. 修订历史
| 版本 | 日期 | 作者 | 更改 |
|---------|------|--------|---------|
| 1.0 | [日期] | [作者] | 初始发布 |
第三阶段 — ISO 27001框架
ISMS实施路线图
条款4 — 组织背景
- [ ] 定义ISMS范围和边界
- [ ] 识别利益相关者及其要求
- [ ] 确定内部和外部问题
- [ ] 文档化范围声明
条款5 — 领导力
- [ ] 管理承诺声明
- [ ] 信息安全政策（由CEO/CTO签署）
- [ ] 分配ISMS角色和责任
- [ ] 分配资源（预算、人员、工具）
条款6 — 计划
- [ ] 风险评估方法（ISO 27005或自定义）
- [ ] 执行风险评估
- [ ] 风险处理计划
- [ ] 适用性声明（SoA）— 映射所有93个附件A控制
- [ ] 信息安全目标（可测量的，有时间限制的）
条款7 — 支持
- [ ] 确定所需能力
- [ ] 安全意识计划
- [ ] 内部和外部沟通计划
- [ ] 文档控制流程
条款8 — 运营
- [ ] 执行风险处理计划
- [ ] 从SoA实施控制
- [ ] 管理运营变更
- [ ] 对变更进行风险评估
条款9 — 性能评估
- [ ] 监控和测量程序
- [ ] 内部审计计划和执行
- [ ] 至少每年一次的管理审查
- [ ] 纠正措施跟踪
条款10 — 改进
- [ ] 非一致性和纠正措施流程
- [ ] 持续改进计划
- [ ] 整合经验教训
ISO 27001:2022附件A控制类别
| 类别 | 控制 | 关键领域 |
|---|---|---|
| A.5组织 | 37 | 政策、角色、威胁情报、资产管理、访问、供应商 |
| A.6人员 | 8 | 筛选、T&C、意识、纪律处分、终止 |
| A.7物理 | 14 | 周边、入口、办公室、监控、公用事业、布线 |
| A.8技术 | 34 | 端点、访问权限、认证、恶意软件、漏洞管理、日志记录、加密、SDLC |
SOC 2 ↔ ISO 27001控制映射（节省40-60%的工作量）
| SOC 2 TSC | ISO 27001附件A | 重叠 |
|---|---|---|
| CC1控制环境 | A.5.1-5.6（组织控制） | ~80% |
| CC2通信 | A.5.1，A.6.3（意识） | ~70% |
| CC3风险评估 | 条款6.1，A.5.7（威胁情报） | ~90% |
| CC5控制活动 | A.8（技术） | ~75% |
| CC6访问 | A.5.15-5.18，A.8.1-8.5 | ~85% |
| CC7运营 | A.8.7-8.16（监控） | ~80% |
| CC8变更管理 | A.8.25-8.33（SDLC） | ~70% |
| CC9供应商 | A.5.19-5.23（供应商） | ~85% |
策略： 为一个框架构建，扩展到另一个。首先SOC 2（更快）→ ISO 27001（添加条款4-10管理系统）。
第四阶段 — GDPR合规计划
12个核心要求
-
处理的法律依据 — 为每个数据处理活动记录法律依据
- 同意 | 合同 | 法律义务 | 重要利益 | 公共任务 | 合法利益
- [ ] 数据处理注册（第30条）
- [ ] 适用时进行合法利益评估（LIAs）
-
数据主体权利 — 30天内响应
- [ ] 访问权（SAR）流程
- [ ] 纠正权
- [ ] 删除权（“被遗忘权”）
- [ ] 数据可携带权（机器可读导出）
- [ ] 加工限制权
- [ ] 反对权
- [ ] 自动化决策制定退出
-
隐私设计和默认 — 将隐私构建到产品中
- [ ] 隐私影响评估（PIA/DPIA）模板
- [ ] 每个功能的最小化数据审查
- [ ] 默认隐私设置（选择加入，而不是选择退出）
-
数据保护官员（DPO） — 如果：
- 公共机构，或
- 大规模系统监控，或
- 大规模处理特殊类别数据
-
同意管理
- [ ] 细粒度同意机制（不捆绑）
- [ ] 容易撤回（和给予同意一样容易）
- [ ] 同意记录带有时间戳、版本、范围
- [ ] Cookie同意横幅（ePrivacy）
-
数据处理协议（DPAs）
- [ ] 子处理器的DPA模板
- [ ] 第28条要求检查表
- [ ] 子处理器通知流程
- [ ] 子处理器注册
-
国际传输
- [ ] 传输机制（SCCs、充分性决定、BCRs）
- [ ] 传输影响评估
- [ ] 如有需要的补充措施
-
泄露通知
- [ ] 向监管机构72小时通知
- [ ] “不合理延迟”向受影响个人通知
- [ ] 带有风险评估的泄露登记册
- [ ] 泄露响应团队和升级路径
-
处理活动记录（ROPA）
processing_activity:
name: ""
purpose: ""
lawful_basis: ""
data_categories: []
data_subjects: []
recipients: []
retention_period: ""
transfers_outside_eea: false
transfer_mechanism: ""
technical_measures: []
organizational_measures: []
dpia_required: false
last_reviewed: ""
-
隐私通知 — 必须包括：
- 控制者的身份
- DPO联系（如适用）
- 目的和法律依据
- 数据类别
- 收件人/传输
- 保留期限
- 数据主体权利
- 向监管机构投诉的权利
- 是否提供数据是法定/合同要求
-
数据保留时间表
| 数据类型 | 保留期限 | 法律依据 | 处置方法 |
|---|---|---|---|
| 客户PII | 持续时间+3年 | 合同+合法利益 | 自动删除 |
| 员工记录 | 持续时间+7年 | 法律义务 | 安全粉碎 |
| 财务记录 | 7年 | 法律义务 | 安全粉碎 |
| 服务器日志 | 90天 | 合法利益 | 自动轮换 |
| 营销同意 | 直到撤回 | 同意 | 数据库清除 |
| 支持票 | 解决后2年 | 合法利益 | 自动删除 |
- 培训与意识
- [ ] 所有员工强制性GDPR培训（每年）
- [ ] 角色特定培训（开发人员、支持、市场营销、HR）
- [ ] 带有完成跟踪的培训记录
第五阶段 — HIPAA合规（健康数据）
HIPAA安全规则 — 3个保护类别
行政保护
- [ ] 安全管理流程（风险分析，风险管理）
- [ ] 分配安全责任（HIPAA安全官员）
- [ ] 劳动力安全（授权、清关、终止）
- [ ] 信息访问管理（访问授权、建立、修改）
- [ ] 安全意识培训（提醒、恶意软件、登录监控、密码管理）
- [ ] 安全事件程序（响应、报告）
- [ ] 应急计划（备份、DR、紧急模式、测试）
- [ ] 评估（定期技术/非技术）
- [ ] 与所有业务伙伴的BAAs
物理保护
- [ ] 设施访问控制（应急操作、设施安全计划、访问控制、维护记录）
- [ ] 工作站使用（政策、限制）
- [ ] 工作站安全（物理保护）
- [ ] 设备和媒体控制（处置、重用、问责、数据备份）
技术保护
- [ ] 访问控制（唯一用户ID、紧急访问、自动注销、加密）
- [ ] 审计控制（硬件、软件、程序机制）
- [ ] 完整性控制（ePHI认证、传输安全）
- [ ] 个人或实体认证（验证身份）
- [ ] 传输安全（完整性控制、加密）
HIPAA泄露规则
- ≤500人： 每年批量通知HHS（年底后60天内）
- >500人： 60天内通知HHS+媒体通知
- 所有泄露： 无不合理延迟通知受影响个人（≤60天）
- 处罚： 每次违规$100-$50,000，每年每类别高达$1.5M
第六阶段 — PCI DSS 4.0（支付数据）
12个要求摘要
| # | 要求 | 关键控制 |
|---|---|---|
| 1 | 安装/维护网络安全控制 | 防火墙，网络分割 |
| 2 | 应用安全配置 | 无供应商默认值，CIS基准 |
| 3 | 保护存储的账户数据 | 加密、掩码、密钥管理 |
| 4 | 加密开放网络上的传输 | TLS 1.2+，无SSL/早期TLS |
| 5 | 保护免受恶意软件 | 反恶意软件，定期更新 |
| 6 | 开发安全系统 | SDLC，漏洞管理，WAF |
| 7 | 根据业务需要限制访问 | RBAC，最小权限 |
| 8 | 识别用户并认证 | MFA，密码标准 |
| 9 | 限制物理访问 | 徽章、摄像头、访客日志 |
| 10 | 记录和监控所有访问 | 集中日志记录，审查 |
| 11 | 定期测试安全性 | 漏洞扫描，渗透测试，IDS |
| 12 | 用政策支持安全 | 政策、培训、事件响应 |
范围缩减策略
- 使用令牌化 — 用令牌替换卡数据（Stripe、Braintree为您处理PCI）
- 使用托管支付页面 — 从未触及原始卡数据（SAQ A而不是SAQ D）
- 网络分割 — 隔离持卡人数据环境
- 云提供商合规性 — 利用AWS/GCP/Azure PCI认证
SAQ决策：
- 完全外包（Stripe Checkout）→ SAQ A（22个控制，最简单）
- API基础（Stripe Elements）→ SAQ A-EP（~140个控制）
- 您存储/处理卡数据 → SAQ D（300+个控制，避免这个）
第七阶段 — 合规工具栈
按类别的基本工具
| 类别 | 预算选项 | 中档 | 企业 |
|---|---|---|---|
| GRC平台 | Notion/Sheets | Vanta, Drata | ServiceNow, OneTrust |
| 政策管理 | Google文档+版本控制 | Vanta政策 | Hyperproof |
| 漏洞扫描 | OWASP ZAP, Trivy | Qualys, Tenable | Rapid7 |
| SIEM/日志记录 | ELK堆栈，Wazuh | Datadog, Sumo Logic | Splunk |
| 端点保护 | CrowdStrike Falcon Go | SentinelOne | CrowdStrike企业 |
| 身份/访问 | Google工作区+Okta | JumpCloud | Azure AD P2 |
| 培训 | KnowBe4免费 | KnowBe4 | Proofpoint |
| 渗透测试 | HackerOne社区 | Cobalt | Bishop Fox |
| 备份 | 原生云备份 | Veeam | Commvault |
以自动化为先的合规
要自动化的内容（节省70%+的审计准备）：
- 证据收集（配置截图→API拉取）
- 访问审查（季度手动→持续监控）
- 漏洞扫描（手动→计划+自动工单）
- 政策确认（电子邮件→入职工作流程）
- 供应商评估（电子表格→带有评分的输入表单）
- 培训跟踪（手动→LMS带有自动提醒）
合规即代码模式
# 基础设施合规
- 带有Sentinel政策的Terraform（强制加密、标记）
- OPA/Rego用于Kubernetes准入控制
- AWS Config规则/Azure Policy用于云合规
- GitHub分支保护规则作为变更管理证据
# 应用合规
- CI中的自动依赖扫描（Snyk, Dependabot）
- PR管道中的SAST（Semgrep, CodeQL）
- 容器扫描（Trivy, Grype）
- 许可证合规（FOSSA, Licensee）
第八阶段 — 审计准备
90天审计准备清单
90-60天：基础
- [ ] 与审计师确认审计范围
- [ ] 完成系统描述文档
- [ ] 验证所有政策是否最新（在过去12个月内审查过）
- [ ] 确认所有员工已完成安全培训
- [ ] 运行漏洞扫描并补救关键/高发现
- [ ] 安排渗透测试（审计前需要结果）
60-30天：证据收集
- [ ] 为每个控制收集证据（按TSC/条款组织）
- [ ] 访问审查文件（审查的截图，行动项目）
- [ ] 变更管理证据（显示批准流程的票样）
- [ ] 事件响应测试证据（桌面演习会议记录）
- [ ] DR测试证据（恢复测试结果，RTO实现）
- [ ] 供应商审查证据（评估记录，DPAs）
- [ ] 风险评估和处理计划（当前年份）
- [ ] 董事会/管理层讨论安全的会议记录
30-0天：最后准备
- [ ] 内部模拟审计 — 走过每个控制
- [ ] 补救任何模拟审计调查结果
- [ ] 向团队介绍审计师面试（预期什么，谁回答什么）
- [ ] 准备管理层断言信
- [ ] 设置审计师访问（对证据库的只读访问）
- [ ] 确认所有监控/警报功能正常
- [ ] 验证已完成所有离职员工的退市
证据组织
/compliance-evidence/
/SOC2-2026/
/CC1-control-environment/
org-chart.pdf
code-of-conduct-signed.pdf
background-check-process.pdf
/CC2-communication/
security-training-completion.csv
security-policy-acknowledgments.pdf
/CC3-risk-assessment/
risk-assessment-2026.xlsx
risk-treatment-plan.pdf
/CC6-access/
access-review-Q1.pdf
access-review-Q2.pdf
mfa-enforcement-screenshot.png
offboarding-checklist-samples/
/CC7-operations/
vulnerability-scan-reports/
pentest-report-2026.pdf
incident-log-2026.csv
/CC8-change-management/
sample-change-tickets/
deployment-pipeline-config.png
/CC9-vendors/
vendor-inventory.xlsx
vendor-assessments/
dpas-and-baas/
审计师面试准备
常见问题及最佳回答者：
| 问题 | 最佳回答者 | 关键点 |
|---|---|---|
| “向我展示你的风险评估流程” | CISO/安全负责人 | 方法论、频率、处理 |
| “描述你如何管理对生产的访问” | 工程负责人 | RBAC、批准流程、审查 |
| “描述你的变更管理流程” | 工程负责人 | PR审查、测试、部署 |
| “你如何处理安全事件？” | 安全负责人 | 检测、响应、沟通 |
| “你如何评估供应商？” | 安全/采购 | 评估、监控、合同 |
| “描述你的备份和恢复流程” | 基础设施负责人 | 时间表、测试、RTO/RPO |
| “你如何跟踪和补救漏洞？” | 安全负责人 | 扫描、SLA、修补 |
| “向我展示员工入职/离职流程” | HR + IT | 检查表、时间、验证 |
第九阶段 — 持续合规
每月合规仪表板
compliance_dashboard:
month: ""
control_health:
total_controls: 0
controls_passing: 0
controls_failing: 0
controls_not_tested: 0
health_percentage: 0
action_items:
open: 0
overdue: 0
closed_this_month: 0
key_metrics:
mean_time_to_patch_critical: ""
access_reviews_completed: "X/X"
security_training_completion: ""
incidents_this_month: 0
vendor_reviews_due: 0
policies_due_for_review: 0
risk_register:
high_risks: 0
risks_without_treatment: 0
new_risks_identified: 0
upcoming:
next_pen_test: ""
next_dr_test: ""
next_audit: ""
next_access_review: ""
合规日历
| 频率 | 活动 |
|---|---|
| 每周 | 审查安全警报，修补关键漏洞 |
| 每月 | 控制测试样本，指标仪表板，政策例外审查 |
| 季度 | 访问审查，供应商风险检查，风险登记册更新，桌面演习 |
| 半年 | 漏洞扫描（外部），BCP/DR测试，安全培训更新 |
| 每年 | 全面风险评估，渗透测试，政策审查周期，SOC 2/ISO审计，安全意识培训，管理审查 |
合规债务跟踪器
compliance_debt:
- id: "CD-001"
framework: "SOC 2"
control: "CC6.1"
finding: "MFA未在暂存环境上执行"
severity: "High"
identified: "2026-01-15"
owner: ""
target_remediation: "2026-02-15"
status: "In Progress"
compensating_control: "VPN + IP allowlisting"
控制失败时
基于严重性的响应：
| 严重性 | 响应时间 | 行动 |
|---|---|---|
| 关键 | 24小时 | 立即补救，通知管理层，考虑是否发生泄露 |
| 高 | 7天 | 补救计划，如有需要采取补偿控制，CISO风险接受 |
| 中 | 30天 | 添加到冲刺，合规债务跟踪 |
| 低 | 90天 | 与下一次审查周期一起批处理 |
第十阶段 — 多框架管理
共同控制框架（CCF）
一次性构建控制，映射到多个框架：
control:
id: "CCF-AC-001"
title: "多因素认证"
description: "对所有生产系统和敏感数据的访问都需要MFA"
owner: "安全团队"
framework_mapping:
soc2: ["CC6.1", "CC6.6"]
iso27001: ["A.8.5"]
gdpr: ["Article 32"]
hipaa: ["§164.312(d)"]
pci_dss: ["Req 8.4"]
evidence:
- type: "配置截图"
source: "Okta MFA政策"
frequency: "季度"
- type: "访问审查"
source: "Okta用户报告"
frequency: "季度"
test_procedure: "验证MFA政策是否执行，测试非MFA登录尝试"
last_tested: ""
result: ""
next_test: ""
框架扩展策略
第一年： SOC 2类型I → 建立基线 第一年-第二年： SOC 2类型II → 证明持续运营 第二年： + GDPR → 覆盖欧盟扩张 第二年-第三年： + ISO 27001 → 国际信誉 如有需要： + HIPAA/PCI DSS → 行业特定
审计疲劳预防
- 单一证据库 — 收集一次，映射到所有框架
- 持续监控 — 证据自动收集，在审计时不慌张
- 控制所有者责任 — 每个控制都有一个所有者，不是"安全团队"
- 合规冲刺 — 2周冲刺专注于合规工作，不在审计前匆忙
- 审计师关系 — 如果可能的话，同一个公司处理多个框架（他们了解你的环境）
第十一阶段 — 评分与质量
合规准备评分（0-100）
| 维度 | 权重 | 评分0-10 |
|---|---|---|
| 政策覆盖 — 所有所需政策存在、审查、批准 | 15% | |
| 技术控制 — 安全工具部署并配置 | 20% | |
| 流程成熟度 — 运营流程一致遵循 | 20% | |
| 证据质量 — 完整、组织、最近的证据 | 15% | |
| 培训与意识 — 所有员工培训，记录维护 | 10% | |
| 供应商管理 — 所有关键供应商评估和合同 | 10% | |
| 风险管理 — 当前评估、处理计划、监控 | 10% |
评分指南：
- 0-2: 未开始/主要差距
- 3-4: 正在进行/重大差距
- 5-6: 部分实施/一些差距
- 7-8: 实施/需要小改进
- 9-10: 成熟/审计准备
解释：
- < 40: 不准备好 — 需要大量工作（3-6个月）
- 40-60: 即将到来 — 专注于差距（1-3个月）
- 60-80: 几乎准备好 — 润色和证据收集（2-6周）
- 80+: 审计准备 — 安排审计
边缘案例与特殊情况
零合规初创公司
- 从安全基础（MFA、加密、访问控制、备份）开始，在任何框架之前
- 从第一天起使用GRC平台（Vanta/Drata成本$10-15K/yr但节省100+小时）
- 不要等待完美 — "文档化和改进"比"未文档化和完美"更好
- 预算$20-40K用于第一个SOC 2类型I（审计师+工具+时间）
多云/混合基础设施
- 为每个提供商映射共享责任模型
- 确保跨环境一致的控制
- 考虑云特定的合规工具（AWS Audit Manager, Azure Compliance Manager）
- 网络分割尤为重要
收购公司整合
- 在关闭后30天内进行合规差距评估
- 确定最高风险差距（访问控制，数据处理）
- 90天整合计划将其带到基线
- 不要假设他们的合规姿态符合声明
国际（多管辖区）
- 映射所有运营或存储数据的司法管辖区
- GDPR适用于如果你有欧盟用户 — 不仅仅是欧盟办公室
- 数据居住要求（俄罗斯、中国、印度、巴西）
- 考虑当地DPA注册
受监管行业（FinTech, HealthTech）
- 在SOC 2/ISO之上叠加行业法规
- FinTech: SOC 2 + PCI DSS + 可能的银行法规（州MTLs, FinCEN）
- HealthTech: SOC 2 + HIPAA + 可能的FDA（SaMD）
- EdTech: SOC 2 + FERPA + COPPA（如果13岁以下）
自然语言命令
| 命令 | 它的作用 |
|---|---|
| “评估我们的合规准备情况” | 运行准备评估，评分，识别差距 |
| “创建SOC 2项目计划” | 生成16周实施时间表 |
| “编写[政策名称]政策” | 从模板生成政策与您的上下文 |
| “映射跨框架控制” | 构建共同控制框架映射 |
| “准备审计” | 生成90天审计准备清单与证据需求 |
| “审查我们的GDPR合规性” | 根据当前状态检查所有12个GDPR要求 |
| “评分我们的合规姿态” | 运行7维评分量表 |
| “生成证据清单” | 列出特定框架所需的所有证据 |
| “构建供应商评估” | 为特定供应商创建供应商风险评估 |
| “计划框架扩展” | 根据业务需求推荐下一个框架 |
| “跟踪合规债务” | 审查和优先考虑开放的合规项目 |
| “运行每月合规审查” | 更新仪表板，检查截止日期，识别行动 |