SaaS vs. On‑Premise: Marco de decisión para cumplimiento y soberanía de datos

La decisión SaaS vs. On‑Premise se vuelve en muchas organizaciones verdaderamente crítica solo cuando los requisitos de cumplimiento y de soberanía de los datos se concretan: ¿Dónde están los datos? ¿Quién tiene acceso administrativo? ¿Cómo se supera una auditoría sin basarse en suposiciones? ¿Y cómo se puede, en caso necesario, salir sin proyectos de migración de meses bajo presión de tiempo?

En la práctica, «Cloud o no» rara vez es la cuestión real. Lo decisivo es si el modelo operativo elegido satisface sus requisitos de conformidad legal, capacidad de comprobación (auditoría), gestión de riesgos y control operativo —a lo largo de todo el ciclo de vida, no solo en la puesta en producción. Este artículo ofrece un marco de decisión sólido que alinea a la dirección de TI, cumplimiento, seguridad, compras y la dirección ejecutiva en una lógica común de evaluación. El foco está en la viabilidad de implementación, las responsabilidades y los controles documentables.

Aclarar términos: Soberanía de los datos, Residencia de datos y Responsabilidad Compartida

Soberanía de los datos no significa solo «los datos están con nosotros». Se trata de la capacidad para hacer cumplir el uso de los datos: controlar los accesos, gestionar las claves, provocar eliminaciones comprobables, extraer exportaciones y mantener la capacidad de actuación ante conflictos (p. ej., solicitudes de autoridades). Residencia de datos es más estrecho: describe en qué región o en qué país se almacenan y procesan los datos.

En SaaS se suele trabajar con el concepto de Responsabilidad Compartida: proveedor y cliente comparten responsabilidades. No es un término de marketing; debe traducirse en controles concretos. Típicamente: el proveedor es responsable de la plataforma (centro de datos, seguridad básica, parcheado de la aplicación SaaS), y el cliente es responsable de identidades, roles, clasificación de datos, permisos, configuración y uso correcto. En On‑Premise la responsabilidad recae casi por completo en su organización; a cambio, las evidencias y los derechos de intervención están al máximo bajo su control.

Por qué «cumplimiento» sin perspectiva de auditoría no basta

Muchos requisitos solo se consideran cumplidos cuando son comprobables: mediante auditoría interna, auditores externos, auditorías de clientes o autoridades. Lo decisivo es si puede responder con claridad a las siguientes preguntas:

• ¿Qué controles existen? (p. ej. control de accesos, registro, gestión de claves, copia de seguridad/recuperación)
• ¿Cómo se implementan los controles? (configuración, procesos, responsables)
• ¿Cómo se demuestra la eficacia? (registros, informes, protocolos de prueba, evidencias de cambios)
• ¿Cómo se responde a las desviaciones? (proceso de incidentes, escalamiento, medidas correctivas)

Un proveedor SaaS puede aportar muchas evidencias (p. ej. informes SOC), pero no automáticamente las que son relevantes para su empresa. A la inversa, On‑Premise puede, en teoría, cubrirlo todo, pero en la práctica fracasa por limitaciones de personal, madurez de procesos o falta de documentación. El marco de decisión debe, por tanto, representar ambas dimensiones: capacidad de control y capacidad operativa real.

SaaS vs. On‑Premise: Las principales dimensiones de decisión

En lugar de una lista general de pros y contras, es más eficaz evaluar a lo largo de dimensiones estables. Cada dimensión se traduce al final en requisitos que usted puede anclar en el RFP, el contrato y la operación.

1) Clasificación de datos y nivel de protección como punto de partida

Sin clasificación de datos, las discusiones sobre SaaS frente a On‑Premise se reducen a decisiones intuitivas. Una clasificación pragmática (p. ej. pública / interna / confidencial / estrictamente confidencial) es suficiente si se aplica de forma consistente. Es importante definir el nivel de protección: confidencialidad, integridad, disponibilidad y registro de auditoría (audit trail).

Regla práctica: cuanto mayor sea el nivel de protección, más deben articularse los controles técnicos (p. ej. gestión de claves) y los controles organizativos (p. ej. procesos de autorización). Esto puede cumplirlo SaaS, pero solo si los mecanismos ofrecidos encajan con su modelo.

2) Acceso, derechos de administrador y separación de inquilinos

