La gestión de proyectos SGSI consiste en tratar los requisitos de seguridad de la información como entregables del proyecto, no como consideraciones de cumplimiento añadidas a posteriori. Según ISO/IEC 27001, un SGSI (Sistema de Gestión de Seguridad de la Información) exige una evaluación y un tratamiento del riesgo documentados, y esos requisitos se corresponden directamente con los grupos de procesos estándar del PMBOK: inicio, planificación, ejecución, seguimiento y cierre. Si se establece esta correspondencia desde el principio, la seguridad deja de percibirse como una pista separada añadida al margen del calendario.
Antes de tocar el plan de proyecto, confirme estos cinco aspectos:
- Definir el alcance del SGSI para este proyecto concreto (qué sistemas, datos y procesos están dentro del ámbito)
- Realizar una evaluación de riesgos centrada en los activos nuevos o modificados
- Redactar un plan de tratamiento del riesgo y las correspondientes entradas en la Declaración de Aplicabilidad (DoA)
- Asignar un responsable de seguridad de la información con nombre y apellidos, sin responsabilidades compartidas
- Programar las pruebas de seguridad y un punto formal de traspaso antes de la puesta en producción
Conclusiones clave
Integrar los requisitos del SGSI en las fases estándar del proyecto, en lugar de tratar la certificación como una pista separada, es lo que mantiene el trabajo de ISO 27001 en plazo y listo para auditoría.
| Punto | Detalles |
|---|---|
| El alcance, siempre primero | Defina el alcance del SGSI para el proyecto durante el inicio, antes de que comience cualquier evaluación de riesgos. |
| Construya la DoA de forma incremental | Añada entradas a la Declaración de Aplicabilidad a medida que cada control se vuelva relevante, no en un único esfuerzo al final del proyecto. |
| Nombre un responsable de seguridad | Asigne un responsable de seguridad de la información diferenciado del director de proyecto para evitar vacíos de responsabilidad. |
| Establezca una revisión en cada fase | Realice breves comprobaciones de seguridad en los límites de cada fase en lugar de una auditoría apresurada antes del cierre. |
| Dimensione el esfuerzo con datos reales | Herramientas como la evaluación de preparación de ISMS Calculator convierten el tamaño de la empresa y su madurez en estimaciones de horas concretas, eliminando las suposiciones. |
Tabla de contenidos
- Fundamentos de gestión de proyectos SGSI: qué exige realmente ISO/IEC 27001
- ¿Por qué integrar los requisitos de seguridad en el plan de proyecto?
- ¿Qué debe ocurrir en cada fase del proyecto?
- ¿Qué documentos y evidencias necesita un proyecto SGSI?
- ¿Quién es responsable de qué en un proyecto SGSI?
- ¿Cuánto tiempo añade realmente el trabajo del SGSI a un proyecto?
- ¿Qué errores descarrilan con más frecuencia los proyectos SGSI?
- Un enfoque pragmático para liderar proyectos alineados con el SGSI
- Dimensione el esfuerzo del SGSI antes de comprometerse con un calendario
- Dónde ampliar información sobre SGSI y estándares de proyectos
- Preguntas frecuentes
- Fuentes
Fundamentos de gestión de proyectos SGSI: qué exige realmente ISO/IEC 27001
Un SGSI es el conjunto de políticas, procesos de riesgo y controles que una organización utiliza para proteger sus activos de información de forma continua. ISO/IEC 27001 es el estándar internacional que certifica dicho sistema, y exige una evaluación del riesgo documentada, un plan de tratamiento del riesgo y evidencias de que los controles seleccionados están efectivamente en funcionamiento.
En el contexto de un proyecto, esto se traduce en obligaciones concretas vinculadas a cláusulas específicas: la evaluación de riesgos debe cubrir los nuevos activos que el proyecto introduce, la DoA debe actualizarse cuando el proyecto modifique los controles aplicables, y cualquier proveedor incorporado durante el proyecto necesita una verificación de seguridad documentada.
Supongamos que el equipo añade una integración de pagos de terceros a mitad del proyecto. Esa única decisión desencadena una revisión de seguridad del proveedor, una nueva entrada en la DoA para los controles de relaciones con proveedores y, probablemente, una nueva línea de evaluación de riesgos para los datos en tránsito. Nada de esto es papeleo opcional. Es lo que un auditor solicitará ver más adelante.
Conviene señalar una advertencia: el acrónimo «ISM» aparece en otros ámbitos de la literatura con el significado de «Modelado Estructural Interpretativo» (Interpretive Structural Modeling), una técnica de sistemas completamente diferente. Si investiga este tema y llega a un artículo sobre modelado estructural, se ha topado con el ISM equivocado.
¿Por qué integrar los requisitos de seguridad en el plan de proyecto?
Añadir la seguridad al final cuesta más que incorporarla desde el primer día. La integración durante la planificación, y no tras la entrega, es lo que mantiene un proyecto en plazo en lugar de atascado en la remediación.
- Menos trabajo rehecho, porque los controles se diseñan junto con las funcionalidades en lugar de añadirse después
- Mayor rapidez en la preparación para la certificación, ya que las evidencias se acumulan de forma natural durante el desarrollo
- Criterios de aceptación más claros, de modo que «completado» incluye la validación de seguridad, no solo una demostración
- Menor riesgo operativo tras el traspaso, porque las brechas se detectan durante las pruebas y no en producción
- Una pista de auditoría que ya existe en lugar de tener que reconstruirla
Para un patrocinador que pondera tiempo, coste y calidad, este es un argumento claro: las tareas de seguridad realizadas en paralelo con la entrega rara vez añaden tiempo neto al calendario, mientras que las realizadas después de la entrega casi siempre lo hacen. Aquí hay un factor que importa más que cualquier lista de verificación: el respaldo visible de la dirección. Los proyectos en los que un patrocinador apoya activamente el plan de tratamiento del riesgo y revisa las entradas de la DoA tienden a avanzar hacia la certificación con muchas menos sorpresas.
¿Qué debe ocurrir en cada fase del proyecto?
La gestión de proyectos estándar equilibra tiempo, coste y calidad a lo largo del inicio, la planificación, la ejecución, el seguimiento y el cierre. El trabajo del SGSI encaja en esa misma estructura. A continuación se indica qué corresponde a cada fase.
Inicio
- Definir el alcance del SGSI para el proyecto: qué activos, sistemas y flujos de datos se ven realmente afectados
- Identificar los activos de información involucrados y quién es actualmente su responsable
- Designar un patrocinador del proyecto y un responsable de seguridad de la información con nombre y apellidos, diferenciado del rol de director de proyecto
- Incluir los criterios de aceptación del SGSI en el acta de constitución del proyecto para que la validación de seguridad sea un entregable definido y no una adición tardía
Planificación
- Realizar una evaluación de riesgos centrada en lo que este proyecto modifica, no una revisión organizativa completa
- Elaborar un plan de tratamiento del riesgo y redactar las entradas relevantes de la DoA
- Programar las ventanas de pruebas de seguridad directamente en el calendario del proyecto, no como un margen al final
- Incorporar los requisitos de seguridad de proveedores en los documentos de contratación antes de firmar los contratos
- Incluir tareas de formación y concienciación para todas las personas que vayan a operar el nuevo sistema
Ejecución
- Implementar los controles definidos en la planificación
- Realizar pruebas de seguridad a nivel de componente y de nuevo en la integración
- Registrar las evidencias a medida que avanza el trabajo: registros de pruebas, resultados de análisis, capturas de configuración
- Hacer seguimiento de los entregables de los proveedores en función de los requisitos de seguridad recogidos en sus contratos
Seguimiento y control
- Mantener un registro de riesgos vivo, no un documento estático redactado una sola vez y abandonado
- Hacer seguimiento de las acciones de remediación para los controles que no superen las pruebas
- Incluir una breve actualización del estado de seguridad en los paneles del comité de dirección junto con las métricas de coste y calendario
- Someter cualquier cambio de alcance al control formal de cambios, con una evaluación de impacto en seguridad adjunta
Cierre y traspaso
- Finalizar el paquete de evidencias: entradas completadas de la DoA, informes de pruebas, registros de asistencia a la formación
- Recoger las lecciones aprendidas específicas del trabajo de seguridad, no solo las lecciones de entrega
- Transferir la titularidad operativa al equipo de seguridad de la información o de operaciones, con un responsable receptor designado
- Programar la primera auditoría de seguimiento o revisión de mejora antes de que el equipo del proyecto se disuelva
Consejo profesional: Construya la DoA de forma incremental, una entrada por control a medida que sea relevante, y realice una breve revisión de seguridad en cada límite de fase en lugar de un sprint de auditoría al final. Los proyectos que esperan al cierre para conciliar la DoA casi siempre encuentran brechas que obligan a reabrir trabajo ya finalizado.
¿Qué documentos y evidencias necesita un proyecto SGSI?
Los auditores no se fían de su palabra. Necesitan un rastro documental, y gran parte de ese rastro se genera durante el propio proyecto, no se hereda del SGSI existente de la organización.
Algunos documentos ya pertenecen a la organización, como la política general del SGSI y la DoA de nivel superior. La misión del proyecto es producir las entradas y evidencias específicas que se integran en esa estructura: una evaluación de riesgos con alcance definido, un plan de tratamiento del riesgo para los cambios que introduce el proyecto, líneas actualizadas de la DoA para los controles nuevos o modificados, informes de pruebas de seguridad, evidencias de seguridad de proveedores y registros de finalización de la formación.
Para una funcionalidad entregada concreta, un auditor normalmente espera ver:
- La entrada de la evaluación de riesgos que cubre los flujos de datos de esa funcionalidad
- La línea de la DoA que muestra qué control aplica y por qué
- Las evidencias de prueba que confirman que el control funciona según lo diseñado
- La documentación del proveedor, si algún tercero participó en la funcionalidad
- Un registro de aceptación firmado que acredite que la validación de seguridad tuvo lugar antes del despliegue
Nuestra lista de verificación de certificación desglosa esto en un listado más completo paso a paso si desea contrastarlo con un proyecto real.
¿Quién es responsable de qué en un proyecto SGSI?
La confusión sobre la titularidad es una de las razones más habituales por las que las tareas del SGSI se estancan dentro de un proyecto. Normalmente seis roles asumen responsabilidades: el patrocinador del proyecto (financia y respalda el trabajo), el director de proyecto (lo programa y hace seguimiento), el responsable de seguridad de la información o propietario del dominio (define qué significa «conforme» para este alcance), el responsable técnico (implementa los controles), los responsables de proveedores (gestionan las obligaciones de seguridad con terceros) y el comité de dirección (revisa el estado y aprueba los cambios de alcance con impacto en seguridad).
La gobernanza en la práctica implica ejecutar revisiones de seguridad en puntos de control definidos, someter cualquier cambio de alcance con impacto en seguridad al control formal de cambios, mantener una cadencia regular de informes al comité de dirección y obtener una validación explícita de las evidencias antes del cierre. Antes de finalizar el plan, pregunte directamente a cada titular de rol: ¿qué evidencias necesita de mí, cuándo las necesita y quién recibe este trabajo en el traspaso? Saltarse esa conversación es cómo los vacíos de responsabilidad afloran tres semanas antes de la puesta en producción. Nuestra guía sobre la titularidad del responsable de TI explica cómo suele articularse esto en la práctica.
¿Cuánto tiempo añade realmente el trabajo del SGSI a un proyecto?
El esfuerzo escala en función de varios factores concretos: cuántos activos de información toca el proyecto, cuántos proveedores están involucrados, cuál es la madurez del SGSI existente en la organización, cuántas pruebas y evidencias requiere el alcance, y si existen restricciones normativas adicionales a las de ISO 27001.
Como orientación aproximada para el dimensionamiento, una funcionalidad pequeña y acotada con uno o dos controles nuevos suele añadir uno o dos días de trabajo de seguridad dedicado. Una integración de tamaño medio, como incorporar un nuevo proveedor SaaS o un procesador de pagos, normalmente requiere entre dos y tres semanas entre la evaluación, las pruebas y la remediación. Para proyectos grandes, en los que el trabajo del SGSI discurre como su propia pista paralela a la entrega, es necesario un estimador adecuado o una referencia organizativa en lugar de una regla general.
Consejo profesional: Realice un análisis de brechas ligero en la primera semana de planificación. Detectar un control ausente en esta etapa tiene el coste de un ajuste en el calendario. Detectarlo durante el cierre tiene el coste de reabrir un sprint y de una conversación con el patrocinador que nadie quiere tener.
¿Qué errores descarrilan con más frecuencia los proyectos SGSI?
Los mismos fallos aparecen en la mayoría de los proyectos SGSI por primera vez, y casi todos son evitables con una planificación más anticipada en lugar de con mayor esfuerzo.
El más grave es tratar la DoA como un documento que se redacta de una vez al final. Le sigue muy de cerca: la falta de evidencias de proveedores porque compras firmó un contrato antes de que los requisitos de seguridad se incorporasen al mismo, saltarse el control formal de cambios cuando el alcance se modifica, y cerrar el proyecto sin recoger las lecciones aprendidas, lo que hace que el siguiente equipo repita los mismos errores.
La solución es fundamentalmente de secuenciación. Escalone las actividades de seguridad junto con el desarrollo en lugar de acumularlas al final, valide las entradas de la DoA a medida que cada control queda implementado, realice pruebas de forma regular en lugar de una única pasada masiva, y forme a los equipos operativos antes del traspaso, no después.
Consejo profesional: Trate la DoA como un documento vivo y ejecute pequeñas revisiones de seguridad en cada límite de fase en lugar de una auditoría acelerada en la recta final. Un proyecto que concilia las evidencias semanalmente raramente se lleva una sorpresa desagradable en la undécima semana.
Un enfoque pragmático para liderar proyectos alineados con el SGSI
La mayoría de los responsables de proyectos SGSI por primera vez invierten en exceso en documentación y en defecto en el descubrimiento. El taller de alcance en la primera semana importa más que cualquier plantilla que descargue, porque un límite de alcance incorrecto significa que toda evaluación de riesgos construida sobre él deberá rehacerse más adelante.
Tres cosas van primero, en este orden: un taller de alcance con el responsable de seguridad de la información y el patrocinador presentes al mismo tiempo, un análisis de riesgos rápido de los activos realmente afectados por este proyecto (no de toda la organización), y las revisiones de seguridad programadas en el calendario antes de que finalice la planificación, no añadidas una vez que comienza la ejecución.
La verdadera disyuntiva es velocidad frente a trazabilidad para la auditoría. Avanzar rápido sin capturar evidencias ahorra semanas al principio y las devuelve en la certificación. Cuando esa tensión se agudiza, es exactamente el momento de llevarla ante el patrocinador, no de enterrarla en un informe de estado que leerá por encima.
Dimensione el esfuerzo del SGSI antes de comprometerse con un calendario
Gran parte de las conjeturas en la planificación de proyectos SGSI se reduce a una pregunta: ¿cuántas horas va a llevar esto realmente? Una calculadora de preparación responde a eso convirtiendo el tamaño de su empresa, el sector y la madurez de seguridad actual en una estimación concreta y una lista de tareas priorizada, en lugar de dejarle adivinar el alcance a partir de una lista de verificación genérica.
El punto de partida con menor esfuerzo es una verificación de preparación gratuita de dos minutos, que le proporciona una instantánea de dónde se sitúan sus brechas antes de escribir una sola tarea del proyecto. Para un desglose más completo, la evaluación de preparación para ISO 27001 produce horas estimadas por dominio y una lista priorizada de elementos de la DoA que abordar primero, que puede incorporar directamente a su calendario de proyecto. Si aún está trazando el cronograma completo de implementación, realice la evaluación ahora y construya su diagrama de Gantt sobre cifras reales en lugar de una estimación aproximada.
Dónde ampliar información sobre SGSI y estándares de proyectos
Para el texto exacto de las cláusulas, consulte directamente la norma ISO/IEC 27001. Para la alineación con el ciclo de vida, la Guía PMBOK cubre en profundidad los grupos de procesos y la gobernanza, y el documento técnico de SANS sobre cómo abordar ISO 27001 como un proyecto recorre la correspondencia práctica de implementación. Para dimensionar su propio cronograma, consulte nuestra guía de cronograma de implementación y el análisis de brechas paso a paso.
Preguntas frecuentes
¿Qué es el SGSI en gestión de proyectos? Significa tratar los requisitos de seguridad de la información —como la evaluación de riesgos, la implementación de controles y la captura de evidencias— como entregables programados del proyecto en lugar de una actividad de cumplimiento separada que se gestiona tras la entrega.
¿Necesito la certificación ISO 27001 para aplicar estos fundamentos? No. Las prácticas aquí descritas —definición de alcance, evaluación de riesgos, entradas en la DoA y revisiones de fase— son aplicables tanto si se persigue la certificación formal como si simplemente se desea mejorar la gestión de la seguridad de la información dentro de los proyectos de la organización.
¿Quién debe ser responsable de las tareas del SGSI dentro de un proyecto? Un responsable de seguridad de la información designado, diferenciado del director de proyecto, suele ser titular del plan de tratamiento del riesgo y de las entradas de la DoA, mientras que el director de proyecto es responsable de la programación y la integración con el plan general del proyecto.
¿Cuánto tiempo adicional supone incorporar el trabajo del SGSI? Depende en gran medida del alcance. Una funcionalidad pequeña puede añadir uno o dos días por control, mientras que una integración mayor que involucra a varios proveedores puede sumar entre dos y tres semanas de evaluación y pruebas, razón por la que un análisis de brechas temprano es fundamental.
¿Cuál es el error más habitual en un proyecto SGSI? Tratar la Declaración de Aplicabilidad como un documento que se finaliza al término del proyecto en lugar de construirla de forma incremental a medida que los controles se vuelven relevantes durante la ejecución.
Fuentes
- Project management 2nd edition — Chapter 1.3 Project constraints
- ISO/IEC 27001 — Information security, cybersecurity and privacy protection — ISO
- Tackling ISO 27001: A Project to Build an ISMS — SANS Institute
- Knowledge management in project management: An ISM approach