← Volver al blog Sistemas de gestión

Qué es ISO 27001 y cómo implementar un SGSI real [2026]

ISO/IEC 27001 es la norma internacional que define los requisitos de un sistema de gestión de seguridad de la información (SGSI): la estructura con la que una organización decide qué información proteger, de qué la protege, quién responde por ella y cómo comprueba que los controles funcionan. La versión vigente es la de 2022, y su Anexo A trae 93 controles agrupados en cuatro temas.

Esta guía responde lo que casi nunca se responde: cuándo un SGSI vale la pena y cuándo es puro papel, qué documentos exige la norma de verdad frente a los que se venden como obligatorios, cuánto pesa el proyecto medido en documentos —no en meses de promesa— y los ocho errores que hacen que un sistema llegue a la auditoría sin evidencia.

Qué es ISO 27001 y qué no es

Un SGSI no es una lista de medidas técnicas. Es un sistema de decisiones: qué activos de información sostienen el negocio, qué riesgos pesan sobre ellos, qué nivel de riesgo la dirección acepta vivir, qué controles se aplican en consecuencia y cómo se demuestra —con registros, no con opiniones— que esos controles operan.

La confusión más cara del tema es tratar como sinónimos cuatro cosas distintas:

Y lo que no es: no es un antivirus corporativo, no es una prueba de penetración, no es un proyecto del área de sistemas. La mitad larga de los 93 controles del Anexo A no la ejecuta TI: la ejecutan recursos humanos, compras, jurídico, instalaciones y la propia dirección. Un SGSI delegado por completo al área de sistemas nace con la mitad del alcance fuera de su control.

Cuándo vale la pena y cuándo es puro papel

Hay empresas para las que implantar un SGSI completo es, hoy, una mala inversión. Distinguir el caso antes de arrancar ahorra meses de trabajo y una discusión incómoda a la mitad del proyecto.

Cinco señales de que sí lo necesitas

1. Te lo empezaron a pedir por escrito. Cuestionarios de seguridad de clientes corporativos, cláusulas contractuales de confidencialidad con auditoría, licitaciones que exigen certificado. Aquí el SGSI deja de ser mejora interna y pasa a ser acceso a mercado; el cálculo es directo: cuánto vale el contrato al que hoy no puedes entrar.
2. Custodias información de terceros. Si operas datos personales de los clientes de tus clientes, o su información financiera, el riesgo ya no es tuyo solamente: es contractual y es legal.
3. Nadie sabe quién tiene acceso a qué. Si no puedes producir en una hora la lista de quién tiene acceso a tu sistema crítico, no tienes un problema de herramientas, tienes un problema de gestión.
4. Ya tuviste un incidente y se resolvió a mano. Se apagó el fuego, nadie escribió qué pasó, nadie cambió nada. El siguiente idéntico cuesta lo mismo.
5. Creciste más rápido de lo que documentaste. Accesos heredados de gente que ya no está, servidores que nadie reclama, proveedores conectados por una integración que montó alguien que se fue.

Cuatro señales de que todavía no

1. Lo quieres solo por el logotipo. El certificado se emite con vigencia de tres años y trae auditorías de seguimiento anuales. Un sistema que nadie opera se cae en la primera.
2. La dirección no piensa aceptar riesgos por escrito. La aceptación del riesgo residual es una firma de dirección, no un trámite del consultor. Si nadie va a firmar, no hay sistema.
3. No hay quién lo mantenga. Un SGSI vivo consume tiempo cada mes: revisión de accesos, gestión de incidentes, seguimiento de proveedores, indicadores. Sin un responsable con tiempo asignado, muere.
4. Tu problema es concreto y acotado. Si lo que te preocupa es una aplicación específica, empieza por asegurarla y por gestionar el riesgo de ese servicio. Montar la estructura completa para un solo sistema es sobreingeniería cara.

Cómo está armada la norma: cláusulas 4 a 10

ISO/IEC 27001 sigue la estructura de alto nivel común a las normas de sistemas de gestión, la misma de ISO 9001 y de ISO/IEC 42001. Los requisitos auditables están en las cláusulas 4 a 10; las tres primeras son objeto, referencias y términos. Aquí se citan por número y se parafrasean: el texto de la norma tiene derechos de autor y se adquiere a través de un organismo de normalización.

