¿Consultoría ISO 27001 o plataforma de cumplimiento?

Qué aporta una consultoría ISO 27001

Una consultoría aporta criterio en las partes de la ISO 27001 que no se pueden convertir en plantilla. El encargo típico incluye un análisis de brechas frente a la norma, la definición del alcance del sistema de gestión de seguridad de la información (SGSI), el diseño de la metodología de análisis de riesgos y el primer análisis, la redacción de las políticas y de la declaración de aplicabilidad, y la preparación para la auditoría de certificación.

El valor está en las decisiones. Qué entra en el alcance y qué se queda fuera. Qué riesgos son aceptables. Por qué un control del anexo A aplica o no aplica. Son las preguntas que el auditor plantea en la fase 1, y un consultor con experiencia sabe cómo suelen reaccionar los auditores a cada respuesta.

Cómo suele desarrollarse un proyecto

La mayoría de los proyectos de consultoría siguen un recorrido parecido. Empiezan con entrevistas y un análisis de brechas que compara la práctica actual con los apartados y los controles del anexo A. Después vienen los documentos base: la declaración de alcance, la política de seguridad y la metodología de riesgos. Sigue el análisis de riesgos, normalmente en talleres donde el consultor dirige y el negocio aporta el conocimiento. De las decisiones de tratamiento sale la declaración de aplicabilidad y, después, el resto de políticas y procedimientos. El proyecto suele cerrar con una auditoría interna, una revisión por la dirección y apoyo durante la auditoría de certificación.

Una buena consultoría traspasa la responsabilidad mientras avanza el proyecto: quienes van a operar cada proceso escriben, o al menos reescriben, el procedimiento que lo describe, y los responsables de cada riesgo toman y registran ellos mismos las decisiones de tratamiento. Un encargo más flojo entrega un juego completo de documentos que la organización lee por primera vez una semana antes de la fase 1.

Señales de una consultoría sólida

Las consultorías son muy distintas entre sí, y las diferencias se ven pronto. Algunas señales útiles: un análisis de brechas que cita apartados y controles concretos en lugar de puntuaciones genéricas de madurez; una metodología de riesgos que se explica en una página, no una hoja de cálculo que nadie más entiende; consultores que han preparado a otras organizaciones para auditorías con entidades de certificación acreditadas conforme a la ISO 27006-1; y un plan claro de cómo se entregarán los documentos y quién los mantendrá. Una propuesta que promete el juego completo de documentos en un número fijo de días, sin preguntar cómo trabaja la empresa, suele indicar que las plantillas hacen casi todo el trabajo.

Dónde llega al límite el modelo de consultoría

Los límites vienen del formato. Una consultoría suele ser un proyecto con principio y fin, y cuando termina tienden a pasar tres cosas:

• Los documentos los ha escrito alguien de fuera, y quienes deben aplicarlos no siempre reconocen en ellos sus propios procesos.
• La recogida de evidencias es manual y vive en carpetas compartidas, así que nadie detecta un control abandonado hasta que se acerca la auditoría de seguimiento.
• El conocimiento de por qué se tomó cada decisión se va con el consultor.

Hay además un problema estructural con la auditoría interna. El apartado 9.2.2 de la ISO 27001 exige seleccionar a los auditores internos de forma que se garantice la objetividad y la imparcialidad. Un consultor que diseñó el SGSI no está bien situado para auditarlo. Algunas consultorías lo resuelven asignando a otro consultor la auditoría interna, lo que ayuda, pero conviene preguntarlo expresamente.

Qué aporta una plataforma de cumplimiento

Una plataforma de cumplimiento es un software que organiza el SGSI como un conjunto de controles, tareas y evidencias. Lo habitual es que incluya una biblioteca de controles vinculada al anexo A, plantillas de políticas, integraciones con los sistemas de nube, identidad y recursos humanos que recogen evidencias de forma automática, asignación de tareas y recordatorios, y la correspondencia de los mismos controles con otros marcos como el ENS o SOC 2.

