Los 14 principales marcos normativos de seguridad en la nube en 2026

Principales conclusiones

• Las normas de seguridad en la nube se clasifican en cinco tipos de aplicación, que van desde las certificaciones y las declaraciones de conformidad hasta las normativas, los contratos y los marcos de control.
• La norma ISO/IEC 27017 ha sido objeto de su primera revisión completa desde 2015, FedRAMP ha redactado de nuevo su reglamento y la CSA ha publicado la versión 4.1 del CCM.
• Las correcciones aparecen en casi todas las normas, pero solo unas pocas establecen un plazo límite estricto para ellas.
• La mayor parte de los problemas relacionados con las auditorías se acumulan entre una evaluación y otra, mientras que se van acumulando los parches pendientes y las configuraciones se van desviando.

Gran parte de lo que sustenta el funcionamiento de una empresa moderna se basa ahora en una infraestructura que no le pertenece, y ese cambio ha modificado quién es el responsable de la seguridad. Además, ha multiplicado el número de normativas que debe cumplir el equipo de seguridad tiene que cumplir al mismo tiempo. Las normas de seguridad en la nube son, en definitiva, esos conjuntos de normas plasmados por escrito.

En este artículo se explica qué son las normas de seguridad en la nube, por qué es importante el tipo de norma y cuáles son las 14 más relevantes para los programas de cumplimiento normativo en la nube en 2026.

¿Qué es la seguridad en la nube?

Seguridad en la nube es el conjunto de controles que protegen las cargas de trabajo, las identidades y los datos en entornos en la nube, lo que normalmente significa servidores gestionados por terceros. Abarca la configuración, el cifrado, la gestión de accesos, la aplicación de parches y la supervisión en IaaS, PaaS y SaaS. En IaaS, el proveedor se encarga de los hosts físicos y del hipervisor, mientras que tú eres propietario de casi todo, desde el sistema operativo invitado en adelante. En SaaS, el proveedor gestiona la mayor parte de la pila, por lo que tu labor se limita a la identidad, la configuración de los inquilinos y el uso que los usuarios hacen de los datos. PaaS se sitúa entre ambos.

¿Qué son las normas de seguridad en la nube?

Las normas de seguridad en la nube son requisitos publicados que definen qué se considera «suficientemente seguro» en la nube y proporcionan a los auditores y a las autoridades reguladoras un criterio concreto con el que realizar sus evaluaciones. Algunas incluyen un certificado real que caduca y se renueva. Otras generan un informe de certificación en lugar de una calificación de «aprobado» o «suspenso». Algunas tienen carácter legal y conllevan multas en caso de incumplimiento. Otras son directrices voluntarias que las organizaciones adoptan porque así se lo indica un cliente, un auditor o su propia evaluación de riesgos.

Esa última categoría se solapa con lo que la gente suele llamar marcos de seguridad en la nube: el CSF del NIST, la Matriz de Controles en la Nube (CCM) de la CSA y otros conjuntos de referencia similares creados a modo de orientación más que de certificación. El solapamiento es real y se da en ambos sentidos. Muchas recopilaciones de «normas» incluyen el CSF del NIST y la CCM, a pesar de que ambas se definen como voluntarias.

En esta guía se utiliza el término «estándar» como término genérico para referirse a los requisitos de seguridad en la computación en la nube en sentido amplio, y clasifica cada entrada según cómo se aplica realmente (certificación, declaración, normativa, requisito contractual o marco de control), en lugar de trazar una línea divisoria clara entre «normas» y «marcos».

Por qué son importantes las normas de seguridad en la nube

Hay dos razones: condicionan los ingresos y condicionan el riesgo. Muchos compradores empresariales no firmarán hasta que se haya presentado un informe SOC 2 o un certificado ISO. Además, las autoridades reguladoras pueden tomar medidas contra ti por incumplimientos del RGPD o la HIPAA, independientemente de que cuentes con un certificado o no.

Para las organizaciones que dan prioridad al cumplimiento normativo, las normas aportan algo más concreto que una simple muestra de buenas intenciones. Convierten la afirmación «nos tomamos la seguridad muy en serio» en un lenguaje de control que un organismo regulador, un auditor o un equipo de compras puede comprobar de forma efectiva.

