Equipo Consultto
Especialistas en sistemas de gestión · 16 sep 2026
La migración se había celebrado como un éxito: el sistema de originación de créditos pasó del centro de datos propio a una plataforma en la nube en un fin de semana y el costo de infraestructura bajó a la mitad. Tres años después, durante la revisión de un socio comercial, alguien preguntó quién aplicaba los parches al sistema operativo de las máquinas virtuales, dónde estaban físicamente los respaldos y qué pasaba con los datos si se terminaba el contrato. El área de sistemas dio por hecho que eso lo resolvía el proveedor. El contrato decía otra cosa: el proveedor cuidaba la infraestructura física y la capa de virtualización, y todo lo que corría encima era responsabilidad del cliente. Durante tres años nadie lo había hecho.
Un servicio en la nube es cualquier recurso de cómputo, almacenamiento, plataforma o aplicación que la organización consume de un tercero a través de la red, sin operar la infraestructura que lo sostiene. El concepto que ordena todo lo demás es el modelo de responsabilidad compartida: una parte de los controles de seguridad la opera el proveedor y otra parte la opera el cliente, y la frontera entre ambas cambia según el tipo de servicio. Ningún modelo deja al cliente sin responsabilidades; lo que cambia es cuáles le quedan.
En infraestructura como servicio, el proveedor responde por el edificio, el hardware, la red física y la virtualización, y el cliente responde por el sistema operativo, los parches, la configuración de red virtual, las aplicaciones, las identidades y los datos. En plataforma como servicio, el proveedor sube hasta el sistema operativo y el entorno de ejecución, y el cliente conserva la aplicación, las identidades y los datos. En software como servicio, el proveedor opera casi todo, pero la configuración de accesos, la gestión de usuarios, la clasificación de lo que se sube y la decisión de qué datos se ponen ahí siguen siendo del cliente. La mayoría de las brechas en la nube no vienen de un fallo del proveedor sino de una configuración del cliente.
Hay un segundo matiz que casi nunca se documenta: la cadena. El proveedor de software que la empresa contrata a menudo corre sobre la infraestructura de otro proveedor, y ese a su vez subcontrata centros de datos o servicios de soporte. La organización necesita saber al menos quiénes son esos subprocesadores relevantes, en qué países tratan la información y cómo se entera cuando cambian, porque un cambio de región o de subprocesador puede alterar obligaciones legales o contractuales sin que nadie en la empresa lo haya decidido.
Lo primero es qué información va a la nube y con qué clasificación. Esa decisión condiciona todo lo demás: la región donde se alojan los datos, el cifrado exigido, quién administra las llaves, el nivel de disponibilidad necesario y los requisitos legales aplicables. Después viene la evaluación del proveedor, que no se resuelve con un cuestionario genérico: hay que revisar sus certificaciones y el alcance real de esas certificaciones, sus reportes de auditoría independiente, su historial de incidentes, sus mecanismos de notificación y la forma en que separa a sus clientes entre sí.
El contrato es el control principal, y conviene leerlo con la lista de riesgos en la mano. Debe dejar claro el reparto de responsabilidades, los niveles de servicio y sus consecuencias, la notificación de incidentes y su plazo, el derecho a auditar o a recibir evidencia equivalente, la ubicación de los datos, el tratamiento de subprocesadores, la devolución y el borrado de la información al terminar, y el plazo de transición para migrar a otro proveedor. Un contrato de adhesión estándar puede ser aceptable, pero la aceptación tiene que ser una decisión basada en riesgos y no un clic en una casilla.
Finalmente hay que planear la salida desde el primer día. La dependencia de un solo proveedor, conocida como bloqueo, es un riesgo en sí mismo: formatos propietarios, servicios que no existen en otra plataforma, costos de extracción de datos y plazos de migración irreales. La estrategia de salida no obliga a tener un segundo proveedor activo, pero sí a saber cómo se recuperarían los datos, en qué formato, en cuánto tiempo y con qué recursos, y a probar al menos la exportación de lo crítico.
La versión 2022 del Anexo A incorporó un control nuevo dedicado a la seguridad de la información en el uso de servicios en la nube. Pide que los procesos de adquisición, uso, gestión y salida de esos servicios se establezcan de acuerdo con los requisitos de seguridad de la organización. Eso implica una política o un procedimiento específico que cubra el ciclo completo del servicio: cómo se decide contratar, qué se evalúa, qué se exige contractualmente, cómo se gestiona durante su uso y cómo se termina la relación sin perder ni exponer información.
El control no trabaja aislado. Se apoya en los controles de relaciones con proveedores, que piden identificar riesgos, acordar requisitos en los contratos, gestionar la cadena de suministro de tecnología y vigilar los cambios en los servicios del proveedor. También en los de respaldo, registro de eventos, uso de criptografía, gestión de configuración, gestión de identidades y preparación de las tecnologías para la continuidad del negocio. Como guía adicional, la ISO/IEC 27017 detalla controles específicos para servicios en la nube y la ISO/IEC 27018 cubre la protección de datos personales en nubes públicas; no son obligatorias para certificarse en la 27001, pero muchos clientes las piden al proveedor.
Para el auditor, la pregunta clave es la trazabilidad. Cada servicio en la nube relevante debe estar en el inventario de activos o de proveedores, con su clasificación, su dueño, su análisis de riesgos y la matriz de responsabilidades que dice qué controles opera el proveedor y cuáles opera la organización. La declaración de aplicabilidad debe justificar por qué el control aplica y cómo se implementa, y el sistema tiene que producir evidencia de los controles que quedaron del lado del cliente: revisiones de configuración, revisiones de accesos, pruebas de restauración y seguimiento de las notificaciones del proveedor.
En servicios financieros, la autoridad suele exigir que la subcontratación de procesamiento o almacenamiento en la nube se sustente en un análisis de riesgos, que el contrato garantice el acceso del regulador a la información y que exista un plan de continuidad y de salida documentado, y en algunos casos pide aviso o autorización previa. Las obligaciones de protección de datos personales agregan la figura del encargado, la notificación de vulneraciones y las condiciones para transferir datos a otro país. Todo eso entra al sistema como requisito legal y debe evaluarse con la misma disciplina que los requisitos de la norma.
La nube entra a las empresas por muchas puertas a la vez: sistemas migra la infraestructura, recursos humanos contrata su plataforma de nómina, ventas su sistema de relación con clientes y finanzas su herramienta de facturación, cada uno con su tarjeta y su contrato de adhesión. Nadie tiene la lista completa y nadie sabe qué controles quedaron sin dueño. En la Ciudad de México, donde los corporativos, las instituciones financieras, las aseguradoras, las empresas de tecnología financiera y los centros de servicios compartidos tratan datos de millones de clientes y responden ante reguladores que piden evidencia de control sobre sus terceros, esa dispersión aparece en la primera revisión seria de proveedores. Ordenar el inventario, la matriz de responsabilidades y la evidencia de los controles propios es parte de lo que se estructura en la Consultoría ISO 9001 en Ciudad de México, donde la gestión de proveedores tecnológicos se integra al sistema y deja de depender de lo que cada área contrató por su cuenta.
Usar servicios en la nube no transfiere la responsabilidad de la seguridad: la reparte entre proveedor y cliente según el tipo de servicio, y la mayoría de los incidentes ocurren del lado que le toca al cliente. Antes de contratar hay que decidir qué información sube, evaluar al proveedor, negociar un contrato que cubra incidentes, ubicación, auditoría y salida, y planear cómo se recuperarían los datos. La ISO 27001 lo exige con un control dedicado al ciclo completo del servicio, apoyado en los controles de proveedores, respaldo, identidades y continuidad, y pide evidencia de que los controles propios realmente se operan.
Sin compromisos. Sin presentaciones genéricas. Te escuchamos, entendemos tu empresa y te decimos honestamente qué necesitas y cómo podemos ayudarte.
Hablemos