Cómo organizar una RFP de concienciación en seguridad sin perder 6 meses

¿Conoces esa sensación cuando tomas un atajo para evitar el tráfico, pasas 10 minutos por carreteras secundarias y, de algún modo, acabas justo detrás del autobús que intentabas adelantar? Todo eso para nada.

Así es más o menos como acaban muchas RFP de concienciación en seguridad. Seis meses de trabajo, una nueva plataforma y 18 meses después la dirección pregunta qué ha cambiado. El porcentaje de clics y el porcentaje de avisos de phishing están casi igual que después del primer problema. A menudo se debe a que el proceso se adueña de la situación. Cambiar de herramienta se convierte en el objetivo y, en algún momento del camino, los equipos pierden de vista lo que intentaban solucionar (asumiendo que lo tuvieran claro desde el principio).

Dirijo los equipos de preventa y licitaciones de SoSafe, por lo que veo muchas de estas evaluaciones desde el lado del proveedor. Esto es lo que haría de forma diferente si estuviera en tu lugar.

¿Qué debes definir antes de hablar con los proveedores?

Vamos a ser sinceros un momento, creo que todos buscamos lo mismo: mantener la seguridad de la empresa, no pagar de más, reducir el trabajo de los administradores y conseguir una herramienta que la gente realmente use y le guste.

No se llega a ese punto empezando por una lista de tareas de funcionalidades, sino yendo al punto final y trabajando en retrospectiva a partir de lo que ocurre de verdad en el día a día.

¿A quién intentas ayudar y qué quieren cambiar?

Un operario de fábrica no aprende ni trabaja de la misma manera que alguien sentado en un escritorio, y el problema puede parecer completamente distinto para un equipo u otro. El departamento de finanzas tal vez lidie con solicitudes falsas de proveedores, mientras que los desarrolladores podrían estar introduciendo código en herramientas de IA no aprobadas.

¿Qué es lo que aún no ves?

Digamos que conoces tus porcentajes de clics, pero no qué equipo reporta más correos electrónicos sospechosos que otros. Se trata de un punto ciego que no quieres que trasladar a la siguiente herramienta.

¿Qué es lo que tu herramienta actual no puede hacer?

Si tienes que buscar soluciones alternativas constantemente, suele indicar que falta algo.

¿Qué pedirán la junta directiva y los auditores?

La junta directiva puede querer una cosa, mientras que un auditor o regulador podría buscar algo totalmente distinto.

¿Quién hace qué?

¿Qué puede gestionar la plataforma por ti? ¿Dónde sigue siendo necesaria la intervención de tu equipo? Y ¿qué tareas vas a seguir asumiendo en cualquier caso?

¿Y si no cambiar es la mejor decisión?

No descartes a tu proveedor actual a las primeras de cambio. Somételo a las mismas comprobaciones que al resto, porque puede que ya tengas lo que necesitas y simplemente no lo estés utilizando. Si no es así, al menos sabrás por qué vas a cambiar.

Puntuar las cosas adecuadas de la forma adecuada

Entiendo por qué las RFP se convierten en enormes hojas de cálculo de funcionalidades. Son fáciles de puntuar para el departamento de compras y fáciles de responder para los proveedores. Pero una vez que la hoja de cálculo toma el control, es fácil dejarse llevar por quién tiene más de qué y olvidar qué herramienta resuelve realmente el problema con el que empezaste.

Si el objetivo es ayudar a las personas a gestionar mejor las amenazas reales, tener más funcionalidades no te llevará automáticamente a conseguirlo. Pongamos como ejemplo las bibliotecas de contenidos: tener miles de módulos genéricos suena impresionante, pero a mí me importaría más en qué idiomas está el contenido, si la persona que lo recibe lo considera relevante y si participa por voluntad propia.

Y yo analizaría las métricas de la misma manera. Puedes tener paneles de métricas por todas partes, pero si no te dicen si la gente está tomando decisiones más seguras o dónde sigues estando expuesto, no te sirven de mucho.

Y no des por sentados los requisitos de la RFP. Si algo está ahí solo porque estaba en la última RFP o procedía de la plantilla de un proveedor, pregunta para qué sirve antes de puntuarlo.