En entornos SaaS, la pregunta más crítica a menudo no es “¿puede el proveedor ver los datos?”, sino quién puede intervenir administrativamente y en qué condiciones. Esto incluye accesos de soporte, accesos de emergencia, subprocesadores y el modelo interno de permisos del proveedor. La separación por inquilinos (Multi‑Tenancy) es habitual en SaaS. No es intrínsecamente insegura, pero requiere una separación técnica y organizativa demostrable y garantías claras sobre entornos de prueba, staging y producción.

On‑Premise le ofrece control máximo sobre los accesos administrativos, pero eso también implica que debe desplegar realmente MFA, Privileged Access Management (PAM, es decir, accesos administrativos controlados con registro) y endurecimiento. Sin estas medidas, “On‑Premise” no es automáticamente más seguro.

3) Cifrado y gestión de claves (KMS, BYOK, HYOK)

El cifrado solo es un argumento de soberanía sobre los datos si la gestión de claves es la adecuada. Algunos términos que aparecen con frecuencia en las negociaciones de adquisición:

• KMS (Key Management Service): servicio para la gestión de claves criptográficas, incluida la rotación y las reglas de acceso.
• BYOK (Bring Your Own Key): usted proporciona la clave; el proveedor la usa en su infraestructura, a menudo con control suyo sobre rotación/desactivación.
• HYOK (Hold Your Own Key): las claves permanecen en su entorno; el proveedor no puede descifrar sin su intervención. Es tecnológicamente más exigente y no está disponible en todos los SaaS.

Para cumplimiento normativo es esencial: ¿quién puede activar, rotar y bloquear claves? Y: ¿qué datos están cifrados y cómo? (at REST, es decir, en reposo; in transit, es decir, en tránsito; en su caso, del lado del cliente). On‑Premise típicamente permite control total, pero exige procesos maduros (rotación, respaldo de claves, escenarios de recuperación).

4) Logging, Audit Trail und Beweissicherung

La capacidad de auditoría depende de los logs: ¿quién consultó, modificó, exportó o eliminó qué datos y cuándo? Para muchos regímenes (sistema de control interno, protección de datos, estándares de seguridad) necesita cadenas de eventos trazables. En SaaS es importante si puede exportar datos en bruto (p. ej. eventos de administrador) y durante cuánto tiempo se conservan. En On‑Premise no basta con que el logging esté “activado”; debe ser analizado centralmente y almacenado con resistencia a la manipulación (principio Write‑Once‑Read‑Many o almacenamiento con garantía de inmutabilidad/revisión).

Para la adquisición hay una pregunta concreta y decisiva: ¿Puede el sistema enviar logs a su SIEM (Security Information and Event Management, análisis centralizado de seguridad), con el nivel de detalle necesario y mediante interfaces estables?

5) Datenresidenz, Subprozessoren und grenzüberschreitende Transfers

Las normas de protección de datos y los requisitos sectoriales exigen con frecuencia claridad sobre dónde se procesa y quién participa en ello. En SaaS la cadena de subprocesadores es central: hosting, soporte, monitoring, respuesta a incidentes, proveedor de correo electrónico, sistemas de ticketing. Necesita transparencia, procesos de cambio y mecanismos de objeción. On‑Premise reduce esa cadena, pero la sustituye por sus propios proveedores (p. ej. mantenimiento, centro de datos, Managed Services), que también deben integrarse adecuadamente tanto contractual como organizativamente.

6) Business Continuity: Backup, RESTore, RTO/RPO, Krisenbetrieb

El cumplimiento y la soberanía de los datos también afectan a la disponibilidad. Dos métricas deberían aparecer en toda decisión:

• RPO (Recovery Point Objective): pérdida máxima de datos tolerable en tiempo (p. ej. 15 minutos).
• RTO (Recovery Time Objective): tiempo máximo tolerable de recuperación (p. ej. 4 horas).

SaaS puede ser muy robusto en este ámbito, pero debe comprobarse lo que se garantiza contractualmente: frecuencia de backups, pruebas de RESTauración, fallos regionales, dependencia de servicios de identidad, tiempos de respuesta del soporte en Major Incident. On‑Premise puede optimizarse exactamente según sus RTO/RPO, pero exige planificación, redundancia de hardware, pruebas regulares de RESTauración y runbooks fiables.

7) Change- und Patch-Management als Compliance-Faktor

En SaaS los cambios suelen ser continuos. Eso es positivo para las actualizaciones de seguridad, pero puede introducir riesgos para la validación, las interfaces y los procesos funcionales. Se vuelve relevante para el cumplimiento cuando necesita rastrear y evaluar los cambios: ¿qué releases se publicarán? ¿Existen notas de versión? ¿Hay avisos previos? ¿Se pueden desactivar o “fijar” funciones?

