SOC 2 · ISO 27001

¿Aprobar SOC 2 o ISO 27001 cubre la divulgación de licencias?

No. Las certificaciones de seguridad y la divulgación de licencias de terceros responden a preguntas distintas, y ambas pueden ser ciertas a la vez: puedes tener un certificado válido y aun así deber un registro de licencias revisado a nivel de producto.

Última actualización: 2 de julio de 2026

01Lo que señala esta página

Los puntos de fallo que se pasan por alto

Estos aparecen en la debida diligencia y las auditorías: existen las obligaciones, falta la evidencia, y el artefacto que esperan los compradores está ausente.

Las licencias de open source son obligaciones legales, no preferencias
MIT, Apache, GPL, LGPL y los acuerdos de SDK propietarios imponen condiciones: aviso, atribución, copyleft, reglas de distribución. No cumplirlas es un incumplimiento de licencia, no un vacío de estilo. Los programas SOC 2 e ISO no hacen desaparecer esas obligaciones; preguntan si tus controles las detectan antes de la distribución.
ISO 27001: la propiedad intelectual es explícita
El Anexo A 5.32 exige procedimientos para cumplir los derechos de propiedad intelectual, incluidas las licencias de software. Los auditores esperan evidencia, no solo un PDF de política. No incluir los textos de licencia exigidos donde las licencias lo requieren es a la vez una infracción de propiedad intelectual y un fallo de evidencia del SGSI cuando tus controles afirman que el software de terceros está gestionado.
SOC 2: sin control de página de licencias, pero los auditores siguen las pistas
Los Trust Services Criteria no mencionan "publicar todas las licencias en un sitio web". Aun así, los auditores rastrean el cumplimiento legal y la gestión de cambios. Los vacíos sistémicos (avisos ausentes, inventario sin revisar, sin registro a nivel de producto) salen a la luz como deficiencias de control cuando las muestras no coinciden con la política.
El alcance de la certificación no es el alcance del producto
Un certificado SOC 2 Tipo II o ISO cubre tu sistema y periodo, no automáticamente cada dependencia de cada SKU. Los compradores igualmente hacen preguntas específicas del producto. Tu certificación ayuda; no sustituye la divulgación de licencias de terceros del producto bajo contrato.
Los paquetes de evidencia se desactualizan entre auditorías
Los equipos presentan a la auditoría de seguimiento ISO la misma hoja de cálculo de OSS que presentaron el año pasado, mientras que ingeniería distribuyó doce versiones. Los auditores de seguimiento muestrean sistemas en vivo. El desajuste entre la evidencia y la producción es un hallazgo mayor clásico, y ese mismo desajuste acaba con las renovaciones de compras.
El análisis de seguridad no es revisión de licencias
Los analizadores de vulnerabilidades y las herramientas de SBOM identifican componentes y, a veces, campos de licencia. No adjuntan el texto completo de la licencia, no aprueban el riesgo de copyleft, ni publican divulgación lista para el comprador. Equiparar la salida de las herramientas de AppSec con el cumplimiento de licencias crea una falsa confianza tanto en la evidencia de SOC como en las respuestas de RFP.
Las sorpresas de copyleft también perjudican a las organizaciones certificadas
GPL o AGPL en un producto distribuido sin oferta de código fuente ni revisión de cumplimiento es un problema legal y de auditoría, independientemente de la certificación ISO 27001. Descubrirlo durante la debida diligencia del comprador, en lugar de en la revisión interna, es el camino caro.
Los compradores quieren pruebas junto a tu informe
Los clientes empresariales piden tu informe SOC y un registro de licencias de terceros del producto: inventario, texto completo, proceso de mantenimiento. El centro de confianza cubre la postura de seguridad; la divulgación de licencias cubre las obligaciones de propiedad intelectual en la base de código. Ambos aparecen en las revisiones de proveedores maduras.

