Compliance roadmap — SOC 2, GDPR, HIPAA¶

Qué requiere cada framework, qué cubrimos arquitectónicamente, qué hace falta operacionalmente. Phased plan. NO consejo legal — guía técnica.

Disclaimer¶

Esto NO es consejo legal. Compliance final requiere: - Asesor legal especialista en el framework. - Audit firma certificada (SOC 2: AICPA-registered; HIPAA: HHS-compliant auditor). - Documentación específica por organización.

Este doc cubre qué prepara el producto para que la compliance sea alcanzable.

SOC 2 Type II — Trust Services Criteria¶

SOC 2 cubre 5 áreas (Trust Services Criteria — TSC):

TSC	Cobertura	Phase
Security (CC)	Acceso, auth, audit, network	M1-M2
Availability (A)	Uptime, DR, capacity	M2-M3
Processing Integrity (PI)	Replay determinism, dedup	M1
Confidentiality (C)	Encryption, data classification	M1-M2
Privacy (P)	PII handling, user controls	M2-M3

Type II = 6+ meses de evidencia operacional. Type I = solo design.

Security CC controls¶

CC1: Control environment. - Organización con código de conducta, hiring, training. - Producto contribuye: docs de incident response, runbooks.

CC2: Communication of information. - Internal comms. - Producto: changelog, status page.

CC3: Risk assessment. - Producto: analysis/failure-mode-analysis, threat model.

CC4: Monitoring activities. - Producto: observability (analysis/observability-deep-dive), alerting.

CC5: Control activities. - Producto: code review process, access controls (RBAC).

CC6: Logical and physical access. - ✅ MFA-required: OIDC con MFA al IdP. - ✅ Least privilege: RBAC granular (adrs/adr-013-simple-rbac-three-roles + future scopes). - ✅ Audit logs: cada acceso loggeado (adrs/adr-025-audit-logging-mandatory). - ✅ Network: TLS-only (adrs/adr-023-tls-only-production). - ✅ Service accounts: separados, rotación de credentials.

CC7: System operations. - ✅ Change management: GitOps + PR review. - ✅ Incident management: runbooks + post-mortem. - ✅ Backup + DR: analysis/disaster-recovery-runbook.

CC8: Change management. - ✅ Version control. - ✅ Code review. - ✅ CI/CD pipelines.

CC9: Risk mitigation. - ✅ Pen testing anual. - ✅ Vulnerability scanning continuo (dependabot, snyk). - ✅ Incident response plan.

Availability A controls¶

A1: Availability commitments. - SLA documentado. - SLI tracking (analysis/observability-deep-dive). - Status page público.

A2: System failures. - Multi-AZ deployment (M3+). - Auto-failover (M2+). - Capacity planning (analysis/performance-testing-methodology).

A3: Backup and recovery. - pgBackRest cross-region (M2+). - RPO 5min, RTO 30s (M3+) — ver analysis/disaster-recovery-runbook.

Processing Integrity PI controls¶

PI1: System processing. - Idempotency (analysis/idempotency-and-deduplication). - Replay determinism (adrs/adr-019-replay-determinism-invariant). - At-least-once con dedup ⇒ effectively-exactly-once.

Confidentiality C controls¶

C1: Information classification. - Data classification per tenant/process. - PII flagged variables → encryption at rest.

C2: Encryption. - ✅ At rest: Postgres data encrypted (LUKS o cloud-native). - ✅ In transit: TLS 1.3 mandatory (adrs/adr-023-tls-only-production). - ✅ Backups: encrypted at rest (pgBackRest cipher). - ⚠️ Specific variables: pgcrypto field-level (M3).

Privacy P controls¶

P1: Notice and communication. - Privacy policy. - Data processing agreement (DPA) para clientes.

P2: Choice and consent. - Customer determina qué data envía. - Opt-out flows.

P3: Collection. - Minimization: solo data necesaria para procesos.

P4: Use and retention. - Configurable retention per tenant. - Auto-deletion after retention period.

P5: Disclosure. - Subprocessors documented. - Customer notification de breach.

P6: Quality. - Data accuracy via process integrity.

P7: Monitoring. - Audit logs. - Access logs.

P8: Incident response. - Privacy incident playbook. - Customer + regulator notification within 72h (GDPR).

SOC 2 readiness checklist¶

Infrastructure
[ ] All access via SSO + MFA
[ ] Least-privilege RBAC enforced
[ ] Network segmentation (VPC, security groups)
[ ] TLS everywhere (no plain HTTP)
[ ] Encryption at rest (DB, backups, object store)
[ ] Vulnerability scanning enabled
[ ] Pen test conducted (annually)

Processes
[ ] Onboarding/offboarding checklist
[ ] Change management process (PR review, deployment gates)
[ ] Incident response runbook tested
[ ] DR drill quarterly
[ ] Vendor security review process

Documentation
[ ] Information security policy
[ ] Access control policy
[ ] Backup & recovery policy
[ ] Incident response plan
[ ] Change management policy
[ ] Data classification policy

