Grundschutz++ y el estándar BSI 300-1: metodología, catálogo de aplicación y el camino hacia la certificación

Tres componentes, un marco normativo

El BSI pone a disposición Grundschutz++ para la implantación de un sistema de gestión de la seguridad de la información. La metodología la describe el estándar BSI 300-1; según expone el BSI, deja margen de maniobra a quienes la aplican, por ejemplo en lo que respecta al tamaño de la institución y a la complejidad del dominio de información. El catálogo de aplicación complementa la metodología: el BSI ha trasladado sus aspectos normativos a requisitos, de modo que el catálogo abarca todos los requisitos de Grundschutz++, tanto los de la metodología como los técnicos y organizativos. Se pone a disposición en la biblioteca del estado de la técnica, la plataforma técnica en la que el BSI publica requisitos y medidas de forma centralizada y legible por máquina. Como los requisitos están disponibles en formato legible por máquina, su verificación puede automatizarse; según el BSI, está previsto que en el futuro herramientas digitales apoyen la implementación.

Qué sustituye GS++ – y qué se mantiene por ahora

Según el BSI, la biblioteca del estado de la técnica sustituye al Compendio IT-Grundschutz. Como evolución del IT-Grundschutz, el catálogo de aplicación ya solo describe requisitos que no se orientan a soluciones de TI específicas; el catálogo del Kernel, del que proceden los 901 requisitos técnicos y organizativos, contiene, según su descripción, exclusivamente requisitos de seguridad neutrales en cuanto a tecnología y fabricante. Por ello, los módulos referidos a productos, como los que el Compendio, edición 2023, incluía por ejemplo para «Windows Server 2012» o «Clients unter macOS» (clientes con macOS), no tienen un equivalente específico de producto en el catálogo de aplicación; para esos sistemas se aplican los requisitos neutrales respecto a las soluciones de las categorías de objetos objetivo correspondientes. En lugar de 111 módulos en diez capas, el catálogo se estructura en 20 prácticas; qué requisitos se aplican a un activo lo determinan las categorías de objetos objetivo. Por eso, a nuestro juicio, las cifras de requisitos del Compendio y del catálogo solo son comparables de forma limitada, y tampoco el BSI entiende su correspondencia del Compendio con GS++ como una equivalencia 1:1, sino como una ayuda orientativa; a fecha de 21/07/2026 figura como borrador. Por ahora, el IT-Grundschutz sigue siendo certificable: según el plan de hitos, la posibilidad de certificación termina el 30/11/2031, cinco años después de la publicación de GS++. Según lo previsto, a partir del 01/01/2027 podrán presentarse solicitudes de certificación ISO 27001 sobre la base de GS++; la fase Early Adopter está prevista desde el primer trimestre de 2027 hasta el 31/12/2027. Según sus propias indicaciones, el BSI adapta el plan de hitos de forma continua.

Carácter vinculante: administración federal y entidades NIS-2

Para las entidades de la administración federal, la ley BSI, en la nueva redacción dada por la ley alemana de transposición de NIS-2 de 2 de diciembre de 2025, establece requisitos mínimos que se derivan de los estándares BSI, del Compendio IT-Grundschutz – que la ley denomina conjuntamente «IT-Grundschutz» – y de los estándares mínimos del BSI para la administración federal. Su cumplimiento debe acreditarse ante el BSI a más tardar cinco años después de la entrada en vigor de la ley, es decir, según el BSI, en 2030; quien implementa los requisitos mínimos cumple con ello, al mismo tiempo, las especificaciones legales de gestión de riesgos, salvo que un acto de ejecución de la UE vaya más allá. La misma ley encomienda al BSI modernizar el IT-Grundschutz a más tardar el 1 de enero de 2026, y el catálogo de aplicación remite en sus metadatos precisamente a estas especificaciones para la administración federal. Ninguna de las fuentes primarias analizadas para esta página establece expresamente a partir de cuándo GS++ se considera la versión de referencia a efectos de esta obligación. Para las entidades particularmente importantes y las entidades importantes, la ley BSI no menciona el IT-Grundschutz: sus medidas deberán respetar el estado de la técnica y tener en cuenta las normas europeas e internacionales pertinentes. A nuestro juicio, GS++ es para ellas un camino posible, no obligatorio.

Estructura: seis capítulos, cuatro anexos

Destinatarios, elaboración, complementos anunciados

En el historial de cambios, la versión 1.0 lleva la fecha 20/10/2026 y la anotación «Publicación inicial de la primera versión aplicable»; como autor figura «S 13», que, según el organigrama del BSI, es la unidad «IT-Grundschutz und Mindeststandards» (IT-Grundschutz y estándares mínimos). Según el plan de hitos, el estándar se presentó el 27/10/2026 en la feria it-sa de Núremberg y se puso a disposición de la comunidad para su aplicación. Se dirige en primer lugar a los Early Adopters, es decir, a instituciones con experiencia que implantan GS++ de forma temprana y cuyas experiencias se incorporan a su desarrollo posterior. La metodología se elaboró junto con la comunidad Grundschutz y se puso a prueba en instituciones piloto seleccionadas; la fase piloto transcurrió del 1 de abril al 31 de agosto de 2026. El «Leitfaden zur Methodik Grundschutz++» (guía sobre la metodología Grundschutz++) de esa fase sigue disponible, pero lo determinante es el estándar. Hay varios elementos que el BSI, por ahora, solo anuncia: conceptos de formación para GS++-Praktiker y consultores GS++ para el 30/11/2026, un ejemplo de aplicación basado en el organismo público ficticio «BDIT» en diciembre de 2026, el concepto de medición del rendimiento para el 26/02/2027 e indicadores de rendimiento para cada requisito de las prácticas de metodología para el 31/03/2027.

Cinco pasos del proceso, cuatro fases PDCA

