ISO 27001 A.5.36: Demostración del cumplimiento de las políticas de desarrollo, operaciones y comercialización en entornos dinámicos

¿Por qué el 'cumplimiento del papel' falla en Dev, Ops y trading?

La norma ISO 27001 A.5.36 no se centra en cuántas políticas se pueden publicar, sino en si los equipos de desarrollo, operaciones y comercio las cumplen bajo presión real. En entornos de alta velocidad, la formación anual y los PDF de la intranet no son suficientes. Muchas organizaciones pueden presumir de una impresionante cantidad de políticas de seguridad aprobadas, pero los ingenieros y comerciantes aún toman decisiones diarias que las ignoran discretamente. Se necesitan reglas claras que las personas puedan aplicar en segundos, medidas de seguridad integradas en las herramientas y evidencia de que el comportamiento diario sigue alineándose con lo que prometen las políticas de seguridad.

En entornos dinámicos, la brecha se ve por todas partes: desarrolladores que implementan correcciones urgentes desde equipos locales, operadores que implementan ajustes de configuración puntuales, comerciantes que utilizan canales no oficiales para confirmar un precio. Nada de esto suele aparecer en un documento de políticas ni en un registro de riesgos formal; sin embargo, todo ello afecta su postura en materia de seguridad de la información y su capacidad para convencer a auditores y reguladores de que las personas realmente cumplen sus normas.

Esta información es general y no constituye asesoramiento legal o regulatorio; usted siempre debe buscar apoyo profesional apropiado para su situación particular.

Las políticas sólo importan cuando cambian lo que sucede en tiempo real.

La brecha de la realidad entre los documentos y el trabajo diario

La norma A.5.36 existe porque muchas políticas de seguridad se redactan para satisfacer a los auditores, no para guiar a quienes desarrollan, ejecutan y operan en sus sistemas. Desarrolladores, operadores y operadores necesitan reglas sencillas y prácticas que se ajusten a sus herramientas y a las limitaciones de tiempo. Si no las consideran adecuadas, recurren discretamente a atajos y a hábitos de "cómo lo hacemos realmente", especialmente cuando los PDF extensos se parecen poco a cómo desarrollan y envían código, ejecutan operaciones o gestionan las mesas de operaciones.

Cuando la política se percibe distante de las herramientas y decisiones cotidianas, se termina con un "cumplimiento en papel": certificaciones anuales, capacitación obligatoria y auditorías internas ocasionales que indican lo correcto, mientras que las prácticas reales se alejan lentamente de la intención. La norma ISO 27001 A.5.36 se actualizó para impulsar a las organizaciones a superar este patrón y adoptar controles regulares y estructurados que garanticen que lo que sucede en la práctica sigue alineándose con las normas establecidas.

Por qué los equipos de alta velocidad están especialmente expuestos

Los equipos de desarrollo, operaciones y trading, altamente dinámicos, toman cientos de decisiones pequeñas y urgentes a diario. Cuanto más rápidos sean los ciclos de cambio y ejecución, menos realista será depender de recordatorios ocasionales o revisiones manuales lentas. Sin medidas de seguridad integradas ni comprobaciones continuas, la desviación de políticas se acelera silenciosamente hasta que se manifiesta como un incidente, una operación fallida o un hallazgo de auditoría problemático.

La entrega continua, la infraestructura en la nube y el comercio electrónico recompensan la velocidad y la adaptabilidad, pero también multiplican los momentos en que alguien puede respetar o eludir una regla de seguridad. Un lanzamiento que antes pasaba por una reunión semanal de cambios ahora puede entregarse en minutos desde un canal automatizado. Una transacción que antes involucraba a varias personas ahora puede generarse, enrutarse y ejecutarse completamente mediante código.

En estos entornos, no se puede depender de los correos electrónicos de "por favor, recuerde las políticas". Se necesitan medidas de seguridad integradas en el funcionamiento de desarrollo, operaciones y comercio, además de evidencia continua de su funcionamiento. Ese es el núcleo de A.5.36: acortar la distancia entre la política escrita y el comportamiento observado, de forma que la organización pueda avanzar con rapidez.

Contacto

Lo que realmente le pide que haga la norma ISO 27001 A.5.36

El Anexo A.5.36 de la norma ISO 27001:2022 le exige hacer mucho más que publicar una política de seguridad. Debe definir reglas claras, decidir a quién se aplican, demostrar que las personas y los sistemas las cumplen, y revisar y abordar periódicamente cualquier deficiencia. En la práctica, debe poder responder a tres preguntas en cualquier momento: cuáles son las reglas, a quién se aplican y cómo sabe que se están cumpliendo en el desarrollo, las operaciones y la gestión comercial.

A grandes rasgos, esto implica definir un conjunto coherente de políticas de seguridad de la información, estándares y procedimientos específicos para cada tema, asignar responsables y planificar revisiones periódicas de cumplimiento. Estas revisiones deben generar evidencia y dar lugar a acciones de seguimiento claras cuando se detecten incumplimientos. Para el desarrollo, las operaciones y el comercio, esto se traduce en expectativas prácticas sobre cómo se escribe el código, cómo se implementan los cambios, cómo se otorga el acceso y cómo se gestiona la información confidencial en la oficina.

Vista en lenguaje sencillo del control

En términos sencillos, A.5.36 dice: «Establezca las reglas de seguridad que importan, compruebe que las personas y los sistemas las cumplan y corrija los errores cuando no lo hagan». Para que esto sea una realidad, necesita políticas específicas y accesibles, un plan para revisar el cumplimiento y un registro de evidencia que muestre lo que encontró y lo que modificó. A los auditores les importa más este ciclo que la redacción perfecta.

Esa simple redacción tiene varias implicaciones:

Las políticas y los estándares deben ser específicos y accesibles para que los equipos sepan qué se espera que hagan.
Debes definir con qué frecuencia y dónde revisarás el cumplimiento.
Debe especificar qué métodos de revisión utilizará, como auditorías, análisis técnicos o revisiones de acceso.
Debe conservar registros de los hallazgos y las acciones para que las auditorías internas y de certificación puedan rastrear lo que sucedió.

Para un auditor, la evidencia de que A.5.36 funciona normalmente incluye cronogramas de revisión, listas de verificación o resultados de pruebas, registros de incidencias, planes de acción correctiva y pruebas de que la gerencia detectó hallazgos significativos y actuó en consecuencia. Buscan evidencia consistente y repetible en lugar de actos heroicos puntuales.

