El reto de peritar en un entorno multi-tenant
Las plataformas SaaS multi-tenant alojan los datos de decenas, cientos o miles de clientes sobre una infraestructura compartida. El aislamiento entre clientes (tenants) se produce a nivel de aplicación —cada usuario ve solo sus datos—, pero por debajo la base de datos, el almacenamiento y los servidores son comunes. Esta arquitectura, que reduce costes y simplifica el mantenimiento para el proveedor, introduce un desafío técnico y legal considerable cuando surge la necesidad de un peritaje informático.
Desde la perspectiva del perito, el problema fundamental es el acceso. A diferencia de un servidor on-premise donde se puede clonar un disco o capturar la memoria RAM, en un SaaS multi-tenant no existe acceso directo a la infraestructura. El proveedor controla el hardware, la red, la base de datos y los logs del sistema. El cliente solo dispone de lo que la plataforma le expone a través de su interfaz y sus API.
A esto se suma la dimensión legal. El RGPD y la LOPDGDD imponen restricciones estrictas sobre el acceso a datos personales. En un entorno multi-tenant, cualquier extracción de datos que no esté perfectamente delimitada al tenant del cliente puede exponer información de terceros, lo que constituiría una violación de la normativa de protección de datos y contaminaría la evidencia obtenida.
El perito debe, por tanto, diseñar una estrategia de obtención de evidencia que sea técnicamente viable, legalmente admisible y respetuosa con los derechos de terceros. Esto requiere conocer cómo funcionan las arquitecturas multi-tenant, qué mecanismos de aislamiento implementan y qué datos son accesibles sin comprometer la privacidad de otros clientes.
Qué evidencia se puede obtener sin comprometer terceros
Aunque el acceso a la infraestructura subyacente esté vedado, un peritaje SaaS bien planificado puede obtener evidencia significativa a partir de las fuentes disponibles para el tenant. La clave es saber qué pedir, a quién pedirlo y en qué formato.
Logs de auditoría específicos del tenant
La mayoría de plataformas SaaS empresariales registran las acciones de los usuarios: inicios de sesión, modificaciones de datos, cambios de permisos, exportaciones y eliminaciones. Estos logs, filtrados por tenant ID, constituyen la fuente primaria de evidencia. El perito solicita la exportación completa del período relevante y analiza patrones de acceso, anomalías y correlaciones temporales con los hechos denunciados.
Registros de actividad de usuario
Más allá de los logs de auditoría, muchas plataformas mantienen registros de actividad del usuario: qué pantallas visitó, qué informes generó, qué filtros aplicó. Aunque menos técnicos, estos datos pueden ser cruciales para demostrar el uso efectivo del sistema o la falta de acceso a determinadas funcionalidades comprometidas.
Logs de llamadas API
Si el cliente utiliza la API del proveedor, los registros de llamadas API (endpoints invocados, parámetros, respuestas, códigos de estado) ofrecen una trazabilidad detallada de las operaciones realizadas. Estos logs están intrínsecamente delimitados al tenant y no exponen datos de terceros.
Exportaciones del proveedor y legal holds
Ante un procedimiento judicial, el perito puede solicitar al proveedor una exportación de datos bajo retención legal (legal hold). Este mecanismo obliga al proveedor a preservar los datos del tenant en su estado actual, evitando que se eliminen por políticas de retención automáticas. La solicitud debe ser formal, específica en su alcance y citar las obligaciones contractuales y legales aplicables.
Disputas típicas que requieren peritaje SaaS
Los conflictos entre clientes y proveedores SaaS que acaban requiriendo intervención pericial suelen encuadrarse en escenarios recurrentes. Conocerlos permite al perito anticipar qué evidencia será necesaria y al abogado plantear la estrategia procesal con mayor precisión.
Propiedad de los datos al abandonar el SaaS
El cliente decide migrar a otro proveedor y solicita la exportación completa de sus datos. El proveedor entrega un formato propietario, incompleto o directamente se niega. El peritaje documenta qué datos existían, qué se entregó y qué se perdió en la transición.
Incumplimiento de SLA
El proveedor garantiza un 99,9 % de disponibilidad, pero el servicio sufre caídas recurrentes que impactan al negocio del cliente. El perito analiza los registros de monitorización, las notificaciones de incidencia y los tiempos reales de indisponibilidad para cuantificar el incumplimiento.
Acceso no autorizado por empleados del proveedor
Un empleado del proveedor SaaS accede a los datos del tenant sin autorización legítima. El peritaje examina los logs de acceso administrativo, los registros de soporte y las políticas de control de acceso internas del proveedor para determinar si el acceso fue justificado.
Eliminación de datos tras fin de contrato
El contrato termina y el cliente descubre que sus datos fueron eliminados antes del plazo pactado, o que no se eliminaron cuando debían. En ambos casos, el perito documenta la línea temporal, las obligaciones contractuales y la evidencia de cumplimiento o incumplimiento.
Funcionalidades no conformes con lo contratado
El cliente contrata un SaaS con funcionalidades específicas que no se implementan correctamente o dejan de funcionar tras una actualización. El perito compara las especificaciones contractuales con el comportamiento real del sistema, documentando las discrepancias mediante pruebas reproducibles.
Cómo solicitar evidencia al proveedor SaaS
La obtención de evidencia en un peritaje SaaS depende en gran medida de la cooperación del proveedor. A diferencia de un análisis forense sobre un dispositivo físico, aquí el perito no puede «clonar el disco»: necesita que el proveedor facilite los datos. El proceso de solicitud debe seguir una secuencia que maximice las probabilidades de éxito y proteja la posición legal del cliente.
El primer paso es una solicitud formal por escrito, dirigida al contacto contractual o al departamento legal del proveedor, citando las cláusulas del contrato que obligan a la entrega de datos, los derechos del usuario bajo el RGPD (especialmente el derecho de acceso del artículo 15) y la finalidad concreta de la solicitud. Debe especificarse con precisión qué datos se requieren, en qué formato y para qué período temporal.
Simultáneamente, conviene enviar una notificación de retención legal (legal hold notice) para impedir que el proveedor elimine datos relevantes bajo sus políticas de retención automáticas. Esta notificación tiene efecto jurídico y su incumplimiento puede interpretarse como spoliation of evidence en jurisdicciones anglosajones, o como mala fe procesal en el marco español.
Si el proveedor rechaza la solicitud o la atiende de forma incompleta, la escalación pasa por vía judicial: solicitar al juzgado un requerimiento de exhibición documental (artículo 328 LEC) o, en procedimientos penales, una orden de entrega. Un perito judicial puede asesorar al abogado sobre qué datos solicitar técnicamente y cómo formular la petición para que sea ejecutable.
En todos los casos, cada solicitud, cada respuesta y cada negativa deben documentarse meticulosamente. Estas comunicaciones forman parte de la cadena de evidencia y pueden ser determinantes si el caso llega a juicio.
El papel del contrato y los SLA como evidencia
En un peritaje SaaS, el contrato de servicio y los acuerdos de nivel de servicio (SLA) no son meros documentos administrativos: son la referencia técnica y legal contra la que se mide el comportamiento del proveedor. El perito los utiliza como baseline para evaluar si las obligaciones se cumplieron o se incumplieron.
El SLA define métricas objetivas —porcentaje de disponibilidad, tiempo máximo de recuperación (RTO), punto máximo de pérdida de datos (RPO), tiempos de respuesta de soporte— que el perito puede contrastar con la evidencia empírica. Si el SLA promete un 99,95 % de uptime mensual y los registros de monitorización muestran un 98,7 %, el incumplimiento es cuantificable y documentable.
El Data Processing Agreement (DPA) es otro documento clave. Establece las obligaciones del proveedor como encargado del tratamiento bajo el RGPD: medidas de seguridad, notificación de brechas, lista de subprocesadores, condiciones de transferencia internacional de datos y derechos de auditoría. Cualquier desviación respecto a lo pactado en el DPA puede constituir un incumplimiento contractual y, simultáneamente, una infracción de la normativa de protección de datos.
La lista de subprocesadores merece atención especial. El cliente tiene derecho a saber qué terceros acceden a sus datos (proveedores de hosting, servicios de backup, herramientas de monitorización). Si el proveedor SaaS cambia un subprocesador sin notificarlo —algo que el RGPD exige—, el perito puede documentar esa omisión como incumplimiento.
Las cláusulas de notificación de incidentes definen en qué plazo el proveedor debe comunicar una brecha de seguridad. El RGPD establece un máximo de 72 horas para la notificación a la autoridad de control, pero el contrato puede imponer plazos más cortos para la notificación al cliente. El perito verifica si el proveedor cumplió esos plazos comparando los registros internos de detección con las comunicaciones enviadas al cliente.
Limitaciones del peritaje SaaS y cómo mitigarlas
El peritaje SaaS tiene limitaciones inherentes que lo distinguen del análisis forense tradicional. Reconocerlas no debilita el informe; al contrario, un perito que identifica y documenta las limitaciones genera mayor credibilidad ante el tribunal.
Sin acceso directo a la infraestructura
El perito no puede inspeccionar servidores, bases de datos ni configuraciones de red del proveedor. La mitigación pasa por maximizar la evidencia disponible en el lado del cliente y complementarla con fuentes externas: registros DNS, certificados SSL, datos de servicios de monitorización independientes como UptimeRobot o Pingdom, y capturas web archivadas.
Logs controlados por el proveedor
Los logs que entrega el proveedor están bajo su control. ¿Pueden haber sido modificados u omitidos? El perito debe analizar la coherencia interna de los logs (secuencias temporales, gaps sospechosos, formatos inconsistentes), cruzarlos con evidencia independiente y documentar cualquier indicio de manipulación. La ausencia de logs también es evidencia.
Límites en la exportación de datos
Muchos proveedores imponen rate limits en sus API o limitan el volumen de datos exportable. Esto puede impedir una extracción completa en plazos razonables. El perito planifica la exportación con antelación, prioriza los datos más relevantes y documenta cualquier restricción impuesta por el proveedor que haya impedido obtener evidencia adicional.
Granularidad insuficiente en los logs
No todos los SaaS registran las acciones con el detalle necesario para un peritaje. Puede haber logs de inicio de sesión pero no de qué datos se consultaron, o registros de cambios sin identificar al usuario responsable. El perito trabaja con lo disponible y señala expresamente qué preguntas no pueden responderse por falta de granularidad.
El proveedor como parte interesada
Cuando el proveedor SaaS es simultáneamente parte en la disputa y custodio de la evidencia, existe un conflicto de interés evidente. El perito debe abordar esta circunstancia con transparencia, buscar fuentes de verificación independientes y, si es necesario, recomendar una exportación forense a nivel de infraestructura cloud cuando la arquitectura lo permita.
¿Tienes una disputa con un proveedor SaaS?
Como perito informático en Mallorca, analizo la evidencia disponible en tu plataforma SaaS, evalúo el cumplimiento contractual del proveedor y elaboro informes periciales defendibles en juicio, sin comprometer datos de terceros.
Preguntas frecuentes
Generalmente no. El perito no tiene acceso directo a la infraestructura del proveedor SaaS. Su trabajo se basa en la evidencia disponible para el cliente (logs, exportaciones, capturas certificadas) y en la documentación contractual. Si es necesario un acceso más profundo, se solicita mediante requerimiento judicial o a través de la cláusula de auditoría del contrato, si existe.
Depende del proveedor y del plan contratado. La mayoría permite exportar los datos propios del tenant (registros, configuraciones, histórico de actividad). Los formatos habituales son CSV, JSON o PDF. Algunos proveedores ofrecen exportaciones completas bajo solicitud formal. El perito evalúa qué datos son relevantes para el caso y guía al cliente en la solicitud de exportación antes de que se pierdan o se sobrescriban.
La evidencia proporcionada por el proveedor debe tratarse con cautela, ya que el proveedor puede ser parte interesada en la disputa. El perito analiza la coherencia interna de los datos, los cruza con evidencia independiente (correos electrónicos, registros DNS, certificados SSL, comunicaciones del cliente) y documenta cualquier inconsistencia. Un juez valorará si la evidencia del proveedor es creíble en el contexto de todas las pruebas aportadas.
Si el proveedor se niega a una solicitud voluntaria, el siguiente paso es una solicitud formal por vía legal: requerimiento judicial en el marco del procedimiento. Si el proveedor tiene sede fuera de España, puede ser necesario recurrir a mecanismos de cooperación internacional. Mientras tanto, es crucial preservar toda la evidencia disponible en el lado del cliente y documentar las negativas del proveedor, ya que estas pueden ser relevantes para el caso.
Sí, y de hecho es lo habitual. El peritaje SaaS se centra en la capa de aplicación visible para el cliente: datos exportados, logs de auditoría, respuestas de API, documentación contractual y comunicaciones con el proveedor. El perito no necesita acceder a los servidores físicos ni a la base de datos compartida para emitir conclusiones válidas sobre el uso, disponibilidad o integridad de los datos del tenant.
Es uno de los escenarios más críticos. Si no existe una cláusula contractual de portabilidad de datos, la recuperación puede ser extremadamente difícil o imposible. El perito puede documentar la situación, preservar los datos accesibles antes del cierre definitivo y analizar si el proveedor cumplió sus obligaciones contractuales de notificación y entrega de datos. La jurisprudencia en este ámbito es aún escasa, pero la tendencia es exigir al proveedor un período razonable de acceso post-terminación.
Sí. El perito compara los compromisos del SLA (disponibilidad, tiempos de respuesta, RPO/RTO) con la evidencia objetiva disponible: monitores de uptime externos, registros de incidencias, comunicaciones del proveedor, status pages históricas y datos del propio cliente. Si el SLA establece un 99,9% de disponibilidad y los datos muestran caídas superiores, el perito lo documenta con precisión técnica para que el tribunal pueda valorar el incumplimiento.
Es altamente recomendable. Una cláusula de auditoría permite al cliente (o a un perito en su nombre) verificar que el proveedor cumple con sus obligaciones contractuales y regulatorias. Sin esta cláusula, el acceso a información del proveedor depende de su buena voluntad o de un requerimiento judicial, lo que retrasa y encarece cualquier disputa. El RGPD exige al responsable del tratamiento poder verificar el cumplimiento del encargado, lo que refuerza la necesidad de esta cláusula.