Guías Guía

RGPD para tiendas PrestaShop: Lo que realmente necesitas

Guía práctica de GDPR para PrestaShop: consentimiento de cookies, políticas de privacidad, derechos de datos, retención, proveedores externos y checklist.

No es asesoramiento legal. Somos una empresa de módulos para PrestaShop con sede en la UE: el RGPD es el marco legal bajo el que trabajamos cada día. Pero los patrones técnicos que se describen a continuación son exactamente eso: técnicos. La redacción de su DPA, su Registro de Actividades de Tratamiento, la notificación de brechas y la decisión de si necesita un DPO son tareas para un abogado especializado en protección de datos de su jurisdicción. Trate esta página como el complemento, desde el lado del desarrollador, a esa conversación, no como un sustituto de ella.

Qué significa realmente "cumplir con el RGPD" (y lo que ningún módulo puede darle)

Hemos creado dos módulos en este ámbito (Cookies Revolution para el consentimiento, y un conjunto de herramientas de privacidad del cliente para la exportación y la supresión) y enviamos más de 150 módulos en total. Lo único que le diríamos a cada comerciante antes de comprar nada: el "pleno cumplimiento del RGPD" no es algo que un módulo pueda venderle. Un módulo cubre las cookies, el registro del consentimiento, la exportación de datos por parte del cliente, la eliminación de la cuenta y las purgas de retención. El RGPD también abarca los Acuerdos de Tratamiento de Datos con cada proveedor, un Registro de Actividades de Tratamiento, una respuesta documentada a las brechas, las decisiones sobre la base jurídica y (según su tamaño y lo que haga) un Delegado de Protección de Datos. La mayoría de esos elementos son papeleo y política, no PHP.

Formulario de registro de cuenta de PrestaShop con las casillas de consentimiento del RGPD (condiciones generales, política de privacidad y protección de datos del cliente) que recogen el consentimiento explícito e informan al cliente de su derecho de acceso a sus datos personales y de supresión de estos.

Así que cuando esta página dice "use un banner de consentimiento que realmente bloquee los scripts", eso es una solución técnica de verdad. Cuando dice "necesita un DPA con Stripe", eso sigue siendo responsabilidad suya, no del desarrollador de su módulo.

El principio que subyace a todo

Su cliente es el propietario de sus datos. Usted los conserva para gestionar el pedido. Esa única frase replantea la mayoría de los requisitos:

  • Diga a las personas qué recopila y por qué: sin seguimiento silencioso, sin píxeles de terceros ocultos
  • Recopile únicamente lo que el pedido necesita de verdad: la fecha de nacimiento no envía un paquete
  • Obtenga un consentimiento real y voluntario para todo lo que no sea estrictamente necesario
  • Permita que las personas vean, corrijan, exporten y eliminen su registro cuando lo soliciten
  • Proteja lo que conserva, y no lo conserve más tiempo del necesario

¿Se aplica el RGPD a su tienda?

Si envía a clientes de la UE o su sitio está disponible en un idioma de la UE, sí. El reglamento sigue al interesado, no a la empresa. Tenemos clientes con sede en EE. UU. que insistían en que el RGPD no se les aplicaba, hasta que llegó su primer pedido francés. Se aplicó a partir de ese pedido.

Deje de intentar buscar excusas. El trabajo de cumplimiento coincide casi por completo con la buena ingeniería: HTTPS, retención sensata, una UX de consentimiento decente, no recopilar basura que no necesita. De todos modos, iba a hacer la mayor parte de ello.

Qué se considera dato personal en una base de datos de PrestaShop

Cualquier cosa que pueda identificar a una persona directamente o en combinación con otros datos. Para una tienda eso significa: nombre, correo electrónico, teléfono, dirección, historial de pedidos, hash de la contraseña, IP, huella digital del navegador, registros de comportamiento y cookies. La trampa en la que cae la gente es "la IP no es un dato personal": lo es, en el momento en que se puede combinar con una marca de tiempo y una sesión.

Seis bases jurídicas, tres de las cuales usará realmente

El RGPD no le permite recopilar datos "porque puede". Necesita una de seis justificaciones. Para una tienda de comercio electrónico, tres de ellas soportan el 99% de la carga:

  • Contrato: para ejecutar el pedido. Dirección de envío, nombre, correo electrónico, datos de pago.
  • Consentimiento: boletines, marketing, cookies no esenciales. Debe ser una aceptación activa, granular y tan fácil de retirar como lo fue de dar.
  • Obligación legal: facturas, registros fiscales. Retención específica de cada país (normalmente de 7 a 10 años en toda la UE).

El "interés legítimo" se invoca para la prevención del fraude y los registros básicos de seguridad. Las otras dos (interés vital, interés público) casi nunca se aplican a una tienda.

Qué recopila realmente su tienda PrestaShop, y dónde reside

