El SoA es el documento que decide si la auditoría va bien o mal

La mayoría de los retrasos en una certificación ISO 27001 no vienen de un control mal implementado — vienen de un Statement of Applicability (SoA) copiado de una plantilla genérica, con los 93 controles del Anexo A marcados como "aplicable" sin justificación real. El auditor lo detecta en los primeros veinte minutos de la Etapa 1, y a partir de ahí cada control que revisa lo hace con más desconfianza.

El SoA no es un checklist. Es el documento que conecta tu análisis de riesgos con cada control: por qué se incluyó, cómo se implementó, y qué evidencia lo respalda. Si el ISMS Manager no puede explicar en una frase por qué A.8.10 (eliminación de información) aplica o no aplica a la organización, ese control no está listo para auditoría, esté marcado como aplicable o no.

Las siete fases, en el orden que realmente importa

1. Definición del alcance

El error más caro de corregir tarde. Un alcance demasiado amplio ("toda la organización") obliga a implementar controles en áreas que no lo necesitan y multiplica el trabajo de evidencia. Un alcance demasiado estrecho deja fuera sistemas que el cliente va a preguntar por escrito en el próximo cuestionario de seguridad. El alcance se define por: ubicaciones físicas, activos de información, tecnología, y — en SaaS — los servicios que efectivamente procesan datos de clientes.

2. Metodología de análisis de riesgos

ISO 27001 no exige una metodología específica, pero sí exige que sea repetible y documentada. La referencia más usada es ISO 27005, con una matriz de probabilidad × impacto y un umbral de riesgo aceptable definido por la dirección, no por el equipo técnico. Este es el punto donde muchos ISMS Manager se quedan cortos: el análisis de riesgos debe tener fecha de revisión y dueño por cada riesgo identificado, no ser un documento estático que se genera una vez y no se vuelve a tocar.

3. El SoA como consecuencia del análisis de riesgos

Cada control del Anexo A se marca aplicable o no aplicable en función de los riesgos identificados en la fase anterior , no al revés. Si un control aparece marcado como aplicable sin un riesgo que lo justifique, es una señal de que se llenó la plantilla sin pasar por el análisis real.

4. Implementación y documentación obligatoria

ISO 27001:2022 exige un conjunto mínimo de documentos que el auditor pide explícitamente:

  • Política de seguridad de la información, aprobada por la dirección.
  • Procedimiento de gestión de riesgos.
  • El SoA con su justificación.
  • Registros de formación y concienciación del personal.
  • Procedimiento de gestión de incidentes, con registro de incidentes reales (aunque sean menores).

La parte que más se subestima: los registros. No basta con tener el procedimiento de gestión de incidentes — el auditor pide ver incidentes reales gestionados según ese procedimiento. Si en los últimos seis meses no hubo ningún incidente registrado, eso en sí mismo genera preguntas.

5. Auditoría interna

Obligatoria antes de la certificación, y con una condición que se pasa por alto con frecuencia: quien la realiza no puede haber participado en la implementación del control que audita. En equipos pequeños esto obliga a traer un auditor interno externo al equipo de seguridad, o contratar el servicio.

La auditoría interna debe generar no conformidades reales. Un informe de auditoría interna sin ningún hallazgo es, para un auditor de certificación experimentado, una señal de que la auditoría no fue rigurosa — no de que todo esté perfecto.

6. Revisión por la dirección

La dirección tiene que revisar el desempeño del SGSI con datos concretos: resultados de la auditoría interna, estado de los riesgos, incidentes del período, y recursos necesarios. Esta reunión debe quedar documentada con fecha, asistentes y decisiones tomadas — es uno de los primeros documentos que pide un auditor de certificación.

7. Auditoría de certificación: Etapa 1 y Etapa 2

La Etapa 1 es documental: el auditor revisa que el SGSI esté diseñado correctamente (alcance, SoA, política, análisis de riesgos) antes de ir a ver la implementación real. Las no conformidades de Etapa 1 casi siempre son de diseño — un SoA sin justificación, un alcance ambiguo — y se corrigen antes de pasar a Etapa 2.

La Etapa 2 evalúa la implementación real: entrevistas al personal, revisión de registros, muestreo de controles operando en producción. Aquí es donde se nota si la Fase 4 (documentación) se hizo con evidencia real o solo con documentos de intención.

No conformidades: mayor vs. menor cambia el cronograma

Una no conformidad menor no bloquea la certificación — se documenta un plan de acción con plazo, y se verifica en la siguiente auditoría de seguimiento. Una no conformidad mayor sí bloquea: implica que un control no está funcionando en absoluto, o que hay un incumplimiento sistemático. El certificado no se emite hasta que el auditor verifica el cierre, lo que puede añadir semanas al proceso.

Cronograma realista

Para una organización SaaS de tamaño medio que empieza desde cero, sin SGSI previo:

  • Definición de alcance + análisis de riesgos: 4-6 semanas.
  • Implementación de controles y documentación: 3-4 meses (la fase más larga, porque requiere generar evidencia operacional real, no solo redactar políticas).
  • Auditoría interna + revisión por la dirección: 2-3 semanas.
  • Etapa 1 + corrección de hallazgos: 2-4 semanas.
  • Etapa 2: 1-2 semanas, más el tiempo de cierre de no conformidades si las hay.

De seis a nueve meses, de principio a fin, es un rango realista — no los "60 días" que a veces prometen consultoras que venden certificaciones exprés basadas en documentación sin evidencia operacional detrás. Esas certificaciones suelen fallar en la primera auditoría de seguimiento, un año después, cuando el auditor pide ver un ciclo completo del sistema funcionando.