¿Por qué la seguridad de la nube de MSP falló de la noche a la mañana?
La seguridad en la nube de los MSP se desmoronó cuando las plataformas en la nube dejaron de ser simples proveedores para convertirse en entornos de responsabilidad compartida que deben gestionarse activamente. La norma ISO 27001 A.5.23 explicita este cambio al exigir que usted controle cómo selecciona, utiliza y abandona los servicios en la nube de acuerdo con su SGSI, en lugar de depender únicamente de los certificados del proveedor. Esta expectativa refleja el texto de la norma ISO 27001:2022 A.5.23 y las directrices generales de seguridad en la nube, que enfatizan procesos definidos para la adquisición, el uso, la gestión y la salida de los servicios en la nube, en lugar de depender únicamente de las garantías del proveedor, como se destaca en los comentarios sobre la norma ISO 27001 A.5.23.
Los servicios en la nube permitieron a su MSP crecer rápidamente, pero también expusieron brechas en la propiedad, la gobernanza y la evidencia que el antiguo modelo de proveedor nunca tuvo que resolver. Cuando clientes y auditores preguntan ahora quién es responsable de qué en la nube, la frase "el proveedor lo hace" ya no es suficiente. A.5.23 cristaliza esta tensión al exigir un enfoque controlado y documentado para el uso de la nube en lugar de la elección de plataformas ad hoc.
La nube sólo se convierte en una ventaja para los MSP cuando la responsabilidad se comparte deliberadamente y no se asume.
La nube ha superado su antigua mentalidad de "proveedor"
La nube ha superado la idea de firmar un contrato, confiar en un certificado y asumir que la seguridad se limita al borde del proveedor. Para los MSP, la norma A.5.23 les obliga a reconocer que las identidades, las configuraciones y las operaciones diarias en cada plataforma ahora son responsabilidad exclusiva de ustedes.
Muchos MSP aún tratan a los proveedores de la nube como proveedores tradicionales, y ahí es precisamente donde la norma A.5.23 empieza a fallar. Durante años, se podía firmar un contrato, confiar en las certificaciones, añadir un poco de monitorización y seguir adelante. Eso funcionaba cuando la nube consistía únicamente en alojamiento de correo electrónico o unas pocas máquinas virtuales.
Hoy en día, catálogos de servicios completos se ejecutan en plataformas de hiperescala, donde sus ingenieros desempeñan potentes roles administrativos y herramientas de automatización que interactúan con docenas de usuarios simultáneamente. En ese entorno, la idea de que "el proveedor gestiona la seguridad" deja de ser cierta. El proveedor de la nube protege su infraestructura y sus servicios principales, pero usted decide las identidades, las configuraciones, las integraciones y gran parte de la resiliencia operativa. Los clientes lo comprenden cada vez más y esperan que usted muestre cómo se definen las responsabilidades compartidas y cómo su equipo gestiona esos controles día a día.
A.5.23 es el punto donde la norma señala explícitamente ese cambio. Se espera que usted pase de una garantía genérica de proveedores a una gobernanza activa de cómo las plataformas en la nube respaldan sus servicios y a sus clientes.
La complejidad oculta de su pila de nube actual
La complejidad oculta de su pila de nube solo se hace evidente al escribirla. Un inventario breve y preciso suele revelar muchos más servicios, flujos de datos y roles administrativos de los que esperaba, que es precisamente lo que A.5.23 quiere que vea y gestione deliberadamente.
La mayoría de los MSP descubren que están ejecutando muchos más servicios, de muchas más maneras, de lo que nadie imaginaba:
- Herramientas SaaS internas para colaboración, tickets, CRM y finanzas.
- Plataformas de nube pública que potencian servicios de infraestructura administrada, respaldo, monitoreo y seguridad.
- Herramientas en la nube de nicho elegidas por equipos o ingenieros individuales para resolver problemas específicos.
En conjunto, estos servicios crean una red de ubicaciones de datos, roles de administrador, registros y modos de fallo. Sin una visión central, los riesgos se acumulan silenciosamente: un ingeniero gestiona la administración global de múltiples inquilinos, una herramienta SaaS temporal se vuelve crucial para el negocio, un servicio de copias de seguridad nunca se ha probado en escenarios reales de restauración. Una plataforma SGSI como ISMS.online puede ayudarle a mantener esa visión central para que la complejidad no quede oculta.
Para que el cambio sea concreto, es útil comparar la antigua mentalidad del proveedor con la gobernanza de la nube que espera A.5.23.
Una breve comparación muestra cómo debe cambiar su enfoque:
| Aspecto | Antiguo modelo de proveedor | A.5.23 Gobernanza de la nube para MSP |
|---|---|---|
| Vista del proveedor | “Un proveedor confiable se encarga de la seguridad”. | “Socio en un modelo definido de responsabilidad compartida”. |
| Alcance del control | Contrato más seguimiento básico | Ciclo de vida completo: selección, uso, cambio, salida |
| Pruebas que tienes | Certificados y contratos | Registros, registros de riesgos, matrices, artefactos del ciclo de vida |
| Propiedad dentro del MSP | Implícito, dependiente de la persona | Roles explícitos, manuales de ejecución e integración de SGSI |
Una vez que veas tu situación desde esta perspectiva, será más fácil decidir dónde necesitas estructura en lugar de soluciones más ad hoc.
Dónde los clientes y los auditores están exponiendo las grietas
Clientes y auditores están exponiendo las vulnerabilidades de su infraestructura en la nube al formular preguntas claras sobre servicios, datos y responsabilidades. Sus preguntas suelen revelar deficiencias en la propiedad, el ciclo de vida y la evidencia mucho antes de que se produzca una brecha o una interrupción. La gestión del riesgo de terceros y el seguimiento del cumplimiento de los proveedores fueron citados como uno de los principales desafíos por el 41 % de las organizaciones en la encuesta ISMS.online de 2025.
Las preguntas típicas incluyen:
- ¿Qué servicios en la nube utilizan en nuestro nombre y dónde se almacenan nuestros datos?
- ¿Quién es responsable de la copia de seguridad, la identidad, el registro y la configuración en cada plataforma?
- ¿Cómo se examinan, supervisan y, si es necesario, se abandonan los proveedores de nube?
- ¿Cómo nos apoyarán si queremos alejarnos de un servicio determinado?
Estas preguntas revelan dónde su enfoque actual es impreciso. Si sus respuestas dependen de quién esté en la reunión o requieren que alguien vaya a verificar, A.5.23 ya representa un problema. El control espera que usted cuente con procesos para adquirir, usar, administrar y abandonar los servicios en la nube de acuerdo con los requisitos de seguridad definidos. Para un MSP, esto significa pasar de una nube improvisada a una estructurada que auditores y clientes puedan probar.
Aquí es donde tener un registro vivo de los servicios en la nube, vinculado a los riesgos, responsabilidades y registros del ciclo de vida, se vuelve esencial en lugar de algo agradable de tener.
ContactoLo que realmente le pide la norma ISO 27001 A.5.23
La norma ISO 27001 A.5.23 exige que se trate la nube como un entorno de servicios gobernado con reglas, responsabilidades y evidencias claras, no como un conjunto impreciso de herramientas y proveedores. En la práctica, esto implica poder demostrar cómo se seleccionan, controlan y retiran los servicios en la nube de acuerdo con los requisitos de seguridad de la información.
El informe sobre el estado de la seguridad de la información de 2025 señala que los clientes generalmente esperan que los proveedores se alineen con marcos formales como ISO 27001, ISO 27701, GDPR, Cyber Essentials, SOC 2 y los estándares de inteligencia artificial emergentes.
En la edición de 2022, la norma A.5.23 establece que se deben establecer e implementar procesos para la adquisición, el uso, la gestión y la salida de los servicios en la nube, de acuerdo con los requisitos de seguridad de la información. Esta formulación es coherente con el texto de control publicado en la norma ISO 27001:2022 A.5.23 y con las directrices de soporte para la nube, como las normas ISO 27017 e ISO 27018, que priorizan la gobernanza integral de los servicios en la nube en lugar de controles puntuales de proveedores. Una plataforma centralizada de SGSI como ISMS.online facilita la gestión de este proceso al integrar las políticas, los riesgos, las responsabilidades y los registros en un solo lugar.
Los auditores suelen buscar una conexión clara entre ese texto de control y las políticas, procedimientos y registros reales. Si puede explicar con sus propias palabras qué significa la norma A.5.23 para su empresa, ya está por delante de muchos MSP que se basan únicamente en la redacción formal.
De una frase a objetivos prácticos
Convertir la norma A.5.23 en objetivos prácticos implica descomponer el texto formal en un conjunto reducido de expectativas concretas y comprobables, en torno a las cuales se pueden diseñar controles y evidencias. Estos objetivos proporcionan un marco para explicar el control a su equipo y a los auditores. Las interpretaciones de los profesionales de la norma ISO 27001 centrados en la nube suelen agrupar los requisitos de la norma A.5.23 en temas como política de la nube, riesgos y requisitos, responsabilidad compartida, ciclo de vida y evidencia, que es el enfoque que se refleja aquí.
En la práctica, A.5.23 espera que realice cinco cosas de forma consistente y pueda demostrarlas. Una forma útil de interpretar el control es dividirlo en cinco objetivos prácticos:
- Política y alcance de la nube – definir qué significa “nube” para su organización, qué servicios y datos están dentro del alcance y quién puede adoptar nuevos servicios.
- Riesgos y requisitos – identificar riesgos específicos de la nube, como multitenencia, ubicación y conectividad de datos, y establecer requisitos mínimos de seguridad y privacidad.
- Responsabilidad compartida – documentar quién es responsable de los controles clave entre el proveedor, el MSP y el cliente para cada plataforma y servicio principal.
- Gestión del ciclo de vida – incorporar seguridad en la selección, incorporación, cambio, monitoreo y salida de los servicios en la nube, no solo en los contratos.
- Evidencia y mejora – mantener registros que muestren que estos procesos están funcionando y revisarlos a medida que cambian las plataformas, los clientes y las regulaciones.
En conjunto, estos objetivos convierten A.5.23 de una simple frase en un conjunto de hábitos. Además, le proporcionan una estructura para integrar el control en su Declaración de Aplicabilidad y su SGSI en general. Registrar los objetivos, los responsables y la evidencia de apoyo en un sistema como ISMS.online le ayuda a mantener la coherencia a medida que evolucionan los servicios y los estándares.
Cómo A.5.23 amplía el antiguo modelo de proveedor
La norma A.5.23 amplía el antiguo modelo de proveedor al reconocer que la nube es una base técnica, no un simple contrato de externalización. Cuando sus servicios dependen de plataformas compartidas, sus decisiones de configuración, acceso y operaciones influyen considerablemente en los resultados de seguridad, incluso si la infraestructura subyacente pertenece a otro proveedor.
En comparación con los controles genéricos de proveedores en dominios como la gestión de proveedores y la seguridad de las operaciones, A.5.23:
- Hace hincapié en el ciclo de vida del servicio en la nube, no sólo en la selección del proveedor.
- Se espera una consideración explícita de la responsabilidad compartida y la multitenencia.
- Se centra en cómo saldrá o reemplazará los servicios en la nube sin perder el control de los datos.
Estos énfasis se reflejan en los comentarios especializados sobre el A.5.23 y en los mapeos de control de la nube, que destacan el ciclo de vida, la responsabilidad compartida y la planificación de salida, a diferencia de la supervisión tradicional de los proveedores. Para los MSP, el A.5.23 también se integra con el control de acceso, la gestión de activos, la gestión de incidentes y otros controles del Anexo A. El objetivo no es duplicar el trabajo, sino garantizar que sus controles actuales consideren plenamente la nube y la forma en que prestan servicios.
Vincular este control claramente a su SGSI ayuda a los auditores a ver que la gobernanza de la nube está integrada y no se trata como una vía separada.
Tipos de documentos que los auditores esperan ver
Los tipos de documentos que los auditores esperan ver para A.5.23 son aquellos que demuestran que sus políticas, procesos y responsabilidades en la nube son reales, consistentes y se aplican. Buscarán un conjunto pequeño y coherente de artefactos en lugar de un gran volumen de documentos vagamente relacionados. Las guías de implementación de gobernanza de la nube para A.5.23 suelen indicar una combinación de políticas, registros de servicios, evaluaciones de riesgos y registros del ciclo de vida como el conjunto de evidencias principal que esperan los auditores.
Durante una auditoría, es probable que le soliciten evidencia como:
- Una política de uso de la nube o de seguridad en la nube.
- Un registro de servicios en la nube utilizados internamente y en nombre de los clientes.
- Evaluaciones de riesgos específicos de la nube y planes de tratamiento.
- Registros de diligencia debida para proveedores clave de nube y subprocesadores.
- Matrices de responsabilidad compartida o definiciones de roles equivalentes.
- Procedimientos o manuales de estrategias para la incorporación y salida de servicios.
- Muestras de registros, revisiones o tickets que muestran estos procesos en funcionamiento.
Si se pueden localizar rápidamente y cuentan una historia coherente, A.5.23 se percibirá controlado y proporcionado. Si solo existen en documentos dispersos o en la mente de las personas, el control se convierte en una fuente de hallazgos y trabajo adicional. Usar una plataforma SGSI como ISMS.online para mantener estos artefactos en un solo lugar facilita enormemente mostrar cómo se gestiona la nube en la práctica.
ISO 27001 simplificado
Una ventaja del 81% desde el primer día
Hemos hecho el trabajo duro por ti y te damos una ventaja inicial del 81 % desde el momento en que inicias sesión. Todo lo que tienes que hacer es completar los espacios en blanco.
La doble vida del MSP: cliente y proveedor de la nube
Su MSP tiene una doble función según la norma A.5.23: es a la vez un cliente exigente de la nube de proveedores upstream y un proveedor de nube responsable ante sus propios clientes. El control espera que comprenda, documente y gestione ambas funciones, incluyendo cómo interactúan a lo largo de la cadena de responsabilidad compartida.
Como cliente de la nube, usted depende de plataformas de hiperescala y herramientas SaaS para gestionar su propio negocio y prestar servicios. Como proveedor de la nube, sus clientes lo ven como responsable de la seguridad, la continuidad y el soporte, incluso cuando la tecnología subyacente pertenece a terceros. A.5.23 integra estas dos perspectivas y le exige gestionarlas de forma coherente.
Comprender sus roles ascendentes y descendentes
Comprender sus roles ascendentes y descendentes implica reconocer que consume servicios en la nube como cliente interno, a la vez que vende servicios basados en la nube como proveedor a sus propios clientes. A.5.23 espera que tenga en cuenta ambas perspectivas y se asegure de que se complementen, en lugar de contradecirse.
Como titular de cliente de la nubeUsted consume servicios como suites de productividad, gestión de tickets, plataformas de monitorización e infraestructura de nube pública. Usted es responsable de cómo se configuran esos servicios, quién tiene acceso y cómo se monitorizan. Cuando ocurren incidentes o los reguladores plantean preguntas, su capacidad para demostrar control depende de la eficacia con la que gestione dicho consumo y de la claridad con la que esté vinculado a los procesos de su SGSI, como la evaluación de riesgos y la gestión de cambios.
Como titular de proveedor o administrador de la nubeUsted diseña, entrega y da soporte a servicios que se ejecutan en estas plataformas. Puede vender infraestructura administrada, copias de seguridad, SOC, alojamiento de aplicaciones o servicios de seguridad. Sus clientes lo ven como responsable, incluso si desarrolla en una nube de terceros. No distinguen entre su servicio y el hiperescalador en el que se ejecuta; asumen que usted se ha encargado de los detalles.
Una desalineación común surge cuando se establecen compromisos con los clientes sobre la retención de registros o el historial de copias de seguridad, pero una herramienta de origen sigue funcionando con su configuración predeterminada, mucho más corta. En ese caso, el compromiso de origen ha superado la configuración de origen, y la versión A.5.23 revelará esa brecha.
Construyendo una visión de responsabilidad de doble rol
Desarrollar una visión de responsabilidad dual implica mapear las responsabilidades entre los proveedores, los equipos de MSP y los clientes en un modelo único y coherente. Esto proporciona a su CISO, responsable de prestación de servicios y gerentes de cuentas una visión compartida de quién es responsable de qué en toda la cadena.
Una forma práctica de lograrlo es crear una matriz de responsabilidad con dos roles. En las áreas de control clave (gestión de identidades y accesos, configuración, registro, copias de seguridad, respuesta a incidentes, control de cambios y protección de datos), se enumeran:
- A qué se comprometen sus proveedores upstream.
- Lo que usted, como MSP, se compromete a hacer desde el principio (por ejemplo, habilitar ciertas funciones o gestionar ciertos riesgos).
- A qué se compromete posteriormente en sus contratos con los clientes y en sus acuerdos de nivel de servicio.
- Lo que esperas que los clientes hagan por sí mismos.
Este ejercicio suele revelar desajustes: obligaciones con clientes que no cuentan con soporte previo o suposiciones sobre proveedores que no están respaldadas por sus contratos. También aclara dónde se necesitan controles más sólidos, una redacción más clara o diseños de servicios diferentes. Al integrar esta visión en una plataforma de SGSI como ISMS.online, se proporciona a los equipos una fuente única de información veraz sobre las responsabilidades compartidas.
Convertir los mapas de responsabilidad en una práctica diaria
Implementar los mapas de responsabilidad en la práctica diaria implica garantizar que todos los que interactúan con los servicios en la nube comprendan los aspectos que les afectan y puedan actuar con rapidez. Los mapas deberían orientar el comportamiento en ventas, ingeniería, soporte y gestión de cuentas.
Hacer realidad los mapas de responsabilidad significa:
- Utilizándolos para informar a los equipos de ventas y cuentas, para que no prometan demasiado ni improvisen compromisos.
- Alinear los runbooks y playbooks con las responsabilidades que ha definido, para que los equipos técnicos actúen de manera consistente.
- Capacitar a los ingenieros sobre cómo y cuándo ejercer sus derechos en los inquilinos de los clientes, incluida la elevación y las aprobaciones sujetas a plazos.
- Acordar cómo se comunicarán y manejarán con los clientes los incidentes que involucren a los proveedores, incluidas las vías de escalamiento.
Al integrar su visión de doble rol de esta manera, A.5.23 deja de ser un requisito abstracto y se convierte en una perspectiva natural sobre cómo opera su MSP en la nube. Además, le proporciona una narrativa clara para las juntas directivas y los clientes que desean comprender su lugar en la cadena de responsabilidad compartida.
Un modelo práctico de responsabilidad compartida para plataformas de nube MSP
Un modelo práctico de responsabilidad compartida para plataformas MSP en la nube consiste en un conjunto de matrices claras que muestran quién hace qué entre el proveedor, el MSP y el cliente para cada servicio. Según A.5.23, estas matrices convierten la idea de responsabilidad compartida en algo que se puede implementar, enseñar y auditar.
La mayoría de los proveedores de nube pública describen una división simple: ellos protegen la infraestructura; usted protege lo que construye sobre ella. Este patrón está documentado en las explicaciones del modelo de responsabilidad compartida de importantes proveedores como AWS, Azure y Google Cloud, y se ha convertido en una base común para el diseño del control de la nube. Para los MSP, este es solo el punto de partida. Necesita modelos que reflejen las plataformas específicas que utiliza, los servicios que ofrece y la forma en que sus equipos operan.
Más allá de la genérica “responsabilidad conjunta”
Ir más allá de las etiquetas genéricas de "responsabilidad conjunta" implica sustituir las declaraciones vagas por tareas específicas y definidas que las personas y los equipos comprendan. La norma A.5.23 premia esta claridad, ya que los auditores y los clientes pueden ver quién es responsable de las acciones reales, no solo de conceptos abstractos.
Las etiquetas genéricas de "responsabilidad conjunta" ocultan riesgos reales. Para superarlos, es necesario considerar:
- Las plataformas específicas que utiliza (por ejemplo, infraestructura como servicio, software como servicio, herramientas de seguridad administradas).
- Los servicios específicos que ofrece (por ejemplo, copia de seguridad administrada, SOC administrado, lugar de trabajo moderno administrado).
- La forma en que realmente opera su equipo (por ejemplo, uso de automatización, monitoreo centralizado, ventanas de mantenimiento).
Para cada combinación de plataforma y servicio, una matriz de responsabilidades debe definir las responsabilidades con suficiente detalle para que las personas puedan actuar. Esto implica nombrar quién habilita el registro, quién prueba las restauraciones, quién gestiona las solicitudes de acceso de los interesados y quién gestiona la comunicación de incidentes, en lugar de simplemente indicar "compartido".
Dar este paso adicional también respalda los controles relacionados, como la gestión de incidentes y la seguridad de las operaciones, porque todos pueden ver dónde comienza y termina su función.
Estructurando sus matrices de responsabilidad
Estructurar bien sus matrices de responsabilidad implica utilizar un diseño coherente que refleje la forma de pensar de sus ingenieros y gerentes de servicio, a la vez que sea lo suficientemente detallado como para guiar la acción. Una estructura simple, repetida en todos los servicios, facilita considerablemente la capacitación y la revisión.
Una matriz práctica para cada servicio podría cubrir dominios como:
- Gestión de identidades y accesos: – quién crea y revoca cuentas, administra roles y revisa el acceso.
- Configuración y endurecimiento: – quién aplica las líneas base, maneja las actualizaciones de seguridad y revisa las desviaciones de configuración.
- Registro y seguimiento: – quién habilita los registros, los almacena, revisa las alertas y responde a los incidentes.
- Copia de seguridad y recuperación: – quien configura las copias de seguridad, prueba las restauraciones y verifica los objetivos de recuperación.
- Protección de datos y privacidad: – quién clasifica los datos, aplica las reglas de retención y gestiona los derechos de los interesados.
- Continuidad y salida: – quién es responsable de los patrones de resiliencia, la conmutación por error y la exportación o eliminación de datos al final de un contrato.
En cada fila, la matriz debe indicar claramente las responsabilidades: proveedor, MSP, cliente o compartidas con tareas específicas asignadas. También debe asegurarse de que cada matriz tenga control de versiones y se revise cuando cambien los servicios, las plataformas o los contratos, para que mantenga su precisión a lo largo del tiempo.
Un ejemplo simplificado de copia de seguridad administrada en una plataforma de nube pública podría verse así:
| Dominio | Responsabilidades del proveedor/MSP/cliente |
|---|---|
| Configuración de respaldo | El proveedor ofrece funciones; **MSP** configura políticas; las revisiones de los clientes son un alcance |
| Restaurar pruebas | **MSP** realiza restauraciones de prueba periódicas; el cliente valida la integridad de los datos |
| Configuración de retención | El proveedor aplica límites; **MSP** establece retención; el cliente aprueba la política |
Luego, puede reutilizar estas matrices en distintos clientes que utilizan el mismo patrón de servicio, ajustándolas solo cuando sea realmente necesario.
Vinculando el modelo a su SGSI y a sus clientes
Vincular el modelo de responsabilidad compartida con su SGSI y sus clientes garantiza que influya en las decisiones desde la preventa hasta la salida, en lugar de permanecer aislado. Cuanto más lo conecte, más útil y creíble será.
Una vez que haya definido estos modelos, conéctelos:
- Internamente, haciendo referencia a ellos en políticas, procedimientos, manuales de instrucciones y capacitación.
- Comercialmente, alineando sus descripciones de servicios, propuestas y SLA con las responsabilidades que ha establecido.
- Con los clientes, compartiendo vistas simplificadas o diagramas durante la incorporación, para que las expectativas estén claras desde el primer día.
Cuando un auditor le pregunte cómo gestiona la responsabilidad compartida según A.5.23, puede señalar estas matrices, su relación con su SGSI y ejemplos de cómo han guiado decisiones reales. Cuando un cliente, como un CISO o un responsable de TI, pregunta "¿quién posee este control?", obtendrá una respuesta coherente en toda la empresa. Una plataforma central como ISMS.online puede alojar estas matrices junto con los riesgos, controles y contratos, para que sean fáciles de mantener y documentar.
Libérate de una montaña de hojas de cálculo
Integre, amplíe y escale su cumplimiento normativo, sin complicaciones. IO le brinda la resiliencia y la confianza para crecer con seguridad.
Diseño de procesos del ciclo de vida del servicio en la nube para A.5.23
Los procesos del ciclo de vida de los servicios en la nube demuestran que la norma A.5.23 es más que una simple declaración de política: demuestran que se seleccionan, ejecutan y retiran los servicios en la nube de forma controlada y repetible. Para un MSP, el objetivo es integrar los pasos del ciclo de vida de la nube en los procesos existentes de su SGSI, no crear una burocracia independiente.
A.5.23 espera que demuestre que los servicios en la nube siguen pasos definidos desde la concepción hasta su salida, considerando la seguridad y la responsabilidad compartida en cada etapa. Esto se ajusta estrechamente al lenguaje propio del control en torno a la "adquisición, uso, gestión y salida" de los servicios en la nube, de acuerdo con los requisitos de seguridad de la información, y con los modelos comunes de ciclo de vida utilizados en la norma ISO 27001 y las directrices de las normas de la nube, como el comentario de la norma ISO 27001 A.5.23. Esto se alinea naturalmente con las cláusulas de la norma ISO 27001 sobre tratamiento de riesgos, planificación operativa, gestión de cambios y gestión de proveedores.
Definición de un ciclo de vida del servicio en la nube que las personas puedan seguir
Definir un ciclo de vida de servicios en la nube que las personas puedan seguir implica convertir la norma A.5.23 en un conjunto reducido de etapas repetibles que se adapten a sus métodos de trabajo actuales. El ciclo de vida debe ser lo suficientemente simple como para que los propietarios de productos, ingenieros y equipos de compras puedan aplicarlo sin conocimientos especializados. Dos tercios de las organizaciones que participaron en la encuesta sobre el estado de la seguridad de la información de ISMS.online de 2025 afirman que la velocidad y el volumen de los cambios regulatorios dificultan el cumplimiento normativo.
Un ciclo de vida típico para servicios de nube importantes podría incluir etapas como:
- Idea y evaluación Alguien propone un nuevo servicio en la nube o una nueva forma de usar uno existente. Se evalúa su valor comercial, seguridad y cumplimiento normativo.
- Selección y diligencia debida – verifica las certificaciones, la ubicación de los datos, los términos contractuales y las capacidades de soporte, y compara las opciones.
- Diseño e incorporación – usted decide cómo se configurará, integrará y supervisará el servicio, y quién será su propietario.
- Operación y cambio – usted ejecuta el servicio, revisa registros y métricas, maneja cambios e incidentes y mantiene la configuración alineada con sus estándares.
- Revisión y renovación – revisa periódicamente si el servicio todavía satisface las necesidades, si los riesgos son aceptables y si se necesitan mejoras.
- Salida o sustitución – Si desactiva o reemplaza el servicio, usted se encargará de la exportación y eliminación de datos y de la comunicación con el cliente.
Estas etapas permiten que las decisiones sobre servicios en la nube sean repetibles en lugar de improvisadas. Para cada una, defina las acciones, aprobaciones y registros mínimos que espera. Esto podría incluir evaluaciones de riesgos, listas de verificación de diligencia debida, líneas base de configuración, registros de cambios y confirmaciones de salida, todo ello alineado con su SGSI central.
Para que esto sea aún más utilizable, puede expresar el ciclo de vida como un conjunto simple de pasos que los equipos deben seguir.
Paso 1: Capturar y filtrar la idea
Capture y analice cada idea de servicio en la nube antes de que alguien la registre o la integre, para que pueda evaluar el valor, el riesgo y la alineación con su SGSI.
Registre el servicio en nube propuesto, su propósito y los riesgos iniciales antes de que alguien lo registre o lo integre.
Paso 2: Completar la debida diligencia y el diseño
Realice la debida diligencia y el diseño antes de adoptar un servicio en la nube, de modo que la configuración, la supervisión y las responsabilidades se definan en lugar de improvisarse.
Verificar el aseguramiento, los contratos y el manejo de datos, luego definir la configuración, el monitoreo y las responsabilidades compartidas.
Paso 3: Incorporarse, operar y planificar la salida
Abordar, operar y planificar la salida de forma estructurada, de forma que se pueda demostrar cómo se controla el servicio a lo largo de su vida.
Incorpore el servicio de acuerdo con sus líneas base, monitoréelo y registre cómo lo abandonará o lo reemplazará de manera segura.
Integración de controles del ciclo de vida en su forma de trabajar
Integrar controles del ciclo de vida en su forma de trabajar significa integrarlos en los procesos y herramientas que sus equipos ya utilizan. Cuando el ciclo de vida es la ruta predeterminada, el cumplimiento de la norma A.5.23 se vuelve mucho más fácil de mantener.
Considerar:
- Alinearlo con los flujos de trabajo de adquisiciones, de modo que no se puedan firmar contratos hasta que se verifiquen los requisitos de seguridad, privacidad y operativos.
- Vincularlo a su proceso de introducción de servicios, para que las nuevas ofertas o los cambios importantes pasen por las puertas del ciclo de vida de la nube.
- Integración de tareas del ciclo de vida en sus sistemas de tickets y cambios, no solo en documentos en la nube separados.
Al conectar los pasos del ciclo de vida con procesos establecidos, como la gestión de cambios y la gestión de proveedores, se reduce la fricción y se mejora la adopción. Las personas siguen el ciclo de vida porque es el camino de menor resistencia, no porque se les haya dicho que lean otra política.
Preparar la evidencia del ciclo de vida para la auditoría
Preparar la evidencia del ciclo de vida para la auditoría implica poder mostrar algunos ejemplos completos que demuestren la misma lógica aplicada a diferentes servicios. Los auditores buscan patrones, no éxitos puntuales.
Para cada ejemplo, intente demostrar:
- Por qué se eligió el servicio, en función del riesgo y los requisitos.
- Cómo se definieron las responsabilidades, utilizando su modelo de responsabilidad compartida.
- ¿Qué controles se implementaron durante la incorporación, incluidas las líneas de base y los patrones de acceso?
- Cómo se supervisa y revisa el servicio, con ejemplos de cambios o mejoras.
- Cómo se gestionarán los datos y el acceso al momento de la salida, incluso si dicha salida aún no se ha producido.
Si puede presentar esta evidencia sin grandes complicaciones, A.5.23 se sentirá integrado en lugar de añadido. Un sistema como ISMS.online puede ayudar al vincular servicios, riesgos, responsabilidades, cambios y registros de salida en un solo lugar, para que no tenga que volver a crear la imagen desde cero cada vez que alguien lo solicite.
Controles técnicos multiinquilino: Implementación de medidas de seguridad consistentes
Los controles técnicos multiusuario son la expresión práctica de sus decisiones de gobernanza de la nube A.5.23 en el trabajo diario de ingeniería. Traducen los modelos de responsabilidad compartida y los procesos del ciclo de vida en bases de referencia concretas que protegen a muchos clientes simultáneamente.
Al gestionar múltiples inquilinos en plataformas comunes, A.5.23 espera que adopte un enfoque proactivo y estandarizado en cuanto a identidad, configuración, registro, copias de seguridad y aislamiento. De esta manera, podrá demostrar que sus medidas de seguridad técnicas se ajustan a las responsabilidades asumidas y a los compromisos adquiridos con los clientes.
Por qué son importantes las líneas base multiinquilino
Las bases de referencia multiinquilino son importantes porque pequeñas debilidades pueden tener importantes consecuencias para muchos clientes a la vez. Un solo rol demasiado permisivo, una actualización omitida o una copia de seguridad sin probar podrían socavar su infraestructura general de seguridad en la nube. Los marcos de seguridad en la nube y las directrices nacionales, como los debates sobre riesgos multiinquilino en los catálogos de control y las recopilaciones de seguridad en la nube de los centros nacionales de ciberseguridad, destacan sistemáticamente la gestión de identidades, la aplicación de parches y las copias de seguridad como áreas de riesgo sistémico que pueden escalar rápidamente entre inquilinos cuando fallan. La mayoría de las organizaciones que participaron en la encuesta ISMS.online de 2025 informaron haberse visto afectadas por al menos un incidente de seguridad relacionado con terceros o proveedores durante el último año.
En un entorno MSP, una cuenta de administrador con privilegios excesivos, una acción crítica sin registrar o un proceso de copia de seguridad sin probar pueden afectar a decenas de clientes en un solo incidente. A.5.23 espera que gestione estos riesgos de forma sistemática, no reactiva, y que pueda demostrar cómo se aplican sus controles a los servicios en la nube que utiliza y ofrece. Unas líneas de base consistentes definen los controles mínimos establecidos para cualquier cliente que utilice una plataforma o servicio determinado y ofrecen a auditores y clientes la seguridad de que no está reinventando la seguridad constantemente.
Desde una perspectiva de liderazgo, estas líneas de base también brindan una historia de garantía: puede mostrar a las juntas directivas y a los clientes que las salvaguardas técnicas se alinean con las decisiones contractuales y de gobernanza que ya ha tomado.
Temas técnicos centrales para estandarizar
Los temas técnicos centrales a estandarizar son las áreas donde las protecciones consistentes reducen la probabilidad de problemas entre inquilinos y brindan a los ingenieros un punto de partida claro en cada plataforma.
Si bien los detalles varían según la plataforma, la mayoría de los MSP se benefician de estandarizar al menos los siguientes temas. Esto facilita que el jefe de seguridad, el responsable de operaciones y los equipos de ingeniería trabajen en la misma dirección.
- Gestión de identidades y accesos: – acceso basado en roles, mínimos privilegios, separación de funciones, elevación con límite de tiempo para acciones de alto riesgo y salida robusta.
- Configuración y endurecimiento: – plantillas de referencia para segmentación de red, cifrado, protección de puntos finales, políticas de parches y denominación de recursos.
- Registro y seguimiento: – configuraciones de registro consistentes, agregación central de registros, reglas de alerta definidas y manuales de respuesta documentados.
- Copia de seguridad y recuperación: – programas de respaldo estándar, retención, cifrado, rutinas de pruebas de restauración y documentación de los objetivos de recuperación del cliente.
- Aislamiento y tenencia: – patrones para separar a los inquilinos en las capas de red, identidad y datos, y controles para verificar que se mantenga el aislamiento.
Cada línea base debe indicar claramente qué ofrece el proveedor, qué configura y mantiene usted, y qué espera que hagan los clientes. En conjunto, estos temas se convierten en la columna vertebral técnica de su implementación de A.5.23.
Después de definir estos temas, el siguiente paso es integrarlos en el lugar donde viven los ingenieros: plantillas, scripts, infraestructura como código, herramientas de administración central y manuales documentados.
Conexión de los controles técnicos a A.5.23 y más allá
La conexión de los controles técnicos con la norma A.5.23 y los controles relacionados garantiza que la gobernanza, los compromisos legales y las prácticas de ingeniería se complementen entre sí, evitando discordancias. Esta alineación facilita la explicación y la defensa del sistema en su conjunto.
Eso significa:
- Asignar cada elemento de línea base a sus matrices de responsabilidad compartida, de modo que los controles técnicos coincidan con las responsabilidades que ha asignado.
- Garantizar que las líneas de base sean parte del ciclo de vida de su servicio en la nube, de modo que se apliquen en el momento de la incorporación y se revisen durante las revisiones.
- Vincular temas como acceso, registro y respaldo con los controles del Anexo A sobre control de acceso, seguridad de operaciones, gestión de incidentes y continuidad del negocio.
Esta alineación proporciona coherencia a su sistema de control general. También significa que, cuando se discuta el tema A.5.23 durante auditorías o revisiones de clientes, estará listo para mostrar no solo políticas, sino también salvaguardas técnicas funcionales que se ajustan a su estrategia de gobernanza. Si gestiona estas líneas base en un sistema central como ISMS.online, podrá demostrar la conexión desde un servicio en la nube hasta su evaluación de riesgos y sus controles técnicos, con solo unos clics.
Gestione todo su cumplimiento, todo en un solo lugar
ISMS.online admite más de 100 estándares y regulaciones, lo que le brinda una única plataforma para todas sus necesidades de cumplimiento.
Contratos, SLA y cláusulas de subprocesador que superan la auditoría
Los contratos, los SLA y las cláusulas de subencargado del tratamiento de datos constituyen el punto en el que sus decisiones de gobernanza en la nube (A.5.23) se convierten en compromisos legalmente vinculantes. El control espera que sus acuerdos con proveedores, subencargados del tratamiento de datos y clientes reflejen la responsabilidad compartida, el ciclo de vida y las decisiones técnicas que ha tomado, en lugar de contradecirlos.
El A.5.23 no exige que se redacten los contratos de una manera específica, pero los auditores y clientes comprobarán si sus compromisos legales y su realidad técnica coinciden. La guía basada en principios sobre el A.5.23 y los controles de la nube relacionados enfatiza sistemáticamente la importancia de alinear las promesas contractuales con los controles reales y los modelos de responsabilidad compartida, ya que la falta de alineamiento es la causa de muchos hallazgos y disputas de auditoría.
El apartado A.5.23 no exige que se redacten los contratos de una manera específica, pero los auditores y clientes comprobarán si sus compromisos legales y su realidad técnica coinciden. De no ser así, el control se convierte en una fuente de riesgo y hallazgos.
Establecer responsabilidades y expectativas explícitas en contratos y SLA implica traducir las matrices de responsabilidad internas a un lenguaje claro y estable que los departamentos legales, de ventas y de clientes puedan comprender. El apartado A.5.23 es mucho más fácil de demostrar cuando esos documentos se ajustan a su forma de operar.
Los contratos y los SLA son el punto donde los malentendidos se convierten en disputas, especialmente cuando se trata de servicios en la nube. Para cumplir con la norma A.5.23, sus acuerdos deben:
- Describa los servicios claramente, incluida cualquier dependencia de plataformas en la nube de terceros.
- Establezca las obligaciones de seguridad y protección de datos con suficiente detalle para que sean significativas, sin prometer lo que no puede cumplir.
- Explique quién es responsable de qué aspectos de la detección, respuesta y comunicación de incidentes.
- Aclarar qué sucede al final del contrato, incluida la exportación o eliminación de datos y cualquier soporte de transición.
Siempre que sea posible, adapte este lenguaje directamente a los dominios de sus matrices de responsabilidad compartida, de modo que exista una conexión clara entre el modelo y la redacción. Esto también contribuye al cumplimiento de los requisitos de la norma ISO 27001 en materia de obligaciones legales, regulatorias y contractuales.
Una vez que las responsabilidades están explícitas tanto en las matrices como en los contratos, sus equipos tienen menos espacio para interpretaciones conflictivas cuando surgen incidentes o demandas complejas de los clientes.
Alinear la realidad técnica con los compromisos legales
Alinear la realidad técnica con los compromisos legales implica verificar que lo prometido en los contratos sea alcanzable con las herramientas, procesos y parámetros actuales. Esto reduce el riesgo de que los clientes o auditores detecten discrepancias entre lo que dicen y lo que hacen. Solo alrededor del 29 % de las organizaciones que participaron en la encuesta ISMS.online de 2025 afirmaron no haber recibido multas por fallos en la protección de datos; la mayoría declaró multas y algunas se enfrentaron a sanciones superiores a 250 000 libras esterlinas.
Es fácil que las cláusulas legales se desvíen de la realidad técnica con el tiempo. Quizás una plantilla promete una notificación de incidentes muy rápida, pero sus procesos de monitorización y escalamiento dificultan esta tarea en la práctica. O bien, un acuerdo de nivel de servicio (SLA) se compromete con objetivos de recuperación que no se ajustan a los diseños de respaldo.
Para evitar esto, revise sus contratos y acuerdos de nivel de servicio (SLA) conjuntamente con los departamentos legal, de seguridad, de operaciones y de gestión de cuentas. Pregunte:
- ¿Podemos cumplir consistentemente con los compromisos que estamos asumiendo, dado nuestro monitoreo actual, horas de soporte y bases técnicas?
- ¿Existen áreas en las que necesitamos invertir en mejores controles o herramientas para cumplirlos?
- ¿Existen obligaciones que deberían recaer en el cliente o el proveedor y ser comunicadas como tales?
Cuando sus compromisos legales y capacidades técnicas están alineados, el A.5.23 se vuelve más fácil de demostrar y menos arriesgado. También reduce la probabilidad de sorpresas para clientes, reguladores o auditores que analizan a fondo sus promesas.
Incorporando la gobernanza en sus acuerdos
Incorporar la gobernanza en sus acuerdos significa usar el lenguaje contractual para reforzar la forma en que desea que se comporten los proveedores y los clientes, no solo documentar los servicios y los precios. Esto puede integrar la responsabilidad compartida y el enfoque del ciclo de vida en la relación diaria.
Eso podría incluir:
- Derecho a recibir o revisar la garantía del proveedor, como certificaciones actualizadas o informes independientes.
- Expectativas en torno a la participación en ejercicios conjuntos de incidentes o de continuidad.
- Obligaciones de notificar cambios significativos de servicio o ubicación.
- Requisitos para seguir los procesos de salida acordados, incluidos los plazos y la cooperación.
Al integrarlos en sus contratos, garantiza que la gobernanza no sea solo un asunto interno. Se convierte en parte de la forma en que usted, sus proveedores y sus clientes colaboran durante la vida del servicio. Cuando los auditores evalúan el estándar A.5.23, pueden ver que el ciclo de vida y la responsabilidad compartida se reflejan de forma coherente en sus acuerdos, no solo en sus políticas.
Reserve una demostración con ISMS.online hoy mismo
Reservar una demostración con ISMS.online es una forma práctica de ver cómo su MSP puede controlar la gobernanza de la nube A.5.23 sin añadir complejidad a sus equipos. En un solo lugar, puede ver cómo se conectan los servicios en la nube, los riesgos, las responsabilidades, los pasos del ciclo de vida y la evidencia, para estar listo para auditorías, preguntas de clientes y revisiones de la junta directiva.
La gobernanza de la nube A.5.23 se controla al reemplazar documentos dispersos y decisiones ad hoc con un sistema único y coherente que vincula servicios, riesgos, responsabilidades, etapas del ciclo de vida y evidencia. Para muchos MSP, usar una plataforma SGSI específica como ISMS.online puede ser una forma práctica de lograr dicha consolidación sin añadir complejidad.
ISMS.online le ayuda a integrar sus responsabilidades de gobernanza de la nube A.5.23 en un único sistema integrado que conecta inventarios de la nube, modelos de responsabilidad compartida, flujos de trabajo del ciclo de vida, contratos y evidencias. En lugar de buscar documentos en diferentes unidades, consolas y bandejas de entrada, puede ver cómo se gobiernan los servicios en la nube y cómo se gestionan las responsabilidades desde un solo lugar.
Para los MSP, esto significa mostrar a auditores, juntas directivas y clientes una narrativa más clara y coherente: qué servicios en la nube utilizan, cómo se reparten las responsabilidades, qué controles existen y cómo cambian estos acuerdos con el tiempo. Quienes analizan las herramientas de gobernanza, riesgo y cumplimiento (GRC) suelen señalar que las plataformas centralizadas facilitan la creación y la coherencia de este tipo de narrativa, ya que integran riesgos, controles y evidencia en un solo entorno. Usted mantiene el control de las decisiones; la plataforma le ayuda a demostrar ese control de forma consistente, a medida que su negocio crece y los estándares evolucionan.
Vea su nivel de nubes en una sola vista
Ver su nube en una sola vista facilita que su CISO, líder de operaciones y equipos de atención al cliente respondan preguntas difíciles sin problemas. A.5.23 deja de ser un ejercicio de cumplimiento normativo y se convierte en una forma sencilla de describir su verdadero trabajo.
Al centralizar la gobernanza de la nube en una plataforma SGSI, usted y su equipo cuentan con un único punto de referencia para A.5.23. Pueden:
- Mantener un registro en vivo de los servicios en la nube internos y orientados al cliente.
- Vincular cada servicio a riesgos, controles, matrices de responsabilidad y etapas del ciclo de vida.
- Adjunte contratos, diligencias debidas, registros de cambios y evidencia de salida directamente a los servicios a los que se relacionan.
En conjunto, estas capacidades facilitan enormemente la respuesta a las preguntas de los auditores, las revisiones de seguridad de los clientes y los responsables internos de la toma de decisiones que desean comprender cómo se gestiona la nube. Ya no depende de la memoria ni de hojas de cálculo dispares para gestionar su nube.
Da el siguiente paso con confianza
Si reconoce a su MSP en los desafíos descritos aquí (responsabilidades difusas, evidencia dispersa, creciente presión de clientes y auditores), explorar una plataforma como ISMS.online en una demostración breve y específica es un siguiente paso práctico. A pesar de la creciente presión, casi todos los encuestados en la encuesta sobre el Estado de la Seguridad de la Información de 2025 consideran la obtención o el mantenimiento de certificaciones de seguridad como ISO 27001 o SOC 2 como una prioridad absoluta.
Puede ver cómo respalda sus herramientas y formas de trabajo existentes al tiempo que le brinda la estructura que A.5.23 espera.
Elija ISMS.online si busca un único lugar donde almacenar el registro, las responsabilidades, los riesgos y las pruebas de sus servicios en la nube para demostrar, y no solo afirmar, que A.5.23 está bajo control. Si valora una gobernanza clara, auditorías más fluidas y una imagen más sólida para clientes y juntas directivas, nuestro equipo está listo para ayudarle a comprender cómo se aplica esto en su entorno.
ContactoPreguntas frecuentes
¿Qué espera realmente la norma ISO 27001:2022 A.5.23 de un MSP que utiliza servicios en la nube?
La norma ISO 27001:2022 A.5.23 espera que su MSP Gobernar activamente el ciclo de vida completo de cada servicio en la nube del que dependeNo se limite a recopilar certificados de proveedores y esperar que todo salga bien. Debe poder demostrar, de forma rápida y consistente, qué usa, por qué lo usa, qué podría salir mal, quién posee qué controles y cómo podría salir sin perder datos ni servicio.
¿Cómo se ve la evidencia “buena” A.5.23 para un MSP?
Los auditores y los clientes informados suelen buscar una pequeño haz coherente de evidencia, no un archivo gigantesco. Para un MSP, el conjunto básico generalmente incluye:
- Una limpieza uso de la nube / política de seguridad en la nube
Esto define qué se considera “nube” en su mundo (IaaS, SaaS, PaaS, servicios de seguridad administrados), quién puede aprobar nuevos servicios y sus expectativas mínimas de configuración, monitoreo y salida.
- A registro de servicios en la nube que cubre:
- herramientas internas (RMM, PSA, tickets, facturación, CRM, monitoreo, transferencia segura de archivos); y
- Servicios orientados al cliente (plataformas IaaS, Microsoft 365 y otras suites SaaS, backup/DR, SOC/XDR, firewalls administrados y WAF).
- Evaluaciones y tratamientos de riesgos específicos de la nube:
Estos deben mencionar la exposición multiinquilino, los potentes roles entre inquilinos, la residencia de datos, la dependencia de proveedores, las dependencias de API y la gestión de claves. Los riesgos deben vincularse con controles reales y acciones de mejora.
- Registros de diligencia debida: para proveedores clave y subprocesadores
Normalmente, esto incluye resúmenes de seguridad, certificaciones (por ejemplo, ISO 27001, SOC 2), DPA, historial de actividad, historial de infracciones y limitaciones o exclusiones conocidas que afectan sus diseños.
- Matrices de responsabilidad compartida:
Para cada servicio principal, muestre qué hace el proveedor, qué hace su MSP y qué debe hacer el cliente. El lenguaje debe ser lo suficientemente concreto como para que un ingeniero o cliente pueda ver "mis tareas" sin una segunda reunión.
- Registros del ciclo de vida del servicio en la nube:
Evidencia de que la selección, la incorporación, la configuración, el cambio, la revisión periódica y la salida se manejan de manera controlada y repetible en lugar de a través de tickets ad hoc.
Si estos elementos están integrados y son fáciles de navegar, A.5.23 se percibe como un sistema controlado y creíble. Usar ISMS.online para mantener las políticas, las entradas de riesgos, los registros de proveedores, las matrices de responsabilidad y la evidencia del ciclo de vida en un único espacio de trabajo de ISMS significa que no tendrá que reconstruir su infraestructura en la nube a partir de búsquedas en la bandeja de entrada y capturas de pantalla de la consola cada vez que un auditor o cliente plantee la cláusula.
¿Cómo debería un MSP construir un modelo de responsabilidad compartida utilizable para la nube según A.5.23?
Se satisface la intención de A.5.23 cuando la “responsabilidad compartida” se convierte en una Mapa de tareas reales, servicio por servicioNo es solo una diapositiva de marketing que dice "tanto nosotros como el proveedor nos preocupamos por la seguridad". Cualquiera que la lea (ingeniero, vendedor, revisor de contratos o cliente) debería poder ver exactamente lo que posee.
¿Cómo convertir la “responsabilidad compartida” en algo concreto?
Un patrón práctico que funciona bien para los MSP es:
1. Catalogue sus servicios en la nube por categoría
Comencemos con una lista corta de objetivos:
- Cargas de trabajo de nube pública (IaaS/PaaS).
- Suites de productividad SaaS (Microsoft 365, Google Workspace y similares).
- Servicios gestionados de backup y recuperación ante desastres.
- Servicios gestionados de SOC/XDR y detección de amenazas.
- Otras herramientas recurrentes basadas en la nube de las que depende para administrar su negocio o prestar servicios.
Esta lista generalmente refleja las entradas en su registro de servicios en la nube, lo que hace que sea más fácil mantener las cosas alineadas.
2. Elija un conjunto común de dominios de seguridad
Elija un pequeño conjunto de dominios que se apliquen a la mayoría de sus servicios, como:
- Gestión de identidad y acceso.
- Configuración base y endurecimiento.
- Registro, monitoreo y alertas.
- Rutinas de backup, restauración y prueba.
- Cifrado y gestión de claves.
- Detección, triaje y respuesta a incidentes.
- Gestión de cambios y aprobaciones.
- Retención, residencia y eliminación de datos.
Seguir un conjunto estándar hace que el modelo sea más fácil de entender y reutilizar en distintos servicios.
3. Asignar propiedad por dominio, por servicio
Para cada servicio y cada dominio de seguridad, decida quién hace realmente el trabajo en la práctica:
- Proveedor de la nube: – resiliencia de la infraestructura, seguridad física, la mayoría de los parches de la plataforma subyacente, algunas opciones de almacenamiento de registros.
- Su MSP: – líneas de base de configuración de inquilinos, enrutamiento de alertas, programaciones de respaldo, pruebas de restauración, clasificación de incidentes, informes de clientes.
- Cliente: – comportamiento del usuario, uso aceptable, clasificación de datos, aprobación de acceso, decisiones sobre el ciclo de vida del contenido.
Cuando se comparten responsabilidades, anote la división como Tareas específicas, no etiquetas vagas de "conjunto". Por ejemplo:
- “El cliente aprueba el período de retención; el MSP implementa y revisa la configuración trimestralmente”.
- “El MSP revisa las alertas de seguridad; el proveedor gestiona la respuesta a incidentes a nivel de plataforma”.
4. Integrar el modelo en las operaciones diarias
Una matriz de responsabilidades solo es importante si se refleja en el lugar de trabajo de las personas. Asegúrese de:
- Referenciarlo en manuales de ejecución y manuales de estrategias, para que los ingenieros puedan ver qué hacer durante incidentes y cambios.
- Alineación Descripciones de servicios estándar y SoW con él, para que las ventas no prometan tareas que no estás realizando.
- Reflejarlo en contratos y SLA, de modo que los compromisos legales coincidan con la realidad técnica y las capacidades de los proveedores ascendentes.
- Incluirlo en paquetes de incorporación, para que los nuevos clientes comprendan qué acciones permanecen en ellos y cuáles son las que le resultan familiares a usted.
El mantenimiento centralizado de estas matrices en ISMS.online (vinculadas a los servicios de su registro en la nube, las entradas de riesgo y los registros de proveedores) le permite actualizar una matriz una vez y que el cambio se propague a los manuales de ejecución, la documentación y la evidencia de auditoría. Esto facilita enormemente demostrar que la norma A.5.23 funciona en la práctica, no solo en un documento de políticas.
¿Qué riesgos específicos de la nube destaca A.5.23 para los MSP y dónde tienden a descuidarse?
Para los MSP, A.5.23 trata menos sobre historias genéricas de "vulneraciones de la nube" y más sobre Expectativas desalineadas, debilidades de configuración y control deficiente del ciclo de vida En entornos compartidos, los problemas suelen surgir cuando las promesas de marketing, las capacidades del proveedor y el comportamiento del equipo no coinciden.
¿En qué aspectos suelen quedar atrapados los MSP?
Los patrones que causan problemas repetidamente incluyen:
Dependencia excesiva de las suposiciones de seguridad del proveedor
Es fácil hablar de "seguridad por diseño" asumiendo que tareas como las pruebas de restauración, la revisión de registros, la búsqueda de amenazas o el reforzamiento a nivel de inquilino están incluidas en una suscripción a la nube. En realidad, muchas de esas actividades son... Su responsabilidad como MSPy, a veces, parcialmente, de su cliente. Cuando no se reflejan en sus matrices de responsabilidad y manuales de ejecución, rara vez se ejecutan de forma consistente.
Acceso privilegiado excesivo y mal gobernado
Los MSP suelen desempeñar funciones importantes (cuentas de administración global, portales de socios, identidades de seguridad) que abarcan a muchos inquilinos. Si estos derechos carecen de una sólida aprobación, registro y revisión, una sola credencial comprometida o una cuenta mal utilizada puede convertirse en un incidente multiinquilino significativo. A.5.23 espera que usted reconozca este riesgo en sus registros de activos y riesgos, y que establezca controles claros al respecto.
SaaS no registrado o “en la sombra”
Los equipos adoptan herramientas SaaS que gestionan datos confidenciales o de clientes (para soporte, colaboración, desarrollo, ventas o automatización) sin añadirlos a su SGSI, registro de proveedores ni procesos de riesgo. Estos servicios quedan entonces fuera de sus planes de monitorización, respuesta a incidentes y salida.
Planes de salida débiles o no probados
Muchos MSP solo piensan en la salida cuando un proveedor anuncia el retiro de un producto, un cambio importante de precios o una interrupción. Sin un plan de salida registrado, que incluya la exportación de datos, la migración, la retención de evidencias y la comunicación con el cliente, se está improvisando justo cuando se necesita el mayor control.
Acuerdos de nivel de servicio que prometen demasiado
Los contratos a veces comprometen objetivos de recuperación, periodos de retención o especificaciones de residencia de datos que la plataforma subyacente no puede garantizar. Cuando el diseño del servicio, las características del proveedor de la nube y el lenguaje del contrato no coinciden, se corre un riesgo innecesario.
A.5.23 le ofrece un marco para abordar estas cuestiones sistemáticamente:
- Inventariar y clasificar los servicios en la nube: para que sepas dónde se concentra el riesgo.
- Realizar evaluaciones de riesgos específicas de la nube que abordan problemas de múltiples inquilinos, acceso privilegiado y modos de falla del proveedor.
- Mantenimiento matrices de responsabilidad De esta manera, las tareas se asignan, se poseen y se revisan.
- Evidencia pasos del ciclo de vida – desde la incorporación hasta la salida – para que las personas puedan ver que los cambios, las revisiones y las salidas son eventos controlados, no reacciones.
Cuando puede rastrear un riesgo (por ejemplo, acceso excesivo al portal de socios) desde su registro hasta las matrices de responsabilidad y luego para cambiar los registros y tomar acciones de mejora, no solo cumple con A.5.23, sino que también presenta un historial de riesgo en la nube mucho más sólido a los auditores y clientes.
¿Cómo puede un MSP documentar A.5.23 en su SGSI sin rediseñar todo?
Generalmente puedes cubrir A.5.23 mediante Incorporación de la gobernanza específica de la nube a su SGSI existenteEn lugar de construir una estructura paralela, el objetivo es que cualquier persona familiarizada con la norma ISO 27001 pueda seguir cómo se seleccionan, controlan y retiran los servicios en la nube con la misma facilidad con la que pueden seguir los activos o proveedores tradicionales.
¿Cómo integrar la gobernanza de la nube en lo que ya tienes?
Un patrón simple pero efectivo es comenzar con tres componentes conectados y luego conectarlos a su SGSI existente:
1. Uso de la nube / política de seguridad en la nube
Amplíe su conjunto de políticas de seguridad de la información existentes con un documento específico que:
- Define lo que califica como un servicio en la nube en su contexto.
- Establece umbrales de aprobación (por ejemplo, quién puede autorizar a un nuevo proveedor).
- Establece expectativas en cuanto a la debida diligencia, líneas de base de configuración, monitoreo, manejo de incidentes y salida.
Esta política se convierte en el ancla para los procedimientos y registros relacionados.
2. Registro de servicios en la nube
Cree un registro, a menudo una lista de activos o proveedores de ISMS.online, que capture, como mínimo:
- Nombre y proveedor del servicio.
- Propietario interno.
- Propósito comercial.
- Tipos de datos manejados y ubicaciones de los datos.
- Criticidad e impacto de la pérdida.
- Enlaces a contratos, DPAs, certificaciones y matrices de responsabilidad.
Puede integrar esto con su inventario de activos existente para que los servicios en la nube no vivan en un universo separado.
3. Matrices de responsabilidad compartida
Para los servicios más importantes, cree y mantenga matrices de responsabilidad como se describió anteriormente. Céntrese inicialmente en:
- Su plataforma de nube pública principal.
- Su principal suite SaaS de productividad y colaboración.
- Su oferta insignia de backup y recuperación ante desastres gestionada.
- Su SOC/XDR administrado o soluciones de seguridad como servicio similares.
Luego puede conectar estos componentes a los elementos del SGSI que ya utiliza:
- Gestión de riesgos: – vincular los servicios en la nube con las entradas y tratamientos de riesgo, especialmente cuando existen escenarios de fallas de múltiples inquilinos o proveedores.
- Administración de suministros: – adjuntar contratos, resúmenes de seguridad, DPA e informes de auditoría a los proveedores pertinentes; registrar revisiones y decisiones periódicas.
- Controles operativos: – haga referencia a los pasos de incorporación, cambio, revisión y salida específicos de la nube dentro de sus procesos existentes de gestión de cambios y manejo de incidentes.
- Gestión de evidencias: – vincular incidentes, resultados de pruebas de respaldo, revisiones de acceso y acciones de mejora con las entradas y riesgos de la nube relevantes.
El uso de ejemplos prácticos (por ejemplo, un SaaS interno, una solución orientada al cliente basada en la nube pública y una plataforma específica, pero crucial) le ayuda a demostrar a los auditores que el patrón es repetible sin tener que documentar individualmente cada servicio menor. ISMS.online está diseñado para este tipo de modelado: políticas, registros, riesgos, proveedores, tareas y evidencia se integran, con enlaces que facilitan el seguimiento de la gobernanza de la nube.
¿Qué contratos y SLA debe alinear un MSP para demostrar A.5.23 a los clientes?
Para demostrar A.5.23 de manera convincente, es necesario tanto sus acuerdos upstream como downstream Para que coincida con su gestión real del riesgo en la nube. Esto significa que sus contratos y acuerdos de nivel de servicio (SLA) con proveedores y subencargados del tratamiento de datos, así como sus condiciones con los clientes, deben incluir la misma distribución de responsabilidades y capacidades que documenta en su SGSI.
¿Qué se debe verificar en los acuerdos con proveedores ascendentes y subencargados del tratamiento?
Revise las partes de cada acuerdo que afectan directamente sus servicios y reclamaciones:
- Compromisos de seguridad y disponibilidad: – asegúrese de que los objetivos de RPO/RTO, los SLA de tiempo de actividad y la durabilidad de los datos se alineen con la forma en que diseña los servicios y las promesas de sus propios SLA.
- Declaraciones de ubicación y residencia de datos: – debe poder responder "¿dónde están nuestros datos?" con confianza, incluidas las ubicaciones de las copias de seguridad y las regiones de conmutación por error.
- Notificación y escalada de incidentes: – comprobar cómo y cuándo los proveedores se comprometen a informarle sobre incidencias que puedan afectar a sus clientes.
- Soporte para controles clave: – confirmar si las funciones como el registro detallado, las claves de cifrado administradas por el cliente, las copias de seguridad inmutables o los controles de acceso avanzados en los que confía están explícitamente disponibles y son compatibles.
- Mecanismos de garantía: – identificar certificaciones, informes de garantía, resúmenes de pruebas de penetración o derechos de auditoría contractuales que pueda utilizar como evidencia dentro de su propio SGSI y los informes de clientes.
Es posible que no necesite renegociar todos los contratos, pero debe comprender y documentar dónde los compromisos de un proveedor no están a la altura de sus descripciones de servicios actuales y ajustar sus propias ofertas o arquitecturas en consecuencia.
¿Cómo deberían cambiar los contratos de los clientes y los SLA para reflejar el punto A.5.23?
Posteriormente, los documentos que dirige al cliente deben:
- Identificar claramente Qué servicios dependen de qué plataformas en la nube, especialmente cuando esto afecta la ubicación, la resiliencia o el soporte de los datos.
- Explicar ¿Quién es responsable de qué áreas de control? – como aprobaciones de acceso de usuarios, uso aceptable, clasificación, retenciones legales y ciclo de vida del contenido, de acuerdo con sus matrices de responsabilidad compartida.
- Comprometerse a objetivos de recuperación, períodos de retención y plazos de comunicación de incidentes que sus acuerdos y diseños upstream puedan entregarse de manera confiable.
- Referencia o enlace a Información sobre responsabilidad y dependencia de una manera que los clientes puedan entender sin tener que leer su SGSI.
Cuando los contratos upstream, las matrices de responsabilidad interna y los SLA downstream coinciden, es mucho más fácil explicar a un cliente o auditor cómo gestionar el riesgo en la nube según A.5.23. Gestionar estos documentos dentro de ISMS.online, junto con sus políticas y riesgos, le ayuda a mantener la coherencia a medida que los proveedores actualizan sus condiciones, las regulaciones evolucionan y los clientes se vuelven más exigentes.
¿Cómo puede un MSP utilizar ISMS.online para mantener A.5.23 bajo control a medida que cambian los servicios en la nube?
ISMS.online le ayuda a mantener A.5.23 bajo control al convertir la gobernanza de la nube en una Sistema conectado y actualizado continuamenteEn lugar de un conjunto de documentos estáticos que se quedan atrás de los cambios en su pila de datos, a medida que adopta, modifica o retira servicios en la nube, su visión del SGSI puede mantenerse actualizada, auditable y explicable.
¿Cómo es la gestión diaria del A.5.23 en ISMS.online?
En una configuración típica, su equipo utilizaría ISMS.online para:
Mantener un registro de servicios en la nube en vivo
- Registre cada servicio en la nube con su propietario, propósito, tipos de datos, ubicaciones de datos y criticidad.
- Servicios de etiquetas utilizados internamente versus aquellos utilizados para brindar servicios administrados.
- Vincular cada entrada con políticas, riesgos, proveedores y matrices de responsabilidad relevantes.
Adjuntar y realizar un seguimiento de los riesgos y tratamientos específicos de la nube
- Cree entradas de riesgo para exposición a múltiples inquilinos, cuentas potentes entre inquilinos, residencia de datos, bloqueo de proveedores y dependencias de API.
- Asignar tratamientos, propietarios y fechas de revisión.
- Utilice el trabajo y los proyectos vinculados de la plataforma para realizar un seguimiento de las acciones de mejora y remediación.
Almacene contratos, certificaciones y diligencia debida en un solo lugar
- Cargue contratos de proveedores, DPA, resúmenes de seguridad e informes de garantía directamente en los registros de proveedores.
- Revise los resultados y las decisiones de la revisión, de modo que pueda demostrar que el riesgo del proveedor se gestiona a lo largo del tiempo.
Centralizar matrices de responsabilidad compartida
- Mantener una matriz autorizada por cada servicio de nube o familia de servicios principal.
- Vincular matrices a políticas, descripciones de servicios, entradas de riesgo y registros de proveedores.
- Úsalos como puntos de referencia al actualizar manuales de ejecución, acuerdos de nivel de servicio y materiales de incorporación.
Actividades del ciclo de vida de la evidencia
- Selección de registros, incorporación, aprobaciones de línea base de configuración, revisiones de cambios, reevaluaciones periódicas y pasos de salida como tareas o elementos de trabajo vinculados.
- Asociar incidentes relacionados, pruebas de respaldo, revisiones de acceso y mejoras con los servicios y riesgos relevantes.
Al incorporar una nueva plataforma, puede clonar una entrada existente, ajustar la configuración y las responsabilidades, y conectarla con los riesgos y proveedores en cuestión de minutos. Al retirar un servicio, puede registrar las decisiones de migración de datos, saneamiento y retención de evidencia en un mismo lugar.
Para auditorías, cuestionarios para clientes o sesiones de consejo, puede recopilar un paquete de evidencias A.5.23 específico directamente desde ISMS.online: la política de la nube, el registro actual, ejemplos de matrices de responsabilidad, riesgos y tratamientos clave de la nube, la debida diligencia del proveedor y una muestra de registros de ciclo de vida e incidentes. Esta capacidad de contar con una visión integral y consistente es lo que hace que un MSP parezca tener el control de la gobernanza de la nube en lugar de reaccionar constantemente. Si desea que clientes y auditores lo consideren en ese primer grupo, invertir en la correcta estructuración de A.5.23 dentro de ISMS.online es un siguiente paso muy rentable.