Qué significa esto para los equipos de desarrollo, operaciones y comercialización

Para los equipos de desarrollo, operaciones y comercialización, A.5.36 espera que las políticas y estándares se plasmen en comportamientos observables y revisables. Los desarrolladores deben ver cómo se aplican las reglas de codificación segura en los pipelines. Los operadores deben reconocer los cambios y las comprobaciones de acceso en sus herramientas diarias. Los operadores deben saber qué sistemas y canales están dentro del alcance y cómo se supervisa su uso. Cada grupo necesita reglas claras y retroalimentación fiable.

Para los equipos de desarrollo, A.5.36 generalmente espera que los estándares de codificación segura, los patrones de arquitectura y las políticas de SDLC sean más que una simple guía. Se necesitan mecanismos que verifiquen si el nuevo código y la configuración cumplen con los requisitos, y es necesario revisar y mejorar dichos mecanismos. Por ejemplo, las reglas de codificación segura podrían implementarse mediante análisis estático y revisión por pares, con verificaciones puntuales periódicas en repositorios y pipelines.

Para los equipos de operaciones, la atención se centra a menudo en la gestión de cambios, acceso, configuración e incidentes. A.5.36 espera que demuestre que los cambios en la producción siguen los procesos acordados, que el acceso privilegiado se gestiona y revisa, y que las desviaciones de las líneas base estándar de compilación y configuración se comprenden y abordan. Para los equipos de operaciones de front-office, se enfatiza el cumplimiento de las normas de gestión de la información, los sistemas y canales autorizados, y los procedimientos administrativos que protegen la información sensible de los clientes y del mercado. En los tres casos, el patrón es el mismo: normas claras, controles operativos, revisión periódica y acciones correctivas documentadas.

Una simple comparación hace que esto sea más fácil de ver.

Dominio	Enfoque principal A.5.36	Señales de evidencia típicas
Dev	Codificación segura e implementación controlada	Registros de canalización, revisiones de código, resultados de escaneo
ops	Disciplina de cambio, acceso y configuración	Cambiar registros, acceder a revisiones, alertas de desvío
Trading	Sistemas autorizados y manejo de información	Informes de vigilancia, atestados documentales.

ISMS.online le ofrece una ventaja inicial del 81 % desde el momento en que inicia sesión

ISO 27001 simplificado

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.

Comenzar

Reformulando A.5.36 como un sistema de control que facilita el flujo

Implementará la norma A.5.36 con mayor eficacia cuando deje de considerarla un simple ejercicio documental y comience a verla como un sistema de control para sus flujos de información críticos. Toda información importante de su organización sigue un proceso: alguien la crea, otros la transforman, los sistemas la almacenan y transmiten, y finalmente se archiva o elimina. A lo largo de ese proceso, las políticas, los estándares y los controles determinan lo permitido. La norma A.5.36 le pide que demuestre que esto se mantiene vigente a medida que los sistemas y los mercados cambian, tratando el control como una barrera de protección integral para esos flujos.

Desde esta perspectiva, A.5.36 se convierte en una cuestión de definir qué se entiende por "buen comportamiento" en cada flujo, garantizando que existan controles en los puntos adecuados para mantener el comportamiento dentro de los límites aceptables, monitorizando dichos controles e interviniendo cuando fallan. Esta mentalidad es especialmente eficaz en desarrollo, operaciones y trading, donde los mismos flujos —por ejemplo, "implementar un nuevo algoritmo de trading en producción" o "gestionar los datos de las órdenes de los clientes"— se repiten a gran velocidad.

Visual: flujo de extremo a extremo desde la idea del código hasta la producción, con puntos de control de seguridad marcados en cada paso principal.

Piense en flujos de extremo a extremo, no en documentos aislados

Un primer paso práctico es seleccionar algunos escenarios de alto riesgo de desarrollo, operaciones y comercio y mapearlos de principio a fin. Para cada uno, pregunte quién maneja la información, qué sistemas la gestionan, qué decisiones son más importantes y dónde se espera que se ubiquen los controles según sus políticas actuales. Ver estos flujos en una sola página permite identificar tanto los puntos fuertes como los débiles.

Por ejemplo, analice cómo un cambio de código pasa de la idea a la producción: quién puede proponerlo, dónde se desarrolla, cómo se prueba, quién puede aprobarlo, cómo se implementa y cómo se supervisa. A continuación, superponga sus políticas y estándares: codificación segura, gestión de cambios, control de acceso, registro y respuesta a incidentes.

A menudo se encontrarán deficiencias donde no existe un control claro, donde los controles solo existen en teoría o donde dependen completamente de que las personas recuerden "hacer lo correcto". Ahí es donde debe centrarse el trabajo de cumplimiento de A.5.36: asegurar que cada paso crítico del flujo cuente con un control concreto que pueda revisarse, y que dichas revisiones estén planificadas y documentadas.

Asignar propiedad, desencadenantes y bucles de retroalimentación

Una vez que los flujos estén más claros, A.5.36 se convierte en una cuestión de responsabilidad, desencadenantes y retroalimentación. Cada punto de control necesita un responsable, señales claras para indicar cuándo se requiere una revisión o una escalada, y una ruta de retorno a su SGSI para que los hallazgos orienten las futuras decisiones sobre políticas y riesgos. El enfoque de flujo también aclara quién debe ser responsable de qué partes de A.5.36: cada punto de control debe tener un responsable, desencadenantes definidos para la revisión (por ejemplo, pruebas fallidas, acceso fuera de la política o actividad comercial inusual) y una ruta de retroalimentación a sus procesos de riesgo y auditoría de SGSI, para que los hallazgos no se queden en tickets o bandejas de entrada y nunca se traduzcan en una mejora sistémica.

Puede respaldar esto con una vista sencilla al estilo RACI: quién redacta y mantiene la política, quién opera el control diariamente, quién supervisa el cumplimiento y quién decide sobre las excepciones. Una vez definidos estos roles, puede utilizar auditorías internas y revisiones de gestión para verificar no solo si existen controles, sino también si el flujo general se mantiene dentro de los niveles de riesgo aceptables. Muchas organizaciones optan por respaldar esto con una plataforma central de SGSI, como ISMS.online, para que los responsables de los procesos, los flujos, los controles y la evidencia estén vinculados en un solo lugar.

Diseño de políticas que Dev, Ops y trading realmente pueden seguir

