El problema de la evidencia en SOC2 Type II
Una auditoría SOC2 Type II no es solo un cuestionario. Los auditores necesitan evidencia de que los controles funcionaron durante el período de auditoría, generalmente 6 o 12 meses.
La pregunta que los auditores hacen siempre: "¿Cómo demuestras que el control funcionó durante el período de auditoría?" Con Vericto, la respuesta es: "Con el export del audit trail firmado por este endpoint."
Sin una capa de proxy, la evidencia de acceso a base de datos se dispersa entre logs de aplicación, logs de la DB, y herramientas de monitorización. Correlacionar todo esto para una auditoría es costoso en tiempo.
El 60% del tiempo de preparación de una auditoría SOC2 se va en recopilar y correlacionar evidencia que ya debería estar centralizada.
Qué registra el audit trail de Vericto
Cada query que pasa por el proxy de Vericto genera un registro en el audit trail. El registro incluye:
- Timestamp con precisión de milisegundos (UTC)
- Texto completo de la query (cifrado con AES-256, solo accesible para el workspace)
- Hash SHA-256 de la query (para correlación sin descifrar)
- Decisión: ALLOWED, BLOCKED, o PARSE_ERROR
- Regla activada (para bloqueos): código, severidad, y nodo AST infractor
- Nodo AST infractor con path completo (ej: DeleteStmt > WhereClause = NULL)
- Identidad del workspace y la base de datos
- Latencia de processing del proxy (para SLA evidence)
Ejemplo de un registro en el export JSON:
{
"event_id": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
"timestamp": "2026-04-15T02:14:33.847291Z",
"workspace_id": "6ba7b810-9dad-11d1-80b4-00c04fd430c8",
"database": "prod-db",
"decision": "BLOCKED",
"rule_code": "VERICTO-001",
"severity": "critical",
"ast_node_path": "DeleteStmt > WhereClause = NULL",
"query_sha256": "e3b0c44298fc1c149afbf4c8996fb924...",
"estimated_rows_affected": 847293,
"latency_ms": 1.3,
"hmac_signature": "9f86d081884c7d659a2feaa0c55ad015..."
}Por qué es inmutable y por qué importa
La inmutabilidad es lo que convierte un log en evidencia auditorial. Un log que puede ser modificado no es evidencia: es un documento editable.
Vericto garantiza la inmutabilidad con dos mecanismos:
- Append-only: los registros del audit trail nunca se modifican ni eliminan por usuarios o el sistema
- Firma Ed25519: cada export incluye una firma criptográfica del contenido completo del archivo, verificable offline con la clave pública del workspace
Al exportar el audit trail, Vericto incluye una firma Ed25519 del archivo completo. Con la clave pública del workspace, el auditor puede verificar independientemente y offline que el export no ha sido modificado desde su generación.
Qué criterios SOC2 satisface directamente
Los Trust Services Criteria de SOC2 más relevantes para el audit trail de Vericto son CC6 (Control de acceso lógico) y CC7 (Operaciones del sistema).
| Criterio | Descripción | Cómo lo satisface Vericto |
|---|---|---|
CC6.1 |
Controles de acceso lógico a datos | El audit trail documenta cada acceso de escritura y su decisión de bloqueo/permiso |
CC6.3 |
Gestión de acceso a información sensible | Las reglas custom permiten bloquear operaciones en tablas sensibles con registro completo |
CC7.2 |
Monitoreo de actividad anómala | Las alertas en tiempo real de bloqueos CRITICAL documentan la detección de anomalías |
CC7.3 |
Evaluación de eventos de seguridad | Cada query bloqueada incluye el nodo AST infractor y la severidad para evaluación |
Cómo exportar evidencia para el auditor
Cada ejecución de la CLI puede emitir un recibo firmado: un registro autocontenido de qué se evaluó y con qué veredicto, firmado con Ed25519. El recibo se verifica offline —sin red ni cuenta— con vericto verify-receipt, así que el auditor confirma su autenticidad de forma independiente. El plan Team y superiores permiten además exportar el audit trail completo del periodo desde el dashboard.
# En CI: evalúa y emite un recibo firmado del run
vericto check --changed --receipt vericto-receipt.json
# El auditor lo verifica offline, sin credenciales ni red
vericto verify-receipt vericto-receipt.json
# La clave pública de verificación se obtiene de:
# GET https://api.vericto.com/api/v1/meta/export-signing-keyEl recibo incluye los eventos del run con su firma Ed25519, verificable contra la clave pública del workspace. Con el audit trail completo del periodo, el auditor puede:
- Verifica la firma Ed25519 del archivo exportado
- Filtra por status = BLOCKED para el período de auditoría
- Confirma que las reglas activas durante el período son las esperadas (versión del ruleset)
- Correlaciona los bloqueos con los cambios en el sistema (deploy log, incident log)
Retención de datos y plazos para auditoría
Los plazos de retención dependen del plan contratado:
- Plan Free: 7 días de retención
- Plan Builder: 30 días de retención
- Plan Team: 90 días de retención
- Plan Enterprise: retención configurable (hasta 3 años)
Para SOC2 Type II con período de 12 meses, recomendamos el plan Enterprise para garantizar que el audit trail completo esté disponible durante todo el período de auditoría.
Para clientes Enterprise, Vericto puede proporcionar reportes de compliance personalizados con el formato específico que requiere cada auditor.
Más allá de SOC2: ISO 27001 y GDPR
El mismo audit trail satisface requisitos de otros marcos de compliance:
- ISO 27001 (Annex A, control A.8.15): Logging, registros de actividad de sistemas
- GDPR Art. 32: Medidas técnicas para garantizar la seguridad del tratamiento
La naturaleza determinística del AST parsing hace que los controles sean certificables: el mismo input siempre produce el mismo resultado, y ese resultado está documentado en el audit trail.