sOLuCIONEs pRÁCTICAs
Riesgo Total
Riesgo Inaceptable –
eliminado
Riesgo Inaceptable
controlado
Riesgo Residual
Riesgo Aceptable
Riesgo No Identificado
Riesgo Residual
o relacionados. Los riesgos pueden ser de
alguna de las siguientes clases:
1. Riesgo identificado – Esto es un riesgo
que es identificado en función de la
experiencia anterior o como resultado
de un análisis del proceso. Una vez
identificado, también pueden calcularse
los costos asociados con su mitigación o
evasión.
2. Riesgos no identificados – Estos son
riesgos que no han sido identificados en
el proceso utilizando experiencias anteriores o herramientas de análisis. Dado
que estos riesgos no están identificados,
no pueden ser medidos o mitigados.
Generalmente son descubiertos al analizar fallas ocurridas.
3. Riesgo total – La suma de los riesgos
identificados y los no identificados.
Cuanto más establecido está el proceso,
mayor es la proporción de riesgos identificados versus los no identificados.
4. Riesgo aceptable – El esfuerzo de eliminar un riesgo puede ser mayor que su
efecto. Algunas veces puede ser aceptable incluso un riesgo importante, si
su eliminación pone en peligro el éxito
del proceso mismo. Como se indicó
anteriormente, éstas son decisiones
subjetivas.
5. Riesgos inaceptables – Estos son riesgos que no pueden ser tolerados en
el proceso. Deben ser eliminados o
minimizados.
6. Riesgos residuales – Son los riesgos que
aceptables o que no han sido identificados en el proceso.
Es importante entender la relación entre
las distintas categorías de riesgo. Un determinado riesgo puede ser recategorizado de
distintas maneras en distintos momentos
en el proceso del ciclo de vida debido a la
subjetividad en la evaluación y el proceso
de análisis.
www.acams.org/espanol
Ejemplo
Para ilustrar algunos de los conceptos
indicados analicemos una cadena hipotética de eventos en un banco mediano:
El banco adquiere sus listas de vigilancia a un proveedor. El vendedor de la lista
publica las actualizaciones a las listas de
vigilancia viernes por medio. Estas actualizaciones requieren depurar la lista vieja
y recargar la lista nueva. El proceso de
actualización es manual y está detalladamente documentado. El proceso ha estado
en funcionamiento durante dos años. Ese
viernes en particular (coincidentemente a
fin de mes) el operador del sistema de vigilancia que normalmente cumple esta tarea
no fue a la oficina y no estaba programada
su ausencia. Él le pidió a la operadora del
centro de datos que lo reemplazara. Esto
había sido autorizado por el supervisor en
varias ocasiones, pero en este caso no se
había solicitado ningún permiso. Si bien la
operadora estaba familiarizada con el proceso de carga de la lista, ella no era parte
del equipo de vigilancia del programa y
no conocía detalles como el tamaño de la
lista, el tiempo promedio de carga, etc.
Si bien no se sabe qué fue lo que no
funcionó — el dispositivo de conexión
había sido desconectado unos meses antes
para ahorrar espacio en el disco — solo se
descargó una pequeña porción de la lista
completa. La lista parcial reemplazó a las
listas completas de la OFAC, SDN y otras
listas de vigilancia obligatorias utilizadas
por el banco para sus operaciones globales. El lunes siguiente, un operador de
vigilancia dio la alarma luego de notar que
se había producido una cantidad inusualmente menor de alertas en el procesamiento de fin de mes. Luego de realizada
la investigación, se descubrió el problema.
Es muy probable que no se haya producido ningún daño y que lo máximo que
haya habido que hacer es volver a realizar
el trabajo y atender a algunos clientes iracundos, pero estoy seguro que el departamento de auditoria y posiblemente los
reguladores considerarían que estoy fue
muy negativo. Si no fuera por el operador
de vigilancia, hubiera sido mucho peor.
Analicemos lo anterior en términos de
los principios ORM y las clases de riesgos que existían en el proceso indicado.
El primer principio — no asumir riesgos
innecesarios— fue violado por hacer que
una tarea fundamental sea realizada por
alguien que no estaba capacitado adecuadamente. De manera similar, la desconexión de un dispositivo de conexión
detallado para ahorrar espacio en el disco
que impidió que el banco descubriera la
cadena de eventos correcta que llevó al problema — no fue evaluada adecuadamente
para determinar su riesgo. La decisión de
sustituir al operador del sistema de vigilancia por un operador del centro de datos
no fue tomada en el nivel apropiado. Y
fi nalmente no se estaba aplicando ningún
control para detectar este problema, ni se
habían elaborado planes al respecto.
En cuanto a la tecnología del banco, el
riesgo de desconectar el dispositivo de
conexión era un riesgo conocido y aceptable. Pero el hecho de que pudo ocurrir un
error sin que generara ninguna alarma en
el sistema fue un riesgo no identificado.
Por favor analice el ejemplo anterior
para detectar otras violaciones de los principios o de las clases de riesgos. Es subjetivo y distintas personas que observen
los mismos pueden llegar a conclusiones
diferentes.
Los seis pasos del ORM
La implementación del ORM puede ser
dividida en seis etapas. Cada una de estas
etapas es importante y debe ser completada
diciembre–Febrero 2010
|
acams today
29