El estándar describe y adquiere carácter vinculante a través del catálogo: el BSI ha trasladado los contenidos normativos de la metodología a requisitos y los ha estructurado en prácticas de metodología. Estos 99 requisitos rigen para todas las instituciones y deben aplicarse a todo dominio de información; «no está previsto un procedimiento individual». El grado de exigencia de cada obligación lo determina el verbo modal del catálogo de aplicación: 80 de los 99 requisitos de metodología son DEBE, 19 DEBERÍA y ninguno PUEDE. El texto del estándar y el catálogo no siempre ponen el acento en el mismo lugar. En varios puntos, el estándar formula una recomendación donde el catálogo exige DEBE; en el riesgo residual de requisitos DEBERÍA pendientes ocurre lo contrario. Recomendación de VamiSec: planifique siguiendo los requisitos del catálogo y utilice el texto del estándar como explicación.

Contexto, cumplimiento y ámbito de aplicación

El análisis del contexto recoge los factores que actúan sobre la institución desde fuera – geopolíticos, jurídicos y regulatorios como NIS-2 o DORA, tecnológicos como el uso de la IA, económicos como las dependencias de las cadenas de suministro, sociales, así como ecológicos y físicos, por ejemplo la ubicación junto a un río – y los factores internos: estrategias y objetivos, estructura, procesos establecidos, el panorama de TI sin inventario detallado, la cultura de la institución y su actitud ante la seguridad, así como la escasez de recursos. La gestión del cumplimiento aporta el registro de requisitos legales, leyes y catálogos de requisitos, normativa interna y obligaciones legales y contractuales; lo que se derive de ello se tiene en cuenta en el paquete de requisitos. El ámbito de aplicación lo determina la dirección de la institución: los procesos de negocio, y de forma completa, las unidades de la institución, ubicaciones, aplicaciones y sistemas de TI pertinentes, además de la delimitación respecto a socios y proveedores de servicios externos y, en su caso, las áreas excluidas. Las partes interesadas, como clientes, proveedores de servicios, autoridades de supervisión, personal o representaciones del personal, se registran junto con sus expectativas; con la dirección se determina qué obligaciones vinculantes se incorporan al SGSI como requisitos.

Procesos de negocio: tan sencillo como sea posible, tan preciso como sea necesario

Los procesos de negocio del ámbito de aplicación deben identificarse y documentarse; se incluyen también los procedimientos administrativos y especializados. Constituyen la base para la determinación de la necesidad de protección, el registro de activos y la consideración de riesgo. Según el estándar, para la documentación basta con que la finalidad del proceso sea reconocible en relación con los objetivos de la institución. Las fuentes son los mapas de procesos y los sistemas de gestión existentes, como un sistema de gestión de la continuidad de negocio (BCMS) o de la protección de datos (DSMS), y, en los organismos públicos, sus mandatos legales. Si no se dispone de tales visiones de conjunto, resulta útil el análisis simplificado de procesos de negocio del anexo del estándar, concebido deliberadamente como requisito mínimo: no se exige ni una gestión integral de procesos ni una documentación exhaustiva de los procesos.

1. 1
   Examinar los flujos de trabajo

   Un proceso de negocio se repite periódicamente o cuando surge un motivo concreto, es esencial para el mandato o los servicios de la institución, conduce a un resultado trazable y consta de varias actividades relacionadas entre sí por su contenido. Los pasos de trabajo aislados no son procesos de negocio; debería evitarse un desglose demasiado fino.

2. 2
   Aprovechar las fuentes existentes

   Organigramas y planes de distribución de funciones, cometidos legales o estatutarios, el registro de actividades de tratamiento, inventarios de aplicaciones y sistemas de la CMDB, catálogos de procesos, herramientas de SGSI e inventarios de contratos y de proveedores de servicios. La conversación con las personas responsables puede resultar especialmente útil.

3. 3
   Documentar cinco datos

   Identificador, nombre, persona, rol o unidad organizativa con responsabilidad funcional, descripción breve y aplicaciones esenciales. La descripción breve debe permitir reconocer la finalidad, el resultado esencial y la contribución a los objetivos de la institución; la forma – tabla, catálogo de procesos, wiki o herramienta de SGSI – puede elegirse libremente.

Política de seguridad de la información, organización de la seguridad y aprobación

La política de seguridad de la información es el documento central del SGSI: describe objetivos concretos y medibles, por ejemplo según SMART, y la estrategia, establece el compromiso y la responsabilidad de la dirección de la institución, es aprobada por esta y debe comunicarse a todo el personal. Una organización de seguridad de la información con roles y responsabilidades definidos es «imprescindible». Deben evitarse los conflictos de intereses, por ejemplo entre la dirección de TI y el ISB o entre el delegado de protección de datos y el ISB, y el ISB u otro rol de la organización de seguridad debe estar involucrado en los proyectos relevantes para la seguridad. Deben establecerse procedimientos para la comunicación interna y externa y para el control de, como mínimo, todos los documentos relevantes para el SGSI. La responsabilidad del SGSI recae en la dirección de la institución y «no puede delegarse»; la dirección recibe propuestas de decisión sobre el ámbito de aplicación, la necesidad de protección, el orden de los procesos de negocio, los recursos y la política de seguridad de la información. Para terminar, la institución inicia la consideración de riesgo: apetito de riesgo y criterios de aceptación del riesgo en el nivel estratégico, procedimientos y criterios en el nivel metodológico, y roles, incluido el propietario del riesgo, en el nivel organizativo; el marco lo autoriza la dirección.

