Use this skill when preparing for SOC 2, HIPAA, or PCI-DSS compliance, conducting audits, or implementing security controls. Triggers on SOC 2, HIPAA, PCI-DSS, compliance audit, security controls, risk assessment, control frameworks, and any task requiring regulatory compliance planning or audit preparation.
Instrucciones de origen · Vista previa de solo lectura
name
regulatory-compliance
version
0.1.0
description
Use this skill when preparing for SOC 2, HIPAA, or PCI-DSS compliance, conducting audits, or implementing security controls. Triggers on SOC 2, HIPAA, PCI-DSS, compliance audit, security controls, risk assessment, control frameworks, and any task requiring regulatory compliance planning or audit preparation.
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.
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.
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.
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.
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:
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)
The best PCI-DSS strategy is reducing scope. Use a PCI-compliant payment
processor (Stripe, Braintree) with iframe/redirect tokenization. If cardholder
data never touches your servers, you qualify for SAQ A (the simplest self-assessment
questionnaire) rather than a full QSA audit.
Conduct a risk assessment
Follow NIST SP 800-30 or ISO 27005 for a defensible methodology:
Identify assets - List all systems, data stores, and third-party services
that store or process regulated data
Identify threats - For each asset, enumerate threat actors (external attacker,
malicious insider, accidental disclosure) and threat events (data breach, ransomware,
misconfiguration)
Identify vulnerabilities - What weaknesses could a threat exploit? (Unpatched
software, weak passwords, no MFA, overly broad access)
Calculate risk - Likelihood x Impact for each threat/vulnerability pair
Identify controls - Existing controls that reduce likelihood or impact; proposed
controls for unacceptable residual risk
Document and accept - Risk owner signs off on residual risk. Risk register is
reviewed annually and after significant changes
Build a controls matrix
A controls matrix maps each framework requirement to:
The control (what you do)
The control owner (who is responsible)
The evidence type (what proves it)
The evidence location (where to find it)
The review frequency (how often it is checked)
See references/controls-matrix.md for a complete SOC 2 Trust Services Criteria
controls matrix you can adapt.
Automate compliance monitoring
Manual compliance creates point-in-time snapshots that drift. Automate:
Evidence type
Automation approach
MFA enrollment
Query IdP API (Okta, Google Workspace) on schedule; alert on non-enrolled users
Access reviews
Export IAM group memberships quarterly; route to manager for sign-off via workflow
Vulnerability scans
Run Trivy or Snyk in CI; export results to compliance platform
Patch status
Query endpoint management API (Jamf, Intune); flag overdue patches
Security training
Pull completion data from training platform API
Change management
Git PR merge log automatically satisfies change control evidence
Logging enabled
IaC enforces CloudTrail/audit logging; drift detected by policy-as-code
Compliance platforms like Vanta, Drata, and Secureframe automate most of this via
integrations. Evaluate whether the platform cost (typically $15k-$40k/year) is
justified by the hours saved vs. manual evidence collection.
Manage the audit process
A well-run audit avoids surprises. Follow this timeline:
T-8 weeks: Auditor kickoff
Agree on scope, observation period dates, and fieldwork schedule
Share the controls matrix and request the evidence request list (PBC list)
Assign an internal point of contact for auditor questions
T-4 weeks: Evidence preparation
Collect all requested evidence; organize by control number
Review for gaps or anomalies before submission
Do not submit evidence you have not reviewed
T-2 weeks: Fieldwork
Respond to auditor questions within 24-48 hours
Track open items in a shared log
Escalate blockers immediately - do not let items age
T-0: Report delivery
Review draft report carefully for factual errors before it is finalized
Exceptions (qualified opinions) are negotiable if the evidence was misunderstood
Attach a management response to any exceptions explaining remediation plans
An exception in a SOC 2 report is not automatically a deal-breaker. Customers
read the management response. A clear remediation timeline with evidence of
progress is often acceptable.
Build a continuous program with automated evidence and quarterly reviews
Scope creep - putting everything in scope
Larger scope = more controls = more cost and audit time
Define the tightest defensible scope; use network segmentation to exclude non-regulated systems
Writing policies nobody reads or follows
Policies without enforcement are paper compliance that auditors see through
Tie every policy to a technical control or an automated check; require annual acknowledgment
Buying a compliance platform before a gap analysis
Platform integrations cover generic controls; custom controls still need manual work
Complete the gap analysis first; then evaluate platforms against your specific control gaps
Using shared accounts to access regulated systems
Violates individual accountability requirements in every major framework
Enforce unique user IDs at the IdP level; fail pipelines that use shared credentials
Deferring the risk assessment until the last month
Risk assessment drives control selection; doing it late means controls may not address real risks
Complete risk assessment in the first gap analysis phase; repeat annually
Gotchas
Starting SOC 2 Type II observation period before all controls operate - The observation clock starts when controls are running, not when you decide to pursue SOC 2. Auditors verify operating effectiveness over the claimed period. Any control that was not operating at the start of the period creates a gap finding. Don't declare the observation period started until every control is actually in place.
PCI-DSS scope assumed to be narrow before scoping exercise - Teams often assume they're out of scope because they "don't store card numbers." But processing or transmitting card data, or being on the same network segment as systems that do, puts you in scope. Conduct formal scope definition with a QSA before building any compliance program assumptions.
Compliance platform purchased before gap analysis - Vanta and Drata automate evidence for generic controls but cannot replace custom controls specific to your architecture. Buying the platform before knowing your gaps means paying for integrations that don't cover your actual exposures.
Exception in SOC 2 report treated as a deal-breaker - A qualified opinion with a management response showing a clear remediation plan is often acceptable to enterprise procurement. The response matters as much as the exception. Draft the management response carefully and include a concrete timeline with evidence of progress.
Risk assessment done once and never updated - A static risk assessment taken at the start of a compliance program becomes fiction within 6 months as systems change. Schedule annual reviews and trigger an unscheduled review after any significant architecture change, acquisition, or data classification change.
References
For detailed implementation guidance, read the relevant file from references/:
references/controls-matrix.md - SOC 2 Trust Services Criteria mapped to controls,
evidence types, and review frequencies
Companion check
On first activation of this skill in a conversation: check which companion skills are installed by running ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null. Compare the results against the recommended_skills field in this file's frontmatter. For any that are missing, mention them once and offer to install:
