grc-agent-soc2-quality-review

使用 SOC 2 质量协会标准（结构、物质、来源）评估 SOC 2 报告质量。在审查供应商 SOC 2 类型 1/类型 2 报告、对报告可信度进行分类、生成风险备忘录或准备尽职后续问题和证据请求时使用。

# SOC 2 Quality Review

## Project Background & Acknowledgment

This skill was built using the SOC 2 Quality Guild resources at **s2guild.org** as a baseline for quality-focused SOC 2 vendor attestation reviews.

This project was the first GRC agent I wanated to try creating with OpenClaw after setting up across multiple environments, including Raspberry Pi, Intel NUC, several LXC containers, and a cluster setup of 3 Mac Studios using EXO.

Big thanks to the **SOC 2 Quality Guild community** for sharing excellent, practical guidance that helped shape this agent.

## Maintainer

- Author: Simon Tin-Yul Kok
- LinkedIn: https://www.linkedin.com/in/simonkok/
- GitHub: https://github.com/mangopudding/

Review SOC 2 quality before trusting conclusions.

## When NOT to use this skill

Do not use this skill for:
- Legal advice or legal conclusions about regulatory compliance.
- Formal certification decisions (this is a quality review aid, not an issuing authority).
- Deep technical penetration testing or exploit validation.
- Historical incident forensics requiring endpoint/network-level evidence collection.
- Vendor contract drafting as a substitute for legal/procurement review.

## Workflow

1. Confirm review profile (audience, risk posture, strictness).
2. Confirm scope.
3. Score all 11 signals.
4. Run S12+ advanced diligence.
5. Summarize critical gaps.
6. Produce decision + follow-up requests.

## Review profile (required)

Before scoring, capture these user-selectable settings:
- **Primary audience:** Security, Procurement, Customer Trust, or All
- **Risk posture:** Conservative / Balanced / Lenient
- **Data sensitivity baseline:** High / Medium / Low
- **Evidence strictness:** Escalate on Unknown / Conditional acceptance with deadline / Case-by-case
- **Output style:** Executive memo, Full analyst report, or Both

Default to user-provided settings when available. If not provided, ask once before final verdict.

## 1) Confirm scope

Capture:
- Report type: Type 1 or Type 2
- Period covered
- Trust Services Categories in scope
- In-scope system boundary
- Auditor firm + signer
- Qualification status (unqualified/qualified/adverse/disclaimer)

If key sections are missing, stop and request a full report.

## 2) Score all 11 signals

Read `references/rubric.md` and score each signal:
- 2 = strong evidence
- 1 = partial or ambiguous
- 0 = missing, contradictory, or weak

Use a strict standard for Section 4 testing detail and source credibility checks.

## 2b) Run S12+ advanced diligence questions

After S1–S11 scoring, run `references/advanced-diligence.md` and collect answers for the additional diligence set.

Rules:
- Treat S12+ as decision-strengthening checks, not replacements for S1–S11.
- If an answer is unavailable, mark it explicitly as `Unknown` and create a follow-up request.
- Elevate risk when multiple S12+ items remain unknown for high-sensitivity data use cases.

## 3) Flag hard fails

Treat these as high-severity findings by default:
- Missing required auditor report structure (S1)
- Missing/incomplete unsigned management assertion (S2)
- Unlicensed or unverified CPA firm (S8)
- Pervasive testing vagueness on critical controls (S7)

If one or more hard fails exist, recommend compensating evidence even if the opinion is unqualified.

## 4) Produce outputs

Always return three artifacts.

### A) Executive verdict (short)

- Overall confidence: High / Medium / Low (use `references/confidence-rubric.md`)
- Decision: Accept / Accept with conditions / Escalate / Reject
- Top 3 reasons

### B) Scorecard

List S1–S11 with:
- Score (0/1/2)
- Evidence citation (use `references/evidence-citation-format.md`)
- Why it matters
- Follow-up request (if score <2)

### C) Follow-up request pack

Create a vendor-facing request list using `references/vendor-request-templates.md`:
- Direct evidence needed
- Clarifications required
- Deadline recommendation
- Decision gate (what must be resolved)

## Scoring guidance

- Prioritize evidence quality over report polish.
- Penalize boilerplate language that could apply to any company.
- Penalize weak control-to-criteria logic.
- Penalize mismatch between exceptions and opinion severity.
- Separate auditor credibility concerns from control design concerns.

## Decision rubric

Use `references/decision-matrix.md` with the selected risk posture and evidence strictness.

Baseline outcomes:
- **Accept**: no hard fails, most signals strong, no unresolved critical gaps.
- **Accept with conditions**: limited gaps, clear compensating evidence path.
- **Escalate**: mixed evidence, source credibility concerns, or unclear testing sufficiency.
- **Reject**: fundamental structure/source failures or severe unresolved substance failures.

## Required response format

Use this exact section order:
1. Executive verdict
2. Signal-by-signal scorecard (S1–S11)
3. Advanced diligence (S12+) findings
4. Critical risks
5. Vendor follow-up questions
6. Interim compensating controls (what your org should do now)

For structure and quality calibration, mirror `references/output-example.md`.

## Calibration rules

Apply thresholds using selected profile:
- **High sensitivity (PII/PHI/financial, including candidate resume and employer/company data):** require strong minimums on S4/S6/S7/S8 and tighter follow-up deadlines.
- **Medium sensitivity:** allow limited partials with compensating evidence.
- **Low sensitivity:** tolerate minor source/substance weaknesses with conditions.