En la determinación de la necesidad de protección se decide, para cada proceso de negocio registrado, qué necesidad de protección tiene respecto a los valores fundamentales de confidencialidad, integridad y disponibilidad. Debe tomarse como base la información tratada en el proceso; lo determinante son los daños que pueden ir asociados a un menoscabo. La necesidad de protección debe determinarse y documentarse para cada proceso por separado, y la dirección de la institución la aprueba. El catálogo de aplicación convierte el procedimiento y la clasificación en requisitos DEBE y los refiere a «procesos de negocio o información»; la clasificación se realiza teniendo en cuenta los objetivos de negocio y en coordinación con la dirección de la institución. Según el texto de orientación, un proceso debe clasificarse con necesidad de protección alta cuando existe la amenaza de daños financieros o de reputación que pongan en peligro la supervivencia, o de repercusiones graves en los objetivos de negocio o en las obligaciones existentes, así como cuando el proceso trata información clasificada como especialmente confidencial.

Cinco escenarios de daño como ayuda para «alta»

• Infracción de leyes, normativas o contratos con consecuencias que amenacen la supervivencia de la institución
• Menoscabo del derecho a la autodeterminación informativa que provoque un daño reputacional considerable
• Menoscabo de la integridad personal
• Efecto negativo interno o externo que dañe de forma duradera la reputación de la institución
• Repercusiones financieras de una magnitud que amenace la supervivencia

La institución puede definir opcionalmente otras categorías propias, pero debe hacerlas corresponder con las dos categorías de GS++; para un SGSI certificable, en la categoría más baja debe respetarse siempre el estado de la técnica. En la primera implantación, el estándar recomienda empezar por el proceso de negocio más importante de la categoría de necesidad de protección más alta – si hay varios, elige la dirección de la institución – y examinar después, sucesivamente, todos los procesos del ámbito de aplicación. El BSI refiere el estado de la técnica publicado a situaciones de tratamiento típicas. En situaciones atípicas o con una necesidad de protección elevada – se mencionan los datos clasificados por el Estado y las categorías especiales de datos personales según el RGPD – pueden ser necesarias medidas de protección adicionales.

De la necesidad de protección al nivel de seguridad

Cada requisito lleva uno de dos niveles de seguridad: normal-SdT, el nivel de seguridad estándar, o elevado. Qué requisitos se seleccionan depende de la necesidad de protección del proceso de negocio considerado. Según el estándar, los requisitos del nivel elevado incluyen el verbo modal PUEDE y su cumplimiento es opcional; pueden utilizarse en la consideración de riesgo para identificar medidas adicionales, por ejemplo en caso de riesgo elevado. En el catálogo del 22/10/2026, esto se aplica a 224 de los 227 requisitos de nivel elevado; tres llevan DEBERÍA. Como requisito DEBERÍA, el catálogo de aplicación prevé revisar la clasificación inicial de los niveles de seguridad cuando el contexto de la institución difiera, según el texto de orientación especialmente en caso de necesidad de protección alta; también puede modificarse para activos concretos. El texto de orientación del catálogo menciona expresamente la rebaja de elevado a normal-SdT como motivo para una consideración de riesgo.

Ámbito de aplicación y dominio de información

El ámbito de aplicación fija la extensión formal y organizativa del SGSI; el dominio de información es su representación técnica y de contenido. Un ámbito de aplicación puede contener uno o varios dominios de información; un dominio de información puede abarcar todo el ámbito de aplicación o áreas concretas, divididas según la estructura organizativa, los procesos de negocio comunes o las aplicaciones. Los activos son todos los bienes materiales e inmateriales necesarios para los procesos de negocio considerados, por ejemplo aplicaciones, sistemas de TI o salas. Una delimitación clara garantiza que se recojan toda la información, todos los activos y todas las dependencias relevantes; los activos registrados son la condición previa para el paquete de requisitos. El catálogo de aplicación lo plasma en dos requisitos DEBE: definir el dominio de información, delimitado de forma trazable, sobre la base del ámbito de aplicación, y definir sus interfaces con procesos externos.

Los activos relevantes pueden ser, en particular, procesos de negocio, información, sistemas y aplicaciones, componentes de red y de comunicación, activos de infraestructura y físicos, así como activos de personal y organizativos. Para la documentación, la institución puede recurrir a los registros de activos existentes y a datos de sistemas recopilados digitalmente; las interfaces con procesos y sistemas externos o con otros dominios de información han de documentarse de forma inequívoca en los planos organizativo, técnico y de infraestructura. El orden del registro sigue la priorización derivada de la determinación de la necesidad de protección; los activos con propiedades y finalidad de uso similares pueden agruparse. El catálogo de aplicación exige como DEBE definir todos los activos relevantes de los procesos de negocio considerados; según el texto de orientación, en la primera pasada del ciclo PDCA bastan los activos del proceso de negocio más importante. Para cada activo prevé una denominación inequívoca, una breve descripción con su finalidad, la asignación a procesos de negocio y un rol responsable o un propietario del activo.

Dependencias: profundidad según la necesidad de protección

Según el estándar, para la representación pueden utilizarse fuentes existentes como CMDB, registros de activos, manuales de operación, diagramas de red o mapas de servicios, con el fin de evitar duplicar el trabajo. Lo decisivo es que las dependencias esenciales estén documentadas de forma trazable, ya que la consideración de riesgo con necesidad de protección alta parte del nivel del proceso de negocio y sigue la ruta de recursos. Para los procesos con necesidad de protección normal, el estándar exige como mínimo dos tipos de relación. A continuación, los activos se asignan a las categorías de objetos objetivo.

Prácticas: ordenación temática en tres categorías

Según el estándar, las prácticas sirven para una mejor comprensión: agrupan los requisitos por temas y se dividen en las categorías Metodología, Organizativa y Técnica. Las seis prácticas de metodología forman, con 99 requisitos, el marco de gestión y no llevan categoría de objetos objetivo. Las ocho prácticas organizativas y las seis técnicas contienen 901 requisitos; cada una de ellas comienza con el subgrupo «Fundamentos» y después se estructura por temas – en conjunto, en 103 subgrupos; el catálogo completo tiene 140. Las definiciones del BSI de cada práctica aclaran las delimitaciones; por ejemplo, que la práctica Monitorización y evaluación corresponde a la fase Check del ciclo PDCA, que Mejora cierra el ciclo y a la vez inicia uno nuevo, y que Detección deja el tratamiento de los eventos detectados a Gestión de incidentes de seguridad.

