Gobernanza de proyectos TIC con seguridad desde el diseño en 2026
El proyecto iba en plazo, hasta que la auditoría formuló una pregunta
El CISO de una empresa de tecnología de pagos en rápido crecimiento tenía buenas noticias para el consejo de administración. La nueva plataforma de alta de clientes estaba lista para su lanzamiento. El equipo de producto había entregado la experiencia móvil, ingeniería había integrado la verificación de identidad, el área jurídica había firmado con los proveedores de servicios en la nube y de API, y operaciones había ensayado el plan de puesta en producción.
Entonces, el auditor interno formuló una pregunta sencilla:
“Muéstreme dónde se tuvieron en cuenta la seguridad y la privacidad en cada fase del proyecto.”
La sala del proyecto quedó en silencio.
Había un informe de pruebas de penetración, pero se había realizado tarde. Había un diagrama de arquitectura en la nube, pero no existían evidencias de que los flujos de datos se hubieran revisado frente a los principios del RGPD de la UE. Había un cuestionario de diligencia debida de proveedores, pero no estaba vinculado al registro de riesgos. Había una solicitud de cambio para el despliegue en producción, pero la aprobación no mencionaba el impacto en servicios críticos, notificación de incidentes, pruebas de resiliencia, notificación a clientes ni escalado de brechas de seguridad de los datos personales. Había notas de sprint, pero los requisitos de seguridad estaban dispersos entre historias de usuario y mensajes de chat.
Nada parecía manifiestamente negligente. Todo se parecía a un proyecto TIC moderno con mucho movimiento. Pero, para una entidad financiera sujeta a DORA, un proveedor SaaS potencialmente dentro del ámbito de NIS2 y un responsable o encargado del tratamiento sujeto al RGPD de la UE, la cuestión ya no era solo si existía seguridad. La cuestión era si la seguridad desde el diseño podía demostrarse.
Ese es el problema de 2026. Los proyectos TIC ya no se evalúan únicamente por la velocidad de entrega, el control de costes y la calidad técnica. Se evalúan por sus evidencias de gobernanza: evaluaciones de riesgos, decisiones de diseño, diligencia debida de proveedores, registros de desarrollo seguro, aprobaciones de cambios, decisiones de privacidad, resultados de pruebas y supervisión por la dirección.
ISO/IEC 27001:2022 proporciona a las organizaciones una estructura práctica de sistema de gestión para resolver este problema. Ayuda a CISO, responsables de cumplimiento, patrocinadores de proyectos, delegados de protección de datos (DPO), arquitectos, equipos de compras y auditores a convertir proyectos TIC significativos en evidencias defendibles de seguridad desde el diseño.
Por qué la gobernanza de proyectos TIC es ahora un problema de evidencias regulatorias
Una migración a la nube, un portal de clientes, una plataforma de pagos, una implantación de CRM, un cambio de proveedor de identidad, una canalización de analítica, una integración de API, un flujo de trabajo SaaS, una aplicación de bajo código o una transición a un servicio gestionado pueden cambiar el perfil de riesgo de la organización. En 2026, esos cambios se producen bajo obligaciones superpuestas.
NIS2 se aplica ampliamente a entidades esenciales e importantes de los sectores del Anexo I y el Anexo II, incluida la infraestructura digital, los proveedores de servicios gestionados, los proveedores de servicios de seguridad gestionados y los proveedores digitales. El artículo 20 de NIS2 responsabiliza a los órganos de dirección de aprobar las medidas de gestión de riesgos de ciberseguridad y supervisar su implementación. El artículo 21 de NIS2 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas para la gestión de riesgos, la gestión de incidentes, la continuidad de negocio, la seguridad de la cadena de suministro, la adquisición segura, el desarrollo seguro, la gestión de vulnerabilidades, la evaluación de la eficacia, la higiene cibernética, la criptografía, el control de acceso, la gestión de activos y las comunicaciones seguras.
DORA se aplica a las entidades financieras y se centra en la resiliencia operativa digital. El artículo 5 de DORA atribuye al órgano de dirección la responsabilidad de la gestión del riesgo TIC. El artículo 6 de DORA exige un marco de gestión del riesgo TIC sólido, integral y debidamente documentado. DORA también cubre la notificación de incidentes relacionados con las TIC, las pruebas de resiliencia operativa, la continuidad de negocio TIC, la respuesta y recuperación, el intercambio de información sobre ciberamenazas, la gestión del riesgo de terceros TIC, los acuerdos contractuales y la supervisión de proveedores terceros de servicios TIC críticos.
El RGPD de la UE añade la capa de responsabilidad proactiva para los datos personales. El artículo 25 del RGPD de la UE exige protección de datos desde el diseño y por defecto. Los responsables del tratamiento deben poder demostrar el cumplimiento de principios como licitud, lealtad, transparencia, limitación de la finalidad, minimización de datos, limitación del plazo de conservación, integridad, confidencialidad y responsabilidad proactiva. Cuando el tratamiento pueda implicar un alto riesgo, también puede ser necesaria una evaluación de impacto relativa a la protección de datos (EIPD) con arreglo al artículo 35 del RGPD de la UE.
El hilo común son las evidencias. Los reguladores y auditores no preguntan solo si una plataforma estaba cifrada, parcheada, escaneada o probada. Preguntan si la organización puede demostrar que la seguridad, la privacidad, el riesgo de proveedores y la resiliencia formaron parte de la toma de decisiones desde el principio.
Por eso la gobernanza de proyectos ISO/IEC 27001:2022 es tan potente. Permite a la organización gestionar NIS2, DORA, el RGPD de la UE, NIST CSF 2.0, las obligaciones contractuales y el aseguramiento frente a clientes mediante un único proceso repetible del SGSI, en lugar de múltiples listas de verificación desconectadas.
La columna vertebral de gobernanza de proyectos ISO 27001
ISO/IEC 27001:2022 suele entenderse erróneamente como un ejercicio de certificación. Para los proyectos TIC, su valor operativo es más amplio. Proporciona una columna vertebral de gobernanza para el cambio organizativo.
Las cláusulas 4.1 a 4.4 exigen que las organizaciones comprendan las cuestiones internas y externas, las partes interesadas, los requisitos legales, regulatorios y contractuales, el alcance del SGSI, las interfaces y las dependencias. En términos de proyecto, esto significa que el acta de constitución del proyecto debe identificar los servicios afectados, clientes, proveedores, regulaciones, procesos de la organización, datos personales, operaciones críticas y servicios externalizados.
Las cláusulas 5.1 a 5.3 exigen compromiso del liderazgo, alineación con las políticas, recursos, integración en los procesos de la organización y responsabilidades asignadas. Esto importa porque tanto NIS2 como DORA sitúan la ciberseguridad y el riesgo TIC bajo la responsabilidad del órgano de dirección. Un proyecto que modifica una plataforma crítica para clientes no puede apoyarse en un comentario informal de seguridad en un hilo de chat. Necesita responsabilidad clara y demostrable.
Las cláusulas 6.1.1 a 6.1.3 exigen un proceso repetible de evaluación y tratamiento de riesgos, criterios de riesgo, propietarios de riesgos, evaluación de confidencialidad, integridad y disponibilidad, planes de tratamiento de riesgos, Declaración de aplicabilidad y aprobación del riesgo residual. Aquí es donde el riesgo del proyecto se convierte en evidencias de auditoría.
Las cláusulas 7.1 a 7.5 exigen recursos, competencia, concienciación, comunicación y control de la información documentada. Así es como los registros del proyecto se convierten en evidencias fiables, en lugar de artefactos dispersos.
La cláusula 8.1 exige planificación y control operacional, información documentada que demuestre que los procesos se ejecutaron según lo planificado, control de los cambios planificados, revisión de cambios no previstos, mitigación de efectos adversos y control de procesos, productos o servicios suministrados externamente que sean relevantes para el SGSI. Las cláusulas 8.2 y 8.3 exigen evaluaciones y tratamiento de riesgos de seguridad de la información a intervalos planificados o cuando se produzcan cambios significativos.
A continuación, el Anexo A conecta este ciclo de gestión con controles prácticos. Para la seguridad desde el diseño en proyectos TIC, tres controles del Anexo A de ISO/IEC 27001:2022 son centrales:
| Control ISO/IEC 27001:2022 | Nombre del control | Por qué importa para los proyectos TIC |
|---|---|---|
| A.5.8 | Seguridad de la información en la gestión de proyectos | Integra la seguridad en todas las fases del proyecto y genera evidencias de gobernanza antes de que se cree exposición |
| A.8.25 | Ciclo de vida de desarrollo seguro | Incorpora requisitos de seguridad, diseño seguro, codificación segura, pruebas y disciplina de despliegue |
| A.8.32 | Gestión de cambios | Garantiza que los cambios en producción se planifiquen, se evalúen en términos de riesgo, se prueben, se aprueben, se supervisen y puedan revisarse |
Zenith Blueprint: hoja de ruta de 30 pasos para auditores de Clarysec trata la seguridad de la información en la gestión de proyectos como una cuestión de gobernanza en todos los tipos de proyecto, no solo en el desarrollo de software:
“Cualquier proyecto —una migración de un sistema de marketing, un traslado de oficinas, un rediseño de procesos de la organización, una plataforma de incorporación de RR. HH. o incluso una fusión o adquisición— puede afectar a la confidencialidad, integridad o disponibilidad de la información. Y cuando lo hace, la seguridad debe tener un asiento en la mesa.”
La misma sección recoge la lección principal de implementación:
“El objetivo de este control no es cargar los proyectos con burocracia. Es garantizar que la seguridad se trate como una entrada de diseño, no como una fase de pruebas.”
Esa distinción separa el teatro de cumplimiento de una seguridad desde el diseño defendible.
Cómo se materializa la seguridad desde el diseño dentro de un proyecto TIC
La seguridad desde el diseño empieza antes del primer sprint, solicitud de compra, diagrama de arquitectura o procedimiento operativo de migración. Plantea una pregunta sencilla: ¿qué podría cambiar este proyecto en relación con el riesgo?
Un modelo práctico de gobernanza de proyectos utiliza siete puntos de control de evidencias.
| Punto de control del proyecto | Evidencias de seguridad desde el diseño | Propietario habitual | Valor de cumplimiento cruzado |
|---|---|---|---|
| Inicio | Clasificación de seguridad del proyecto, servicios afectados, aplicabilidad regulatoria, categorías de datos, criticidad | Patrocinador del proyecto y CISO | Respaldan el alcance ISO, las medidas de riesgo de NIS2, el análisis de funciones críticas de DORA y la responsabilidad proactiva del RGPD de la UE |
| Requisitos | Requisitos de seguridad, requisitos de privacidad, requisitos de resiliencia, requisitos de proveedores | Responsable de producto, responsable de seguridad, DPO, compras | Respaldan la adquisición segura, la privacidad desde el diseño y las cláusulas de terceros |
| Diseño | Revisión de arquitectura, modelo de amenazas, mapa de flujo de datos, límites de confianza, decisiones de criptografía | Equipos de arquitectura y seguridad | Respaldan el desarrollo seguro, la protección de datos del RGPD de la UE y los controles de riesgo TIC de DORA |
| Construcción o configuración | Registros de codificación segura, inventario de componentes, riesgo de dependencias, configuraciones de referencia | Equipo de ingeniería o de plataforma | Respaldan la gestión de vulnerabilidades y la seguridad de la cadena de suministro de software |
| Pruebas | Resultados de pruebas de seguridad, casos de abuso, escaneos de vulnerabilidades, pruebas de copia de seguridad y recuperación cuando proceda | Calidad, seguridad, operaciones | Respaldan las pruebas DORA, la evaluación de eficacia de NIS2 y las evidencias ISO |
| Aprobación de cambios | Aceptación del riesgo, plan de reversión, plan de supervisión, actualizaciones de escalado de incidentes | Comité asesor de cambios (CAB) o aprobadores delegados | Respaldan el control de cambios ISO, la comunicación de gobernanza DORA y la resiliencia operativa |
| Posterior a la implementación | Lecciones aprendidas, revisión del riesgo residual, supervisión de proveedores, revisión de la eficacia del control | Propietario del servicio y responsable del SGSI | Respaldan la mejora continua y la preparación para auditorías |
El objetivo no es la burocracia. El objetivo es hacer visible la seguridad allí donde realmente se toman las decisiones del proyecto.
La Política de Seguridad de la Información Enterprise de Clarysec lo expresa directamente:
“La gobernanza de la seguridad debe integrarse con la gobernanza empresarial, la gestión de proyectos, la adquisición y las funciones de supervisión jurídica para garantizar que la seguridad de la información no quede aislada, sino incorporada a la toma de decisiones de la organización.”
De la sección “Requisitos de gobernanza”, cláusula 5.5 de la política.
También convierte los ciclos de vida de los proyectos en un requisito de implementación:
“Ciclos de vida de proyectos (p. ej., desarrollo seguro, modelado de amenazas)”
De la sección “Requisitos de implementación de la política”, cláusula 6.3.1.1 de la política.
Y establece el principio de auditoría que muchas organizaciones descubren demasiado tarde:
“Todos los controles implementados deben ser auditables, estar respaldados por procedimientos documentados y conservar evidencias de su operación.”
De la sección “Requisitos de implementación de la política”, cláusula 6.6.1 de la política.
En otras palabras, el trabajo de seguridad que no está gobernado, conservado y mapeado a menudo fallará en auditoría, aunque los equipos técnicos hayan tomado decisiones razonables.
Del modelado de amenazas a las evidencias: un ejemplo fintech práctico
Piense en un proyecto para lanzar un nuevo portal de alta de clientes de la UE para una fintech. El portal recopila documentos de identidad, realiza verificación biométrica a través de un tercero, almacena el estado del alta, se integra con CRM, activa notificaciones a clientes y alimenta la calificación de riesgo.
Un enfoque de seguridad desde el diseño generaría evidencias a medida que avanza el proyecto.
Primero, abra un registro de clasificación de seguridad del proyecto. Identifique si el proyecto afecta a funciones críticas o importantes, datos personales, categorías especiales de datos personales, autenticación, disponibilidad orientada al cliente, servicios TIC externalizados, procesos regulados de notificación o comunicaciones con clientes. Bajo el RGPD de la UE, los datos biométricos utilizados para la identificación única son una categoría especial de datos personales, salvo que se aplique una excepción específica. Esto eleva de inmediato el nivel requerido de análisis jurídico y salvaguardas.
Segundo, cree una evaluación de riesgos del proyecto. La Política de gestión de riesgos SME de Clarysec convierte la gestión de riesgos en parte de la planificación, no en un ejercicio trimestral de hoja de cálculo:
“1.2 Garantiza que la gestión de riesgos sea un componente activo de la planificación, la ejecución de proyectos, la selección de proveedores y la respuesta a incidentes, en alineación con ISO 27001, ISO 31000 y los requisitos regulatorios aplicables.”
De la sección “Propósito”, cláusula 1.2 de la política.
Para entornos empresariales, la Política de gestión de riesgos Enterprise de Clarysec define el alcance en los niveles estratégico, operativo, de proyecto y técnico:
“Cubre los riesgos de seguridad de la información en los niveles estratégico, operativo, de proyecto y técnico, y es obligatoria para todo el personal, contratistas y proveedores de servicios que participen en actividades del Sistema de Gestión de la Seguridad de la Información (SGSI).”
De la sección “Alcance”, cláusula 2.3 de la política.
Tercero, ejecute un modelo de amenazas antes de que comience el desarrollo. La Política de Desarrollo Seguro Enterprise es explícita:
“Todas las aplicaciones nuevas y cambios mayores deben someterse a una revisión de arquitectura segura y modelado de amenazas antes de que comience el desarrollo.”
De la sección “Requisitos de implementación de la política”, cláusula 6.1.1 de la política.
Para el portal de alta, el modelo de amenazas debe cubrir interfaces expuestas, flujos de identidad, límites de privilegios, casos de abuso de API, suplantación de webhooks, ataques de repetición, credenciales comprometidas, rutas de fuga de datos, riesgo de dependencias, requisitos de registro de eventos, supuestos de copias de seguridad, requisitos de recuperación y modos de fallo del proveedor.
Cuarto, actualice las evidencias de privacidad. La Política de Protección de Datos y Privacidad SME establece la línea base:
“5.3.1. La privacidad desde el diseño y por defecto debe aplicarse en todos los nuevos sistemas y servicios”
De la sección “Requisitos de gobernanza”, cláusula 5.3.1 de la política.
El registro del proyecto debe incluir finalidad, base jurídica, rol de responsable o encargado del tratamiento, decisiones de minimización de datos, reglas de conservación, roles de acceso, decisiones de cifrado, consideraciones de impacto para los interesados, requisitos de transparencia, condiciones del encargado del tratamiento y rutas de notificación de brechas de seguridad de los datos personales.
Quinto, registre las evidencias de desarrollo seguro. La Política de Desarrollo Seguro SME ofrece una lista concisa de evidencias que funciona para equipos pequeños y medianos:
“5.3 El Director General (DG) debe mantener registros de: 5.3.1 Todos los proyectos activos de desarrollo de software y los desarrolladores o proveedores responsables 5.3.2 Listas de verificación de seguridad utilizadas para cada proyecto 5.3.3 Revisiones de código realizadas y las personas que las llevaron a cabo 5.3.4 Resultados de pruebas antes del despliegue 5.3.5 Componentes de terceros y su estado asociado de licencias o riesgo”
De la sección “Requisitos de gobernanza”, cláusula 5.3 de la política.
Sexto, controle el despliegue como un cambio. La Política de gestión de cambios SME establece:
“1.1 Esta política garantiza que todos los cambios en sistemas de TI, configuraciones, aplicaciones de la organización o servicios en la nube se planifiquen, evalúen en términos de riesgo, prueben y aprueben antes de su implementación.”
De la sección “Propósito”, cláusula 1.1 de la política.
Para el portal de alta, la solicitud de cambio debe incluir servicios afectados, evaluación de riesgos, resultados de pruebas, plan de reversión, plan de supervisión, aprobaciones de seguridad, aprobación formal de privacidad, preparación de proveedores, actualizaciones de escalado de incidentes y activadores de comunicación a clientes.
Finalmente, mapee las obligaciones. La Política de Cumplimiento Legal y Normativo SME proporciona la regla operativa:
“5.2.2 Cuando una regulación se aplique a múltiples áreas (p. ej., el RGPD de la UE se aplica a la conservación, la seguridad y la privacidad), esto debe mapearse claramente en el Registro de Cumplimiento y en los materiales de formación.”
De la sección “Requisitos de gobernanza”, cláusula 5.2.2 de la política.
Ese registro de cumplimiento se convierte en el puente entre los controles ISO/IEC 27001:2022, las medidas del artículo 21 de NIS2, las obligaciones de gestión del riesgo TIC de DORA, la responsabilidad proactiva del RGPD de la UE y los compromisos contractuales con clientes.
Mapear un único paquete de evidencias de proyecto con NIS2, DORA, RGPD de la UE y NIST CSF 2.0
La estrategia de cumplimiento más eficiente no consiste en duplicar trabajo. Consiste en mapear un conjunto sólido de evidencias con múltiples obligaciones.
Zenith Blueprint, en la fase de Gestión de riesgos, paso 14, recomienda este tipo de trabajo de referencias cruzadas:
“Para cada regulación, si aplica, puede crear una tabla sencilla de mapeo (podría ser un anexo de un informe) que enumere los requisitos clave de seguridad de la regulación y los controles/políticas correspondientes en su SGSI.”
Añade que esto es útil porque demuestra a auditores y evaluadores “que no está gestionando la seguridad en el vacío, sino que conoce el contexto jurídico”.
Zenith Controls: guía de cumplimiento cruzado de Clarysec respalda el mismo enfoque integrado al mapear los controles ISO/IEC 27001:2022 con otros marcos, expectativas de auditoría y necesidades de cumplimiento. Para la gobernanza de proyectos TIC, presenta A.5.8, A.8.25 y A.8.32 como controles preventivos que protegen la confidencialidad, integridad y disponibilidad en cuestiones de gobernanza, seguridad de aplicaciones, ecosistema, protección y seguridad de sistemas y redes.
| Artefacto de evidencia | Propósito ISO/IEC 27001:2022 | Valor para NIS2 | Valor para DORA | Valor para el RGPD de la UE |
|---|---|---|---|---|
| Clasificación de seguridad del proyecto | Define alcance, partes interesadas, dependencias y control operacional | Demuestra la identificación basada en riesgos de sistemas y servicios afectados | Identifica el impacto en funciones críticas o importantes | Identifica datos personales, roles y contexto del tratamiento |
| Modelo de amenazas | Respalda la evaluación de riesgos y los controles de desarrollo seguro | Respalda la adquisición segura, el desarrollo y la gestión de vulnerabilidades | Respalda el marco de riesgo TIC y la estrategia de resiliencia | Respalda la privacidad desde el diseño y las salvaguardas adecuadas |
| Diligencia debida de proveedores y revisión contractual | Respalda los controles de proveedores y de la cadena de suministro TIC | Respalda la seguridad de la cadena de suministro y la evaluación directa de proveedores | Respalda el riesgo de terceros TIC, derechos de auditoría y planificación de salida | Respalda las salvaguardas del encargado del tratamiento y las instrucciones de tratamiento |
| Registros de desarrollo seguro y pruebas | Respaldan el SDLC seguro, la gestión de vulnerabilidades y la preparación ante cambios | Respaldan el desarrollo seguro y la evaluación de eficacia | Respaldan las pruebas de resiliencia y la remediación | Respaldan la seguridad del tratamiento y la reducción del riesgo de brechas de seguridad |
| Registro de aprobación de cambios | Respalda cambios planificados, revisión y mitigación de efectos adversos | Respalda una implementación gestionada por riesgos | Respalda la comunicación de gobernanza y la resiliencia operativa | Respalda la responsabilidad proactiva de cambios de sistema que afectan a datos personales |
| Actualización de incidentes y supervisión | Respalda el registro de eventos, la supervisión, la planificación de incidentes y la recopilación de evidencias | Respalda la preparación para gestión y notificación de incidentes | Respalda la clasificación y el escalado de incidentes TIC graves | Respalda la detección y respuesta ante brechas de seguridad de los datos personales |
| Mapeo del registro de cumplimiento | Respalda requisitos legales y regulatorios e información documentada | Demuestra alineación con el artículo 21 | Demuestra la integración del marco DORA | Demuestra responsabilidad proactiva sobre los principios |
Esta tabla no sustituye al análisis jurídico. Es un acelerador de gobernanza. Garantiza que el CISO, el DPO, el patrocinador del proyecto, el responsable de compras, el propietario del sistema y el auditor interno estén observando las mismas evidencias.
NIST CSF 2.0 también encaja de forma natural en este modelo. Su función GOVERN ayuda a las organizaciones a establecer políticas, roles, apetito de riesgo, supervisión y conocimiento legal o contractual. Sus funciones IDENTIFY, PROTECT, DETECT, RESPOND y RECOVER ayudan a los equipos a debatir sobre activos, servicios de proveedores, control de acceso, seguridad de datos, seguridad de plataforma, desarrollo seguro de software, supervisión, respuesta a incidentes y recuperación en un lenguaje operativo común.
| Requisito regulatorio o de marco | Cómo aporta evidencias la gobernanza de proyectos ISO 27001 |
|---|---|
| DORA Article 5, gobernanza y organización | Demuestra supervisión de la dirección, responsabilidades definidas, vías de escalado y aprobación de decisiones de riesgo TIC |
| DORA Article 6, marco de gestión del riesgo TIC | Genera evaluaciones de riesgos TIC a nivel de proyecto, registros de tratamiento, requisitos de resiliencia y evidencias de control |
| DORA Article 28, riesgo de terceros TIC | Documenta diligencia debida de proveedores, salvaguardas contractuales, derechos de auditoría, planificación de salida y supervisión continua |
| NIS2 Article 20, gobernanza | Demuestra aprobación y supervisión por la dirección de las medidas de gestión de riesgos de ciberseguridad |
| NIS2 Article 21(2)(d), seguridad de la cadena de suministro | Registra evaluación de proveedores, criterios de adquisición, riesgos de proveedores de servicios y requisitos contractuales de seguridad |
| NIS2 Article 21(2)(e), adquisición, desarrollo y mantenimiento seguros | Captura requisitos de seguridad, revisión de arquitectura, gestión de vulnerabilidades, pruebas y evidencias de remediación |
| GDPR Article 25, protección de datos desde el diseño y por defecto | Demuestra requisitos de privacidad, minimización, conservación, control de acceso, salvaguardas del encargado del tratamiento y resultados de EIPD cuando sean necesarios |
| NIST CSF 2.0 GV.PO-01 y GV.PO-02 | Demuestra que las políticas de ciberseguridad se establecen, comunican, aplican, revisan y actualizan mediante la ejecución del proyecto |
Un único proceso alineado con ISO 27001 y centrado en el Anexo A.5.8 puede generar evidencias defendibles para todas estas expectativas.
El desarrollo seguro es más amplio que escribir código
Muchos fallos de proyectos TIC se producen porque la organización trata el desarrollo seguro como algo que solo hacen los desarrolladores. En 2026, el desarrollo seguro también incluye configuración SaaS, automatización de flujos de trabajo, infraestructura como código, integraciones de API, reglas de identidad, zonas de aterrizaje en la nube, canalizaciones de analítica, automatización robótica de procesos y aplicaciones corporativas de bajo código.
Zenith Blueprint, en la fase Controles en acción, paso 20, aborda el control 8.25 Ciclo de vida de desarrollo seguro de ISO/IEC 27002:2022:
“Este control se aplica tanto si escribe sus propias aplicaciones, configura plataformas como sistemas ERP o CRM, personaliza flujos de trabajo SaaS o gestiona entornos de infraestructura como código.”
También explica que los requisitos de seguridad deben situarse junto a los requisitos funcionales y que el modelado de amenazas ayuda a identificar partes expuestas del sistema, roles de usuario de riesgo y flujos de datos que requieren mayor protección.
Para un proyecto moderno, las evidencias de desarrollo seguro pueden incluir:
- Requisitos de seguridad vinculados a requisitos de la organización
- Modelo de amenazas o revisión de arquitectura segura
- Lista de verificación de codificación segura o configuración segura
- Registros de revisión de código o revisión por pares
- Inventario de componentes y estado de riesgo de dependencias
- Decisiones de gestión de secretos
- Diseño de control de acceso y mínimo privilegio
- Requisitos de registro de eventos y supervisión
- Resultados de escaneos de vulnerabilidades y registros de remediación
- Pruebas de seguridad en preproducción
- Pruebas de copia de seguridad, recuperación y resiliencia cuando proceda
- Evidencias de aprobación del despliegue y reversión
El objetivo no es obligar a todos los proyectos a pasar por el mismo proceso pesado. El objetivo es la proporcionalidad. Un cambio menor en un flujo de trabajo interno no requiere las mismas evidencias que una migración de una plataforma central de pagos. Pero todo proyecto debe clasificarse, evaluarse en términos de riesgo y gobernarse de acuerdo con su impacto.
La gestión de cambios protege al proyecto de sí mismo
El momento de mayor riesgo en muchos proyectos no es el diseño ni la codificación. Es el despliegue.
Un equipo puede realizar modelado de amenazas, revisión de código, evaluación de proveedores y revisión de privacidad, y aun así provocar una indisponibilidad o una brecha de seguridad por un cambio de producción apresurado. Una bandera de depuración permanece habilitada. Una regla de cortafuegos es más amplia que la aprobada. Un script de migración copia datos personales a un entorno no productivo. Un punto de conexión de webhook de terceros se despliega sin autenticación. Un cambio de registro de eventos registra números de documentos de identidad. Un trabajo de copia de seguridad falla silenciosamente tras el paso a producción.
Zenith Blueprint, en la fase Controles en acción, paso 21, describe el control 8.32 Gestión de cambios de ISO/IEC 27002:2022 en términos directos:
“El cambio es inevitable, pero en ciberseguridad, el cambio no controlado es peligroso.”
Y continúa:
“En esencia, una gestión de cambios eficaz es un flujo de trabajo repetible. Comienza con una propuesta clara, que describe qué cambia, por qué, cuándo y cuáles son los riesgos potenciales.”
Un registro sólido de cambios TIC debe responder:
- ¿Qué sistema, servicio, flujo de datos, proveedor o configuración cambia?
- ¿Qué riesgos se identificaron y quién es su propietario?
- ¿Afecta el cambio a datos personales, servicios críticos, autenticación, registro de eventos, copias de seguridad o respuesta a incidentes?
- ¿Qué comprobaciones de seguridad, privacidad, resiliencia y proveedores se realizaron?
- ¿Qué pruebas se completaron antes del despliegue?
- ¿Qué supervisión confirmará el comportamiento esperado?
- ¿Qué plan de reversión o recuperación existe?
- ¿Quién aprobó el riesgo residual?
- ¿Qué evidencias se conservarán?
Para DORA, esto respalda la gestión documentada del riesgo TIC, la resiliencia, la continuidad, la clasificación de incidentes y las lecciones aprendidas. Para NIS2, respalda las medidas de gestión de riesgos, el desarrollo seguro, la prevención de incidentes y la continuidad. Para el RGPD de la UE, ayuda a demostrar que los cambios que afectan a datos personales se revisaron frente a los principios de finalidad, minimización, conservación, acceso y seguridad.
Las decisiones sobre proveedores y nube deben formar parte del diseño del proyecto
En los proyectos TIC modernos, la decisión de diseño de mayor riesgo suele ser “comprar” en lugar de “construir”. Los servicios en la nube, proveedores de API, plataformas de verificación de identidad, procesadores de pagos, proveedores de analítica, proveedores de servicios gestionados y proveedores de seguridad gestionada pasan a formar parte de la superficie de riesgo.
NIS2 incluye explícitamente la seguridad de la cadena de suministro, las vulnerabilidades directas de proveedores y proveedores de servicios, las prácticas de ciberseguridad de proveedores, los procedimientos de desarrollo seguro y los resultados de evaluaciones coordinadas del riesgo de la cadena de suministro. DORA profundiza más para las entidades financieras. Exige la gestión del riesgo de terceros TIC como parte del marco de gestión del riesgo TIC, la responsabilidad continuada incluso cuando se externalizan servicios TIC, registros de información, evaluaciones precontractuales, análisis de riesgo de concentración, controles contractuales, derechos de auditoría e inspección, activadores de terminación y estrategias de salida probadas para funciones críticas o importantes.
Para el portal de alta, el proveedor de verificación biométrica no puede aprobarse solo porque a compras le guste el precio y la documentación de la API sea buena. El proyecto necesita evidencias de diligencia debida de seguridad, rol en el tratamiento, ubicación de los datos, subencargados, compromisos de disponibilidad, soporte ante incidentes, derechos de auditoría, asistencia para la terminación, viabilidad de salida y obligaciones de supervisión.
En un modelo de evidencias maduro, las decisiones sobre proveedores y nube se integran dentro del paquete de evidencias del proyecto, no en una carpeta de proveedores desconectada. Cuando el auditor pregunta por qué se aceptó a un tercero, la respuesta debe incluir necesidad de negocio, evaluación de riesgos, salvaguardas contractuales, revisión de protección de datos, impacto en resiliencia y supervisión continua.
Cómo revisarán los auditores las evidencias de seguridad desde el diseño
Distintos auditores abordan el mismo proyecto TIC desde ángulos diferentes. Un auditor de certificación, auditor interno, revisor DORA, autoridad competente NIS2, auditor de privacidad, evaluador orientado a NIST o auditor con enfoque COBIT puede solicitar evidencias similares, pero interpretarlas de forma distinta.
| Enfoque de auditoría | Qué preguntará el auditor | Evidencias que suelen satisfacer la pregunta |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | ¿Se integró la seguridad de la información en la gestión de proyectos y la planificación operacional, y están documentadas las decisiones de tratamiento de riesgos? | Acta de constitución del proyecto, evaluación de riesgos, mapeo de la SoA, plan de tratamiento, aprobaciones por fases, controles de información documentada |
| Evaluador NIST CSF 2.0 | ¿Los resultados de gobernanza, riesgo, proveedores, protección, detección, respuesta y recuperación se reflejan en las decisiones del proyecto? | Perfil actual y objetivo, plan de brechas, inventario de proveedores, diseño de acceso, plan de supervisión, procedimientos de incidentes y recuperación |
| Auditor con enfoque COBIT o ISACA | ¿Están claros los objetivos, la titularidad, los controles de proceso, los derechos de decisión y la supervisión del desempeño? | RACI, actas de gobernanza, propiedad del control, informes de KPI y KRI, aprobaciones de cambios, hallazgos de auditoría interna |
| Revisor DORA | ¿El proyecto afecta a funciones críticas o importantes, dependencias de terceros TIC, pruebas de resiliencia o notificación de incidentes? | Evaluación de criticidad, registro de riesgo TIC, registro de proveedores, cláusulas contractuales, resultados de pruebas, actualizaciones de clasificación de incidentes |
| Auditor del RGPD de la UE o de privacidad | ¿El proyecto aplicó privacidad desde el diseño, base jurídica, minimización, conservación, seguridad y responsabilidad proactiva? | Mapa de flujo de datos, registro de base jurídica, EIPD cuando proceda, matriz de acceso, reglas de conservación, condiciones del encargado del tratamiento, actualizaciones del procedimiento de actuación ante brechas de seguridad |
Los auditores no quieren una presentación bonita del proyecto. Quieren trazabilidad. Quieren ver que los requisitos condujeron a riesgos, los riesgos a controles, los controles a evidencias de implementación y la implementación a una revisión.
Por eso Zenith Controls resulta útil en la preparación para auditorías. Ayuda a los equipos a explicar por qué el Anexo A.5.8, A.8.25 y A.8.32 son controles preventivos que protegen la confidencialidad, integridad y disponibilidad antes de que fallos previsibles lleguen a producción.
El paquete mínimo de evidencias de proyecto de Clarysec
Un paquete sólido de evidencias de seguridad desde el diseño no necesita ser enorme. Debe ser coherente, proporcional y estar mapeado.
Para un proyecto TIC de riesgo medio, Clarysec suele recomendar el siguiente paquete mínimo:
- Registro de clasificación de seguridad del proyecto
- Nota de aplicabilidad regulatoria que cubra NIS2, DORA cuando corresponda, RGPD de la UE y obligaciones contractuales
- Mapa de impacto sobre flujos de datos y activos
- Evaluación de riesgos del proyecto y plan de tratamiento
- Modelo de amenazas o revisión de arquitectura segura
- Evaluación de proveedores y servicios en la nube cuando aplique
- Lista de verificación de desarrollo seguro o de configuración
- Resultados de pruebas de seguridad y evidencias de remediación
- Aprobación de cambios con plan de reversión y supervisión
- Registro de privacidad desde el diseño, incluida base jurídica y conservación cuando intervengan datos personales
- Actualizaciones de respuesta a incidentes y supervisión
- Revisión posterior a la implementación y lecciones aprendidas
- Mapeo del registro de cumplimiento con controles y obligaciones
Zenith Blueprint aporta la lógica de la hoja de ruta. El paso 22 incorpora la seguridad de la información en todas las fases del proyecto. El paso 20 integra el desarrollo seguro en planificación, diseño, código, pruebas y despliegue. El paso 21 convierte la gestión de cambios en un proceso estructurado, trazable y revisable. El paso 14 recomienda establecer referencias cruzadas con el RGPD de la UE, NIS2, DORA y otras obligaciones para que los requisitos de cumplimiento no queden sin atender.
Las políticas aportan reglas operativas. La Política de Seguridad de la Información integra la seguridad con la gestión de proyectos, la adquisición y la supervisión jurídica. La Política de gestión de riesgos convierte los riesgos de proyecto en parte de la actividad del SGSI. La Política de Desarrollo Seguro exige modelado de amenazas. La Política de gestión de cambios exige cambios planificados, evaluados en términos de riesgo, probados y aprobados. La Política de Protección de Datos y Privacidad exige privacidad desde el diseño y por defecto. La Política de Cumplimiento Legal y Normativo exige que las regulaciones que afectan a varias áreas se mapeen en el registro de cumplimiento.
Juntas, estas herramientas convierten la seguridad desde el diseño de una aspiración en un modelo operativo auditable.
Patrones comunes de fallo en proyectos TIC
Los fallos suelen ser previsibles.
El primero es la participación tardía de seguridad. Las revisiones de seguridad se producen después de que la arquitectura esté fijada, los contratos firmados y las fechas de entrega publicadas. En ese punto, la seguridad se convierte en un bloqueo y no en una entrada de diseño.
El segundo son las evidencias fragmentadas. El proyecto tiene resultados de pruebas en una herramienta, revisión de proveedores en otra, comentarios de privacidad por correo electrónico, aceptación del riesgo en una grabación de reunión y aprobación de cambios en una solicitud. No existe un hilo único que demuestre la gobernanza.
El tercero son los puntos ciegos con proveedores. El proyecto depende de un servicio en la nube o de un proveedor de API, pero nadie comprueba subencargados, ubicación de datos, derechos de auditoría, soporte ante incidentes, planes de salida o riesgo de concentración.
El cuarto es la deriva de privacidad. Un sistema construido para una finalidad empieza a soportar analítica, experimentación con IA, exportaciones de marketing o supervisión operativa sin revisar la base jurídica, la transparencia, la minimización o la conservación.
El quinto es el cambio no revisado. Un despliegue en producción se aprueba por funcionalidad, pero no se evalúa por su impacto en acceso, registro de eventos, cifrado, copias de seguridad, resiliencia, datos personales o notificación.
El sexto es una supervisión débil de la dirección. Los riesgos de proyecto de alto impacto se aceptan a un nivel demasiado bajo, sin evidencias de que el propietario del riesgo responsable entendiera las consecuencias regulatorias.
Estos problemas no se resuelven comprando otro escáner. Se resuelven integrando la gobernanza de la seguridad en la forma en que los proyectos se proponen, diseñan, contratan, construyen, prueban, cambian y revisan.
La conclusión para el CISO en 2026
La seguridad desde el diseño en proyectos TIC es ahora una cuestión de consejo de administración, auditoría y regulación. NIS2 convierte la gestión de riesgos de ciberseguridad en una responsabilidad del órgano de dirección. DORA convierte el riesgo TIC, las pruebas de resiliencia, la gestión de incidentes y la supervisión de terceros en una obligación estructurada del sector financiero. El RGPD de la UE exige responsabilidad proactiva sobre el tratamiento de datos personales y seguridad adecuada. ISO/IEC 27001:2022 aporta la estructura de sistema de gestión para hacer operativas estas obligaciones.
Para los CISO, la oportunidad es dejar de enfrentarse a los equipos de proyecto al final de la entrega. Incorpore la seguridad en el inicio, los requisitos, el diseño, la selección de proveedores, la construcción, las pruebas, la aprobación de cambios y la revisión posterior a la implementación.
Para los responsables de cumplimiento, la oportunidad es sustituir evidencias dispersas por un único paquete de evidencias de proyecto mapeado.
Para los auditores, la oportunidad es probar el ciclo de vida del proyecto, no solo el sistema final.
Para los responsables de negocio, la oportunidad es una entrega más rápida y segura. La seguridad desde el diseño reduce retrabajos, evita sorpresas de cumplimiento, mejora las decisiones sobre proveedores y proporciona a la dirección una narrativa de riesgo defendible.
Si sus proyectos TIC avanzan más rápido que su modelo de evidencias, empiece con un proyecto piloto. Use Zenith Blueprint de Clarysec para definir puntos de control de seguridad del proyecto, aplique las políticas de Clarysec para gestión de riesgos, desarrollo seguro, gestión de cambios y privacidad, y use Zenith Controls para mapear la gobernanza de proyectos ISO/IEC 27001:2022 con NIS2, DORA, RGPD de la UE y NIST CSF 2.0.
Clarysec puede ayudarle a crear un paquete reutilizable de evidencias de proyecto con seguridad desde el diseño, alinearlo con su SGSI y prepararlo para auditoría interna, auditoría de certificación, preparación DORA, gobernanza NIS2 y responsabilidad proactiva del RGPD de la UE.
Empiece con su próximo proyecto TIC significativo. Si cambia sistemas, proveedores, datos, accesos, resiliencia o la confianza del cliente, merece seguridad desde el diseño desde el primer día.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
