Saltar a contenido

1.2.1.-Plan director de seguridad

1.2.1. Plan Director de Seguridad

Idea principal

Un Plan Director de Seguridad (PDS) convierte las necesidades de seguridad de una organización en una hoja de ruta de iniciativas priorizadas, con responsables, recursos, plazos y resultados que se puedan comprobar. Se apoya en el contexto del negocio y en la evaluación de la situación y de los riesgos; no es una garantía de seguridad ni una lista genérica de productos que haya que comprar.

En el tema Principios generales de ciberseguridad has visto que una organización debe conocer qué activos necesita proteger, qué amenazas pueden afectarlos y qué medidas reducen los riesgos. El siguiente paso es ordenar ese trabajo: decidir qué mejorar primero, quién se encargará y cómo se comprobará el resultado.

El objetivo de este tema es entender cómo se elabora y se pone en marcha esa hoja de ruta. Aprenderás a relacionar el diagnóstico con las prioridades del negocio, a proponer iniciativas viables y a explicar por qué requieren recursos. En el tema siguiente, Análisis de riesgos, estudiarás con más detalle cómo identificar y valorar los riesgos que alimentan las decisiones del PDS.

Código Descripción
RA 1 Desarrolla planes de prevención y concienciación en ciberseguridad, estableciendo normas y medidas de protección.
CE 1.a Se han definido los principios generales de la organización en materia de ciberseguridad, que deben ser conocidos y apoyados por la dirección de la misma.

El tema se relaciona directamente con el criterio CE 1.a: un PDS necesita principios y prioridades respaldados por la dirección. La revisión de controles que aparece en el diagnóstico del PDS aporta contexto, pero no sustituye por sí sola la auditoría específica del plan de prevención y concienciación contemplada en el CE 1.e.

Qué deberías saber al terminar

Al acabar este tema deberías poder:

  • explicar para qué sirve un PDS y en qué se diferencia de una política, un control o un SGSI;
  • describir sus seis fases y los entregables principales de cada una;
  • convertir una brecha o necesidad de seguridad en una iniciativa con alcance, responsable, recursos y una forma de medir su resultado;
  • priorizar iniciativas con criterios transparentes, teniendo en cuenta riesgos, estrategia, obligaciones y capacidad de la organización;
  • reconocer el papel de ISO/IEC 27001 e ISO/IEC 27002 sin confundir sus funciones.

Mapa del tema

Seguiremos esta secuencia:

  1. qué es un PDS y cómo se relaciona con otros instrumentos de seguridad;
  2. qué información se necesita para prepararlo;
  3. cómo se pasa del diagnóstico a una cartera priorizada de iniciativas;
  4. cómo se aprueba, ejecuta y mejora el plan.

1. Del diagnóstico a una hoja de ruta

Una empresa puede depender de una tienda en línea, un sistema de facturación, el correo, los datos de clientes y los servicios de sus proveedores. Si uno de esos elementos falla, se expone a pérdidas económicas, interrupciones, obligaciones legales incumplidas o daños a su reputación. La respuesta no consiste necesariamente en comprar más herramientas: primero hay que entender qué necesita proteger la organización y qué puede hacer con los recursos disponibles.

Un Plan Director de Seguridad (PDS) es una planificación coordinada de iniciativas para mejorar la seguridad de la información y reducir los riesgos a un nivel que la organización haya decidido gestionar. Ordena las actuaciones a corto, medio y largo plazo y relaciona cada una con un objetivo, una persona o área responsable, unos recursos y un criterio de seguimiento.

El PDS puede incluir medidas técnicas, organizativas, físicas, legales y de formación. Por ejemplo, puede proponer revisar los accesos, mejorar las copias de seguridad, formar al personal, definir un procedimiento de respuesta a incidentes, revisar contratos de proveedores o preparar un plan de continuidad.

PDS

Hoja de ruta aprobada por la dirección que organiza y prioriza las iniciativas de seguridad de una organización, a partir de su situación, sus objetivos y los riesgos que necesita tratar.

El PDS no es una metodología única impuesta por ley ni un producto que se instala. Las seis fases que se presentan aquí siguen la guía de INCIBE citada en las fuentes; una organización puede adaptar el método a su tamaño, sector, obligaciones, alcance y recursos.

Instrumento Para qué sirve Ejemplo
Política de seguridad Expresa principios, reglas y responsabilidades de la organización. Una política establece que los accesos privilegiados deben protegerse con autenticación multifactor.
Control de seguridad Reduce la probabilidad o el impacto de un escenario concreto. Aplicar autenticación multifactor a las cuentas de administración.
Plan Director de Seguridad Ordena las iniciativas necesarias, sus prioridades, responsables, recursos y plazos. Un proyecto para desplegar autenticación multifactor, con alcance, fecha y criterio de comprobación.
SGSI Sistema de gestión que establece cómo dirigir, operar, revisar y mejorar la seguridad de la información. Un SGSI implantado conforme a ISO/IEC 27001.

