regulatory-compliance

Files (4)

• README.md
• SKILL.md
• evals.json
• controls-matrix.md · references/

SKILL.md (first lines)

## 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:

| Framework | Owner | Core focus | Audit type | Who needs it |
|---|---|---|---|---|
| SOC 2 | AICPA | Trust Services Criteria (security, availability, confidentiality, privacy, processing integrity) | Third-party CPA audit | B2B SaaS, cloud services |
| HIPAA | U.S. HHS | Protected health information (PHI) privacy and security | Self-attestation + OCR enforcement | Healthcare, covered entities, business associates |
| PCI-DSS | PCI Security Standards Council | Cardholder data environment (CDE) protection | QSA audit (Level 1) or SAQ (Level 2-4) | Any entity storing/processing/transmitting card data |

### 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)

| Score | Action |
|---|---|
| 20-25 | Critical - immediate remediation required |
| 12-19 | High - remediate within 30 days |
| 6-11 | Medium - remediate within 90 days |
| 1-5 | Low - accept with documented rationale or remediate in backlog |

---

## 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

From mkurman/zorai, MIT.

More from mkurman/zorai