La implementación eficaz de A.5.36 depende de políticas y estándares que las personas puedan seguir realmente. Esto implica documentos breves y específicos, redactados en el lenguaje de desarrollo, operaciones y comercio, que expliquen en términos concretos qué significa "buen" y que, al mismo tiempo, reflejen sus ambiciones y gobernanza más amplias. Las políticas maestras marcan la dirección; los manuales y estándares basados en roles muestran exactamente cómo actuar en situaciones específicas, de forma que se ajuste a la forma de pensar y trabajar de los diferentes equipos.

Las políticas maestras describen los principios, el alcance y la gobernanza. Los manuales y estándares traducen estos principios en una guía concreta sobre cómo lo hacemos aquí para desarrolladores, operadores y personal comercial. Al combinarse con procesos estructurados de excepción y aprobación, esto proporciona una base práctica para el cumplimiento y la rapidez.

Convertir políticas a largo plazo en manuales de estrategias basados en roles

Los manuales de estrategias basados en roles acortan la distancia entre la política corporativa y las herramientas en pantalla. Desarrolladores, operadores y comerciantes deberían identificarse con los ejemplos y el lenguaje, para que seguir la política se sienta como seguir nuestra forma de trabajar, en lugar de lidiar con cláusulas abstractas.

Un estándar de desarrollo seguro, fácil de usar para desarrolladores, podría centrarse en temas como la autenticación, la validación de entradas, el registro y la gestión de errores, cada uno explicado brevemente con ejemplos específicos de "hacer esto, no aquello" en los lenguajes y marcos que utilizan sus equipos. Un estándar de gestión de cambios centrado en las operaciones podría especificar los pasos y las responsabilidades para los cambios normales, estándar y de emergencia, con árboles de decisión sencillos y enlaces a manuales de ejecución.

Para los equipos de trading, es posible que necesite procedimientos específicos de cada departamento que redefinan las reglas de manejo y acceso a la información en el contexto de los sistemas, instrumentos y tipos de clientes con los que trabajan. La clave es que cada manual de estrategias se derive claramente de sus políticas principales y esté claramente referenciado en su SGSI, pero que sea lo suficientemente breve y concreto como para que los usuarios lo utilicen.

Incorpore excepciones y aprobaciones en el diseño

Si el personal de desarrollo, operaciones o comercio siente que debe elegir entre seguir las políticas y hacer su trabajo, encontrará soluciones alternativas no oficiales. Los equipos de alta velocidad a veces se ven obligados a elegir entre el proceso "correcto" y objetivos realistas de entrega o ejecución, lo que, en última instancia, supone un fallo de diseño. A.5.36 espera que evite esta trampa definiendo tanto reglas estándar como métodos claros y revisables para gestionar las excepciones, de modo que el riesgo permanezca visible y controlado en lugar de ocultarse en decisiones improvisadas.

Para el equipo de desarrollo, esto podría significar permitir que las correcciones urgentes eludan algunas comprobaciones bajo condiciones muy específicas, con revisiones y pruebas adicionales posteriormente. Para el equipo de operaciones, podría ser un proceso controlado de emergencia para el acceso urgente. Para el equipo de comercio, podrían ser procedimientos especiales para condiciones de mercado extremas.

Estas rutas de excepción requieren criterios claros, aprobadores autorizados, plazos y requisitos de registro. Al diseñarlas abiertamente y vincularlas con las evaluaciones de riesgos, se ofrece a los equipos una vía legítima para actuar con rapidez cuando es necesario, a la vez que se genera evidencia que puede revisarse. Con el tiempo, los patrones en los datos de excepción se convierten en una de las fuentes más valiosas para mejorar tanto las políticas como los controles.

Integre, amplíe y escale su cumplimiento normativo, sin complicaciones. IO le brinda la resiliencia y la confianza para crecer con seguridad.

Reserva tu demostración

Integración de A.5.36 en Dev y CI/CD sin afectar la velocidad

Para los equipos de desarrollo y plataforma, la forma más sostenible de cumplir con la norma A.5.36 es integrar el cumplimiento de las políticas en las buenas prácticas de ingeniería. Los principios de seguridad por diseño y los patrones de DevSecOps convierten muchos requisitos de políticas en comprobaciones automatizadas dentro de sus pipelines y repositorios. Los desarrolladores realizan entregas con rapidez y usted obtiene evidencia continua de que se aplican las reglas de seguridad.

En un ciclo de vida de desarrollo de software (SDLC) seguro y un modelo de desarrollo, seguridad y operaciones (DevSecOps), las comprobaciones de seguridad se integran en los requisitos, el diseño, la codificación, las pruebas y la implementación, en lugar de añadirse manualmente al final. Los estándares de codificación segura y las reglas de arquitectura se pueden aplicar automáticamente siempre que sea posible, y las excepciones se gestionan mediante las herramientas habituales del flujo de trabajo. Los auditores y revisores de riesgos pueden consultar los registros de la canalización y los metadatos del repositorio. Esto les ayuda a comprender la frecuencia con la que se ejecutan los controles, la cantidad de problemas detectados y la rapidez con la que se resuelven.

Política como código en su SDLC y pipelines

La política como código convierte partes de sus estándares de seguridad en reglas que sus herramientas aplican automáticamente. En la práctica, esto podría implicar comprobaciones de análisis estático, escaneo de dependencias y contenedores, controles de infraestructura como código y reglas de protección de ramas que se ajustan directamente a sus políticas. Cada comprobación fallida genera una tarea de desarrollo y una señal de cumplimiento de la norma A.5.36.

Algunos ejemplos son:

Reglas de análisis estático que bloquean patrones inseguros o API prohibidas.
Escaneos de dependencias y contenedores que refuerzan las listas de componentes aprobados.
Comprobaciones de infraestructura como código que impiden que se apliquen configuraciones inseguras.
Reglas de protección de ramas que requieren al menos una revisión por pares para los cambios que afectan a componentes sensibles.

Estas comprobaciones técnicas se convierten en evidencia A.5.36 sólida al conectar las herramientas con los controles. Es posible integrar los resultados de análisis estático, análisis de composición de software e infraestructura como código en un único registro de evidencia. Por ejemplo, una compilación puede fallar porque una plantilla de infraestructura intentó crear un contenedor de almacenamiento sin cifrar. La ejecución fallida de la canalización, el código corregido y la repetición exitosa demuestran que un requisito específico de la política se aplicó y verificó a lo largo del tiempo.