• 4. Contexto de la organización. Qué asuntos internos y externos afectan a la seguridad, quiénes son las partes interesadas y qué esperan, y —lo que más se subestima— la definición del alcance del SGSI.
• 5. Liderazgo. Compromiso de la dirección, la política de seguridad de la información y la asignación de roles y responsabilidades. No es retórica: si la dirección no aparece en la evidencia, el auditor lo ve en dos preguntas.
• 6. Planificación. El corazón de la norma: el proceso de apreciación del riesgo (6.1.2), el tratamiento del riesgo (6.1.3) —del que sale la declaración de aplicabilidad—, y los objetivos de seguridad (6.2). La versión 2022 añadió además la planificación de los cambios.
• 7. Apoyo. Recursos, competencia, toma de conciencia, comunicación e información documentada. Aquí vive la evidencia de que la gente sabe lo que le toca.
• 8. Operación. Ejecutar lo planeado, y volver a apreciar y tratar los riesgos cuando algo cambia. Los resultados de esas apreciaciones son información documentada.
• 9. Evaluación del desempeño. Seguimiento y medición, auditoría interna (9.2) y revisión por la dirección (9.3).
• 10. Mejora. No conformidades, acciones correctivas y mejora continua. En 2022 el orden de la cláusula cambió: la mejora continua va primero.

Conviene saberlo antes de comprar plantillas: si un paquete está armado sobre la estructura de ISO/IEC 27001:2013, trae 114 controles en 14 dominios y una numeración del Anexo A que ya no existe. La transición a la versión 2022 cerró el 31 de octubre de 2025; un certificado sobre la versión anterior ya no está vigente. Qué documentos pide hoy un SGSI y cómo armarlos está en plantillas ISO 27001.

Los 93 controles del Anexo A, en cuatro temas

El Anexo A de la versión 2022 pasó de 14 dominios a cuatro temas y de 114 controles a 93, de los cuales 11 son nuevos. La guía de implantación de cada uno vive en ISO/IEC 27002:2022, que es la norma hermana y la que de verdad se lee para trabajar.

Los once controles nuevos de 2022 son los que más trabajo dan porque casi nadie los tenía: inteligencia de amenazas, seguridad para el uso de servicios en la nube, preparación de las TIC para la continuidad del negocio, monitoreo de la seguridad física, gestión de la configuración, borrado de información, enmascaramiento de datos, prevención de fuga de datos, actividades de monitoreo, filtrado web y codificación segura.

Dos advertencias que ahorran discusiones con el auditor:

• Los controles del Anexo A no son un menú obligatorio. Salen del tratamiento del riesgo. Si un control no aplica a tu contexto, se excluye y se justifica por escrito. Lo que no se puede es ignorarlo sin decir por qué.
• El Anexo A tampoco es un techo. Si tu apreciación de riesgos exige un control que no está en la lista, se implanta igual. La norma pide comparar contra el Anexo A para no olvidar nada, no para limitarse a él.

Qué documentos exige de verdad

Esta es la sección que más dinero ahorra, porque el mito de ISO 27001 es «hay que documentarlo todo». La norma exige mantener como información documentada una lista concreta, y es más corta de lo que se vende:

Ningún «manual de seguridad» aparece en esa lista. Tampoco un procedimiento documentado por cada control del Anexo A. La cláusula 7.5.1 deja explícitamente en manos de la organización decidir qué más documentar para que el sistema sea eficaz, y ahí es donde entra el criterio: se documenta lo que, sin documento, se ejecuta distinto cada vez o no deja rastro.

La trampa está en la palabra evidencia. La mayoría de los controles del Anexo A no se demuestran con un procedimiento: se demuestran con un registro. La revisión trimestral de accesos no se prueba enseñando la política de control de acceso, se prueba enseñando las cuatro revisiones firmadas del año con los accesos que se retiraron. Es la diferencia entre un sistema documentado y un sistema operando, y es lo primero que busca un auditor experimentado.

Cuánto pesa el proyecto, medido en documentos

Los plazos que se publican son los del mejor caso y no dicen nada del esfuerzo. Un número mejor es el volumen documental del sistema terminado. En el SGSI ISO/IEC 27001:2022 completo que implantamos en una empresa de software, el sistema quedó en 34 políticas, 25 procedimientos y 46 formatos: 105 piezas documentales para cubrir la totalidad de los controles aplicables.

Ese número sirve para tres cosas, y conviene usarlo antes de firmar nada:

• Dimensionar. Un proyecto de ese tamaño no lo sostiene alguien «en sus ratos libres». Si nadie tiene tiempo asignado, el calendario que te presenten es ficción.
• Detectar el inflado. Si te proponen varios cientos de documentos para un alcance de un servicio y un sitio, la pregunta correcta es qué control exige cada uno. Cada documento de más es revisión, aprobación, versionado y auditoría para siempre.
• Comparar con calidad. Es un sistema bastante más documental que un ISO 9001 de una línea de servicio, que se resuelve con 10 a 15 procedimientos. Si alguien te propone el volumen de un 27001 para un 9001, algo no cuadra. Lo comparamos a fondo en la guía del sistema de gestión de calidad.

Los plazos concretos dependen tanto del alcance, del tamaño y de la disponibilidad de los dueños de proceso que publicar un rango sin contexto sería inventarlo. [DATO A CONFIRMAR CON FER] — duración media de las implantaciones 27001 de Softgrade y horas de dedicación del responsable interno.

La declaración de aplicabilidad, el documento que más se equivoca

La declaración de aplicabilidad (SoA, por Statement of Applicability) es el documento que exige la cláusula 6.1.3 y el que el auditor abre primero. Para cada uno de los 93 controles del Anexo A tiene que decir cuatro cosas:

1. Si aplica o no.
2. Por qué. La justificación de la inclusión —qué riesgo trata— o de la exclusión.
3. Si ya está implantado, y en qué estado.
4. Cómo. La referencia al documento, al sistema o al registro que lo evidencia.

Los tres defectos que se repiten: marcar los 93 como aplicables «para no tener que justificar nada» —con lo que te obligas a evidenciarlos todos—; excluir controles con una justificación circular («no aplica porque no lo hacemos»); y dejar la columna de evidencia apuntando a un documento que no existe todavía. La SoA es, en la práctica, el índice del sistema: si está bien hecha, el resto del proyecto ya está planificado.

Cómo implementarlo en 7 fases

Fase 1 — Diagnóstico de brecha

Antes de escribir una sola política, medir qué hay. Se recorre cada cláusula y cada control aplicable y se marca qué existe, qué existe a medias y qué no existe. El entregable es una lista priorizada de brechas con dueño, no un informe de trescientas páginas. Sin esta fase se documenta a ciegas y se rehace todo dos veces.

Fase 2 — Alcance, contexto y política

Delimitar qué servicios, sitios, sistemas y personas entran. Es la decisión más subestimada del proyecto: cada sitio y cada línea de servicio que se agrega multiplica el trabajo de evidencia y el costo de la auditoría. Un alcance honesto y acotado vale más que uno amplio y falso, que se cae en la primera visita.

Fase 3 — Inventario de activos y apreciación de riesgos

No hay riesgo sin activo. Se levanta qué información existe, dónde vive, quién la usa y quién responde por ella; después se identifican escenarios de riesgo y se valoran con una escala definida antes de valorar, no ajustada después para que el resultado quede bonito.

Fase 4 — Tratamiento, SoA y plan

Por cada riesgo relevante, una decisión: mitigar, transferir, evitar o aceptar. De ahí salen los controles, y de los controles la declaración de aplicabilidad y el plan de tratamiento con fechas y responsables. El riesgo residual lo acepta la dirección por escrito.

Fase 5 — Documentar e implantar

Se escriben las políticas y procedimientos que los controles exigen y se ponen a operar. La regla de orden: primero lo que genera evidencia recurrente (accesos, respaldos, incidentes, proveedores), porque es lo que necesita tiempo acumulado antes de la auditoría.

Fase 6 — Operar, formar y generar evidencia

El sistema tiene que haber funcionado para poder auditarse. Un ciclo completo de gestión de incidentes, revisiones de acceso, pruebas de restauración de respaldos, formación registrada e indicadores medidos. Esta fase no se comprime: es tiempo de calendario, no de esfuerzo.

Fase 7 — Auditoría interna, revisión por la dirección y certificación

Se audita el sistema contra la norma y contra sí mismo, se levantan hallazgos y se corrigen; la dirección revisa desempeño, riesgos y recursos, y decide. La auditoría de certificación se realiza en dos etapas —revisión documental y auditoría en sitio— y el certificado se emite con vigencia de tres años, con seguimientos anuales. Quien certifica es un organismo de certificación acreditado bajo ISO/IEC 17021-1, independiente de quien te ayudó a implantar: esa separación es un requisito de imparcialidad, no una preferencia comercial. Si quieres ensayarla antes, el mecanismo es la auditoría interna.

8 errores que hacen fracasar un SGSI

