Pack final para tener tu web/app “lista para inspección/auditoría”- Roadmap 90 días / 6 meses / 12 meses + checklist de evidencias + reporting a Comité GRC

Si has llegado hasta aquí, ya sabes lo esencial: tu web y tu app no son “una página”, son un ecosistema de terceros. Y el cumplimiento real no se gana con un banner bonito ni con un PDF de SCCs archivado. Se gana con algo más simple (y más duro): poder demostrar control.

Este último post es un “pack” para que lo puedas ejecutar, repartir responsabilidades, medir avances y, sobre todo, tener evidencias sin improvisar cuando toque auditoría o inspección.

La promesa de este cierre: si haces el plan de 90 días, tendrás un expediente que se entiende, se sostiene y se puede enseñar.

1) Qué significa “lista para inspección”

Estar “listo” no es tener todo perfecto. Es poder responder con orden a 5 preguntas:

1. Qué terceros tratan datos en tu web/app (y cómo se activan).

2. Qué sale del EEE (o qué puede ser accesible desde fuera) y con qué mecanismo.

3. Qué decisiones has tomado (aceptar, bloquear, sustituir, mitigar).

4. Qué controles tienes en marcha para que no se rompa con cada cambio.

5. Qué evidencias lo prueban (y dónde están).

Ese es el estándar.

2) Estructura del “expediente único” (la carpeta que te salva)

Antes del roadmap, define un único sitio donde vive todo. No 20 carpetas.

Carpeta 00 — “Índice y mapa”

• Índice del expediente (1 página)

• Alcance (dominios/apps incluidos)

• Lista corta de “sistemas críticos” (checkout, login, formularios, campañas, etc.)

• Contactos y RACI (quién responde)

Carpeta 01 — “Inventario real de terceros”

• Registro de terceros Web/App (endpoints/SDKs, proveedor, finalidad, activación)

• Lista “observado vs registrado” (lo que aparece en tráfico y no está en inventario)

Carpeta 02 — “Consentimiento y activación”

• Configuración CMP (vendors, finalidades, screenshots, versión)

• Evidencias HAR (pre / accept / reject) por páginas clave

• Evidencia de control de tags (export/versionado del contenedor)

Carpeta 03 — “TPRM + transferencias”

Por proveedor crítico:

• Contrato + DPA

• Subencargados (y registro de cambios)

• Mecanismo (adecuación/SCC/etc.)

• TIA/TRA (si aplica) + medidas complementarias

• Evidencias: cifrado/keys/masking/minimización/logs (según el caso)

Carpeta 04 — “Operación continua”

• Política de caducidades (TIA/TRA, inventario, evidencias)

• KRIs y umbrales

• Plan de auditoría trimestral (muestras, pruebas, reportes)

• Control de cambios (tickets y evidencias post-implementación)

• Registro de excepciones y aceptación de riesgo

Carpeta 05 — “Comité GRC”

• Dashboard trimestral (KRIs + decisiones + planes)

• Actas o minutas (qué se decidió y por qué)

Clave: si esta estructura existe, el resto del trabajo se ordena solo.

3) Roadmap práctico (90 días / 6 meses / 12 meses)

A) Roadmap 90 días — “Expediente mínimo defendible”

Objetivo: dejar de improvisar. Tener lo esencial y que sea coherente.

Semana 1–2: “Saber qué tienes de verdad”

Entregables

1. Inventario inicial de terceros (web + app si aplica) a nivel endpoint/SDK

2. “Top 10 páginas/flujos” por riesgo: home, landings, login, checkout, formularios, soporte

3. Primera foto del “ecosistema”: proveedores críticos (analítica/replay, ads/pixels, CDN/WAF, chat, pago, antifraude, mapas, fuentes, A/B)

Cómo hacerlo (práctico)

• Levanta HAR en 3 escenarios por página: pre, aceptar, rechazar

• Completa inventario “observado” con dominios/endpoints del HAR

• Mapea cada endpoint a proveedor y finalidad

Lo que suele pasar aquí: salen “terceros invisibles” (CDN, tags de campañas, embeds). Perfecto: eso era el objetivo.

Semana 3–4: “Consentimiento que funciona y se puede probar”

Entregables

1. Configuración CMP documentada (vendors/finalidades/versiones)

2. Evidencia de funcionamiento real (HAR + cookies)

3. “Regla de oro” de activación: qué está permitido pre-consent y qué no

Checklist de verificación

• ¿Rechazar es tan visible y fácil como aceptar?

• ¿Rechazar evita llamadas a terceros no necesarios (cuando aplica)?

• ¿La elección se respeta en todas las páginas?

Semana 5–6: “Transferencias y TPRM por lo menos para lo crítico”

Entregables

1. Lista de proveedores con posible salida del EEE o acceso remoto

2. Para los 5–10 proveedores críticos:

   • contrato/DPA

   • subencargados

   • mecanismo

   • TIA/TRA (si aplica)

   • medidas y evidencias (mínimas)

Cómo priorizar sin ahogarte

• Prioriza por: volumen de usuarios + criticidad del flujo + sensibilidad + perfilado/marketing

Semana 7–8: “Medidas complementarias y evidencias mínimas”

No intentes “blindarlo todo”. Elige medidas que puedas demostrar.

Entregables (por proveedor crítico)

• Qué medida aplicas (cifrado/keys, seudonimización, minimización, masking…)

• Dónde está documentado

• Dónde está la evidencia (config/log/test)

Semana 9–10: “Control de cambios”

Aquí se gana el mantenimiento.