Todos estos controles pueden vincularse a cláusulas específicas de sus estándares. Cuando un pipeline falla debido a la infracción de una regla, no se trata solo de un evento técnico, sino de un ejemplo de la supervisión del cumplimiento de A.5.36 en acción. Con el tiempo, puede generar informes sencillos para mostrar la frecuencia con la que se activa cada control, qué equipos tienen más problemas y si su postura general está mejorando.

Diseño de barandillas que protejan la velocidad

Las barreras de seguridad deberían proteger sus sistemas más importantes sin convertir cada implementación en una negociación. Esto suele implicar aplicar controles más rigurosos a los servicios de alto riesgo, usar controles más ligeros en otros lugares y tener rutas de anulación claramente definidas y registradas para emergencias reales. Si se implementa correctamente, esto permite que los ingenieros estén siempre disponibles, a la vez que permite visualizar y revisar los atajos arriesgados.

No todo puede ni debe automatizarse por completo, y no todos los equipos tienen el mismo perfil de riesgo. Un patrón razonable es aplicar las comprobaciones más rigurosas y exhaustivas a los sistemas que gestionan datos sensibles, se conectan con terceros o respaldan procesos comerciales o de riesgo críticos, mientras que se utilizan medidas de seguridad más sencillas para los servicios de menor riesgo. Etiquetar repositorios y pipelines por criticidad y sensibilidad de los datos ayuda a escalar las políticas adecuadamente.

También necesita claridad sobre cuándo y cómo se pueden eludir los controles. Por ejemplo, podría permitir que un ingeniero sénior anule un control defectuoso para solucionar un problema urgente de producción, siempre que registre el motivo, lo vincule a un ticket de incidente y active una revisión obligatoria dentro de un plazo definido. Posteriormente, puede resumir las anulaciones, las tendencias de fallos y los plazos de remediación en paquetes de revisión de la gerencia, de modo que la evidencia A.5.36 se integre directamente en su ciclo general del SGSI. La velocidad de entrega se mantiene donde importa, pero cada desviación del estándar se hace visible y revisable.

Puesta en práctica de A.5.36 en operaciones de producción e infraestructura

En las operaciones de producción e infraestructura, A.5.36 se integra en procesos que ya conoce bien (gestión de cambios, incidentes, problemas, acceso y configuración). Sin embargo, ahora debe demostrar que estos procesos implementan sus políticas de seguridad, que el cumplimiento se revisa periódicamente y que puede generar evidencia a demanda. No necesita nuevos procesos, sino una mejor alineación, instrumentación y visibilidad para que los flujos de trabajo existentes demuestren claramente que A.5.36 funciona en la práctica.

La mayoría de las organizaciones ya implementan procesos de gestión de cambios, incidentes, problemas, acceso y configuración. El A.5.36 pregunta si estos procesos implementan realmente sus políticas y estándares de seguridad, si revisa el cumplimiento periódicamente y si puede generar evidencia cuando se le solicita. El objetivo es adaptar las expectativas del A.5.36 a los flujos de trabajo existentes y luego instrumentarlos para que generen la evidencia correcta con el mínimo esfuerzo adicional.

Aquí, a menudo se trabaja con herramientas como plataformas de gestión de servicios de TI, sistemas de monitorización, soluciones de gestión de identidades y accesos, y bases de datos de gestión de la configuración. En lugar de inventar "procesos de seguridad" paralelos, se alinean las expectativas de seguridad con estos flujos de trabajo y se garantiza su visibilidad en el SGSI o plataforma central.

Asignación de expectativas de control a los flujos de trabajo de operaciones centrales

El A.5.36 en Operaciones se vuelve mucho más claro al documentar explícitamente qué partes de los flujos de trabajo de gestión de servicios de TI aplican qué reglas de seguridad. Para cada proceso, especifique cómo se ve el "comportamiento conforme", qué aprobaciones se requieren y qué debe registrarse. Esto convierte las expectativas vagas en comprobaciones específicas que puede supervisar.

Un punto de partida práctico es revisar cada proceso operativo y documentar sus reglas relevantes para la seguridad. Para la gestión de cambios, esto podría incluir quién puede solicitar qué tipos de cambio, qué evaluaciones de riesgos se requieren, qué aprobaciones son obligatorias, qué pruebas se esperan y cómo se gestionan las reversiones. Para la gestión de incidentes, se pueden especificar reglas de clasificación, vías de escalamiento, canales de comunicación y requisitos de revisión posteriores al incidente. Para la gestión de acceso, se define cómo se realizan las solicitudes, las aprobaciones, el aprovisionamiento, las revisiones y la revocación.

Una vez claras estas reglas, puede colaborar con los responsables de sus herramientas para garantizar que se reflejen en formularios, flujos de trabajo, campos e informes. Por ejemplo, un registro de cambios podría requerir campos estándar para el impacto en la seguridad, los activos de información afectados y referencias a evaluaciones de riesgos. Una solicitud de acceso podría tener que estar vinculada a un modelo de acceso basado en roles, en lugar de a derechos de formato libre. Estos detalles convierten la actividad diaria de operaciones en evidencia concreta según el estándar A.5.36.

Métricas y evidencia de la producción

Para demostrar que A.5.36 funciona en producción, se necesitan unas cuantas métricas sencillas que se pueden extraer de los sistemas de registro, no de hojas de cálculo creadas la noche anterior a una auditoría. Algunos indicadores útiles suelen ser el porcentaje de cambios que siguen el proceso estándar, la proporción de cambios de emergencia frente a cambios normales, la frecuencia de las revisiones de acceso privilegiado y las tendencias en las desviaciones de configuración y los incidentes relacionados con las políticas.

Debe diseñar sus registros e informes de forma que estas métricas se puedan generar sin un esfuerzo excesivo. Esto suele implicar estandarizar el etiquetado de los registros y garantizar que las configuraciones de retención cubran el periodo de auditoría. También implica otorgar a los equipos de seguridad y riesgo el acceso adecuado a los paneles de control y a los datos subyacentes. Muchas organizaciones utilizan una plataforma SGSI como ISMS.online para vincular la evidencia de cambios, accesos e incidentes con controles específicos de la norma A.5.36 y presentarla en una estructura compatible con la norma ISO.

Al realizar posteriormente una auditoría de seguimiento o recertificación de la norma ISO 27001, se extraen datos de los sistemas de registro en lugar de crear hojas de cálculo improvisadas. Además, se pueden integrar estas métricas en las agendas de auditoría interna y revisión por la dirección, de modo que la experiencia operativa influya directamente en las actualizaciones de políticas, las evaluaciones de riesgos y los planes de mejora.

