Para una startup, el primer cuestionario de seguridad de un cliente enterprise suele llegar antes de que exista un área de seguridad. Doscientas preguntas sobre cifrado, accesos, respaldos, proveedores y respuesta a incidentes, y una frase al final: "¿cuentan con certificación ISO/IEC 27001?". Implementar ISO 27001 en una startup o empresa SaaS en México no requiere un departamento de cumplimiento ni una biblioteca de 80 políticas; requiere un Sistema de Gestión de Seguridad de la Información (SGSI) proporcional a tu tamaño, bien enfocado en tu producto y sostenible con el equipo que ya tienes.
Esta guía rápida está escrita para fundadores, CTO, líderes de ingeniería y responsables de operaciones de startups y SaaS de 10 a 50 personas. Al terminar sabrás cómo dimensionar el alcance, qué documentos son realmente obligatorios, cómo repartir roles en un equipo pequeño, qué evidencia pedirá el auditor y qué hallazgos detienen con más frecuencia a las empresas jóvenes.
Por qué ISO 27001 es distinta en una startup o SaaS
ISO/IEC 27001:2022 es la misma norma para un banco que para una startup de 15 personas. Lo que cambia es la forma de cumplirla. La norma exige resultados: un alcance definido, riesgos evaluados con criterios propios, controles seleccionados con base en esos riesgos, y evidencia de que el sistema funciona y mejora. No prescribe cuántas políticas debes tener ni qué herramientas usar.
En una startup, tres condiciones moldean el diseño del SGSI:
- Pocas personas con muchos sombreros. El CTO también administra la nube, el fundador firma contratos y revisa accesos, y el líder de operaciones lleva recursos humanos. El SGSI debe asignar roles sin crear conflictos de interés críticos.
- Infraestructura 100 % en la nube y herramientas SaaS. No hay centro de datos propio, pero sí decenas de servicios de terceros: proveedor de nube, identidad, correo, repositorio, CI/CD, monitoreo, soporte y pagos. La gestión de proveedores (Anexo A 5.19 a 5.23) pesa más que la seguridad física.
- Cambio constante. El producto, el equipo y los procesos cambian cada trimestre. El SGSI debe estar diseñado para actualizarse, no para congelarse. El §6.3 de la edición 2022 pide planificar los cambios del sistema de gestión.
Si tu empresa ya tiene más de 50 personas o varias líneas de producto, nuestra guía de ISO 27001 para empresas de software profundiza en el ciclo de desarrollo seguro y en los controles 8.25 a 8.34.
Marco normativo y regulatorio aplicable
La norma certificable es ISO/IEC 27001:2022, con su Enmienda 1:2024 sobre cambio climático en §4.1 y §4.2. La guía de implementación de los 93 controles del Anexo A está en ISO/IEC 27002:2022. El periodo de transición desde la edición 2013 concluyó el 31 de octubre de 2025, de modo que cualquier certificación nueva o vigente debe estar emitida contra la edición 2022.
| Referencia | Qué aporta | Cuándo te importa |
|---|---|---|
| ISO/IEC 27001:2022 + Amd 1:2024 | Requisitos del SGSI y Anexo A | Siempre; es la norma certificable |
| ISO/IEC 27002:2022 | Guía de implementación de cada control | Al diseñar y documentar controles |
| ISO/IEC 27017:2015 | Controles para servicios en la nube | Si tus clientes preguntan por seguridad de nube |
| ISO/IEC 27018:2025 | Protección de datos personales en nube pública como encargado | Si procesas datos personales de los clientes de tus clientes |
| ISO/IEC 27006-1:2024 | Reglas para organismos certificadores, incluido el cálculo de días de auditoría | Para entender la duración y costo de la auditoría |
| Ley Federal de Protección de Datos Personales en Posesión de los Particulares (DOF 20-03-2025) | Deber de seguridad, avisos de privacidad y relación responsable–encargado | Siempre que trates datos personales en México |
Requisito normativo: la proporcionalidad está en la propia norma
ISO/IEC 27001:2022 §7.5.1 indica que la extensión de la información documentada puede variar según el tamaño de la organización, la complejidad de sus procesos y la competencia de las personas. Esto no exime de los documentos que la norma exige expresamente, pero sí justifica un SGSI ligero, con pocos procedimientos bien escritos y mucha evidencia generada por las propias herramientas.
En protección de datos, la ley publicada en el DOF el 20 de marzo de 2025 abrogó la de 2010 y trasladó la vigilancia a la Secretaría Anticorrupción y Buen Gobierno. Si tu plataforma trata datos personales por cuenta de tus clientes, eres encargado y tus contratos deben reflejarlo. El control 5.34 (privacidad y protección de información de identificación personal) conecta ese requisito legal con tu SGSI.
Cómo definir un alcance lean sin perder valor comercial
El alcance (§4.3) determina el esfuerzo, la duración de la auditoría y el valor del certificado frente a tus clientes. En una startup, la recomendación casi universal es certificar la plataforma que vendes y los procesos que la sostienen: desarrollo, operación en nube, soporte, gestión de personal y proveedores.
Ejemplo de alcance para una startup SaaS
"El SGSI aplica al desarrollo, operación y soporte de la plataforma SaaS de gestión de inventarios para comercio minorista, incluyendo la gestión de personal, proveedores de nube y servicios de terceros, operado mediante trabajo remoto desde México, conforme a la Declaración de Aplicabilidad vigente."
Evita dos errores comunes. El primero, excluir procesos de los que depende el producto (por ejemplo, dejar fuera soporte cuando tu equipo de soporte accede a datos de clientes). El segundo, incluir proyectos experimentales o líneas de negocio que aún no venden y que multiplican el trabajo sin valor comercial inmediato. Documenta las interfaces y dependencias (§4.3 c): proveedor de nube, proveedor de identidad, repositorio de código y herramientas de comunicación.
Documentos obligatorios y evidencia que pide el auditor
Una startup no necesita decenas de procedimientos. Necesita los documentos que la norma exige, una Declaración de Aplicabilidad (SoA) sólida y evidencia consistente. Esta tabla resume lo indispensable:
| Requisito | Qué verifica el auditor | Evidencia lean aceptable |
|---|---|---|
| §4.3 Alcance | Alcance documentado con interfaces | Documento de una página con alcance, exclusiones y dependencias |
| §5.2 Política de seguridad | Aprobada, comunicada y con compromisos | Política de dos páginas firmada por el CEO y aceptada por el personal |
| §5.3 Roles | Responsabilidades asignadas | Matriz RACI del SGSI con nombres |
| §6.1.2 Proceso de apreciación de riesgos | Criterios de aceptación y método | Metodología breve con escala de probabilidad e impacto aprobada |
| §6.1.3 Tratamiento y SoA | 93 controles evaluados con justificación | SoA en hoja de cálculo o herramienta, con estado real de cada control |
| §6.2 Objetivos | Objetivos medibles con plan | 3 a 5 objetivos con indicador, meta y responsable |
| §7.2 Competencia | Evidencia de competencia | Constancias de capacitación en seguridad, registro de inducción |
| §7.3 Concientización | Personal conoce la política y su papel | Capacitación anual registrada y simulaciones de phishing |
| §8.1 Control operacional | Procesos ejecutados como se planificó | Tickets, pull requests aprobados, registros de cambios |
| §8.2 / §8.3 Resultados de riesgos | Apreciación ejecutada y plan aplicado | Matriz de riesgos con fecha, dueños y estado del plan de tratamiento |
| §9.1 Seguimiento y medición | Resultados registrados | Tablero mensual de indicadores |
| §9.2 Auditoría interna | Programa y resultados | Programa anual e informe de auditoría con hallazgos |
| §9.3 Revisión por la dirección | Decisiones de la dirección | Acta con entradas requeridas y acuerdos |
| §10.2 No conformidades | Tratamiento y causa raíz | Registro de no conformidades con acción correctiva |
A estos se suman los documentos que exigen ciertos controles del Anexo A cuando son aplicables, como el inventario de activos (5.9), las reglas de uso aceptable (5.10), el plan de respuesta a incidentes (5.24 a 5.26) y los procedimientos operativos documentados (5.37). La clave es que cada documento tenga dueño, versión y fecha de revisión.
Controles del Anexo A que más pesan en una startup SaaS
De los 93 controles, estos concentran la mayor parte del trabajo técnico en un equipo pequeño que opera en la nube:
| Control | Tema (paráfrasis) | Implementación lean |
|---|---|---|
| 5.9 | Inventario de activos | Exportación periódica de consolas de nube, proveedor de identidad y listado de servicios SaaS |
| 5.15 a 5.18 | Control de acceso, identidades, autenticación y derechos | Inicio de sesión único, altas y bajas ligadas a una lista de verificación de RR. HH. |
| 5.19 a 5.23 | Proveedores y servicios en la nube | Registro de proveedores críticos con sus certificados o informes vigentes y matriz de responsabilidad compartida |
| 5.24 a 5.28 | Gestión de incidentes | Plan de respuesta de pocas páginas, canal de reporte y simulacro anual |
| 5.30 | Preparación de las TIC para la continuidad | Objetivos de recuperación definidos y prueba de restauración |
| 6.3 | Concientización y capacitación | Inducción de seguridad y refuerzo anual |
| 6.7 | Trabajo remoto | Reglas para equipos personales o corporativos, cifrado de disco y bloqueo de pantalla |
| 8.1 | Dispositivos de usuario final | Gestión de dispositivos (MDM) con cifrado y parches |
| 8.2 y 8.5 | Acceso privilegiado y autenticación segura | Factor múltiple obligatorio; acceso administrativo restringido y revisado |
| 8.8 | Vulnerabilidades técnicas | Escaneo de dependencias y de infraestructura con plazos de remediación |
| 8.13 | Respaldos | Respaldos automáticos con prueba de restauración documentada |
| 8.15 y 8.16 | Registro y monitoreo | Bitácoras centralizadas y alertas con responsable |
| 8.25 a 8.32 | Desarrollo seguro y cambios | Revisión obligatoria de código, análisis automático en el pipeline, ambientes separados |
Consejo de auditor: deja que tus herramientas generen la evidencia
En una startup, la mejor evidencia es la que ya producen tus sistemas: historial de pull requests, bitácoras de despliegue, registros del proveedor de identidad y reportes de escaneo. Diseña los controles para que la evidencia quede guardada automáticamente y define quién la revisa y con qué frecuencia. Las plataformas de automatización de cumplimiento pueden ayudar, pero no sustituyen las decisiones de riesgo ni la revisión humana.
Ruta de implementación para un equipo de 10 a 50 personas
- Diagnóstico de brechas. Revisa tu operación actual contra las cláusulas 4 a 10 y los 93 controles. En empresas nativas de la nube, muchos controles técnicos ya existen parcialmente; la brecha suele estar en la gestión: riesgos, SoA, auditoría interna y revisión por la dirección.
- Alcance, contexto y roles. Define el alcance desde el producto, documenta partes interesadas (clientes enterprise, inversionistas, autoridades) y asigna roles. Un responsable del SGSI con tiempo parcial dedicado es suficiente si tiene respaldo de la dirección.
- Metodología y apreciación de riesgos. Escenarios reales de tu operación, criterios de aceptación aprobados por los fundadores y dueños de riesgo identificados.
- SoA y plan de tratamiento. Evalúa los 93 controles, justifica cada exclusión y registra el estado real. Prioriza el plan por riesgo, no por facilidad.
- Implementación de controles críticos. Identidad centralizada con factor múltiple, gestión de dispositivos, respaldos con prueba de restauración, escaneos de vulnerabilidades y bitácoras.
- Políticas y procedimientos mínimos. Política de seguridad, uso aceptable, control de acceso, respuesta a incidentes, gestión de proveedores, desarrollo seguro y continuidad. Breves, claros y aceptados por el personal.
- Operación con evidencia. Opera el sistema al menos durante algunas semanas generando registros: revisiones de accesos, capacitación, incidentes, cambios.
- Auditoría interna y revisión por la dirección. Auditor independiente del responsable del SGSI, informe con hallazgos y acta de revisión con decisiones.
- Auditoría de certificación. Elige un organismo acreditado; la etapa 1 revisa diseño y preparación, la etapa 2 verifica implementación y eficacia.
Ejemplo resuelto: SGSI de una startup SaaS de 22 personas
Ejemplo aplicado: "Inventa Cloud", 22 personas, Ciudad de México
Contexto. Startup ficticia con una plataforma SaaS de gestión de inventarios para minoristas. 12 ingenieros, 4 en soporte, 3 en ventas y 3 en administración. Infraestructura en un proveedor de nube pública, 30 servicios SaaS de terceros y datos de 180 clientes, incluidos datos personales de empleados de esos clientes. Un prospecto de cadena comercial exige certificado ISO/IEC 27001:2022 para firmar.
Asignación de roles sin conflicto de interés.
| Rol del SGSI | Persona | Control de conflicto |
|---|---|---|
| Dueño del SGSI y aprobación de riesgos | CEO | Aprueba, no ejecuta controles técnicos |
| Responsable del SGSI | Líder de operaciones (20 % de su tiempo) | No audita su propio trabajo |
| Dueño de controles técnicos | CTO | Accesos privilegiados revisados por el CEO |
| Auditor interno | Auditor externo contratado | Independencia frente al responsable del SGSI |
Apreciación de riesgos (extracto). Criterios: Probabilidad (P) e Impacto (I) de 1 a 5; nivel = P × I; aceptable ≤ 6; tratamiento obligatorio ≥ 12.
| Escenario | P | I | Nivel | Tratamiento | Residual |
|---|---|---|---|---|---|
| Robo de laptop de un ingeniero con acceso a producción | 3 | 4 | 12 | Cifrado de disco y MDM (8.1), factor múltiple (8.5), acceso a producción solo mediante sesiones temporales (8.2) | 1 × 4 = 4 |
| Exempleado conserva acceso a herramientas SaaS | 4 | 4 | 16 | Inicio de sesión único en todas las herramientas críticas (5.16), lista de verificación de baja (5.18, 6.5) | 1 × 4 = 4 |
| Pérdida de datos por borrado accidental en producción | 2 | 5 | 10 | Respaldos automáticos con restauración probada (8.13), permisos de borrado restringidos (8.2) | 1 × 5 = 5 |
| Proveedor SaaS crítico sufre una brecha | 3 | 3 | 9 | Evaluación de proveedores y cláusulas contractuales (5.19, 5.20); minimización de datos compartidos | 2 × 3 = 6 |
Resultado. SoA con 86 controles aplicables y 7 exclusiones justificadas, principalmente controles físicos de instalaciones propias que no existen porque la operación es remota y la infraestructura está en la nube (la parte física se cubre con evidencia del proveedor y con 7.9 para equipos fuera de las instalaciones). Documentación total: 12 documentos de política y procedimiento, más registros generados por herramientas. Las cifras son ilustrativas: tus criterios y resultados dependerán de tu contexto.
Indicadores mínimos para una startup
El §9.1 pide medir el desempeño del SGSI. En una startup, pocos indicadores bien elegidos valen más que un tablero extenso:
| Indicador | Fórmula | Criterio sugerido (ajústalo) | Control |
|---|---|---|---|
| Cobertura de factor múltiple | Cuentas con MFA ÷ cuentas totales en herramientas críticas | 100 % | 8.5 |
| Bajas oportunas | Accesos revocados ≤ 24 h ÷ bajas | 100 % | 5.18 |
| Dispositivos administrados | Equipos con MDM y cifrado ÷ equipos con acceso a datos | 100 % | 8.1 |
| Remediación de vulnerabilidades críticas | Días promedio de cierre | Definido en tu política | 8.8 |
| Pruebas de restauración | Restauraciones exitosas ÷ probadas | 100 % dentro del objetivo de recuperación | 8.13 |
| Capacitación de seguridad | Personal capacitado en el año ÷ plantilla | 100 % | 6.3 |
Hallazgos típicos en startups y cómo evitarlos
| Hallazgo | Requisito | Corrección y acción correctiva |
|---|---|---|
| Políticas descargadas de una plantilla que describen procesos inexistentes | §7.5, §8.1 | Reescribir con base en la operación real; eliminar lo que no aplica |
| SoA con controles marcados como implementados sin evidencia | §6.1.3 d) | Ajustar estado real y completar el plan de tratamiento |
| Cuentas de exempleados activas en herramientas SaaS fuera del inicio de sesión único | Anexo A 5.18 | Inventario de herramientas, integración al proveedor de identidad y revisión mensual |
| El responsable del SGSI audita su propio trabajo | §9.2.2 | Auditor interno independiente o externo |
| Respaldos configurados pero nunca restaurados | Anexo A 8.13 | Prueba de restauración programada y registrada |
| Revisión por la dirección sin decisiones ni recursos | §9.3 | Acta con acuerdos, responsables y fechas |
| Proveedores críticos sin evaluación | Anexo A 5.19, 5.20, 5.23 | Registro de proveedores con certificados vigentes y requisitos contractuales |
| Ningún incidente registrado en meses | Anexo A 5.24 a 5.26 | Promover el reporte, definir qué es un evento y registrar incluso los menores |
"Cero incidentes" no es una buena noticia para el auditor
Una empresa con decenas de servicios en la nube y personal remoto tiene eventos de seguridad todos los meses: correos de phishing, alertas de inicio de sesión, vulnerabilidades en dependencias. Un registro vacío suele indicar que el proceso de reporte no funciona. Define qué es un evento, qué es un incidente y registra ambos.
Checklist de preparación para la certificación
- Alcance redactado desde el producto con interfaces y dependencias (§4.3).
- Contexto y partes interesadas documentados, incluido el cambio climático (§4.1, §4.2).
- Política aprobada por la dirección y aceptada por todo el personal (§5.2).
- Roles asignados sin conflictos críticos de interés (§5.3).
- Metodología de riesgos aprobada y apreciación completa con dueños (§6.1.2, §8.2).
- SoA con 93 controles evaluados y estado real (§6.1.3 d).
- Objetivos medibles con seguimiento (§6.2).
- Inicio de sesión único y factor múltiple en herramientas críticas (5.16, 8.5).
- Dispositivos administrados y cifrados (8.1).
- Proveedores críticos evaluados con matriz de responsabilidad compartida (5.19 a 5.23).
- Plan de respuesta a incidentes ensayado (5.24 a 5.28).
- Respaldos con prueba de restauración (8.13).
- Avisos de privacidad y contratos de encargado alineados a la LFPDPPP de 2025 (5.34).
- Auditoría interna independiente y revisión por la dirección completadas (§9.2, §9.3).
Si tus clientes en Estados Unidos te piden SOC 2 en lugar de ISO 27001, revisa nuestra comparación ISO 27001 vs SOC 2; si operas en servicios financieros, la guía de ISO 27001 para Fintech. Más contexto en la página de ISO 27001 y en la de tecnología, SaaS y Fintech.
Cómo lo abordamos en Quality College
Para startups y SaaS empezamos con un diagnóstico de brechas que revisa tu nube, tu proveedor de identidad, tus herramientas y tus contratos contra ISO/IEC 27001:2022, y diseñamos un SGSI proporcional a tu tamaño: pocos documentos, mucha evidencia automatizada y roles claros. Acompañamos la implementación de controles, ejecutamos la auditoría interna con independencia 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.
Qualitix Bot®, nuestra IA para documentación, genera borradores de políticas, metodología de riesgos y SoA a partir de tu contexto real, siempre revisados por un consultor; e ISO Track®, nuestro SaaS, centraliza riesgos, auditorías, acciones correctivas e indicadores. Hemos acompañado a más de 150 organizaciones en su certificación desde 2018 y ofrecemos garantía contractual de certificación.