El plan no sustituye a la gestión diaria

El PDS organiza mejoras y permite seguirlas. No reemplaza las políticas, los procedimientos ni la operación cotidiana de los controles. Tampoco garantiza que no vaya a producirse un incidente: ayuda a tomar decisiones informadas y a mejorar la capacidad de prevenir, detectar, responder y recuperarse.

2. Marco de referencia, controles y responsabilidades

2.1. ISO/IEC 27001 e ISO/IEC 27002

Las normas pueden ayudar a estructurar el diagnóstico, pero no se deben aplicar como una lista automática. Hay que seleccionar los controles pertinentes para el alcance, el contexto y las obligaciones de la organización.

Referencia Función principal Qué conviene recordar
ISO/IEC 27001:2022 Establece requisitos para crear, implantar, mantener y mejorar un Sistema de Gestión de Seguridad de la Información (SGSI). Una organización puede someter el SGSI a certificación dentro de un alcance definido. La norma no equivale al PDS.
ISO/IEC 27002:2022 Ofrece orientación para seleccionar y aplicar controles de seguridad de la información. No es una norma de certificación independiente. La edición de 2013 agrupaba 114 controles en 14 dominios; la edición de 2022 reúne 93 controles en cuatro temas: organizativos, de personas, físicos y tecnológicos.
Normativa y compromisos aplicables Define obligaciones legales, reglamentarias o contractuales que la organización debe determinar. No todas las referencias se aplican a todas las organizaciones. Hay que comprobar el ámbito y los requisitos concretos.
Esquema didáctico rotulado como borrador de ISO/IEC 27002:2013, con 14 dominios, 35 objetivos de control y 114 controles
Material didáctico histórico, marcado como borrador, sobre la edición 2013; no es el texto oficial ni muestra la estructura de 2022.

La imagen muestra una edición anterior

La figura es material didáctico rotulado como borrador sobre ISO/IEC 27002:2013; sirve únicamente para reconocer su estructura histórica. No es el texto oficial de la norma. Para el diagnóstico actual descrito en este tema se toma como referencia la edición 2022, organizada en cuatro temas y con 93 controles.

Por ejemplo, el Reglamento General de Protección de Datos (RGPD) contiene obligaciones sobre el tratamiento de datos personales; el Esquema Nacional de Seguridad (ENS) se aplica en el ámbito definido por su normativa, y PCI DSS (estándar de seguridad de datos del sector de tarjetas de pago) puede resultar pertinente según la participación de la organización en ese entorno. No son referencias intercambiables: la organización debe determinar cuáles le afectan y pedir asesoramiento especializado cuando sea necesario.

ISO/IEC 27001 e ISO/IEC 27002 no son lo mismo

ISO/IEC 27001 establece requisitos de un SGSI; ISO/IEC 27002 aporta orientación sobre controles. Usar controles de ISO/IEC 27002 puede ayudar a planificar mejoras, pero no demuestra por sí solo que se cumpla ISO/IEC 27001 ni una obligación legal.

En la fase de diagnóstico puede prepararse una matriz de controles para registrar cuáles son relevantes, qué evidencias existen, qué brechas se han detectado y qué mejoras se proponen. Si la organización implanta un SGSI conforme a ISO/IEC 27001, la Declaración de Aplicabilidad (Statement of Applicability, SoA) identifica los controles necesarios, justifica su inclusión, registra si están implantados y justifica la exclusión de controles del Anexo A que no sean necesarios. Una matriz de un PDS puede ser útil, pero no debe llamarse SoA ni presentarse como obligatoria para cualquier PDS.

2.1.1. Ejemplo aplicado: comercio electrónico

Una tienda en línea puede utilizar la guía de controles como punto de partida y seleccionar medidas según sus datos, servicios y riesgos. Los ejemplos siguientes son decisiones posibles, no requisitos idénticos para todas las tiendas:

Área Ejemplo de iniciativa o control
Accesos Asignar permisos por función y aplicar autenticación multifactor (MFA) a accesos privilegiados o remotos cuando corresponda.
Protección de datos Proteger las comunicaciones con TLS (Transport Layer Security) correctamente configurado y valorar el cifrado de datos almacenados y la gestión de sus claves.
Red y servicios Restringir comunicaciones innecesarias, separar los servicios expuestos de los sistemas internos y proteger los accesos remotos con mecanismos adecuados.
Incidentes Definir responsabilidades, vías de notificación, recogida de evidencias y revisión de lecciones aprendidas.
Proveedores de pago Evaluar el servicio y las obligaciones contractuales; comprobar el alcance de PCI DSS cuando la actividad esté dentro de su ámbito. Externalizar el pago no elimina todas las responsabilidades de la tienda.
Datos personales Determinar la base jurídica y las obligaciones aplicables a cada tratamiento. El consentimiento no es la base jurídica universal y la designación de una persona delegada de protección de datos solo es obligatoria en los supuestos previstos por la normativa.