El valor está en la continuidad. Los controles siguen a la vista entre auditorías. Una revisión de accesos pendiente o un portátil sin cifrar aparecen en un panel en lugar de en un hallazgo del auditor. Las evidencias quedan fechadas y trazables, que es justo lo que muestrean las auditorías de seguimiento. Cómo funciona en la práctica se explica en cómo una plataforma de cumplimiento recopila y rastrea las evidencias.

Lo que la automatización cubre bien

Las integraciones rinden más cuando la evidencia es una configuración o un listado que un sistema ya tiene:

• Si el doble factor de autenticación está obligado en el proveedor de identidad.
• Si los portátiles están cifrados y tienen protección instalada.
• Si el almacenamiento en la nube es privado y los registros están activados.
• Qué personas han entrado y salido de la empresa, y si sus cuentas se crearon y eliminaron.
• Si la plantilla ha aceptado las políticas y completado la formación.

En estos casos, la plataforma convierte una recogida manual en una comprobación continua. Relacionar la misma evidencia con varios marcos evita además recogerla dos veces cuando la ISO 27001 convive con el ENS o SOC 2.

Qué revisar al elegir una plataforma

Las plataformas se diferencian menos por su biblioteca de controles que por cómo encajan con los sistemas que la empresa usa de verdad. Antes de elegir, conviene comprobar con qué herramientas de identidad, nube, equipos y recursos humanos se integra, y qué evidencia produce cada integración. Pregunta cómo se recoge y se revisa la evidencia de los controles que no tienen integración. Comprueba si las políticas se pueden reescribir libremente o solo retocar, y si la plataforma cubre los otros marcos que vas a necesitar, como el ENS para trabajar con el sector público. Y pregunta quién, por parte del proveedor, responde a las dudas sobre la norma, no sobre el software.

Lo que la automatización no puede decidir

Los límites vienen del mismo sitio. Una plataforma puede guardar un registro de riesgos, pero no decide qué riesgos acepta tu empresa. Puede generar una política a partir de una plantilla, pero no sabe si describe cómo trabajan de verdad tus equipos. Y las integraciones confirman configuraciones, por ejemplo que el doble factor está activado, no que un proceso como la gestión de incidentes o la revisión de proveedores se haga bien.

Las políticas de plantilla tienen un riesgo concreto en la auditoría. El auditor lee la política y luego entrevista a las personas a las que se aplica. Si la política describe un comité de aprobación de cambios que la empresa nunca ha reunido, la diferencia se convierte en un hallazgo, y el auditor empieza a preguntarse qué más de la documentación es una aspiración.

Las plataformas que se compran sin nadie que las gestione siguen un patrón conocido: el panel se llena de alertas en rojo, nadie se hace cargo y el proyecto se para. Ese patrón se trata en cómo reactivar un proyecto ISO parado.

Dónde se queda corta cada una

Puestos uno al lado del otro, los dos modelos fallan en direcciones opuestas. La consultoría aporta criterio sin continuidad. La plataforma aporta continuidad sin criterio.

Si se sigue el trabajo a lo largo del ciclo de certificación, se ve dónde aparece cada carencia:

• Alcance y análisis de riesgos. Puntos fuertes de la consultoría. La plataforma ofrece estructura y un registro, pero no criterio sobre qué entra en el alcance ni qué riesgos importan.
• Políticas y declaración de aplicabilidad. La consultoría las adapta; la plataforma ofrece plantillas. En ambos casos, alguien de dentro tiene que confirmar que describen la realidad.
• Recogida de evidencias. Manual con la consultoría, normalmente en carpetas. Automática para las configuraciones con la plataforma, manual para todo lo demás.
• Auditoría interna. La consultoría puede hacerla si se cuida la imparcialidad. La plataforma puede guardar la lista de comprobación, pero no audita.
• Auditorías de seguimiento del segundo y el tercer año. A menudo quedan fuera del proyecto de consultoría original. La plataforma mantiene el flujo de evidencias si alguien sigue actuando sobre ellas.