Para la lectura resulta útil un patrón: en las 14 prácticas técnicas y organizativas solo hay 69 requisitos DEBE, y todos se encuentran en el subgrupo «Fundamentos». En cada práctica forman el mismo marco de proceso – implantar procedimientos y reglas, documentarlos, asignar las tareas asociadas, informar a los responsables y revisar las reglas periódicamente y cuando la ocasión lo requiera; en la práctica Concienciación, en lugar de la revisión figura un requisito DEBERÍA sobre la medición del éxito. Los 832 requisitos restantes de estas prácticas son DEBERÍA o PUEDE, y los requisitos PUEDE pertenecen sin excepción al nivel de seguridad elevado. A nuestro juicio, DEBERÍA es, por tanto, la auténtica vara de medir de GS++: una desviación ha de sopesarse cuidadosamente y justificarse de forma sólida, y un incumplimiento permanente desencadena una consideración de riesgo.

Categorías de objetos objetivo: nodos padre y nodos hijo

Los nodos jerárquicamente superiores se denominan nodos padre, y los subordinados a ellos, nodos hijo. Los requisitos del nivel más alto de una rama suelen tener carácter conceptual, por ejemplo «implantar procedimientos»; cada categoría está definida en el anexo del estándar, la mayoría además con ejemplos, y todo activo identificado puede asignarse al menos a una categoría. Lo decisivo es la herencia: a un activo han de asignársele también todas las categorías superiores, y solo la categoría directa y las superiores en conjunto dan como resultado sus requisitos. Así, un servicio SaaS gestionado como servicio en la nube hereda los requisitos de Externalización, Servicios y Compras – 9 directos más 29, 31 y 39, en total 108. El catálogo de aplicación convierte la asignación, la herencia y la consolidación en requisitos DEBE: la asignación se realiza de forma orientada a la función, es decir, según cómo actúa el activo en el proceso de negocio; los requisitos que inciden varias veces se recogen una sola vez, y los activos difíciles de asignar se analizan en la consideración de riesgo.

Tres tipos de requisitos

El estándar presenta el camino hacia el paquete como una cadena: proceso de negocio con necesidad de protección normal o alta, activos, categorías de objetos objetivo, requisitos, paquete de requisitos – y, con necesidad de protección alta, la consideración de riesgo. Para cada activo se derivan especificaciones organizativas, técnicas, de personal y de infraestructura; los requisitos que se aplican a varios activos de la misma categoría figuran una sola vez en el paquete. En los requisitos sin categoría de objetos objetivo, los textos difieren: el estándar exige incorporarlos obligatoriamente, mientras que el texto de orientación del catálogo prevé para cada requisito una decisión sobre su relevancia y la supresión justificada de los requisitos no relevantes. Recomendación de VamiSec: seguir el estándar, incorporarlos todos y gestionar en la realización como «no aplicable», con una justificación documentada, los requisitos cuyo componente no exista en el dominio de información – así el procedimiento sigue siendo trazable conforme a ambos textos.

Blueprints: previstos, pero aún no publicados

Según el estándar, un blueprint es un catálogo de requisitos predefinido que, a diferencia del catálogo de aplicación, está adaptado a determinados escenarios de aplicación, realiza una preselección y predetermina los parámetros. Los blueprints pueden asignarse a grupos de activos o a activos individuales y combinarse; la selección, incluida su versión, así como la asignación y la adaptación han de documentarse de forma trazable, las brechas han de cerrarse con otros blueprints o requisitos y, ante cambios en el dominio de información o en los blueprints disponibles, ha de revisarse la selección. Para determinadas instituciones puede haber blueprints obligatorios; el estándar no indica cuáles. A fecha de 29/10/2026, ningún artefacto de la biblioteca del estado de la técnica está designado como blueprint. Se han publicado, entre otros, el perfil «Stand der Technik WLAN» (estado de la técnica WLAN), con 48 requisitos seleccionados y tres parámetros fijados, como «WPA3», así como un perfil sobre seguridad de la cadena de suministro con 146 requisitos sin parámetros fijados; el BSI no indica si se consideran blueprints. El BSI ha presentado a un grupo de trabajo de la comunidad un concepto de blueprints como versión alfa para recabar comentarios; no está disponible públicamente.

Requisitos propios y decisiones de diseño

Si un activo no puede representarse suficientemente con los requisitos existentes o si surgen obligaciones derivadas de la gestión del cumplimiento o del análisis de las partes interesadas, el estándar formula como recomendación desarrollar requisitos complementarios; el catálogo de aplicación convierte ambos casos en requisito DEBE. Para los activos sin requisitos adecuados, el texto de orientación prevé documentar los activos afectados, justificar por qué los requisitos de GS++ no son suficientes, formular en su caso nuevos requisitos referidos a los objetivos de protección, incorporarlos de forma fija al paquete y remitirlos al BSI. El estándar no precisa el «formato previsto por GS++» para los requisitos propios; a nuestro juicio, resulta adecuado el esquema de frase con el que están construidos todos los requisitos del catálogo: práctica, en su caso categoría de objetos objetivo, verbo modal, resultado, opcionalmente una especificación del resultado y un verbo de acción, por ejemplo «Información y activos para sistemas de TI DEBERÍA documentar las necesidades de mantenimiento de los componentes del sistema y la infraestructura necesaria para la operación». El catálogo utiliza 27 verbos de acción, los más frecuentes «implantar», «documentar» y «activar», e indica para 961 requisitos un tipo de documentación recomendado.

