Controlar los cambios en los sistemas en servicio

Cómo lo verifica StandardOS

Conectado en solo lectura, según un calendario. Una comprobación superada mantiene fresca una entrada de evidencia; una fallida la deja caducar, para que una regresión salga a la luz en lugar de esperar a la auditoría. Cada integración, y qué puede ver cada credencial.

• GitHub · StandardOS lee si la rama predeterminada exige una revisión aprobatoria antes de fusionar nada, e informa de una protección que bloquea los force-push sin exigir revisión como la cosa distinta que es.

Qué preguntan los clientes sobre este control

Los cuestionarios de seguridad no usan números de control. Estas son las preguntas, tal como las plantean los clientes, que desembocan en A.8.32. Cada una se responde a partir de los mismos cuatro registros: el estado en la DdA, la política aprobada, evidencia fechada y una comprobación en vivo. El mapa completo de los treinta temas.

• ¿Siguen un ciclo de desarrollo seguro con revisión de código y gestión de cambios?

  Desarrollo seguro, revisión de código, gestión de cambios, CI/CD · también A.8.25, A.8.29

Dónde encaja esto en NIS2

A.8.32 es parte de lo que exige el artículo 21, apartado 2, letra e), Security in network and information systems acquisition, development and maintenance. Implementarlo una vez cuenta para ambos, y esa es toda la razón de que exista la correspondencia con NIS2.