De TIA/TRA a control continuo

Caducidades, KRIs, control de cambios y auditoría trimestral del ecosistema web/app

Si el Post 6 te llevó del “mapa técnico” al expediente defendible, y el Post 7 bajó las medidas complementarias que realmente cambian el riesgo, este Post 8 aborda el punto donde más programas se rompen:

Cómo evitar que tu cumplimiento se degrade con cada release, nuevo tag, nueva campaña o nuevo subencargado.

El objetivo no es “auditar más”. Es operar un sistema de control continuo: señales (KRIs) + caducidades + triggers + evidencias repetibles + decisiones de Comité.

1) Por qué “TIA/TRA” sin operación continua es papel (y por qué ahora importa más)

Una TIA/TRA puede ser excelente el día que se aprueba… y quedar obsoleta en semanas por:

• cambios en el contenedor de tags (GTM u otro),
• nuevas integraciones (píxeles/Conversion APIs),
• cambios de proveedor/subencargado,
• activaciones “pre-consent” accidentales,
• cambios de arquitectura (CDN/WAF, nueva región cloud, soporte global).

Además, los reguladores han ido reforzando el enfoque operativo: no basta con elegir un mecanismo; hay que documentar y mantener la evaluación y las garantías en el tiempo. El ICO, por ejemplo, publica una guía muy detallada sobre cómo completar una Transfer Risk Assessment (TRA) y qué exige mantener para cumplir, en versión actualizada de 15/01/2026. (ico.org.uk)
En España, la AEPD también consolida en su material de cumplimiento el foco en garantías y documentación para transferencias. (Agencia Española de Protección de Datos)

2) El modelo operativo GRCx3: de “control puntual” a “ciclo de control”

Te propongo un modelo que puedas explicar a dirección y que sea ejecutable por equipos técnicos:

Ciclo continuo (tres carriles)

1. Carril A — Control preventivo (change control)
   • Nada entra sin ticket, revisión y evidencias post-implementación.
2. Carril B — Monitorización/KRIs
   • Señales tempranas que te avisan de degradación (antes de que sea un incidente o una inspección).
3. Carril C — Auditoría trimestral (muestra + evidencia repetible)
   • Pruebas planificadas, con método y reportes comparables.

Este enfoque es perfectamente compatible con prácticas de auditoría: definir alcance, criterios, método de muestreo, evidencias y conclusiones. Y en web/app, además, tienes tooling específico para hacer pruebas repetibles (p. ej., EDPB Website Auditing Tool y collectors asociados). (EDPB)

3) Caducidades: la “política de vencimiento” que mantiene vivo el expediente

Sin caducidades, todo “parece vigente” hasta que algo se rompe.

3.1. Define tres caducidades mínimas (recomendación práctica)

(1) Caducidad de la evaluación (TIA/TRA):

• Alta criticidad: 6 meses
• Media: 12 meses
• Baja: 18–24 meses

(2) Caducidad de la evidencia técnica (pre/post/reject):

• Alta: 1 mes (o por release)
• Media: trimestral
• Baja: semestral

(3) Caducidad del inventario de terceros (endpoints/SDKs):

• Alta: mensual
• Media: trimestral
• Baja: semestral

Por qué es defendible: el EDPB, al hablar de medidas suplementarias, insiste en analizar el contexto de cada transferencia y en que la efectividad puede variar. Si cambia el contexto (proveedor, país, subencargados, activación, tipo de datos), tu evaluación pierde valor. (EDPB)

3.2. Regla de oro (simple)

Si cambia alguno de estos factores, se dispara revisión:

• país/región de tratamiento o soporte,
• subencargados,
• categorías de datos o finalidades,
• forma de activación (pre/post consent),
• medidas criptográficas o control de claves,
• tooling publicitario o tracking.

4) KRIs: indicadores que de verdad predicen incumplimiento

La mayoría de programas falla porque reporta “cumple/no cumple”. Los KRIs sirven para anticipar.

4.1. KRIs técnicos (web/app)

• KRI-1: Nº de llamadas a terceros pre-consent detectadas (cuando aplica).
• KRI-2: Nº de endpoints detectados no inventariados (diferencia entre “observado” vs “registrado”).
• KRI-3: Nº de vendors “fantasma” (la CMP declara X, el tráfico muestra Y).
• KRI-4: Nº de cambios en GTM/CMP sin evidencia asociada (HAR + capturas + versión).
• KRI-5: Nº de SDKs en app sin ficha TPRM/transferencias.

4.2. KRIs de transferencias/TPRM

• KRI-6: % de proveedores con transferencia con TIA/TRA vencida.
• KRI-7: % de proveedores con subencargados sin control (sin registro, sin notificación, sin evaluación).
• KRI-8: % de flujos sin medida complementaria “efectiva” (p. ej., cifrado sin control de claves).

4.3. KRIs de gobernanza

• KRI-9: tiempo medio de remediación de hallazgos críticos.
• KRI-10: Nº de excepciones abiertas (y su antigüedad).

Consejo operativo: define umbrales (verde/ámbar/rojo) y exige “acción correctiva” cuando se alcanza ámbar por dos periodos o rojo una vez.

5) Change control: el control que evita que el cumplimiento se rompa “por accidente”

El cumplimiento en web/app se rompe en el flujo de releases. Por eso, tu change control tiene que incluir checks específicos de terceros/transferencias.

5.1. “Checklist de cambio” (para cualquier release con impacto web/app)