Apply evidence strictness setting:
- **Escalate on Unknown:** unknowns on critical areas force Escalate.
- **Conditional acceptance with deadline:** permit temporary acceptance only with explicit due dates and owners.
- **Case-by-case:** weigh unknowns by control criticality and data sensitivity.

---

## 中文说明

# SOC 2 质量审查

## 项目背景与致谢

本技能以 **s2guild.org** 上的 SOC 2 Quality Guild 资源为基础构建，作为以质量为核心的 SOC 2 供应商鉴证报告审查的基准。

这是我在多个环境（包括 Raspberry Pi、Intel NUC、若干 LXC 容器，以及使用 EXO 搭建的 3 台 Mac Studio 集群）部署完成后，第一个想尝试用 OpenClaw 创建的 GRC agent。

非常感谢 **SOC 2 Quality Guild 社区** 分享了出色而实用的指导，帮助塑造了这个 agent。

## 维护者

- 作者：Simon Tin-Yul Kok
- LinkedIn: https://www.linkedin.com/in/simonkok/
- GitHub: https://github.com/mangopudding/

在信任结论之前，先审查 SOC 2 质量。

## 何时不应使用本技能

请勿将本技能用于：
- 关于法规合规的法律意见或法律结论。
- 正式认证决策（这是质量审查辅助工具，而非颁发机构）。
- 深度技术渗透测试或漏洞利用验证。
- 需要端点/网络级证据收集的历史事件取证。
- 作为法律/采购审查替代品的供应商合同起草。

## 工作流程

1. 确认审查档案（受众、风险态度、严格程度）。
2. 确认范围。
3. 对全部 11 个信号评分。
4. 运行 S12+ 高级尽职调查。
5. 总结关键缺口。
6. 给出决策 + 后续请求。

## 审查档案（必需）

在评分前，捕获以下用户可选设置：
- **主要受众：** 安全、采购、客户信任，或全部
- **风险态度：** 保守 / 平衡 / 宽松
- **数据敏感度基线：** 高 / 中 / 低
- **证据严格程度：** 遇 Unknown 升级 / 带截止期限的有条件接受 / 逐案处理
- **输出风格：** 高管备忘录、完整分析师报告，或两者皆备

在可用时默认使用用户提供的设置。若未提供，则在最终裁定前询问一次。

## 1）确认范围

捕获：
- 报告类型：Type 1 或 Type 2
- 涵盖期间
- 范围内的信任服务类别
- 范围内的系统边界
- 审计机构 + 签署人
- 保留意见状态（无保留/有保留/否定/拒绝表示意见）

如果关键章节缺失，停止并请求提供完整报告。

## 2）对全部 11 个信号评分

阅读 `references/rubric.md` 并对每个信号评分：
- 2 = 有力证据
- 1 = 部分或含糊
- 0 = 缺失、矛盾或薄弱

对第 4 节的测试细节和来源可信度检查采用严格标准。

## 2b）运行 S12+ 高级尽职调查问题

在 S1–S11 评分之后，运行 `references/advanced-diligence.md` 并收集附加尽职调查集合的答案。

规则：
- 将 S12+ 视为强化决策的检查项，而非 S1–S11 的替代。
- 如果某个答案无法获得，明确将其标记为 `Unknown` 并创建后续请求。
- 当高敏感度数据用例中有多个 S12+ 项保持未知时，提升风险等级。

## 3）标记硬性失败

默认将以下情况视为高严重度发现：
- 缺少必需的审计报告结构（S1）
- 缺失/不完整的未签署管理层声明（S2）
- 未持牌或未经核实的 CPA 机构（S8）
- 关键控制上普遍存在的测试模糊（S7）

如果存在一项或多项硬性失败，即使意见为无保留，也建议补偿性证据。

## 4）产出输出

始终返回三个产物。

### A）高管裁定（简短）

- 整体置信度：高 / 中 / 低（使用 `references/confidence-rubric.md`）
- 决策：接受 / 有条件接受 / 升级 / 拒绝
- 前 3 大原因

### B）评分卡

列出 S1–S11，并包含：
- 分数（0/1/2）
- 证据引用（使用 `references/evidence-citation-format.md`）
- 为何重要
- 后续请求（如果分数 <2）

### C）后续请求包

使用 `references/vendor-request-templates.md` 创建面向供应商的请求清单：
- 所需的直接证据
- 需要的澄清
- 截止期限建议
- 决策门（必须解决哪些问题）

## 评分指导

- 优先考虑证据质量，而非报告的精美程度。
- 惩罚可套用于任何公司的样板化措辞。
- 惩罚薄弱的“控制对应准则”逻辑。
- 惩罚例外情况与意见严重度之间的不匹配。
- 将审计机构可信度问题与控制设计问题区分开。

## 决策评分准则

结合所选的风险态度和证据严格程度，使用 `references/decision-matrix.md`。

基线结果：
- **接受**：无硬性失败，多数信号有力，无未解决的关键缺口。
- **有条件接受**：缺口有限，存在清晰的补偿性证据路径。
- **升级**：证据参差不齐、来源可信度存疑，或测试充分性不明确。
- **拒绝**：根本性的结构/来源失败，或严重的未解决实质性失败。

##