El RGPD para equipos de TI y proveedores de servicios gestionados (MSP): lo que hay que saber y hacer

La aplicación del RGPD ya no es un riesgo teórico. Las autoridades europeas de protección de datos impusieron multas por más de 1200 millones de euros solo en 2025, y la categoría de infracción más común fueron las medidas de seguridad técnicas y organizativas insuficientes, precisamente lo que el Artículo 32 del reglamento exige implementar a los equipos de TI y MSP. El total acumulado de multas desde 2018 ya supera los 7100 millones de euros, según el análisis del Rastreador de Aplicación del RGPD publicado a principios de 2026.

Para los profesionales de TI y MSP que atienden a clientes en la UE o el Reino Unido, el RGPD es un requisito operativo que se enmarca directamente en la gestión de TI, y no meramente en una función legal o de cumplimiento. La plataforma de Kaseya es utilizada por más de 50 000 MSP y equipos de TI en todo el mundo, muchos de los cuales gestionan exactamente estas obligaciones para múltiples clientes de forma simultánea, y esta guía se apoya en esa profundidad operativa para abordar lo que realmente importa en la práctica.

Esta guía se centra en los requisitos de seguridad técnicos y organizativos, las obligaciones de notificación de brechas y los roles de procesamiento de datos que convierten al RGPD en un asunto fundamental de gestión de TI.

Documente el cumplimiento del RGPD en cada cliente.

Compliance Manager GRC incluye un marco normativo para el RGPD con mapeo de controles, recopilación automatizada de evidencias y documentación lista para auditorías, lo que ayuda a los MSP a demostrar el cumplimiento de los requisitos de seguridad del Artículo 32 y más allá.

Explora Compliance Manager GRC

Qué es el RGPD y a quién se aplica

El Reglamento General de Protección de Datos (UE 2016/679) regula cómo se recopilan, procesan, almacenan y transfieren los datos personales de las personas en la UE y el Espacio Económico Europeo (EEE). El RGPD del Reino Unido, mantenido y adaptado tras el Brexit, aplica un conjunto de requisitos casi equivalentes para el procesamiento en territorio británico, con la ICO como autoridad de control.

Los datos personales según el RGPD son más amplios de lo que la mayoría de los equipos de TI suponen en un principio. Las direcciones IP, los identificadores de dispositivos, las direcciones de correo electrónico y los registros técnicos pueden constituir datos personales si se pueden vincular a un individuo. El reglamento se aplica a cualquier operación realizada sobre dichos datos, incluyendo la recolección, el almacenamiento, la recuperación, el uso, la transmisión y la supresión.

El RGPD se aplica a las organizaciones establecidas en la UE/EEE sin importar dónde se encuentren los interesados, así como a las organizaciones fuera de la UE/EEE que ofrezcan bienes o servicios a personas en la UE/EEE o supervisen su comportamiento. No existe un umbral de tamaño mínimo. Un negocio unipersonal que procese datos personales de ciudadanos de la UE tiene las mismas obligaciones que una multinacional.

Para las empresas de tecnología B2B, los proveedores de SaaS y los MSP con clientes en la UE o el Reino Unido, el RGPD resulta prácticamente de aplicación obligatoria.

Artículo 32: el requisito de seguridad de TI en el núcleo del RGPD

El Artículo 32 es el punto donde el RGPD se convierte en un requisito de gestión de TI. Establece la obligación de que los responsables y encargados del tratamiento implementen medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo. El reglamento especifica cuatro categorías de capacidades:

Seudonimización y cifrado. Los datos personales deben protegerse tanto en reposo como en tránsito. Su implementación práctica consiste en el cifrado en el extremo y a nivel de respaldo, combinado con controles de acceso que restrinjan quién puede visualizar los datos no cifrados.

Confidencialidad, integridad, disponibilidad y resiliencia. Los sistemas de procesamiento deben ser capaces de mantener estas propiedades de forma continuada. Esto se alinea directamente con la detección y respuesta en los endpoints (EDR) para la confidencialidad y la integridad, así como con el respaldo y la recuperación ante desastres para la disponibilidad y la resiliencia. No se trata de productos de seguridad independientes añadidos a un programa de cumplimiento del RGPD; son el programa de cumplimiento del RGPD.

Restauración rápida de la disponibilidad. Tras un incidente físico o técnico, las organizaciones deben poder restablecer el acceso a los datos personales de manera oportuna. El objetivo de tiempo de recuperación (RTO) es un requisito del RGPD, no meramente una preferencia operativa. Un MSP que gestione datos de clientes y no pueda demostrar una recuperación rápida y probada a partir de respaldos incumple el Artículo 32.