Como parte de una iniciativa de privacidad, también puede definirse cómo tramitar las solicitudes de derechos —incluida la supresión cuando proceda, según el artículo 17 del RGPD— y cómo evaluar una brecha de datos personales para determinar si corresponde notificar a la autoridad de control o comunicarla a las personas afectadas (artículos 33 y 34). Las obligaciones dependen de las circunstancias; no toda brecha genera las mismas notificaciones.

La edición de ISO/IEC 27002 utilizada y el alcance deben quedar claros al citar controles. Para RGPD y otras obligaciones legales, la organización debe contar con las áreas competentes: una lista de controles no sustituye el análisis jurídico.

2.2. Quién participa

La seguridad es transversal. La organización debe dejar claro quién decide, quién coordina y quién aporta información o ejecuta cada iniciativa. En una empresa pequeña una persona puede asumir varias funciones, pero las responsabilidades no deberían quedar implícitas.

Rol o área Contribución habitual
Dirección o patrocinador ejecutivo Aprueba el alcance y las prioridades, asigna recursos y decide sobre los riesgos que acepta dentro de sus competencias.
Coordinación del PDS Organiza el trabajo, mantiene la hoja de ruta y comunica el estado de las iniciativas. Puede recaer en la persona responsable de seguridad o en otra función designada.
Responsables de procesos e información Explican el valor de los procesos y datos, validan las necesidades y participan en la selección de prioridades.
Equipo TIC y proveedores Aportan el estado técnico, estiman el esfuerzo y ejecutan o apoyan las medidas acordadas.
Áreas como RR. HH., Jurídico, Compras y Administración Aportan requisitos, procesos y dependencias que no se pueden valorar solo desde tecnología.

3. Fases para elaborar y gestionar el PDS

El siguiente diagrama resume el ciclo de seis fases. La última alimenta una nueva revisión de la situación: al cambiar la organización, los servicios, las amenazas o las obligaciones, también pueden cambiar las prioridades.

flowchart LR
  A["1. Conocer la situación actual"] --> B["2. Entender la estrategia"]
  B --> C["3. Definir iniciativas"]
  C --> D["4. Clasificar y priorizar"]
  D --> E["5. Obtener aprobación"]
  E --> F["6. Ejecutar y mejorar"]
  F --> A

3.1. Fase 1: conocer la situación actual

El propósito es construir una imagen documentada y realista de la seguridad dentro del alcance acordado. No basta con preguntar si existe un control: conviene comprobar cómo se aplica y qué evidencias permiten sostener esa respuesta.

3.1.1. Definir el alcance y el contexto

El alcance establece qué procesos, sedes, departamentos, sistemas, servicios, información y terceros se incluyen en el trabajo. Puede abarcar toda la organización o comenzar por un proceso crítico, siempre que se expliquen los límites y las dependencias que quedan fuera.

Por ejemplo, una pyme industrial puede empezar por el proceso de compras, almacén y facturación, que depende de un sistema de planificación de recursos empresariales (ERP). El análisis debe identificar qué personas, servicios, aplicaciones, datos, proveedores e instalaciones hacen posible ese proceso. Si se excluye un elemento que puede afectar al proceso, conviene registrar la decisión y el motivo.

3.1.2. Identificar activos y responsables

Un inventario útil puede incluir información en soporte digital o papel, procesos, aplicaciones, equipos, redes, instalaciones, personas con conocimientos clave y servicios de proveedores. Para cada activo o grupo de activos interesa registrar, según el alcance:

  • nombre y descripción;
  • ubicación o servicio del que depende;
  • proceso de negocio al que da soporte;
  • responsable de la información o del proceso y contacto técnico;
  • clasificación o importancia para la organización;
  • proveedores y dependencias relevantes.

El objetivo no es producir un inventario perfecto antes de empezar, sino contar con información suficiente para decidir y mantenerla actualizada. Un inventario sin responsables ni relación con los procesos puede quedar obsoleto sin que nadie lo advierta.

3.1.3. Revisar las medidas existentes

La evaluación inicial puede combinar entrevistas, revisión de documentación, comprobaciones técnicas, observación de procesos y evidencias de funcionamiento. Se revisan medidas organizativas, de personas, físicas y tecnológicas que sean pertinentes para el alcance. Por ejemplo:

  • políticas, procedimientos, asignación de responsabilidades y formación;
  • altas, cambios y bajas de cuentas y permisos;
  • seguridad de instalaciones, salas técnicas y dispositivos;
  • mantenimiento, actualizaciones, registros, segmentación y protección de equipos;
  • copias de seguridad, pruebas de restauración y continuidad;
  • gestión de incidentes y relación con proveedores.

La referencia ISO/IEC 27002:2022 puede ayudar a organizar esta revisión, pero no es necesario implantar todos sus controles. La selección debe responder a los procesos incluidos, los riesgos, las obligaciones y las características reales de la organización.