Antes de poder describir qué recopila, necesita saberlo. La mayoría de los comerciantes lo subestiman a la mitad. La auditoría que ejecutamos en cada tienda que incorporamos recorre cada categoría de tablas que figura a continuación.

Cuentas de cliente

ps_customer contiene el nombre, los apellidos, el correo electrónico, el hash de la contraseña, la fecha de nacimiento y el sexo opcionales, los indicadores de boletín y optin, la fecha de creación de la cuenta, el último inicio de sesión, la IP en el momento del registro y los campos B2B (empresa, SIRET/APE). La mayoría de las tiendas piden la fecha de nacimiento en el registro sin llegar a usarla nunca. Si no realiza campañas de cumpleaños, elimine el campo.

Pedidos y direcciones

Cada pedido escribe en ps_orders, ps_order_detail, ps_order_payment, ps_order_history, ps_address, ps_order_carrier y ps_message. ps_address por sí sola puede contener datos postales completos, dos números de teléfono, el nombre de la empresa, el número de IVA y un documento nacional de identidad (el campo dni, usado en España y en algunos otros países).

Invitados, conexiones, vistas de página: la tabla que crece sin que nadie lo note

Incluso los visitantes que nunca se registran dejan un rastro en ps_guest, ps_connections, ps_connections_source, ps_connections_page, ps_page y ps_page_viewed. En una tienda con un tráfico moderado hemos visto que ps_connections alcanza ocho cifras de filas en un año. La IP más el comportamiento de navegación son datos personales, y nadie nos ha dicho nunca "sí, conservo deliberadamente tres años de ellos". Simplemente se acumulan porque nada los borra.

Carritos

ps_cart recibe una fila en el momento en que un visitante deja algo en el carrito, tanto si finaliza la compra como si no. Vinculada a un cliente o a un invitado, con selecciones de productos, direcciones y marcas de tiempo. Los carritos abandonados que se vinculan a una persona real son datos personales. La mayoría de las tiendas nunca los depuran.

Boletín, cookies, registros del servidor, módulos de terceros

ps_emailsubscription (o ps_newsletter en tiendas más antiguas) contiene correos electrónicos, fechas de suscripción y, a veces, la IP. Las cookies propias de PrestaShop son funcionales (sesión, carrito, autenticación de administrador) y no requieren consentimiento. Las cookies que sí requieren consentimiento son las que dejan sus módulos de terceros: GA, Meta Pixel, Hotjar, widgets de chat, etiquetas de retargeting. Los registros de acceso de Apache/Nginx también son datos personales (IP + marcas de tiempo + URL). Audite cada módulo que crea sus propias tablas: reseñas, listas de deseos, chat en directo, fidelización, recuperación de carritos, módulos de analítica. Si no sabe qué tablas ha creado un módulo, no puede ser transparente sobre lo que recopila.

Abra phpMyAdmin, filtre la lista de tablas por el prefijo de su módulo y compruebe qué hay dentro. Hacemos esto en cada tienda que auditamos y siempre encuentra algo que el comerciante había olvidado que tenía instalado.

Consentimiento de cookies: donde la mayoría de las tiendas siguen equivocándose

Si auditamos una tienda al azar mañana, la infracción más probable que encontraremos es el consentimiento de cookies. O bien el banner es cosmético (se muestra, pero GA se carga igualmente), o las casillas están premarcadas, o no hay control granular. Esta es la parte que los reguladores miran primero porque es la más fácil de verificar con un inspector del navegador.

Qué exigen realmente la ePrivacy + el RGPD

  • Las cookies estrictamente necesarias (sesión, carrito, CSRF, autenticación de administrador) no requieren consentimiento
  • Todo lo demás (analítica, marketing, personalización, redes sociales) requiere una aceptación explícita antes de que se establezca la cookie o se ejecute el script
  • El consentimiento debe ser libre, específico (por categoría), informado y activo
  • Retirar el consentimiento debe ser tan fácil como darlo

Qué no es un consentimiento válido

  • "Al continuar navegando, acepta las cookies": el consentimiento implícito no es consentimiento
  • Un banner solo con "Aceptar": ninguna opción real
  • Casillas premarcadas: debe ser una aceptación, no una exclusión
  • Muros de cookies ("acepte o márchese"): la mayoría de los reguladores de la UE se han pronunciado en contra de ellos
  • Un banner que se muestra cuando los scripts ya se han ejecutado: puramente decorativo

Qué aspecto tiene una implementación que funciona

El patrón de etiqueta de script que realmente funciona:

<!-- En lugar de cargar Google Analytics directamente: -->
<script src="https://www.googletagmanager.com/gtag/js?id=GA_ID"></script>