La institución toma las decisiones de diseño a través de parámetros: elementos variables como «periódicamente», que muestran a auditores e instituciones usuarias los márgenes de maniobra y pueden aprovecharse para la verificación automatizada. Se concretan durante la elaboración del paquete o después; el catálogo de aplicación exige como DEBE asignar valores concretos: según el texto de orientación, por ejemplo «diariamente», «semanalmente» o «mensualmente» en lugar de «periódicamente», o las personas y roles a los que cada práctica técnica y organizativa asigna las tareas en sus «Fundamentos». El catálogo contiene 223 parámetros en 210 requisitos. El perfil del catálogo de aplicación solo fija dos de ellos: el estándar para el SGSI, «BSI Grundschutz++», y el estándar para un SGCN, «BSI-Standard 200-4»; todos los demás valores los determina la institución, salvo que un blueprint los predetermine.

Estado de implementación: tres valores, verificación completa

Para cada requisito del paquete de requisitos debe verificarse por completo el estado de implementación actual. El estándar contempla tres valores: «cumplido», «no cumplido» y «no aplicable». El tercer valor está sujeto a condiciones: un requisito puede considerarse «no aplicable» si no puede cumplirse funcionalmente o si el componente subyacente no existe en el dominio de información; la justificación ha de documentarse. La determinación debería seguir un procedimiento estructurado, que puede abarcar desde entrevistas y revisiones documentales hasta verificaciones automatizadas de la configuración y escaneos técnicos; en primer lugar han de verificarse los requisitos con el nivel de seguridad normal-SdT. En el catálogo de aplicación, la verificación del estado es un requisito DEBE, completa y periódica, y la institución fija el intervalo como parámetro. El texto de orientación del catálogo solo contempla «implementado» y «no implementado» y añade una regla que el estándar no menciona: un requisito solo se considera implementado cuando también están implementados todos los requisitos que guardan una relación de dependencia con él.

Plan de implementación: cada medida vinculada a su requisito

Del paquete de requisitos surge un plan de implementación estructurado. Este define medidas concretas para cada requisito y las prioriza; como criterios, el estándar menciona a modo de ejemplo el esfuerzo del requisito subyacente, las sinergias entre medidas, la magnitud de los riesgos, la importancia estratégica y los quick wins de alta eficacia. Por principio, recomienda implementar primero los requisitos de los nodos padre. Para cada requisito debe poder reconocerse de forma inequívoca qué medidas tiene asignadas; si una medida aborda varios requisitos, han de indicarse todas las asignaciones, así como las dependencias. Por cada medida han de registrarse como mínimo el requisito correspondiente, la fecha de implementación o de verificación y la persona que documenta o, en su caso, verifica. Las responsabilidades y los plazos realistas deberían documentarse de forma adecuada, por ejemplo en un sistema de gestión de proyectos o de tickets; el procedimiento lo aprueba la dirección de la institución, ya que es ella quien ha de facilitar los recursos. El avance ha de seguirse de forma continua, y un posible conflicto de intereses entre la implementación y el seguimiento del avance ha de evitarse mediante un reparto adecuado de roles.

Evidencias, verificación automatizada e historial

Las evidencias que se utilizan para la evaluación han de asignarse de forma inequívoca a la medida correspondiente, para que la implementación sea trazable. En las verificaciones automatizadas, la herramienta utilizada, el momento de la verificación y el resultado forman parte de la documentación; si la herramienta genera un informe de verificación, este se asigna a la medida y al requisito. Si cambian la asignación, el estado de implementación o el resultado de la verificación, ha de actualizarse la documentación, y para la trazabilidad el estándar recomienda un historial con, como mínimo, el momento, la persona responsable y la herramienta utilizada. Qué contenidos suele incluir un plan de implementación lo enumera el texto de orientación sobre la aprobación de la planificación de la implementación: desde la descripción del requisito, el objeto objetivo, la unidad responsable, los plazos y las prioridades, pasando por los riesgos con su justificación, los recursos y las dependencias, hasta la fecha de aprobación y la firma del propietario del riesgo. Para resultados de verificación legibles por máquina, la biblioteca del estado de la técnica prevé un Assessment Layer propio; hasta ahora no se ha publicado allí ningún artefacto.

Cuándo es necesaria una consideración de riesgo propia

El catálogo de aplicación se basa en una consideración de riesgo general del BSI que parte de una situación de amenazas típica presupuesta; por ello, las instituciones usuarias no tienen que realizar una consideración de riesgo propia cuando la necesidad de protección es normal. Es necesaria una consideración de riesgo explícita cuando un proceso de negocio tiene una necesidad de protección alta en al menos un objetivo de protección, cuando un activo relevante para el dominio de información no queda suficientemente cubierto por las categorías de objetos objetivo y sus requisitos, o cuando un requisito DEBERÍA aplicable no se cumple en el futuro previsible o de forma definitiva. En el catálogo de aplicación, estos desencadenantes están formulados como requisitos DEBE: una consideración de riesgo específica para procesos de negocio o información con necesidad de protección alta y una consideración de riesgo siempre que la metodología la exija. El texto explicativo correspondiente menciona además la reducción del nivel de seguridad de elevado a normal-SdT, un motivo que el propio estándar no enumera. La institución elige por sí misma el procedimiento de identificación, evaluación y tratamiento, por ejemplo sobre la base de ISO/IEC 27005, ISO 31000 o el estándar BSI 200-3, siempre que se respeten los criterios mínimos para la consideración de riesgo. Estos tienen por objeto, entre otras cosas, hacer que el método sea comparable y verificable en el marco de una certificación.

Roles y aprobaciones: quién autoriza qué

Amenazas elementales: nexo entre la derivación del BSI y el análisis propio

