5 riesgos regulatorios de TI que enfrentan las cooperativas en Costa Rica
Trazabilidad incompleta, respaldos sin verificar, accesos sin revocar. Los hallazgos que más se repiten en supervisión y cómo anticiparlos antes de que aparezcan en un informe.
Una cooperativa de ahorro y crédito opera bajo las mismas exigencias de supervisión que un banco, con una fracción del presupuesto de TI. Esa asimetría es la que produce la mayoría de los hallazgos: no falta voluntad de cumplir, falta capacidad de sostener controles que fueron diseñados pensando en instituciones más grandes.
Estos cinco son los que aparecen con más frecuencia.
1. Trazabilidad incompleta
El requisito es simple de enunciar: para cualquier operación relevante, la institución debe poder responder qué pasó, cuándo pasó, quién lo hizo y desde dónde.
En la práctica se rompe en las juntas entre sistemas. El core registra la transacción, pero el ajuste manual que la corrigió se hizo desde una hoja de cálculo. O el log existe pero se rota cada treinta días y la consulta pide seis meses atrás.
Qué revisar: tome tres operaciones al azar de hace cuatro meses y trate de reconstruir su historia completa. Si necesita llamar a alguien para entender un paso, ahí está el hallazgo.
2. Accesos que sobreviven a las personas
El colaborador se fue hace ocho meses y su usuario sigue activo. O cambió de área y conserva los permisos del puesto anterior sumados a los del nuevo. Es el hallazgo más común y el más fácil de encontrar para un auditor: pide la lista de usuarios activos y la compara con la planilla.
El problema de fondo no es técnico sino de proceso. La baja de un colaborador pasa por Recursos Humanos, y si no existe un disparador automático hacia TI, la revocación depende de que alguien se acuerde.
Qué revisar: cruce la lista de usuarios activos de cada sistema con la planilla vigente. Los que no calcen son deuda acumulada.
3. Respaldos que nadie ha restaurado
Tener respaldos y poder recuperarse son cosas distintas. Una institución puede llevar años ejecutando el respaldo nocturno sin fallas y descubrir, el día que lo necesita, que el archivo está corrupto, que falta una base, o que la restauración completa toma treinta horas cuando el compromiso de continuidad decía cuatro.
Qué revisar: cuándo fue la última restauración de prueba, quién la hizo y qué tiempo tomó. Si la respuesta es “nunca se ha probado”, el respaldo es una suposición, no un control.
4. Dependencia de terceros sin gobierno
La cooperativa contrata un proveedor para el core, otro para el canal digital, otro para el procesamiento de tarjetas. Cada contrato se negoció por separado y en momentos distintos. Cuando el supervisor pregunta quién responde por la continuidad del servicio al asociado, la respuesta involucra a tres empresas y ningún documento que las coordine.
Qué revisar: para cada proveedor crítico, ¿existe un acuerdo de nivel de servicio escrito, con tiempos de respuesta por severidad y consecuencias definidas? ¿Alguien lo revisa periódicamente o se firmó y se archivó?
5. Continuidad documentada pero no ensayada
Casi todas las instituciones tienen un plan de continuidad. Muchas menos lo han ejecutado. Un plan que nunca se probó suele contener teléfonos desactualizados, responsables que ya no trabajan ahí y procedimientos que asumen sistemas que se reemplazaron.
Qué revisar: la fecha del último ensayo y el acta de resultados. Si el documento tiene tres años y ninguna versión posterior, describe una institución que ya no existe.
El patrón común
Los cinco comparten algo: no son fallas de tecnología, son fallas de proceso que se manifiestan en la tecnología. Ninguno se resuelve comprando una herramienta.
Se resuelven asignando responsables, definiendo periodicidad y dejando evidencia de que la revisión ocurrió. Eso es más barato que cualquier software, y es exactamente lo que un supervisor busca cuando pregunta.
Este artículo describe riesgos operativos frecuentes y no constituye asesoría regulatoria. Las obligaciones específicas aplicables a cada institución dependen de su tamaño, actividad y de la normativa vigente al momento de la supervisión.
¿Este tema describe la situación de su organización?
Conversemos sobre su casoSeguir leyendo
Qué debe exigirle a un proveedor de integración de sistemas críticos
Doce preguntas concretas para hacer antes de firmar. Si el proveedor no puede responderlas con especificidad, el riesgo lo asume su organización.
BancaCómo modernizar sistemas bancarios sin interrumpir la operación
Migrar un core bancario no es un proyecto de tecnología: es un ejercicio de gestión de riesgo. Las fases, los puntos de reversión y los errores que salen caros.