Pruebas y evaluación regulares. La eficacia de las medidas de seguridad debe probarse, evaluarse y valorarse con regularidad. El cumplimiento no es un estado estático. Requiere evaluaciones continuas, evidencias documentadas y un proceso para identificar y cerrar brechas.

La sanción impuesta en 2025 a Advanced Computer Software Group, un proveedor de TI multado con 3,07 millones de libras por la ICO del Reino Unido debido a fallos de seguridad que afectaron a los servicios del NHS, representó la primera multa emitida directamente contra un encargado del tratamiento en lugar de un responsable. La ICO determinó que la empresa no había implementado las medidas técnicas adecuadas contempladas en el Artículo 32, citando deficiencias específicas en la implementación de MFA, el análisis de vulnerabilidades y la gestión de parches. Esto no es un riesgo abstracto para los MSP; sienta un claro precedente de que los proveedores de servicios de TI pueden asumir responsabilidad directa por fallos de seguridad en los sistemas que administran.

Una forma práctica de entender las obligaciones del Artículo 32 es la siguiente: si hoy no pudiera demostrar ante un auditor, con pruebas documentadas, que el cifrado está activo en todos los endpoints que procesan datos personales, que se han ejecutado y superado las pruebas de verificación de respaldos y que se han probado los procedimientos de respuesta a incidentes, tiene una brecha respecto al Artículo 32.

Notificación de violaciones de datos: la regla de las 72 horas

El Artículo 33 exige que los responsables del tratamiento de datos notifiquen a su autoridad de control en un plazo máximo de 72 horas tras tener conocimiento de una violación de datos personales, a menos que sea improbable que dicha violación entrañe un riesgo para los derechos y libertades de las personas físicas. La autoridad de control en el Reino Unido es la ICO. En los estados miembros de la UE, es la autoridad nacional de protección de datos correspondiente.

El contador de las 72 horas comienza cuando la organización tiene un grado razonable de certeza de que un incidente de seguridad ha comprometido datos personales. Esto no ocurre al finalizar la investigación, sino en el momento en que se toma conciencia de que los datos personales pueden haberse visto afectados. El RGPD permite explícitamente la notificación por fases: una notificación inicial con la información disponible, seguida de actualizaciones a medida que la investigación arroje más detalles.

El Artículo 34 añade la obligación independiente de notificar directamente a los afectados cuando sea probable que la violación entrañe un alto riesgo para sus derechos y libertades. Los datos de salud, los datos financieros, los documentos de identidad y los datos de menores son categorías en las que se suele superar este umbral.

La implicación operativa para los equipos de TI y los MSPs es clara: contar con una capacidad de detección de brechas lo suficientemente rápida como para identificar y confirmar un incidente en cuestión de horas desde que se produce es un requisito del RGPD. La fatiga por alertas, las rutas de escalamiento lentas y los procedimientos poco claros de respuesta a incidentes se traducen en infracciones del plazo de 72 horas. Un proceso de respuesta a incidentes de seguridad bien gestionado considera que el contador empieza a correr en la detección, no al concluir la investigación.

Los encargados del tratamiento tienen una obligación paralela. Los MSPs que actúan como encargados del tratamiento deben notificar al responsable sin dilación indebida tras tener conocimiento de una brecha. A su vez, el responsable notifica a la autoridad de control dentro del plazo de 72 horas. Si un MSP descubre una brecha que afecta a los datos de un cliente un viernes por la noche y no se lo comunica al cliente hasta el lunes por la mañana, ese retraso puede hacer que el responsable incumpla el plazo legal.

Protección de datos desde el diseño y por defecto

El Artículo 25 exige que los controles de privacidad se integren en los sistemas desde el inicio, y no que se implementen como un añadido tras su despliegue.

La protección de datos desde el diseño significa que, al adquirir, configurar o desarrollar sistemas, los requisitos de privacidad formen parte de las especificaciones técnicas. Los controles de acceso, el cifrado y la minimización de datos son decisiones de arquitectura, no complementos posteriores. Para los equipos de TI que evalúan nuevas herramientas, una evaluación de impacto de la privacidad es parte del proceso, no un paso posterior.

La protección de datos por defecto significa que la configuración predeterminada debe ser la opción que garantice un mayor nivel de privacidad. Si un sistema puede recopilar menos datos, compartir menos datos o proporcionar un acceso más limitado, la opción predeterminada debe priorizar la privacidad. Los usuarios deben tener que activar explícitamente una recopilación de datos más amplia, en lugar de tener que excluirse de ella.