Las 47 amenazas elementales G 0.1 a G 0.47, desde el fuego hasta los efectos secundarios perjudiciales de ataques basados en TI, describen eventos, circunstancias o acciones fundamentales en un nivel abstracto. Son neutrales respecto a productos y tecnologías, compatibles con estándares internacionales, están asignadas a los valores fundamentales de confidencialidad, integridad y disponibilidad y se orientan a peligros realistas; una medida de seguridad ausente o implementada de forma insuficiente no constituye, en principio, una amenaza elemental. En GS++ cumplen dos funciones: son una base a partir de la cual el BSI ha derivado los requisitos del catálogo y sirven a las instituciones usuarias como punto de partida de sus propias consideraciones de riesgo. El vínculo es visible en el catálogo. Los 901 requisitos del Kernel llevan identificadores G0, aparecen las 47 amenazas y los requisitos de las prácticas de metodología no tienen ninguno. En los requisitos DEBERÍA incumplidos de forma permanente deben tenerse en cuenta las amenazas asignadas; concretamente, el análisis de una brecha de este tipo empieza, por tanto, por los identificadores G0 del requisito afectado.

Evaluación del desempeño: obligatoria, pero aún sin especificaciones uniformes

Para verificar la eficacia del SGSI y de sus objetivos es necesaria una evaluación del desempeño. Como en GS++ aún está pendiente el desarrollo de especificaciones uniformes para ello, las instituciones tienen libertad para configurarla; los resultados deberían presentarse a la dirección de la institución de forma trazable. Libre no significa opcional: el catálogo de aplicación exige, como requisitos DEBE, procedimientos y disposiciones para la medición y la evaluación del desempeño del SGSI, la revisión y actualización periódicas del plan de implementación, así como una verificación periódica de si los requisitos siguen vigentes. Según su plan de hitos, el BSI quiere cerrar esta laguna metodológica en 2027: para el 26/02/2027 está previsto que el concepto de medición del rendimiento esté integrado en la metodología y pueda aplicarse, y para el 31/03/2027, que cada requisito de las prácticas de metodología cuente con indicadores de rendimiento.

Auditoría, revisión por la dirección y monitorización

Según el estándar, la auditoría interna sirve al autocontrol: su foco no está en señalar no conformidades, sino potenciales de mejora. En la planificación deben fijarse en primer lugar los objetivos del programa de auditoría; estos deberían tener en cuenta, entre otros aspectos, los requisitos de seguridad de la información, el rendimiento de la detección y de la gestión de incidentes de seguridad, los riesgos identificados, los procesos, el grado de madurez del SGSI y los resultados de auditorías anteriores. Los riesgos del propio programa de auditoría deben determinarse y evaluarse, incluidas las medidas para la confidencialidad en la auditoría. El alcance y la periodicidad deberían orientarse al número de sistemas de información, ubicaciones y personas afectadas, a la complejidad del SGSI y a la importancia de los riesgos; las auditorías pueden realizarse in situ, de forma remota o combinada, y la selección del equipo auditor debería garantizar la objetividad y la imparcialidad. En la revisión por la dirección, la dirección de la institución examina, sobre la base del informe para la dirección, si el SGSI es idóneo, adecuado y eficaz, teniendo en cuenta los resultados de auditoría, la evaluación del desempeño, los incidentes de seguridad, el estado del tratamiento de riesgos, los cambios en la institución o en la situación de amenazas y el estado de decisiones anteriores. Para la monitorización deben estar establecidos tres procedimientos, a los que se suma la validación periódica de los requisitos:

• Detección de incidentes de seguridad con identificación y notificación tempranas, desde procesos manuales hasta sistemas de detección automatizados, según el tamaño y la complejidad de la institución.
• Gestión de vulnerabilidades: identificarlas, evaluarlas, tratarlas y hacer su seguimiento de forma sistemática, con retroalimentación a la consideración de riesgo.
• Registro de las amenazas emergentes y respuesta a ellas, también con retroalimentación a la consideración de riesgo.
• Validación de los requisitos ante cambios en el dominio de información, en la biblioteca del estado de la técnica, en los blueprints utilizados o en la metodología GS++, coordinada con las unidades organizativas competentes y, en su caso, con adaptación del paquete de requisitos.

Mejora: del hallazgo al plan de corrección y mejora

Si los requisitos no se cumplen en la medida prevista, existe una desviación. Las no conformidades se registran de forma sistemática y se analizan sus causas, no solo las inmediatas, sino también las subyacentes. Ello incluye estimar cuán probable sería que se repitieran y qué consecuencias tendría, examinar casos similares en otros ámbitos y plantearse si existe una debilidad sistémica del SGSI. Los potenciales de mejora se derivan, entre otras fuentes, de la situación de amenazas, la efectividad del plan de implementación, los resultados de auditoría, los incidentes de seguridad y las propuestas del personal; deberían evaluarse según la reducción del riesgo, los recursos necesarios, la importancia estratégica, las sinergias y la sostenibilidad. Las propuestas de corrección y mejora deben integrarse en un plan de corrección y mejora que se prioriza según los recursos, los quick wins y el mayor potencial de mejora y se incorpora al plan de implementación. A continuación, la evaluación comprueba mediante criterios medibles, pruebas o auditorías si las medidas surten efecto. Las vulnerabilidades detectadas y los cambios en la situación de amenazas desencadenan un nuevo ciclo de consideración de riesgo, y se cierra el círculo con el plan de implementación de la realización.

Verbos modales, niveles de seguridad y vinculación a objetos objetivo

Niveles de esfuerzo: qué trabajo prevé el BSI

Qué ha cambiado desde abril de 2026

