Mantener la tecnología en marcha pese a la interrupción

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.

• AWS · StandardOS lee si hay un plan de AWS Backup programado en la región.
• AWS · StandardOS lee si un plan de copia de seguridad copia a otro lugar, la preparación sobre la que descansa la continuidad de las TIC.

Riesgos que trata este control

Del registro de riesgos inicial que StandardOS propone en la configuración. Usted conserva, edita o elimina cada uno; estos son los que citan A.5.30 como tratamiento.

• Indisponibilidad de un servicio en la nube críticoServicios en la nube

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.5.30. 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.

• ¿Cuáles son sus RTO y RPO, y existe un plan de recuperación ante desastres probado?

  Continuidad de negocio, recuperación ante desastres, RTO y RPO · también A.5.29, A.8.14

• ¿Qué SLA de disponibilidad ofrecen, y cómo se gestiona la capacidad?

  Capacidad, disponibilidad, SLA · también A.8.6

Dónde encaja esto en NIS2

A.5.30 es parte de lo que exige el artículo 21, apartado 2, letra c), Business continuity and crisis management. Implementarlo una vez cuenta para ambos, y esa es toda la razón de que exista la correspondencia con NIS2.