Checklist de auditoría RGPD para equipos de ingeniería

Publicado el 16 de septiembre de 2026

Cuando llega una auditoría real, las preguntas no son de derecho: son de datos. Esto es lo que un ingeniero necesita poder enseñar, y dónde vive cada pieza si usas Tripticonsent.

Una auditoría RGPD casi nunca empieza con una pregunta legal. Empieza con una pregunta de datos: "enséñame el consentimiento exacto que dio este usuario, en esta fecha, y demuéstrame que no ha cambiado desde entonces". Si esa pregunta te obliga a escribir una query ad-hoc contra producción, ya vas tarde.

Esto es lo que de verdad se pide en una auditoría seria, ordenado como una lista de comprobación. Cada punto enlaza a dónde vive esa pieza si usas Tripticonsent, pero el criterio en sí sirve igual para evaluar cualquier stack, incluido uno construido a mano.

1. ¿Puedes reconstruir el consentimiento tal y como era en una fecha concreta, no solo hoy?

Un booleano en una tabla de usuarios solo dice el estado actual. Un regulador pregunta por un momento del pasado: qué versión de la cláusula estaba publicada, y qué decidió esa persona sobre esa versión exacta. Eso exige guardar cada cambio como una fila nueva, nunca sobrescribir la anterior. En la bóveda esto es la cronología completa por sujeto: consentimiento, preferencias y fusiones, con marca de tiempo.

2. ¿Puedes demostrar qué vio la persona exactamente, palabra por palabra?

No basta con saber que aceptó "marketing". Hace falta el texto exacto que tenía delante en ese momento, con su versión. El justificante firmado incluye un hash del texto exacto de la cláusula junto a la decisión, así que cualquier disputa sobre qué decía el banner se resuelve comparando hashes, no memorias.

3. ¿Puede alguien verificar esa prueba sin tener que confiar en tu palabra?

Esta es la pregunta que casi ningún stack casero se plantea hasta que ya es tarde. Un justificante firmado con Ed25519 se verifica con las claves públicas en /.well-known/jwks.json, sin llamar a tu API. Ya escribimos sobre esto con detalle en qué prueba realmente un recibo firmado.

4. ¿Puedes entregar un export completo de una persona cuando lo pide?

Un DSAR de exportación no es "busca su email en la base de datos". Es historial completo, justificantes incluidos, entregado de forma verificable. El flujo de solicitudes de datos genera una URL firmada y con caducidad para exactamente esto.

5. Cuando borras a alguien, ¿de verdad desaparece, y puedes probarlo?

"Borrar" en la mayoría de los sistemas caseros significa una actualización que marca una fecha de borrado. El identificador sigue en texto plano en algún backup. El crypto-shredding real destruye el material de cifrado del identificador de forma inmediata: el sujeto queda ilocalizable desde ese instante, y el registro anonimizado que queda sirve como constancia defensiva, no como un riesgo.

6. ¿Tu propio registro de cambios se puede alterar sin que se note?

Un registro de auditoría que un administrador puede editar por detrás no es una prueba, es una opinión. Cada entrada de un registro encadenado por hash incluye el hash de la entrada anterior. Alterar o borrar una fila intermedia rompe la cadena a partir de ese punto de forma visible, sin depender de que nadie revise manualmente los logs.

7. ¿Sabes, y puedes enseñar, quién más toca esos datos?

Un auditor pregunta por subencargados: quién procesa los datos además de ti. Stripe para pagos, Groq para clasificación de cookies con IA cuando está activado, el proveedor de hosting. La lista completa, con qué hace cada uno, tiene que estar publicada de antemano y no descubrirse durante la propia auditoría.

Ninguno de estos siete puntos es exclusivo de Tripticonsent: son la lista que un auditor serio revisa en cualquier stack. La diferencia está en si la respuesta a cada uno es "sí, mira aquí" o "dame una semana para reconstruirlo".