Una visión realista: Superar una auditoría no garantiza que tus controles funcionen correctamente todos los días entre una y otra. Las auditorías de vigilancia de la norma ISO 27001 suelen realizarse una vez al año, y un periodo de observación de SOC 2 Tipo II puede durar por sí solo casi todo un año. Entre esos puntos de control, se acumulan los parches pendientes, las configuraciones se desvían y se ponen en marcha nuevos servicios fuera del alcance de la última auditoría. Sin una supervisión continua, gran parte de ello no saldrá a la luz hasta la próxima evaluación. Nuestra lista de amenazas a la seguridad en la nube abarca lo que suele acumularse en ese intervalo.

Las 14 principales normas de seguridad en la nube

El tipo de norma que estés considerando determina qué medidas debes tomar al respecto. Confundir estos cinco tipos es lo que lleva a los equipos a prometer a un cliente un «certificado ISO 27017» que no existe como tal, o a decirle a un auditor que cuentan con la «certificación NIST CSF», cuando el CSF no cuenta con ningún programa de certificación.

1. ISO/IEC 27017 (Edición de 2026)

La ISO y la IEC se encargan conjuntamente de la gestión de esta norma a través de su comité técnico conjunto sobre seguridad de la información, y la edición de 2026 supone una auténtica remodelación, no una simple actualización. Publicada en julio de 2026, sustituye por completo a la original de 2015 y adapta la norma a la estructura de control de la norma ISO/IEC 27002:2022, en lugar de la estructura de 2013 en la que se basaba.

La edición de 2015 incluía siete controles adicionales para la nube con números CLD, que abarcaban aspectos como el refuerzo de la seguridad de las máquinas virtuales y la devolución de los activos del cliente al finalizar el contrato. La edición de 2026 reduce a cuatro las adiciones específicas para la nube: el reparto básico de la responsabilidad compartida entre el proveedor y el cliente, un acuerdo sobre las funciones y responsabilidades de cualquier socio de servicios en la nube implicado, como un intermediario o un auditor que forme parte de la cadena de suministro, la segregación en entornos informáticos virtuales y la detección y prevención del uso no autorizado de la nube.

La mayor parte de las directrices sobre la nube que quedan se presentan ahora como notas específicas sobre la nube, incorporadas a los propios controles pertinentes de la norma ISO/IEC 27002:2022.

Al igual que antes, no existe un certificado independiente para este aspecto. Se audita como parte de una certificación ISO/IEC 27001 cuyo alcance incluye los servicios en la nube. Si tu documentación de cumplimiento sigue citando el antiguo conjunto de siete controles por sus números CLD, se está haciendo referencia a una estructura obsoleta, y es muy probable que un evaluador que trabaje con la edición de 2026 lo señale.

Resulta especialmente útil para los proveedores de servicios en la nube que desean demostrar su madurez en materia de control a los compradores empresariales, así como para los clientes que desean que la separación de funciones en una relación de servicios en la nube quede plasmada en un documento más concreto que una simple conversación comercial.

2. SOC 2

La norma SOC 2 procede de la AICPA y funciona de forma diferente a la mayoría de los elementos de esta lista. Una empresa de contabilidad autorizada examina tus controles y emite un informe de opinión. No existe ninguna insignia oficial de «certificado SOC 2», por mucho que pueda dar a entender la página de inicio de un proveedor.

La evaluación se realiza con arreglo a los Criterios de Servicios de Confianza de 2017, con los puntos clave revisados que la AICPA publicó en 2022 para mantener la guía actualizada frente a las nuevas tecnologías y amenazas. Los criterios subyacentes en sí mismos no han cambiado desde 2017. Hay cinco categorías: seguridad, disponibilidad, integridad del procesamiento, confidencialidad y privacidad. La seguridad es obligatoria en todos los informes SOC 2, y el resto se añade en función de lo que se haya comprometido con los clientes.

Los informes de tipo I describen el diseño de los controles en un momento concreto. Los informes de tipo II describen la eficacia operativa a lo largo de un periodo, normalmente de entre tres y doce meses, y son los que suelen solicitar los compradores empresariales. Nuestra guía para cumplir y mantener el cumplimiento de la norma SOC 2 aborda la tensión existente entre los compromisos de tiempo de actividad y los plazos para la aplicación de parches.

3. RGPD

