Compliance Automation

Generate compliance policies, automate evidence collection, assess audit readiness, and respond to auditor control matrices — all from one skill.

Important Disclaimer

GENERATED DRAFTS ONLY – All policies and responses require human review before use. These are starting points, not audit-ready documents.

When to Use This Skill

Use this skill when the user:

• Needs to create compliance policies (SOC 2, ISO 27001, or both)
• Mentions SOC 2 certification, ISO 27001 certification, or audit preparation
• Asks for security policy templates or compliance documentation
• Wants to set up automated evidence collection or GitHub Actions workflows
• Pastes an auditor’s control matrix or security questionnaire
• Asks to respond to a vendor security questionnaire (SIG, CAIQ, or custom)
• Wants to assess audit readiness, run a gap analysis, or understand compliance posture
• Is new to SOC 2 and wants to understand the basics before starting

Routing

Detect what the user needs and load the appropriate workflow:

Route A: External Document Response

Check FIRST — before starting the normal policy workflow, check if the user is providing an external compliance document. Route here if ANY of these signals are present:

• Keywords: “control matrix”, “test plan”, “security questionnaire”, “SIG”, “CAIQ”, “vendor questionnaire”, “RFP”, “auditor requirements”, “respond to this”, “map this to our compliance”
• Structural signals: tabular or list format with 10+ items, numbered test IDs (e.g., “1.1”, “TST-003”), control codes (e.g., “CC6.1”, “A.5.15”), compliance-oriented descriptions
• Explicit request: “here’s what our auditor needs”, “can you generate responses to this”

If detected → Load references/workflow-responses.md and follow its steps.

Route B: Evidence Collection

Route here if the user specifically asks about evidence collection without needing policies first:

• Keywords: “set up evidence collection”, “automate compliance monitoring”, “GitHub Actions for compliance”, “evidence scripts”, “configure SaaS tools for compliance”

If detected → Load references/workflow-evidence.md and follow its steps.

Route D: Audit Readiness Assessment

Route here if the user wants to understand their current compliance posture before generating policies:

• Keywords: “how ready are we”, “readiness assessment”, “gap analysis”, “compliance gaps”, “assess our compliance”, “compliance posture”, “what’s missing”, “pre-audit check”, “compliance scan”, “where do we stand”, “security assessment”, “audit readiness”
• Structural signals: User asks an evaluative question about their current state rather than requesting a specific artifact (policy, script, response)
• Explicit request: “scan my codebase for compliance”, “show me our gaps”, “run an assessment”

If detected → Load references/workflow-assessment.md and follow its steps.

Route E: Orientation & Getting Started

Route here if the user is new to compliance or asking foundational questions:

• Keywords: “what is SOC 2”, “where do I start”, “new to compliance”, “SOC 2 101”, “explain SOC 2”, “how does SOC 2 work”, “getting started”, “first time”, “help me understand”, “what do I need for SOC 2”
• Structural signals: User asks broad/foundational questions rather than requesting a specific artifact (policy, script, response) or action
• Explicit request: “walk me through SOC 2”, “I don’t know where to begin”

If detected → Load references/workflow-orientation.md and follow its steps.

Route F: Evidence Inventory

Route here if the user wants to see what evidence has been collected or build an inventory from scan results:

• Keywords: “inventory”, “what did we find”, “evidence summary”, “aggregate evidence”, “show collected evidence”, “list all evidence”, “what do we have”, “evidence index”, “asset inventory”, “identity inventory”
• Structural signals: User asks about collected scan results rather than requesting new scanning or policies
• Prerequisite: .compliance/evidence/ must contain at least one .json file

If detected → Load references/workflow-inventory.md and follow its steps.

Route C: Policy Generation (default)

If none of Routes A, B, D, E, or F match, this is the default. The user wants to generate policies:

• Keywords: “generate policies”, “SOC 2”, “ISO 27001”, “compliance policies”, “security policies”, “audit preparation”

First-time user nudge: If Route C triggers AND .compliance/config.json does not exist, present this choice before starting the policy workflow:

Before generating policies, I’d recommend starting with a readiness assessment to understand where you stand. This takes about 5 minutes and scans your codebase for existing controls.

Would you like to:

1. Run a readiness assessment first (recommended)
2. Jump straight to policy generation
3. Get a quick orientation on how SOC 2 works

