Tercerización de IT y responsabilidad por datos

La tercerización de IT (cloud, soporte, desarrollo, mesa de ayuda, ciberseguridad o BPO tecnológico) acelera operaciones, pero también expone la protección de datos a fallas de control, contratos incompletos y cadenas de subproveedores difíciles de auditar.

La duda más frecuente aparece cuando ocurre un incidente o una queja: si el proveedor accedía a datos personales, ¿quién es responsable por la seguridad, la legalidad del tratamiento, los derechos de las personas y la notificación ante autoridades? La respuesta suele depender de roles (responsable/encargado), instrucciones, evidencias y cláusulas operativas, no solo del “servicio” contratado.

Resumen operativo sobre la tercerización de IT

• Qué es: externalización de servicios tecnológicos que pueden implicar acceso, almacenamiento o tratamiento de datos personales.
• Cuándo surge el problema: migraciones a cloud, soporte 24/7, integraciones, automatización, outsourcing de seguridad o atención al cliente.
• Derecho principal involucrado: reglas de responsable/encargado, deber de seguridad, confidencialidad y base legal del tratamiento.
• Consecuencias de ignorarlo: incidentes, reclamaciones por derechos, sanciones administrativas y conflictos contractuales con el proveedor.
• Camino básico: inventario de tratamientos, contrato/DPA, controles técnicos y auditoría; ante conflicto, reclamación interna y vías administrativas/judiciales según el caso.

Entendiendo la tercerización de IT en la práctica

En outsourcing tecnológico, la clave no es solo “quién presta el servicio”, sino quién determina las finalidades y las decisiones esenciales del tratamiento. La entidad que define por qué y para qué se tratan datos suele actuar como responsable; el proveedor que trata datos por cuenta ajena suele ser encargado.

Los puntos de fricción aparecen cuando el proveedor usa herramientas propias, define estándares sin validación, subcontrata partes del servicio o reutiliza datos (por ejemplo, para analítica o mejora de producto) sin instrucción clara.

• Acceso: qué equipos/personas pueden ver datos y con qué permisos.
• Almacenamiento: dónde se alojan datos y copias, y por cuánto tiempo.
• Soporte: cómo se registran tickets, capturas, trazas y evidencias.
• Subproveedores: quiénes intervienen, en qué países y con qué controles.
• Salida: reversibilidad, portabilidad y borrado seguro al terminar el contrato.

Aspectos jurídicos y prácticos de la tercerización

En términos jurídicos, el contrato debe reflejar: objeto del tratamiento, instrucciones, confidencialidad, seguridad, subencargos, asistencia en derechos, y reglas sobre incidentes. Además, es habitual exigir evidencia de controles (auditorías, certificaciones, pruebas de restauración, reportes).

En lo práctico, la responsabilidad no se “traslada” por completo: la entidad que decide el tratamiento suele conservar deberes de diligencia, supervisión y accountability. El proveedor, por su parte, debe cumplir medidas adecuadas y actuar conforme instrucciones, documentando acciones.

• Requisitos contractuales típicos: DPA/anexo de tratamiento, subencargos autorizados, retorno/borrado, auditoría y cooperación.
• Plazos relevantes: tiempos de respuesta a incidentes, restauración, y atención a solicitudes de derechos.
• Criterios frecuentes de evaluación: proporcionalidad de medidas, segregación de entornos, y trazabilidad de accesos.

Diferencias importantes y caminos posibles en la contratación

Una diferencia relevante es entre encargo puro (el proveedor ejecuta instrucciones) y escenarios de cocontrol o definición compartida de medios esenciales (por ejemplo, plataformas con parámetros rígidos que condicionan decisiones). También varía el riesgo según se trate de infraestructura (IaaS), plataforma (PaaS), software (SaaS) o soporte con acceso.

• Camino 1: acuerdo contractual reforzado (DPA + anexos técnicos) y auditorías periódicas.
• Camino 2: reconfiguración del servicio (minimización de datos, seudonimización, acceso “just-in-time”).
• Camino 3: cambio de proveedor o internalización parcial cuando no hay garantías verificables.

Aplicación práctica de la tercerización en casos reales

La exposición suele aparecer en migraciones (movimiento de bases), en soporte (acceso remoto a entornos productivos), en integraciones (APIs con datos sensibles) y en centros de atención tercerizados (grabaciones, CRM y analítica).

Los más afectados suelen ser titulares de datos cuyos registros se encuentran en sistemas críticos (clientes, pacientes, usuarios, empleados). En auditorías o incidentes, suelen ser relevantes: contratos, anexos, registros de acceso, tickets, reportes de seguridad, inventario de subproveedores y evidencias de formación/confidencialidad.

1. Reunir documentación: contrato, DPA, anexos técnicos, lista de subencargos y mapa de datos.
2. Verificar controles: accesos, MFA, segregación, backups, cifrado y registros de auditoría.
3. Formalizar instrucciones: RACI, procedimiento de cambios, y protocolo de respuesta a incidentes.
4. Gestionar plazos: ventanas de notificación, respuesta a derechos y tiempos de restauración.
5. Revisar y escalar: auditoría, plan de remediación y, si aplica, reclamación administrativa/judicial.

