La Comunicación A 8398 del BCRA no le pidió a los PSP que entiendan la norma. Eso ya lo saben. Les pidió algo más difícil: que demuestren, con evidencia, que sus controles de tecnología y seguridad de la información funcionan en la operación real. Y ahí es donde la mayoría se va a encontrar con un problema que no esperaba.

No es que los PSP no quieran cumplir. Es que el modelo operativo que los hizo crecer rápido, con procesos livianos y mucha dependencia de personas claves, no genera por sí solo el tipo de registro que un regulador va a pedir el 4 de agosto.

El problema no es la norma, es la evidencia

Casi todos los PSP con los que hablamos tienen algo escrito: una política de seguridad, un manual de continuidad, un procedimiento de gestión de incidentes. El problema aparece cuando alguien pregunta cómo se ejecuta eso en el día a día. Ahí la respuesta cambia según quién conteste, y la evidencia no está consolidada en ningún lado. Existe, pero hay que armarla.

Esa brecha entre lo que está documentado y lo que realmente se ejecuta es el verdadero riesgo de la A 8398, mucho más que la norma en sí.

Cinco brechas que se repiten en casi todos los PSP

1. Controles de seguridad que existen pero no se ejecutan de forma consistente. Hay una política. Hay un control definido. Pero su ejecución depende de que alguien se acuerde de hacerlo, y no hay registro de que se haya hecho cada vez.
2. Continuidad del negocio que depende de personas, no de sistemas. El plan de continuidad funciona si la persona que lo diseñó está disponible para activarlo. Si no está, el proceso se reconstruye sobre la marcha.
3. Terceros críticos sin due diligence formal ni monitoreo continuo. Proveedores tecnológicos que procesan datos sensibles o sostienen servicios críticos, evaluados una vez al firmar el contrato y nunca más.
4. Gestión de ciberincidentes sin registros auditables desde el origen. Cuando pasa algo, se resuelve. Pero el registro de qué pasó, cuándo se detectó y cómo se respondió no queda armado de forma sistemática.
5. Trazabilidad que se reconstruye cuando alguien la pide, en vez de existir en tiempo real. Esta es la brecha que conecta a todas las anteriores. La evidencia se fabrica para la auditoría, no nace de la operación.

Lo que el BCRA va a mirar primero

Cuando un regulador audita gestión de riesgos tecnológicos, no empieza preguntando si existe la política. Empieza pidiendo el registro de ejecución: quién hizo el control, cuándo, con qué resultado. Si esa evidencia no existe desde el origen, no hay forma de reconstruirla de manera creíble en el momento.

Esto cambia la pregunta que cada PSP debería estar haciéndose. No es “¿tenemos la política?”. Es “¿podemos mostrar, con registros reales, que el control se ejecutó la semana pasada?”.

Diagnóstico, plan, control crítico: no hace falta estar completo, hace falta estar en proceso

Quedan menos de siete semanas hasta el 4 de agosto. Adecuarse por completo en ese plazo no es realista para la gran mayoría de los PSP, y cualquiera que prometa lo contrario no está siendo honesto con el timeline.

Lo que sí es alcanzable, y lo que un regulador valora cuando ve que una organización está trabajando en serio, es demostrar tres cosas: que se hizo un diagnóstico real de la brecha, que existe un plan priorizado por riesgo y tiempo, y que los controles más críticos ya están en marcha. Eso no es llegar completo. Es llegar con evidencia de proceso, en vez de llegar a reconstruir todo bajo presión cuando el plazo ya venció.

En COA venimos trabajando hace casi cuatro décadas con bancos e instituciones financieras en gobierno de tecnología, gestión de riesgos, seguridad de la información, continuidad del negocio, gestión de ciberincidentes y gestión de terceros críticos. Si la A 8398 es algo que tu equipo está empezando a mapear, vale la pena una conversación corta para ver dónde está parado tu PSP hoy y qué es lo mínimo viable para llegar a agosto con un plan creíble.