La revisión puede realizarla el equipo interno o una entidad externa con la competencia adecuada. Si se recurre a especialistas externos, se acuerdan antes el alcance, los métodos, los horarios y la coordinación con el personal propio.

Las comprobaciones técnicas requieren autorización

Las auditorías y pruebas deben limitarse a sistemas propios o a aquellos para los que exista autorización explícita. Antes de realizar pruebas, se acuerdan el alcance, los horarios, los métodos y las medidas para evitar interrupciones. No se deben probar herramientas sobre redes ajenas ni sobre sistemas productivos fuera del alcance autorizado.

3.1.4. Valorar brechas y madurez

Una organización puede usar una escala de madurez para describir hasta qué punto un control está definido, aplicado y revisado. La tabla siguiente es una escala didáctica de ejemplo, no una escala universal de ISO ni un porcentaje de cumplimiento:

Nivel Descripción orientativa Ejemplo con copias de seguridad
0 – Inexistente El control no se realiza o no hay evidencia de que exista. No se hacen copias ni hay responsable asignado.
1 – Inicial Se actúa de forma puntual y depende de personas concretas. Alguien copia archivos manualmente cuando lo recuerda.
2 – Repetible La actividad se repite, pero el proceso sigue siendo informal o incompleto. Hay copias programadas, pero no se revisan los resultados ni se prueba la restauración.
3 – Definido Existe un procedimiento documentado y se aplica de forma consistente. Se especifican alcance, responsables, frecuencia, conservación y evidencias.
4 – Gestionado Se supervisa el proceso y se mide si funciona. Se revisan las ejecuciones y se realizan restauraciones de prueba planificadas.
5 – Mejorado Los resultados se usan para revisar y mejorar el control. Se analizan fallos de restauración, se corrigen causas y se actualiza el procedimiento.
Escala ilustrativa de madurez de controles, de inexistente a optimizado, con porcentajes asociados a cada nivel
Modelo visual de madurez 0–5. Los porcentajes forman parte de esta representación y no constituyen una escala universal.

La puntuación debe apoyarse en evidencias y en criterios definidos por la organización. Aunque la imagen asocia cada nivel a un porcentaje, no significa que un control de nivel 4 tenga exactamente un 80 % de eficacia. Para comunicar las brechas puede compararse el estado actual con objetivos a corto y medio plazo; un gráfico radar es solo una ayuda visual y no convierte la valoración en una medida exacta.

3.1.5. Realizar una evaluación técnica y una primera revisión de riesgos

Cuando el alcance lo requiera, el diagnóstico se complementa con revisiones autorizadas de redes, sistemas, aplicaciones y configuraciones. Se pueden comprobar, entre otros aspectos, la exposición de servicios, las reglas de cortafuegos y segmentación, la gestión de parches, los permisos, la protección antimalware, los registros, los sistemas de detección y prevención de intrusiones (IDS/IPS), la seguridad de aplicaciones y la capacidad de recuperar datos. No son controles obligatorios para todos los PDS: se seleccionan según el alcance y el contexto. Los hallazgos se documentan con evidencias y se valoran según su efecto en el negocio; una vulnerabilidad técnica no determina por sí sola la prioridad.

El PDS también necesita una valoración inicial de los riesgos para entender qué escenarios podrían afectar a los activos, qué controles existen y qué riesgos pueden quedar. En este punto se establece el contexto y se identifican necesidades; el proceso detallado de alcance, activos, amenazas, vulnerabilidades, estimación y tratamiento se desarrolla en Análisis de riesgos.

3.1.6. Formular objetivos de mejora

Con las brechas identificadas se fijan objetivos de seguridad realistas, relacionados con el negocio y con la capacidad de la organización. Conviene indicar:

  • qué estado se quiere alcanzar;
  • en qué plazo se revisará;
  • qué evidencia demostrará el avance;
  • quién validará el resultado;
  • qué limitaciones o dependencias hay que resolver.

Por ejemplo, en vez de fijar como objetivo «tener las copias al 100 %», una organización puede acordar que las copias de determinados servicios se ejecuten según el procedimiento aprobado y que las restauraciones de prueba alcancen los objetivos de recuperación definidos para esos servicios. El objetivo debe ser comprensible y verificable, sin confundir una cifra de madurez con una garantía.

El gráfico siguiente ilustra cómo comparar el estado actual con objetivos definidos para distintos dominios. La organización decide qué dominios evaluar y qué metas son realistas; la etiqueta «óptimo» representa una aspiración propia, no un nivel universal que todas deban alcanzar.

Gráfico radar ilustrativo que compara el estado actual, el objetivo y una aspiración de mejora en varios dominios de seguridad
Ejemplo de visualización de objetivos de mejora por dominios; los valores y el nivel «óptimo» son orientativos.