RGPD, cuyo nombre oficial es el Reglamento (UE) 2016/679, se aplica a las organizaciones establecidas en la UE, así como a aquellas situadas fuera de la UE que ofrezcan bienes o servicios a personas residentes en la UE o que supervisen el comportamiento de estas. En lo que respecta específicamente a la nube, la distinción entre responsable y encargado del tratamiento es fundamental. Es necesario disponer de un acuerdo de tratamiento de datos, de garantías documentadas para las transferencias fuera del Espacio Económico Europeo y de un procedimiento que permita al responsable del tratamiento notificar a la autoridad de control sin demora injustificada y, cuando sea posible, en un plazo de 72 horas desde que tenga conocimiento de una violación sujeta a notificación. Los encargados del tratamiento, por su parte, deben informar a los responsables sin demora injustificada.

Las multas máximas ascienden a 20 millones de euros o el 4 % de la facturación anual global, lo que sea mayor.

4. HIPAA

La Ley de Portabilidad y Responsabilidad del Seguro Médico (HIPAA) establece las normas básicas para la protección de la información sanitaria en EE. UU., y su cumplimiento lo supervisa la Oficina de Derechos Civiles del Departamento de Salud y Servicios Humanos (HHS). Al igual que el RGPD, se trata de una ley y no de un marco voluntario. Se aplica a las entidades sujetas a la ley (proveedores de asistencia sanitaria, planes de salud y centros de intercambio de información sanitaria) y a sus socios comerciales. Un proveedor de servicios en la nube que cree, reciba, mantenga o transmita información sanitaria protegida en formato electrónico (ePHI) en nombre de una entidad sujeta a la ley es un socio comercial, incluso si nunca consulta los datos.

Un acuerdo de socio comercial (BAA) detalla las responsabilidades de cada parte y obliga contractualmente al proveedor a proteger la información médica protegida electrónica (ePHI). Un proveedor de servicios en la nube que desempeñe esa función también es directamente responsable de cumplir con los requisitos aplicables de la HIPAA, y dicha responsabilidad no depende del BAA.

Los requisitos técnicos se recogen en la Norma de Seguridad: control de acceso, controles de auditoría, integridad, seguridad de la transmisión y análisis de riesgos. Una propuesta de actualización eliminaría la distinción actual entre especificaciones «obligatorias» y «recomendadas» y haría obligatorios el cifrado, la autenticación multifactorial y un inventario documentado de activos tecnológicos, con solo unas excepciones limitadas. A fecha de octubre de 2026, dicha norma definitiva aún no se ha publicado. La agenda normativa del HHS señala ahora julio de 2027 como fecha prevista, después de que se dejara pasar la fecha anterior fijada para mayo de 2026.

5. PCI DSS

El Consejo de Normas de Seguridad PCI publica este documento, y la versión actual es la v4.0.1. Aunque el nombre incluye la palabra «estándar», su cumplimiento es de carácter contractual. Son tu banco adquirente y las entidades emisoras de las tarjetas quienes velan por su cumplimiento, no un organismo regulador gubernamental.

Las fechas relevantes en este caso ya han pasado. La versión 4.0 introdujo una serie de nuevos requisitos, y los 51 que tenían una fecha de entrada en vigor futura pasaron a ser obligatorios el 31 de marzo de 2025. Todos ellos ya están en vigor, sin que quede ningún periodo de gracia al que recurrir.

La norma PCI DSS también cuenta con uno de los requisitos más explícitos en materia de aplicación de parches de esta lista. El requisito 6.3.3 establece que los parches para vulnerabilidades críticas deben aplicarse en el plazo de un mes desde su publicación, mientras que el resto de parches aplicables deben ajustarse al plazo que la entidad establezca en función de su propia clasificación de riesgos. La redacción original de la versión 4.0 ampliaba ligeramente ese plazo de un mes para incluir también los parches de alta gravedad. El consejo volvió a limitarlo a las vulnerabilidades críticas en la versión 4.0.1, que es el requisito actual, más restrictivo. El requisito 11.3.1 exige, por separado, la realización de análisis internos de vulnerabilidades al menos una vez cada tres meses y tras cualquier cambio significativo.

6. ISO/IEC 27001 (Edición de 2022)

A diferencia de las normas ISO/IEC 27017 y 27018, la norma ISO/IEC 27001 te proporciona un certificado auténtico e independiente. Un organismo de certificación acreditado audita tu sistema de gestión de la seguridad de la información y expide un certificado con una validez de tres años, con auditorías de vigilancia anuales que garantizan su cumplimiento durante ese periodo.