Detalles técnicos y actualizaciones relevantes

En la práctica, las autoridades suelen exigir más evidencia y menos declaraciones generales. Se valoran anexos con controles verificables, reportes de auditoría, pruebas de continuidad, y trazas que permitan atribuir acciones (quién accedió, qué cambió, cuándo y por qué).

También se observa mayor atención a cadenas de subproveedores, a la minimización de accesos y a la gestión de transferencias internacionales cuando el servicio opera desde múltiples jurisdicciones o data centers.

• Puntos en discusión: acceso de soporte a datos sensibles, retención de backups y telemetría del proveedor.
• Controles que ganan peso: “least privilege”, segmentación, cifrado y monitoreo continuo.
• Gobernanza: revisiones periódicas del inventario de tratamientos y de subencargos autorizados.

Ejemplos prácticos de tercerización de IT

Ejemplo 1 (más detallado): una empresa migra su CRM a un servicio SaaS. El proveedor ofrece un “equipo de éxito” con acceso para resolver incidencias. Tras una queja, se descubre que tickets incluían capturas con datos personales y que había subencargos para soporte fuera de la jurisdicción principal. Se recopilan: contrato, DPA, listado de subencargos, registros de acceso, políticas de retención de tickets y evidencias de configuración de permisos. El encaminamiento típico incluye ajustar roles, limitar campos visibles en soporte, actualizar anexos sobre subencargos y establecer un protocolo de incidentes con tiempos de comunicación y preservación de evidencias, sin asumir un resultado único.

Ejemplo 2: un proveedor de mesa de ayuda usa una herramienta externa para registrar solicitudes, y se cargan datos excesivos en los tickets. El manejo habitual es definir plantillas de ticket con campos mínimos, reglas de redacción, control de adjuntos, y revisiones mensuales de accesos y registros.

Errores frecuentes en la tercerización

• Firmar contratos sin anexo de tratamiento y sin instrucciones operativas verificables.
• No controlar subencargos ni la ubicación/flujo de datos y copias.
• Accesos excesivos para soporte, sin MFA, sin segregación y sin trazabilidad.
• Falta de evidencia (logs, auditorías, reportes) ante incidentes o inspecciones.
• Retención indefinida de backups, tickets o grabaciones sin política y borrado seguro.
• Salida mal definida sin plan de reversibilidad, portabilidad y destrucción de datos.

FAQ sobre la tercerización

¿Cuándo un proveedor de IT se considera encargado del tratamiento?

Cuando trata datos personales por cuenta de otra entidad y siguiendo sus instrucciones. En ese escenario, el contrato debe especificar objeto, duración, medidas de seguridad, subencargos y cooperación para derechos e incidentes, con evidencia de cumplimiento.

¿Qué áreas suelen quedar más expuestas al externalizar IT?

Soporte con acceso remoto, servicios cloud con múltiples subproveedores, integraciones por API, centros de atención y herramientas de ticketing o analítica. La exposición aumenta si hay datos sensibles, privilegios elevados y falta de registros de auditoría.

¿Qué documentación suele ser clave si hay un incidente o una negativa del proveedor?

Contrato y DPA, anexos técnicos (SLA/RACI), listado de subencargos, registros de acceso y cambios, evidencias de medidas de seguridad, reportes de auditoría y el historial de comunicaciones sobre el incidente o la solicitud.

Fundamentación normativa y jurisprudencial

En marcos como el RGPD (UE) y leyes nacionales complementarias, la relación responsable–encargado exige que el tratamiento por terceros se sustente en un contrato u acto jurídico que delimite instrucciones, confidencialidad y medidas técnicas y organizativas. La responsabilidad se analiza conforme el rol real y el nivel de control y diligencia demostrable.

Como base práctica, suelen citarse obligaciones sobre seguridad, minimización, limitación de finalidad, responsabilidad proactiva y cooperación ante violaciones de seguridad. En disputas, la evaluación suele centrarse en si existieron controles razonables, auditoría efectiva, y si el proveedor actuó conforme instrucciones documentadas.

En términos de entendimiento predominante, cuando faltan anexos operativos o evidencias de supervisión, tiende a considerarse insuficiente la diligencia del responsable. Cuando el proveedor excede instrucciones o reutiliza datos, aumenta la probabilidad de imputación directa de incumplimientos, sin perjuicio de responsabilidades compartidas según el caso.

Consideraciones finales

La tercerización de IT no elimina deberes: exige definir roles, documentar instrucciones y mantener controles verificables. La prevención suele depender de anexos técnicos claros, gestión de subencargos, trazabilidad y un plan realista de respuesta a incidentes.

En la práctica, la reducción de exposición se apoya en documentación consistente, revisiones periódicas, y medidas de acceso y retención proporcionales. La ausencia de evidencia suele ser el punto que más debilita la defensa ante auditorías, reclamos o incidentes.

Este contenido tiene carácter meramente informativo y no sustituye el análisis individualizado del caso concreto por abogado o profesional habilitado.