Cuando una organización sufre una brecha de seguridad, la pregunta que casi nunca falta en la sala del consejo es «¿quién sabía esto y por qué no se hizo nada?». La respuesta casi siempre revela lo mismo: gobierno, riesgo y cumplimiento funcionando como tres departamentos que no se hablan, con tres inventarios de riesgos distintos, tres calendarios de auditoría y ningún propietario claro de la decisión que finalmente falló. GRC nace precisamente para cerrar esa grieta.
Este módulo es la base conceptual de todo el curso. Antes de entrar en controles técnicos, marcos normativos o auditorías, necesitas un lenguaje común y preciso: qué es gobernar frente a gestionar, quién responde ante quién, y cómo encajan entre sí ISO 27001, NIST CSF, COBIT o el ENS sin que se pisen. Sin esta base, cualquier implementación de seguridad de la información acaba siendo un conjunto de controles sueltos sin trazabilidad hacia el negocio ni hacia la responsabilidad legal de la alta dirección.
Qué aprenderás
- La definición rigurosa de gobierno, riesgo y cumplimiento, y por qué GRC los integra en un solo sistema de gestión.
- La diferencia real —no cosmética— entre gobernar y gestionar, y entre seguridad de la información y ciberseguridad.
- El modelo de las Tres Líneas del IIA (2020) y cómo se distribuye la responsabilidad del riesgo entre 1ª, 2ª y 3ª línea, órgano de gobierno y auditor externo.
- Los roles clave del ecosistema GRC: consejo, CISO, DPO, responsable de cumplimiento, propietario del riesgo, auditoría interna y comité de seguridad.
- Un mapa comparativo de los marcos de referencia más relevantes: ISO/IEC 27001 y 27002, ISO 31000, NIST CSF 2.0, COBIT 2019 y el ENS.
- Por qué GRC es un habilitador de negocio y no un centro de coste, con datos de mercado que lo sustentan.
- A mapear las tres líneas de defensa en una empresa mediana real y a clasificar funciones concretas en su línea correspondiente.
Qué es GRC y por qué surge
GRC son las siglas de Governance, Risk and Compliance (Gobierno, Riesgo y Cumplimiento). No es un producto ni una certificación: es un enfoque integrado de gestión que coordina tres disciplinas que, históricamente, evolucionaron por separado en las organizaciones y que, sin coordinación, generan silos, duplicidad de esfuerzo y —lo más peligroso— puntos ciegos de riesgo que nadie cubre porque cada departamento asume que es responsabilidad del otro.
El término se popularizó a partir de los trabajos de OCEG (Open Compliance and Ethics Group, hoy simplemente «OCEG»), organización sin ánimo de lucro que desde principios de la década de 2000 define GRC como «la capacidad integrada de lograr de forma fiable los objetivos, abordando la incertidumbre y actuando con integridad». Esa definición —fiabilidad en el logro de objetivos, gestión de la incertidumbre e integridad— es la que debes retener frente a definiciones más superficiales que reducen GRC a «un software para gestionar auditorías».
Gobierno (Governance)
El gobierno es el sistema mediante el cual una organización es dirigida y controlada. En el ámbito de la seguridad de la información, gobernar significa que el órgano de administración —consejo de administración, comité de dirección u órgano equivalente— define la dirección estratégica, aprueba el apetito de riesgo, asigna responsabilidades y autoridad, y supervisa que la organización actúa conforme a esa dirección. ISO/IEC 27001:2022, en su cláusula 5 («Liderazgo»), formaliza esto exigiendo en el apartado 5.1 que la alta dirección demuestre liderazgo y compromiso con el sistema de gestión de seguridad de la información (SGSI); en el 5.2, que establezca y comunique una política de seguridad de la información; y en el 5.3, que asigne y comunique dentro de la organización las funciones, responsabilidades y autoridades pertinentes. El gobierno no ejecuta controles técnicos: decide, prioriza recursos y rinde cuentas.
Riesgo (Risk)
La gestión de riesgos es el conjunto de actividades coordinadas para dirigir y controlar una organización con respecto al riesgo, entendido —según ISO 31000:2018, «Gestión del riesgo — Directrices»— como el «efecto de la incertidumbre sobre los objetivos». Es una definición deliberadamente neutra: el riesgo no es solo la posibilidad de un incidente de ciberseguridad, sino cualquier desviación, positiva o negativa, respecto a lo esperado. En la práctica de seguridad de la información trabajamos casi siempre con la cara negativa (amenazas que explotan vulnerabilidades y generan impacto), pero el marco conceptual de ISO 31000 —principios, marco de referencia y proceso— es aplicable a cualquier tipo de riesgo, no solo al tecnológico.
Cumplimiento (Compliance)
El cumplimiento es la capacidad de demostrar que la organización actúa conforme a las leyes, reglamentos, contratos, normas y políticas internas que le son de aplicación. En el contexto español y europeo esto incluye, entre otros: el Reglamento General de Protección de Datos (RGPD, Reglamento UE 2016/679) y la Ley Orgánica 3/2018 de Protección de Datos Personales y garantía de los derechos digitales (LOPDGDD); el Esquema Nacional de Seguridad (ENS, Real Decreto 311/2022, de 3 de mayo, que deroga el RD 3/2010) para el sector público y proveedores que le prestan servicios; la Directiva NIS2 (Directiva UE 2022/2555) y su transposición al ordenamiento español; y, en el sector financiero, el Reglamento DORA (Reglamento UE 2022/2554), aplicable desde el 17 de enero de 2025. El cumplimiento no es «pasar una auditoría»: es un estado sostenido y demostrable, con evidencias, que se degrada en el momento en que dejas de mantenerlo.
Por qué se integran las tres patas
Sin integración, cada disciplina construye su propio inventario: el comité de riesgos mantiene una matriz de riesgos operativos, el departamento legal lleva su propio registro de obligaciones normativas y el equipo de seguridad gestiona un tercer listado de vulnerabilidades técnicas. Cuando llega una auditoría externa o un incidente, nadie tiene la vista de conjunto: se duplica trabajo (tres equipos preguntando lo mismo al mismo propietario de proceso), se generan inconsistencias (un riesgo catalogado como «bajo» en una matriz y como «crítico» en otra) y, sobre todo, se diluye la responsabilidad. GRC integrado significa un único lenguaje de riesgo, una única jerarquía de políticas y un flujo de reporting que llega, sin traducción, hasta el consejo.
Gobernar frente a gestionar
Esta distinción es la más citada en exámenes de certificación (CISM, CISA, ISO 27001 Lead Implementer) y la más ignorada en la práctica diaria de muchas organizaciones. COBIT 2019, el marco de gobierno de TI de ISACA, la formaliza con precisión:
| Dimensión | Gobernar (Governance) | Gestionar (Management) |
|---|---|---|
| Responsable | Órgano de gobierno (consejo, comité de dirección) | Dirección ejecutiva (CEO, CISO, directores de área) |
| Actividad típica | Evaluar, dirigir, supervisar (Evaluate, Direct, Monitor — EDM en COBIT 2019) | Planificar, construir, ejecutar, supervisar operativamente (APO, BAI, DSS, MEA en COBIT 2019) |
| Horizonte temporal | Estratégico, plurianual | Táctico y operativo, anual o inferior |
| Pregunta que responde | ¿Estamos haciendo lo correcto y generando el valor esperado? | ¿Lo estamos haciendo bien y con los recursos adecuados? |
| Ejemplo en seguridad | Aprobar el apetito de riesgo cibernético y la política de seguridad | Implementar el SGSI, gestionar el SOC, aplicar parches |
Gobernar es decidir qué riesgo es aceptable y quién responde si algo falla; gestionar es ejecutar el día a día dentro de esos límites. Un CISO que solo gestiona controles técnicos sin nunca elevar decisiones de apetito de riesgo al consejo no está haciendo gobierno de la seguridad, está haciendo operaciones de seguridad con un título inflado.
Seguridad de la información frente a ciberseguridad
Otra confusión habitual, incluso entre profesionales seniors. La seguridad de la información es la disciplina más amplia: protege la confidencialidad, integridad y disponibilidad de la información en cualquier soporte —digital, papel, verbal— y frente a cualquier tipo de amenaza, incluyendo errores humanos, desastres naturales o fallos de proceso. ISO/IEC 27001 es, formalmente, una norma de seguridad de la información, no solo de ciberseguridad. La ciberseguridad es un subconjunto: se centra específicamente en la protección de sistemas, redes y datos frente a ataques que se producen en o a través del ciberespacio (malware, intrusión, ransomware, phishing, etc.). Todo dato en un servidor comprometido es un problema de ciberseguridad y de seguridad de la información a la vez; un contrato en papel filtrado por un empleado descuidado es un problema de seguridad de la información que no es, en sentido estricto, un incidente de ciberseguridad. En un programa GRC maduro, el alcance del SGSI debe cubrir ambos, y conviene dejarlo explícito en el alcance documentado (cláusula 4.3 de ISO/IEC 27001) para evitar zonas grises de responsabilidad.
El modelo de las Tres Líneas (IIA, 2020)
El Institute of Internal Auditors (IIA) publicó en julio de 2020 The IIA’s Three Lines Model, una actualización que sustituye formalmente al antiguo «Three Lines of Defence» (Tres Líneas de Defensa), vigente desde 2013. El cambio de nombre no es cosmético: el modelo de 2020 elimina deliberadamente la connotación puramente defensiva («defensa» sugiere solo evitar pérdidas) y la sustituye por un enfoque de colaboración, responsabilidad compartida y creación de valor, sin renunciar por ello a la claridad sobre quién responde de qué. El modelo distingue seis elementos: el órgano de gobierno, la dirección (que a su vez despliega la 1ª y 2ª línea), la auditoría interna (3ª línea) y el auditor externo y los reguladores como referencias fuera del modelo pero relevantes para la organización.
| Línea | Quién la compone | Función principal | Ejemplo en ciberseguridad |
|---|---|---|---|
| Órgano de gobierno | Consejo de administración, comité de auditoría | Rendir cuentas ante las partes interesadas por la supervisión organizacional; garantizar estructuras y procesos de gobierno adecuados | Aprobar el apetito de riesgo cibernético y la estrategia de seguridad plurianual |
| 1ª línea | Propietarios de procesos y del riesgo: áreas de negocio, TI, operaciones | Proporcionar productos/servicios a clientes y gestionar el riesgo de forma directa como parte de la responsabilidad de rendición de cuentas ante la dirección | El equipo de desarrollo aplica prácticas de secure coding y corrige vulnerabilidades en su propio código |
| 2ª línea | Funciones de gestión de riesgos, cumplimiento y seguridad (el CISO suele estar aquí) | Asistir a la dirección en el establecimiento y supervisión de prácticas de gestión de riesgos; proveer marcos, herramientas, formación y seguimiento | El CISO define la política de seguridad, gestiona el programa de gestión de vulnerabilidades a nivel corporativo y reporta el estado del riesgo a dirección |
| 3ª línea | Auditoría interna | Proporcionar aseguramiento independiente y objetivo, y asesoramiento, sobre la adecuación y eficacia del gobierno y la gestión de riesgos | Auditoría interna evalúa, con independencia de la 1ª y 2ª línea, si el programa de ciberseguridad cumple la política aprobada y es efectivo |
| Auditor externo / reguladores | Firma de auditoría externa, supervisores sectoriales (Banco de España, AEPD, INCIBE-CERT, etc.) | Aseguramiento adicional o regulación desde fuera de la estructura de la organización | Auditoría de certificación ISO/IEC 27001 por un organismo acreditado; inspección de la AEPD |
Un matiz que suele generar debate en consultoría: dónde se sitúa el CISO. La práctica mayoritaria —y la que recomienda el propio IIA en su guía de aplicación al riesgo cibernético— es situar a la función de seguridad de la información en la 2ª línea, porque su rol es definir el marco, supervisar su cumplimiento y asesorar a la 1ª línea, no ejecutar directamente los controles del día a día (eso corresponde a los equipos de TI y de negocio como propietarios del riesgo). Sin embargo, en organizaciones pequeñas donde el CISO también opera el SOC o aplica parches personalmente, la línea se difumina: en ese caso está actuando simultáneamente como 1ª y 2ª línea, lo cual es aceptable en empresas pequeñas siempre que quede documentado como una limitación de segregación de funciones y se compense con supervisión de auditoría interna o externa reforzada.
Roles clave y su encaje en el modelo GRC
| Rol | Línea / posición | Responsabilidad principal |
|---|---|---|
| Consejo de administración / comité de dirección | Órgano de gobierno | Aprobar el apetito de riesgo, la política de seguridad y el presupuesto; supervisar al CISO y a auditoría interna; rendir cuentas ante accionistas y reguladores |
| CISO (Chief Information Security Officer) | 2ª línea (normalmente) | Diseñar y mantener el SGSI, definir políticas y controles, coordinar respuesta a incidentes, reportar el estado de riesgo cibernético a dirección |
| DPO (Delegado de Protección de Datos) | 2ª línea, función de cumplimiento con independencia reforzada por el RGPD (art. 38.3) | Supervisar el cumplimiento del RGPD y la LOPDGDD, asesorar en evaluaciones de impacto (EIPD), ser punto de contacto con la AEPD |
| Responsable de cumplimiento normativo (Compliance Officer) | 2ª línea | Mantener el mapa de obligaciones legales y contractuales, coordinar auditorías de cumplimiento, gestionar el canal de denuncias (Ley 2/2023) |
| Propietario del riesgo (Risk Owner) | 1ª línea | Responsable último de un riesgo concreto dentro de su área; decide y ejecuta el tratamiento (mitigar, transferir, evitar, aceptar) |
| Auditoría interna | 3ª línea | Aseguramiento independiente sobre la eficacia del gobierno, la gestión de riesgos y los controles; no participa en el diseño de los controles que audita |
| Comité de seguridad de la información | Órgano transversal, normalmente reporta al órgano de gobierno o a la dirección | Foro de coordinación entre negocio, TI, legal y seguridad para decisiones que exceden la autoridad de un único departamento |
Un error de diseño frecuente es que auditoría interna (3ª línea) acabe redactando o aprobando las propias políticas que después audita. Eso rompe la independencia exigida por el modelo del IIA y por la propia norma ISO/IEC 27001, que en la cláusula 9.2 exige que las auditorías internas del SGSI se planifiquen y ejecuten con objetividad e imparcialidad respecto al proceso auditado.
Marcos de referencia: panorama y cuándo usar cada uno
Uno de los mayores focos de confusión —y de pérdida de tiempo en consultoría— es tratar los marcos como si compitieran entre sí. No compiten: cada uno responde a una pregunta distinta y, en un programa GRC maduro, se combinan.
| Marco | Qué es | Pregunta que responde | Alcance típico |
|---|---|---|---|
| ISO/IEC 27001:2022 | Norma certificable de requisitos para un Sistema de Gestión de Seguridad de la Información (SGSI) | ¿Qué debe tener implantado mi organización, de forma auditable y certificable, para gestionar la seguridad de la información? | Sistema de gestión completo: liderazgo, planificación, soporte, operación, evaluación del desempeño, mejora, más 93 controles del Anexo A (alineados con ISO/IEC 27002:2022) |
| ISO/IEC 27002:2022 | Código de buenas prácticas con guía de implementación de los controles | ¿Cómo implemento en detalle cada control de seguridad? | Catálogo de 93 controles organizados en 4 temas: organizativos, de personas, físicos y tecnológicos |
| ISO 31000:2018 | Directrices genéricas de gestión del riesgo (no certificable) | ¿Cómo diseño un proceso de gestión de riesgos coherente para toda la organización, no solo el tecnológico? | Principios, marco de referencia y proceso de gestión de riesgos, aplicable a cualquier tipo de riesgo |
| NIST CSF 2.0 | Marco voluntario de referencia para gestionar el riesgo de ciberseguridad, publicado por el NIST (EE.UU.) en febrero de 2024 | ¿Cómo describo, de forma común y comparable, mi postura de ciberseguridad, desde el gobierno hasta la recuperación? | 6 funciones: Govern, Identify, Protect, Detect, Respond, Recover; con categorías y subcategorías |
| COBIT 2019 | Marco de gobierno y gestión de TI de ISACA | ¿Cómo gobierno y gestiono TI de forma que genere valor y controle el riesgo, en toda la empresa, no solo en seguridad? | 40 objetivos de gobierno y gestión (dominios EDM, APO, BAI, DSS, MEA) |
| ENS (RD 311/2022) | Esquema Nacional de Seguridad, de obligado cumplimiento en el sector público español y proveedores | ¿Qué medidas de seguridad exige la normativa española a las administraciones públicas y a quienes les prestan servicios? | Principios básicos, requisitos mínimos y medidas de seguridad, categorizadas según nivel (básico, medio, alto) |
La novedad de NIST CSF 2.0: la función GOVERN
La versión 1.1 del CSF (2018) tenía cinco funciones: Identify, Protect, Detect, Respond, Recover. El NIST publicó la versión 2.0 el 26 de febrero de 2024 (documento NIST CSWP 29), y el cambio estructural más relevante es la incorporación de una sexta función, Govern, que además pasa a ser transversal a las otras cinco. GOVERN cubre la estrategia de gestión del riesgo de ciberseguridad, la supervisión por parte de la alta dirección, los roles y responsabilidades, la política, y la gestión del riesgo en la cadena de suministro. Es, en esencia, el mismo reconocimiento que ya hacía ISO/IEC 27001 con su cláusula 5: sin gobierno explícito y con supervisión de la alta dirección, ningún programa de ciberseguridad es sostenible en el tiempo. Otra novedad relevante de CSF 2.0 es que amplía su público objetivo más allá de las infraestructuras críticas (alcance original del CSF 1.0 de 2014) para aplicarse a organizaciones de cualquier tamaño y sector.
Cómo se combinan en la práctica
Un patrón habitual en organizaciones españolas medianas-grandes: se certifica el SGSI en ISO/IEC 27001 (porque lo exigen clientes o licitaciones), se usa ISO/IEC 27002 como catálogo detallado para implementar los controles del Anexo A, se apoya el proceso de gestión de riesgos globalmente en ISO 31000 (porque el área de riesgo corporativo ya lo usa para riesgo operacional y financiero, y conviene un único lenguaje de riesgo en toda la empresa), se usa NIST CSF 2.0 como marco de comunicación con el consejo y con terceros (es más legible para no especialistas y permite evaluar madurez por función), y COBIT 2019 se reserva para el gobierno de TI en sentido amplio cuando el alcance excede la seguridad (por ejemplo, gestión de proveedores de TI, gestión de la cartera de proyectos). Si la organización presta servicios al sector público, el ENS se convierte en obligatorio y se solapa de forma importante con los controles de ISO/IEC 27002, lo que permite reutilizar buena parte de la evidencia entre ambos.
Para profundizar en cómo se traduce este marco de gobierno a la práctica de detección y respuesta operativa, este curso conecta directamente con el módulo de DFIR y respuesta a incidentes, donde se aplican las funciones Detect, Respond y Recover del NIST CSF 2.0 sobre casos reales, y con el curso de defensa de Active Directory, que ilustra cómo los controles técnicos de la 1ª línea sostienen los objetivos de riesgo definidos por la 2ª línea y el gobierno.
Por qué GRC importa al negocio
Es habitual que GRC se perciba internamente como un centro de coste burocrático. Esa percepción es un error estratégico y, con frecuencia, una señal de que el programa GRC está mal vendido a dirección, no de que GRC en sí no aporte valor. Tres argumentos, con base concreta:
GRC como habilitador, no como bloqueador
Un programa GRC bien diseñado no dice «no» por defecto: convierte decisiones de riesgo implícitas y no gestionadas en decisiones explícitas y trazables. Permite lanzar un nuevo producto digital, adoptar la nube o firmar con un proveedor crítico con una evaluación de riesgo documentada, en lugar de bloquear la iniciativa o, peor, dejar que avance sin ningún análisis. La velocidad de negocio no se pierde por tener GRC; se pierde cuando GRC no está integrado en el ciclo de decisión y aparece al final, como un veto de última hora.
Requisito de mercado y contractual
Cada vez más licitaciones públicas y contratos B2B en España exigen certificación ISO/IEC 27001, cumplimiento acreditado del ENS, o cuestionarios de seguridad extensos como condición de acceso al contrato. En sectores regulados —banca, seguros, infraestructuras críticas— el Reglamento DORA (aplicable desde enero de 2025) y la Directiva NIS2 convierten la gestión de riesgo de terceros y la notificación de incidentes en obligación legal directa, no en buena práctica opcional. No tener un programa GRC maduro deja fuera a la organización de determinados mercados, directamente.
Reducción de pérdidas
Más allá de la multa regulatoria (el RGPD contempla sanciones de hasta 20 millones de euros o el 4% de la facturación anual global, lo que sea mayor, según el artículo 83), el coste real de un incidente mal gestionado incluye interrupción operativa, coste de recuperación, pérdida de clientes y daño reputacional que se prolonga durante años. Un programa GRC no elimina el riesgo —eso no es su objetivo—, pero reduce la probabilidad de que un riesgo conocido se materialice sin control y acota drásticamente el tiempo de detección y respuesta cuando ocurre, que es la variable que más correlaciona con el coste final de un incidente.
Caso práctico: mapear las tres líneas en una empresa mediana
Tomemos «Textiles Rioja, S.A.», una empresa manufacturera española de 320 empleados, con una planta de producción, un ERP en la nube, una tienda online y datos de clientes y empleados que caen bajo el RGPD. No cotiza en bolsa, no tiene función de auditoría interna a tiempo completo (la subcontrata anualmente) y su comité de dirección se reúne mensualmente.
| Elemento del modelo | Quién lo ocupa en Textiles Rioja | Notas de diseño |
|---|---|---|
| Órgano de gobierno | Comité de dirección (el consejo de administración delega la supervisión operativa de seguridad en este comité, y recibe informe trimestral) | Aprueba anualmente el apetito de riesgo y la política de seguridad propuesta por el CISO |
| 1ª línea | Responsable de producción (riesgo OT/planta), responsable de TI (administración de sistemas), responsable de e-commerce (riesgo de la tienda online), RR.HH. (gestión de accesos de personal) | Cada uno es propietario de los riesgos de su área y ejecuta los controles del día a día |
| 2ª línea | CISO a tiempo parcial (compartido con el rol de responsable de TI corporativo, con las limitaciones de segregación que eso implica) y un DPO externalizado | El CISO define política, coordina el análisis de riesgos anual y reporta al comité de dirección; el DPO supervisa cumplimiento RGPD de forma independiente del área de TI |
| 3ª línea | Firma de auditoría externa contratada una vez al año para revisar el SGSI y el cumplimiento del RGPD | Al no tener auditoría interna propia, la independencia se logra subcontratando la función; el informe se entrega directamente al comité de dirección, no al CISO |
| Auditor externo / regulador | Organismo de certificación acreditado (auditoría de certificación/seguimiento ISO/IEC 27001) y AEPD como autoridad de control | Referencia externa al modelo, pero clave para el aseguramiento final ante clientes y ante la ley |
El punto crítico de diseño en este caso es la limitación de segregación de funciones: el mismo responsable de TI ejerce simultáneamente 1ª línea (operar los sistemas) y 2ª línea (definir la política que rige esos sistemas). Es una situación común en pymes y no es, por sí sola, un incumplimiento, pero debe documentarse explícitamente como riesgo residual aceptado por el comité de dirección, y compensarse reforzando la independencia de la 3ª línea (auditoría externa anual) y, si el presupuesto lo permite, incorporando una revisión de un tercero independiente sobre las decisiones más sensibles del CISO/responsable de TI (por ejemplo, la gestión de accesos privilegiados).
Errores comunes
- Confundir «tener un SGSI certificado» con «tener gobierno de la seguridad»: la certificación acredita que existe un sistema, no que la alta dirección lo dirige activamente ni que el apetito de riesgo esté realmente aprobado y comunicado.
- Situar al CISO en la 1ª línea sin darse cuenta, es decir, dejar que sea juez y parte: diseña el control, lo implementa y luego «audita» su propia implementación sin ninguna revisión independiente.
- Tratar los marcos como alternativas excluyentes («¿hacemos ISO 27001 o NIST CSF?») en lugar de como capas complementarias con propósitos distintos.
- Redactar una política de seguridad aprobada por el consejo que nunca se traduce en procedimientos operativos: gobierno sin gestión efectiva es papel mojado.
- Mantener registros de riesgo distintos y no reconciliados entre el área de riesgo corporativo, cumplimiento normativo y seguridad de la información, lo que genera respuestas contradictorias ante un mismo hallazgo de auditoría.
- Asumir que la Directiva NIS2 o el Reglamento DORA «no van con nosotros» sin haber hecho antes un análisis formal de aplicabilidad, incluyendo la condición de proveedor de una entidad esencial o importante.
- Que auditoría interna participe en el diseño de los controles que más tarde tiene que auditar, rompiendo la objetividad exigida por la cláusula 9.2 de ISO/IEC 27001.
Ejercicio
Clasifica cada una de las siguientes funciones dentro de una organización en 1ª línea, 2ª línea, 3ª línea u órgano de gobierno, según el Three Lines Model del IIA (2020), y justifica brevemente cada respuesta:
- El administrador de sistemas que aplica los parches mensuales a los servidores de producción.
- El CISO que define la política de gestión de vulnerabilidades y reporta trimestralmente el estado de riesgo al comité de dirección.
- El comité de auditoría del consejo de administración que aprueba el plan anual de auditoría interna.
- El equipo de auditoría interna que evalúa, una vez al año, si el proceso de gestión de accesos cumple la política aprobada.
- El responsable de un departamento de negocio que decide aceptar formalmente un riesgo residual identificado en su área.
- La firma externa que certifica el SGSI conforme a ISO/IEC 27001.
- El comité de seguridad de la información que decide, con representantes de TI, legal y negocio, priorizar la migración a MFA en todos los sistemas críticos.
Pista de corrección: las respuestas 1 y 5 corresponden a la 1ª línea (ejecución y propiedad directa del riesgo); la 2 corresponde a la 2ª línea (definición del marco y supervisión); la 3 corresponde al órgano de gobierno; la 4 corresponde a la 3ª línea (aseguramiento independiente); la 6 es un auditor externo, fuera de las tres líneas pero relevante para el aseguramiento global; la 7 es un órgano transversal cuya composición mezcla 1ª y 2ª línea, y cuyas decisiones deben quedar dentro del apetito de riesgo aprobado por el órgano de gobierno.
Preguntas frecuentes
¿Es obligatorio implantar GRC como sistema formal, o es solo una buena práctica?
No existe una ley española o europea que exija literalmente «implantar GRC» como tal. Lo que sí es obligatorio, dependiendo del sector y tamaño de la organización, es cumplir normativas concretas que en la práctica requieren una estructura de gobierno, riesgo y cumplimiento: el RGPD exige responsabilidad proactiva (accountability, artículo 5.2) y, en determinados casos, un DPO (artículo 37); el ENS es obligatorio para el sector público y sus proveedores; DORA lo es para entidades financieras y sus proveedores TIC críticos desde enero de 2025; NIS2 lo será, tras su transposición, para entidades esenciales e importantes en sectores críticos. GRC como enfoque integrado no es un mandato legal en sí mismo, pero es la forma más eficiente de cumplir simultáneamente todas esas obligaciones sin triplicar el trabajo.
¿Puede una pyme prescindir de la 3ª línea (auditoría interna) por falta de recursos?
Puede prescindir de tener una función de auditoría interna permanente y a tiempo completo, como se ilustra en el caso práctico de este módulo, pero no puede prescindir del principio de aseguramiento independiente sin asumir el riesgo correspondiente. La alternativa habitual es subcontratar auditorías puntuales (anuales o bianuales) a un tercero independiente, o aprovechar la auditoría de certificación/seguimiento de ISO/IEC 27001 como fuente parcial de aseguramiento, dejando constancia expresa ante el órgano de gobierno de que se trata de una limitación aceptada y de cómo se compensa.
¿NIST CSF 2.0 sustituye a ISO/IEC 27001 en Europa?
No. Son instrumentos de naturaleza distinta: ISO/IEC 27001 es una norma certificable con requisitos de sistema de gestión auditables por un tercero acreditado; NIST CSF 2.0 es un marco de referencia voluntario, no certificable, orientado a describir y comunicar la postura de ciberseguridad por funciones y niveles de madurez. En Europa, y en particular en España, ISO/IEC 27001 sigue siendo el estándar de referencia para certificación y para exigencias contractuales o de licitación; NIST CSF 2.0 se usa habitualmente como capa de comunicación con el consejo, benchmarking sectorial o requisito de clientes o matrices estadounidenses, no como sustituto de la certificación.
¿Dónde debe reportar el CISO: a TI, a riesgo corporativo o directamente al consejo?
No hay una única respuesta correcta válida para todas las organizaciones, pero sí un principio de diseño: si el CISO reporta jerárquicamente al CIO o al director de TI, existe un conflicto de interés estructural, porque en muchos casos el CISO debe señalar deficiencias de seguridad causadas por decisiones o prioridades del propio CIO (por ejemplo, retrasos en parcheo por priorizar disponibilidad). Buenas prácticas de gobierno —recogidas de forma consistente en guías de COBIT 2019 y en recomendaciones de organismos como ISACA— apuntan a que el CISO tenga una línea de reporting directa o, como mínimo, de escalado garantizado al comité de dirección o al comité de riesgos del consejo, independiente de la cadena de mando de TI, precisamente para preservar su capacidad de 2ª línea.
¿Qué diferencia hay entre «apetito de riesgo» y «tolerancia al riesgo», y quién los aprueba?
El apetito de riesgo es la cantidad y tipo de riesgo que una organización está dispuesta a aceptar en la búsqueda de sus objetivos estratégicos; es una declaración de alto nivel («no aceptamos ningún riesgo que pueda derivar en fuga de datos de clientes categoría especial»). La tolerancia al riesgo es la variación aceptable respecto a ese apetito para un objetivo concreto, normalmente expresada en umbrales medibles («aceptamos hasta 4 horas de indisponibilidad del e-commerce al trimestre»). Conforme a ISO 31000:2018, ambos deben ser definidos y aprobados por el órgano de gobierno como parte del marco de referencia de gestión de riesgos, no por la función de seguridad ni por gestión de riesgos de forma unilateral: son estas últimas quienes proponen y ejecutan dentro de esos límites, no quienes los fijan.
«The Governance function […] is central to an organization’s implementation of the CSF and provides context and understanding of the other five Functions […]. The Govern Function is critical, and it is intended to be considered while addressing each of the other Functions.» — National Institute of Standards and Technology (NIST), The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, 26 de febrero de 2024.