3.2. Fase 2: entender la estrategia de la organización

La seguridad debe ayudar a la organización a cumplir sus objetivos, no convertirse en un conjunto de medidas desconectadas. En esta fase se consulta a la dirección y a las áreas implicadas para conocer, por ejemplo:

  • planes de crecimiento, nuevos servicios, fusiones o cambios de sede;
  • procesos que generan ingresos o cuya interrupción tendría consecuencias relevantes;
  • cambios de arquitectura, externalización, servicios en la nube o dependencia de proveedores;
  • requisitos legales, regulatorios y contractuales que puedan resultar aplicables;
  • recursos, presupuesto, personal disponible y restricciones técnicas.

Si una editorial planea ofrecer impresión bajo demanda, tendrá que revisar cómo cambian sus procesos, su volumen de datos y las dependencias de sus sistemas y proveedores. La estrategia permite anticipar esas necesidades antes de escoger proyectos y plazos.

Ejemplo

Una organización proyecta trasladar parte de su plataforma a un servicio en la nube. El PDS debe contemplar la transición, las responsabilidades con el proveedor, los accesos, las copias, la continuidad y los requisitos aplicables. No sería razonable definir primero una solución técnica y preguntar después si encaja con el plan de negocio.

3.3. Fase 3: definir proyectos e iniciativas

Las brechas, los riesgos y los objetivos se traducen en iniciativas. Se pueden agrupar según su origen o naturaleza, por ejemplo:

  1. mejoras organizativas, de procedimientos y de cumplimiento;
  2. mejoras técnicas o físicas detectadas en las revisiones;
  3. medidas para tratar riesgos que superen el nivel aceptado por la organización.

Al revisar los riesgos, la organización puede decidir evitar la actividad que los origina, mitigarlos mediante controles, compartir o transferir parte de sus consecuencias o aceptarlos de forma consciente y aprobada. Estas decisiones no son equivalentes: contratar un seguro no impide el incidente ni elimina todas las obligaciones. La valoración y el tratamiento detallados se desarrollan en el tema siguiente; en el PDS se registran las decisiones y se planifican las iniciativas que correspondan.

Decisión Qué significa Ejemplo
Evitar Dejar de realizar la actividad que genera el riesgo, si es viable. Retirar un servicio antiguo que ya no aporta valor y no se puede proteger de forma proporcionada.
Mitigar Reducir la probabilidad o el impacto mediante controles. Mejorar las copias y probar la restauración de un servicio prioritario.
Compartir o transferir Compartir parte de las consecuencias mediante acuerdos o seguros, sin eliminar el riesgo. Contratar una cobertura con límites y exclusiones revisados.
Aceptar Mantener el riesgo de forma consciente, justificada, aprobada y revisable. Aplazar una mejora no crítica mientras se documenta la decisión y se fija una fecha de revisión.

Riesgo residual y umbral aceptable

Después de considerar las salvaguardas existentes, la organización estima el riesgo que permanece —actual o residual, según el método utilizado— y lo compara con sus criterios de aceptación. Si el criterio aprobado permite riesgos medios o inferiores y uno queda alto, existe un desajuste o brecha de riesgo: el PDS puede planificar un tratamiento o elevar la decisión para que la autoridad apruebe una excepción documentada. El ejemplo no fija un umbral universal. Esta brecha de riesgo no significa que haya ocurrido una brecha de seguridad o un incidente. La valoración detallada se desarrolla en Análisis de riesgos.

Cada iniciativa debe tener suficiente información para que se pueda aprobar, estimar y seguir. Como mínimo, conviene registrar el objetivo, el alcance, la relación con la brecha o el riesgo que trata, una persona responsable, los recursos y el coste estimado, la duración, las dependencias, los hitos y cómo se comprobará el resultado.

ID Iniciativa Objetivo y relación con la brecha Responsable Recursos y plazo Evidencia de resultado
01 Probar la restauración de copias del ERP Comprobar si la organización puede recuperar los datos y servicios incluidos en el alcance. Responsable del servicio, con apoyo de TIC. Tiempo técnico y entorno de prueba; plazo por acordar. Registro de una restauración de prueba, incidencias detectadas y acciones correctoras.

El plazo y los recursos de la tabla no son valores universales: se concretan después de conocer los sistemas, el equipo disponible y las necesidades del proceso. También debe mantenerse la trazabilidad entre la iniciativa y el diagnóstico que la justifica.

3.3.1. Ejemplos de iniciativas habituales

Los siguientes proyectos aparecen con frecuencia, pero no son una lista obligatoria. Cada organización elige y adapta lo que responda a sus necesidades:

