Gobernanza de extensiones de navegador para NIS2, DORA y GDPR

María, la CISO de una fintech en rápido crecimiento, pensaba que la preevaluación de DORA avanzaba correctamente. Su equipo había preparado el registro de terceros de TIC, los contratos SaaS críticos, los registros de diligencia debida de proveedores, las decisiones de aceptación del riesgo y el paquete de informes para el órgano de dirección.

Entonces el auditor formuló una pregunta que nadie había previsto.

“¿Pueden mostrarnos su proceso de gobernanza para extensiones de navegador?”

La pregunta surgió durante una revisión de endpoints con un analista financiero. Durante una sesión de pantalla compartida, el auditor observó una extensión de productividad de terceros en el navegador del analista. Parecía inofensiva, pero una búsqueda rápida mostró que el desarrollador había sufrido un compromiso de la cadena de suministro tres meses antes. La extensión comprometida se había utilizado para sustraer tokens de sesión de importantes plataformas SaaS.

La fintech contaba con políticas sólidas contra el software no autorizado. Disponía de EDR, MFA, CASB, registros SaaS y un SGSI alineado con ISO/IEC 27001. Pero nadie había tratado el navegador como una plataforma de software gestionada. Nadie había inventariado las extensiones. Nadie había aprobado sus permisos. Nadie había comprobado si los desarrolladores de extensiones eran proveedores. Nadie había mapeado la actividad de las extensiones con evidencia de DORA, NIS2 o GDPR.

Un único complemento de navegador había convertido un endpoint aparentemente conforme en una posible puerta trasera hacia sistemas financieros, datos de clientes y flujos de trabajo regulados.

Ese es el problema de la gobernanza de extensiones de navegador en 2026. El navegador ya no es solo una ventana a internet. Es donde los empleados se autentican, aprueban pagos, acceden a registros de CRM, tratan datos personales, gestionan infraestructura en la nube e interactúan con plataformas SaaS críticas. Las extensiones ya no son complementos estéticos. Son código de terceros que se ejecuta dentro de la capa más sensible del trabajo moderno.

Para CISO, responsables de cumplimiento, delegados de protección de datos y propietarios del riesgo de las TIC, las extensiones no gestionadas se sitúan en la intersección de la seguridad de endpoints, la TI en la sombra, el riesgo de proveedores, la gestión de cambios, la gestión de vulnerabilidades y la responsabilidad proactiva en privacidad. ISO/IEC 27001:2022 proporciona a las organizaciones la estructura para gobernar este riesgo. NIS2, DORA y GDPR aportan la presión regulatoria para demostrarlo.

Las extensiones de navegador son software, proveedores y encargados del tratamiento

La mayoría de las organizaciones ya han aprendido a gestionar portátiles, dispositivos móviles, servidores, aplicaciones SaaS, infraestructura en la nube y cuentas privilegiadas. Las extensiones de navegador suelen quedar entre esos programas.

Los equipos de seguridad las ven como un ajuste del navegador. Compras no las ve porque no se firma ningún contrato. Legal no las ve porque no se abre ninguna solicitud de incorporación de proveedor. Los equipos de privacidad no las ven porque la extensión la instala un usuario, no se despliega como una aplicación oficial. Sin embargo, la extensión puede solicitar permiso para leer y modificar datos en todos los sitios web, acceder al contenido del portapapeles, capturar metadatos de páginas, gestionar descargas, inyectar scripts o comunicarse con un backend externo.

Esto significa que una extensión de navegador puede ser todo lo siguiente a la vez:

[ZB] Zenith Blueprint: An Auditor’s 30-Step Roadmap recoge el problema central en su guía ISO/IEC 27002:2022 para Control 8.19. Advierte que “incluso el personal con buenas intenciones podría instalar herramientas para ‘hacer el trabajo más rápido’, una extensión de navegador, una biblioteca de código, una aplicación de transferencia de archivos, sin darse cuenta de que acaba de introducir una puerta trasera, una dependencia sin parchear o un vector de exfiltración de datos”.

Esa frase debe tratarse como una declaración de riesgo para el consejo de administración. Los empleados que instalan extensiones de riesgo no suelen intentar eludir la seguridad. Buscan mejorar la productividad. El fallo de gobernanza se produce cuando la organización no proporciona un proceso seguro de solicitud, aprobación, despliegue y supervisión.