Evidence (continuous)
[ ] Access logs (12+ months retention)
[ ] Audit logs (12+ months)
[ ] Backup verification reports
[ ] Patch management records
[ ] Training records
[ ] Vendor management records

Aplicable si procesás datos personales de residentes EU.

Core principles¶

Lawful basis: cada procesamiento necesita base legal (consent, contract, legitimate interest, etc.).

Data minimization: solo lo necesario.

Purpose limitation: usado solo para propósito declarado.

Storage limitation: borrar cuando ya no necesario.

Accuracy: data correcta y actualizada.

Integrity & confidentiality: encryption, access controls.

Accountability: documentar cumplimiento.

Specific rights¶

Cada residente EU tiene:

Acceso (Art 15): "dame mi data".
Producto: API GET /api/v1/admin/data-export?subject={subjectId} que extrae todos los procesos/jobs/variables que mencionen al subject.
Rectificación (Art 16): "corrige mi data".
Variable update vía API o UI.
Borrado (Art 17, "right to be forgotten"):
Producto: API DELETE /api/v1/admin/subjects/{subjectId} que:
- Anonymiza variables (replace con [REDACTED]).
- Mantiene audit trail (legal basis).
- Marca process instances "subject erased".
Considerar: archived audit logs según retention legal.
Portabilidad (Art 20): "exporta mi data".
JSON export estructurado.
Oposición (Art 21): "para de procesar".
Cancel active instances + stop new instances for subject.

Data subject request flow¶

# Verificar identidad (out-of-band)
# Luego ejecutar
wf gdpr export --subject-id "user-12345" --output user-12345.json
wf gdpr erase --subject-id "user-12345" --reason "Article 17 request"
# Audit log captures the request + execution

Timeline: respond within 30 days.

Subprocessors¶

GDPR requiere disclosure de subprocessors (proveedores que reciben PII).

Postgres provider (e.g., AWS RDS) → subprocessor.
Object storage para backups (S3) → subprocessor.
Monitoring (Datadog) → subprocessor (si recibe PII).

Producto: lista pública de subprocessors actualizada.

Data residency¶

Algunos clientes EU exigen data en EU. Producto: - Multi-region support (Modelo B in analysis/multi-region-active-active). - Tenant data_residency: "eu-west-1" enforced en routing + storage.

Encryption keys¶

GDPR no exige específicamente BYOK, pero algunos clientes sí. Producto: - Postgres TDE (Transparent Data Encryption). - KMS integration: AWS KMS / GCP KMS / Azure Key Vault. - BYOK opcional (cliente provee KEK).

Breach notification¶

Si breach que afecta PII: - Producto: alert system (audit log anomaly detection). - Process: 72h notification a regulator. - Customer notification per DPA.

[ ] DPA template ready
[ ] Subject request API working
[ ] Data export tool tested
[ ] Erasure tool tested
[ ] Subprocessor list current
[ ] Retention policy per data type
[ ] Breach response plan
[ ] DPO designated (if needed)
[ ] Privacy impact assessment template
[ ] Multi-region data residency option

HIPAA — Health Insurance Portability and Accountability Act (US)¶

Aplica si procesa PHI (Protected Health Information).

HIPAA Security Rule áreas¶

Administrative safeguards: - Workforce training. - Access management. - Audit controls. - Incident response.

Physical safeguards: - Facility access (cloud provider responsibility). - Workstation security.

Technical safeguards: - Access control (unique IDs). - Audit logs. - Integrity controls. - Transmission security (TLS). - Encryption at rest.

HIPAA-specific product needs¶

BAA (Business Associate Agreement): requerido si procesás PHI.
Cloud provider BAA (AWS HIPAA-eligible services).
Nuestro contrato customer DPA + BAA.
Audit logs detallados: cada acceso a PHI loggeado.
Already: adrs/adr-025-audit-logging-mandatory.
Adicional: log every read of PHI fields.
Encryption at rest mandatory: no opcional para PHI.
Access controls: MFA mandatory.
Minimum necessary: usuarios solo ven PHI estrictamente necesario.
RBAC fine-grained (Phase 2+: scopes específicos).
Data integrity: PHI no debe alterarse en transit/rest sin detection.
Audit log con tamper detection (hash chain).
Audit log retention: 6 años minimum HIPAA.

Special data handling¶

PHI requires: - Encrypted variables (pgcrypto field-level). - Access logs separados. - Anonymization tooling.

-- Tag variables como PHI en proceso
{
  "patient_name": { "type": "string", "phi": true },
  "diagnosis": { "type": "string", "phi": true },
  "appointment_time": { "type": "datetime", "phi": false }
}

Engine routes PHI variables a encrypted column. Audit logs include PHI access.

HIPAA readiness checklist¶

[ ] BAA template ready
[ ] Cloud provider HIPAA-eligible
[ ] Encryption at rest verified
[ ] Encryption in transit verified
[ ] MFA enforced
[ ] Audit logs include PHI access
[ ] Audit log retention 6+ years
[ ] Tamper-evident audit log
[ ] Workforce training records
[ ] Risk assessment annual
[ ] Incident response includes breach
[ ] Data backup encrypted
[ ] Workstation security policy

