Cumplimiento RGPD en BaaS: guía práctica para pymes y desarrolladores

Montar un Backend as a Service (BaaS) te acelera el proyecto: auth, base de datos, storage, APIs… todo “listo para usar”.

El problema es que, cuando eso toca datos reales de clientes, el RGPD deja de ser una pestaña de “legal” y se convierte en parte de tu arquitectura: dónde están los datos, quién los procesa, cuánto tiempo se guardan, qué registran tus logs y cómo borras una cuenta cuando te lo piden.

Si aún estás en fase de decisión técnica, te recomiendo leer primero: Backend as a Service (BaaS) en 2025: cómo elegirlo y conectarlo con Astro o Next.js. Aquí nos vamos a centrar en la parte “incómoda” pero inevitable: protección de datos.

Qué vas a conseguir con esta guía:

Identificar qué datos personales se procesan en un BaaS (incluidos los “invisibles”, como logs e IPs).
Entender tu papel (responsable) y el del proveedor (encargado), y qué pedir en un DPA.
Diseñar una configuración “privacy-first”: cifrado, retención, minimización, control de accesos y entornos.
Llevarte una checklist final para pymes y para desarrolladores.

Nota: esto no sustituye asesoramiento legal. La idea es darte un marco práctico para reducir riesgo y, sobre todo, evitar errores típicos de implementación.

1. Mapa rápido: qué datos personales tocas en un BaaS (aunque no lo parezca)

En RGPD, “dato personal” no es solo nombre y email. En un proyecto con BaaS, suelen aparecer (como mínimo) estas categorías:

Identificación directa:
- Nombre, apellidos, email, teléfono.
Identificación indirecta / técnica:
- IP, user agent, IDs de sesión, device IDs, cookies.
Datos de cuenta:
- Hash de contraseña (si aplica), proveedores de login (Google/GitHub), tokens, refrescos.
Contenido que sube el usuario:
- Imágenes, PDFs, notas, mensajes.
Metadatos:
- Timestamps, geolocalización aproximada, “última conexión”, historial de eventos.

Y ahora lo más importante: en BaaS, además del “dato”, existen capas que también pueden contenerlo:

Auth (registro, login, recuperación, MFA).
Base de datos (tablas con datos de negocio).
Storage (ficheros con metadatos y rutas).
Logs y métricas (errores, auditoría, trazas, queries, rate limiting).
Herramientas conectadas (email transaccional, analítica, soporte, CRM).

Si quieres cumplir RGPD, tu primer entregable no es un documento legal: es un mapa de datos sencillo que diga:

Qué entra.
Dónde se guarda.
Quién accede.
Cuánto tiempo vive.
Cómo se borra.

2. Roles RGPD en un BaaS: responsable vs encargado (y por qué te afecta en el diseño)

En la mayoría de escenarios “pyme + app web”, lo habitual es:

Tu empresa / tu proyecto: responsable del tratamiento (decide para qué y cómo se usan los datos).
El proveedor BaaS: encargado del tratamiento (procesa datos por tu cuenta, para darte el servicio).
Subprocesadores: terceros del BaaS (hosting, soporte, monitorización, etc.).

Esto se traduce en una regla práctica:

Si no puedes explicar qué hace el proveedor con tus datos y bajo qué contrato, no tienes “un backend gestionado”: tienes un punto ciego.

Qué implica para ti como responsable:

Tienes que informar (política de privacidad, cookies si aplica).
Tienes que limitar (solo datos necesarios).
Tienes que proteger (seguridad técnica y organizativa).
Tienes que responder (derechos ARSULIPO: acceso, rectificación, supresión, limitación, portabilidad y oposición).
Tienes que documentar (aunque sea con un nivel “pyme”, pero documentar).

3. Elegir proveedor con cabeza: UE, DPA y transferencias internacionales

Aquí es donde muchas implementaciones fallan, porque se confunde “mi web está en Europa” con “mis datos están en Europa”.

Checklist para evaluar un BaaS antes de meter datos reales:

3.1 Ubicación y residencia de datos

¿Puedes elegir región (UE) para base de datos y storage?
¿El proveedor te garantiza residencia de datos o solo “preferencia” de región?
¿Qué servicios quedan fuera de esa residencia (logs, soporte, analítica del proveedor)?

3.2 DPA: el contrato que necesitas (aunque sea un clic)

Necesitas un Data Processing Agreement (en España lo verás como “acuerdo de encargo de tratamiento”). A nivel práctico, fíjate en:

Qué datos y operaciones cubre.
Medidas de seguridad declaradas.
Subencargados (lista y mecanismo de cambios).
Notificación de brechas y soporte en incidentes.
Devolución/borrado al terminar el servicio.
Soporte para derechos de los interesados (borrados, exportaciones).

3.3 Transferencias fuera del EEE

Aunque elijas región UE, puede haber transferencias (por soporte, servicios auxiliares, analítica, etc.). Lo importante no es “evitarlo a toda costa”, sino:

Saber si ocurre.
Saber con qué base (cláusulas contractuales tipo, decisiones de adecuación, etc.).
Reducir exposición técnica (minimización, cifrado, pseudonimización).

4. Configuración “privacy-first” en BaaS: lo técnico que más reduce riesgo

La parte legal sin configuración técnica es papel mojado. Aquí tienes las piezas que, bien hechas, te evitan problemas reales.

4.1 Minimización: diseña el modelo de datos con intención

No guardes “por si acaso”.
Separa datos:
- Necesarios para el servicio (por ejemplo, email de cuenta).
- Opcionales (teléfono, dirección, preferencias).
Evita meter datos sensibles en campos libres (por ejemplo, “observaciones” donde acaban apareciendo historias clínicas o documentos de identidad).

Regla simple para pymes:

