Una empresa de software no protege solo servidores: protege código fuente, pipelines de integración y despliegue, credenciales de nube, datos de clientes en ambientes productivos y la confianza contractual que sostiene cada renovación. Por eso implementar ISO 27001 en una empresa de software y tecnología exige algo distinto a copiar una plantilla de políticas: el Sistema de Gestión de Seguridad de la Información (SGSI) tiene que vivir dentro del ciclo de desarrollo, no al lado de él.
Esta guía está escrita para directores de tecnología (CTO), responsables de seguridad (CISO), líderes de ingeniería y directores generales de casas de software, integradores, proveedores de servicios administrados y empresas SaaS en México. Al terminar sabrás cómo definir el alcance, qué controles del Anexo A de ISO/IEC 27001:2022 pesan más en un entorno de desarrollo, qué evidencia pedirá el auditor y cuáles son los hallazgos que con mayor frecuencia detienen una certificación.
Por qué ISO 27001 en una empresa de software es un caso particular
En una manufacturera, el activo de información crítico suele ser la ingeniería de producto o la base de clientes. En una empresa de software, el producto es información. Eso cambia tres cosas de fondo en el diseño del SGSI:
- La superficie de ataque incluye la cadena de suministro de software: dependencias de código abierto, imágenes de contenedores, acciones de CI/CD de terceros y servicios de nube. El control 5.21 (seguridad de la información en la cadena de suministro de TIC) deja de ser teórico.
- Los cambios son continuos: un equipo que despliega varias veces al día necesita que la gestión de cambios (8.32) y la separación de ambientes (8.31) estén automatizadas; un formato de solicitud de cambio en papel no sobrevive una semana.
- El cliente audita al proveedor: cuestionarios de seguridad, cláusulas de protección de datos y derechos de auditoría llegan antes que la orden de compra. El certificado ISO/IEC 27001 emitido por un organismo acreditado reduce ese desgaste, pero solo si el alcance cubre lo que el cliente compra.
Además, el estándar cambió. La edición 2022 reorganizó el Anexo A en 93 controles agrupados en 4 temas y el periodo de transición desde la edición 2013, definido por el Foro Internacional de Acreditación (IAF MD 26), concluyó el 31 de octubre de 2025. Cualquier certificado vigente hoy debe estar emitido contra ISO/IEC 27001:2022; si un proveedor te muestra uno contra la edición 2013, ya no es válido.
Marco normativo y regulatorio aplicable
El núcleo es ISO/IEC 27001:2022 (requisitos certificables, cláusulas 4 a 10 más el Anexo A), complementada por ISO/IEC 27002:2022, que da la guía de implementación de cada control e introduce atributos (tipo de control, propiedades de seguridad, conceptos de ciberseguridad, capacidades operativas y dominios). Desde febrero de 2024 aplica además la Enmienda 1:2024, que pide considerar si el cambio climático es una cuestión pertinente en el contexto (§4.1) y en los requisitos de las partes interesadas (§4.2). Para una empresa de software esto suele traducirse en riesgos de disponibilidad de centros de datos o regiones de nube ante eventos climáticos extremos.
| Referencia | Qué aporta | Cuándo aplica |
|---|---|---|
| ISO/IEC 27001:2022 + Amd 1:2024 | Requisitos del SGSI y Anexo A (93 controles) | Siempre; es la norma certificable |
| ISO/IEC 27002:2022 | Guía de implementación y atributos de cada control | Siempre, como referencia técnica |
| ISO/IEC 27017:2015 | Controles específicos para servicios en la nube (proveedor y cliente) | Si operas o consumes IaaS/PaaS/SaaS de forma relevante |
| ISO/IEC 27018:2025 | Protección de datos personales en nube pública como encargado | Si tratas datos personales de clientes en tu plataforma |
| ISO/IEC 27701:2025 | Sistema de gestión de privacidad (ahora norma independiente) | Si tus clientes exigen evidencia de gestión de privacidad |
| Ley Federal de Protección de Datos Personales en Posesión de los Particulares (DOF 20-03-2025) | Deber de seguridad, avisos de privacidad, relación responsable–encargado | Siempre que trates datos personales en México |
| ISO/IEC 20000-1:2018 | Gestión de servicios de TI | Si además operas mesa de servicio, soporte o servicios administrados |
Requisito normativo: el SoA no es un anexo decorativo
ISO/IEC 27001:2022 §6.1.3 d) exige una Declaración de Aplicabilidad que contenga los controles necesarios, la justificación de su inclusión, si están implementados o no y la justificación de cualquier exclusión de controles del Anexo A. En una empresa de software, excluir controles como 8.25 a 8.31 casi nunca es defendible si desarrollas el producto que entregas.
En materia de datos personales, la nueva Ley Federal de Protección de Datos Personales en Posesión de los Particulares, publicada en el DOF el 20 de marzo de 2025 y vigente desde el día siguiente, abrogó la ley de 2010 y trasladó las facultades de vigilancia del extinto INAI a la Secretaría Anticorrupción y Buen Gobierno. Mantiene la obligación de establecer medidas de seguridad administrativas, físicas y técnicas, y de informar a los titulares sobre vulneraciones que afecten de forma significativa sus derechos. Si tu plataforma procesa datos de los clientes de tu cliente, eres encargado y tu contrato debe reflejarlo; el control 5.34 (privacidad y protección de información de identificación personal) es el puente entre la ley y el SGSI.
Cómo definir el alcance del SGSI en una empresa de software
El alcance (§4.3) es la decisión que más condiciona el costo, la duración y el valor comercial del certificado. Un error común es certificar "la oficina" cuando el cliente compra "la plataforma". Otro, igual de grave, es intentar certificar toda la empresa con tres líneas de negocio distintas en el primer ciclo.
Recomendamos redactar el alcance desde el producto o servicio que se vende, incluyendo los procesos que lo hacen posible:
Ejemplo de enunciado de alcance bien construido
"El SGSI aplica al diseño, desarrollo, operación y soporte de la plataforma SaaS de facturación electrónica, incluyendo los procesos de gestión de personal técnico, gestión de proveedores de nube, respuesta a incidentes y continuidad, operados desde las oficinas de Guadalajara y mediante trabajo remoto, de acuerdo con la Declaración de Aplicabilidad versión 1.2."
Al definir el alcance documenta explícitamente las interfaces y dependencias (§4.3 c): el proveedor de nube, el proveedor de identidad, el servicio de correo, la pasarela de pagos o la herramienta de control de versiones. El modelo de responsabilidad compartida de la nube debe quedar por escrito: el proveedor protege la infraestructura física; tú respondes por la configuración, las identidades, el cifrado y los datos. El control 5.23 (seguridad de la información para el uso de servicios en la nube), nuevo en 2022, pide precisamente procesos para adquirir, usar, gestionar y salir de esos servicios.
Consejo de auditor
Los informes de certificación y atestación de tu proveedor de nube no "heredan" controles de forma automática. Úsalos como evidencia de la parte que le corresponde, pero demuestra con tus propios registros la parte que te toca: configuración de cuentas, revisión de accesos, cifrado y respaldos.
Requisitos clave de ISO 27001 y evidencia que pide el auditor
El auditor de certificación sigue el esquema de ISO/IEC 17021-1 e ISO/IEC 27006-1:2024: una etapa 1 de revisión de diseño y preparación, y una etapa 2 donde verifica implementación y eficacia. En una empresa de software, la mayor parte de la evidencia ya existe en tus herramientas; el trabajo consiste en hacerla trazable a cada requisito.
| Requisito | Qué verifica el auditor | Evidencia aceptable |
|---|---|---|
| §4.1 / §4.2 Contexto y partes interesadas | Que conozcas tus cuestiones internas, externas y requisitos de clientes | Análisis de contexto con requisitos contractuales de seguridad de los principales clientes |
| §5.1 Liderazgo | Compromiso visible de la dirección | Actas de comité con decisiones y recursos asignados; presupuesto de seguridad aprobado |
| §6.1.2 Apreciación de riesgos | Criterios definidos y resultados reproducibles | Metodología, matriz con dueños de riesgo y fechas; riesgos ligados a activos y procesos reales |
| §6.1.3 Tratamiento y SoA | Coherencia entre riesgos, controles y SoA | SoA con justificación por control y plan de tratamiento aprobado por los dueños de riesgo |
| §7.2 Competencia | Desarrolladores y operadores con formación en seguridad | Matriz de competencias, constancias de capacitación en desarrollo seguro |
| §8.1 Control operacional | Que los procesos se ejecuten como se planificaron | Registros de pipeline, aprobaciones de pull requests, tickets de cambio |
| Anexo A 8.25 / 8.28 Desarrollo y codificación segura | Reglas de desarrollo seguro aplicadas en la práctica | Estándar de codificación, reglas de revisión de código, reportes de análisis estático |
| Anexo A 8.8 Vulnerabilidades técnicas | Detección y remediación oportuna | Reportes de escaneo de dependencias e infraestructura con fechas de cierre |
| §9.2 Auditoría interna | Programa basado en riesgo, auditores imparciales | Programa anual, informes con hallazgos y evidencia de seguimiento |
| §9.3 Revisión por la dirección | Entradas completas y decisiones | Acta con estado de riesgos, incidentes, objetivos y cambios; acuerdos con responsables |
Recuerda que la edición 2022 añadió el §6.3 (planificación de los cambios): si migras de un proveedor de nube a otro o reorganizas los equipos de ingeniería, el auditor esperará ver que el cambio se planificó considerando su impacto en el SGSI.
Controles del Anexo A críticos para desarrollo de software
De los 93 controles, una veintena concentra la mayor parte del esfuerzo técnico en una empresa de software. Estos son los que, en nuestra experiencia como auditores, se revisan con más profundidad:
| Control | Nombre (paráfrasis) | Práctica DevSecOps que lo evidencia |
|---|---|---|
| 5.8 | Seguridad en la gestión de proyectos | Requisitos de seguridad en la definición de cada épica o historia de usuario |
| 5.21 | Cadena de suministro de TIC | Inventario de dependencias (SBOM), política de licencias y origen de componentes |
| 5.23 | Uso de servicios en la nube | Línea base de configuración de cuentas, plan de salida del proveedor |
| 8.2 | Derechos de acceso privilegiado | Acceso administrativo temporal, con aprobación y registro |
| 8.4 | Acceso al código fuente | Repositorios privados, ramas protegidas, revisión obligatoria antes de fusionar |
| 8.9 | Gestión de la configuración | Infraestructura como código versionada y detección de desviaciones |
| 8.12 | Prevención de fuga de datos | Escaneo de secretos en repositorios, restricciones de exportación de datos productivos |
| 8.15 / 8.16 | Registro y monitoreo | Bitácoras centralizadas con retención definida y alertas revisadas |
| 8.25 | Ciclo de vida de desarrollo seguro | Procedimiento de SDLC con puertas de seguridad definidas |
| 8.26 | Requisitos de seguridad de aplicaciones | Requisitos basados en un estándar reconocido (p. ej. OWASP ASVS) |
| 8.27 | Arquitectura e ingeniería segura | Principios de arquitectura documentados y modelado de amenazas en cambios mayores |
| 8.28 | Codificación segura | Análisis estático (SAST) y de composición (SCA) en el pipeline |
| 8.29 | Pruebas de seguridad | Pruebas dinámicas (DAST) y pruebas de penetración periódicas |
| 8.30 | Desarrollo subcontratado | Cláusulas de seguridad y revisión del código entregado por terceros |
| 8.31 | Separación de ambientes | Cuentas o suscripciones separadas para desarrollo, pruebas y producción |
| 8.32 | Gestión de cambios | Pull request aprobado + pipeline verde + despliegue trazable |
| 8.33 | Información de prueba | Prohibición de datos productivos sin enmascarar (8.11) en pruebas |
Cuatro de estos controles son nuevos en 2022: 5.23, 8.9, 8.12 y 8.28. Junto con 5.7 (inteligencia de amenazas), 5.30 (preparación de las TIC para la continuidad), 7.4 (monitoreo de seguridad física), 8.10 (eliminación de información), 8.11 (enmascaramiento de datos), 8.16 (actividades de monitoreo) y 8.23 (filtrado web) completan los 11 controles incorporados en la revisión.
Cuidado con los datos productivos en ambientes de prueba
Copiar la base de datos de producción a un ambiente de QA para "reproducir un error" es uno de los hallazgos más frecuentes en empresas de software. Viola 8.33 y 8.31, y puede constituir un tratamiento de datos personales no previsto en el aviso de privacidad. Define un procedimiento de enmascaramiento (8.11) antes de que el problema ocurra.
Cómo integrar el SGSI al ciclo de desarrollo paso a paso
La meta es que la evidencia de cumplimiento sea un subproducto del trabajo de ingeniería y no una tarea adicional al final del trimestre. Esta es la secuencia que seguimos con equipos de desarrollo:
- Inventario de activos orientado a producto. Además de laptops y servidores, registra repositorios, pipelines, cuentas de nube, bases de datos, secretos y servicios SaaS críticos, cada uno con dueño (5.9). Exportar el inventario desde las consolas de nube y del sistema de control de versiones reduce el mantenimiento manual.
- Clasificación de información. Define tres o cuatro niveles (p. ej. pública, interna, confidencial, restringida) y aplica la clasificación a datos de clientes, código y credenciales (5.12). El nivel determina cifrado, retención y quién puede acceder.
- Metodología de riesgos ligada a escenarios técnicos. Evalúa amenazas reales: credenciales filtradas en un repositorio, dependencia comprometida, mala configuración de un bucket, error de despliegue, caída de región. Usa criterios de probabilidad e impacto definidos por la dirección (§6.1.2 a).
- Puertas de seguridad en el pipeline. Escaneo de secretos, SAST y SCA en cada pull request; DAST en el ambiente de pruebas; bloqueo automático ante vulnerabilidades críticas. Documenta el criterio de bloqueo y quién puede autorizar excepciones.
- Gestión de identidades centralizada. Inicio de sesión único con factor múltiple (8.5), aprovisionamiento y baja ligados a recursos humanos (5.16, 5.18) y revisión trimestral de accesos privilegiados (8.2).
- Bitácoras, monitoreo y respuesta. Centraliza registros de aplicación, nube y proveedor de identidad (8.15), define alertas con responsable (8.16) y ensaya el plan de respuesta a incidentes (5.24 a 5.28) al menos una vez antes de la auditoría.
- Proveedores y nube. Clasifica proveedores por criticidad, revisa sus certificaciones o informes de atestación y formaliza requisitos de seguridad en contrato (5.19 a 5.22). Incluye un plan de salida para el proveedor de nube principal.
- Auditoría interna y revisión por la dirección. Audita con alguien independiente del área auditada (§9.2), cierra hallazgos con análisis de causa y lleva a la dirección indicadores, riesgos residuales y decisiones pendientes (§9.3).
Si tu organización también presta soporte o servicios administrados, considera integrar el SGSI con ISO/IEC 20000-1; ambos comparten la estructura armonizada y muchos procesos (cambios, incidentes, proveedores). Para una comparación con el marco estadounidense que piden algunos clientes, revisa ISO 27001 vs SOC 2.
Ejemplo resuelto: apreciación de riesgos en una casa de software
Ejemplo aplicado: "Codex Bajío", 48 personas, plataforma SaaS de nómina
Contexto. Empresa ficticia con sede en Querétaro, 32 desarrolladores, despliegues diarios en una nube pública, base de datos con información de nómina de empleados de 60 clientes corporativos. Dos prospectos enterprise exigen certificado ISO/IEC 27001:2022 en su evaluación de proveedores.
Criterios definidos por la dirección (§6.1.2 a). Probabilidad (P) e Impacto (I) en escala de 1 a 5. Nivel de riesgo = P × I. Aceptable: ≤ 6. Tratamiento obligatorio: ≥ 10. Entre 7 y 9: decisión del dueño del riesgo con justificación documentada.
| Escenario | P | I | Nivel | Tratamiento y controles | Residual |
|---|---|---|---|---|---|
| Llave de acceso a la nube publicada en un repositorio | 3 | 5 | 15 | Escaneo de secretos en pre-commit y pipeline (8.12), rotación automática, gestor de secretos (5.17) | 1 × 5 = 5 |
| Dependencia de código abierto con vulnerabilidad crítica | 4 | 4 | 16 | SCA con bloqueo en severidad crítica (8.28), SBOM (5.21), SLA de parcheo (8.8) | 2 × 4 = 8 (aceptado por el CTO con justificación) |
| Copia de datos de nómina en ambiente de QA | 3 | 4 | 12 | Enmascaramiento obligatorio (8.11), cuentas separadas (8.31), regla en el procedimiento de pruebas (8.33) | 1 × 4 = 4 |
| Caída de la región de nube principal | 2 | 4 | 8 | Respaldos en región secundaria (8.13), procedimiento de recuperación probado (5.30) | 2 × 3 = 6 |
Resultado. El SoA quedó con 89 controles aplicables y 4 exclusiones justificadas (por ejemplo, controles de seguridad física de centro de datos propio, porque no lo hay; la parte física se cubre con la evidencia del proveedor de nube y 7.9 para equipos fuera de las instalaciones). Las cifras son ilustrativas: tus criterios y resultados dependerán de tu contexto.
Observa la lógica que busca el auditor: el escenario está ligado a un activo real, el control elegido aparece en el SoA, el riesgo residual tiene una aceptación firmada y el plan indica responsable y fecha. Si cualquiera de esos eslabones falta, la apreciación no es reproducible y el §6.1.2 c) no se cumple.
Indicadores de seguridad para una empresa de software
El §9.1 exige determinar qué se mide, cómo, cuándo y quién analiza los resultados. Evita indicadores de vanidad como "número de políticas publicadas". Estos son ejemplos útiles; los umbrales deben definirlos tu dirección y tus compromisos contractuales:
| Indicador | Fórmula | Criterio sugerido (ajústalo) | Control relacionado |
|---|---|---|---|
| Tiempo de remediación de vulnerabilidades críticas | Días entre detección y cierre | Definido en tu política, p. ej. ≤ 15 días | 8.8 |
| Cobertura de análisis en pipeline | Repositorios con SAST/SCA activos ÷ repositorios productivos | 100 % de repositorios productivos | 8.28 |
| Revisión de accesos privilegiados | Revisiones completadas ÷ revisiones programadas | 100 % trimestral | 8.2, 5.18 |
| Bajas oportunas | Cuentas deshabilitadas ≤ 24 h ÷ bajas totales | 100 % | 5.18, 6.5 |
| Cambios sin aprobación | Despliegues a producción sin revisión registrada | 0 | 8.32 |
| Pruebas de restauración exitosas | Restauraciones exitosas ÷ restauraciones probadas | 100 % dentro del RTO definido | 8.13 |
| Capacitación en desarrollo seguro | Desarrolladores capacitados en el año ÷ total | 100 % | 6.3 |
Hallazgos típicos de auditoría ISO 27001 en empresas de TI
Estos son los hallazgos que con más frecuencia vemos en auditorías internas y de certificación de empresas de software. Ninguno requiere herramientas costosas para evitarse; requieren disciplina y trazabilidad.
| Hallazgo | Requisito | Corrección y acción correctiva |
|---|---|---|
| Exdesarrolladores con acceso activo al repositorio o a la nube | Anexo A 5.18, 6.5 | Deshabilitar cuentas; ligar la baja de RR. HH. al proveedor de identidad; revisión mensual automatizada |
| El SoA declara 8.29 "implementado", pero no hay pruebas de seguridad en el último año | §6.1.3 d), Anexo A 8.29 | Ejecutar pruebas; corregir el SoA para reflejar el estado real; programa anual de pruebas |
| Despliegues de emergencia sin registro posterior | Anexo A 8.32 | Definir procedimiento de cambio de emergencia con revisión retrospectiva en 48 h |
| Riesgos genéricos copiados de una plantilla, sin relación con los activos | §6.1.2 c) y d) | Reconstruir la apreciación con escenarios del producto y dueños identificados |
| Proveedor de nube sin evaluación ni requisitos contractuales revisados | Anexo A 5.19, 5.20, 5.23 | Evaluar al proveedor, archivar sus informes vigentes y documentar la matriz de responsabilidad compartida |
| Auditoría interna realizada por el mismo responsable del SGSI sobre su propio trabajo | §9.2.2 | Asignar auditor interno independiente o externo para los procesos propios |
| Bitácoras habilitadas pero nadie revisa alertas | Anexo A 8.15, 8.16 | Definir alertas prioritarias, responsable de revisión y evidencia de atención |
| Objetivos de seguridad sin medición ni seguimiento | §6.2, §9.1 | Objetivos medibles con responsable, plazo y revisión en el comité |
Si quieres profundizar en el tratamiento de no conformidades y el análisis de causa raíz, consulta nuestra guía de gestión de no conformidades; el método es el mismo para el SGSI (§10.2).
Checklist de preparación para la auditoría de certificación
- Alcance redactado desde el producto, con interfaces y dependencias identificadas (§4.3).
- Análisis de contexto con requisitos contractuales de seguridad de clientes clave y consideración de cambio climático (§4.1, §4.2).
- Política de seguridad aprobada por la dirección y comunicada (§5.2).
- Metodología de riesgos con criterios de aceptación aprobados y apreciación completa (§6.1.2, §8.2).
- SoA con 93 controles evaluados, justificación de inclusiones y exclusiones, y estado real de implementación (§6.1.3 d).
- Inventario de activos que incluye repositorios, pipelines, cuentas de nube y secretos (5.9).
- Procedimiento de SDLC seguro con puertas de seguridad automatizadas y evidencias en el pipeline (8.25 a 8.29).
- Ambientes separados y prohibición documentada de datos productivos sin enmascarar en pruebas (8.31, 8.33).
- Inicio de sesión único con factor múltiple y revisión periódica de accesos privilegiados (8.2, 8.5).
- Evaluación de proveedores críticos, incluida la nube, con plan de salida (5.19 a 5.23).
- Plan de respuesta a incidentes ensayado y registrado (5.24 a 5.28).
- Respaldos con pruebas de restauración documentadas (8.13).
- Avisos de privacidad y contratos de encargado alineados a la LFPDPPP de 2025 (5.34).
- Al menos un ciclo completo de auditoría interna y revisión por la dirección con acciones en seguimiento (§9.2, §9.3).
Para entender cómo se adapta este mismo modelo a una organización de 10 a 50 personas, revisa la guía rápida de ISO 27001 para startups y SaaS; y si buscas una visión general del estándar aplicable a cualquier giro, la guía de seguridad de la información para empresas. Más contexto sectorial en la página de tecnología, SaaS y Fintech y en la página de ISO 27001.
Cómo lo abordamos en Quality College
Iniciamos con un diagnóstico de brechas contra ISO/IEC 27001:2022 que revisa tu pipeline, tus cuentas de nube y tus contratos, no solo tus documentos. Con base en él definimos alcance, metodología de riesgos y SoA junto con tu equipo de ingeniería; acompañamos la implementación de controles, formamos auditores internos, ejecutamos la auditoría interna y te acompañamos en las etapas 1 y 2 frente al organismo certificador acreditado que elijas. Los proyectos típicos van de 8 a 16 semanas según alcance y madurez.
Para acelerar la documentación usamos Qualitix Bot®, nuestra IA especializada que genera borradores de políticas, procedimientos y SoA a partir de tu contexto real, siempre revisados por un consultor; y ISO Track®, nuestro SaaS para gestionar riesgos, auditorías, acciones correctivas e indicadores del SGSI. Hemos acompañado a más de 150 organizaciones en su certificación desde 2018 y ofrecemos garantía contractual de certificación.