Bloque A — Qué cambia

• Se añade/modifica tag, pixel, SDK, CDN/WAF, fuente externa, widget, analítica, A/B testing.

Bloque B — Riesgo/transferencias

• ¿Hay destino fuera del EEE / acceso remoto / soporte global?
• ¿Cambia el mecanismo (adecuación/SCC/etc.) o la necesidad de TIA/TRA?

Bloque C — Medidas complementarias

• Cifrado + control de claves / seudonimización / minimización / split processing (según caso).
• Alineación con Recomendaciones EDPB 01/2020 y garantías esenciales 02/2020 cuando el riesgo se relaciona con vigilancia/acceso. (EDPB)

Bloque D — Evidencias post-implementación obligatorias

• HAR pre / accept / reject
• Capturas CMP (vendors/finalidades)
• Export/versionado GTM (o equivalente)
• Actualización del inventario (endpoints/SDKs)
• Si aplica: actualización TIA/TRA y anexos

5.2. “Regla de bloqueo”

Si no hay evidencia post-implementación, el cambio no se da por cerrado (y si es crítico, se revierte).

6) Auditoría trimestral: método, muestreo y evidencias repetibles

Aquí no buscamos “pillarte”. Buscamos confirmar control y detectar deriva.

6.1. Alcance y muestreo recomendado (web)

• Top páginas por tráfico: home, pricing, checkout, login, formularios.
• Landings de campañas (donde suele colarse AdTech).
• Páginas con embeds (maps, vídeos, widgets).
• Flujos críticos (registro/compra/soporte).

6.2. Pruebas (test cases) que deberían ser fijas

1. Pre-consent: no dispara lo no necesario.
2. Reject funciona de verdad (equivalencia práctica).
3. Persistencia de elección (sesión/páginas).
4. Coherencia CMP vs tráfico real.
5. Inventario actualizado (observado ↔ registrado).
6. Transferencias: evidencia de mecanismo + TIA/TRA vigente + medidas.

6.3. Herramientas para evidencia repetible

• EDPB Website Auditing Tool (preparar, ejecutar, evaluar y reportar auditorías de sitios). (EDPB)
• Recolectores de evidencia compatibles (p. ej., Website Evidence Collector del entorno EDPS) para automatizar recogida. (GitLab)

7) Integración con TIA/TRA: cómo “operacionalizar” la evaluación

La evaluación no debe vivir en un PDF. Debe vivir en un sistema con estado.

7.1. Estructura mínima por proveedor (estado auditable)

• Estado TIA/TRA: vigente / por vencer / vencida
• Medidas: definidas / implementadas / verificadas (con fecha)
• Evidencia técnica: último HAR / último reporte de auditoría
• Cambios: últimos 90 días (tags/SDKs/endpoints)
• Riesgo: score + decisión (aceptar/remediar/bloquear)

El ICO proporciona una guía muy concreta sobre el contenido y finalidad de la TRA (y su enfoque de cumplimiento), útil como referencia para estructurar y mantener el proceso. (ico.org.uk)
Como metodología práctica UE, la CNIL publicó una guía final de TIA y una plantilla para documentarlo. (cnil.fr)

8) Caso especial: solicitudes de autoridades de terceros países (Art. 48 RGPD)

Si trabajas con cloud y soporte global, necesitas un “procedimiento de Art. 48” y evidencias mínimas.

El EDPB publicó la versión final de las Guidelines 02/2024 sobre el Art. 48 RGPD (junio 2025), que te sirve como referencia de cómo tratar transferencias/divulgaciones no autorizadas por derecho de la UE. (EDPB)

Mínimo operativo:

• cláusulas de notificación y challenge cuando sea posible,
• registro de solicitudes (aunque sea “0 solicitudes”),
• RACI: quién decide y quién documenta,
• evidencias de revisión periódica.

9) Qué presentar al Comité GRC (el “dashboard” que sirve)

Un comité no necesita HARs. Necesita control y decisiones.

Paquete trimestral (recomendado)

• Mapa de riesgo (top 10 proveedores/servicios por criticidad).
• KRIs (tendencia vs umbral).
• TIAs/TRAs por vencer (lista + plan).
• Hallazgos críticos (pre-consent, vendors fantasma, endpoints no inventariados).
• Decisiones: aceptar riesgo / remediar / bloquear / cambiar proveedor.
• Plan de remediación: responsables + fechas.

10) Cierre: lo profesional es “sistema”, no “documento”

El cumplimiento sostenible en web/app se logra cuando conectas:

TIA/TRA + medidas + evidencias técnicas + control de cambios + KRIs + auditoría trimestral + comité.

Ese es el estándar defendible: no porque suene bien, sino porque es lo único que aguanta la realidad de un stack cambiante.

Bibliografía y recursos (selección esencial)

• EDPB — Recommendations 01/2020 (v2.0) medidas suplementarias. (EDPB)
• EDPB — Recommendations 02/2020 garantías esenciales europeas (vigilancia/medidas de terceros países). (EDPB)
• AEPD — Garantías para transferencias (actualizada 30/01/2026). (Agencia Española de Protección de Datos)
• ICO — Completing a TRA (actualizada 15/01/2026). (ico.org.uk)
• CNIL — Practical guide TIA + template. (cnil.fr)
• EDPB — Website Auditing Tool (29/01/2024) + compatibilidad con collector. (EDPB)
• EDPB — Guidelines 02/2024 Art. 48 (final). (EDPB)