ISMS.online admite más de 100 estándares y regulaciones, lo que le brinda una única plataforma para todas sus necesidades de cumplimiento.

Reserva tu demostración

Aplicación de A.5.36 en el parqué sin ralentizar la ejecución

En el parqué, A.5.36 debe coexistir con estrictos objetivos de ejecución y condiciones de mercado exigentes. Los operadores gestionan órdenes, posiciones e información sensible del mercado a gran velocidad, utilizando una combinación de sistemas estándar, herramientas a medida y canales de comunicación. Su tarea es asegurarse de que cumplan las normas de seguridad de la información sin sentirse bloqueados y recopilar pruebas que demuestren a los reguladores y auditores que dichas normas se aplican y revisan con el mismo rigor que en los equipos de tecnología.

Los entornos de trading front-office combinan todos los desafíos de Dev y Ops con una intensa presión de tiempo y estrictas expectativas regulatorias. La norma A.5.36 se aplica tanto en este caso como en los equipos de tecnología: el personal de trading debe cumplir con las políticas, normas y estándares de seguridad de la información, y usted debe poder demostrar que revisa y garantiza dicho cumplimiento. La dificultad radica en lograrlo sin degradar la calidad de la ejecución ni fomentar soluciones alternativas no autorizadas. La respuesta reside en normas de comportamiento claras, controles bien diseñados que se adapten a las realidades del trading y revisiones periódicas y basadas en evidencia.

Definición de comportamientos seguros en front-office

Sus operadores necesitan una guía clara sobre qué sistemas y canales pueden usar, cómo gestionar los datos de clientes y órdenes, y dónde la política de seguridad impone límites estrictos. Los procedimientos y manuales de estrategia a nivel de escritorio son el lugar adecuado para concretar esto. Deben reflejar herramientas, productos y escenarios reales, para que "hacer lo correcto" se integre de forma natural en los patrones normales de trading.

Comience por aclarar claramente qué sistemas se pueden usar para qué actividades, qué constituye un manejo aceptable de los datos de clientes y órdenes, qué canales de comunicación están autorizados y cuáles son las normas sobre dispositivos personales y acceso remoto. Estas expectativas deben quedar plasmadas en los procedimientos de oficina y en los manuales de estrategias para operadores, no en una política corporativa genérica.

A continuación, colabore con los equipos de front-office y de cumplimiento para garantizar que la configuración del sistema respalde dichos comportamientos: perfiles de acceso que reflejen roles y productos, límites y controles comerciales que apliquen patrones de verificación de marca cuando corresponda, y monitoreo que permita detectar usos indebidos. La capacitación y las simulaciones deben utilizar las herramientas y los escenarios reales a los que se enfrentan los operadores, de modo que la aplicación de las reglas resulte natural incluso en mercados volátiles.

Luego, puede utilizar revisiones periódicas de escritorio, ejercicios de certificación y registros de capacitación como evidencia de que estos comportamientos se comprenden y se cuestionan cuando es necesario, vinculando la práctica comercial con A.5.36 de una manera que los reguladores reconozcan.

Controles que respetan la velocidad de negociación

Los controles de negociación deben diseñarse de forma que la mayor parte de la actividad legítima fluya sin problemas, mientras que las conductas de riesgo se bloquean o se resaltan para su revisión. Los controles pre-negociación pueden bloquear órdenes claramente fuera de política, como el envío de instrucciones sensibles a través de canales no autorizados, mientras que la vigilancia post-negociación puede detectar patrones que sugieran un uso indebido de los sistemas o la información e incorporar estos hallazgos directamente en las revisiones A.5.36. Algunas aprobaciones pueden integrarse en el flujo de trabajo del sistema de gestión de órdenes o de ejecución, en lugar de depender de cadenas de correo electrónico independientes que los operadores podrían intentar eludir bajo presión.

Para evitar que A.5.36 se convierta en el control que arruinó la ejecución, diseñe controles que intervengan en los momentos oportunos. Los controles pre-negociación, por ejemplo, pueden bloquear automáticamente acciones claramente fuera de la política, mientras que las revisiones y la vigilancia post-negociación pueden centrarse en patrones y casos extremos. También debe diseñar explícitamente para situaciones excepcionales: dislocaciones del mercado, solicitudes urgentes de clientes o interrupciones del sistema. Para cada escenario, defina qué se puede hacer rápidamente con reglas predefinidas, qué se debe registrar y qué revisión posterior es obligatoria.

Por ejemplo, usted podría:

Bloquear intentos de exportar libros de pedidos a correo electrónico personal o herramientas no autorizadas.
Señalar el uso repetido de canales o dispositivos inusuales para la discusión de órdenes en la vigilancia posterior a la negociación.
Aplicar reglas de excepción previamente aprobadas para órdenes urgentes de clientes durante situaciones de estrés del mercado, con registro obligatorio y revisión posterior a la operación.

Esto mantiene a los operadores dentro de un marco controlado y revisable, incluso cuando necesitan actuar con rapidez. Los datos de los sistemas de vigilancia, los registros de acceso y las revisiones de escritorio se convierten entonces en evidencia vital para las revisiones A.5.36 y para sus obligaciones regulatorias más amplias en virtud de los regímenes de conducta y abuso de mercado.

Reserve una demostración con ISMS.online hoy mismo

ISMS.online le ayuda a convertir la norma ISO 27001 A.5.36 en un control dinámico al conectar sus políticas, estándares y evidencia real en un solo entorno. Defina las reglas una vez, asigne estas a los controles del Anexo A y vincúlelas con señales concretas de desarrollo, operaciones y operaciones comerciales, para que pueda ver de un vistazo dónde el cumplimiento es sólido, dónde requiere atención y cómo su implementación se integra en su sistema de gestión de seguridad de la información.

Si desea que A.5.36 se sienta como un control activo en lugar de una simple verificación anual, necesita una forma de conectar las políticas, estándares y controles con las herramientas y flujos de trabajo que sus equipos de desarrollo, operaciones y comercialización ya utilizan. ISMS.online está diseñado para lograr precisamente eso: le ofrece un entorno único donde puede definir sus reglas de seguridad de la información, asignarlas a los controles del Anexo A, asignarles responsabilidad y vincularlas con evidencia concreta de toda su organización.

