Use this when a client needs to understand their compliance posture against SOC 2, ISO 27001, GDPR, HIPAA, or other frameworks -- whether preparing for an audit, assessing current gaps, or building a compliance program from scratch.

Related skills: Use /threat-model to validate that controls address identified threats. Use /decision-brief when compliance investments need stakeholder approval. Use /vendor-security-assessment for vendor compliance evaluation. Use /security-review for feature-level compliance implications.

Process

Step 1: Gather inputs

Collect from the user:

• Target framework(s) -- SOC 2 Type I/II, ISO 27001, GDPR, HIPAA, PCI-DSS, NIST CSF, FedRAMP, or combinations
• Current security controls -- policies, procedures, technical controls already in place
• Previous audit findings -- past reports, open remediation items, auditor observations
• Target audit date -- when is the audit or assessment?
• Team responsible -- who owns compliance day-to-day?
• Budget constraints -- are there limits on tooling, staffing, or consulting spend?
• Scope boundaries -- which systems, data types, and business processes are in scope?

Step 2: Select framework domains

Break the target framework into auditable domains. Examples:

SOC 2 Trust Service Criteria:

• CC1: Control Environment
• CC2: Communication and Information
• CC3: Risk Assessment
• CC4: Monitoring Activities
• CC5: Control Activities
• CC6: Logical and Physical Access Controls
• CC7: System Operations
• CC8: Change Management
• CC9: Risk Mitigation
• Plus: Availability, Processing Integrity, Confidentiality, Privacy (if in scope)

ISO 27001 Annex A (2022):

• A.5: Organizational Controls
• A.6: People Controls
• A.7: Physical Controls
• A.8: Technological Controls

For each domain, list the specific control requirements that apply given the organization's scope.

Step 3: Map existing controls

For each domain requirement, document the current state:

| Req ID | Requirement Description | Current Control | Control Type | Maturity (1-5) | Evidence Available | Gap Status |
|---|---|---|---|---|---|---|
| {{req_id}} | {{requirement}} | {{current_control_or_none}} | Preventive / Detective / Corrective | {{1-5}} | {{yes/partial/no}} | Fully Met / Partially Met / Not Met |

Maturity scale:

1. Ad hoc -- done inconsistently, no documentation
2. Repeatable -- done consistently but not documented
3. Defined -- documented policy and procedure exists
4. Managed -- documented, measured, and reviewed periodically
5. Optimized -- continuously improved based on metrics

The critical distinction: "we do this informally" vs. "we have documented evidence." Auditors care about evidence. An undocumented control is, for audit purposes, a gap.

Step 4: Gap analysis

For each gap (Partially Met or Not Met), produce a remediation plan:

| Req ID | Gap Description | Remediation Action | Effort (S/M/L) | Suggested Control | Evidence Needed | Owner |
|---|---|---|---|---|---|---|
| {{req_id}} | {{what_is_missing}} | {{specific_action}} | {{effort}} | {{control_description}} | {{what_auditor_wants}} | {{team_or_person}} |

Distinguish between:

• Documentation gaps -- the control exists but isn't written down (often quick wins)
• Process gaps -- the procedure doesn't exist and needs to be built
• Technical gaps -- tooling or infrastructure changes required
• Evidence gaps -- the control runs but doesn't produce audit-ready evidence

Step 5: Generate compliance readiness scorecard

Produce a summary view:

## Readiness Scorecard -- {{framework}} -- {{date}}

| Domain | Total Requirements | Fully Met | Partially Met | Not Met | Coverage % |
|---|---|---|---|---|---|
| {{domain}} | {{total}} | {{met}} | {{partial}} | {{not_met}} | {{percentage}} |

**Overall readiness:** {{percentage}}%
**Critical gaps blocking certification/attestation:** {{count}}
**Estimated remediation timeline:** {{weeks/months}}

Flag any single gap that would block certification on its own (e.g., no encryption at rest for a SOC 2 confidentiality criterion).

Step 6: Produce audit preparation checklist