<!-- Cárguelo de forma condicional según el consentimiento: -->
<script type="text/plain" data-cookieconsent="statistics">
  // Este script solo se ejecuta después de que el usuario consienta las cookies de estadísticas
  (function(){ /* código de GA aquí */ })();
</script>

type="text/plain" impide que el navegador lo ejecute. Tras el consentimiento, su gestor de consentimiento lo cambia a type="text/javascript" y lo ejecuta. Si su "banner de consentimiento" no hace esto (si puede ver _ga en las Herramientas de desarrollo antes de hacer clic en nada), está roto.

El problema de Google Analytics del que nadie habla con honestidad

Si implementa el consentimiento correctamente, una fracción significativa de los visitantes rechazará la analítica, y sus cifras de GA caerán. Ese es el resultado correcto. Los datos que solía tener se recopilaban sin base jurídica. Tres caminos honestos a seguir:

  • Mantener GA4 con un consentimiento adecuado y aceptar datos incompletos. Las tendencias siguen funcionando; las cifras absolutas, no.
  • Cambiar a Matomo o Plausible autoalojados, configurados para funcionar sin cookies identificativas. Algunos abogados aceptan que "no se necesita consentimiento" bajo el interés legítimo para estos: consulte con el suyo.
  • Usar el Modo de Consentimiento de GA4, que envía pings sin cookies en caso de rechazo y modela la diferencia. Un compromiso, no una solución.

El módulo oficial psgdpr frente a las CMP dedicadas

PrestaShop incluye psgdpr, que añade un banner de consentimiento, un flujo de exportación/supresión de datos orientado al cliente y un registro del consentimiento. Es un punto de partida razonable. No siempre bloquea las cookies de terceros antes del consentimiento (eso depende de cómo carguen los scripts su tema y sus módulos) y la UX del banner es básica. Para una tienda pequeña con GA y nada más, es suficiente. Para una tienda que ejecuta GA + Pixel + Hotjar + chat + retargeting + píxeles de afiliados, querrá o bien nuestro Cookies Revolution, o bien una CMP dedicada como Cookiebot o CookieYes.

Sea lo que sea lo que instale, pruébelo. Ventana de navegación privada, Herramientas de desarrollo abiertas en Aplicación → Cookies, recargue la página de inicio. Si _ga, _fbp o cualquier cookie de rastreador se establece antes de que haga clic en nada, la implementación no está cumpliendo su función.

Su política de privacidad

Esto es un documento legal. Las plantillas genéricas extraídas de internet fracasan porque describen una tienda que no es la suya. La suya tiene que nombrar a sus encargados del tratamiento, sus plazos de retención y sus flujos de datos específicos.

Qué tiene que cubrir (Artículos 13 y 14 del RGPD)

  • Quién es usted: nombre de la empresa, domicilio social, correo electrónico de contacto para consultas de privacidad
  • El contacto de su DPO, si ha designado uno
  • Qué datos personales recopila, desglosados por categoría
  • Por qué recopila cada categoría: la finalidad
  • La base jurídica por categoría (contrato, consentimiento, interés legítimo, obligación legal)
  • Con quién comparte los datos: pago, envío, correo electrónico, analítica, alojamiento
  • Las transferencias internacionales y el mecanismo legal que las respalda
  • Los plazos de retención por tipo de dato
  • Los derechos del interesado: acceso, rectificación, supresión, portabilidad, oposición, limitación
  • Cómo ejercer esos derechos
  • El derecho a presentar una reclamación ante una autoridad de control
  • Si facilitar los datos es obligatorio para usar el servicio
  • Cualquier decisión automatizada (la mayoría de las tiendas no tiene ninguna)
  • Información sobre cookies, o un enlace a una política de cookies independiente

Esqueleto que puede adaptar

1. Quiénes Somos
   - Nombre de la empresa, número de registro, dirección
   - Correo electrónico de contacto para asuntos de privacidad

2. Qué Datos Recopilamos
   - Datos de registro de la cuenta (nombre, correo electrónico, contraseña)
   - Datos del pedido (dirección de envío, dirección de facturación, contenido del pedido)
   - Datos de pago (nota: no almacenamos números de tarjeta: lo hace nuestro procesador de pagos)
   - Datos de comunicación (mensajes del formulario de contacto, mensajes del pedido)
   - Datos técnicos (dirección IP, tipo de navegador, cookies)
   - Suscripción al boletín (dirección de correo electrónico)

3. Por Qué los Recopilamos (Finalidades y Base Jurídica)
   - Para procesar sus pedidos (contrato)
   - Para crear y gestionar su cuenta (contrato)
   - Para enviar confirmaciones de pedido y actualizaciones de envío (contrato)
   - Para enviar correos electrónicos de marketing (consentimiento: puede darse de baja en cualquier momento)
   - Para mejorar nuestro sitio web (interés legítimo / consentimiento para las cookies de analítica)
   - Para cumplir con las leyes fiscales y contables (obligación legal)
   - Para prevenir el fraude (interés legítimo)