Dentro de la misma plataforma, puede gestionar su conjunto de políticas, realizar un seguimiento de las revisiones de cumplimiento, registrar excepciones y acciones correctivas, y adjuntar registros de apoyo como informes de tramitación, tickets de cambio, revisiones de acceso y certificaciones de la mesa de operaciones. Esto facilita demostrar a auditores, reguladores y clientes que sus políticas son más que simples palabras.

Vea su postura A.5.36 en un solo lugar

Obtendrá el máximo provecho de A.5.36 al ver cómo funciona realmente en las áreas de Desarrollo, Operaciones y Comercialización, en lugar de depender de suposiciones o búsquedas de evidencia de última hora. ISMS.online le permite seleccionar el control, ver qué políticas, estándares y procedimientos se relacionan con él y, a continuación, extraer los artefactos que demuestran el funcionamiento en cada dominio. Al visualizar la situación, las brechas se hacen visibles: responsables ausentes, ciclos de revisión inconsistentes, evidencia débil o manual. A partir de ahí, puede priorizar las mejoras basándose en el riesgo y los plazos de auditoría, en lugar de conjeturas.

Dado que la plataforma está diseñada específicamente para la norma ISO 27001, también le ayuda a mantenerse al día con la norma general: cláusulas, controles del Anexo A, registros de riesgos, declaraciones de aplicabilidad, auditorías internas y revisiones de gestión se encuentran en un solo lugar. Esto reduce la duplicación y facilita la alineación de su implementación a medida que evolucionan sus entornos tecnológicos y comerciales.

Tome un primer paso de bajo riesgo

Una forma sensata de empezar es ejecutar un piloto centrado en un servicio crítico o mesa de operaciones, en lugar de intentar rediseñarlo todo a la vez. Incorpore las políticas y estándares relevantes en ISMS.online, conéctelos con la evidencia real de sus herramientas existentes y practique cómo presentaría esa situación en una auditoría o reunión con un regulador. Verá rápidamente qué funciona bien y dónde un modelo más integrado sería rentable.

Ese piloto inicial también le mostrará dónde su enfoque actual depende de la heroicidad y dónde un modelo más integrado y automatizado aportaría un valor real. A partir de ahí, podrá crear una hoja de ruta por fases que alinee la adopción de la plataforma con las próximas auditorías de certificación o vigilancia, de modo que cada inversión en el cumplimiento de la norma A.5.36 le acerque también a sus objetivos más amplios de seguridad de la información. Cuando esté listo, reservar una demostración con ISMS.online es una forma sencilla de explorar cómo esto podría aplicarse a la combinación de desarrollo, operaciones y comercialización de su organización.

Contacto

Preguntas Frecuentes

No necesitas reescribirlo desde cero. La esencia es sólida, pero una puntuación de crítica de 0 suele significar que se están detectando problemas estructurales o de duplicación, en lugar de problemas de contenido. Así es como yo lo ajustaría para que sea más conciso, evite repeticiones y se convierta en un texto de página de destino.

A continuación, se muestra una versión limpia y lista para publicar que mantiene su intención y sus ejemplos, pero agudiza la redacción, elimina la duplicación entre las secciones de preguntas frecuentes y de "crítica" y se inclina un poco más hacia ISMS.online como hilo unificador.

¿Cómo se aplica realmente la norma ISO 27001 A.5.36 a los equipos de desarrollo, operaciones y comercialización día a día?

La norma ISO 27001 A.5.36 exige que se establezcan reglas de seguridad claras para cada equipo, se verifique que el comportamiento diario se ajuste a dichas reglas y se actúe cuando no sea así. En la práctica, reduce la brecha entre lo que dicen las políticas y lo que realmente sucede en el desarrollo, las operaciones y el mercado de valores.

¿Cómo se ve A.5.36 para los equipos de desarrollo?

Para el desarrollo, A.5.36 trata de hacer que la ingeniería segura sea visible, repetible y evidenciada:

Reglas: La codificación segura, las herramientas y servicios aprobados, la segregación del entorno y las rutas de cambio y lanzamiento se escriben, se poseen y se mantienen actualizados.
Aplicación: Esas reglas aparecen en pipelines, políticas de ramas, listas de verificación de revisión de código y estándares de arquitectura que los desarrolladores ven todos los días.
Evidencia: Puede señalar solicitudes de extracción recientes, ejecuciones de canalización y registros de excepciones que muestran que las reglas se siguen la mayor parte del tiempo y que usted reacciona cuando no es así.

Los auditores esperarán ver un estándar de desarrollo seguro correlacionado con el Anexo A (incluyendo el control A.5.36 y los controles técnicos del A.8), y luego seguirlo a través de repositorios reales y registros de compilación. Si pueden comenzar con el control A.5.36 en su SGSI y terminar con una solicitud de fusión específica que muestre quién aprobó un cambio de alto riesgo, qué verificó y dónde se registró cualquier excepción, estará demostrando que el cumplimiento forma parte del flujo de trabajo de desarrollo, no una consideración posterior.

¿Cómo se aplica el artículo A.5.36 a las operaciones y al comercio?

Para productos de una sola cara, coloque el lado recubierto hacia arriba durante el templado. optimizar las operacionesEl énfasis está en si la producción realmente sigue sus políticas de cambio, acceso, configuración e incidentes. Normalmente, esto se ve así:

cambios significativos que pasan por flujos de trabajo acordados con aprobaciones, pruebas y planes de reversión
Acceso privilegiado solicitado, aprobado, limitado en el tiempo y revisado periódicamente.
Desviación de configuración y vulnerabilidades encontradas, priorizadas y corregidas en relación con los objetivos acordados
Incidentes registrados, analizados y vinculados a acciones de seguimiento

Para productos de una sola cara, coloque el lado recubierto hacia arriba durante el templado. comercio, A.5.36 se centra en cómo se maneja la información en entornos rápidos y de alto riesgo:

Qué plataformas y canales se pueden utilizar para la investigación, la entrada de pedidos y el contacto con el cliente
Cómo se pueden ver, descargar, almacenar o reenviar datos sensibles de clientes, pedidos y mercados
Cómo se controlan y supervisan los derechos, los dispositivos personales y el acceso remoto

En las tres áreas, A.5.36 ofrece un hilo conductor: se revisa el cumplimiento a intervalos definidos, se documentan los hallazgos y se realiza un seguimiento de las acciones correctivas. En ISMS.online, puede crear controles A.5.36 independientes para Desarrollo, Operaciones y Comercialización, vincular cada uno con sus políticas y procesos, y adjuntar evidencia en tiempo real de sus herramientas existentes para contar con una plataforma coherente para auditorías y revisiones de gestión.