Por qué NIS2, DORA y GDPR hacen urgente este punto ciego

El riesgo de extensiones de navegador existe desde hace años, pero el contexto regulatorio ha cambiado. En 2026, se espera que las organizaciones demuestren no solo que existen controles, sino que están basados en el riesgo, integrados, supervisados y respaldados por evidencia.

NIS2 eleva las expectativas sobre ciberhigiene y seguridad de la cadena de suministro. DORA exige a las entidades financieras gestionar el riesgo de las TIC en dependencias internas y de terceros. GDPR exige a responsables y encargados demostrar seguridad del tratamiento, responsabilidad proactiva y privacidad desde el diseño. Las extensiones no gestionadas pueden socavar los tres marcos.

La lección es sencilla. Una extensión de navegador no es demasiado pequeña para importar. Si puede interactuar con datos regulados, sesiones autenticadas, flujos de trabajo financieros o servicios SaaS críticos, debe gobernarse.

Use ISO/IEC 27001:2022 como modelo operativo

ISO/IEC 27001:2022 es eficaz para la gobernanza de extensiones de navegador porque no exige un silo de cumplimiento independiente. Permite a las organizaciones extender los procesos existentes del SGSI a la capa del navegador.

El modelo práctico de control se construye alrededor de ocho controles del Anexo A de ISO/IEC 27001:2022:

[ZC] Zenith Controls: The Cross-Compliance Guide es especialmente útil porque explica cómo se auditan los controles de ISO/IEC 27001 y cómo respaldan evidencia entre marcos. Para Control 8.19, Zenith Controls: The Cross-Compliance Guide explica que los auditores “trazarán el flujo de trabajo: desde la solicitud hasta la prueba, la aprobación y la implementación”. Así es exactamente como debe diseñarse la gobernanza de extensiones.

Si un auditor encuentra una extensión que no está en la lista aprobada, no está documentada en registros de cambios y no ha sido objeto de evaluación de riesgos, el problema deja de ser un simple ajuste del navegador. Se convierte en evidencia de un control débil de instalación de software, de una gobernanza débil de endpoints y de un posible fallo de riesgo de proveedores.

Paso 1: descubra el parque de extensiones

El primer fallo de control en la fintech de María fue la visibilidad. Su equipo no sabía qué extensiones estaban instaladas, quién las había instalado, qué permisos solicitaban o si se conectaban a servicios externos.

El descubrimiento debe abarcar todos los navegadores, perfiles, usuarios, dispositivos y sistemas operativos gestionados. Debe identificar nombre de la extensión, ID único, versión, editor, fuente de instalación, conjunto de permisos, fecha de instalación, estado de actualización, número de usuarios, propietario de negocio y si la extensión se instala de forma forzada, por el usuario, mediante carga lateral o está bloqueada.

Control 8.1, Dispositivos endpoint de usuario, es el ancla. La guía de Zenith Blueprint: An Auditor’s 30-Step Roadmap para Control 8.1 establece que los dispositivos endpoint de usuario “deben reforzarse, supervisarse y controlarse”. Ese requisito incluye de forma natural al navegador, porque el navegador es ahora la interfaz principal del endpoint de usuario para el trabajo SaaS y en la nube.

Control 5.23 también se aplica cuando las extensiones se conectan a servicios en la nube. Zenith Blueprint: An Auditor’s 30-Step Roadmap presenta este control como una respuesta a la TI en la sombra, donde los usuarios adoptan servicios no autorizados sin gobernanza. Una extensión de navegador que envía contenido a un backend alojado desconocido constituye un evento de adopción de servicio en la nube, aunque nadie en compras lo haya aprobado.

Un resultado de descubrimiento maduro debe clasificar cada extensión en uno de cinco estados:

El descubrimiento no debe ser un proyecto puntual. Las extensiones se actualizan con frecuencia, los editores cambian de propietario, los permisos se amplían y las tiendas eliminan paquetes maliciosos después de que los usuarios ya los hayan instalado. El inventario debe ser continuo o, al menos, lo bastante recurrente para respaldar la gestión de vulnerabilidades y la evidencia de auditoría.

Paso 2: haga explícito el uso aceptable

Una vez visibles las extensiones, las expectativas para los usuarios deben ser claras. Muchas organizaciones ya disponen de lenguaje de política que puede respaldar la gobernanza de extensiones, pero debe aplicarse explícitamente al navegador.