Otros frameworks (cobertura ligera)¶

Framework	Quién	Highlights
PCI DSS	Procesadores de tarjetas	Tokenization; nuestro engine NO almacena card data
FedRAMP	US gov cloud	Mucho overlap con SOC 2, plus continuous monitoring
ISO 27001	Global ISMS	ISMS structure; similar a SOC 2
CCPA	California	Similar a GDPR pero menos estricto
LGPD	Brasil	Similar a GDPR

ISO 27001 + SOC 2 + GDPR cover ~90% de lo que enterprise customers piden.

Audit trail architecture¶

Crítico para todos los frameworks.

CREATE TABLE audit_log (
    id BIGSERIAL PRIMARY KEY,
    timestamp TIMESTAMPTZ NOT NULL DEFAULT now(),
    actor_type TEXT NOT NULL,      -- user / service / system
    actor_id TEXT NOT NULL,
    tenant_id TEXT NOT NULL,
    action TEXT NOT NULL,          -- "instance.cancel", "process.deploy"
    resource_type TEXT NOT NULL,
    resource_id TEXT,
    outcome TEXT NOT NULL,         -- "success", "denied", "failed"
    request_id TEXT,
    ip_address INET,
    user_agent TEXT,
    payload_hash TEXT,             -- hash of request body (for non-repudiation)
    prev_hash TEXT,                -- chain back to previous event (tamper detection)
    this_hash TEXT,                -- hash(prev_hash + this row)
    metadata JSONB
) PARTITION BY RANGE (timestamp);

-- Hash chain check
SELECT *
FROM audit_log
WHERE this_hash != sha256(prev_hash || ... || row data);
-- Si retorna filas: tampering detected

Append-only via permissions:

GRANT INSERT, SELECT ON audit_log TO app_user;
-- NO UPDATE, NO DELETE permissions

Retention partitions:

-- Mensual partitions
CREATE TABLE audit_log_2026_05 PARTITION OF audit_log
    FOR VALUES FROM ('2026-05-01') TO ('2026-06-01');

-- Drop después de retention period
-- HIPAA: 6 años → drop después de 7 (extra buffer)

Phased rollout¶

Phase 1 (M1): Foundations¶

Encryption at rest + in transit.
Basic audit log.
RBAC 3 roles.
TLS-only.
OIDC integration.

Suficiente para SOC 2 Type I (design only).

Phase 2 (M2): SOC 2 Type II prep¶

6+ meses ops evidence.
Quarterly DR drills.
Pen test (1× annual).
Vulnerability scanning automated.
Incident response runbook.
Change management documented.

Goal: SOC 2 Type II audit kicks off after 6 months of operation.

Subject request API.
Data export/erase tools.
Multi-region for data residency.
DPA template.
Subprocessor management.

Goal: GDPR-ready for EU customers.

Phase 4 (M4): HIPAA ready¶

BAA template.
Cloud provider HIPAA verification.
Field-level encryption for PHI.
Enhanced audit logging.
6-year retention.

Goal: HIPAA-ready for healthcare customers.

Phase 5+: FedRAMP / specialized¶

Based on customer demand.

Cost of compliance¶

Approximate annual costs (en USD):

Item	SOC 2	GDPR	HIPAA
Audit firm	$30K-100K	$0 (self-attest)	$50K+
Pen test	$20K-50K	included	included
Tooling (Vanta/Drata)	$20K-50K	included	included
Legal	$10K-30K	$20K-50K	$15K-30K
Engineering time	200-500h	100-300h	200-400h
Total Year 1	$80K-250K	$30K-100K	$100K-300K

Year 2+: maintenance ~30-50% of Year 1.

Tooling para compliance¶

Vanta / Drata: continuous compliance monitoring.
Tugboat Logic: SOC 2 dashboards.
Privacera / BigID: data classification, GDPR tooling.
Veracode / Snyk: SAST / DAST.
CrowdStrike / SentinelOne: EDR.

Decisión: pick 1 platform en Year 1 para evitar tool sprawl.

Customer-facing artifacts¶

Lista que enterprise expects:

trust.example.com/
├── security/
│   ├── overview.pdf
│   ├── audit-reports/
│   │   ├── soc2-type-ii-2026.pdf
│   │   └── pen-test-2026.pdf
│   └── compliance/
│       ├── soc2.md
│       ├── gdpr.md
│       └── hipaa.md
├── policies/
│   ├── information-security.pdf
│   ├── incident-response.pdf
│   └── access-control.pdf
├── subprocessors.md
├── status.html (status page)
└── changelog/

Referencias¶

analysis/security-threat-model — STRIDE
analysis/disaster-recovery-runbook — availability A
analysis/observability-deep-dive — monitoring CC4
analysis/idempotency-and-deduplication — processing integrity PI1
adrs/adr-023-tls-only-production — transit encryption
adrs/adr-024-postgres-rls-defense-in-depth — access control
adrs/adr-025-audit-logging-mandatory — audit logs
AICPA SOC 2
GDPR text
HHS HIPAA Security Rule