Los cambios afectan sobre todo a las prácticas de metodología: en ellas se han suprimido o fusionado subgrupos, diez de los doce requisitos suprimidos proceden de la metodología y cinco requisitos de metodología se elevaron de DEBERÍA a DEBE. En total, once requisitos cambiaron de verbo modal; además de esos cinco, cuatro subieron de PUEDE a DEBERÍA, uno bajó de DEBERÍA a PUEDE y otro de DEBE a DEBERÍA. Los requisitos añadidos pertenecen mayoritariamente a la práctica Derechos de acceso. Para el día a día, más importante que cualquier cifra aislada es la conclusión de fondo: los ID dependen de la posición y pueden cambiar entre versiones del catálogo; lo estable es el UUID. Una mera comparación de los ID arrojaría bastantes más requisitos nuevos y suprimidos de los que realmente hay. Por ello, quien base el estado de implementación, las correspondencias o las declaraciones de aplicabilidad en los ID de los requisitos debería contrastar cada nueva versión del catálogo a través de los UUID; a nuestro juicio, se trata de una función básica de toda herramienta de GS++. Otras cifras clave de un vistazo:

• Prácticas más amplias: KONF con 157, BES con 109, BER con 92, SENS con 87, DET con 82 y GEB con 75 requisitos; las seis prácticas de metodología suman en conjunto 99 requisitos, de ellos 80 DEBE y 19 DEBERÍA.
• Tipos de documentación más frecuentes: historial de configuración con 183, concepto de operación de TI con 116, criterios de adquisición con 70, concepto de detección con 61, instrucción de trabajo y plan de formación con 60 menciones cada uno.
• La etiqueta de parámetro más frecuente es «periódicamente», con 68 apariciones; el perfil del catálogo de aplicación solo fija dos de los 223 parámetros y todos los demás los concreta la institución.
• Amenazas elementales más frecuentes: G 0.18 con 385, G 0.23 con 142, G 0.30 con 130, G 0.36 con 110, G 0.19 con 98 y G 0.39 con 95 asignaciones.
• La herencia a lo largo de las categorías de objetos objetivo hace crecer el volumen por activo: a un activo de la categoría «Servicios en la nube» se le asignan directamente 9 requisitos; con las categorías superiores «Externalización», «Servicios» y «Compras», son 108.
• Plantilla de frase: 27 verbos de acción distintos; los más frecuentes son «establecer», con 137 requisitos, «documentar», con 100, y «activar», con 78.

La biblioteca del estado de la técnica

Según el BSI, la biblioteca del estado de la técnica es la plataforma técnica en la que se ponen a disposición de forma centralizada todos los requisitos y medidas; sustituye al Compendio IT-Grundschutz, y el catálogo de aplicación Grundschutz++ forma parte de ella. De acuerdo con el BSI, el repositorio BSI-Bund/Stand-der-Technik-Bibliothek es público desde el 29/09/2025 y está sujeto a la licencia CC BY-SA 4.0. Desde el cambio a una estructura de capas el 27/07/2026, el BSI publica las actualizaciones como «rolling publication» automatizada a intervalos variables; hasta la fecha de cierre de redacción, el 29/10/2026, la última fue el 23/10/2026. Como formato se utiliza OSCAL, la Open Security Controls Assessment Language del NIST estadounidense; el BSI justifica la elección argumentando que así no tiene que desarrollar una solución nacional propia y aumenta la compatibilidad con los estándares de seguridad internacionales. Formalmente, la página del BSI «Stand der Technik» (estado de la técnica) sigue describiendo la biblioteca como en fase piloto.

Qué contiene cada requisito

• ID y UUID: según el manual del BSI para autores de la biblioteca del estado de la técnica, el ID depende de la posición y puede cambiar en caso de reestructuraciones, mientras que el UUID permanece vinculado al significado del requisito. Entre abril y octubre de 2026, 157 requisitos recibieron un nuevo ID.
• Plantilla de frase compuesta por práctica, en su caso categoría de objetos objetivo, verbo modal, resultado y verbo de acción. Según el mismo manual para autores, las prescripciones deben formularse de modo que un tercero independiente pueda verificar con un sí o un no si se cumplen.
• Metadatos: nivel de seguridad, nivel de esfuerzo y, cuando se han asignado, categorías de objetos objetivo, tipo de documentación y palabras clave; los requisitos del Kernel, además, con valores de relevancia de 0 a 2 para confidencialidad, integridad, disponibilidad y autenticidad, así como con los identificadores G0 de las amenazas elementales.
• Parámetros como texto por completar para decisiones de diseño, por ejemplo «periódicamente». Los perfiles pueden fijar valores o acotarlos; el perfil del catálogo de aplicación solo fija dos, entre ellos «BSI Grundschutz++» como estándar para el SGSI.
• Vínculos con requisitos relacionados y con requisitos previos, así como textos explicativos que aclaran un requisito y ofrecen ejemplos de implementación.

Mappings: puentes hacia ISO/IEC 27001 y el Compendio IT-Grundschutz

Para la lectura, el README del repositorio del BSI recomienda el Stand-der-Technik-Viewer (visor del estado de la técnica), una aplicación de navegador de la organización comunitaria bsi-community. Muestra en el lado del cliente catálogos, definiciones de componentes y mappings, filtra por atributos como nivel de seguridad, esfuerzo, categoría de objetos objetivo, verbo modal o amenaza y, al seleccionar una categoría de objetos objetivo, añade automáticamente las categorías superiores. Según indica el BSI, numerosos fabricantes de herramientas de IT-Grundschutz trabajan en la integración de los datos OSCAL. Los límites deberían estar claros: según el BSI, los catálogos OSCAL no automatizan ninguna implementación ni sustituyen la verificación técnica in situ, la Assessment Layer sigue vacía y hasta ahora no se ha publicado ningún artefacto denominado blueprint (Blaupause). Los perfiles de seguridad de la cadena de suministro, con 146 requisitos, y de WLAN, con 48, son selecciones del Kernel; el BSI no los denomina blueprints.

