Aceptación y puesta en servicio

Qué exige, en claro

Que ningún software entre en producción sin superar una aceptación previa: pruebas de funcionamiento y de seguridad definidas antes (criterios de aceptación), en un entorno que no comprometa producción, con comprobación de que no se degradan las medidas de seguridad existentes.

Controlar la puesta en servicio: quién autoriza el paso, con qué resultado de pruebas, y cómo se vuelve atrás si algo sale mal. Las pruebas no usan datos reales — y si excepcionalmente los usan, con la misma protección que en producción (enlaza con mp.info y op.exp.5).

Cuándo aplica y cómo escala

Aplica con carácter general a todo sistema que incorpora o actualiza software — desarrollado o adquirido. El rigor formal crece con la categoría. Confírmalo en la valoración formal del sistema.

Ejemplos de implementación

• Pipeline de despliegue con puerta de aceptación: pruebas automáticas (funcionales + análisis de seguridad), aprobación registrada del responsable y despliegue con vuelta atrás probada.
• Para software adquirido: entorno de preproducción donde se valida configuración segura (op.exp.2), compatibilidad y ausencia de degradación de seguridad antes de autorizar el paso.

Errores habituales

• Desplegar «en caliente» directamente a producción porque el cambio «era pequeño».
• Probar con una copia entera de la base de datos real sin anonimizar ni proteger.
• Criterios de aceptación que solo miran funcionalidad: la seguridad se comprueba… nunca.
• No poder decir quién autorizó la última puesta en producción ni con qué evidencia.
• Carecer de vuelta atrás: si la versión nueva rompe, la avería se gestiona en pánico.

Evidencias que suele ser razonable preparar

• Criterios de aceptación definidos (funcionales y de seguridad).
• Resultados de las pruebas de aceptación de los últimos pases a producción.
• Autorizaciones de puesta en servicio y procedimiento de vuelta atrás.
• Política de datos de prueba (anonimización o protección equivalente).

Preguntas que debería hacerse el responsable

• ¿Qué tuvo que superar la última versión antes de llegar a producción?
• ¿Quién autorizó el pase y dónde quedó registrado?
• ¿Vuestros entornos de prueba usan datos reales? ¿Protegidos cómo?
• ¿Cuánto tardaríais en volver a la versión anterior si la nueva falla?

Fuente oficial: Anexo II del Real Decreto 311/2022 y Guía CCN-STIC 804 · Implantación del ENS (CCN-CERT). Ficha elaborada por Roberto Mickel, fundador y CTO de ENSFácil; revisada el 25 de agosto de 2026: la aplicabilidad exacta y los refuerzos dependen de la categoría y valoración de tu sistema — verifica siempre la versión vigente de la norma y de las guías.