¿Cómo se puede integrar A.5.36 en Dev y CI/CD sin ralentizar la entrega?

Mantiene la entrega rápida al convertir los requisitos de A.5.36 en barreras dentro de las herramientas que los desarrolladores ya usan, en lugar de documentos adicionales que se espera que recuerden. Cuanto más se apliquen automáticamente sus políticas en CI/CD, menos fricción sentirán.

¿Cómo convertir las políticas en reglas de tramitación?

Trate su estándar de desarrollo seguro como una “política como código”:

construimos análisis estático y análisis de composición de software controles que bloquean funciones inseguras, dependencias conocidas como incorrectas o licencias que no permite
escanear infraestructura como código Para configuraciones erróneas antes de la implementación, no después
use plantillas de protección de ramas y solicitudes de extracción Para hacer cumplir la revisión por pares y las aprobaciones específicas para componentes sensibles
puedes seguir Detección de secretos y escaneo de imágenes En el momento de confirmación o compilación, por lo que los problemas obvios nunca llegan a producción

Cuando una canalización falla una de estas comprobaciones, los desarrolladores reciben retroalimentación inmediata y usted obtiene evidencia repetible y con marca de tiempo de que los controles se ejecutan a diario. Puede ajustar las reglas según la criticidad de los activos y la confidencialidad de los datos para que los servicios de alto riesgo se sometan a comprobaciones más estrictas, mientras que el trabajo de bajo riesgo no se ralentiza innecesariamente.

¿Cómo se deben abordar los cambios urgentes sin infringir el estándar A.5.36?

A.5.36 no prohíbe la urgencia; espera que la gestiones de forma transparente:

definir una clara camino de “romper el cristal” para cuestiones de producción y eventos del mercado: quién puede eludir qué controles, bajo qué circunstancias, durante cuánto tiempo
Asegúrese de que las anulaciones sean aprobado, registrado y revisado Posteriormente, se registraron los cambios de seguimiento.
Realizar un seguimiento de métricas como la frecuencia de anulación, el tiempo de reparación y la recurrencia para demostrar que las excepciones siguen siendo excepcionales.

Si su control A.5.36 en ISMS.online se vincula a repositorios, canalizaciones y registros de anulación específicos, puede mostrar a los auditores que el desarrollo seguro está integrado en CI/CD y que incluso la actividad de emergencia es visible, responsable y limitada en el tiempo.

¿Cómo deben los equipos de operaciones demostrar el cumplimiento de A.5.36 en producción?

Las operaciones muestran el cumplimiento de A.5.36 cuando las actividades de producción siguen claramente sus políticas de cambio, acceso, configuración e incidentes, y usted puede demostrarlo a través de sus herramientas de gestión de servicios de TI.

¿Cómo conectar los flujos de trabajo de ITSM a A.5.36?

Comience asignando cada proceso operativo al control:

Gestión del cambio: Qué niveles de riesgo requieren aprobación de seguridad o arquitectura, evidencia de pruebas y planes de reversión; cómo se manejan y revisan los cambios de emergencia
Gestión de Acceso: Quién puede aprobar roles privilegiados, cuánto duran y con qué frecuencia los revisa
Gestión de configuración y vulnerabilidades: Qué significa “línea base” en su entorno, con qué frecuencia escanea, qué equipos solucionan qué y en qué plazos
Gestión de incidentes y problemas: Cómo se clasifican, escalan, comunican y cierran los incidentes, y cómo se capturan las lecciones aprendidas

Luego, configure su herramienta ITSM para que las preguntas y aprobaciones requeridas sean inomitibles, los tickets muestren enlaces a las políticas que implementan y los paneles muestren los incumplimientos. Su sistema ITSM se convierte en una superficie de control activa y una fuente de evidencia, en lugar de solo un retraso operativo.

¿Qué evidencia de producción suelen pedir ver los auditores?

Los auditores normalmente toman muestras de:

registros de cambios para trabajos significativos o de alto riesgo, incluidas aprobaciones, calificaciones de riesgo, evidencia de pruebas y resultados
registros de solicitudes de acceso y revisión de acceso para incorporaciones, traslados y egresos, especialmente para cuentas privilegiadas
Informes de configuración y vulnerabilidad que muestran desviaciones, excepciones y estado de remediación
registros de incidentes, libros de ejecución y revisiones posteriores a incidentes, incluidas las tareas de seguimiento y su finalización

Reunir estos artefactos bajo un control A.5.36 en ISMS.online le permite guiar al auditor desde el texto del requisito hasta ejemplos concretos de su entorno de producción de manera estructurada, en lugar de depender de pantallas compartidas ad hoc o exportaciones de último momento.

¿Cómo pueden las mesas de negociación cumplir con el estándar A.5.36 sin perjudicar la velocidad de ejecución?

Las mesas de operaciones cumplen con el punto A.5.36 cuando las expectativas de seguridad de la información están escritas en lenguaje comercial, están incorporadas en los sistemas de operaciones y procedimientos de la mesa, y están respaldadas por una supervisión y vigilancia que se centran en el riesgo real en lugar de ralentizar cada orden.

¿Cómo hacer que la seguridad sea parte del comportamiento comercial normal?

Comience con procedimientos a nivel de escritorio que los comerciantes realmente utilizan:

Establecer qué plataformas y herramientas están aprobadas para la investigación previa a la negociación, la entrada de órdenes, la ejecución y el análisis posterior a la negociación.
definir cómo se puede acceder, exportar, almacenar y compartir los datos de clientes, pedidos y mercado, incluidas las reglas para dispositivos personales y ubicaciones remotas
Explicar qué canales de comunicación (chat, voz, correo electrónico, aplicaciones de mensajería) están permitidos y bajo qué condiciones.

Alinear esos procedimientos con:

perfiles de acceso basados en roles: que limitan a cada usuario a los sistemas y datos que realmente necesita
controles previos a la negociación y de la plataforma: que bloquean infracciones obvias de la política, como el comercio desde ubicaciones o dispositivos no autorizados
Vigilancia post-negociación: que busca patrones en transacciones y comunicaciones que puedan indicar un mal uso del acceso o de los datos

Si un comerciante que intenta hacer lo correcto naturalmente se mantiene dentro de las reglas, y alguien que intenta eludirlas deja un rastro ruidoso, usted está cerca de la intención de A.5.36.

¿Cómo es la evidencia comercial útil para A.5.36?

