When this skill is activated, always start your first response with the 🧢 emoji.

Regulatory Compliance

A practitioner's framework for achieving and maintaining regulatory compliance. This skill covers SOC 2, HIPAA, and PCI-DSS - the three frameworks most commonly demanded by enterprise customers - with an emphasis on how to build a sustainable compliance program, not just pass a one-time audit.

When to use this skill

Trigger this skill when the user:

• Prepares for a SOC 2 Type I or Type II audit
• Implements HIPAA technical, administrative, or physical safeguards
• Works toward PCI-DSS compliance for payment card environments
• Conducts a risk assessment or gap analysis
• Builds or updates a controls matrix
• Automates evidence collection for ongoing compliance
• Manages an active audit with an external auditor
• Defines policies for data handling, access control, or incident response

Do NOT trigger this skill for:

• General security hardening not tied to a specific framework (use backend-engineering security references instead)
• Legal or attorney-client questions - always refer to qualified legal counsel for jurisdiction-specific obligations

Key principles

1. Compliance is continuous, not a project - Passing an audit is a snapshot in time. The goal is a living program with controls that operate daily. Scrambling for evidence two weeks before an audit means your controls are theater, not real.

2. Automate evidence collection - Manual evidence collection does not scale and creates audit fatigue. Instrument your systems to produce compliance artifacts automatically: access logs, change records, configuration exports, and training completions should all be captured without human intervention.

3. Controls should serve the business - A control that creates so much friction that engineers route around it is worse than no control. Design controls that are least-privilege without being obstructive. If teams hate a control, find a more elegant implementation, not an exception.

4. Start with the framework that customers demand - Do not attempt all three frameworks simultaneously. Survey your enterprise customers and prospects. SOC 2 unblocks most B2B SaaS deals. HIPAA is required the moment you touch protected health information. PCI-DSS is mandatory if you store, process, or transmit cardholder data. Pick one, reach Type II, then expand.

5. Gap analysis before implementation - Never start writing policies or deploying tools without first mapping your current state to the required controls. A gap analysis reveals which controls are already satisfied (often 30-40%), which need tooling, and which need process changes. Skipping it wastes months building things you already have.

Core concepts

Control frameworks

A control framework is a structured set of requirements that an organization must satisfy to meet a compliance standard. The three major frameworks covered here:

Evidence types

Auditors require evidence that controls are designed correctly (Type I) and operating effectively over time (Type II). Evidence categories:

• Configuration exports - Screenshots or exports showing system settings (MFA enabled, encryption at rest, logging enabled)
• Access reviews - Periodic exports showing who has access to what, reviewed and signed off by a manager
• Policy documents - Written policies with version history and employee acknowledgment records
• Training records - Completion logs for security awareness and role-specific training
• Incident records - Log of security incidents with detection, response, and closure
• Vendor reviews - SOC 2 reports or security questionnaires for third-party vendors
• Change management records - Git history, PR approvals, deploy logs showing change control processes

Audit process

Gap Analysis -> Remediation -> Readiness Review -> Audit -> Report
     |               |               |                |         |
  4-8 weeks      3-12 months     4-6 weeks        4-8 weeks  2-4 weeks
  Map controls   Build controls  Mock audit       Evidence   Final report
  to current     that are        with auditor     collection issued
  state          missing         (optional)

Type I audit: point-in-time snapshot that controls are designed appropriately. Type II audit: 6-12 month observation period proving controls operate continuously. Always target Type II - enterprise procurement teams reject Type I as insufficient.

Risk assessment

Risk assessment is the foundation of every compliance framework. It identifies threats to your systems and data, evaluates their likelihood and impact, and drives the prioritization of controls.

Risk score formula: Risk = Likelihood (1-5) x Impact (1-5)

Common tasks

Prepare for SOC 2 Type II

A realistic 12-18 month roadmap for a startup with no prior compliance program:

Months 1-2: Gap analysis and scoping

• Define the system boundary (what systems are in scope)
• Map all Trust Services Criteria to existing controls
• Identify gaps and assign remediation owners
• Select a compliance platform (Vanta, Drata, Secureframe, or manual)

Months 3-8: Remediation

• Implement missing technical controls (MFA everywhere, encryption at rest and in transit, logging and monitoring, vulnerability scanning, access reviews)
• Write required policies (security, access control, incident response, business continuity, vendor management, change management)
• Run employee security awareness training and document completion
• Conduct vendor reviews for all subprocessors handling customer data

Months 9-10: Observation period start

• All controls must be operating; the clock starts for the Type II period
• Automate evidence collection for operating controls
• Schedule quarterly access reviews and vulnerability scans

Months 11-12: Readiness and audit

• Conduct internal readiness review; fix any findings
• Engage auditor for fieldwork
• Respond to auditor requests within agreed SLAs
• Receive SOC 2 Type II report (6-month or 12-month observation period)

Choose the 6-month observation period for your first report. You can expand to 12-month on renewal. A 6-month report unblocks deals faster.

Implement HIPAA safeguards

HIPAA requires three categories of safeguards for covered entities and business associates handling PHI:

Administrative safeguards (45 CFR 164.308)

• Conduct and document a security risk analysis annually
• Designate a Security Officer responsible for HIPAA compliance
• Implement workforce training with documented completion records
• Establish sanction policies for employees who violate HIPAA
• Define access authorization and management procedures

Physical safeguards (45 CFR 164.310)

• Control physical access to systems that contain PHI
• Implement workstation use and security policies
• Establish device and media controls (encryption, disposal procedures)

Technical safeguards (45 CFR 164.312)

• Unique user identification for all PHI access (no shared