Iniciativa Ejemplo de propósito
Política de seguridad de la información Definir principios, responsabilidades y reglas generales, con aprobación y difusión adecuadas.
Plan de formación y concienciación Ayudar al personal a reconocer riesgos y a comunicar situaciones sospechosas.
Gestión de incidentes Establecer cómo detectar, registrar, escalar, responder y aprender de los incidentes.
Gestión de privacidad y cumplimiento Revisar los tratamientos de datos personales y las obligaciones que resulten aplicables, con asesoramiento de las áreas competentes.
Coordinación entre RR. HH. y TIC Coordinar altas, cambios de puesto y bajas, incluidos los accesos y dispositivos.
Continuidad y recuperación Preparar medidas para mantener o restablecer procesos y servicios prioritarios.
Seguridad de la red corporativa Revisar segmentación, reglas de comunicación, exposición y monitorización.
Copias de seguridad Definir alcance, protección, conservación y pruebas de restauración.
Clasificación de la información Establecer categorías y pautas para acceder, compartir, conservar y eliminar la información.
Gestión de proveedores Identificar proveedores críticos y definir requisitos y seguimiento de seguridad adecuados.

3.4. Fase 4: clasificar y priorizar las iniciativas

La organización normalmente no puede abordar todos los proyectos al mismo tiempo. Para ordenar el trabajo debe valorar, con criterios conocidos:

  • la reducción esperada de riesgos y la criticidad de los procesos afectados;
  • las obligaciones legales o contractuales y sus plazos;
  • el esfuerzo, el coste, el tiempo y la capacidad real del equipo;
  • el impacto de la implantación en las operaciones;
  • las dependencias entre iniciativas;
  • la posibilidad de obtener mejoras tempranas (quick wins) sin dejar de planificar cambios estructurales.

Una matriz de impacto y esfuerzo puede facilitar la conversación, pero no debe sustituir la justificación. Una iniciativa de alto esfuerzo puede seguir siendo prioritaria si trata un riesgo grave o una obligación con fecha límite; una acción sencilla no es necesariamente importante si apenas mejora la situación.

Ejemplo de iniciativa Impacto esperado Esfuerzo estimado Lectura inicial
Probar la restauración de una copia de un servicio crítico Alto si no se había comprobado la recuperación. Bajo o medio, según el servicio y el entorno de prueba. Posible mejora temprana, tras verificar el alcance y los riesgos de la prueba.
Implantar MFA en cuentas privilegiadas Alto cuando existen accesos privilegiados expuestos o débilmente protegidos. Medio, según los sistemas y la preparación de las personas usuarias. Prioridad potencialmente alta; requiere plan de despliegue y soporte.
Centralizar registros de seguridad Variable según cobertura, capacidad de análisis y respuesta. Medio o alto. Puede depender de inventariar fuentes y definir quién revisará las alertas.
Diseñar un plan de continuidad para procesos críticos Alto para los procesos que no pueden interrumpirse durante mucho tiempo. Alto. Proyecto estructural que necesita información de negocio y pruebas.

Estas valoraciones son ejemplos, no prioridades universales. Las personas responsables deben contrastar los supuestos y documentar por qué se adelanta, aplaza o descarta cada iniciativa. Las decisiones de tratamiento de riesgos se estudian en el tema siguiente.

3.5. Fase 5: obtener la aprobación de la dirección

La aprobación convierte la propuesta en un compromiso organizativo. Para facilitar una decisión informada, se prepara un dossier ejecutivo, adecuado a su audiencia, que puede incluir:

  • el alcance y el estado inicial, con las fortalezas y las brechas principales;
  • los escenarios de riesgo prioritarios y sus posibles consecuencias para el negocio;
  • las iniciativas propuestas, su prioridad, responsables, plazos, dependencias y recursos;
  • los beneficios esperados y las consecuencias de aplazar o no ejecutar cada iniciativa;
  • las decisiones que se solicitan a la dirección, incluidos los criterios de aceptación de riesgos.

La dirección puede ajustar el alcance, los plazos o el orden de las iniciativas. La persona que coordina el PDS debe registrar los cambios y las decisiones, comunicar lo aprobado a las áreas implicadas y confirmar que se han asignado los recursos. No basta con aprobar un documento si después no hay tiempo, presupuesto o autoridad para ejecutar sus acciones.

Explicar el plan en términos comprensibles

La dirección necesita conocer las consecuencias y las alternativas; no basta con presentar una lista de vulnerabilidades o nombres de herramientas. Los detalles técnicos sensibles se comparten solo con las personas que los necesitan para decidir o ejecutar las medidas.

3.6. Fase 6: ejecutar y mejorar continuamente

Una vez aprobado el PDS, se gestionan las iniciativas como proyectos o actividades coordinadas. Para ello conviene:

  1. comunicar el plan y las responsabilidades a las personas afectadas;
  2. asignar una persona coordinadora y responsables concretos para cada iniciativa;
  3. confirmar presupuesto, recursos, calendario, dependencias y ventanas de cambio;
  4. seguir los hitos y resolver bloqueos mediante una estructura de coordinación adecuada;
  5. comprobar con evidencias que la medida se ha implantado y que reduce la brecha prevista;
  6. revisar el plan cuando haya cambios en el negocio, los sistemas, los proveedores, las amenazas o las obligaciones aplicables.