La revisión de 2022 modificó considerablemente el anexo A, reduciendo el número de controles de 114 a 93 y agrupándolos en cuatro temas. Junto con esa reestructuración, se introdujeron once controles totalmente nuevos, entre los que se incluyen la inteligencia sobre amenazas, la seguridad de la información para los servicios en la nube y la prevención de fugas de datos.

El plazo de transición desde la edición de 2013 finalizó el 31 de octubre de 2025, y los certificados que aún se rigen por la edición de 2013 ya no son válidos. Si tu organización no ha realizado la transición, deberá someterse a una nueva auditoría de certificación inicial, en lugar de a una auditoría de transición más sencilla.

7. ISO/IEC 27018 (Edición de 2025)

Esta norma, gestionada por el mismo comité de la ISO/IEC que la ISO/IEC 27017, comparte una estructura similar. No es certificable de forma independiente. Se trata de una guía que complementa un SGSI basado en la norma ISO/IEC 27001, y algunos organismos de certificación la tendrán en cuenta junto con la auditoría de la norma 27001. Actualmente se encuentra en su tercera edición, publicada en agosto de 2025 para sustituir a la versión de 2019, con sus controles reajustados a la norma ISO/IEC 27002:2022 y un nuevo anexo B añadido.

Mientras que el 27017 aborda la seguridad en la nube en términos generales, la norma 27018 aborda en profundidad un aspecto concreto: la protección de la información de identificación personal (PII) en las nubes públicas en las que el proveedor actúa como encargado del tratamiento de dicha información. Esto incluye el consentimiento, la limitación de la finalidad, la divulgación de cualquier subencargado del tratamiento, la transparencia sobre dónde se tratan y almacenan los datos, y su supresión una vez finalizada la relación.

Es la solución ideal para los proveedores de nube pública que buscan un conjunto de controles de privacidad reconocido que se ajuste perfectamente a las obligaciones de los encargados del tratamiento establecidas en el RGPD.

8. CSA STAR y la Matriz de Controles en la Nube

La Cloud Security Alliance gestiona ambos elementos aquí, y es fácil confundirlos. La Cloud Controls Matrix es el propio marco de controles. STAR es el programa de garantía que se basa en él. La versión 4.1 de la CCM se publicó a finales de enero de 2026 con 11 nuevos controles, lo que eleva el total a 207 repartidos en los mismos 17 ámbitos.

STAR cuenta con tres niveles. El nivel 1 consiste en una autoevaluación gratuita basada en el cuestionario CAIQ, cuyos resultados se publican en un registro público al que cualquiera puede acceder. El nivel 2 añade una evaluación independiente realizada por terceros, que a menudo se lleva a cabo en paralelo a un proceso de certificación según la norma ISO 27001 o SOC 2 ya en marcha. La CSA también describe un nivel 3 basado en la auditoría continua, pero las entradas del registro que realmente encontrarás corresponden al nivel 1 y al nivel 2.

El valor práctico reside en el propio registro. Si estás evaluando a un proveedor de servicios en la nube que haya publicado información en STAR, sus respuestas al CAIQ están ahí, a la vista de todos, y son lo suficientemente específicas como para contrastarlas con el resto de su documentación. Solo hay que tener en cuenta que las respuestas del Nivel 1 son declaradas por el propio proveedor.

9. NIST SP 800-53 (versión 5.2.0)

El NIST publica este documento como un catálogo de controles, en lugar de como una certificación, y constituye la base de las líneas de referencia de FedRAMP, además de servir de referencia para numerosas correspondencias de controles del sector privado.

La versión 5.2.0 se publicó el 27 de agosto de 2025, y cualquier persona responsable de la aplicación de parches debería leerla. Publicada en respuesta a un decreto ejecutivo federal sobre la seguridad de las actualizaciones de software, incorpora una mejora en el análisis de las causas raíz de los problemas y fallos del sistema, que abarca las actualizaciones fallidas (SI-02(07)), una mejora en la sintaxis de registro (SA-15(13)) y un nuevo control de diseño de ciberresiliencia (SA-24).

La actualización considera que el propio proceso de aplicación de parches constituye una superficie de ataque que hay que proteger, y no solo las vulnerabilidades que dicho proceso pretende corregir.