Las Evaluaciones de Impacto Relativas a la Protección de Datos (EIPD) son obligatorias antes de realizar cualquier tratamiento que pueda entrañar un alto riesgo, como decisiones automatizadas, monitorización sistemática a gran escala, tratamiento a gran escala de categorías especiales de datos y análisis de comportamiento. Para los equipos de TI, los factores desencadenantes incluyen herramientas de monitorización basadas en inteligencia artificial, plataformas de análisis del comportamiento del usuario y sistemas de acceso biométrico. Una EIPD no es opcional para estas categorías; es un requisito previo legal.

El RGPD para MSPs: responsable frente a encargado del tratamiento

Comprender los roles según el RGPD es uno de los aspectos más importantes a nivel práctico para los MSPs.

Un responsable del tratamiento determina los fines y los medios del tratamiento de los datos personales. El cliente del MSP suele ser el responsable de los datos de sus propios clientes, de los datos de sus empleados y de cualquier otro dato personal que procese su empresa.

Un encargado del tratamiento procesa datos personales por cuenta del responsable. Un MSP que gestiona sistemas de TI con datos personales, proporciona servicios de correo electrónico, aloja datos o presta servicios de respaldo y recuperación para los entornos de sus clientes actúa, en la mayoría de los casos, como encargado del tratamiento de los datos de dicho cliente.

Las obligaciones del encargado del tratamiento según el RGPD incluyen:

• Tratar los datos únicamente siguiendo las instrucciones documentadas del responsable.
• Implementar medidas de seguridad técnicas y organizativas adecuadas (Artículo 32).
• Notificar al responsable sin dilación indebida tras tener conocimiento de una violación de datos.
• Suprimir o devolver todos los datos personales una vez finalizado el contrato de servicio.
• Permitir y contribuir a las auditorías realizadas por el responsable.

Un mismo MSP puede actuar como responsable del tratamiento respecto a ciertos datos (los datos de sus propios empleados, los datos de sus relaciones con clientes) y como encargado respecto a otros (los datos personales de los clientes que gestiona como parte de la prestación del servicio). Ambos conjuntos de obligaciones se aplican de forma simultánea.

Los subencargados constituyen un nivel adicional. Cuando un MSP utiliza proveedores en la nube, proveedores de copias de seguridad u otros servicios para prestar servicios de TI a sus clientes, dichos terceros pueden convertirse en subencargados de los datos personales del cliente. Los acuerdos con subencargados deben ser comunicados y autorizados por el responsable del tratamiento. Los subencargados deben cumplir con estándares de seguridad equivalentes a los exigidos al encargado principal.

Acuerdos de Encargo de Tratamiento (DPA): lo que los MSPs deben tener implementado

Un acuerdo de procesamiento de datos (DPA, por sus siglas en inglés) es un contrato legalmente obligatorio entre el responsable del tratamiento y el encargado del tratamiento. Todo MSP que gestione datos personales de clientes de la UE o el Reino Unido debe contar con un DPA firmado con cada uno de dichos clientes. Esto no es opcional ni un mero trámite comercial, sino un requisito del RGPD establecido en su artículo 28.

Un DPA debe contemplar, como mínimo:

• El objeto, la duración, la naturaleza y la finalidad del tratamiento
• El tipo de datos personales y las categorías de interesados
• Las instrucciones documentadas del responsable dirigidas al encargado
• Las medidas de seguridad que implementará el encargado (obligaciones del artículo 32)
• El procedimiento de notificación de brechas de seguridad del encargado al responsable
• La subcontratación de tratamientos y el requisito de ofrecer una protección equivalente
• Las obligaciones del encargado al finalizar el contrato: supresión o devolución de los datos
• Los derechos de auditoría del responsable

Para un MSP que gestiona múltiples clientes, disponer de condiciones de DPA estandarizadas y listas para su implementación es un requisito comercial previo, no una carga administrativa. Los MSP que operan sin un DPA no cumplen con la normativa como encargados del tratamiento, por muy sólida que sea su postura técnica en materia de seguridad. Además, el DPA es el documento en el que los clientes evalúan las prácticas de seguridad del MSP antes de formalizar la relación comercial. Para los clientes del mercado medio y grandes empresas con sus propios programas de cumplimiento del RGPD, un DPA claro y bien redactado es cada vez más una condición contractual indispensable.