Qué modelo encaja en cada situación

La combinación adecuada depende del punto de partida. Una empresa que afronta su primera certificación con un plazo marcado por un cliente, sin nadie dentro que conozca la norma, necesita criterio primero: decidir bien el alcance y los riesgos al principio ahorra meses después. Una empresa que ya tiene el certificado pero no consigue mantener las evidencias al día entre auditorías necesita continuidad más que documentos nuevos. Una empresa con varios marcos a la vez, como la ISO 27001 y el ENS, es la que más gana relacionando evidencias entre ellos. Y una empresa sin capacidad interna de seguridad necesita, antes que nada de lo anterior, a alguien que opere los controles que describe el certificado.

Las dos comparten una carencia que la norma no permite externalizar del todo: la responsabilidad. El apartado 5.3 de la ISO 27001 exige que la alta dirección asigne las responsabilidades y autoridades del SGSI, y el apartado 9.3 le exige revisarlo. Un consultor puede preparar el orden del día de la revisión por la dirección y una plataforma puede generar el informe, pero las decisiones que quedan registradas son de la organización.

En la práctica, la pregunta no es consultoría o plataforma. Es quién es el responsable del SGSI dentro de la empresa y qué apoyo necesita para mantenerlo vivo después del primer certificado.

Lo que no cubre ninguna de las dos

Ninguno de los dos modelos opera la seguridad. El anexo A de la ISO 27001 incluye controles que solo existen si alguien los ejecuta a diario:

• Actividades de monitorización (control 8.16): redes, sistemas y aplicaciones vigilados para detectar comportamientos anómalos.
• Gestión de incidentes (controles 5.24 a 5.26): eventos evaluados, incidentes respondidos y lecciones registradas.
• Gestión de vulnerabilidades técnicas (control 8.8): vulnerabilidades identificadas, evaluadas y corregidas.
• Concienciación, educación y formación (control 6.3): impartida y medida, no solo programada.

Estos controles generan los registros a los que vuelven cada año las auditorías de seguimiento, porque son el punto en el que el sistema de gestión se encuentra con la operación diaria. Una consultoría puede redactar el procedimiento de respuesta a incidentes. Una plataforma puede comprobar si se ejecutó el escaneo de vulnerabilidades. Ninguna analiza una alerta a las tres de la madrugada ni parchea un servidor. Si esos controles son aplicables en la declaración de aplicabilidad, alguien tiene que operarlos, y las auditorías de seguimiento muestrearán los registros que generan.

Otros controles están en la misma situación aunque parezcan administrativos: las revisiones de accesos (5.18) necesitan a alguien que decida si cada permiso sigue justificado; las evaluaciones de proveedores (5.19 a 5.22), a alguien que lea las respuestas y actúe; las pruebas de continuidad (5.30), a alguien que haga el ejercicio y anote lo que falló. El software puede programarlos y seguirlos todos. Hacerlos les toca a las personas.

Cómo se ve en una auditoría

Pensemos en el control 8.16. La política dice que se monitorizan los eventos de seguridad. El auditor pide ver las alertas del último mes y qué se hizo con cada una. Una organización en la que nadie vigila las alertas solo tiene dos respuestas: que no hubo ninguna, algo poco creíble, o que hubo algunas y nadie las miró. En los dos casos el control no funciona, y la política que lo describe se ha convertido en un problema.

Con la gestión de vulnerabilidades pasa lo mismo. Un escáner que se ejecuta cada semana genera informes. El control es la corrección que viene después, con fechas, y la decisión de aceptar el riesgo cuando no hay arreglo posible. La diferencia entre documentar un control y ejecutarlo se analiza en plataforma de compliance vs seguridad: lo que una licencia no cubre.