SOC 2 e ISO 27001 demuestran que gestionas un sistema de seguridad y gestión: control de acceso, gestión de cambios, tratamiento de riesgos, supervisión de proveedores. Los auditores examinan el diseño de los controles y su eficacia operativa. Ninguna de las dos certificaciones inventaría por defecto todas las obligaciones de licencia de open source en cada producto distribuido.

Los compradores tratan la certificación como un requisito mínimo, y luego piden por separado divulgación de licencias de terceros (texto completo, atribución, inventario delimitado por producto). Superar SOC 2 no responde a "qué componentes GPL hay en la build que licenciamos".

¿Qué exige realmente ISO 27001 sobre las licencias de open source?

ISO/IEC 27001:2022 exige que operes procedimientos que aseguren el cumplimiento de los derechos de propiedad intelectual, incluidas las condiciones de licencia de software, bajo el control 5.32 del Anexo A. No prescribe una página de licencias pública, pero un auditor puede pedir evidencia de que las condiciones de licencia de terceros en lo que distribuyes realmente se cumplen.

Un documento de control que dice "respetamos las licencias de OSS" sin evidencia (inventario revisado, texto completo, alineación con las versiones) es un hallazgo esperando a suceder. Especialmente cuando las pruebas de muestreo encuentran paquetes en producción que no están en ninguna lista.

Política para licencias aceptables y procesos de aprobación.
Evidencia de que los productos distribuidos cumplen las condiciones de licencia de terceros.
Registros de revisión, no solo la salida de un análisis de descubrimiento.
Alineación entre lo que declara el SGSI y lo que distribuye ingeniería.
Gestión de los cambios de licencia cuando se actualizan las dependencias.

¿Qué buscan en la práctica los auditores de SOC 2 sobre el cumplimiento de licencias?

Los auditores de SOC 2 no exigen una página de licencias pública; rastrean si tus controles de los Trust Services Criteria de la AICPA para cumplimiento legal, gestión de proveedores y control de cambios realmente detectan las obligaciones de licencia de terceros. Una higiene de OSS descuidada aparece ahí como evidencia débil frente a criterios que ya afirmas operar.

Los auditores muestrean sistemas. Preguntan cómo sabes que el software de terceros está licenciado correctamente. "Ejecutamos npm audit" no es una respuesta. Tampoco lo es una insignia de certificación en tu sitio web sin un inventario a nivel de producto.

Control	Qué esperan los auditores	Evidencia que lo satisface
ISO 27001 A 5.32	Procedimientos que aseguran el cumplimiento de la propiedad intelectual y las licencias de software	Inventario revisado con el texto completo de la licencia por cada producto distribuido
SOC 2 CC2.2	Gobernanza y supervisión de las obligaciones de cumplimiento	Registros de revisión que muestran quién aprobó qué componentes y cuándo
SOC 2 CC8.1	Los cambios de dependencias pasan por la gestión de cambios	Registros de deriva que vinculan los cambios de lockfile con la nueva revisión
SOC 2 CC9.2	Se gestiona el riesgo del software de terceros y proveedores	Registro de divulgación delimitado por producto, al día a fecha de la versión

Los hallazgos aparecen cuando existe una política, pero no la prueba operativa.

Por qué las certificaciones y la debida diligencia del comprador divergen

El alcance de la certificación es el entorno de control: a menudo un centro de confianza, un periodo, un límite de sistema. El alcance de la debida diligencia del comprador es el producto que compra (este SKU, esta versión, estas obligaciones hoy).

Tu informe SOC 2 cubre cómo gestionas el cambio. Su equipo legal pide el texto de la licencia MIT de libfoo 2.4.1 en el instalador que despliegan. Preguntas distintas; ambas necesitan respuestas honestas.

¿Por qué el inventario se desactualiza en las organizaciones certificadas?

El inventario se desactualiza porque la certificación es periódica mientras que las dependencias cambian continuamente. El informe Open Source Security and Risk Analysis de Black Duck encontró código de open source en el 96 % de las bases de código que auditó, y que la mayoría contenía componentes con conflictos de licencia o sin licencia identificable, así que un único paquete de evidencia anual no puede rastrear lo que realmente distribuye cada versión.

