De todos los requisitos del numeral 8.2.6, hay uno que no se resuelve comprando software, contratando un proveedor ni corriendo más. El 8.2.6.12.b exige un sistema de gestión de seguridad de la información certificado bajo ISO/IEC 27001 por un organismo acreditado.
Si su centro está inscrito como de mayor envergadura, este es el punto crítico de su cronograma. Y conviene entender por qué antes de asignarle presupuesto a otra cosa.
Qué es y qué no es
ISO/IEC 27001 no certifica un producto. Certifica que una organización gestiona la seguridad de su información de forma sistemática.
Lo que un auditor va a pedirle no es una lista de tecnologías. Es esto:
- Un alcance definido: qué procesos, qué sedes, qué sistemas entran.
- Una política de seguridad aprobada por la dirección.
- Un análisis de riesgos con su metodología, sus criterios de aceptación y su tratamiento.
- Una declaración de aplicabilidad: qué controles aplica, cuáles no y por qué.
- Los controles implantados y operando, con evidencia.
- Formación del personal y registro de que se hizo.
- Gestión de proveedores y de sus riesgos.
- Auditoría interna y revisión por la dirección.
- Finalmente, la auditoría de certificación en dos etapas.
Ninguna licencia de software le entrega eso. Un proveedor que insinúe lo contrario le está vendiendo un problema para dentro de un año, cuando llegue el auditor y pregunte por el análisis de riesgos.
Cuánto tarda de verdad
Entre 9 y 18 meses para una organización que empieza de cero, y el rango depende menos del presupuesto que de dos factores: la dedicación real de alguien interno y la velocidad con la que la dirección toma decisiones.
Hay una razón que explica por qué no se puede comprimir mucho más: el auditor necesita ver evidencia de operación, no de implantación. Un control aprobado la semana pasada no genera registros. Un registro de revisiones de accesos que empezó hace tres meses, sí. Ese tiempo de maduración no se salta con dinero.
Por eso, si hoy no lo ha arrancado, arrancarlo es más urgente que cualquier otra partida de su plan de cumplimiento.
Qué parte sí aporta la plataforma
Dicho lo anterior, la mitad técnica del expediente sí se puede tener resuelta de antemano. Un sistema de expedientes bien construido cubre, por diseño, varios controles del anexo de la norma y —más importante— genera su evidencia automáticamente:
Control de accesos y gestión de identidades. Roles diferenciados, altas y bajas con rastro, segundo factor obligatorio para el personal interno, cierre de sesión por inactividad. Cuando el auditor pida evidencia de la revisión de accesos, la lista de usuarios con su rol y su historial de cambios ya existe.
Registro de eventos y protección de los registros. Este control tiene dos partes y la segunda es la que suele fallar: no basta con registrar, hay que proteger el registro frente a manipulación. Un registro encadenado por hash y protegido en el motor de base de datos contra UPDATE y DELETE satisface exactamente eso, y lo demuestra en pantalla.
Copias de seguridad. Respaldo automático con retención definida y, sobre todo, con historial de cuándo se hizo cada uno.
Gestión de incidentes. Registro con fecha de detección, de reporte y de cierre, con las medidas adoptadas. Es el mismo módulo que le exige el 8.2.6.16, y sirve para las dos cosas.
Segregación de funciones. Que el sistema impida la acumulación de cargos incompatibles es un control implantado, no una política escrita.
Gestión de credenciales. Restablecimiento con rastro, cambio forzado tras un reinicio, política de contraseñas.
La diferencia entre llegar a la auditoría con estos controles ya operando y llegar con un plan es de meses.
El error de secuencia más caro
Es este: esperar a tener el software para empezar el SGSI.
Son dos caminos paralelos, no consecutivos. La política, el alcance, el análisis de riesgos y la formación no dependen de qué sistema use. Puede —y debería— empezarlos ahora, con lo que tiene hoy, y sustituir después las evidencias técnicas por las del sistema nuevo cuando entre en operación.
Si encadena las dos cosas, suma los plazos. Si las solapa, no.
Lo que se puede hacer este mes
Sin presupuesto grande y sin consultora todavía:
- Nombre un responsable interno. Sin alguien que responda por esto, el proyecto no avanza aunque haya consultora.
- Defina el alcance provisional. Qué procesos y qué sistemas entran. Es la decisión que condiciona todo lo demás y el coste de la certificación.
- Levante el inventario de activos de información. Qué información maneja el centro, dónde está y quién la toca.
- Haga un análisis de brechas. Contra el anexo de la norma, aunque sea informal. Le dirá el tamaño real del trabajo.
- Documente lo que ya hace bien. Muchos centros tienen controles operando sin haberlos escrito nunca. Escribirlos es la mitad del trabajo.
Un apunte sobre la nube
Un alivio en medio de todo lo anterior: la Directiva 004 no exige residencia de datos en el Perú y admite expresamente servidores en la nube. Eso despeja una decisión que en otros marcos regulatorios encarece y complica bastante el proyecto.
Sí conviene, en cambio, tratar al proveedor de nube como lo que es a efectos del SGSI: un proveedor con acceso a información, con su evaluación de riesgos, su contrato y sus garantías documentadas. Es uno de los puntos que el auditor mira con más atención.
Contenido informativo. No constituye asesoría legal ni de certificación; el alcance, la metodología y la elección del organismo certificador corresponden a cada centro y a su consultor.