Certificación del sistema: qué está establecido y qué sigue abierto

Está establecido lo siguiente: a partir del 01/01/2027 podrán presentarse solicitudes de certificación ISO 27001 sobre la base de GS++. En su comunicado sobre la publicación del estándar, el BSI describe un SGSI implementado conforme a Grundschutz++ como certificable a partir de 2027 y compatible con la ISO/IEC 27001. Sigue abierto el procedimiento de verificación: no se ha publicado ningún esquema de auditoría para GS++. Según el programa del BSI para la it-sa, para el 28/10/2026 estaba anunciada una ponencia del organismo de certificación del BSI con el título «Ausblick auf die Zertifizierung nach Grundschutz++» (Perspectivas de la certificación conforme a Grundschutz++), que debía presentar las consideraciones actuales sobre el esquema de auditoría, incluidos los retos relativos a los objetos y los criterios de verificación. La documentación vigente para la certificación ISO 27001 sobre la base de IT-Grundschutz, es decir, la base de verificación 4.8, el esquema de certificación 2.2 y el esquema de auditoría 2.5 del 01/02/2026, se refiere a la ISO/IEC 27001:2022, al estándar BSI 200-2 y al Compendio IT-Grundschutz edición 2023. El propio estándar contiene indicios sobre cómo se auditará en el futuro: si se acumulan incumplimientos permanentes de requisitos DEBERÍA, podría constatarse una desviación significativa en el marco de una certificación, y los criterios mínimos tienen por objeto que el método de riesgos sea comparable y verificable, entre otros fines, para una certificación.

Formación y certificación de personas: GS++-Praktiker, consultor GS++, jefe de equipo auditor GS++

El BSI también reorganiza la cualificación de personas. Para el 30/11/2026 está previsto que se publiquen conceptos de formación para la capacitación como GS++-Praktiker y como consultor GS++. A partir del 01/01/2027 podrán presentarse solicitudes de certificación como consultor GS++ y como jefe de equipo auditor GS++; en el primer trimestre de 2027 comienza, para consultores IT-Grundschutz y jefes de equipo auditor ya certificados, una formación continua específica para la certificación como consultor GS++ o como jefe de equipo auditor GS++, respectivamente. El plan de hitos no indica contenidos, alcance ni requisitos de acceso. Desde nuestro punto de vista, de ello se deriva una regla de verificación sencilla para licitaciones y ofertas: antes del 01/01/2027 nadie puede estar certificado como consultor GS++ o jefe de equipo auditor GS++; las cualificaciones del BSI existentes se refieren al IT-Grundschutz.

Quién debe tener en cuenta qué

A fecha de 29/10/2026. El BSI actualiza de forma continua el plan de hitos; lo determinante son las bases de certificación publicadas en cada momento. VamiSec no es un organismo de certificación, y la certificación de personas GS++ no comienza hasta 2027.

Ruta A: desde el IT-Grundschutz

Ruta B: desde la ISO/IEC 27001

Plan de arranque de 90 días

1. 1
   Días 1–15 · BSI 300-1 cap. 2.3 y 2.10 · GC.1.2, GC.6.1, GC.8.1Aclarar el mandato, el ámbito de aplicación y el objetivo

   La dirección de la institución confirma el proyecto, fija el ámbito de aplicación, aprueba los recursos y decide si en 2027 se aspira a una certificación ISO 27001 sobre la base de GS++. Se designa un equipo central formado por el ISB, los responsables de procesos y TI.

2. 2
   Días 16–30 · cap. 2.5 y 2.6 · GC.7.1.1, GC.7.1.2Procesos de negocio y necesidad de protección

   Documentar los procesos de negocio del ámbito de aplicación y, donde no exista un mapa de procesos, utilizar el análisis simplificado de procesos de negocio del anexo 2. Seleccionar el proceso más importante de la categoría de necesidad de protección más alta y hacer que la dirección apruebe la necesidad de protección normal o alta por objetivo de protección.

3. 3
   Días 31–50 · cap. 3 · STM.2.1.2 a STM.2.1.5, STM.5.1Activos, categorías de objetos objetivo y paquete de requisitos

   Según el texto explicativo del catálogo, para la primera iteración bastan los activos del proceso de negocio más importante. Asignar los activos a las categorías de objetos objetivo junto con sus categorías de nivel superior, incorporar los requisitos de metodología y los requisitos sin categoría de objetos objetivo, eliminar duplicados y fijar los valores de los parámetros.

4. 4
   Días 51–70 · cap. 4.1 · UMS.1.1Levantar el estado de implementación

   Empezar por los requisitos normal-SdT y documentar para cada requisito «cumplido», «no cumplido» o «no aplicable» con su justificación. Los resultados existentes del IT-Grundschutz-Check o de la declaración de aplicabilidad sirven como valor de partida, no como resultado.

5. 5
   Días 71–85 · cap. 2.11 y 4.2 · anexo 3Establecer la consideración de riesgo

   Hacer que la dirección de la institución autorice el apetito de riesgo, los criterios de aceptación del riesgo, el procedimiento y los roles; iniciar consideraciones de riesgo para procesos con necesidad de protección alta, activos no suficientemente cubiertos y requisitos DEBERÍA incumplidos de forma permanente.

6. 6
   Días 86–90 · cap. 4.3 a 4.5 y 5.3 · UMS.2.1, RISK.1.10, PERF.4.1Plan de implementación y primer informe para la dirección

   Priorizar las medidas, primero los nodos padre, fijar responsables y plazos, hacer que los propietarios del riesgo autoricen la planificación de la implementación y presentar a la dirección, en el informe para la dirección, el estado de situación, los riesgos residuales y el siguiente proceso de negocio.

Puntos abiertos: lo que el BSI aún tiene pendiente