La evidencia útil generalmente incluye:

corriente manuales de escritorio y guías de referencia rápida que reafirman las normas de seguridad y conducta en escenarios cotidianos
informes de titularidad y registros de aprobación: Para sistemas de trading, fuentes de datos de mercado y canales externos
alertas de vigilancia, registros de escalada y notas de investigación: , incluidos los resultados y la remediación
Revisiones y certificaciones de supervisión: Confirmar que el personal clave ha leído, comprendido y aplicado las reglas.

Al anclar estos documentos y registros a un control A.5.36 centrado en el comercio en ISMS.online, usted puede mostrar a los reguladores y auditores que la mesa conoce las reglas, que los sistemas ayudan a los comerciantes a seguirlas y que los supervisores actúan cuando algo parece estar mal.

¿Qué tipo de evidencia respalda mejor A.5.36 en Dev, Ops y trading?

La estructura A.5.36 más sólida es consistente entre equipos: las reglas son claras, los controles funcionan correctamente y se responde cuando el comportamiento se desvía. La evidencia debe reflejar esta estructura, respetando las diferencias entre desarrollo, operaciones y comercialización.

¿Cómo se puede estructurar la evidencia para que sea convincente y eficiente?

Una estructura simple funciona bien:

Políticas y estándares: Su política de seguridad de la información, el estándar de desarrollo seguro, los manuales de operaciones y los procedimientos de escritorio asignados a A.5.36 y los controles técnicos pertinentes
Operación de control: muestras de sistemas CI/CD, ITSM y de comercio/vigilancia que muestran que las reglas se ejecutan repetidamente en el tiempo, no solo una vez para la auditoría
Excepciones y acciones: registros de verificaciones fallidas, cambios de emergencia, eventos comerciales inusuales u otras desviaciones, junto con notas de investigación, decisiones y correcciones

Para el desarrollo, esto podría implicar directrices de desarrollo seguro, además de registros de pipeline e historiales de solicitudes de fusión. Para operaciones, tickets de cambio y acceso, configuración y resultados de incidentes. Para operaciones comerciales, procedimientos de escritorio, revisiones de derechos y artefactos de vigilancia. Obtener evidencia directamente de los sistemas de registro reduce el esfuerzo manual y la compilación de documentos de última hora.

¿Cómo mantener la evidencia A.5.36 organizada y reutilizable?

En lugar de reinventar la rueda para cada auditoría, puede:

Para crear registros de control separados para A.5.36 que cubre Dev, Ops y trading en su SGSI
Vincular cada control a las políticas, estándares, procesos y propietarios subyacentes
adjuntar o referenciar artefactos específicos (registros, tickets, informes, revisiones) a medida que se generan a lo largo del año
grabar Hallazgos, excepciones y acciones correctivas directamente dentro de esos controles para que las revisiones de gestión y las auditorías internas vean el progreso a lo largo del tiempo

ISMS.online está diseñado para esta forma de trabajar. Le permite mantener los controles, los responsables y las evidencias en un solo lugar, de modo que las auditorías internas y de certificación se conviertan en un recorrido por el funcionamiento real de su organización, en lugar de un ejercicio de documentación puntual.

¿Cómo puede ISMS.online simplificar el cumplimiento de A.5.36 en desarrollo, operaciones y comercio?

ISMS.online simplifica el A.5.36 al convertirlo en un bucle de control continuo y compartido que abarca el desarrollo, las operaciones y la comercialización, en lugar de tres conjuntos de documentos separados, propiedad de diferentes equipos. Usted define sus reglas una vez, las asigna al Anexo A y luego las conecta con la actividad y la evidencia reales.

¿Qué permite ejecutar A.5.36 a través de una única plataforma?

Con ISMS.online usted puede:

definir y mantener políticas y estándares de seguridad de la información que se aplican a Dev, Ops y trading, luego asigne directamente a A.5.36 y controles relacionados
Para crear controles vinculados Para cada equipo, capturando cómo interpretan y aplican las reglas en un lenguaje que tenga sentido para ellos.
adjuntar evidencia en vivo desde sistemas CI/CD, herramientas ITSM y plataformas comerciales contra los controles adecuados, con fechas y propietarios visibles de un vistazo
planificar y realizar un seguimiento revisiones, excepciones y mejoras mediante revisiones de gestión, auditorías internas y flujos de trabajo de acciones correctivas
Utilice paneles de control para ver dónde el cumplimiento es sólido, dónde se está desviando y dónde las próximas auditorías o visitas regulatorias requieren más atención.

Para un grupo de desarrollo, esto podría significar vincular estándares de codificación segura a repositorios y pipelines específicos, y almacenar como evidencia los resultados de compilación y revisión seleccionados. Para operaciones, asignar los flujos de trabajo de cambio y acceso desde su herramienta ITSM a A.5.36 y adjuntar tickets e informes seleccionados. Para operaciones comerciales, capturar los procedimientos de escritorio, las certificaciones y los resultados de vigilancia en un único registro de control.

¿Por dónde empezar si aún no has formalizado el A.5.36?

Intentar modelar todos los procesos a la vez puede frenar el progreso. Un piloto específico suele funcionar mejor:

choose un servicio o mesa de operaciones de alto riesgo donde los clientes, los reguladores o la junta directiva se preocupan más por el comportamiento en materia de seguridad de la información
mapear sus políticas, estándares, tickets, registros y revisiones en un pequeño conjunto de controles A.5.36 en ISMS.online
Ejecute ese modelo durante un período corto, observando qué tan fácil es capturar evidencia, dónde aparecen las brechas y qué tan bien los gerentes y auditores pueden seguir la historia.
Refine su enfoque en función de lo que aprenda y luego extienda el patrón a otros servicios, equipos y marcos como SOC 2, ISO 27701 o NIS 2

Comenzar de esta manera le permite demostrar a las partes interesadas de alto nivel que tiene el control del cumplimiento de las políticas de seguridad de la información donde más importa, a la vez que proporciona a los equipos de desarrollo, operaciones y comercialización un sistema práctico que respalda su forma de trabajar. A medida que crece, su organización empieza a parecerse menos a tres funciones separadas y más a un entorno coordinado y resiliente donde las políticas, el comportamiento y la evidencia se mantienen alineados.

Si lo desea, ahora puedo:

comprimir esto en unas preguntas frecuentes más cortas, estilo página de destino, o
Agregue una pregunta frecuente más dirigida específicamente a auditores o reguladores que lean la página.