Compliance Manager GRC respalda la evaluación del cumplimiento del RGPD y la documentación de evidencias en los controles del artículo 32, ofreciendo a los MSP una manera estructurada de demostrar y mantener las medidas de seguridad a las que se comprometen en sus DPA. Descubra cómo respalda los programas de cumplimiento.

Las sanciones y su significado para los proveedores de servicios de TI

El régimen sancionador del RGPD es de sobra conocido: hasta 20 millones de euros o el 4 % de la cifra de negocio anual global para las infracciones más graves, y hasta 10 millones de euros o el 2 % para los incumplimientos de carácter procedimental, lo que incluye medidas de seguridad inadecuadas y retrasos en la notificación de brechas.

La realidad de la aplicación de la ley en 2025 y 2026 demuestra que las deficiencias de seguridad del artículo 32 son la causa más frecuente de multas por número de expedientes, más allá de los titulares generados por las sanciones a grandes tecnológicas. La CNIL francesa impuso a Free Mobile una multa de 27 millones de euros en enero de 2026 debido a unas medidas de seguridad insuficientes tras una brecha de datos. Por su parte, la ICO británica sancionó a Advanced Computer Software Group con 3,07 millones de libras en marzo de 2025 por esas mismas infracciones del artículo 32, entre las que se incluían deficiencias en el MFA, en el análisis de vulnerabilidades y en la gestión de parches. España e Italia han mantenido una actividad constante en la imposición de multas a proveedores sanitarios, empresas de servicios financieros y compañías de ámbito regional.

Las autoridades de control también han confirmado que la labor inspectora no se limita a las grandes organizaciones. El análisis de los datos de seguimiento de sanciones revela que un porcentaje significativo de todas las multas impuestas recae sobre proveedores de servicios regionales, pequeñas empresas de SaaS y agencias locales. Aunque las sanciones sean proporcionalmente menores, siguen siendo multas.

Para los MSP, el panorama sancionador se traduce en tres riesgos específicos: la responsabilidad directa como encargados del tratamiento ante fallos de seguridad amparados en el artículo 32, la responsabilidad frente a los clientes por retrasos en las notificaciones de brechas que provoquen que el responsable incumpla el plazo de 72 horas, y la exposición comercial derivada de carecer por completo de contratos DPA.

El cumplimiento del RGPD constituye asimismo un requisito comercial, y no solo normativo. Los clientes del mercado medio y las grandes empresas con operaciones en la UE y el Reino Unido exigen de manera rutinaria pruebas de cumplimiento del RGPD como parte de la evaluación de proveedores y la renovación de contratos. Un MSP que no pueda aportar controles de seguridad documentados, procedimientos de respuesta a incidentes probados y un DPA firmado pierde competitividad en ese segmento de mercado.

Si desea profundizar en cómo se relacionan los requisitos de gobernanza de datos con el RGPD, la HIPAA y otros marcos que los MSP deben gestionar para sus clientes, consulte nuestra guía sobre gobernanza de datos para equipos de TI y MSP.

Puntos clave

• El artículo 32 exige de forma directa cifrado, disponibilidad, resiliencia y pruebas de seguridad periódicas. Se trata de requisitos de gestión de TI, no de cuestiones jurídicas. Las herramientas que los garantizan —como EDR, copias de seguridad y recuperación, y gestión de endpoints— conforman en sí mismas el programa de cumplimiento del RGPD.
• El requisito de notificar las brechas de seguridad en un plazo de 72 horas exige una capacidad de detección lo suficientemente rápida como para identificar los incidentes notificables en cuestión de horas, no de días. Los encargados del tratamiento deben avisar a los responsables sin dilación indebida, y ese tiempo de demora computa dentro del plazo de 72 horas del responsable.
• Los MSP que actúan como encargados del tratamiento deben formalizar acuerdos de procesamiento de datos con todos sus clientes de la UE y el Reino Unido. De lo contrario, el MSP incumple la normativa en su calidad de encargado, con independencia de su nivel de seguridad técnica.
• La protección de datos desde el diseño significa que los controles de privacidad se integran en la arquitectura de los sistemas y en los procesos de adquisición, en lugar de añadirse a posteriori. Los ajustes predeterminados deben priorizar la privacidad. Las evaluaciones de impacto relativas a la protección de datos (DPIA) son un requisito legal previo para los tratamientos de alto riesgo.
• La aplicación del RGPD a los proveedores de servicios de TI es una realidad tangible. La multa impuesta por la ICO en marzo de 2025 a Advanced Computer Software Group por infracciones del artículo 32 —incluyendo la ausencia de MFA y una gestión de parches deficiente— sienta un precedente directo en cuanto a la responsabilidad de los MSP.