Working backward from the target audit date:

## Audit Preparation Timeline

### {{audit_date - 12 weeks}}: Evidence gathering begins
- [ ] Assign evidence owners per domain
- [ ] Create shared evidence repository with access controls
- [ ] Begin collecting {{specific_evidence_types}}

### {{audit_date - 8 weeks}}: Gap remediation deadline
- [ ] All critical gaps remediated
- [ ] Documentation reviewed and updated
- [ ] Control testing completed internally

### {{audit_date - 4 weeks}}: Dry run
- [ ] Internal audit simulation
- [ ] Interview preparation for key personnel
- [ ] Evidence package reviewed for completeness

### {{audit_date - 1 week}}: Final preparation
- [ ] Evidence repository finalized
- [ ] Logistics confirmed (auditor access, rooms, schedules)
- [ ] Point of contact assigned for auditor questions

Step 7: HIPAA-specific playbook (if applicable)

When HIPAA is a target framework, add these proven patterns:

BAA execution strategy:

• Inventory all vendors and subprocessors that touch PHI
• Classify by access level: stores PHI, processes PHI, transmits PHI, or incidental access
• Execute BAAs before any PHI flows -- not after. A retroactive BAA is a documented violation.
• Template BAAs are acceptable for low-risk vendors; negotiate custom terms for primary infrastructure providers

PHI data handling rules:

• URL parameter protection: Never pass PHI in URL parameters (query strings appear in server logs, browser history, and referrer headers). Use POST bodies or encrypted tokens.
• "Track B" token pattern: Generate opaque session tokens that map to PHI server-side. The token travels through the application; the PHI stays in the encrypted store.
• Data at rest: AES-256 encryption minimum. Key management via AWS KMS, Azure Key Vault, or equivalent -- never application-managed keys.
• Data in transit: TLS 1.2+ for all connections. No exceptions for internal services.
• Minimum necessary: Every access request should answer "why does this role need this specific data field?"

Vendor compliance audit checklist:

• BAA executed and on file
• SOC 2 Type II report reviewed (current year)
• Data residency confirmed (where is PHI stored geographically?)
• Breach notification process documented (72-hour requirement)
• Subprocessor list obtained and reviewed
• Data deletion/return process confirmed for contract termination
• Encryption at rest and in transit confirmed
• Access logging enabled and reviewable

HIPAA-specific gap priorities:

1. Missing BAAs (immediate -- every day without one is a violation)
2. Unencrypted PHI at rest (critical -- blocks any audit)
3. Missing access logs (high -- auditors check these first)
4. No breach response plan (high -- required by Breach Notification Rule)
5. Incomplete workforce training (medium -- required annually)

Step 7b: AI-specific controls (if applicable)

When the organization uses AI tools that process sensitive data, add these controls:

AI data handling:

AI risk classification for compliance:

• Tier 1 (low risk): AI used for internal productivity with non-sensitive data (e.g., summarizing meeting notes)
• Tier 2 (medium risk): AI processing confidential data or producing outputs used in business decisions
• Tier 3 (high risk): AI processing regulated data (PHI, PII, financial) or producing outputs that affect regulated decisions
• Prohibited: AI making autonomous decisions in regulated domains without human review

Related skills: See /ai-governance-framework for comprehensive AI governance policy design.

Step 8: Review

Ask the user:

• Is the target audit date realistic given the gaps identified?
• Who owns remediation for each domain? Are those people aware and resourced?
• Are there budget constraints that affect control choices (e.g., open-source vs. commercial SIEM)?
• Any framework-specific concerns from legal counsel?
• Are there overlapping frameworks where a single control can satisfy multiple requirements?
• (If HIPAA) Have all vendor BAAs been executed? Is the PHI data flow documented?
• (If AI) Are AI tools inventoried and classified by risk tier?

Output location

Deliver as a markdown document. Suggested filename: compliance-map-{{framework}}-{{org-name}}-{{date}}.md. The readiness scorecard section should be extractable for executive reporting.