4. Con Quién Compartimos Sus Datos
   - Procesador de pagos: [Nombre]: procesa los pagos con tarjeta
   - Transportista: [Nombre]: recibe la dirección de entrega y el teléfono
   - Servicio de correo electrónico: [Nombre]: envía correos transaccionales y de marketing
   - Analítica: [Nombre]: estadísticas de uso del sitio web
   - Proveedor de alojamiento: [Nombre]: almacena todos los datos del sitio web

5. Transferencias Internacionales
   - [Enumere los servicios que transfieren datos fuera de la UE/EEE]
   - Garantías establecidas (Marco de Privacidad de Datos UE-EE. UU., Cláusulas Contractuales Tipo)

6. Durante Cuánto Tiempo Conservamos Sus Datos
   - Datos de la cuenta: hasta que elimine su cuenta
   - Datos del pedido: [X] años (requisito legal para las facturas)
   - Datos de carritos abandonados: [X] meses
   - Datos de analítica: [X] meses
   - Registros del servidor: [X] días

7. Sus Derechos
   - Acceso, rectificación, supresión, portabilidad, oposición, limitación
   - Cómo ejercerlos (correo electrónico, ajustes de la cuenta, módulo RGPD)
   - Derecho a presentar una reclamación ante [la autoridad de control de su país]

8. Cookies
   - [Resumen o enlace a la política de cookies]

9. Cambios en Esta Política
   - Última actualización: [fecha]

10. Contáctenos
    - Correo electrónico para consultas de privacidad

Dónde enlazarla

Pie de página (todas las páginas), formulario de registro, proceso de compra, formulario de contacto, suscripción al boletín y el banner de cookies. En PrestaShop, normalmente crearía la política como una página de CMS (Diseño → Páginas) y la mostraría a través del widget de enlaces o del pie de página de su tema.

Derechos del cliente sobre los datos

Su cliente puede pedir sus datos, pedirle que los corrija, pedirle que los elimine o pedirlos en un formato portable. El plazo para responder es de 30 días.

Derecho de acceso: exportación de datos

No solo la página de su cuenta. Todo: pedidos, direcciones, registros de consentimiento, mensajes, estado del boletín y todo lo que sus módulos hayan almacenado. El módulo psgdpr añade un botón en la página de la cuenta que genera un PDF/CSV a partir de las tablas del núcleo de PrestaShop. Si lo hace a mano:

-- Obtener todos los datos de un cliente concreto
SELECT * FROM ps_customer WHERE id_customer = {ID};
SELECT * FROM ps_address WHERE id_customer = {ID};
SELECT * FROM ps_orders WHERE id_customer = {ID};
SELECT * FROM ps_cart WHERE id_customer = {ID};
SELECT * FROM ps_message WHERE id_customer = {ID};
SELECT * FROM ps_customer_message WHERE id_customer = {ID};

-- No olvide las tablas específicas de los módulos
SELECT * FROM ps_emailsubscription WHERE email = '{EMAIL}';
-- Compruebe cualquier otra tabla de módulos que almacene datos de clientes

Derecho de supresión: derecho al olvido

No es absoluto. Puede negarse cuando tenga una obligación legal de conservar el registro (facturas con fines fiscales, normalmente de 5 a 10 años en toda la UE) o un litigio legal en curso. En la práctica, esto significa una mezcla de eliminar, anonimizar y conservar:

  • Eliminar: la propia cuenta, las direcciones no utilizadas, los carritos abandonados, la suscripción al boletín, los registros de invitado, la lista de deseos, las reseñas
  • Anonimizar: los pedidos, reemplace los campos personales por "Cliente Eliminado", conserve el registro financiero para la contabilidad
  • Conservar: las facturas, con los datos del cliente anonimizados en la copia orientada al cliente, y el registro completo retenido a efectos fiscales

Enfoque manual si no puede usar un módulo:

-- Anonimizar el registro del cliente (no use DELETE: los pedidos vinculados se romperían)
UPDATE ps_customer SET
  firstname = 'Deleted',
  lastname = 'Customer',
  email = CONCAT('deleted_', id_customer, '@anonymous.invalid'),
  passwd = '',
  birthday = '0000-00-00',
  phone = '',
  optin = 0,
  newsletter = 0,
  deleted = 1,
  active = 0
WHERE id_customer = {ID};

-- Anonimizar las direcciones no vinculadas a pedidos entregados
UPDATE ps_address SET
  firstname = 'Deleted',
  lastname = 'Customer',
  address1 = 'Deleted',
  address2 = '',
  postcode = '00000',
  city = 'Deleted',
  phone = '',
  phone_mobile = '',
  other = '',
  company = '',
  vat_number = '',
  dni = '',
  deleted = 1