Por último, si algo apenas marca la diferencia, no le des el mismo peso que a algo de lo que depende todo el programa.

Lo que la demo de producto no te mostrará

La demo de producto no te dirá cuánto trabajo de administración incluye la herramienta, pero unas semanas de uso real sí. Una prueba de valor en tu propio entorno te permite descubrirlo antes, contrastándolo con los directorios, grupos de usuarios y flujos de trabajo que ya tienes.

Pruébalo a propósito con las cosas aburridas. ¿Cómo se gestionan las altas y bajas de empleados? ¿Con qué rapidez puedes cambiar una campaña? Si algo está etiquetado como «automatizado», no te detengas ahí. Analízalo a fondo y comprueba qué le queda aún por hacer a tu equipo, porque 10 minutos por aquí y 20 por allá pueden acumularse más rápido de lo que crees. Ese tiempo también forma parte del coste, tanto si figura en la factura como si no.

Y fíjate también en todo lo que tiene que ocurrir en torno a la plataforma: la configuración del SSO, el acceso a la API, la limpieza de directorios, las comprobaciones de privacidad, las revisiones del comité de empresa, la revisión de contenidos, las comunicaciones internas y la gestión de cambios. Es posible que algunas cosas que dabas por sentadas estén reservadas a un paquete superior, o que acaben costándote más tiempo del que ahorraste en la licencia.

Una demo de producto puede hacer que algunas tareas muy manuales parezcan sencillas, especialmente las cargas periódicas de archivos CSV, que parecen bastante fáciles hasta que la gente empieza a incorporarse, cambiar de equipo e irse de la empresa, y alguien tiene que mantenerlo todo en orden. Los informes de cumplimiento de las normativas pueden ser la misma historia: si alguien todavía tiene que exportar los datos y rehacer el informe en otro lugar, difícilmente se puede considerar automatizado. Y no dejes la residencia de los datos, los subencargados del tratamiento o las certificaciones de seguridad para que el equipo legal los revise más adelante.

Quieres saber a qué te comprometes antes de firmar, no a mitad de la implementación.

La experiencia en el otro lado

Ahora ponte en el lugar del destinatario por un momento. Haces clic en una simulación. ¿Aprendes algo útil o solo sientes que te han pillado? Reportas un correo electrónico sospechoso. ¿Recibes alguna respuesta o simplemente acaba en una cola de espera? Si cada vez que la gente recibe noticias de tu departamento es para otra prueba, un recordatorio o un módulo obligatorio, tarde o temprano acabarán desconectando mentalmente. Intenta trasladar esa perspectiva a la RFP. Es más difícil de clasificar, pero es con lo que la gente va a convivir realmente, ¿no?

Pregunta a tu alrededor. La gente podría usar esa herramienta durante años, así que te conviene saber cómo es cuando todos están acostumbrados a ella. Habla con clientes que la hayan tenido al menos durante unos 18 meses y pregunta si los usuarios siguen participando, si el soporte técnico sigue respondiendo de manera eficaz y qué les habría gustado saber antes.

Establece cómo se define el éxito antes de firmar

Mientras aún tienes la atención del proveedor, acuerda cómo se define el éxito. ¿Qué estás midiendo, qué debería mejorar y con qué frecuencia lo estás revisando? Pasados uno o dos años, así es como sabrás si sigue cumpliendo su función.

Si 6 meses de trabajo en la RFP solo te sirven para saber qué proveedor obtuvo la puntuación más alta, te has perdido la mitad de lo que podría enseñarte. Lo ideal es que salgas de este proceso de evaluación conociendo también mejor tu propio programa. Aférrate a eso a medida que avanzas, y la plataforma tendrá muchas más posibilidades de hacer el trabajo para el que la elegiste.

Sobre el autor

Harry Jeyarajah
Director de ingeniería de soluciones

Harry Jeyarajah dirige el equipo de ingeniería de soluciones de SoSafe, donde ayuda a los responsables de seguridad a respaldar sus inversiones en concienciación con puntos de prueba sólidos, abarcando desde la reducción de riesgos hasta el cambio de comportamientos. Aporta 10 años de experiencia en el entorno digital de la región DACH, abarcando desde pruebas A/B, infraestructura informática para web y aplicaciones hasta Content Management y gestión del riesgo humano.

Más información