En On‑Premise usted controla parches y releases. Eso reduce sorpresas, pero aumenta el riesgo de que las actualizaciones queden pendientes. En auditorías, “hubiéramos podido parchear” no es eximente si vulnerabilidades conocidas permanecen abiertas durante meses.

Regulatorische Anforderungen in eine umsetzbare Prüflogik übersetzen

Independientemente de si se orienta por normas ISO, requisitos sectoriales o marcos regulatorios: lo decisivo es traducirlos a requisitos verificables. Ejemplos de factores impulsores comunes (sin pretensión de exhaustividad):

• Protección de datos (p. ej. RGPD): encargo de tratamiento, conceptos de eliminación, derechos de los interesados, medidas técnicas y organizativas.
• NIS2: responsabilidad de la dirección, medidas de seguridad, procesos de notificación, riesgos en la cadena de suministro.
• DORA (sector financiero): gestión de riesgos TIC, pruebas de resiliencia, control de terceros, planificación de salida.
• Auditorías específicas por sector: evidencias de accesos, gestión de cambios, manejo de incidentes, BCM.

Importante para „Approvvigionamento“: Estos impulsores no deben figurar como palabras de moda en un RFP, sino como requisitos de control concretos con evidencias, responsabilidades y derechos de auditoría.

Marco de decisión: De los requisitos a una selección robusta

El siguiente marco funciona como un proceso que puede integrarse en la adquisición, la gobernanza y la planificación de proyectos. Obliga a aclarar los puntos abiertos desde el principio — antes de que el contrato y la arquitectura técnica creen hechos consumados.

Paso 1: Definir controles mínimos (no negociable)

Defina una lista de controles mínimos que se apliquen independientemente del modelo de operación. Ejemplos:

• MFA para todos los accesos administrativos; principio de mínimos privilegios (privilegios estrictamente necesarios).
• Registro de auditoría verificable para acciones críticas (p. ej. cambios de permisos, exportaciones, eliminaciones).
• Residencia de datos definida o desviación justificada con controles de transferencia.
• Cifrado en tránsito y en reposo; gestión de claves documentada, incluida la rotación.
• Concepto de backup/RESTore con pruebas de RESTauración periódicas y RTO/RPO definidos.
• Proceso de incidentes con plazos de notificación, puntos de contacto y soporte forense.

Estos controles mínimos son el núcleo de su posición de cumplimiento. Si un proveedor (o su propia organización On‑Prem) no puede cumplirlos, la discusión termina o se requiere una aceptación formal del riesgo a nivel directivo.

Paso 2: Establecer el mapeo de controles y responsabilidades (RACI)

Para cada objetivo de control debe definir quién es Responsible (ejecutor), Accountable (responsable último), Consulted (consultado) y Informed (informado). Especialmente en entornos SaaS aparecen brechas cuando todos asumen «el proveedor lo hará».

Fallas típicas en RACI son la gestión de identidades (SSO, es decir Single Sign‑On), la administración de permisos, las exportaciones de datos, las solicitudes de eliminación, las decisiones sobre claves y la retención de logs. Estos puntos deben figurar como líneas independientes en su matriz.

Paso 3: Crear un plan de evidencias para auditorías

Un plan de evidencias es una lista de pruebas que debe poder entregar con un clic. Ejemplos:

• Extracto de configuración de MFA/SSO y roles administrativos
• Registro de una prueba de RESTauración (fecha, alcance, resultado, desviaciones)
• Aprobaciones de cambios para ajustes relevantes para la seguridad
• Lista de subprocesadores, incluido el historial de cambios
• Extracto de eventos SIEM para acciones críticas (reducción a los datos necesarios)

Importante: Planifique las evidencias de modo que estén disponibles incluso si el SaaS‑Tenant está bloqueado o los sistemas On‑Prem quedan aislados durante un incidente.

Paso 4: Estrategia de salida y portabilidad como capítulo obligatorio

El cumplimiento y la soberanía de los datos no terminan en la operación, sino en la salida. Un plan de salida es más que «podemos exportar». Incluye:

• Exportación de datos: formatos, integridad (incl. metadatos, registros de auditoría), frecuencia, automatización.
• Identidades y permisos: ¿Cómo se migran o reconstruyen roles, grupos y estructuras de permisos?
• Interfaces: ¿Qué integraciones dependen del sistema (ERP, DMS, IAM, BI)? ¿Cómo se realizará la transición?
• Plazos: ¿Cuánto tiempo permanecen los datos disponibles tras la rescisión? ¿Cómo se realiza la eliminación demostrable?
• Dependencias: flujos de trabajo propietarios, modelos de datos, informes, automatizaciones.