Qué preguntar a cualquier proveedor

Sea cual sea el modelo, estas preguntas distinguen un certificado que se sostiene de uno que se apaga después del primer año. En cada una, lo útil no es tanto el sí o el no como lo concreta que sea la respuesta.

• ¿Quién hace el análisis de riesgos y quién de nuestra empresa aprueba las decisiones de tratamiento? Una buena respuesta nombra un método y describe talleres con vuestros responsables de riesgo, no un registro precargado desde una biblioteca.
• ¿Quién mantiene la declaración de aplicabilidad cuando cambia el negocio? Un producto nuevo, una oficina nueva o un nuevo proveedor en la nube cambian el alcance y los riesgos. Alguien tiene que darse cuenta y actualizar los documentos.
• ¿Quién hace la auditoría interna y cómo se garantiza su imparcialidad? Fíjate en cómo se mantiene al auditor independiente de quien construyó y gestiona el SGSI.
• ¿Cómo se recogen las evidencias para las auditorías de seguimiento del segundo y el tercer año? Si la respuesta es «os preparamos antes de cada auditoría», cuenta con carreras de última hora cada año.
• ¿Qué controles del anexo A operáis vosotros y cuáles tenemos que operar nosotros? Pide una lista frente a la declaración de aplicabilidad, no una descripción general.
• ¿Qué pasa cuando salta una alerta fuera del horario laboral? Si nadie tiene nombre, la monitorización es un informe que alguien lee por la mañana.
• ¿Cómo es el primer año después de la certificación, mes a mes? Un proveedor con experiencia puede describir los controles recurrentes, la auditoría interna, la revisión por la dirección y la auditoría de seguimiento como un calendario, con un responsable para cada punto.
• ¿Quién estará en la sala durante la auditoría de certificación? El auditor entrevista a quienes llevan los procesos. El proveedor puede prepararlos y acompañar durante la auditoría, pero no puede responder por ellos.
• ¿Qué conservamos si dejamos de trabajar juntos? Los documentos, el histórico de evidencias y las configuraciones deberían seguir siendo de la organización, en formatos que pueda usar.

Las respuestas muestran dónde recaerá el trabajo cuando el proveedor deje de estar encima. Si la respuesta honesta a casi todas es «vuestro equipo», la siguiente pregunta es si vuestro equipo tiene el tiempo y los conocimientos.

Combinar los dos modelos

Muchas organizaciones acaban combinando una consultoría para las decisiones iniciales con una plataforma para la continuidad. Puede funcionar, pero el traspaso entre ambas es donde se pierden cosas: el razonamiento del consultor sobre el alcance y los riesgos rara vez llega a la plataforma, y las alertas de la plataforma no tienen a nadie con autoridad para actuar. Si las combinas, acuerda de antemano quién es el responsable del SGSI cuando se vaya el consultor y quién opera los controles que no cubre ninguna de las dos.

Una plataforma con acompañamiento

Qalea combina una plataforma de cumplimiento con el acompañamiento de un equipo de seguridad, de modo que la continuidad del software y el criterio de las personas están en el mismo servicio. La plataforma relaciona los controles con la ISO 27001 y otros marcos y recoge evidencias de forma continua. Nuestro equipo trabaja con el vuestro en el alcance, el análisis de riesgos, la declaración de aplicabilidad, la auditoría interna y la revisión por la dirección, con un CISO virtual cuando hace falta esa figura.

Qalea también opera los controles que no cubren ni la consultoría ni la plataforma: EDR en los equipos, SIEM y un SOC 24/7 para la monitorización y la respuesta a incidentes, y gestión de la superficie de ataque y de vulnerabilidades. La organización conserva la responsabilidad del SGSI y de sus decisiones. Lo que deja de tener que hacer sola es operar la función de seguridad de la que depende el certificado.