Los indicadores deben medir tanto el avance como el resultado. Algunos ejemplos son el porcentaje de restauraciones de prueba satisfactorias dentro de los objetivos acordados, el tiempo de resolución de incidencias del proyecto o el número de cuentas privilegiadas revisadas. Un porcentaje de proyectos completados es útil para el seguimiento, pero no demuestra por sí solo que los controles sean eficaces.

Al cerrar una iniciativa se documentan los resultados, las incidencias y las lecciones aprendidas. Cuando termina el ciclo o cambia de forma significativa el contexto, se revisa de nuevo la situación y se inicia otra iteración. La frecuencia de revisión debe definirse según el contexto de la organización; no existe un único calendario anual válido para todos los PDS.

4. Caso integrado: editorial con tienda en línea y logística

Una editorial vende libros por Internet y gestiona el almacén y los pedidos mediante un ERP. Ha sufrido interrupciones del correo y errores en pedidos. Las copias se realizan semanalmente, pero no se ha comprobado si permiten recuperar los sistemas. La dirección valora ofrecer impresión bajo demanda, lo que modificaría algunos procesos y el tratamiento de información.

El equipo no empieza comprando herramientas. Sigue una secuencia de trabajo:

  1. Delimita el alcance: incluye la tienda, los datos y el proceso de pedidos, el ERP de logística, los servicios de correo necesarios y los proveedores de los que dependen. Deja por escrito las exclusiones.
  2. Recopila información: identifica activos y responsables, revisa cómo se ejecutan las copias, consulta a las áreas implicadas y obtiene evidencias de las medidas actuales.
  3. Analiza las necesidades: considera escenarios como ransomware en el ERP, un ataque de denegación de servicio contra la tienda o la exposición de datos. La probabilidad, el impacto y el riesgo residual se estiman con el método que se estudiará en Análisis de riesgos; no se asignan etiquetas sin justificar los criterios.
  4. Define iniciativas: por ejemplo, probar restauraciones, formalizar la gestión de incidentes, revisar la segmentación, implantar controles de acceso adecuados, mejorar la formación y preparar la continuidad de los procesos prioritarios.
  5. Prioriza y presenta: compara la reducción de riesgo esperada, las obligaciones, los recursos y las dependencias. Expone a la dirección un calendario y un coste estimado, junto con las decisiones pendientes.
  6. Ejecuta y verifica: asigna responsables, hace seguimiento de las iniciativas y comprueba con pruebas que las mejoras previstas se han conseguido. Después revisa el plan ante el crecimiento y los nuevos servicios.

Este caso ilustra que el mismo PDS puede incluir proyectos técnicos, organizativos y de continuidad. La prioridad final depende de las evidencias y decisiones de la organización; no se puede afirmar que un riesgo haya quedado aceptable solo porque se haya instalado una herramienta.

5. Entregables del PDS

El contenido exacto depende del alcance y del método adoptado. Un conjunto de trabajo puede incluir:

  • alcance, contexto, objetivos y personas responsables;
  • inventario de activos y dependencias relevantes;
  • evaluación inicial de controles, evidencias y brechas;
  • resultados de las revisiones técnicas y de cumplimiento que se hayan realizado;
  • registro de riesgos y decisiones de tratamiento, desarrollado según la metodología elegida;
  • cartera de iniciativas con prioridades, objetivos, recursos, costes, responsables, plazos y dependencias;
  • hoja de ruta o cronograma consolidado;
  • acta o registro de aprobación, decisiones y aceptación de riesgos;
  • indicadores e informes de seguimiento, junto con las lecciones aprendidas.

La matriz de controles puede servir para ordenar el diagnóstico. La SoA solo se preparará cuando corresponda dentro de un SGSI conforme a ISO/IEC 27001; no se debe presentar como entregable obligatorio de cualquier PDS.

6. Buenas prácticas

Para trabajar el PDS con criterio profesional:

  • Empieza por el contexto y el alcance: explica qué procesos se incluyen y por qué, e identifica sus dependencias.
  • Cuenta con apoyo de la dirección: el patrocinio debe traducirse en decisiones, recursos y seguimiento.
  • Involucra a las áreas afectadas: RR. HH., Jurídico, Compras, TIC y responsables de procesos aportan información distinta y necesaria.
  • Usa evidencias: distingue lo que está previsto, lo que está implantado y lo que se ha comprobado que funciona.
  • Relaciona cada iniciativa con una brecha o un riesgo: así se puede justificar su prioridad y verificar su resultado.
  • Planifica de forma realista: estima tiempo de las personas, presupuesto, dependencias, cambios operativos y necesidades de soporte.
  • Combina medidas: una herramienta no sustituye políticas, responsabilidades, procedimientos, formación y recuperación.
  • Mide resultados y revisa el plan: actualiza objetivos cuando cambian la organización o los riesgos, y registra las lecciones aprendidas.