[P-EPM] Política de Protección de Endpoints frente al Malware - pyme establece que los usuarios “no deben instalar software o complementos no autorizados que puedan introducir riesgos”. Esa única frase proporciona a los equipos de seguridad una base sólida de política para tratar las extensiones de navegador como software controlado.

[P03-AUP] P03 Política de Uso Aceptable, también referenciada como la Política de Uso Aceptable corporativa, prohíbe “Herramientas no aprobadas: instalar o utilizar software, hardware, servicios en la nube o dispositivos no autorizados”. Esta es la base orientada al usuario. Convierte la gobernanza de extensiones de navegador de una preferencia técnica en un requisito exigible de comportamiento y cumplimiento.

Una política sólida de extensiones de navegador debe responder a seis preguntas prácticas:

No se trata de prohibir todas las extensiones útiles. Se trata de pasar de la confianza implícita a la aprobación explícita. Algunas extensiones pueden ser seguras, necesarias y mejorar la productividad. Otras pueden ser innecesarias, tener permisos excesivos, estar abandonadas o ser hostiles. El programa de gobernanza debe distinguir entre ellas.

Paso 3: aplique denegación por defecto con lista de permitidos por excepción

Control 8.19, Instalación de software en sistemas en explotación, es el control que convierte la política en operación. Las extensiones de navegador no deben tratarse de forma distinta a otro software simplemente porque los usuarios las instalen desde una tienda del navegador.

Zenith Blueprint: An Auditor’s 30-Step Roadmap es directo en este punto: “no se instala ningún software salvo que esté justificado, autorizado y asegurado”. Para las extensiones de navegador, esto implica utilizar gestión corporativa del navegador, gestión de endpoints o herramientas de configuración de dispositivos para aplicar reglas de instalación.

El modelo más defendible es la denegación por defecto con lista de permitidos por excepción:

1. Bloquear todas las extensiones por defecto en navegadores gestionados.
2. Forzar la instalación únicamente de extensiones corporativas esenciales y aprobadas.
3. Mantener una lista de permitidos para extensiones aprobadas por grupo de usuarios, departamento o rol.
4. Bloquear extensiones instaladas por carga lateral y fuentes de instalación no confiables.
5. Impedir que los usuarios eludan las políticas cambiando de perfil o usando navegadores no gestionados.
6. Eliminar extensiones ya instaladas que no estén aprobadas.
7. Revisar los permisos de la extensión y el riesgo del editor antes de la aprobación.
8. Registrar extensiones permitidas, bloqueadas, eliminadas y modificadas.

Algunas organizaciones empiezan con un modelo más gradual por complejidad operativa. Pueden inventariar primero, bloquear extensiones conocidas como maliciosas y después introducir listas de permitidos por fases para grupos de alto riesgo, como finanzas, ingeniería, administradores privilegiados, legal, Recursos Humanos y soporte al cliente. Esto es aceptable si existe una hoja de ruta documentada. Lo que no es defendible es tolerar de forma permanente el riesgo desconocido de extensiones.

Paso 4: evalúe el riesgo de las extensiones como proveedores y software

Una revisión de riesgos de extensiones de navegador debe ser lo bastante ligera para facilitar la adopción por la organización, pero lo bastante sólida para superar una auditoría. La revisión debe combinar riesgo de software, riesgo de proveedores, riesgo en la nube, protección de datos y gestión de vulnerabilidades.

[P-TP] Política de Seguridad de Terceros y Proveedores exige que “todos los proveedores nuevos se sometan a una evaluación de seguridad documentada antes de la ejecución del contrato”. No todos los desarrolladores de extensiones requerirán un proceso completo de incorporación de proveedores corporativos, pero el principio de riesgo de proveedores sigue aplicando. Si un desarrollador puede enviar actualizaciones de código a los navegadores de los empleados o tratar datos de la organización mediante un servicio backend, la organización tiene una dependencia de terceros.

[P-ASR] Política de requisitos de seguridad de las aplicaciones - pyme refuerza el mismo requisito desde la perspectiva del software: “cualquier herramienta de terceros, complemento o biblioteca de código externa utilizada en una aplicación debe registrarse y revisarse anualmente en cuanto a impacto de seguridad y estado de parcheado”.

Utilice el siguiente modelo de riesgo para normalizar las decisiones:

Una extensión de alto riesgo no debe aprobarse salvo que exista una necesidad crítica de negocio, controles compensatorios documentados y aceptación del riesgo por la alta dirección. Entre los ejemplos de controles compensatorios se incluyen limitar el uso a un perfil de navegador reforzado, restringirlo a URL específicas, bloquear la introducción de datos en aplicaciones sensibles mientras esté activa, utilizar supervisión DLP o exigir un contrato con el proveedor y un anexo de privacidad.

Paso 5: integre la revisión de privacidad y GDPR

La gobernanza de extensiones de navegador suele fallar porque la revisión de privacidad está desconectada de las herramientas de endpoints. Sin embargo, muchas extensiones pueden ver datos personales mostrados en aplicaciones SaaS, sistemas de Recursos Humanos, tickets de soporte, registros de CRM, correo electrónico, plataformas de analítica y herramientas de colaboración.

Conforme a GDPR Article 5(2), la organización debe demostrar responsabilidad proactiva. Conforme a Article 25, debe aplicar protección de datos desde el diseño y por defecto. Conforme a Article 32, debe aplicar medidas técnicas y organizativas adecuadas para la seguridad del tratamiento. Si una extensión exfiltra datos personales, el evento puede convertirse en una brecha de datos personales conforme a Article 4(12), lo que activa la evaluación y, posiblemente, las obligaciones de notificación de Article 33.

Una revisión de extensiones con enfoque de privacidad debe plantear:

No todas las extensiones requieren una EIPD completa. Sin embargo, las extensiones con acceso amplio a páginas, procesamiento de IA, captura de pantalla, acceso a correo electrónico, acceso a CRM, acceso a datos de Recursos Humanos, datos de soporte al cliente o datos financieros regulados deben activar una evaluación estructurada de privacidad.

Paso 6: registre y supervise para auditoría y respuesta a incidentes

Un programa de gobernanza de extensiones sin registros no es auditable. También debilita la respuesta a incidentes, porque la organización no puede determinar cuándo se instaló una extensión, quién la usó, qué versión estaba presente, cuándo cambiaron los permisos o si se produjo un intento de instalación bloqueado.

[P-LM] Política de registro y supervisión - pyme identifica los registros de “instalaciones de software” como un requisito clave de gobernanza. La instalación de una extensión de navegador es un evento de instalación de software y debe capturarse como tal.

Como mínimo, los registros deben incluir:

Estos registros deben alimentar los procesos de supervisión conforme a los controles 8.15 y 8.16. En función del riesgo, también pueden enviarse a un SIEM, una plataforma de endpoints o un repositorio de evidencia de cumplimiento. Deben configurarse alertas para extensiones de alto riesgo bloqueadas, aumentos repentinos en solicitudes de extensiones, cambios de permisos en extensiones aprobadas, intentos de instalación desde fuentes no oficiales e intentos de instalación por usuarios privilegiados.

La supervisión también aporta ventaja frente a NIS2 y DORA. La notificación de incidentes de NIS2 Article 23 depende de la detección temprana y de la evaluación de impacto. DORA exige una gestión robusta de incidentes de TIC y evidencia de resiliencia. La evaluación de brechas conforme a GDPR depende de saber qué ocurrió, cuándo y qué datos pudieron verse afectados.

Lo que el auditor quiere ver

Un auditor rara vez se conforma con una afirmación como “bloqueamos extensiones de riesgo”. Quiere evidencia de gobernanza. La evidencia debe conectar política, evaluación de riesgos, aplicación técnica, supervisión y responsabilidad de la dirección.

Aquí es donde Zenith Controls: The Cross-Compliance Guide resulta valiosa. Ayuda a las organizaciones a mostrar cómo una actividad de control respalda múltiples expectativas de cumplimiento. Un único flujo de aprobación de extensiones de navegador puede respaldar ISO/IEC 27001 Control 8.19, la ciberhigiene de NIS2, la gestión del riesgo de las TIC de DORA y la responsabilidad proactiva de GDPR si la evidencia se conserva y se mapea con claridad.

Matriz de correspondencia: ISO/IEC 27001:2022 con NIS2, DORA y GDPR

Una matriz de correspondencia práctica ayuda a los CISO a explicar por qué la gobernanza de extensiones de navegador no es un control técnico de nicho. Es un control de cumplimiento con amplio valor regulatorio.

