GRC, vendor management o plataforma RGPD
La decisión no es “Excel o software”: puede combinar sistemas maestros, especialistas y una capa que coordine terceros y excepciones.
Mapa de alternativas
GRC/privacy management para registro; procurement para contratos; trust centers para evidencia; ticketing para incidencias; plataforma para solicitudes, cambios y aprobaciones. Cada opción cubre una parte distinta y debe evaluarse por operación completa, no por número de funciones.
Cuándo basta una hoja
Una hoja puede servir para probar este caso: una empresa contrata un SaaS europeo con infraestructura, soporte y analítica prestados por tres subencargados. Debe relacionar proveedor · servicio · tratamiento · finalidad · datos · interesados · rol · DPA · instrucción · medida · región · subencargado · país · transferencia · incidente · retención · borrado · revisión. Si aparece esta incidencia —el proveedor añade un subencargado fuera del EEE y una función de IA sin actualizar ubicación, finalidad ni contrato—, comprueba si permite asignar la corrección, conservar versiones y preparar registro de tratamientos y proveedores, DPA vinculados, evidencias, cadena de subencargados, decisiones de transferencia, revisiones, incidentes y cierre probado; si ese seguimiento depende de correos separados, el piloto necesita otra forma de coordinación.
Sistemas internos
El sistema maestro aporta identidad, compras, lotes o activos. Valora cuánto esfuerzo requiere pedir información externa, interpretar archivos, gestionar cambios y conservar decisiones.
Especialistas y consultoría
Aportan método y criterio. Define transferencia, propiedad de datos, actualización, tiempo de respuesta y cómo seguirá funcionando el proceso entre revisiones.
Criterios de elección
Mide volumen, terceros, variabilidad, excepciones, coste de error, plazos, mercados, integraciones, auditoría y salida. Prueba específicamente: el proveedor añade un subencargado fuera del EEE y una función de IA sin actualizar ubicación, finalidad ni contrato.
Mapa operativo específico de RGPD y proveedores
Para esta decisión sobre comparación de alternativas, el modelo debe relacionar proveedor · servicio · tratamiento · finalidad · datos · interesados · rol · DPA · instrucción · medida · región · subencargado · país · transferencia · incidente · retención · borrado · revisión. Los participantes reales son responsable, encargado, corresponsable, subencargado, DPO, seguridad, compras, legal, propietario del tratamiento y autoridad. La salida verificable es registro de tratamientos y proveedores, DPA vinculados, evidencias, cadena de subencargados, decisiones de transferencia, revisiones, incidentes y cierre probado.
Prueba de estrés antes de aprobar
Reproduce este escenario: una empresa contrata un SaaS europeo con infraestructura, soporte y analítica prestados por tres subencargados. Introduce deliberadamente la excepción “el proveedor añade un subencargado fuera del EEE y una función de IA sin actualizar ubicación, finalidad ni contrato”. Comprueba qué sistema la detecta, quién recibe la tarea, qué fuente resuelve la duda y cómo queda registrada la aprobación.
La herramienta organiza; el responsable decide
El expediente debe conservar dato, fuente, versión, control, excepción y aprobación. Code Contract puede coordinar la operación, pero no sustituye la evaluación técnica, la declaración oficial ni al supervisor.