Blog - Metodologías y Legislación

Usar puntuación: / 3
MaloBueno 

Hemos leído y escuchado que el riesgo tecnológico es una parte importante del riesgo operacional, esto se da en la medida que los procesos de negocio de las empresas dependan de las Tecnologías de la Información (TI), situación que hoy es muy común.

Por otra parte hemos visto como diversos entes reguladores de distintos países de Latinoamérica han adoptado la Supervisión Basada en Riesgo (SBR), la cual toma el riesgo operacional como base de la auto supervisión. Por último, tanto en las recomendaciones para el sector Bancario del acuerdo de Basilea II (acuerdo vigente desde el 2004), y Solvencia II (a partir del año 2011) para las empresas del sector Seguros, el riesgo operacional es un pilar base.

La pregunta que aparece al instante es ¿Cómo evalúo el riesgo tecnológico? Todas estas normativas, recomendaciones y modelos de autorregulación nos hablan de que el riesgo tecnológico es pilar fundamental del riesgo operacional, pero no indican cómo evaluarlo o cuál es el nivel de madurez que debería existir en el control interno de TI.

¿Cuál es la realidad de TI hoy?

Si bien muchas compañías han logrado un nivel de madurez de sus áreas de TI, es común encontrarnos con gerentes que han manifestado su descontento con relación a la TI, luego de haber realizado grandes inversiones de dinero.

Por su parte, cada vez más el gobierno corporativo de las organizaciones, se está dando cuenta de la importancia que tiene un área vista tradicionalmente como ejecutora de proyectos específicos de automatización y como consumidora de recursos: el área de Tecnología de Información
Dentro de esta área, la gerencia de TI está preocupada por su propio gobierno: ¿Cómo saber que la dirección seguida y el retorno obtenido son los esperados? ¿Cómo determinar la propia capacidad de transformación, de mejora de las operaciones actuales, así como de manejo del ambiente de control dentro de las cuales se debe operar?

¿Qué hacemos?

Mucho se dice de donde deberíamos estar, que estándares adoptar, que certificaciones obtener, entre otros. Pero el paso previo que debemos realizar siempre, es conocer el “donde estamos”. Resulta casi imposible definir el objetivo a alcanzar, así como trabajar en cómo y cuándo alcanzarlo, si no sabemos nuestro estado inicial.

En este punto es donde se recomienda adoptar como marco referencial a COBIT, ya que es el complemento tecnológico para COSO, que es el marco de control recomendado por los organismos de supervisión.

La principal utilidad de COBIT en esta etapa, es que nos permite comparar nuestros elementos de control interno TI con las mejores prácticas. Una vez realizada esta comparación con COBIT, tendremos el punto de partida. Ahora debemos trabajar en base a los riesgos propios del negocio, regulaciones específicas y los más importante, las definiciones como Gobierno Corporativo de cuál es el grado de madurez que se requiere para el área de TI, y cuál es el nivel de control interno que la compañía define.

A quienes ya estén embarcados en proyectos de este tipo, y a quienes en un futuro lo harán, recuerden que concentrar los esfuerzos en las etapas iniciales (identificación del punto de partida) disminuye el esfuerzo en las etapas de implementación, les deseo a todos éxito en sus proyectos.

Autor: Víctor Muñoz, Senior Manager IT Advisory KPMG en Chile