Cumplimiento y auditoría: la evidencia como efecto secundario
SchemaBridge Team · 2026-01-24 · Compliance, SOC2, GDPR, Security
Facilitar la evidencia SOC2 y el borrado GDPR con un historial de ejecución registrado, y ser precisos sobre lo que no garantiza.
El impuesto del cumplimiento: por qué las auditorías le frenan
Si alguna vez ha pasado por una auditoría SOC2, ISO27001 o HIPAA, conoce el dolor. El auditor pregunta: «Muéstreme evidencia de que cada solicitud de baja de usuario se procesó en menos de 24 horas».
En un sistema tradicional, esto desencadena una búsqueda frenética.
- Revisa los registros de correo.
- Hace grep en Splunk buscando algún mensaje de «Deleted User».
- Toma capturas de pantalla de un ticket de JIRA.
- Cruza marcas de tiempo en una hoja de cálculo.
Esta recopilación manual de evidencia puede consumir semanas de tiempo de ingeniería. Es el impuesto del cumplimiento. Distrae a sus mejores profesionales de construir funcionalidades. Y, peor aún, la evidencia suele ser circunstancial. Puede demostrar que un script se ejecutó, pero ¿puede demostrar exactamente qué datos tocó?
El rastro de auditoría: la evidencia como efecto secundario
En SchemaBridge creemos que la evidencia debe ser un efecto secundario de la ejecución, no una actividad aparte. El motor escribe un rastro de auditoría mientras trabaja: inicios, repeticiones (replays) y resoluciones de operador de las ejecuciones, cambios en workflows, vértices y aristas, despliegues, cambios de configuración y de retención, cambios de permisos y roles, y decisiones de aprobación.
Lo que le aporta el rastro
- Transiciones de estado registradas: el estado de la ejecución vive en PostgreSQL y se actualiza a medida que avanza la ejecución; junto a él, cada transición de estado se añade a una traza de ejecución, de modo que «¿cómo llegamos aquí?» tiene respuesta a posteriori. El rastro de auditoría registra el inicio de la ejecución y cualquier acción de un operador sobre ella, no cada transición.
- Trazabilidad: para cualquier ejecución, puede inspeccionar la entrada y la salida registradas de cada paso (dentro de su ventana de retención). Tenga en cuenta la distinción: Replay en SchemaBridge vuelve a ejecutar un workflow bajo una nueva ejecución, efectos secundarios incluidos; no es una reproducción histórica de solo lectura.
- Historial consultable: el rastro de auditoría se puede consultar por workspace y por workflow a través de la API, y reside en un almacén columnar dedicado (ClickHouse, detrás de un servicio de auditoría interno), separado de la base de datos operativa.
Lo que no es
Sea preciso con su auditor sobre las garantías. El rastro de auditoría es de solo anexado a nivel de aplicación, pero no a prueba de manipulaciones: no hay cadena de hashes ni firma, y las escrituras de auditoría son de tipo best-effort, por lo que un fallo de escritura no aparece como un hueco detectable. Si necesita evidencia de nivel WORM, exporte el rastro a un almacenamiento de escritura única que usted controle.
GDPR y el «derecho al olvido»
Uno de los retos más difíciles en cualquier sistema que conserva historial es el «derecho al olvido» (artículo 17 del GDPR). Si guarda un historial, ¿cómo elimina la PII (información de identificación personal) de un usuario?
Borrado y retención
SchemaBridge lo aborda con rutas de borrado y ventanas de retención.
1. Borrado: eliminar un workspace ejecuta una ruta de borrado dedicada, respaldada por un registro de obligaciones que se anota antes del borrado irreversible y se verifica después; una ruta independiente borra los datos de un usuario individual.
2. Purga automatizada: las ventanas de retención se definen por workspace (o se heredan de su plan). Las filas de ejecución, trazas y payloads antiguos se eliminan automáticamente.
3. Enmascaramiento de credenciales: los campos con forma de credencial (claves de API, secretos, tokens) se enmascaran como en los registros de ejecución. El enmascaramiento de PII no* es automático, así que la mejor defensa es no hacer pasar datos personales por pasos que no los necesitan.
Automatizar la recopilación de evidencia SOC2
Puede usar workflows de SchemaBridge para automatizar partes de la propia auditoría.
El «bot auditor»
En lugar de recopilar capturas de pantalla a mano, crea un workflow especializado de «Recopilación de evidencia» que se ejecuta con una programación cron cada lunes.
1. Escanear: consulta la API de GitHub para listar todos los PR fusionados la semana anterior.
2. Verificar: comprueba si cada PR tiene una revisión «Approved» de un code owner.
3. Instantánea: genera una instantánea JSON del estado de cumplimiento.
4. Archivar: escribe la instantánea en un almacenamiento que sus auditores puedan leer (a través de un endpoint HTTP que usted controla; idealmente, almacenamiento de escritura única).
Cuando llega el auditor, le remite al archivo en lugar de a un montón de capturas de pantalla, y el tiempo de preparación de la auditoría se reduce en consecuencia.
{
"week": "2026-W03",
"mergedPullRequests": 42,
"withCodeOwnerApproval": 42,
"exceptions": []
}Escenario ilustrativo: alta de pacientes en un entorno regulado
Considere una startup HealthTech hipotética que necesita automatizar los formularios de admisión de pacientes.
El reto
Necesitan demostrar que:
1. Solo el personal autorizado podía modificar o ejecutar el workflow de admisión.
2. Cada cambio en el workflow y cada resultado de ejecución quedaron registrados.
3. Los datos nunca se expusieron a herramientas de logging de terceros (Splunk/Datadog).
El enfoque
1. Acceso basado en roles: los roles de workspace (admin, writer, reader) y los ámbitos de permisos limitan quién puede editar, desplegar y ejecutar el workflow, y cada cambio de rol queda en el rastro de auditoría.
2. Ejecuciones registradas: el inicio de cada ejecución de admisión y cualquier resolución de un operador están en el rastro de auditoría, su historial completo de estados vive en el historial de ejecuciones, y el payload de cada paso puede inspeccionarse dentro de la plataforma en lugar de imprimirse en stdout.
3. Las brechas que seguirían siendo suyas: SchemaBridge no registra quién vio un payload, no tiene un rol específico para HIPAA y no posee certificación HIPAA. El registro de accesos por visualización y la documentación regulatoria seguirían siendo su responsabilidad.
El beneficio probable
Una configuración así haría mucho menos dolorosas las partes de una auditoría relativas a la gestión de cambios y al historial de ejecuciones, siendo a la vez honesta sobre las partes que la plataforma no cubre.
Comparativa: logging tradicional vs. rastro de auditoría de SchemaBridge
| Característica | Syslog / Splunk | Tablas de auditoría en base de datos | Rastro de auditoría de SchemaBridge |
| :--- | :--- | :--- | :--- |
| Inmutabilidad | Baja (se puede borrar) | Media (el DBA puede editar) | Media–alta (solo anexado a nivel de aplicación; almacén controlado por el operador) |
| Contexto | Una sola línea | Cambio de fila | Contexto de workflow y ejecución |
| Manejo de credenciales | Enmascaramiento manual | Cifrado de columnas | Campos de credenciales enmascarados en los registros de ejecución |
| Retención | Limitada (costosa) | Limitada (rendimiento) | Ventanas por workspace / por plan |
Lista de verificación experta para la arquitectura de cumplimiento
1. No registre PII: tenga cuidado con lo que imprime en stdout y con lo que pasa entre pasos. Mantenga los datos personales fuera de los payloads que no los necesitan.
2. Automatice la evidencia: si lo hace a mano, cometerá errores. Automatice la auditoría con scripts.
3. Separe funciones: quien escribe el workflow no debería ser quien custodia las claves de administrador.
4. Pruebe el borrado: ejecute periódicamente «solicitudes GDPR simuladas» para verificar que sus rutas de borrado y retención funcionan de verdad.
5. Conozca los límites de su plataforma: pregunte a cada proveedor, incluidos nosotros, qué se registra exactamente, durante cuánto tiempo y si es a prueba de manipulaciones. Incorpore las respuestas a la descripción de sus controles.
Conclusión: la confianza es una API
El cumplimiento no va de papeleo; va de confianza. Al construir sus sistemas sobre una base de historial registrado y consultable, y siendo precisos sobre lo que ese historial garantiza y lo que no, pasa de «Confíe en mí, soy un buen ingeniero» a «Aquí está la evidencia».
Parte de nuestra serie Building the Bridge. Véase también: El futuro de la integración.