Cómo elegir el mejor software GRC
Derya AltinayCEO
17 Min. de lectura
El software GRC debe escalar su metodología, conectar cada conclusión con la evidencia y mantener a las personas responsables en control. Estas siete preguntas separan un sistema operativo GRC real de otra lista de verificación, repositorio de documentos o asistente de IA genérico.
Se acerca una auditoría, pero la información necesaria para prepararse está dispersa por toda la organización.
El registro de control se mantiene en una hoja de cálculo. Las políticas residen en SharePoint. La evidencia se almacena en carpetas. Las tareas de corrección se rastrean en Jira. Las decisiones de riesgo están enterradas en notas de reuniones. El razonamiento detrás de la última evaluación existe principalmente en la cabeza del consultor o del responsable de cumplimiento.
Los equipos suelen recurrir a uno de tres enfoques. Reconstruyen el paquete de auditoría del año pasado, introducen otra lista de verificación rígida o utilizan una herramienta de inteligencia artificial de uso general para generar documentación pulida a partir de un contexto incompleto.
Los tres pueden generar resultados. Ninguno crea necesariamente un sistema de cumplimiento confiable.
Los proveedores de GRC suelen describir su software como una ubicación central para controles, riesgos, políticas, pruebas y tareas. La centralización es útil, pero el almacenamiento por sí solo soluciona sólo una parte del problema. El trabajo de gobernanza, riesgo y cumplimiento requiere que los equipos interpreten los requisitos, definan el alcance, implementen controles, recopilen evidencia, evalúen la efectividad, documenten decisiones y repitan ese proceso a medida que cambian los sistemas y las obligaciones.
Cuando esas relaciones faltan, las evaluaciones pueden convertirse en ejercicios de reconstrucción.
Por lo tanto, la elección del software es importante más allá de la próxima auditoría. Un sistema débil combina controles duplicados, evidencia obsoleta, mapeos opacos y declaraciones generadas por IA no verificables. Un sistema sólido convierte el trabajo completado en conocimiento organizacional estructurado que puede revisarse, reutilizarse y actualizarse.
Los compradores deben evaluar el software GRC mediante siete preguntas:
- ¿Se ajusta a la forma en que realmente se realiza el trabajo de GRC?
- ¿Refleja su alcance y metodología?
- ¿Conecta los controles con la implementación y la evidencia?
- ¿Se pueden verificar todas las evaluaciones y conclusiones generadas por la IA?
- ¿Se puede reutilizar el trabajo de forma segura en todos los marcos?
- ¿Puede ejecutar flujos de trabajo repetibles sin eliminar la responsabilidad humana?
- ¿Es lo suficientemente seguro y portátil para datos confidenciales de cumplimiento?
Una base útil para el software GRC moderno
El software GRC respalda la gestión de obligaciones de gobernanza, riesgos, controles, evidencia, evaluaciones, hallazgos, remediación e informes.
Las plataformas más potentes no las tratan como tablas o carpetas no relacionadas. Conservan las conexiones entre ellos:
Requisito → control → implementación → evidencia → evaluación → hallazgo → remediación → decisión
Esa cadena es una base útil para evaluar el software GRC moderno.
Un requisito debe mostrar qué controles lo abordan. Un control debe mostrar cómo se implementa, quién es su propietario, a qué activos o procesos se refiere y qué evidencia lo respalda. Una evaluación debe registrar lo que se examinó, lo que se concluyó, lo que sigue siendo incierto y los riesgos o acciones correctivas resultantes.
ISO/IEC 27001 promueve un enfoque holístico de la seguridad de la información y permite a las organizaciones establecer un SGSI con un proceso de gestión de riesgos adaptado a su tamaño y necesidades. Por lo tanto, seleccionar software no se trata simplemente de encontrar la plataforma con la lista de marcos más larga. Se trata de encontrar un sistema capaz de representar el SGSI actual de la organización.
Los estándares abiertos también están cambiando lo que los compradores pueden esperar. NIST Lenguaje de evaluación de controles de seguridad abiertos, u OSCAL, proporciona modelos legibles por máquina para catálogos de control, implementaciones, evaluaciones, resultados e información de remediación. En lugar de reconstruir repetidamente los documentos de cumplimiento, los modelos estructurados hacen que la información subyacente sea portátil y procesable.
Una distinción es importante. Este artículo se centra principalmente en el trabajo de GRC e ISMS en ciberseguridad. Una plataforma GRC debe conectarse con la gestión de documentos, emisión de tickets, inventarios de activos, sistemas en la nube, proveedores de identidad y herramientas de seguridad. No es necesario reemplazar todos los sistemas fuente operativos. Necesita preservar el contexto que conecta esos sistemas con las decisiones de cumplimiento.
¿Se ajusta a la forma en que realmente se realiza el trabajo de GRC?
Comience con el ambiente de trabajo.
El trabajo de GRC no ocurre exclusivamente dentro de una aplicación de GRC. Ocurre durante entrevistas, talleres, discusiones sobre riesgos, revisiones de políticas, implementación técnica, resolución de tickets, recopilación de evidencia, llamadas de auditoría y revisiones de gestión.
El software gana su lugar cuando puede integrar esas actividades en un flujo de trabajo coherente sin obligar al equipo a recrear manualmente todo dentro de una base de datos separada.
Contar las integraciones no es suficiente. Los compradores deberían preguntar qué sucede después de que la información ingresa a la plataforma:
- ¿Las pruebas importadas conservan su fuente y marca de tiempo originales?
- ¿Pueden los documentos permanecer vinculados a su sistema fuente?
- ¿Pueden las notas de la entrevista convertirse en declaraciones revisables en lugar de texto separado?
- ¿Pueden las tareas permanecer conectadas con el control, el riesgo o el hallazgo que las creó?
- ¿Pueden los agentes autorizados trabajar con el mismo contexto gobernado que los usuarios humanos?
Una plataforma que importa una captura de pantalla pero pierde su origen simplemente ha movido el archivo. Una plataforma que conecta la captura de pantalla con un sistema, control, período de revisión, propietario y evaluación ha creado un contexto de cumplimiento utilizable.
Una prueba de demostración útil
Lleve un control representativo a la demostración del producto, utilizando únicamente información desinfectada o aprobada adecuadamente.
Solicite al proveedor que conecte el requisito, la descripción de la implementación, el propietario responsable, el activo relevante, la evidencia de dos fuentes diferentes y una tarea de remediación abierta. Luego solicite al sistema que prepare una evaluación de ese control.
Esto revela más de lo que jamás revelará un tablero pulido.
¿Refleja su alcance y metodología?
GRC no es una lista de verificación universal.
Dos organizaciones que persiguen el mismo estándar pueden tener diferentes alcances, sistemas, riesgos, responsabilidades, implementaciones de control y expectativas de evidencia. Dos empresas consultoras también pueden seguir diferentes metodologías de implementación y evaluación.
Por lo tanto, el software debe representar la forma en que trabaja la organización en lugar de obligar a cada cliente a seguir un proceso predefinido idéntico.
Los compradores deben examinar si la plataforma puede modelar:
- Múltiples organizaciones, espacios de trabajo, clientes o ámbitos de gobernanza
- Procesos de negocio, aplicaciones, infraestructura, información, servicios y ubicaciones.
- Bibliotecas de control personalizadas y métodos de implementación.
- Decisiones de aplicabilidad y sus fundamentos.
- Controlar la propiedad y las responsabilidades compartidas
- Controles heredados, comunes y específicos del sistema.
- Diferentes metodologías de evaluación y riesgo
- Plantillas reutilizables sin mezclar información específica del cliente
Esto es especialmente importante para las consultorías. Un consultor debe poder reutilizar una metodología probada entre clientes y al mismo tiempo mantener estrictamente aisladas las pruebas, los riesgos, las decisiones y la información confidencial de cada cliente.
La pregunta relevante no es simplemente: "¿La plataforma es compatible con ISO?"/IEC 27001?”
Es: “¿Puede la plataforma representar cómo implementamos y evaluamos las normas ISO?/IEC 27001 en esta organización en particular?
¿Conecta los controles con la implementación y la evidencia?
Un control marcado como completo no es prueba de que el control esté implementado o sea efectivo.
Por lo tanto, una plataforma GRC seria necesita una capa de evidencia. Esto a veces se describe como un depósito de evidencia o una bóveda de evidencia, pero debe hacer más que almacenar archivos.
Una bóveda de pruebas útil debería poder:
- Almacene o haga referencia a documentos, capturas de pantalla, exportaciones, registros y resultados de API
- Conservar fuente, propietario, fecha de recolección, fecha de revisión y período de validez
- Vincular evidencia a controles, activos, procesos, riesgos y actividades de evaluación.
- Identificar evidencia obsoleta, reemplazada, contradictoria o incompleta
- Reutilizar evidencia cuando sea apropiado sin crear copias no controladas
- Mantenga los pasajes extraídos conectados al archivo original
- Distinguir la evidencia presentada de la evidencia revisada y aceptada.
Esta distinción se vuelve aún más importante cuando se trata de IA.
Un sistema de IA genérico puede redactar una descripción de control convincente a partir de un breve mensaje. Pero una descripción fluida puede exagerar lo que realmente se implementa. El software GRC debe generar a partir de la evidencia disponible y mostrar claramente dónde está incompleto el registro.
Secani se basa en este modelo conectado: Los requisitos, controles, evidencia, riesgos, obligaciones, evaluaciones y decisiones permanecen relacionados para que los equipos y los agentes autorizados puedan comprender qué respalda cada conclusión.
Una prueba de demostración útil
Proporcione al sistema tres pruebas:
- Un documento actual y relevante.
- Un documento obsoleto
- Un documento que contradice parcialmente la descripción del control.
Solicite a la plataforma que evalúe el control.
Un sistema confiable no debería combinar todo silenciosamente en una respuesta segura. Debe distinguir las fuentes, identificar la incertidumbre y mostrar dónde se requiere una revisión profesional.
¿Se pueden verificar todas las evaluaciones y resultados de la IA?
La conexión a tierra y la verificación están relacionadas, pero no son lo mismo.
La conexión a tierra determina qué documentos, registros, estándares y datos informaron una salida.
La verificación determina si un usuario puede inspeccionar las fuentes y decisiones específicas detrás de ese resultado.
Una plataforma puede afirmar que su IA funciona a partir de datos de la empresa y al mismo tiempo devolver una respuesta que no se puede verificar. En GRC esto no es suficiente. Los profesionales de cumplimiento, los propietarios de los controles, los auditores y la gerencia deben comprender por qué se llegó a una conclusión.
Un registro GRC verificable debe mostrar:
- El requisito que se evalúa.
- La evidencia y extractos de fuentes utilizados.
- La implementación del control relevante.
- Información contradictoria o faltante
- El estado de la evidencia subyacente.
- La persona o flujo de trabajo que revisó el resultado.
- La diferencia entre una propuesta de IA y un registro aprobado
- Cuándo se realizó la evaluación y qué ha cambiado desde entonces
Sin esta información, la IA puede ahorrar tiempo durante la redacción pero devolver toda la carga de verificación al revisor.
Para GRC, la fluidez no es suficiente. El resultado debe ser defendible.
La dirección de productos de Secani sigue un principio simple: los agentes pueden recopilar contexto, preparar propuestas y realizar trabajos explícitamente autorizados, mientras que las aprobaciones y decisiones administrativas de alto impacto quedan en manos de las personas responsables. El acceso se evalúa en los límites de la organización, el espacio de trabajo y el alcance de la gobernanza y según la capacidad específica de la tarea., en lugar de otorgarle a un agente acceso general al entorno de cumplimiento.
Una prueba de demostración útil
Pídale a la IA del proveedor que explique por qué se calificó que un control se implementó parcialmente.
Entonces pregunta:
- ¿Qué evidencia apoya la conclusión?
- ¿Qué evidencia lo debilita?
- ¿Qué requisito o criterio de evaluación se aplicó?
- ¿Quién aprobó el estatus final?
- ¿Qué haría que la conclusión cambiara?
La calidad de esas respuestas es más importante que la rapidez con la que se generó el párrafo inicial.
¿Se puede reutilizar el trabajo de forma segura en todos los marcos?
La compatibilidad con múltiples marcos debería significar más que mostrar una gran colección de logotipos de marcos.
Muchas organizaciones buscan reutilizar el trabajo de seguridad en todas las regulaciones y estándares. El mismo proceso de respuesta a incidentes, sistema de control de acceso, revisión de proveedores o procedimiento de gestión de riesgos puede respaldar varias obligaciones.
La oportunidad es implementar y evidenciar un control una vez y luego determinar dónde se puede reutilizar ese trabajo.
El peligro es tratar diferentes requisitos como automáticamente equivalentes.
Un control de gestión de incidentes puede soportar ISO/IEC 27001, NIS2, un requisito del cliente y un marco específico de la industria. Eso no significa que cada fuente espere la misma gobernanza, plazos de presentación de informes, evidencia, alcance o nivel de seguridad.
Por lo tanto, una cartografía fiable debería preservar:
- El marco y la versión en cada lado.
- El tipo y dirección de la relación.
- La fuente o autor del mapeo.
- El grado de cobertura
- Lagunas conocidas y requisitos adicionales
- Estado de confianza y revisión
- Si el mapeo fue manual, automatizado o híbrido
NIST Modelo de mapeo de control OSCAL Representa relaciones entre controles y elementos de control de diferentes fuentes documentales en un formato estructurado y legible por máquina. Puede describir estas asignaciones sin duplicar el contenido del control original.
El resultado importante no es sólo la superposición. También es el delta restante.
Un sistema GRC útil debería poder decirle al equipo:
¿Qué podemos reutilizar y qué debemos hacer aún?
Secani está diseñado para programas basados en estándares como ISO/IEC 27001, NIS2, BSI IT-Grundschutz, publicaciones NIST y CMMC. La plataforma permite a los equipos mapear un mismo conjunto de trabajo entre varios estándares y marcos, y utiliza formatos abiertos como OSCAL para crear artefactos portátiles y tipados.
Una prueba de demostración útil
Seleccione un proceso implementado, como respuesta a incidentes.
Pídale al proveedor que lo compare con dos estándares y una obligación regulatoria. La plataforma debe mostrar la implementación y la evidencia reutilizables, pero también resaltar los requisitos que aún no se han satisfecho.
Una pantalla llena de mapas verdes sin espacios visibles debería generar más preocupación, no menos.
¿Puede ejecutar trabajos GRC repetibles?
Los flujos de trabajo repetibles son donde el software GRC se convierte en una infraestructura operativa en lugar de una herramienta de generación de informes ocasional.
Muchas actividades de GRC siguen patrones recurrentes:
- Definir o cambiar un alcance
- Realizar una evaluación de brechas
- Recopilación y revisión de pruebas.
- Probando un control
- Aceptar o tratar un riesgo
- Realizar una evaluación de proveedores
- Preparar una revisión de la gestión
- Grabar un hallazgo
- Seguimiento de la corrección
- Generar un informe de evaluación
Una plataforma sólida debería permitir a la organización codificar esos métodos como flujos de trabajo reutilizables.
El flujo de trabajo debe definir las entradas, los pasos, las responsabilidades, los puntos de revisión, los resultados y los límites de aprobación requeridos. También debe preservar el registro de cada ejecución.
Los agentes de IA pueden agregar una influencia sustancial aquí. Un agente puede recopilar contexto relevante, comparar registros, identificar información faltante, redactar una declaración de implementación o preparar un informe. Pero no debería convertir silenciosamente una sugerencia en una decisión de cumplimiento aprobada.
Una conversación única con el chatbot puede dejar el proceso dentro del historial de mensajes.
Una plataforma GRC convierte el proceso en una capacidad organizacional controlada y repetible.
Una prueba de demostración útil
Pídale al proveedor que demuestre una revisión de control de un extremo a otro en lugar de un mensaje de IA aislado.
El flujo de trabajo debe comenzar con el requisito y la implementación actual, recopilar evidencia, identificar brechas, preparar una propuesta, enviarla para su revisión, registrar la decisión y actualizar cualquier evaluación afectada o elemento de remediación.
El equipo debería poder ver qué hizo el agente, qué cambió el humano y qué pasó a formar parte del registro aprobado.
¿Es lo suficientemente seguro y portátil para datos confidenciales de cumplimiento?
Los sistemas GRC contienen parte de la información más confidencial de la organización.
Pueden revelar arquitectura interna, controles de seguridad, debilidades conocidas, riesgos abiertos, dependencias de proveedores, procedimientos de incidentes, hallazgos de auditorías, decisiones ejecutivas y planes de remediación.
Por lo tanto, la seguridad debe evaluarse antes de cargar evidencia real, no después de que la plataforma ya se haya convertido en el sistema de registro de cumplimiento.
Los compradores deben verificar:
- Aislamiento de inquilinos y clientes
- Cifrado en tránsito y en reposo
- Permisos basados en roles y a nivel de recursos
- Separación entre lectura, lectura sensible, escritura, aprobación y administración.
- Ubicaciones de alojamiento y residencia de datos
- Procesos de retención y eliminación
- Si los datos del cliente se utilizan para el entrenamiento de modelos
- Qué proveedores de modelos y subprocesadores reciben datos
- Registros de auditoría de actividad humana y de agentes
- Opciones de exportación y migración
- El alcance real de cualquier certificación de seguridad.
En el caso de las consultorías, el aislamiento del cliente merece especial atención. La metodología reutilizable nunca debe convertirse en una reutilización accidental de la evidencia de un cliente o del contexto confidencial en el espacio de trabajo de otro cliente.
La portabilidad también importa. Una empresa no debería descubrir después de varios años que sus controles, mapeos, evaluaciones y decisiones sólo pueden exportarse como hojas de cálculo aplanadas o archivos PDF finales.
OSCAL proporciona representaciones estructuradas XML, JSON y YAML para información de control de seguridad. Los formatos abiertos no eliminan todos los problemas de migración, pero reducen la dependencia de una interpretación propietaria del programa de cumplimiento.
Secani utiliza formatos abiertos como OSCAL para artefactos portátiles y legibles por máquinas y separa la lectura, la lectura sensible, la escritura, la aprobación y la administración en los límites de la organización, el espacio de trabajo y el alcance de la gobernanza.
La pregunta del comprador detrás de cada característica
Los siete criterios se pueden reducir a una sola pregunta:
¿La plataforma preserva la conexión entre obligaciones, implementación, evidencia, riesgo y juicio profesional mientras hace que el trabajo repetido sea más rápido y consistente?
Utilice esa pregunta durante todo el proceso de compra.
No evalúe solo la lista de marcos, el diseño del panel, la cantidad de integraciones o la calidad de una política generada. Esas características pueden ser útiles, pero no prueban que la plataforma pueda operar un programa de cumplimiento real.
La evaluación más confiable es un piloto representativo.
Traiga un alcance representativo, un pequeño conjunto de controles, varias fuentes de evidencia desinfectadas o aprobadas adecuadamente, una brecha no resuelta y dos marcos superpuestos. Solicite al proveedor que complete el flujo de trabajo desde el requisito hasta la conclusión revisada.
Luego cambie una pieza de evidencia importante.
Una plataforma sólida debería mostrar qué controles, evaluaciones, informes, mapeos y decisiones pueden verse afectados. Ésa es la diferencia entre almacenar registros de cumplimiento y comprender el sistema de cumplimiento.
Evalúe Secani en trabajos reales de GRC
Secani está diseñado para trabajos conectados de ciberseguridad y cumplimiento.
Secani reúne trabajo de seguridad, pruebas, decisiones y flujos de trabajo asistidos por IA en un solo producto conectado. Está diseñado para equipos que estructuran un SGSI, mapean los requisitos, recopilan evidencia y coordinan el trabajo de implementación. Las revisiones generadas y las evaluaciones de primer paso actualmente están marcadas como En progreso en la página hoja de ruta pública.
La mejor manera de determinar si Secani se adapta a su equipo es no probarlo con una política genérica. Pruébelo con un alcance representativo, su metodología y evidencia desinfectada o aprobada adecuadamente.
Preguntas frecuentes
¿Qué es el software GRC?
El software GRC ayuda a las organizaciones a gestionar las actividades de gobernanza, riesgo y cumplimiento en un sistema estructurado.
Las plataformas básicas centralizan registros, políticas, controles, riesgos, tareas y evidencias. Plataformas más avanzadas conectan esos objetos para que los equipos puedan comprender qué requisitos se aplican, cómo se implementan, qué evidencia los respalda, qué se ha evaluado y dónde aún es necesario actuar.
¿Cuál es la diferencia entre el software GRC y la automatización del cumplimiento?
La automatización del cumplimiento a menudo se centra en un proceso más limitado, como recopilar evidencia de sistemas en la nube, monitorear configuraciones, completar cuestionarios o prepararse para una auditoría específica.
El software GRC representa el sistema de gobernanza más amplio en torno a ese trabajo. Conecta requisitos, controles, riesgos, responsabilidades, evaluaciones, hallazgos, decisiones, remediación e informes.
Los dos enfoques pueden funcionar juntos. Las herramientas automatizadas pueden recopilar señales y pruebas, mientras que la plataforma GRC mantiene el contexto necesario para interpretarlas y gobernarlas.
¿Puede el software GRC hacer que una organización cumpla con las normas?
Ningún software puede hacer que una organización cumpla por sí solo.
Una plataforma puede estructurar requisitos, identificar brechas, automatizar la recopilación de evidencia, respaldar la implementación y preparar documentación. La organización todavía necesita tomar decisiones, operar controles, gestionar riesgos y proporcionar evidencia confiable.
Cuando se trata de una certificación formal, la decisión de certificación pertenece al organismo de certificación correspondiente, no al proveedor de software.
¿Puede la IA realizar por sí sola una evaluación del cumplimiento?
La IA puede extraer información, comparar evidencia con requisitos, identificar posibles brechas y preparar una propuesta de evaluación.
Una persona calificada debe revisar la evidencia, los supuestos, el alcance, los conflictos y las conclusiones resultantes antes de que la evaluación se convierta en un registro de cumplimiento aprobado.
El valor de la IA no es que elimine el juicio profesional. Proporciona a los profesionales una base más rápida y mejor estructurada para aplicar ese juicio.
¿En qué se diferencia el GRC nativo de IA de un chatbot de uso general?
Una conversación única de chatbot de propósito general puede limitarse a la información proporcionada en esa conversación, a menos que esté conectada a fuentes gobernadas y a un contexto persistente.
Un sistema GRC nativo de IA diseñado específicamente funciona a partir de un modelo de cumplimiento persistente y consciente de los permisos: la organización y el alcance relevantes, los marcos aplicables, la evidencia aprobada, los controles afectados, los permisos de usuarios o agentes y las decisiones que aún requieren revisión humana.
También debe preservar las fuentes, el historial del flujo de trabajo y la distinción entre propuestas generadas y registros aprobados.
¿Cómo deberían los equipos medir el retorno del software GRC?
El ahorro de tiempo es útil, pero no es la única medida.
Los equipos pueden comparar:
- Tiempo necesario para preparar una evaluación o auditoría
- Tiempo dedicado a buscar y validar pruebas.
- Trabajo duplicado entre marcos
- Número de preguntas de seguimiento causadas por la falta de contexto
- Tiempo necesario para incorporar un nuevo marco, alcance o cliente
- Tiempo entre la identificación y la asignación de un hueco
- Porcentaje de evidencia actualizada y revisada
- Retrabajo causado por documentos obsoletos o descripciones de control inconsistentes
- Adopción entre propietarios de controles y revisores
Gran parte del valor proviene de la reutilización que se agrava con el tiempo. Un control, mapeo, elemento de evidencia o flujo de trabajo revisado se convierte en una parte reutilizable del sistema de cumplimiento en lugar de un entregable de auditoría único.
¿El software GRC reemplaza a los profesionales o consultores de cumplimiento?
No.
El software GRC puede reducir el trabajo mecánico, preservar la metodología y hacer que el conocimiento experto sea reutilizable. No puede asumir responsabilidad por las decisiones de alcance, la aceptación de riesgos, la interpretación de requisitos ambiguos o el juicio final de que un control está diseñado apropiadamente y opera de manera efectiva.
La plataforma debería brindar a los profesionales una ventaja y al mismo tiempo mantener visible la responsabilidad.
Crea flujos de cumplimiento auditables
Secani conecta Scopes, evidencias, tareas y agentes de IA en un espacio de trabajo compartido.
Artículos relacionados
Todos los artículosOSCAL
Más allá de los mapeos cruzados en hojas de cálculo
OLIR proporciona contenido cartográfico y gobernanza. OSCAL proporciona la estructura legible por máquina para utilizar esas asignaciones en el análisis de brechas, la reutilización de evidencia y los flujos de trabajo de impacto de cambios.
OSCAL
Contamos todas las restricciones en OSCAL 1.2.2. Los 348 de ellos.
Cada validador de OSCAL pretende validar OSCAL. Enumeramos las 348 apariciones de restricciones en las fuentes del NIST, probamos o excluimos cada una y luego realizamos la comparación con la CLI de Java de verdad.
Protección básica de TI
IT-Grundschutz++ se encuentra con OSCAL
Con Stand-der-Technik-Bibliothek, IT-Grundschutz deja atrás el PDF: IT-Grundschutz++ se envía como un catálogo OSCAL, cambiando la forma en que se organiza el trabajo de ISMS.