7. Errores frecuentes

Error frecuente Por qué ocurre Cómo evitarlo
Convertir el PDS en una lista de compras tecnológicas. Se identifica seguridad únicamente con herramientas. Incluye iniciativas organizativas, físicas, humanas y técnicas, vinculadas a necesidades reales.
Intentar aplicar todos los controles de una norma sin revisar el alcance. Se confunde una referencia con una receta universal. Selecciona los controles pertinentes y justifica su relación con el contexto, los riesgos y las obligaciones.
Confundir ISO/IEC 27001 con ISO/IEC 27002 o con el PDS. Las tres referencias se usan en proyectos de seguridad, pero cumplen funciones distintas. Recuerda: 27001 define requisitos de un SGSI; 27002 ofrece orientación sobre controles; el PDS prioriza iniciativas.
Llamar SoA a cualquier lista de controles o exigirla en todo PDS. Se trasladan artefactos de un SGSI a un plan sin considerar su contexto. Reserva el término SoA para el documento correspondiente al SGSI basado en ISO/IEC 27001.
Interpretar una escala de madurez como porcentaje universal de seguridad. Una puntuación facilita la comparación y puede parecer una medida exacta. Define niveles y evidencias, explica que son una escala de trabajo y evita convertirlos en garantías o porcentajes sin base.
Fijar prioridades solo por facilidad, coste o intuición. Es sencillo comparar precios, pero se pierden de vista riesgos, obligaciones y dependencias. Registra criterios, supuestos y decisiones; contrástalos con las áreas responsables.
Dar por finalizada una iniciativa al instalar la solución. Se confunde la implantación técnica con la eficacia del control. Comprueba el funcionamiento con evidencias y verifica si se ha reducido la brecha prevista.
Aceptar o transferir un riesgo como si desapareciera. Se confunde una decisión o una cobertura económica con la eliminación del escenario. Registra quién acepta el riesgo y por qué; un seguro o contrato no impide el incidente ni elimina todas las responsabilidades.
Aprobar un plan sin asignar recursos ni responsables. El documento parece completo, pero no se ha preparado su ejecución. Vincula cada iniciativa con una persona responsable, recursos, plazos y autoridad para desbloquearla.
Difundir detalles técnicos sensibles sin control. Se confunde transparencia del plan con acceso irrestricto a toda la información. Ajusta el nivel de detalle y el acceso a las necesidades de cada audiencia.
Suponer que todo tratamiento de datos personales requiere consentimiento o que cualquier organización debe nombrar una persona delegada de protección de datos. Se generalizan obligaciones que dependen del tratamiento y de los supuestos definidos por la normativa. Determina la base jurídica y las obligaciones aplicables con apoyo de las áreas competentes.

8. Resumen

En este tema has aprendido que:

  • un PDS organiza y prioriza iniciativas para mejorar la seguridad de acuerdo con el contexto, la estrategia y los riesgos de la organización;
  • la guía de INCIBE presenta seis fases: conocer la situación, entender la estrategia, definir iniciativas, priorizarlas, obtener aprobación y ejecutarlas con mejora continua;
  • cada iniciativa debe tener un objetivo, un alcance, una persona responsable, recursos, plazos, dependencias y evidencias de resultado;
  • ISO/IEC 27001 establece requisitos para un SGSI e ISO/IEC 27002 orienta sobre controles; ninguna de las dos convierte automáticamente un PDS en un plan eficaz;
  • la dirección debe respaldar las prioridades y facilitar los recursos, y el plan debe revisarse cuando cambia el contexto.

Idea clave

Un PDS eficaz conecta lo que la organización necesita proteger con decisiones que puede ejecutar y comprobar. No busca comprarlo todo ni prometer riesgo cero: ayuda a priorizar, asignar responsabilidades, tratar los riesgos y mejorar de forma continua.

9. Para seguir practicando

Trabaja con una organización ficticia —por ejemplo, una tienda en línea, una clínica o una pyme industrial— y prepara un primer borrador de PDS:

  1. Define el alcance y anota qué procesos, activos, personas y proveedores quedan dentro.
  2. Describe tres brechas observables y qué evidencia necesitarías para confirmarlas.
  3. Propón tres iniciativas, incluyendo una mejora temprana y otra que requiera planificación a medio plazo.
  4. Para cada iniciativa, indica objetivo, responsable, recursos, plazo, dependencia y evidencia de resultado.
  5. Explica ante la dirección qué criterio has usado para priorizarlas y qué información te falta.

Puedes apoyarte en las plantillas locales de inventario de activos, verificación de controles y clasificación y priorización de iniciativas. Para desarrollar la valoración detallada de los escenarios, continúa con Análisis de riesgos y consulta la plantilla de análisis de riesgos.

Bibliografía y fuentes

Presentación