Entregables

• Checklist de cambio (si toca tags/CMP/SDKs/CDN/analítica → evidencias obligatorias)

• Regla: “sin evidencia post-implementación no se cierra el ticket”

• Registro de cambios de GTM/CMP (versionado)

Semana 11–12: “Primer reporte a Comité GRC”

Entregables

• Top riesgos y hallazgos

• KRIs iniciales (aunque sean 6)

• Decisiones: bloquear / mitigar / aceptar / reemplazar

• Plan de remediación con fechas y responsables

Resultado del día 90: tienes un expediente mínimo, con evidencias, y un sistema para que no muera.

B) Roadmap 6 meses — “De expediente mínimo a control estable”

Objetivo: pasar de “lo tengo” a “lo mantengo”.

Líneas de trabajo

1. Auditoría trimestral real (muestra + pruebas repetibles + reporte comparable)

2. Caducidades en serio (TIA/TRA y evidencias con semáforo)

3. TPRM ampliado (no solo top 10, sino top 20–30 por riesgo)

4. Mejoras en minimización (menos datos enviados, menos retención, menos vendors)

5. Registro de excepciones (y razones) para que no haya “cumplimiento de palabra”

Entregables

• Reporte trimestral #1 y #2

• Dashboard con tendencias

• Mejora del inventario (menos “observado no registrado”)

• Control de subencargados y cambios (alertas)

C) Roadmap 12 meses — “Madurez: menos riesgo, más gobernanza”

Objetivo: que el sistema funcione sin depender de una persona heroica.

Líneas de trabajo

1. Automatizar evidencia (tooling y rutinas)

2. Integrar con SDLC (privacy checks en releases)

3. Medir madurez por dominios (consent, terceros, transfers, evidencias, operación)

4. Revisión de proveedores: sustituir lo que no puedes gobernar

5. Preparar respuesta a escenarios difíciles (Art. 48 y requerimientos de autoridades, incidentes, etc.)

Entregables

• Programa anual (plan de auditoría)

• Revisión anual de proveedores críticos

• Informe de madurez y reducción de riesgo

• Pack listo para auditoría externa

4) Checklist final  — “¿Qué debo poder enseñar?”

Aquí tienes el “sí/no” que no falla.

A) Inventario

• Lista de terceros por endpoint/SDK (no solo marcas)

• Dueño interno asignado por tercero

• “Observado vs registrado” con plan para cerrar brechas

B) Consentimiento y activación

• CMP documentada (vendors/finalidades/versionado)

• Evidencia HAR pre / accept / reject por páginas clave

• Evidencia de que “rechazar” funciona (no solo UI)

C) Transferencias y mecanismos

• Lista de terceros con posible salida del EEE / acceso remoto

• Mecanismo definido por proveedor (adecuación/SCC/etc.)

• TIA/TRA vigente para los críticos (con fecha y responsable)

D) Medidas complementarias (con pruebas)

• Cifrado + quién controla claves (si aplica)

• Minimización (qué datos no enviamos)

• Masking en replay/analítica (si aplica)

• Logs y control de accesos (si aplica)

• Evidencia guardada (config/test/log)

E) TPRM y subencargados

• Contrato/DPA accesible

• Lista de subencargados y control de cambios

• Proceso de revisión y aprobación

F) Operación continua

• Caducidades y semáforo (TIA/TRA, inventario, evidencias)

• KRIs con umbrales y responsables

• Auditoría trimestral (método + resultados)

• Control de cambios (tickets + evidencias post-implementación)

G) Comité GRC

• Dashboard trimestral

• Registro de decisiones (aceptar / mitigar / bloquear)

• Plan de remediación con fechas

5) KRIs recomendados (pocos, buenos y accionables)

No midas 30 cosas. Mide 8–10 que te avisen temprano.

1. Nº de llamadas a terceros pre-consent (donde aplique)

2. Nº de endpoints/SDKs no inventariados detectados

3. % de proveedores críticos con TIA/TRA vencida o por vencer

4. Nº de cambios en GTM/CMP sin evidencia asociada

5. Nº de vendors declarados vs vendors observados (brecha)

6. Tiempo medio de remediación de hallazgos críticos

7. Nº de subencargados nuevos sin revisión documentada

8. Nº de excepciones abiertas y antigüedad

6) Lo que suele matar el programa (para evitarlo desde ya)

• “Lo llevamos en un excel personal” → debe ser repositorio compartido y gobernado.

• “Revisamos una vez al año” → en web/app, una vez al año es no revisar.

• “Cumple el proveedor” → el proveedor no responde por tu configuración, tu CMP o tus tags.

• “Tenemos TIA” → si no hay caducidad, muere.

• “Rechazar está” → si no hay evidencia, no existe.

7) Cierre de la Serie 1 y lo que viene ahora

Con este Post 9 cerramos la Serie 1 (TPRM/Transfers) con un objetivo claro: que puedas pasar de lectura a ejecución.

Series que vienen, ¡no te las pierdas!

• Serie 2 — Patrones oscuros y consentimiento real (cookies/CMP/UX + “lo que pasa en producción”)

• Serie 3 — Medición de audiencia y analítica privacy-friendly (configuración real, retención, exenciones, evidencias)

• Serie 4 — IA en front-office y decisiones automatizadas (chatbots, perfilado, Art. 22 y auditoría práctica)

• Serie 5 — Recolección indirecta (scraping, formularios, enriquecimiento, terceros)

• Serie 6 — Auditoría lista para inspección (metodología, muestreo, reporting, evidencias repetibles)