• If option 1 → Load references/workflow-assessment.md and follow its steps
• If option 2 → Load references/workflow-policies.md and follow its steps
• If option 3 → Load references/workflow-orientation.md and follow its steps

If .compliance/config.json already exists, skip the nudge and load references/workflow-policies.md directly.

After policies are generated, the user may continue to evidence collection (Route B) or receive an external document (Route A). The workflows interconnect through the .compliance/ directory.

Session State

CRITICAL: All session state MUST be written to the .compliance/ folder. Do NOT rely on in-memory context, agent-internal files, or conversation history.

CRITICAL: This is a conversational flow. Ask ONE question, wait for answer, then ask the next. NEVER list multiple questions in a single message.

.compliance/
├── config.json               # Company context — created during onboarding, read by all workflows
├── status.md                 # Progress tracking — updated by all workflows
├── assessment.md             # Readiness assessment report (generated by assessment workflow)
├── secrets.env               # API tokens (must be in .gitignore)
├── tasks/                    # Filesystem task queue for tracking work items
│   └── {task-id}.md          # See references/task-system.md
├── answers/{policy-id}.md    # Per-policy Q&A answers (editable before generation)
├── policies/{policy-id}.md   # Generated policy documents
├── scripts/                  # Evidence collection scripts + configs
├── evidence/                 # Collected evidence
│   ├── code/                 # Codebase scan results
│   ├── cloud/                # Cloud infrastructure results
│   ├── saas/                 # SaaS tool results
│   └── manual/{policy-id}/   # User-collected evidence
├── inventories/              # Aggregated inventories (generated by inventory workflow)
│   ├── identities.md          # Users, service accounts, roles
│   ├── assets.md              # Compute, deployments, DNS
│   ├── data-stores.md         # Databases, storage, key vaults
│   ├── network.md             # Firewalls, WAF, SSL policies
│   ├── integrations.md        # SaaS tools, monitoring, alerting
│   ├── summary.md             # Executive summary with counts
│   └── inventory.json         # Machine-readable combined inventory
└── responses/                # Auditor response mappings
    ├── {name}-raw.md          # Parsed input document
    ├── {name}.md              # Draft response document
    └── {name}-filled.xlsx     # Filled spreadsheet

Output Format

File Header

Every policy file MUST start with:

<!--
GENERATED DRAFT ONLY - USER REVIEW REQUIRED

- Not audit-ready
- Not legally binding
- Not a substitute for professional audits

Review, edit, and own all content.
-->

File Footer

Every policy MUST end with:

---
**Policy Safety Note:** This draft deliberately under-claims to reduce risk.
Auditors may require stronger language + evidence of operation.

---
Generated with [Compliance Automation](https://github.com/screenata/compliance-automation)

Evidence Types

Format evidence requirements as a table with a Status checkbox column. Include sufficiency criteria in the Description:

## Proof Required Later

| Status | Evidence | Type | Description |
|--------|----------|------|-------------|
| [ ] | MFA enforcement settings | Screenshot | IdP admin console showing MFA required. Must show: policy enabled, scope = all users, no exceptions |
| [ ] | Access provisioning ticket | Workflow | Recording of approval flow. Must show: request, manager approval, IT provisioning, access granted |

Reference Index

Workflow Details

Codebase Scanning

Shared guidelines: shared.md. SaaS detection: saas-detection.md.

Cloud Scanning

Shared cloud guidelines: cloud-shared.md

SaaS Integrations

Shared SaaS guidelines: shared.md

Other References

Important Notes

• NEVER batch questions — ask ONE question per message, wait for answer
• Generate ONE policy at a time
• Use the user’s actual answers to customize procedures
• Tailor complexity to company size (smaller = simpler controls)
• For healthcare/fintech, include relevant compliance alignment notes
• Always include placeholders like [timeframe], [owner name] for values the user should fill in
• When scanning is enabled, extract concrete values and use them instead of placeholders. Reference with file:line
• When a concrete value is found, bold it in both the evidence table and the policy text
• Cloud scanning safety: Only run read-only CLI commands (describe, list, get, show). NEVER run commands that modify infrastructure. Never include secrets, private keys, or credential values in evidence output
• SaaS scanning safety: Only call read-only API endpoints (GET requests). Never call endpoints that create, update, or delete data. Redact PII — use counts and percentages instead of user lists. Never include API tokens in evidence output
• When evidence exists from multiple sources (code, cloud, SaaS), compare overlapping controls and flag drift/discrepancies with a cross-source comparison table