10. Marco de ciberseguridad 2.0 del NIST

El NIST también publica esta guía, y la versión 2.0 salió en febrero de 2024. Se trata de una guía de carácter voluntario, sin un proceso de certificación ni un auditor al que cumplir.

CSF 2.0 ha añadido una sexta función, «Gobernar», junto a las cinco originales: «Identificar», «Proteger», «Detectar», «Responder» y «Recuperar». Además, ha ampliado su ámbito de aplicación más allá del enfoque centrado en las infraestructuras críticas que caracterizaba a la versión 1.1, y ahora se dirige a organizaciones de cualquier tamaño o sector.

Piensa en ello como el organigrama de tu programa de seguridad, con los controles detallados de las normas 800-53, CIS o CCM asignados debajo. El CSF no es muy útil a la hora de indicarte qué debes configurar, pero sí lo es para señalarte a qué elementos te has olvidado de asignar un responsable.

11. FedRAMP

Gestionado por la Oficina de Gestión de Proyectos (PMO) de FedRAMP, dependiente de la GSA, FedRAMP autoriza los servicios en la nube para su uso por parte de las agencias federales de EE. UU., y en 2026 se llevó a cabo su mayor reforma en años.

FedRAMP ha publicado las Normas Consolidadas para 2026 a finales de junio. Entraron en vigor el 4 de julio de 2026, lo que dio inicio a una fase de adopción temprana, y está previsto que FedRAMP 20x sustituya a la Rev5 con el tiempo. La terminología cambió junto con la estructura. «Autorización» pasó a denominarse «Certificación FedRAMP», los niveles de impacto dieron paso a las clases de certificación de la A a la D, y los proveedores ya no mantienen planes de acción ni hitos. En su lugar, mantienen registros de vulnerabilidades y una lista de deficiencias aceptadas, mientras que las agencias aún pueden elaborar sus propios planes de acción e hitos (POA&M) para las medidas y decisiones de riesgo que les competan.

Las fechas relevantes dependen de tu situación. Si ya dispones de una certificación Rev5, las Normas Consolidadas pasarán a ser obligatorias el 1 de enero de 2027, aunque algunos conjuntos de normas tienen sus propias fechas de entrada en vigor y períodos de gracia, y el último de esos períodos de gracia finaliza el 1 de febrero de 2028. Si todavía estás planeando presentar una solicitud de Rev5, FedRAMP dejará de aceptar nuevas solicitudes el 11 de junio de 2027 y, a partir de entonces, la única vía será la certificación 20x. Si en tu documentación todavía figura «FedRAMP Moderate ATO», se trata de terminología de la Rev5, y la fecha límite que te corresponde es el 1 de enero de 2027, cuando las Normas Consolidadas pasen a ser obligatorias. Queda tiempo, pero no mucho. 

La criptografía validada según FIPS sigue siendo importante en este contexto, aunque las nuevas normas reducen su ámbito de aplicación. FedRAMP exige ahora que el cifrado FIPS 140 proteja los datos sensibles y quiere que los proveedores documenten dónde lo utilizan, para que las agencias puedan evaluar su idoneidad para sus propios sistemas. En AlmaLinux, TuxCare Enterprise Support ofrece actualizaciones conformes con FIPS para el conjunto completo de paquetes FIPS (kernel, OpenSSL, libgcrypt, NSS y GnuTLS) a través de las Actualizaciones de Seguridad Extendidas para determinadas versiones menores. Tanto AlmaLinux 9.2 como 9.6 cuentan con certificados CMVP activos para los cinco módulos, el más reciente de los cuales se expidió en agosto de 2026. 

12. Directiva NIS2

NIS2, conocida oficialmente como la Directiva (UE) 2022/2555, funciona de manera diferente a un reglamento, ya que se trata de una directiva. La directiva es vinculante para los Estados miembros, pero las obligaciones para las empresas solo entran en vigor una vez que cada Estado la transpone a la legislación nacional, y ese proceso se ha desarrollado de forma desigual en todo el bloque.