Las empresas certificadas fusionan actualizaciones de dependencias entre ciclos de auditoría. Los desarrolladores añaden paquetes sin actualizar la hoja de cálculo del paquete de evidencia ISO del año pasado. El certificado es válido; el inventario está desactualizado.

El cumplimiento operativo de licencias significa reimportar en cada versión, revisar de nuevo, volver a publicar. El mismo ciclo de mantenimiento que exigen la CRA y compras, dentro de un SGSI que ya afirma que gestionas el riesgo de terceros.

Evidencia que aceptan tanto auditores como compradores

Inventario de terceros revisado y vinculado a etiquetas de versión. Texto completo de la licencia almacenado junto a cada componente aprobado. Instantánea de publicación o exportación con fecha y aprobador. Detección de deriva cuando cambian los lockfiles. Divulgación pública o de cara al cliente cuando los contratos lo exigen.

El formato varía (URL, exportación en PDF, paquete JSON). La evidencia es el registro revisado y el proceso, no el tipo de archivo.

Importar desde lockfiles o SBOM en cada versión.
Revisión humana antes de aprobar, especialmente para copyleft.
Registro de auditoría: quién aprobó qué y cuándo.
Exportaciones adjuntas a la evidencia ISO o a las solicitudes de los auditores de SOC.
Se repite con cada cambio de dependencias, no solo anualmente.

Patrones de fallo habituales en auditorías y acuerdos

Política sin inventario. Inventario sin el texto completo de la licencia. Texto completo recopilado una vez y nunca actualizado. Análisis de seguridad confundido con revisión de licencias. Centro de confianza que menciona privacidad y seguridad pero calla sobre OSS. GPL en producción descubierta por el análisis del comprador, no por el tuyo.

Cada patrón genera hallazgos de ISO, excepciones de SOC, o retrasos en acuerdos. La solución es infraestructura operativa para las obligaciones de licencia, en paralelo a los programas de certificación (no sustituida por ellos).

Cómo asocian los equipos los controles con el trabajo de licencias

Asocia el control 5.32 y los criterios de gestión de cambios de SOC a pasos concretos: importar, revisar, publicar, comprobar deriva. Nombra responsables en ingeniería y cumplimiento. Adjunta las exportaciones de divulgación a las carpetas de evidencia del SGSI. Muestrea productos durante la auditoría interna de la misma forma que lo harán los auditores externos.

La certificación demuestra la madurez del proceso. Los registros de licencias a nivel de producto demuestran que cumples las obligaciones del software que vendes. Los compradores y las pruebas de muestreo de ISO esperan cada vez más ambas cosas juntas.

Fuentes

Cómo respalda SourceTrust la evidencia certificada

Las certificaciones demuestran que tienes un sistema de gestión. Los registros de licencias a nivel de producto demuestran lo que se distribuyó: revisado, con texto completo, actualizado cuando cambian las dependencias.

SourceTrust importa archivos de paquetes y SBOM, exige revisión antes de publicar, y genera un registro de divulgación mantenido por producto, además de exportaciones para las carpetas de evidencia ISO y los cuestionarios de compradores. Las comprobaciones de deriva alinean los registros de licencias con los mismos cambios de dependencias que tus controles de gestión de cambios ya rastrean para SOC 2.

Ve cómo funciona la plataforma

Importa desde repositorios, manifiestos y SBOM. Cada fila es una licencia que satisfacer
Puertas de revisión y publicación. Evidencia que los auditores pueden muestrear contra producción
Registro de divulgación por producto. Lo que piden los compradores más allá del informe SOC
Alertas de deriva cuando cambian las dependencias o licencias entre ciclos de auditoría

SourceTrust es infraestructura de cumplimiento, no asesoramiento jurídico ni un sustituto de tu firma auditora de ISO o SOC. Te ayuda a poner en práctica las obligaciones de licencia; tu asesoría legal y tus auditores siguen siendo la autoridad sobre el diseño de tus controles.