Si un campo no tiene un uso claro en un proceso, es un campo que te puede explotar en una petición de borrado o en una brecha.

4.2 Control de accesos: el 80% de la seguridad en BaaS

En BaaS, es muy fácil “que funcione” y muy fácil también dejar una API abierta sin querer.

Buenas prácticas mínimas:

Principio de mínimo privilegio:
- Cada clave/rol con los permisos justos.
Separación de llaves:
- Llaves “públicas” solo para operaciones limitadas desde cliente.
- Llaves “de servicio” solo en servidor (por ejemplo, Functions).
Políticas a nivel de fila (si tu proveedor las soporta):
- “Un usuario solo puede leer/escribir sus propios datos”, por defecto.

Si usas Astro o Next.js, un patrón muy útil para reducir exposición es interponer una capa de backend propia para operaciones sensibles (validaciones, lógica de negocio, claves privadas). Si ya trabajas con Netlify, esto encaja especialmente bien con Functions y Edge Functions: Netlify Functions y Edge Functions con Astro.

4.3 Cifrado y secretos: el error típico es meter “secreto” en el repo

Mínimos recomendables:

HTTPS siempre (esto normalmente ya lo cubre el proveedor, pero valida dominios y redirects).
Secretos en variables de entorno (no en el repo, no en el frontend).
Rotación de claves (plan simple: cuándo y cómo la haces).
Si guardas datos especialmente delicados (aunque no sean “categorías especiales”), valora cifrado por campo o tokenización.

4.4 Logs y retención: RGPD y FinOps se dan la mano

Los logs son el lugar donde se cuela PII sin que nadie lo note:

Emails en mensajes de error.
Tokens en URLs.
Payloads completos en trazas.
IDs que permiten reidentificación.

Checklist práctica:

Define una retención de logs razonable (y distinta por entorno).
Enmascara o elimina PII en logs (especialmente errores).
Evita loggear request/response completos en producción.
Revisa qué guarda el proveedor “por defecto” (y si puedes reducirlo).

Además, esto afecta al coste: retenciones eternas y logs verbosos se pagan. Si estás controlando gasto cloud, te puede interesar enlazar este punto con FinOps: FinOps para pymes: cómo controlar los costes de la nube.

4.5 Entornos y datos de prueba: no uses producción como “dataset”

En pymes es habitual:

Copiar la base de datos de producción a staging “para probar”.
Compartir capturas con datos reales por WhatsApp.
Usar emails reales en QA y que se disparen notificaciones.

Buenas prácticas mínimas:

Entornos separados (dev/staging/prod).
Datos sintéticos o anonimizados para pruebas.
Feature flags para evitar envíos reales en staging.
Accesos acotados (staging no debería ser “barra libre”).

5. Derechos ARSULIPO: cómo no sufrir cuando te pidan exportar o borrar

Tu cumplimiento se nota cuando alguien te escribe: “Quiero que borréis mi cuenta” o “Quiero una copia de mis datos”.

Si tu app usa BaaS, define desde el inicio:

Flujo de borrado:
- Borrado lógico vs borrado físico (y cuándo haces cada uno).
- Qué pasa con logs, backups y auditoría.
Exportación:
- Qué entregas (JSON/CSV + ficheros).
- Quién puede solicitarlo (verificación de identidad).
Rectificación:
- Qué datos puede editar el usuario y qué datos requieren soporte.

Regla de oro:

Si no puedes borrar o exportar sin “tocar la base de datos a mano”, te falta diseño de producto (y te falta RGPD).

6. Documentación mínima viable para una pyme (sin montar una consultora)

No necesitas un departamento legal para empezar, pero sí necesitas orden.

Entregables recomendables (versión realista):

Política de privacidad clara (qué datos, para qué, base legal, conservación, derechos y contacto).
Política de cookies si usas analítica/marketing (y un banner coherente con tu implementación).
Registro interno (simple) de tratamientos:
- Qué sistemas procesan datos (web, BaaS, email, analítica).
- Quién es el proveedor y dónde está.
- Retenciones.
Procedimiento de incidentes:
- Qué haces si hay brecha, a quién avisar, qué logs revisar, cómo revocas claves.

Esto no solo “cumple”: también genera confianza cuando vendes servicios o captas leads online.

7. Checklist final (por perfil)

7.1 Checklist para pyme (propietario/a o responsable de negocio)

Tengo claro qué datos recojo y para qué.
El proveedor BaaS tiene DPA firmado/aceptado y subprocesadores identificados.
Sé en qué región están los datos y si hay transferencias fuera del EEE.
Tengo una política de privacidad realista y un canal de contacto para derechos.
Tengo definida retención (datos, logs, backups) y un plan de borrado.
He limitado accesos internos (quién puede ver/descargar datos).

7.2 Checklist para desarrollador/a

He mapeado flujos: auth, DB, storage, logs, analítica y terceros.
Mínimo privilegio aplicado (roles, claves, entornos).
Operaciones sensibles pasan por backend propio (Functions) y secretos no se exponen.
Logs sin PII y con retención definida.
Staging sin datos reales o con datos anonimizados.
Implementados flujos de exportación/borrado y verificación.
Backups y borrado: sé qué se borra ya y qué queda por retención técnica.

Cierre: RGPD como parte del producto (y no como “papel al final”)

Cumplir RGPD usando BaaS no va de elegir “el proveedor correcto” y olvidarte. Va de diseñar el sistema para minimizar datos, controlar accesos, definir retenciones, y poder responder a usuarios y a incidentes sin improvisar.

Si estás montando (o revisando) una web/app con BaaS y quieres una auditoría práctica —sin humo, centrada en riesgos reales y acciones concretas— puedes escribirme desde contacto. Trabajo tanto con proyectos online como con pymes locales en Málaga.