La ISO 27001 no le exige a tu infraestructura ninguna marca ni ninguna tecnología en particular. Le exige que puedas demostrar con evidencia que los controles que declaraste existen y que llevan tiempo operando. En la práctica eso se concentra en seis frentes —inventario de activos, cuentas privilegiadas, bitácoras, respaldos probados, gestión de vulnerabilidades y configuración— y el problema casi nunca es implementarlos. El problema es que varios necesitan meses de historial, y el historial no se fabrica la semana antes de la auditoría.
Este artículo está escrito desde el lado de sistemas, no desde el del consultor. Si a ti te va a tocar producir la evidencia, esto es lo que conviene saber antes de que se fije la fecha de la auditoría.
¿Qué hace el consultor y qué te toca a ti?
La norma tiene dos mitades. Las cláusulas 4 a 10 son el sistema de gestión: contexto, liderazgo, objetivos, evaluación de riesgos, auditoría interna, revisión por la dirección. El Anexo A es el catálogo de controles de referencia.
El consultor arma la primera mitad y redacta las políticas. Lo que casi nadie aclara en la junta de arranque es que el documento que sale de ahí —la Declaración de Aplicabilidad— es una lista firmada de promesas que tu infraestructura tiene que cumplir. Cada control que se declara aplicable es trabajo técnico con fecha. Cada control que se excluye hay que justificarlo por escrito ante el auditor.
Pide estar en la mesa cuando se llene la Declaración de Aplicabilidad. Es el momento en que se decide cuánto trabajo te va a tocar, y suele decidirse sin ti.
¿Qué cambió en la versión 2022?
El Anexo A pasó de 114 controles a 93, reorganizados en cuatro temas en lugar de catorce dominios: organizacionales (37), de personas (8), físicos (14) y tecnológicos (34). La mayoría son los mismos de antes, fusionados o renumerados.
Lo que importa para ti son los once controles nuevos, porque son los que nadie tenía implementados y los que más no conformidades generan. Siete caen directo en infraestructura:
- A.5.23 — Seguridad para el uso de servicios en la nube
- A.5.30 — Preparación de las TIC para la continuidad del negocio
- A.8.9 — Gestión de la configuración
- A.8.10 — Borrado de información
- A.8.12 — Prevención de fuga de datos
- A.8.16 — Actividades de seguimiento
- A.8.23 — Filtrado web
Los otros cuatro son inteligencia de amenazas, monitoreo de seguridad física, gestión de información documentada y codificación segura.
Un detalle de calendario que conviene tener claro: el plazo para migrar de la versión 2013 a la 2022 venció el 31 de octubre de 2025, y los certificados emitidos bajo la versión anterior dejaron de ser válidos. Si alguien te comparte un material de preparación organizado en catorce dominios, está trabajando con la norma vieja.
¿Qué controles tocan directamente a la infraestructura?
Esta es la traducción de la norma a lo que un auditor te va a pedir que le enseñes en pantalla. No es la lista completa; son los que en nuestra experiencia detienen más auditorías en empresas medianas.
| Control | Lo que el auditor pide ver |
|---|---|
| A.5.9 Inventario de activos | La lista de servidores, equipos y servicios, con responsable asignado y actualizada. Es lo primero que piden y casi nunca está al día |
| A.8.2 Accesos privilegiados | Quién tiene administrador, con qué cuenta, y el registro de altas y bajas. Las cuentas compartidas son hallazgo garantizado |
| A.8.5 Autenticación segura | Segundo factor en los accesos remotos y en la administración |
| A.8.8 Vulnerabilidades técnicas | No un escaneo: el ciclo. Escaneo, priorización, remediación y reescaneo, con fechas |
| A.8.9 Configuración (nuevo) | Líneas base documentadas por tipo de sistema, y cómo detectas que algo se salió de la línea base |
| A.8.13 Respaldo | El registro de la última restauración probada, con fecha y duración. No el reporte verde del software |
| A.8.15 Registro de eventos | Bitácoras centralizadas, protegidas contra borrado, con retención definida |
| A.8.16 Seguimiento (nuevo) | Que alguien las revise. Con nombre, horario y qué hace cuando salta algo |
| A.8.17 Sincronización de relojes | Fuente de tiempo única para todos los sistemas |
| A.8.22 Segregación de redes | Que las estaciones de trabajo no alcancen la administración de los servidores |
| A.8.32 Gestión de cambios | Registro de cambios a producción: qué, quién, cuándo y quién autorizó |
Si quieres medir en treinta segundos qué tan lejos estás, quédate con A.8.15 y A.8.17. Las bitácoras y la hora son el control aburrido que decide todos los demás: sin registros centralizados y sin una fuente de tiempo común, no puedes probar nada de lo que afirmas en el resto de la lista. Cuando el auditor pregunte quién entró a ese servidor el 12 de marzo, necesitas un registro que exista, que nadie haya podido borrar y cuya hora sea confiable.
¿Qué hay que empezar hoy aunque la auditoría sea en seis meses?
Aquí está la parte que el calendario de certificación suele ignorar. Algunos controles se implementan en una tarde. Otros necesitan historial, y el historial solo se acumula con el reloj corriendo.
| Trabajo | Plazo realista | Por qué tarda |
|---|---|---|
| Inventario de activos | 2 a 4 semanas | Siempre aparece infraestructura que nadie recordaba |
| Centralizar bitácoras y sincronizar relojes | 3 a 6 semanas | Hay que tocar todos los sistemas |
| Líneas base de configuración | 4 a 6 semanas | Se documentan sistema por sistema |
| Copia inmutable y restauración probada | 4 a 8 semanas | Requiere entorno aislado y una ventana real |
| Separar cuentas administrativas y quitar admin local | 2 a 4 meses | Es resistencia organizacional, no trabajo técnico |
| Segmentar la red | 1 a 3 meses | Necesita ventanas de mantenimiento y pruebas |
| Ciclo de vulnerabilidades con historial | 6 meses | El auditor quiere ver varios trimestres, no un escaneo |
El error de secuencia más común: se contrata al consultor con seis meses de margen, se trabaja la documentación durante cuatro, y el trabajo de infraestructura aparece en el mes cinco. Para entonces ya no alcanza, porque tres de las líneas de arriba tardan más que el tiempo que queda. El trabajo técnico empieza antes de que llegue el consultor, no después.
¿Por qué el alcance es tu mejor herramienta?
La cláusula 4.3 dice que la organización define el alcance de su sistema de gestión. Eso significa que ustedes deciden qué queda adentro, y esa decisión determina cuánta infraestructura entra a la auditoría.
Un alcance de “toda la empresa” mete cada servidor, cada sede y cada equipo. Un alcance acotado a la plataforma que el cliente exige y a la infraestructura que la sostiene puede ser una fracción del trabajo, y sigue siendo un certificado válido. La dirección suele inclinarse por el alcance amplio porque suena mejor, sin que nadie le haya puesto número al costo técnico de esa decisión.
Ese número lo tienes tú. Llévalo a la junta donde se define el alcance, y llévalo antes de que se firme el contrato con el organismo certificador.
¿Qué pasa con tu proveedor de TI?
Los controles de la sección A.5.19 a A.5.22 cubren la relación con proveedores, y A.5.23 cubre específicamente los servicios en la nube. Si alguien externo administra tu infraestructura, ese proveedor entra en el alcance: el auditor va a querer ver el contrato, los acuerdos de nivel de servicio, cómo se controla su acceso y qué pasa cuando la relación termina.
Vale la pena preguntarle a tu proveedor, con tiempo, si puede entregarte la evidencia que te van a pedir sobre lo que administra: el registro de accesos privilegiados, las bitácoras, las pruebas de restauración, el inventario. Si la respuesta tarda, ya sabes dónde vas a tener un problema en la Etapa 2.
Lista de verificación rápida
- ¿Tengo un inventario de activos actualizado, con responsable por activo?
- ¿Puedo entregar hoy la lista de quién tiene acceso administrativo, sin cuentas compartidas?
- ¿Las bitácoras están centralizadas y protegidas contra borrado?
- ¿Todos los sistemas toman la hora de la misma fuente?
- ¿Tengo el registro de la última restauración probada, con fecha y duración?
- ¿Existe un ciclo de vulnerabilidades con al menos dos trimestres de historial?
- ¿Hay líneas base de configuración documentadas?
- ¿Los cambios a producción quedan registrados con quién los autorizó?
- ¿Estuve en la junta donde se definió el alcance?
Si dudaste en cuatro o más y la auditoría es en menos de seis meses, el problema no es de esfuerzo: es de calendario. Conviene decirlo en voz alta ahora y no en la Etapa 2, cuando una no conformidad mayor ya cuesta una auditoría de seguimiento y una fecha corrida.
Nosotros no somos consultores de certificación y no armamos sistemas de gestión. Lo que hacemos es la parte de abajo: accesos privilegiados, segmentación, bitácoras, respaldos con restauración cronometrada y gestión de vulnerabilidades, que es donde se produce la evidencia que el auditor pide. Si quieres ver dónde estás parado antes de comprometer una fecha, eso es exactamente lo que mide nuestro diagnóstico. El control A.5.30, de preparación de las TIC para la continuidad, está desarrollado en la guía de continuidad de negocio, y el A.8.2 en qué pasa cuando un empleado descarga lo que no debía.