El plazo de transposición vencía el 17 de octubre de 2024. En julio de 2026, la Comisión Europea llevó a Irlanda, España, Francia y los Países Bajos ante el Tribunal de Justicia de la UE por no haber notificado la transposición completa, y solicitó al tribunal que impusiera sanciones económicas. Los Países Bajos pusieron en vigor su Ley de Ciberseguridad el 15 de agosto de 2026 y, a mediados de septiembre, Irlanda, España y Francia seguían trabajando en las suyas. Dado que la NIS2 es una directiva, las obligaciones de las entidades privadas dependen de la legislación nacional de transposición de cada Estado, por lo que conviene consultar la normativa nacional aplicable en lugar de dar por sentado un efecto directo uniforme. La NIS2 exige a los Estados miembros que hagan responsables a los órganos de dirección con arreglo a la legislación nacional, y las normas nacionales deben permitir la imposición de multas a las entidades esenciales de al menos 10 millones de euros o el 2 % de la facturación anual mundial, el importe que sea mayor.

La NIS2 abarca entidades de 18 sectores, entre los que se incluyen los proveedores de computación en la nube, los servicios de centros de datos y los proveedores de servicios de seguridad gestionados.

13. DORA

La Ley de Resiliencia Operativa Digital, el Reglamento (UE) 2022/2554, entró en vigor en enero de 2023 y pasó a ser plenamente aplicable el 17 de enero de 2025. Las Autoridades Europeas de Supervisión coordinan su aplicación.

La normativa DORA se aplica directamente a las entidades financieras de toda la UE y se articula en torno a cinco pilares: gestión de riesgos de las TIC, notificación de incidentes, pruebas de resiliencia operativa digital, gestión de riesgos de terceros en el ámbito de las TIC e intercambio de información.

El pilar de los terceros es el que los proveedores de servicios en la nube suelen pasar por alto. Las entidades financieras deben incorporar los requisitos de la DORA en sus contratos de TIC, y un proveedor designado como proveedor crítico de TIC queda bajo la supervisión directa de un supervisor principal procedente de las Autoridades Europeas de Supervisión (ESA). Esto significa que vender infraestructura a bancos de la UE puede hacer que quedes bajo el ámbito de aplicación de la DORA, aunque tú mismo no seas una entidad financiera.

14. Pautas y controles CIS, versión 8.1

El Centro para la Seguridad en Internet publica aquí dos recursos relacionados: los «Controles», un conjunto de medidas de seguridad ordenadas por prioridad, y los «Puntos de referencia», que son directrices de configuración específicas para cada plataforma. Ninguno de ellos es certificable en el sentido tradicional.

CIS Controls v8.1, lanzado en junio de 2024, organiza 18 controles priorizados en tres grupos de implementación en función del riesgo, los recursos y la complejidad, de modo que no se exija lo mismo a un equipo pequeño que a una gran empresa desde el principio. Los CIS Benchmarks son el equivalente a nivel de configuración: guías de refuerzo de seguridad redactadas para plataformas específicas, entre las que se incluyen AWS Foundations, Azure Foundations, GCP, Kubernetes y las principales distribuciones de Linux.

Las pruebas de referencia son aquellas en las que los estándares dejan de ser algo abstracto y empiezan a indicarte qué configuración debes modificar. Muchas herramientas de gestión de la seguridad en la nube incluyen de serie comprobaciones basadas en las pruebas de referencia de CIS, lo que las convierte en uno de los puntos de partida más sencillos de esta lista.

Para AlmaLinux, el servicio de soporte empresarial de TuxCare incluye asistencia para el refuerzo de la seguridad que asocia los controles CIS y STIG a marcos de cumplimiento como PCI DSS e ISO 27001.

Buenas prácticas para la seguridad en la nube

Las normas indican qué hay que demostrar. Estas cinco prácticas son la forma en que los equipos obtienen realmente las pruebas.

Evaluaciones periódicas de la seguridad

Realiza las evaluaciones con una periodicidad definida, en lugar de hacerlo únicamente cuando se presenta un auditor. La periodicidad varía según la norma: algunas establecen ciclos anuales, mientras que otras se basan en el riesgo y no tienen un intervalo fijo. El requisito 12.5.2 de la norma PCI DSS añade un ejercicio anual de confirmación del alcance, independientemente de la periodicidad que elijas.

Los datos económicos aconsejan seguir adelante. El informe de IBM de 2026 sobre el coste de una filtración de datos sitúa el coste medio global de una filtración en 4,99 millones de dólares, lo que supone un aumento del 12 % y un nuevo récord que revierte el breve descenso del año anterior.