1. Empezar por los controles y no por el riesgo. Se compra un paquete de 93 controles y se implanta de arriba abajo. El resultado es un sistema que no puede explicar por qué hace lo que hace, y el auditor pregunta exactamente eso.
2. Un alcance ancho para que se vea mejor. Incluir toda la empresa cuando solo un servicio tiene los controles operando duplica el trabajo y garantiza hallazgos en las áreas que nadie preparó.
3. Copiar las políticas de otra empresa. Se nota de inmediato: códigos ajenos en los pies de página, áreas que no existen, sistemas que no se usan. Además del ridículo, el sistema no describe tu operación.
4. Tratarlo como un proyecto de TI. Recursos humanos, compras y jurídico ejecutan una parte grande del Anexo A. Si no están en el proyecto desde el inicio, esos controles llegan vacíos a la auditoría.
5. Documentar sin generar registros. La política de respaldos aprobada no prueba nada; la prueba es el registro de restauraciones probadas. Es el hallazgo más común en una primera auditoría.
6. Valorar riesgos con números inventados. Una escala sin criterios definidos produce un mapa de calor decorativo. Si no puedes explicar por qué un riesgo es 4 y no 3, no tienes una apreciación: tienes una opinión con formato de tabla.
7. Olvidar a los proveedores. El acceso de un tercero es acceso. Sin inventario de proveedores, cláusulas de seguridad y revisión periódica, tu SGSI termina donde empieza el contrato de alguien más.
8. No decidir quién lo mantiene después del certificado. El proyecto termina, el consultor se va y el sistema queda sin dueño. Dieciocho meses después, la auditoría de seguimiento encuentra un sistema congelado en la fecha de certificación.

ISO 27001 frente a 9001, 42001 y un pentest

Cuatro cosas que se mezclan en la misma conversación y resuelven problemas distintos:

• ISO 9001 gestiona la calidad: que el producto o servicio salga igual sin importar quién lo haga. Comparte con 27001 la estructura de cláusulas 4 a 10, así que auditoría interna, revisión por la dirección, control documental y acciones correctivas se comparten entre los dos sistemas. Si ya tienes un 9001 operando, arrancas con una parte del trabajo hecha. Lo mismo pasa con un sistema antisoborno ISO 37001.
• ISO/IEC 42001 gestiona la inteligencia artificial: los riesgos hacia las personas y hacia terceros que introduce un sistema de IA. Se monta muy bien encima de un 27001, pero no lo sustituye ni se deduce de él. Lo desarrollamos en la guía de ISO 42001.
• Una prueba de penetración es una medición técnica en un momento dado. Es evidencia útil para varios controles del Anexo A, pero no es un sistema de gestión: no decide alcances, no acepta riesgos y no sobrevive al mes siguiente.
• El cumplimiento de la ley de datos personales es obligatorio y no opcional. Un SGSI te da gran parte de la maquinaria —inventario, clasificación, control de acceso, gestión de incidentes—, pero las obligaciones legales se cumplen por sí mismas, con certificado o sin él.

El riesgo tecnológico que un SGSI trata es solo una parte del riesgo tecnológico total de la empresa: la obsolescencia, la dependencia de un proveedor único o un ERP mal elegido no aparecen en el Anexo A y hunden igual. Ese panorama completo está en la guía de gestión de riesgos tecnológicos.

Ejemplo: el diagnóstico de brecha de una empresa de servicios

Para aterrizar la fase 1, así se ve un diagnóstico de brecha real. En 2026 entregamos uno a una empresa de servicios, levantado con 26 cuestionarios por área: no una entrevista con el director de sistemas, sino un cuestionario por cada área que toca información, respondido por quien de verdad ejecuta el control.

Un diagnóstico así se hace en semanas, no en meses, y cambia por completo la conversación con la dirección: en vez de «hay que certificarse», la pregunta pasa a ser «tenemos estas brechas, en estas áreas, y estas cinco son las que nos dejan sin operar si salen mal». Es también el punto donde muchas empresas descubren que lo que necesitan no es un certificado todavía, sino cerrar seis huecos concretos.

Preguntas frecuentes

Conclusión

ISO 27001 sirve cuando la empresa ya tiene el problema que resuelve: información de terceros bajo custodia, clientes que auditan, accesos que nadie controla o un incidente que se apagó sin aprender nada. Cuando se monta por el logotipo, produce una carpeta cara y un hallazgo en la primera auditoría de seguimiento.

Si vas a arrancar, tres decisiones ordenan el resto: acota el alcance más de lo que te dé confianza, trabaja desde el riesgo hacia los controles y no al revés, y ponle nombre y apellido al responsable de mantenerlo antes de escribir la primera política. Las tres se toman en la primera semana y determinan si el sistema sigue vivo en dos años.