El mapeo con DORA merece atención especial. Algunos auditores y evaluadores usarán lenguaje de estilo COBIT al revisar la gobernanza de cambios de TIC. COBIT BAI06 se entiende comúnmente como Managed IT Changes. Si las extensiones de navegador son software y su instalación cambia el entorno informático del usuario, entonces la instalación de extensiones pertenece a la misma lógica de cambio gobernado. Zenith Controls: The Cross-Compliance Guide respalda esta perspectiva de auditoría al mostrar cómo la evidencia de controles ISO/IEC 27001 puede reutilizarse en distintas expectativas de cumplimiento.

Plan de implementación de 90 días para la gobernanza de extensiones de navegador

Las organizaciones no necesitan resolverlo todo en una sola semana. Un programa práctico puede construirse por fases, especialmente si la interrupción de las operaciones de la organización debe gestionarse con cuidado.

Para organizaciones de alto riesgo, especialmente entidades financieras sujetas a DORA o entidades esenciales e importantes sujetas a NIS2, la primera fase de aplicación debe priorizar a los usuarios con acceso a sistemas críticos, datos regulados, consolas de administración privilegiada, plataformas financieras, herramientas de soporte al cliente y entornos de desarrollo.

El mensaje para el consejo de administración

La gobernanza de extensiones de navegador no debe presentarse a la alta dirección como un proyecto de bastionado del navegador. Debe presentarse como un control sobre código de terceros no evaluado en flujos de trabajo regulados.

El consejo de administración y el órgano de dirección deben comprender cuatro puntos:

1. El navegador es ahora una plataforma central de la organización.
2. Las extensiones pueden acceder a datos SaaS sensibles y sesiones autenticadas.
3. Las extensiones no gestionadas generan riesgo de proveedores, privacidad, incidentes y resiliencia.
4. ISO/IEC 27001:2022 proporciona un modelo de control defendible que respalda evidencia de NIS2, DORA y GDPR.

Este enfoque desplaza la conversación de la preferencia técnica a la resiliencia operativa. También respalda la financiación de la gestión corporativa del navegador, la integración con endpoints, la supervisión, la revisión de privacidad, el triaje de proveedores y la automatización de evidencia de auditoría.

Del punto ciego al control estratégico

El problema de auditoría de María no lo causó un analista instalando una herramienta de productividad. Lo causó una clase de riesgo no gestionada. La organización había construido un programa sólido de cumplimiento alrededor de activos visibles, proveedores visibles, plataformas SaaS visibles y endpoints visibles, pero la capa de extensiones de navegador seguía siendo invisible.

Esa brecha es ahora demasiado importante para ignorarla.

La solución no es complicada, pero debe ser deliberada. Trate el navegador como parte del endpoint. Trate las extensiones como software. Trate a los desarrolladores de extensiones y sus backends como proveedores cuando proceda. Trate los permisos como acceso a datos. Trate la instalación como un cambio. Trate los registros como evidencia de cumplimiento.

Un programa defendible empieza con cuatro acciones:

1. Descubrir todas las extensiones en navegadores y endpoints gestionados.
2. Definir reglas de uso aceptable y denegación por defecto utilizando Política de Protección de Endpoints frente al Malware - pyme, P03 Política de Uso Aceptable y la Política de Uso Aceptable corporativa.
3. Evaluar las solicitudes de extensiones usando criterios de proveedores, nube, vulnerabilidades y privacidad de la Política de Seguridad de Terceros y Proveedores y la Política de requisitos de seguridad de las aplicaciones - pyme.
4. Aplicar y supervisar la actividad de instalación mediante gestión del navegador, registro de eventos y prácticas de evidencia alineadas con la Política de registro y supervisión - pyme.

Para CISO que se preparan para auditorías NIS2, DORA, GDPR o ISO/IEC 27001:2022, la gobernanza de extensiones de navegador es una mejora de control de alto valor porque cierra una ruta real de ataque y, a la vez, produce evidencia reutilizable entre marcos.

Para acelerar el trabajo, descargue Zenith Blueprint: An Auditor’s 30-Step Roadmap y mapee su evidencia con Zenith Controls: The Cross-Compliance Guide. Si desea convertir el caos de extensiones de navegador en un programa de gobernanza preparado para auditorías, programe una evaluación o demostración de Clarysec y comience con un inventario práctico, un mapa de riesgos y un plan de control de 90 días.