Si estos puntos no están garantizados contractualmente y técnicamente, el Vendor Lock‑in no aparece como una «sensación», sino como un bloqueo concreto de la migración.

Lista de verificación para adquisiciones (RFP): comparar SaaS vs. On‑Premise de forma auditable

La siguiente lista de verificación está formulada deliberadamente para poder incorporarse a un RFP, a una lista de Due‑Diligence o a una hoja de evaluación interna.

A) Datos y protección de datos

• ¿Qué categorías de datos se procesan? ¿Existen funciones para clasificación/etiquetado de datos?
• ¿Dónde se realiza el procesamiento y almacenamiento (regiones)? ¿Existe una garantía vinculante sobre la residencia de los datos?
• ¿Cómo se divulgan los subprocesadores? ¿Hay notificación previa, posibilidad de objeción, derechos de salida?
• ¿Cómo se gestionan y prueban las solicitudes de eliminación (incl. copias de seguridad, réplicas, registros)?
• ¿La solución soporta los derechos de los interesados (acceso, eliminación, exportación) en plazos prácticos?

B) Seguridad y control de acceso

• ¿Soporte para SSO (p. ej. SAML/OIDC) y MFA, incluyendo accesos de administrador y accesos por API?
• Modelo de roles: principio de menor privilegio (Least Privilege), roles personalizados (Custom Roles), roles de administrador separados, cuentas Break‑Glass (acceso de emergencia) con registro?
• Cifrado: en tránsito / en reposo; opciones para BYOK/HYOK; rotación de claves; auditabilidad de las acciones sobre claves?
• RESTricciones de red y de acceso: IP‑Allowlisting, conectividad privada, aislamiento de tenant (Tenant‑Isolation)?

C) Auditoría, registro y evidencias

• ¿Qué registros de auditoría están disponibles (acciones de admin, accesos a datos, exportaciones, eventos de autenticación)?
• ¿Cuánto tiempo se conservan los registros y pueden exportarse (integración SIEM)?
• ¿Qué informes de auditoría independientes están disponibles (p. ej. informes SOC) y con qué periodicidad?
• ¿Cómo se documenta la gestión de cambios (notas de versión, ventanas de mantenimiento, opciones de reversión)?

D) Operación, resiliencia y soporte

• RTO/RPO definidos, frecuencia de copias de seguridad, pruebas de RESTauración, documentación de verificación?
• Respuesta a incidentes: contactos, escalado, plazos de notificación, soporte forense, análisis post‑mortem?
• SLA: disponibilidad, horarios de soporte, tiempos de respuesta, priorización, lógica de compensación?
• Dependencias: proveedor IAM, entrega de correo electrónico, DNS, límites de tasa de API, ventanas de mantenimiento?

E) Salida, portabilidad, fin de contrato

• Exportaciones estandarizadas (datos + metadatos + registro de auditoría), documentadas y comprobables periódicamente?
• Plazos y condiciones en caso de rescisión: acceso a datos, exportación, eliminación, costes?
• Soporte en la migración: documentación técnica, estabilidad de interfaces, ventanas de migración?

Bloques de plantilla: requisitos mínimos como texto de política

Para que los requisitos no existan solo “en la cabeza”, ayuda un breve bloque de policy que se pueda copiar. Está deliberadamente formulado de forma genérica y debe adaptarse a su organización.

POLICY: Selección y operación de soluciones SaaS y On-Premise con necesidad de protección “confidencial” o superior

1. Identidad & Acceso
- El acceso administrativo requiere MFA y es personal (no hay cuentas compartidas).
- Roles y permisos siguen el principio de mínimo privilegio y se recertifican al menos trimestralmente.
- Los accesos de emergencia (Break-Glass) están documentados, son temporales y quedan registrados por completo.

2. Datos & Claves
- Los datos están cifrados en tránsito y at REST.
- La gestión de claves está documentada (rotación, bloqueo, recuperación). Cuando sea posible, se prefieren claves controladas por el cliente.

3. Logging & Auditoría
- Los eventos relevantes para la seguridad (autenticación, acciones administrativas, exportaciones, eliminaciones) se registran de forma que cumplan requisitos de auditoría.
- Los registros son exportables y se correlacionan de forma centralizada (SIEM o equivalente).

4. Resiliencia
- RTO/RPO están definidos y demostrados mediante pruebas regulares de RESTauración.
- Los procesos de incidentes (notificación, escalada, comunicación) están regulados contractualmente y organizacionalmente.