La desviación del alcance es el modo de fallo al que hay que prestar especial atención. Imagina un equipo de SaaS formado por 40 personas que pone en marcha un entorno de pruebas para una migración, se olvida de desactivarlo y lo deja fuera de los límites establecidos durante meses.

Si una evaluación no detecta absolutamente nada, es probable que el alcance se haya definido de forma demasiado restrictiva. Si detecta los mismos tres problemas cada trimestre, el problema radica en la responsabilidad de la corrección, más que en la detección.

Exploración de vulnerabilidades

Realiza análisis autenticados desde dentro del entorno, además de cualquier análisis externo. Los análisis externos no autenticados pasan por alto las vulnerabilidades a nivel de paquete en las cargas de trabajo en ejecución, que es precisamente donde se encuentran muchas de las vulnerabilidades explotables.

La cadencia mínima varía mucho según la norma. La norma PCI DSS exige análisis internos y externos cada tres meses y tras cualquier cambio significativo, y los análisis externos obligatorios deben realizarse a través de un proveedor de análisis homologado. Las normas técnicas de la DORA exigen análisis automatizados de vulnerabilidades al menos una vez a la semana en los activos de TIC que soportan funciones críticas o importantes, pruebas anuales de los sistemas que sustentan dichas funciones y pruebas de penetración basadas en amenazas al menos cada tres años para las entidades que designen sus reguladores. La actualización propuesta de la HIPAA exigiría análisis automatizados al menos cada seis meses y pruebas de penetración al menos una vez al año. Los controles CIS v8.1 exigen análisis automatizados de los activos internos al menos trimestralmente (Medida de protección 7.5) y de los activos expuestos externamente al menos mensualmente (Medida de protección 7.6). La NIS2 se basa en el riesgo y deja los detalles en manos de cada Estado miembro.

Contrastar los resultados con el catálogo de vulnerabilidades explotadas de la CISA antes de priorizar las medidas correctivas. Una puntuación CVSS por sí sola ocultará una vulnerabilidad de 7,5 que se está explotando activamente bajo una pila de puntuaciones teóricas de 9,8 sin explotación conocida.

Las reglas de cadencia anteriores parten de la base de que un escáner informa con precisión de lo que ya se ha corregido, y en Linux esa suposición suele fallar. Las distribuciones retroaportan correcciones de seguridad sin cambiar el número de versión del desarrollador original, y es posible que un parche aplicado en memoria sin necesidad de reiniciar ni siquiera aparezca en una comprobación de la versión del paquete. TuxCare Radar comprueba el estado real de los parches, incluidos los parches que no requieren reinicio y las correcciones cubiertas por ELS que una simple comprobación de la versión pasaría por alto, de modo que un ciclo de análisis no se convierta en una conciliación manual entre lo que indica el escáner y lo que indican tus registros de parches.

Controles de acceso estrictos

Aplicar la autenticación multifactorial en todas las cuentas de usuarios con acceso a la consola, sin excepciones para los propietarios de servicios ni para los contratistas. La norma PCI DSS v4.x amplió la autenticación multifactorial (MFA) más allá de los administradores a todos los accesos al entorno de datos de los titulares de tarjetas, con una excepción limitada para las cuentas que utilizan autenticación resistente al phishing, y la actualización propuesta de la HIPAA va en la misma dirección.

Más allá de MFA, establece como opción predeterminada el acceso basado en roles y con el mínimo privilegio, y revísalo al menos una vez al trimestre. Mantén separadas las identidades humanas y las de las máquinas, sin que haya credenciales compartidas de cuentas de servicio en los flujos de trabajo de CI. Opta por credenciales de corta duración en lugar de claves API de larga duración siempre que el proveedor las admita. Y documenta tu proceso de incorporación, traslado y baja de personal, ya que los auditores lo comprueban de forma rutinaria.

Cifrado de datos

Cifrar los datos en reposo y en tránsito debe ser un requisito mínimo. La gestión de claves es el aspecto que realmente falla en las auditorías: quién las custodia, con qué frecuencia se renuevan y si se puede demostrar exactamente qué puede y qué no puede descifrar el proveedor.