WHERE id_customer = {ID}
AND id_address NOT IN (
  SELECT id_address_delivery FROM ps_orders WHERE id_customer = {ID}
  UNION
  SELECT id_address_invoice FROM ps_orders WHERE id_customer = {ID}
);

-- Eliminar los carritos abandonados (no convertidos en pedidos)
DELETE FROM ps_cart_product
WHERE id_cart IN (
  SELECT id_cart FROM ps_cart
  WHERE id_customer = {ID}
  AND id_cart NOT IN (SELECT id_cart FROM ps_orders)
);
DELETE FROM ps_cart
WHERE id_customer = {ID}
AND id_cart NOT IN (SELECT id_cart FROM ps_orders);

-- Eliminar la suscripción al boletín
DELETE FROM ps_emailsubscription WHERE email = '{ORIGINAL_EMAIL}';
Haga siempre una copia de seguridad primero, ejecute siempre la versión SELECT de cada consulta y compruebe el número de filas, pruebe siempre en un entorno de staging. Anonimice cuando las filas estén vinculadas a pedidos. Hemos limpiado suficientes supresiones manuales mal hechas como para sostener cada palabra de esto.

Derecho a la portabilidad

Exportación legible por máquina (JSON o CSV) para que el interesado pueda llevársela a otra parte. La exportación de psgdpr lo cubre. Si lo hace manualmente, el mismo conjunto de consultas que para el derecho de acceso, con formato que permita la portabilidad, CSV o JSON.

Derecho de rectificación

El más sencillo. Los clientes pueden autogestionar la mayor parte de esto desde la página de su cuenta. Si le escriben, corríjalo en el back office. Listo.

Cómo gestionar el proceso

  1. Verifique la identidad: el mismo correo electrónico que el de la cuenta, o una coincidencia de nombre real en el registro del cliente. Hemos visto intentos de apropiación de cuentas a través de correos de "derecho de supresión".
  2. Regístrelo: quién lo pidió, cuándo y qué quería
  3. Responda en un plazo de 30 días: ampliable en 60 más en casos complejos, pero debe notificárselo dentro de los primeros 30
  4. Cumpla o deniegue con un motivo documentado: p. ej., "anonimizaremos todo excepto las facturas, conservadas por obligación legal durante 7 años"
  5. Confirme la finalización por escrito

Gestión del consentimiento

Formulario de registro

Casilla de consentimiento de la política de privacidad sin marcar, con enlace a la política. No premarcada. No agrupada con el consentimiento del boletín: son consentimientos separados para finalidades separadas.

Boletín

Aceptación activa, con claridad sobre lo que se está suscribiendo, baja fácil en cada correo electrónico. Compruebe la plantilla del bloque de boletín de su tema: los temas más antiguos incluyen una casilla premarcada que tiene que desmarcar manualmente.

Consentimiento de marketing / publicidad

Si envía listas de correo electrónico a las Audiencias Personalizadas de Facebook o similares, esa es una finalidad distinta y necesita su propia aceptación. El consentimiento de la política de privacidad no la cubre.

Guardar los justificantes

Tiene que poder demostrar que se dio el consentimiento. Quién, cuándo, para qué, cómo y qué versión de la política estaba en vigor. psgdpr mantiene un registro. Si crea el suyo propio:

CREATE TABLE ps_gdpr_consent_log (
  id_consent_log INT AUTO_INCREMENT PRIMARY KEY,
  id_customer INT DEFAULT NULL,
  customer_email VARCHAR(255) NOT NULL,
  consent_type VARCHAR(50) NOT NULL,  -- 'privacy_policy', 'newsletter', 'marketing'
  consent_given TINYINT(1) NOT NULL,  -- 1 = otorgado, 0 = retirado
  ip_address VARCHAR(45) DEFAULT NULL,
  date_add DATETIME NOT NULL,
  request_details TEXT DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Retención: ¿cuánto tiempo puede conservarlos?

El RGPD dice "no más tiempo del necesario". No le entrega cifras concretas: usted las define, las documenta y se atiene a ellas. Para las purgas recurrentes, Database Cleanup puede encargarse de las tablas de PrestaShop que tienden a desbordar su ventana de retención. Nuestros valores predeterminados en las tiendas que gestionamos:

  • Cuentas activas: mientras estén activas. Consideramos que de 24 a 36 meses sin un inicio de sesión o una compra equivalen a inactividad.
  • Cuentas inactivas: correo electrónico de reactivación y, después, anonimización si no hay respuesta en 30 días.
  • Datos del pedido: el periodo de retención fiscal de su país (normalmente de 5 a 10 años en toda la UE). Anonimice los campos personales, conserve el registro financiero.
  • Facturas: el periodo legalmente exigido, sin excepción.
  • Carritos abandonados: 6 a 12 meses como máximo. No hay ninguna razón comercial para conservarlos más tiempo.
  • Invitados / conexiones: 6 meses. ps_connections es la tabla que más duele si se olvida de ella.
  • Suscriptores del boletín: hasta que se den de baja. Reconfirme periódicamente a los suscriptores inactivos durante mucho tiempo.
  • Registros del servidor: 30 a 90 días, con rotación agresiva.
  • Registros de consentimiento: al menos la duración del consentimiento (normalmente 12 meses como mínimo).

El SQL de limpieza que realmente ejecutamos

-- Eliminar los registros de invitado de más de 6 meses
DELETE FROM ps_guest
WHERE id_guest NOT IN (SELECT id_guest FROM ps_cart WHERE id_cart IN (SELECT id_cart FROM ps_orders))
AND id_guest IN (
  SELECT g.id_guest FROM ps_guest g
  INNER JOIN ps_connections c ON c.id_guest = g.id_guest
  GROUP BY g.id_guest
  HAVING MAX(c.date_add) < DATE_SUB(NOW(), INTERVAL 6 MONTH)
);

-- Eliminar los registros de conexión antiguos (conserva las estadísticas pero elimina los datos vinculados a la IP)
DELETE FROM ps_connections_source
WHERE id_connections IN (
  SELECT id_connections FROM ps_connections
  WHERE date_add < DATE_SUB(NOW(), INTERVAL 6 MONTH)
);

DELETE FROM ps_connections_page
WHERE id_connections IN (
  SELECT id_connections FROM ps_connections
  WHERE date_add < DATE_SUB(NOW(), INTERVAL 6 MONTH)
);

DELETE FROM ps_connections
WHERE date_add < DATE_SUB(NOW(), INTERVAL 6 MONTH);

-- Eliminar los carritos abandonados de más de 12 meses (no convertidos en pedidos)
DELETE cp FROM ps_cart_product cp
INNER JOIN ps_cart c ON cp.id_cart = c.id_cart
WHERE c.date_add < DATE_SUB(NOW(), INTERVAL 12 MONTH)
AND c.id_cart NOT IN (SELECT id_cart FROM ps_orders);

DELETE FROM ps_cart
WHERE date_add < DATE_SUB(NOW(), INTERVAL 12 MONTH)
AND id_cart NOT IN (SELECT id_cart FROM ps_orders);

-- Limpiar las estadísticas antiguas de vistas de página (datos agregados anónimos: prioridad más baja)
DELETE FROM ps_page_viewed
WHERE date_add < DATE_SUB(NOW(), INTERVAL 12 MONTH);
Envuelva cualquier DELETE en un SELECT primero y compruebe el número de filas antes de ejecutarlo. Ejecútelo mensualmente fuera de las horas punta a través de cron. Haga siempre una copia de seguridad primero. La primera vez que olvide la cláusula WHERE será la última vez que la olvide.
# Ejemplo de entrada de crontab: se ejecuta a las 3 de la madrugada el día 1 de cada mes
0 3 1 * * /usr/bin/php /path/to/your/store/scripts/gdpr-cleanup.php >> /var/log/gdpr-cleanup.log 2>&1

El script debería registrar qué eliminó y cuándo: ese registro forma parte de su rastro documental de responsabilidad proactiva.

Encargados del tratamiento de terceros

Su tienda no opera de forma aislada. Cada proveedor al que envía datos de clientes es un encargado del tratamiento que actúa en su nombre, y necesita un Acuerdo de Tratamiento de Datos con cada uno de ellos.

Los encargados del tratamiento que tiene una tienda PrestaShop típica

  • Pago: Stripe, PayPal, Adyen, Mollie
  • Transportistas: DHL, UPS, DPD, servicios postales nacionales locales
  • Email marketing: Mailchimp, Brevo, Klaviyo
  • Analítica: GA, Matomo, Plausible
  • Alojamiento: su VPS, servidor dedicado o proveedor en la nube
  • CDN / WAF: Cloudflare, Sucuri
  • Herramientas de soporte: Zendesk, Freshdesk
  • Píxeles de marketing: Meta, TikTok, Pinterest
  • ERP / contabilidad: lo que sea que vuelque los pedidos en su back office

Los DPA

Cada uno de ellos necesita un DPA firmado. La buena noticia: todos los grandes proveedores tienen versiones ya preparadas que puede aceptar dentro de su panel de control.

  • Stripe: integrado en sus Condiciones del Servicio
  • PayPal: en sus documentos legales
  • Google: Enmienda de Tratamiento de Datos, activable en la administración de GA
  • Mailchimp: DPA estándar en su página legal
  • Brevo: DPA en las condiciones o a petición
  • Cloudflare: DPA en su documentación de confianza

Acéptelos, conserve copias y archívelos en un lugar donde pueda encontrarlos durante una auditoría. Usamos una carpeta compartida por tienda con un PDF por proveedor.

Transferencias internacionales

Si un encargado del tratamiento está fuera de la UE/EEE (y la mayoría de la lista de SaaS anterior tiene su sede en EE. UU.) necesita un mecanismo legal para la transferencia. Actualmente:

  • Marco de Privacidad de Datos UE-EE. UU.: empresas estadounidenses que se han certificado. Compruébelo en dataprivacyframework.gov.
  • Cláusulas Contractuales Tipo: el texto estándar que aprobó la Comisión Europea. La mayoría de los grandes proveedores las incluyen en sus DPA.
  • Decisiones de adecuación: Reino Unido, Canadá, Japón, Corea del Sur, Suiza y algunos otros.

Enumere cada transferencia en su política de privacidad con el país y el mecanismo.

Cuando se produce una brecha de datos: el procedimiento ante una brecha

Una "brecha de seguridad de los datos" según el RGPD no es solo "nos han hackeado". Es cualquier incidente que ocasione la destrucción, pérdida, alteración, comunicación o acceso accidentales o ilícitos: así que una exportación de pedidos enviada por error, un bucket de copias de seguridad mal configurado, un portátil robado, una consulta de un empleado deshonesto o un ransomware que le deja sin acceso a los registros de clientes, todos ellos cuentan.

El plazo de 72 horas

Si es probable que la brecha afecte a los derechos de los interesados, debe notificarlo a su autoridad de control en un plazo de 72 horas desde que tiene conocimiento de ella. Si el riesgo es alto, también debe notificarlo a las personas afectadas sin dilación indebida. "Tener conocimiento" significa el momento en el que ha concluido razonablemente que se ha producido una brecha, y se espera que tenga una supervisión implantada para que ese momento llegue rápidamente.

Qué incluir en una notificación de brecha

  • La naturaleza de la brecha
  • Las categorías y el número aproximado de interesados afectados
  • Las categorías y el número aproximado de registros afectados
  • El contacto del DPO o el punto de contacto principal
  • Las consecuencias probables
  • Las medidas adoptadas o propuestas

Tenga el plan antes de necesitarlo

  1. Identifique su autoridad de control: CNIL (Francia), ICO (Reino Unido), UODO (Polonia), BfDI (Alemania), Garante (Italia), AEPD (España), y así sucesivamente
  2. Guarde en marcadores su formulario de notificación de brechas
  3. Redacte ya una plantilla de notificación: para la autoridad y para los clientes afectados
  4. Documente cada incidente, incluso aquellos que decida que no era necesario notificar. El razonamiento es en sí mismo un requisito del RGPD.
  5. Sepa quién investiga, quién aplica los parches, quién comunica
Un ataque bloqueado sin pérdida de datos es un incidente, no una brecha. Regístrelo de todos modos: demuestra que la supervisión existe.

Los errores que vemos con más frecuencia

A lo largo de las auditorías que hemos realizado en tiendas PrestaShop, surgen las mismas diez cosas.

1. Casillas de consentimiento premarcadas

Casilla del boletín en el proceso de compra o en el registro premarcada. Busque en las plantillas de su tema checked o checked="checked" en cualquier input relacionado con el consentimiento. Desmárquela.

2. Ninguna forma de eliminar una cuenta

De serie, PrestaShop no permite que un cliente autogestione la eliminación de su cuenta. O bien instale psgdpr, o nuestro módulo de privacidad del cliente, o cree su propio botón en la página Mi Cuenta.

3. Acumular datos para siempre

Ninguna política de retención. Filas de ps_connections de 2019. Carritos abandonados hace tres años que siguen ahí. Defina ventanas de retención y automatice la purga.

4. Base técnica débil

El Artículo 32 del RGPD exige "medidas técnicas y organizativas apropiadas". Una base de fortalecimiento documentada, ya sea manual o aplicada a través de Security Revolution, forma parte de la demostración de que esas garantías existen. Los fallos que vemos:

  • Sin HTTPS: no hay excusa para esto en 2026
  • Cuentas de administrador con contraseñas débiles o compartidas entre el personal
  • Versiones de PrestaShop con años de retraso respecto a los parches de seguridad
  • Módulos con CVE conocidas todavía instalados
  • Sin copias de seguridad, o copias de seguridad en un directorio de lectura pública
  • Alojamiento compartido con un aislamiento de inquilinos deficiente
  • FTP en lugar de SFTP: credenciales en texto plano

5. Google Analytics disparándose antes del consentimiento

El clásico. Aparece el banner, GA ya está cargado. El banner es teatro.

6. Banner de cookies cosmético

El banner existe, los scripts se ejecutan igualmente. Abra las Herramientas de desarrollo y observe la pestaña Red mientras se carga la página: si Pixel y GA se disparan antes de cualquier clic, el banner es decoración.

7. Política de privacidad ausente o genérica

Plantilla copiada y pegada con los marcadores de posición sin rellenar, o que nombra a encargados del tratamiento que la tienda no usa en realidad. La política tiene que describir su tienda.

8. Ningún registro del consentimiento

"Demuestre que este cliente aceptó los correos electrónicos de marketing", y no hay nada que mostrar. O bien el registro de psgdpr, o el registro de nuestro Cookies Revolution, o su propia tabla de consentimiento.

9. Auditar solo el núcleo e ignorar los módulos

Reseñas, listas de deseos, recuperación de carritos abandonados, chat en directo: cada uno de ellos almacena datos personales, cada uno de ellos tiene que estar en su política de privacidad y en su purga de retención.

10. Ningún DPA

Stripe, GA, Mailchimp, Cloudflare en uso, cero DPA firmados archivados. Dedique una hora, acéptelos todos, archive los PDF.

La lista de comprobación

Recórrala una vez y, después, revísela trimestralmente.

Fundamento legal

  • Política de privacidad redactada, publicada, específica para esta tienda
  • Enlazada desde el pie de página, el registro, el proceso de compra, el formulario de contacto
  • Política de cookies (página o sección independiente)
  • Las CGV hacen referencia a la política de privacidad
  • DPA firmados con cada encargado del tratamiento
  • Registro de Actividades de Tratamiento (RAT) mantenido
  • DPO designado si es necesario (normalmente solo para tratamientos a gran escala o sensibles)

Consentimiento

  • Registro: casilla de política de privacidad sin marcar
  • Boletín: aceptación activa separada
  • Marketing: separado del consentimiento de la política de privacidad
  • El banner de cookies bloquea las cookies no esenciales antes del consentimiento
  • Elección granular: aceptar todo / rechazar todo / personalizar
  • Retirable desde un enlace persistente del pie de página
  • Registro del consentimiento con marca de tiempo, interesado, tipo, versión

Derechos del cliente

  • Los clientes pueden exportar sus datos
  • Los clientes pueden solicitar la eliminación de la cuenta
  • Los clientes pueden corregir sus datos
  • Exportación con portabilidad (legible por máquina) disponible
  • Proceso de respuesta de 30 días documentado
  • Verificación de identidad en cada solicitud
  • psgdpr o equivalente instalado y probado

Gestión de datos

  • Plazos de retención definidos por categoría de dato
  • Limpieza automatizada para las tablas de invitados/conexiones
  • Limpieza automatizada para los carritos abandonados
  • Rotación de los registros del servidor implantada
  • Cuentas inactivas gestionadas
  • Todas las ubicaciones de los datos documentadas (BD, archivos, terceros)

Seguridad

  • HTTPS forzado
  • PrestaShop en una versión compatible con los parches de seguridad aplicados
  • Módulos actualizados
  • Contraseñas de administrador robustas (y 2FA donde sea compatible)
  • Directorio de administración renombrado
  • Copias de seguridad configuradas, probadas y almacenadas fuera de la raíz web
  • Solo SFTP/SSH
  • Permisos de archivo sensatos (nada de 777)
  • Acceso a la base de datos restringido

Preparación ante brechas

  • Autoridad de control identificada
  • Plantilla de notificación redactada
  • Contacto designado para incidentes
  • Supervisión (registros, detección de intrusiones) implantada

Terceros

  • Cada encargado del tratamiento enumerado
  • DPA archivado para cada uno
  • Transferencias internacionales documentadas con su base legal
  • Encargados del tratamiento nombrados en la política de privacidad
  • Píxeles de analítica y marketing condicionados al consentimiento

Honestidad final

Los reguladores no buscan la perfección. Buscan un esfuerzo genuino y una práctica razonable. Una tienda con una política de privacidad real, un consentimiento que funciona, reglas de retención y un proceso para las solicitudes de los interesados está en una posición sólida, aunque no cubra todos los casos límite. Lo que se penaliza es la negligencia: las tiendas que ignoran las solicitudes, acumulan datos que no necesitan y muestran banners cosméticos que no hacen nada.

Elija la lista de comprobación anterior. Recórrala a lo largo de las próximas semanas. Revísela trimestralmente. Eso es el cumplimiento en la práctica: papeleo más ingeniería, ninguno de los dos por separado.

Lo hemos dicho dos veces y lo diremos una vez más: este es el complemento, desde el lado del desarrollador, a una conversación con un abogado especializado en protección de datos. Las piezas técnicas (el condicionamiento del consentimiento, las purgas de retención, los flujos de supresión, el registro de auditoría) podemos enviarlas. La redacción del DPA, el RAT, la notificación de brechas, las decisiones sobre la base jurídica y la decisión de si necesita un DPO son tareas para un asesor legal de su jurisdicción.

Lecturas relacionadas

Preguntas relacionadas

Volver arriba