1. La respuesta corta
Sí, pero no por usar GitHub. Para ISO 27001 debes incluir la forja en el alcance, tratar sus riesgos y conservar evidencias. Para ENS ALTA en SaaS, GitHub Enterprise Cloud aporta piezas que Team no ofrece, aunque la aceptación depende del servicio exacto, el contrato, la configuración, la evidencia reconocida y el auditor.
Capacidad contratada no significa control implantado. Control implantado no significa evidencia auditada. Y la certificación del proveedor no significa certificación del cliente.
2. La trampa de la certificación heredada
La confusión más común es pensar que, como GitHub tiene certificaciones y corre sobre Azure, esa conformidad ya cubre tu proyecto. No es cierto. Una certificación protege el perímetro concreto que se evaluó, no salta sola hacia dentro.
Que servicios o regiones concretos de Microsoft o Azure estén en un alcance ENS no cubre a GitHub por pertenencia societaria ni por usar su infraestructura. La certificación del proveedor tampoco cubre tu tenant, tu configuración ni el sistema que presta tu servicio. GitHub debe identificarse y tratarse como proveedor o dependencia en el alcance, los riesgos y las evidencias.
3. Los cinco peldaños de la evidencia
Demostrar cumplimiento es subir una escalera de cinco peldaños. La mayoría de organizaciones se quedan en el segundo, el del proveedor, y confunden lo que GitHub declara con lo que ellas pueden probar.
El salto que casi nadie da es del peldaño Proveedor al Tenant: pasar de lo que GitHub promete a lo que tú tienes realmente configurado, registrado y restaurable. Ahí es donde un plan barato deja de dar de sí.
4. Lo que GitHub Team no te deja demostrar
GitHub Team no es inseguro. Permite repositorios privados, 2FA, roles, reglas de repositorio y revisiones. El problema para un sistema ENS ALTA no es la seguridad del proveedor, sino tu capacidad de demostrar gobierno, trazabilidad, jurisdicción y recuperación. Estas son las carencias que más pesan.
| Dimensión | GitHub Team | Enterprise Cloud (UE + EMU) |
|---|---|---|
| Identidad | Cuentas personales, sin EMU, SAML ni SCIM. | Usuarios gestionados desde tu IdP, SAML u OIDC y SCIM. |
| Auditoría | 180 días y exportación manual, sin API. | API y streaming de auditoría hacia tu SIEM. |
| Residencia | Sin región seleccionable para GitHub.com. | Código y datos principales en la UE, con excepciones. |
| Red | Sin lista de IP permitidas de empresa. | Restricción de acceso por red. |
| SLA | Sin el SLA estándar de Enterprise. | Compromiso de disponibilidad con créditos. |
| Copia | Resiliencia interna, sin copia lógica completa tuya. | La copia externa independiente depende de riesgos, RPO, RTO y responsabilidad compartida. |
| Seguridad de código | Secret Protection y Code Security como añadidos. | Gobierno central, aunque los avanzados siguen siendo añadidos. |
| Evidencia cloud | Sin certificado reconocido localizado del servicio. | Más evidencias, pero conformidad ENS aún condicionada. |
Puede formar parte de un SGSI ISO 27001 bien gestionado. Como estado objetivo para ENS ALTA, con la evidencia pública disponible, no basta por sí solo.
5. Qué cambia con GitHub Enterprise Cloud
A 22 de julio de 2026, dentro de la oferta SaaS pública analizada de GitHub, Enterprise Cloud con residencia en la UE y Enterprise Managed Users es el único plan que reúne estas piezas. Funciones, retenciones, SLA, residencia y complementos pueden cambiar.
Cuentas gestionadas desde tu IdP, SAML u OIDC y SCIM para altas y bajas reales.
Código y datos principales en la Unión, con excepciones documentadas.
API y streaming del registro para recolectar, retener y correlacionar eventos.
Lista de IP permitidas para imponer el mismo acceso que el resto del sistema.
Compromiso de disponibilidad y una base contractual más sólida que negociar.
SOC 1, SOC 2 Type II, CSA STAR y documentación adicional de continuidad.
6. Enterprise aporta piezas, no certificados
Comprar Enterprise no te certifica. En ISO 27001 se certifica el SGSI dentro de un alcance definido. En ENS se certifica la conformidad de los sistemas incluidos.
Viable con criterio
No impone marca ni plan. Incluso Team puede formar parte de un SGSI certificado si tratas riesgos, controlas identidad, registros y copia, y conservas evidencias. Enterprise reduce el esfuerzo probatorio.
Condicionado
En categoría ALTA, el refuerzo de op.nub.1 exige que los sistemas de información que soportan los servicios cloud suministrados por terceros sean conformes con el ENS o dispongan de una certificación equivalente cuyo procedimiento sea reconocido por el Organismo de Certificación del CCN. Enterprise ayuda, pero la aceptación depende del servicio exacto, el contrato, la configuración y el auditor.
A 22 de julio de 2026 no he localizado evidencia pública suficiente de un certificado reconocido que identifique el servicio, la región y el alcance evaluados de GitHub. Debe pedirse y comprobarse, no presumirse.
7. Si la evidencia no llega, cambias el alcance
Cuando no puedes obtener la evidencia reconocida para el servicio exacto, no te quedas sin salidas. Tienes dos caminos, y ninguno es automático.
Otro servicio cloud que sí aporte la certificación reconocida para tu categoría, con su contrato y su configuración.
Una forja incluida en el alcance de un sistema con certificación ENS de categoría ALTA o contratada como servicio prestado mediante ese sistema. Autohospedar no da conformidad automática: asumes parcheado, hardening, alta disponibilidad, copia, claves, registros, seguridad física y operación continua.
La arquitectura más defendible separa GitHub del acceso directo a producción, construye en runners controlados, firma los artefactos y saca los registros y las copias fuera del dominio de GitHub. Así, un compromiso del repositorio no tumba tu sistema.
8. Anexos para justificar la decisión
Estos anexos resumen el material que sostiene el análisis. Sirven para llevar la conversación al proveedor y al auditor con preguntas concretas.
Niveles de evidencia
| Nivel | Qué significa |
|---|---|
| N | Normativa. Obligación de una fuente oficial. |
| V | Proveedor. Capacidad o compromiso que declara GitHub. |
| C | Contrato. Obligación comprobada en lo firmado. |
| T | Tenant. Control verificado en tu entorno real. |
| A | Auditor. Aceptación formal de la entidad certificadora. |
Diez preguntas de due diligence a GitHub
- Certificado reconocido por el CCN para el servicio, región y alcance exactos, si existe.
- Certificado ISO 27001 y SOC 2 Type II vigentes, con alcance, entidad, localizaciones y exclusiones.
- Mapa de localizaciones de código, registros, copias, soporte y telemetría.
- Lista de subprocesadores, países y mecanismo de cambio y notificación.
- Cifrado, gestión de claves, rotación y opciones de clave gestionada por el cliente.
- RPO y RTO por componente y resultados recientes de pruebas de recuperación.
- Eventos disponibles, retención, entrega a SIEM y recuperación tras interrupción.
- Plazo de notificación para compromisos de código, no solo de datos personales.
- Derecho de auditoría, cooperación con el certificador y acceso a evidencia forense.
- Portabilidad de todos los activos y prueba real de migración de salida.
Preguntas frecuentes
¿Puedo tener mi código en GitHub y certificarme en ISO 27001?
Sí. ISO 27001 no impone plataforma ni plan. GitHub se identifica y trata como proveedor o dependencia dentro del alcance del SGSI, sus riesgos y sus evidencias. Team no lo impide por sí solo, aunque Enterprise reduce el esfuerzo de identidad, auditoría, supervisión y prueba.
¿GitHub Team sirve para un sistema ENS de categoría ALTA?
Como estado objetivo, con la evidencia pública disponible, no basta por sí solo. Le faltan identidad corporativa, auditoría exportable a tu SIEM, residencia seleccionable, SLA estándar y una copia lógica completa que puedas demostrar. Puede mantenerse como transición temporal con el riesgo residual aceptado por escrito y una fecha de migración.
¿La certificación de GitHub o de Azure me vale a mí?
No se hereda. Una certificación cubre el perímetro evaluado del proveedor, no tu tenant ni el sistema que presta tu servicio. Solo cuentan los servicios, regiones y alcances concretos certificados de Microsoft o Azure. GitHub debe tratarse en tu alcance, riesgos y evidencias como proveedor o dependencia crítica.
¿Qué me da GitHub Enterprise Cloud que no tenga Team?
Enterprise Managed Users con SAML u OIDC y SCIM, residencia en la UE para el código y los datos principales, API y streaming de auditoría hacia tu SIEM, lista de IP permitidas, SLA con créditos y más evidencias. La copia externa independiente se decide según riesgos, RPO, RTO y responsabilidad compartida.
¿Comprar Enterprise me deja certificado en ENS ALTA?
No. Enterprise aporta las piezas, pero no acredita por sí solo la conformidad. La aceptación depende del servicio exacto, el contrato, la configuración, una certificación equivalente cuyo procedimiento reconozca el Organismo de Certificación del CCN y el auditor.
Si no consigo esa evidencia reconocida, ¿qué hago?
Tienes dos caminos. Cambiar a otro servicio cloud que sí aporte la certificación reconocida para tu categoría, o usar una forja incluida en el alcance de un sistema con certificación ENS de categoría ALTA. Autohospedar no da conformidad automática: traslada a tu equipo el parcheado, la alta disponibilidad, la copia, las claves, los registros y la operación continua.
Fuentes oficiales consultadas
Fecha de corte 22 de julio de 2026. Verifica los enlaces antes de una auditoría o una contratación.
- Real Decreto 311/2022, Esquema Nacional de Seguridad
- CCN-STIC 825, ENS y certificaciones ISO 27001
- CCN-STIC 823, seguridad en entornos cloud
- ISO/IEC 27001:2022
- GitHub: planes y funcionalidades
- GitHub Enterprise Cloud con residencia de datos
- GitHub Enterprise Cloud: streaming del registro de auditoría
- GitHub: informes de cumplimiento
- GitHub Data Protection Agreement
- Microsoft: alcance ENS de los servicios
Nota sobre evidencia. Donde no se ha localizado documentación pública debe entenderse como ausencia de evidencia localizada, no como afirmación absoluta de inexistencia.
¿Vuestro código crítico tiene que defenderse ante una auditoría?
Puedo revisar dónde vive vuestro código, qué evidencias os faltan y qué arquitectura os deja demostrar cumplimiento sin sobredimensionar el proyecto.