En el caso de las cargas de trabajo reguladas, la implementación es tan importante como la propia elección del algoritmo. Los sistemas federales de EE. UU. suelen exigir módulos criptográficos validados según la norma FIPS 140-3 siempre que se requiera el uso de criptografía homologada, y los contratos comerciales también los exigen cada vez con mayor frecuencia. TLS 1.2 es el mínimo exigido, y TLS 1.3 es el objetivo siempre que tu pila lo admita.

Atención: El cifrado en reposo con claves gestionadas por el proveedor cumple muchos requisitos de cumplimiento normativo, pero lo que realmente protege es contra la exposición en la capa de almacenamiento, como el robo de un disco o la retirada inadecuada de soportes. No sirve de nada frente a una credencial comprometida dentro de tu propia cuenta que permita descifrar los datos. Los auditores rara vez insisten en esta distinción. Los atacantes la aprovechan habitualmente.

Parches y actualizaciones periódicas

Es aquí donde la mayoría de los programas de cumplimiento normativo en la nube se desmoronan silenciosamente. Los controles parecen sencillos sobre el papel, pero resultan difíciles de aplicar en la práctica, ya que aplicar parches a un núcleo de producción suele implicar un reinicio, y un reinicio implica negociar una ventana de mantenimiento con todos aquellos que dependen de ese tiempo de actividad.

El reloj se menciona explícitamente en varias normas:

Un plazo de 30 días parece generoso hasta que se tienen en cuenta los pasos concretos que hay que seguir: clasificación, prueba, programación, notificación, reinicio, verificación y documentación. En una flota de varios cientos de hosts con acuerdos de nivel de servicio (SLA) de disponibilidad que cumplir, eso puede llevar la mayor parte del mes antes de que el parche llegue siquiera al entorno de producción.

Reflexiones finales

Elige tus normas basándote primero en las obligaciones y, después, en la demanda de los clientes, y no vayas más allá. Aplicar las normas ISO 27001, SOC 2 y CSA STAR todas a la vez solo porque la página de confianza de un competidor las menciona a las tres es la forma en que los equipos de seguridad pequeños pierden un año entero en documentación en lugar de dedicarlo a los controles.

Hay algo que no cambia independientemente de las normas que se te apliquen. Casi todas ellas exigen que detectes y corrijas las vulnerabilidades conocidas, y que dispongas de pruebas que puedas presentar cuando se te soliciten. El tipo de certificación varía. La aplicación de las normas también varía. Pero, en la mayoría de estos programas, es en las operaciones de aplicación de parches donde esas pruebas se presentan a tiempo o se descuidan.

Soporte técnico de ciclo de vida ilimitado garantiza que sigan llegando actualizaciones de seguridad a los sistemas operativos, entornos de ejecución de lenguajes y bibliotecas que han llegado al final de su vida útil, incluso después de que el soporte del proveedor haya finalizado, de modo que un componente sin soporte pueda seguir recibiendo correcciones en lugar de convertirse en una brecha de cumplimiento permanente. En cuanto a las dependencias de código abierto que utilizan tus cargas de trabajo en la nube, SecureChain ofrece a los equipos registros privados filtrados para paquetes de JavaScript, Python, Java, Go, Rust y PHP, lo que permite aplicar el tipo de controles de la cadena de suministro descritos en las normas ISO/IEC 27017 y CCM v4.1. TuxCare Enterprise Support cubre la criptografía validada según FIPS y el refuerzo de la conformidad que suelen exigir los entornos federales y otros entornos regulados. Y KernelCare aplica parches al núcleo sin necesidad de reiniciar el sistema, por lo que el cumplimiento de los plazos establecidos por la norma PCI DSS y otras normas similares no depende de que se apruebe una ventana de mantenimiento. Se siguen realizando pruebas, verificaciones y documentación como con cualquier otro parche, pero el reinicio ya no forma parte del calendario.

¿Tienes dudas sobre cuáles de estas normas se aplican a tu entorno o sobre dónde se encuentran realmente las lagunas en las pruebas de tu programa de cumplimiento? Habla con un experto en seguridad de TuxCare.

Resumen

Nombre del artículo

Los 14 principales marcos normativos de seguridad en la nube en 2026

Descripción

ISO 27017, SOC 2, FedRAMP, NIS2, DORA y otras normas. Qué exige cada norma de seguridad en la nube en 2026 y cómo se aplica realmente.

Autor

Rohan Timalsina

Nombre del editor

TuxCare

Logotipo de la editorial