5. Salida
- La exportación y eliminación de datos al término del contrato es técnicamente posible, está documentada y garantizada contractualmente.
- El plan de salida se evalúa antes de la firma del contrato y se revisa al menos anualmente.

Evaluar costos y riesgos de forma realista: TCO frente al esfuerzo de cumplimiento

La cuestión del coste a menudo se reduce a las licencias. Para los requisitos de cumplimiento y soberanía de datos, sin embargo, es determinante cuánto esfuerzo se invierte en controles y demostración. Bloques de costes típicos:

• SaaS: licencias, módulos adicionales (Security/Compliance), integración SIEM, opciones de exportación de datos/backup, soporte empresarial, esfuerzos contractuales y de auditoría, en su caso costes por opciones de cifrado controladas por el cliente.
• On‑Premise: hardware/virtualización, almacenamiento/backup, segmentación de red, hardening, ventanas de parcheo, disponibilidad 24/7, monitorización/SIEM, esfuerzo de personal para operación y documentación, pruebas de recuperación, gestión del ciclo de vida.

Un error frecuente: se calcula On‑Premise como “gratuito” con equipos existentes, mientras que SaaS se percibe como “caro”. En auditorías cuenta si la operación y la documentación se realizan realmente. Si On‑Premise significa que, por falta de capacidad, no se aplican parches, no se rota claves o no se hacen pruebas de RESTauración, el riesgo de cumplimiento pronto se convierte en un asunto de dirección.

Patrones típicos de decisión y opciones híbridas sensatas

En la práctica rara vez hay blanco o negro. A menudo surgen modelos robustos mediante combinaciones:

• SaaS con control estricto de identidad y datos: SSO/MFA obligatorios, modelo de roles RESTrictivo, exportación a SIEM, reglas claras sobre subprocesadores, residencia de datos fijada contractualmente.
• On‑Premise para procesos clave con alta necesidad de protección: cuando la soberanía de los datos y la proximidad de integración dominan y usted dispone de la madurez operativa.
• Híbrido: los datos sensibles permanecen on‑prem (p. ej. en un almacenamiento de datos interno), SaaS aporta el flujo de trabajo/UX; las interfaces se diseñan de modo que sean posibles la minimización de datos y la seudonimización.

Para la adquisición es importante: Híbrido no es una vía de escape a la responsabilidad, sino que aumenta la complejidad de integración y gobernanza. A cambio, puede segmentar los flujos de datos de forma que los riesgos de cumplimiento disminuyan.

Plantilla de decisión: modelo de puntuación con aceptación de riesgo

Para las decisiones de comités ayuda un scoring sencillo que no pretenda que todo sea exactamente medible. Funciona bien una escala 0–3 por dimensión (0 = no cumplido, 3 = completamente cumplido) más criterios obligatorios. Dimensiones que típicamente se ponderan en compliance/soberanía de datos:

• Residencia de datos y control de subprocesadores
• Control de claves (BYOK/HYOK) y evidencias de cifrado
• Auditabilidad (logs, reports, informes de auditoría independientes)
• Identidad y acceso (capacidad SSO/MFA/PAM)
• BCP/DR (RTO/RPO, evidencias de RESTauración)
• Capacidad de salida (exportación, borrado, portabilidad)
• Operatividad (recursos, habilidades, runbooks, monitorización)

Importante es el último paso: si se elige un modelo aunque determinadas dimensiones no estén suficientemente cumplidas, se necesita una aceptación de riesgo documentada con plan de medidas, responsable y plazo. Sin esta disciplina, «SaaS vs. On‑Premise» se convertirá más adelante en una disputa sobre responsabilidades.

Conclusión: La elección correcta es la que usted domina de forma demostrable

SaaS vs. On‑Premise no es una cuestión de fe, sino de controles manejables. SaaS puede apoyar bien el cumplimiento y la soberanía de los datos cuando identidad, logging, control de subprocesadores, gestión de claves y planificación de salida están regulados de forma rigurosa. On‑Premise puede ofrecer la máxima soberanía de datos y control, pero exige madurez operativa, documentación, disciplina de parches y pruebas de RESTauración.

Si utiliza el marco descrito aquí – controles mínimos, RACI, plan de evidencias y capítulo de salida – obtendrá una decisión que no solo suena bien en la compra, sino que también se sostiene en la auditoría y en situación de crisis.

Para este tema también son importantes los requisitos de cumplimiento. El artículo ordena estos aspectos de forma comprensible y muestra en qué debe fijarse en el día a día.