compliance_checklist_builder v1.0.0

name: "compliance_checklist_builder" description: "Build compliance checklists and evidence plans for audits and policy rollouts. Turns a framework scope (SOC 2, ISO 27001, PCI DSS, HIPAA, NIST CSF) into control checklists with owners, an evidence map, a 0-5 readiness score, and a prioritized remediation plan. Triggers on requests like 'audit readiness checklist', 'compliance gap assessment', 'evidence plan for SOC 2', or 'score our controls for an audit'."

Compliance Checklist Builder

Purpose

Produce audit-ready compliance checklists that survive contact with an actual auditor: every requirement mapped to a control, every control to an owner, every control to concrete evidence, scored for readiness with gaps prioritized into a remediation plan. Covers SOC 2 Type II, ISO 27001, PCI DSS, HIPAA, NIST CSF 2.0, and custom policy rollouts.

Workflow

1. Scope the audit. Ask (or infer from the request): which framework and which version, which time window, in-scope systems/data, and which requirements the org wants to claim or is deferring. Record the framework version in the output; requirement IDs drift between versions.
2. Build the checklist. One row per framework requirement, never per existing control. Columns: requirement ID + name, domain, control statement (what the org must do), owner (one accountable name), current state 0-5, target state 0-5, evidence required (concrete artifacts, not "policy exists"), evidence strength, review cadence. Use bin/checklist.py build with a YAML control list; starter format in assets/checklist-starter.yaml. See references/evidence-map-template.md for the full column set.
3. Score readiness. Rate each control 0-5 against the rubric in references/readiness-scoring.md, score evidence strength (direct / indirect / missing / stale), then compute section and overall readiness. Anything under level 3 is a gap; anything with missing or stale evidence is a gap regardless of score.
4. Write the evidence plan. For every control, list the exact artifacts the auditor will ask for and where they live today (repo path, ticket queue, SIEM export, signed PDF). Missing evidence becomes a remediation item with an artifact named, not a vague "document this".
5. Prioritize gaps. Rank by gap size times audit weight: (target - current) against the control's risk (likelihood x impact, 1-25). Tag effort: quick win (<1 week), moderate (1-4 weeks), significant (1-3 months), major (3+ months). The top of the list is what the org does first.
6. Ship the report. Executive summary with the overall score and rating, coverage by domain, top gaps, maturity by domain, remediation roadmap with owners and dates, and the full checklist plus evidence catalog as the appendix.

Output Contract

• A Markdown report: overall readiness score (0-100%) plus rating (Audit Ready / Near Ready / Significant Gaps / Not Ready), domain coverage, top-10 gap list, remediation roadmap, full checklist appendix, evidence catalog appendix.
• A machine-readable YAML/CSV of the checklist so the org can rerun scoring after remediation.
• No invented requirement IDs: framework requirement IDs are presented as illustrative and the report states the framework version and tells the user to confirm numbering with their auditor.

Operating Rules

• Build requirement-outward: every framework requirement gets a row even when the mapped-control column says "gap, no control yet".
• One owner per control. Shared ownership is how controls die; if two names seem right, pick the accountable one and list the other as contributor.
• Evidence wins the audit. A level-4 control with missing evidence scores as a gap. Concrete artifacts only: named documents with versions, dated exports, signed attestations. "We do this" is not evidence.
• Automate collection early. Point the user at evidence that can be pulled programmatically (IAM exports, audit logs, config scans, TLS scans) rather than screenshotted quarterly.
• Cross-framework reuse: one control can satisfy many frameworks (requirement mapping in references/evidence-map-template.md). Implement once, reference everywhere, but verify each framework's exact requirement text.
• Run a tabletop walkthrough before the real audit: pretend to be the auditor, ask for the evidence, time the retrieval. Same-day retrieval is the bar.
• When a factual claim about a framework (requirement text, version, numbering) cannot be verified against the source, flag it as unverified in the report instead of presenting it confidently.