Los ingenieros que se adentran por primera vez en ISO 27001 suelen imaginarse una gran auditoría de código, o un certificado que se aprueba como una suite de pruebas. No es ni lo uno ni lo otro. ISO/IEC 27001:2022 es un estándar de sistema de gestión. Construyes un sistema de gestión de seguridad de la información (políticas, tratamiento de riesgos, roles, proveedores, incidentes, y el resto). Un organismo de certificación acreditado audita ese sistema y, si cumple, emite un certificado. El repositorio de GitHub no es el objeto de certificación.
Esta página trata sobre la pequeña parte que sí reside en el repositorio: los controles tecnológicos del Anexo A que una solicitud de extracción puede debilitar en silencio. Es el equivalente de ISO 27001 de las guías "qué revisa realmente" de SOC 2 y HIPAA. No es el catálogo de controles (eso es el centro del marco), ni la pregunta "¿hay una App de GitHub?" (eso tiene su propia respuesta).
El certificado no es un escaneo de repositorio
Un informe SOC 2 Tipo II es la opinión de una firma de contabilidad independiente sobre si sus controles, tal como los describió, estaban adecuadamente diseñados y operaron de manera efectiva durante un período. Un informe Tipo I solo habla del diseño en un momento determinado. Un certificado ISO 27001 acreditado es diferente en especie: un organismo de certificación acreditado certifica que su sistema de gestión cumple con la norma. Ninguno es un escaneo estático del código fuente. Ninguno es emitido por una Aplicación de GitHub. Si un proveedor implica que instalar un revisor "te da ISO 27001", están describiendo un producto diferente al estándar.
El Anexo A de la ISO/IEC 27001:2022 lista 93 controles en cuatro temas (organizacional, personas, físico, tecnológico). No implementas los 93 como una lista de verificación de código. La Declaración de Aplicabilidad registra los controles que determinaste que eran necesarios, por qué están incluidos, si están implementados y por qué se excluye cualquier control del Anexo A. El Anexo A es un conjunto de referencia al que verificas esas decisiones, no un menú de 93 elementos para implementar como código. La mayoría de los 93 nunca aparecen en un diff: contratos con proveedores, oficinas físicas, selección de RRHH, documentación de tratamiento de riesgos. Tratar los 93 como una auditoría de repositorio es el grano equivocado.
La porción del Anexo A que reside en el código
El tema tecnológico (A.8) tiene 34 controles. Incluso allí, solo unos pocos aparecen habitualmente en una solicitud de extracción: registro (A.8.15), monitoreo (A.8.16), criptografía y manejo de claves (A.8.24), restricción de acceso (A.8.3), fuerza de autenticación (A.8.5), configuración que se mantiene ajustada a una línea base (A.8.9), codificación segura (A.8.28), gestión de cambios (A.8.32), copia de seguridad de información (A.8.13). Si puedes razonar sobre quién puede acceder a qué, cómo demuestran quién son, qué se registra, cómo se mantienen los secretos y si un cambio aún pasó por el proceso que escribiste, estás razonando sobre la mayoría de la superficie orientada al código.
El resto de A.8 (redes, capacidad, malware, relojes, etc.) es real, pero generalmente se decide en la arquitectura y las operaciones, no en una solicitud de extracción de dos líneas. El centro del marco enumera los desencadenantes. Esta página es el modelo mental: ISO 27001 en un repositorio son esas formas de A.8, no el certificado ni toda la lista del Anexo A.
Una ruta privilegiada que elimina silenciosamente un segundo factor
Un equipo de soporte no puede generar un token de API durante un incidente porque la ruta de administración requiere MFA y el teléfono de guardia está en un armario. Una solicitud de extracción elimina la verificación del segundo factor y deja la cookie de sesión como la única puerta. Las pruebas siguen siendo verdes. El código es más corto. Los comentarios de revisión se centran en desbloquear el incidente. Después de la fusión, cualquier persona que pueda obtener una sesión válida puede generar un token privilegiado sin el factor adicional que el camino solía exigir.
ISO 27001:2022 A.8.5 trata sobre la fuerza de autenticación. Una acción privilegiada que antes requería un segundo factor y ahora solo requiere una sesión es más débil después de la fusión. Si eso es aceptable (una excepción de incidente documentada y con tiempo limitado frente a un agujero permanente) es una decisión de riesgo para el equipo. El trabajo de la revisión es nombrar el control para que la decisión se tome a propósito. A.8.3 (restricción de acceso) puede sentarse a su lado si el token es cómo se concede el acceso.
El cambio inverso, volver a poner requireMfa en la ruta o enrutar la creación de tokens de incidentes a través de un camino de emergencia que se registra y expira, es barato en la PR. Dejar el camino más débil en su lugar es la versión costosa: seis meses después, un muestreador de un organismo de certificación puede preguntar cómo se autentican las acciones privilegiadas, y el contexto se ha perdido.
Dónde encaja heygrc y el límite de honestidad
heygrc es una App de GitHub que revisa cada solicitud de extracción en función de los marcos que seleccionaste y cita el control del Anexo A que un cambio toca, por ejemplo, A.8.5 en el salto de MFA anterior, o A.8.15 cuando una acción privilegiada deja de registrarse. No te certifica. No ejecuta tu ISMS. No escribe la Declaración de Aplicabilidad, elige el organismo de certificación o emite un certificado. Ni heygrc ni ISMS Copilot poseen una certificación ISO 27001. Úsalo como revisor del cambio, no como el sistema de gestión.
Si la pregunta que realmente escribiste fue "¿hay una App de GitHub para ISO 27001", la respuesta corta es sí, y vive en su propia página. Esta guía es la otra mitad: qué estaría mirando esa App y por qué la mayor parte de ISO 27001 nunca aparecerá en la diferencia.