La Auditoría de TI aplicada al proceso de

La Auditoría de TI aplicada al proceso de
Prevención de Lavado de Dinero Eduardo Ritegno BNA Mayo de 2009 NOTAS: ____________________________________________________________ ___________________

Temario Definición del Lavado de Activos / Mecanismos /Características. Categorías de Riesgos (enfoque Basilea II) y su relación con PLD y TI. El Marco de Gobierno Corporativo y Gobierno de la TI – COSO/COBIT. El Marco de Control Interno para PLD y TI. Evaluación de Riesgo – Mejores Prácticas. Tipos de Sistemas de PLD y modelo de Controles. Alertas y tipología de Reglas y Perfiles del Sistema. Módulos del Sistema de PLD y esquema general de Procesamiento. Practicas de control para la Auditoria de TI – Mejores Practicas. Mitos y Conclusiones. NOTAS: ____________________________________________________________ ___________________

Definición de Lavado de Dinero y Etapas del Proceso
“El lavado de dinero puede ser definido generalmente como el proceso de ocultamiento de la existencia, fuente ilegal, o aplicación de ingresos derivados de una actividad delictiva, y el consecuente ocultamiento de la fuente de ese ingreso para hacerla aparecer legitimo” NOTAS: ____________________________________________________________ ___________________ 3

Definición de Lavado de Dinero y Etapas del Proceso
Tiene tres etapas definidas La colocación de fondos de origen ilícito en el mercado financiero legítimo La estratificación de esos fondos de manera de disfrazar su origen, o pertenencia con sucesivas transacciones financieras (Ej. Cheques de Viajero, transferencias, etc.) La integración de los fondos utilizando transacciones aparentemente licitas (Ej. Recompra de cheques, uso de fondos de tarjetas previamente depositados, recepción de transferencias etc.) Banco A Banco B Banco C Banco D Banco E Banco F Banco G NOTAS: _______________En la estratificación intervienen numerosas personas de manera de que no se pueda rastrear el dinero _____________________________________________ ___________En la integración se adquieren bienes o también se reinvierte en el sistema para continuar realizando operaciones. _________________________________________________ ____________________________________________________________ Banco H Empresa Legítima ___________________ 4

Características del Lavado de Dinero
Ser un delito de cuello blanco. Ser un conjunto de operaciones complejas y de difícil detección especialmente cuando se realiza en el ámbito internacional. Crear la apariencia de que los fondos ilícitos tienen un origen legal. Ser un fenómeno globalizado y de dimensiones internacionales. Servirse de los instrumentos del sector financiero y de sus avances tecnológicos. NOTAS: __TRANSFERENCIAS INTERBANCARIAS EN TIEMPO REAL BANCA POR INTERNET ETC.__________________________________________________________ ____________________________________________________________ ___________________ 5

Riesgos Primarios del Lavado de Activos – Comité de Basilea
Cumplimiento Riesgo de sanciones normativas, perdida financiera material, pérdida de reputación que un Banco puede sufrir a causa del no cumplimiento de las leyes y códigos de conducta aplicables a sus actividades bancarias (Basilea Abr 2005) El lavado de activos representa un riesgo desde el punto de vista del cumplimiento. El panorama es complejo debido a que: En el marco nacional/internacional hay muchas leyes, reglamentaciones y principios que tienen cierto grado de superposición. (FATF/GAFI, UIF/FINCEN, FFIEC, A”4459”, Ley Patriota, SOX, Principios Wolfsberg) Comúnmente es necesario tener una correspondencia para ciertos aspectos que son cubiertos por mas de una reglamentación/ley. Resulta difícil reconciliar estos problemas con las observaciones de los reguladores y de los defensores del gobierno corporativo acerca de la necesidad de una supervisión continua y el valor de las acciones de cumplimiento. NOTAS: ____NORMALMENTE LAS UNIDADES FINANCIERAS y los REGULADORES DE CADA PAIS INCORPORAN LAS DISPOSICIONES INTERNACIONALES SOBRE LAVADO ____________________________________________________________ AUN ASI MUCHAS INSTITUCIONES ENFOCAN PRIMARIAMENTE EL GUARDADO DE REGISTROS Y REGLAS FIJAS DE REPORTE EN LUGAR DE TOMAR UN MODELO DE CONOCIMIENTO DEL CLIENTE KYC QUE ES EL FUNDAMENTO DE UN PROGRAMA SOLIDO DE PLD ____________________________________________________________ TIENE MAS PESO EN EL CASO DE BANCOS CON PRESENCIA INTERNACIONAL ____________________________________________________________ ___________________ 6

Riesgos Primarios del Lavado de Activos – Comité de Basilea
Operativo/Tecnológico El riesgo operativo se define como el riesgo de pérdida debido a la inadecuación o a fallos de los procesos, el personal y los sistemas internos o bien a causa de acontecimientos externos. Esta definición incluye el riesgo legal, pero excluye el riesgo estratégico y el de reputación. (Jun 2004) Res A”4793” De todos los riesgos este es el mas extendido, particularmente en operaciones complejas como es el tema de Lavado de Dinero. Se logra un mejor control: Documentando los procesos de evaluación de riesgos, supervisión y proceso de gobernabilidad relacionado. Realizando un análisis de brecha para identificar proceso por proceso cuales son los riesgos inherentes y los controles que se especifican y requieran algún tipo de remediación Trabajando con estándares internacionales de TI y con las regulaciones locales de TI. BASE DE DATOS DE EVENTOS DE RIESGO 4609 SOX ITIL CMMI ISO27001 COBIT_____________________________________________ ____________________________________________________________ ___________________ 7

Riesgos Derivados del Lavado de Activos – Comité de Basilea
Reputacional Si bien el Comité reconoce la dificultad de estimar este riesgo, básicamente se puede dar como una falla de control que convierta al Banco en vehículo de una acción dolosa o víctima de un crimen financiero. Lo que daría lugar a una observación o una acción/sanción de cumplimiento por parte de los reguladores o entes de contralor. Este riesgo es un derivado del de Cumplimiento. Lo establece como un riesgo secundario. Estratégico NOTAS: Debido a su naturaleza, y a su habilidad de mover fondos rápidamente, el sistema bancario es especialmente vulnerable al lavado de dinero. ____________________________________________________________ Es un riesgo inherente a cualquier proceso de negocio. Ser vulnerable al Lavado de Dinero se convierte en riesgo estratégico en si mismo cuando la empresa pierda su habilidad para planear o implementar cambios efectivamente y simplemente evalúe que es riesgoso continuar con ese tipo de operaciones y deba discontinuarla. ___________________ 8

PLD – Dos grandes pasos Para lograr un programa efectivo de Prevención de Lavado de Dinero básicamente se debe lograr un balance enfocándose en: Las políticas y procesos con buenos estándares de cumplimiento de las legislaciones y reglamentaciones Complementar estos esfuerzos con el soporte de la TI. Desempeño Cumplimiento NOTAS: ____________Los principios de Desempeño y Cumplimiento hacen al Gobierno Corporativo ________________________________________________ ____________________________________________________________ Esto se logra con una adecuada solución tecnológica y funcional dentro de un marco de Gobierno de la TI y las buenas practicas. ___________________ 9

i PLD – Dos grandes pasos
“Es Clave la Alineación Estratégica de la TI con la necesidad operativa” Los Recursos de TI y Procesos de TI -> brindan la información para Los Procesos de Negocio -> que responden a Los Objetivos del Negocio. i Recursos de TI y Procesos Información Procesos de Negocio Objetivos de Negocio proveen para para lograr NOTAS: ____________________________________________________________ ___________________ 10

Enfoque COSO – Marco de Control Interno
El modelo COSO no trata específicamente todo lo referido a la administración de la información y la tecnología de la información. Sin embargo la TI es una parte implícita dentro de cualquier marco de Control Interno independientemente del tipo de riesgo que se trate: Reporte Financiero Cumplimiento Operacional COSO: Efectividad y eficiencia de las operaciones Confiabilidad del reporte financiero Cumplimiento de las leyes y reglamentaciones ____________________________________________________________ Consecuentemente el riesgo tecnológico es un factor importante en el enfoque de riesgo operacional de la organización. ___________________ 11

Enfoque COBIT – Marco de Control Interno
El modelo COBIT brinda un marco de trabajo para todos los procesos de TI, los objetivos de control y las actividades que en definitiva se adaptan al tratamiento de riesgo de TI COBIT acorta la brecha entre la administración de riesgos de alto nivel y los riesgos específicos de la TI. NOTAS: ____________________________________________________________ Los recursos de TI son administrados por los procesos de TI. parar lograr los objetivos/metas de TI que responden a los requerimientos del negocio. Este es el principio básico del marco de trabajo COBIT, como se ilustra en el cubo. ___________________ 12

OBJETIVOS DEL NEGOCIO Y
El Marco de Trabajo COBIT OBJETIVOS DEL NEGOCIO Y OBJETIVOS DE GOBIERNO INFORMACION ME1 Monitorear y Evaluar el desempeño de TI ME2 Monitorear y evaluar el control interno ME3 Garantizar el cumplimiento regulatorio ME4 Proporcionar Gobierno de TI MARCO DE TRABAJO C O B I T PO1 Definir un plan estratégico de TI PO2 Definir la arquitectura de la información. PO3 Determinar dirección tecnológica. PO4 Definir los procesos, organización y relaciones de TI. PO5 Administrar la inversión en TI. PO6 Comunicar las aspiraciones y dirección de la gerencia. PO7 Administrar los recursos humanos de TI. PO8 Administrar la calidad. PO9 Evaluar y administrar los riesgos de TI. PO10 Administra proyectos. Eficiencia Integridad Efectividad Disponibilidad MONITOREO Y EVALUACION Cumplimiento Confidencialidad PLANEAR Y ORGANIZAR Confiabilidad DS1 Definir y administrar niveles de servicio. DS2 Administrar los servicios de terceros. DS3 Administrar el desempeño y la capacidad. DS4 Garantizar la continuidad de servicio. DS5 Garantizar la seguridad de los sistemas. DS6 Identifica y asignar costos. DS7 Educar y entrenar usarlos. DS8 Administrar la mesa de servicios DS9 Administrar la configuración. DS10 Administrar problemas. DS11 Administrar datos. DS12 Administrar el entorno físico. DS13 Administrar operaciones. RECURSOS DE TI COBIT Provee Objetivos de Control para administrar el Ciclo de Vida de la TI _______________________________ 4 dominios 34 procesos o Objetivos de Control de Alto Nivel de TI 215 Objetivos de Control detallados _________________________________________________________ Aplicaciones Información Infraestructura Gente ENTREGAR Y DAR SOPORTE ADQUIRIR E IMPLANTAR AI1 Identificar soluciones automatizadas. AI2 Adquirir y mantener software aplicativo. AI3 Adquirir y mantener infraestructura tecnológica. AI4 Facilitar la operación y el uso AI5 Adquirir recursos de TI . AI6 Administrar cambios AI7 Instalar y acreditar soluciones y cambios. ___________________ 13

COBIT se corresponde en un 100% con COSO
Relación COSO - COBIT COSO divide el control interno en cinco componentes los cuales deben cumplirse para lograr los objetivos de un programa de control integrado. COBIT provee similares directrices para la TI a través de sus controles generales en sus cuatro dominios. El cubo compuesto establece que existe mas de una relación de cada dominio de COBIT con los componentes COSO. Esto es esperable dado que la naturaleza de los controles generales de la TI establecen la base de respaldo para los controles de las aplicaciones. AMBIENTE DE CONTROL EVALUACION DE RIESGO ACTIVIDADES DE CONTROL INFORMACION Y COMUNICACION MONITOREO PLANEAR ORGANIZAR ADQUIRIR IMPLEMNTAR ENTREGA Y SOPORTE EVALUACION Los requerimientos funcionales y de control vienen del lado del negocio Los controles generales de TI son la base para un marco confiable del ciclo de vida de la TI Los servicios automáticos son el producto del ciclo de vida de la tecnología de la información En la práctica, esta relación demuestra que los controles de TI son la base para otros controles y establecen el basamento de un programa de control interno confiable. COBIT se corresponde en un 100% con COSO ___________________

Marco de Control Interno para PLD y TI
Ambiente de Control: Antes de que el auditor se adentre en los procesos de negocio relevantes que dan origen a los procesos de TI y sus controles, conviene evaluar el esquema de control interno y como se relaciona con el cumplimiento de los reportes reglamentarios y de Actividad Sospechosa (SAR/STR). Es clave para el ambiente de control de PLD: El involucramiento de los gerentes en las políticas aprobadas por el directorio. El mensaje y la postura que se transmite al nivel de la organización respecto de la problemática. El conocimiento de los empleados sobre la letra y el espíritu del tema y la frecuencia de las comunicaciones internas. Las directrices de la política de conozca a su cliente (KYC). El impacto de esta política en los controles de las aplicaciones de TI. NOTAS: El ambiente de control es la base del control interno efectivo __________________________________ ____________________________________________________________ ___________________ 15

Evaluación de Riesgos: Básicamente la institución debe estar protegida de los cuatro tipos de riesgos ya mencionados (según Basilea). La evaluación de estos riesgos dará la base para desarrollar las actividades de control. Es clave saber como se tratan estos temas en el comité de PLD encabezado por el oficial de cumplimiento con la presencia de los representantes de diferentes unidades de negocio. Los miembros del comité deben participar de evaluaciones periódicas del riesgo con resultados elevados al directorio, enmarcado en un programa de mejora continua de los programas internos. Se deben considerar además los riesgos inherentes de la TI, al nivel de seguridad de datos, integridad y controles de cambio. Es importante contar con indicadores de los SAR/STR emitidos y compararlo contra empresas de similar envergadura o actividad. NOTAS: ___________En la organización es probable que los riesgos estén mas extendidos en las áreas de TI que en otras áreas de la compañía. Para eso están los controles generales de COBIT para TI. _________________________________________________ Riesgos de Cumplimiento Operativo / Tecnológico Reputación Riesgo Estratégico ______________________________________________________ ____________________________________________________________ ___________________ 16

Actividades de Control: Los auditores deben revisar las minutas a fin de identificar si se efectúan las acciones correctas o si hay alguna intención de modificar las políticas. Evaluar como se define en las mismas, el apetito de Riesgo de la Organización. Validar si las políticas y procedimientos están correctamente aplicados y como se relacionan con la TI. Desde el punto de vista de TI es imposible que se genere información confiable si no existen controles de TI efectivos (COBIT). Se deben revisar los controles referidos a: Operaciones del Centro de Datos Controles en el Software Aplicativo Seguridad de las aplicaciones Desarrollo y mantenimiento NOTAS: Son las políticas y los procedimientos y las actividades que conforman mecanismos que aseguren que las mismas sean cumplidas como fueron planeadas ____________________________________________________________ ___________________ 17

Información y Comunicación: Se debe evaluar la información estratégica que impulsan los procesos SAR / STR / ROS de PLD en cuanto a su calidad, oportunidad, precisión. Determinar que información es necesaria para lograr los objetivos de control del proceso de PLD y que a su vez la misma se comunique en un marco de tiempo adecuado para permitir que se lleven a cabo las tareas del proceso. La auditoria de TI se debe focalizar en los procesos automáticos, las herramientas y los reportes utilizados tanto para el monitoreo, como el escalamiento de la investigación y el soporte de la actividad sospechosa. Se deben evaluar los esquemas de reporte que requieren para comunicarse con los entes de control UIF/FIU y el entrenamiento en los mismos. Se deben verificar los diferentes tipo de accesos Web (BSA e-filing) Interfases automáticas, formularios (FINCEN u otras UIF/FIU) Encriptación de datos necesarios para el reporte. NOTAS: COSO define que la información es necesaria en todos los niveles de la organización y para llevar adelante el negocio y lograr los objetivos de control. Este tema se ha convertido en un desafío para las áreas de TI que cada vez se incrementa mas ___________________________________________________________ ____________________________________________________________ ___________________ 18

Cumplimiento y monitoreo: Tanto de las reglamentaciones como las funciones automáticas soportadas por el sistema de PLD en función de los requerimientos del negocio, y el monitoreo de transacciones sospechosas. Con cada vez mas frecuencia el desempeño y la efectividad de la TI son monitoreadas con indicadores y métricas que evidencian si las actividades de control están funcionando efectivamente. En el marco COBIT se proveen indicadores de desempeño y metas en las directrices gerenciales al nivel de cada Objetivo de Control. En el caso de PLD esto es fundamental para establecer la calidad y la eficiencia de los sistemas implantados que dan soporte al monitoreo. Esto no debe ser confundido con una prueba independiente de las transacciones o de la efectividad del programa de PLD, tal como lo establecen las “buenas practicas”. NOTAS: El monitoreo incluye también la supervisión del Control Interno y desde el punto de vista de la TI cada vez cobra mas importancia para la gerencia de TI _____________________________________________ ____________________________________________________________ ___________________ 19

Mejores practicas – Evaluación del riesgo
El foco primario para la demostración de una “mejor practica”, es que el enfoque de prevención de lavado de dinero sea basado en riesgo, y proporcional al riesgo. Lo que significa que primero se debe analizar e identificar el nivel de riesgo que debe ser administrado por cada cliente, lo cual implica: Una tipificación del cliente. Una estratificación de los mismos en función de su actividad financiera esperada. Esto también se relaciona con la dimensión de los sistemas a implementar descartando aquellos que no puedan brindar un nivel de servicio requerido para esta temática. Concretamente en lo que se refiere a los sistemas automáticos de detección, que servirán para la generación de las alertas de la actividad sospechosa y el tratamiento de las investigaciones. NOTAS: ____________________________________________________________ ___________________ 20

Evaluación del Riesgo – Lecciones aprendidas
Considerar a todos los clientes como iguales, básicamente sabotea el propósito de la evaluación de riesgo. Aun mas, lo que aparentemente se presenta como una solución fácil, luego resulta “difícil de poner en practica”. La evaluación del riesgo de PLD es un arte y no una ciencia. Se necesita poner en práctica el esquema de “prueba y error” probando la metodología con la participación y la revisión de los resultados por parte de todos los departamentos afectados por el proceso de negocio. (Cumplimiento, Líneas de negocio, Oficiales de cuenta y Operaciones como así también la Gerencia superior). Se deben revisar los resultados de las pruebas y trabajar en forma colaborativa para refinar la metodología hasta tenerla estabilizada. Una vez lista la metodología, se debe considerar el entrenamiento en la misma. NOTAS: ________CICLO DE DEMING PLAN DO CHECK ACT ESTRATEGIA DE MEJORA CONTINUA DE LA CALIDAD ____________________________________________________ ____________________________________________________________ ___________________ 21

Evaluación del Riesgo – Esquema practico
Cuando se efectúa una evaluación de riesgo, el foco debe estar centrado en el riesgo inherente mas que en el riesgo residual KYC Riesgo Geográfico Productos y Servicios Riesgo de Cliente Respuesta al Riesgo (Controles) Análisis Respuesta Impacto y Probabilidad Cantidad de Riesgo Riesgo Residual Acciones Las actividades especificas para las que el lavado de dinero sea relativamente alto incluyen: • Clientes que usan frentes (por Ej. Fideicomisos, corporaciones, intermediarios profesionales) para abrir una cuenta y ocultar su verdadera identidad. • Operaciones de la banca privada, que por naturaleza involucran una gran cantidad de confidencialidad. • Clientes que son personas políticamente expuestas (PEPs) pueden elevar significativamente el riesgo de la reputación. • Negocios de introducción, donde el banco puede tener confianza indebida sobre la debida diligencia realizada por la parte que presenta. • Negocios bancarios correspondiente, especialmente cuando los bancos no comprenden totalmente la naturaleza de los negocios bancarios que responden, o si los respondentes son bancos extraterritoriales (offshore) localizados en jurisdicciones que tienen bajos estándares para conocer al cliente. Identificar los Factores de Riesgo Evaluar la cantidad de Riesgo Evaluar la Calidad del Riesgo Plan de Acción/Táctico Como se materializa el RIESGO en el sistema  Con los patrones inusuales de transacciones ___________________

Características de los sistemas de PLD
Una clasificación primaria de los tipos de sistemas se basa en la calidad y eficiencia de sus motores de búsqueda. Sistemas Manuales: Filtran únicamente por una regla como por Ejemplo transacciones mayores a $ ,- Sistemas Automáticos: Basados en Reglas : Filtran en función de múltiples reglas y perfiles de Clientes/KYC. Inteligentes: Con las mismas características, mas búsqueda de tendencias. SISTEMAS PLD MANUALES AUTOMATICOS BASADOS EN REGLAS INTELIGENTES NOTAS: _________DE LOS SISTEMAS AUTOMATICOS APROX EL 20% SON INTELIGENTES Y EL RESTO (80) POR REGLAS, ULTIMA ENCUESTA AÑO 2007 ___________________________________________________ ____________________________________________________________ ___________________ 23

Características de los sistemas Automáticos de PLD
Identifican transacciones individuales o patrones de actividad inusual o desviaciones de la actividad esperada. Estos sistemas pueden capturar un amplio rango de actividad en cuentas como depósitos y extracciones transferencias, Clearing, transacciones de Cajeros Automáticos directamente de los sistemas CORE de las instituciones financieras. La carga de los datos provenientes de las aplicaciones CORE o LEGACY de los bancos se realizan a través de mecanismos de ETL, de extracción transformación y carga (Requiere una correspondencia de datos – “Mapping”). Almacenan toda la información extraída en una Base de Datos específica, que reserva la información histórica por largos períodos de tiempo. Todos los bancos que tienen gran cantidad de cuentas o que operan en diferentes locaciones, tienen este tipo de sistemas (típicamente). NOTAS: __Sistemas pueden estar desarrollados internamente o adquiridos a terceros __________________________________________________ ____________________________________________________________ ___________________ 24

Sistema Automático Basado en reglas de PLD
Detectan las transacciones inusuales que no cumplan las reglas establecidas por la gerencia. Los esquemas consisten en pocas o muchas reglas dependiendo de la complejidad del sistema y de la organización. Las reglas se aplican tomando una serie de filtros transaccionales o motor de reglas. Son mas sofisticados que aquellos sistemas manuales que solamente filtran por una regla. Pueden aplicar filtros múltiples o complejos. Por ejemplo primero a todas las cuentas y luego a un subset de las mismas, dependiendo de la categoría de riesgo (Determinado tipo de cliente). Pueden filtrar por perfiles individuales asignado a una cuenta en particular y realizar consultas del tipo Ad-Hoc en función de una investigación que no respondan a una regla definida. NOTAS: ____________________________________________________________ ___________________ 25

Sistema Automático Inteligente de PLD
Son sistemas adaptativos que pueden cambiar su análisis a lo largo del tiempo basados en varios factores como patrones de actividad, tendencias recientes, cambios en la base de clientes u otros factores trabajan a lo largo de la organización en función de la actividad de los clientes y transacciones históricas. Cargan los datos transaccionales y la información de clientes en una Base de Datos con un motor multidimensional del tipo OLAP (“On line Analytical Processing”), pueden detectar actividades sospechosas que no responden a una regla específica. Estos sistemas transforman dinámicamente el riesgo complejo en una modelización de riesgo de manera que los algoritmos puedan ser usados para detectar la actividad sospechosa con una mejor precisión y eficiencia. Usan cubos de Base de Datos similares a los de un sistema de “Data Warehousing” o “Data Mining”. Presentan gráficos de relaciones entre cuentas, flujos de fondos y Tableros de Control. NOTAS: _______________permiten modelar el riesgo sin contar con una regla definida. Usan modelos Bayesianos de análisis de riesgo o Heurísticos. _____________________________________________ ____________________________________________________________ ___________________ 26

Esquemas de controles – manuales o automaticos
El costo de prueba y documentación de controles se incrementa para los controles manuales debido a que los mismos requieren mayor cantidad de horas de pruebas. Los controles automáticos cuando trabajan en un ambiente confiable de controles generales de la TI (Desarrollo, Control de Cambios, Seguridad de programas y datos y Operaciones) requieren menor cantidad de horas de prueba una vez implementados. COSTO DE IMPLEMENTACION Y PRUEBAS DE LOS CONTROLES CONTROLES MANUALES NOTAS: Si bien los controles manuales son mas fáciles de implementar son mas difíciles de probar y requieren mayores frecuencia de revisión debido a los errores humanos. Los controles automáticos requieren mayor desarrollo pero menos prueba Especialmente en empresas donde se requiere un cumplimiento sostenido.____________________________________________________________ ____________________________________________________________ TAMAÑO Y COMPLEJIDAD DE LA ORGANIZACIÓN CONTROLES DE APLICACION ___________________ 27

Capas de controles en sistemas de PLD
Cuentas Tendencias inusuales / Consultas AD HOC Detección en función de reglas- Escenarios Efectividad Detección de relaciones ocultas Cruzamiento listas OFAC/FinCen/PEP NOTAS: ______Reglas Heurísticas para detectar relaciones ocultas Fuzzy Logic (logica difusa) para detectar nombres similares en el cruzamiento de listas ______________________________________________________ ____________________________________________________________ Evaluación de Riesgo - Cuentas ___________________ 28

Regularidad en la revisión
Escalera de Controles de PLD en la Organización INDEPENDENCIA Regularidad en la revisión EVALUACIONES INDEPENDIENTES Auditoría Interna o Externa MEJORAS EN CONTROLES NUEVAS EVALUACIONES DE RIESGO Cumplimiento / Crimen financiero PRUEBAS REGULARES EN LA EFECTIVIDAD DE CONTROLES TRATO CON EL CLIENTE MONITOREO DIARIO PLD Operaciones /Front Office NEGOCIO ___________________

Las alertas se generan cuando se rompe una regla establecida
Alertas del sistema de PLD – Tipos de Error Las alertas se generan cuando se rompe una regla establecida Falsos Positivos: Estadísticamente Error del Tipo I que implica detectar una operación como sospechosa cuando en realidad no lo es. Un exceso de transacciones falsos positivos que sean detectadas como sospechosas por sistemas automáticos que luego resulten ser no problemáticas en la práctica es otro problema común. De no encontrarse un balance adecuado en los limites de detección se pueden llegar a cuadruplicar los costos de revisión de las áreas de cumplimiento (EDD) cuando la tasa de falsos positivos es demasiada alta. Falsos Negativos: Estadísticamente Error del Tipo II que implica no detectar una operación como sospechosa cuando en realidad lo es. Por otra parte no tendríamos sobrecarga operativa por un falso negativo, aunque las consecuencias de este tipo de error estaría directamente relacionada con un mal enfoque de riesgo cuando se establecieron las reglas. NOTAS: ___________RED FLAG _________________________________________________ ____________________________________________________________ ___________________ 30

Tasas de Investigación de alertas en función del tipo de sistema
Los sistemas basados en reglas tienen normalmente una tasa del 1% de investigaciones reales en función de las alertas que se presentan como pasibles de ser investigadas Los sistemas que analizan tendencias y presentan las mismas en combinación con las reglas establecidas, tienen normalmente una tasa del 15% de investigaciones reales en función de las alertas que se presentan como pasibles de ser investigadas ___________________

ALERTAS > INVESTIGACIONES/CASOS > REPORTES (SAR/STR)
Tasas de Investigación de alertas en función del tipo de sistema En ambos casos los porcentajes de alertas e investigaciones se reducen drásticamente en función de las siguientes alternativas: Una baja rotación de la cartera de Clientes Repetición de tendencias que como resultado de investigaciones anteriores fueran desestimadas por el investigador Incorporación a las reglas del sistema de las alertas por tendencias que se dan en forma reiterativa Recordar la siguiente relación ALERTAS > INVESTIGACIONES/CASOS > REPORTES (SAR/STR) ___________________

Esquema básico del “Workflow” de análisis de casos
Investigador de Debida Diligencia NIVEL 1 NO Aprobación de la investigación NIVEL 2 SUFICIENTE SI NO Intervención del Of. Cumplimiento NIVEL 3 SUFICIENTE SI DESESTIMACIÓN DEL CASO NO Este flujo corresponde al circuito dado según un reporte de alertas no desestimado. El sistema debería manejar este circuito dentro de un caso cuando una cuenta rompe mas de una regla establecida. SAR SI Emisión del SAR/STR ___________________

Tipología de los perfiles de un sistema PLD
Perfiles Globales o Generales (Afectan a todo el sistema) Universales por Tipo de Cliente (Afectan a la tipificación del cliente) Perfiles Estándar Perfiles personas Jurídicas (Bancos/Compañía Seguros/Agencia de Viajes/Particulares) Perfiles personas Físicas Perfiles estratificados por el conocimiento del Cliente (KYC) “Mejor práctica” Ejemplo: No es lo mismo. $ para un Empleado de Comercio que para un Gerente de una Empresa $ para una PYME que para una Corporación. NOTAS: ____________________________________________________________ ___________________ 34

Tipología de Reglas de detección de un Sistema de PLD
Todos los cables o transferencias en los cuales el beneficiario y el ordenante son la misma persona Todos los cables o transferencias en los cuales la dirección del beneficiario es la misma que la dirección del ordenante Criterios opcionales número de transacciones > 3 y monto mayor a $50000 Cheques de viajero buscando por Originante persona/Banco, Moneda, Cantidad. Transferencias de cliente mayores a cierto monto Criterios opcionales fechas desde/hasta. Transferencias ordenadas por el mismo ordenante con el mismo beneficiario Criterios opcionales mayor a 10 transacciones o la Suma de transacciones superior a determinado monto. Las reglas representan los factores de Riesgo Las alertas se generan cuando se rompe una regla establecida. ___________________

Tipología de Reglas de detección de un Sistema de PLD – Cont.
Cheques depositados para el mismo beneficiario Criterio opcional mayor a 2 operaciones y la suma de importes mayor a $10000 Cheques depositados del mismo librador o cuenta. Criterio opcional mayor a “x” cheques o suma mayor a “x” importe. Múltiples depósitos en Cajeros Automáticos en diferentes locaciones para una misma cuenta o cliente. Cheques recibidos del clearing con el mismo beneficiario Criterio opcional mayor a 1 transacción y monto mayor a cierto importe Cheques por cifras mínimamente inferiores a los criterios de reporte por ejemplo si es $10000 –> Cheques por $ 8999 o $ 9999 ___________________

Tipología de Reglas de detección de un Sistema de PLD – Cont.
Transferencias entrantes ordenadas por beneficiario y remitente común dentro de los beneficiarios Criterios adicionales número de transacciones mayor a 3 y suma mayor a $25000 Transferencias mayores a determinado monto para clientes particulares Pagos SWIFT no del país Pagos salientes ordenado por un beneficiario en común dentro del ordenante Transferencias salientes ordenadas por Ordenante con criterios de suma mayor a 5 o monto mayor a $50000 Velocidad para Corporaciones (Para todas las transacciones) Ejemplo: mas de tres transacciones debito que sumen mas del 75% del monto de un crédito en cuenta Velocidad para individuos: Ídem dentro de los 3 días de depositada ___________________

Módulos primarios de un sistema de PLD
CIP Programa de Identificación y Aceptación de clientes (CIP) Monitoreo Automático de Transacciones, Calificación de perfiles en función al riesgo (CDD) CDD KYC MOTOR DE REGLAS CALIFICAC. DE RIESGO COTROL DE LISTAS Cruzamiento de la Base de Datos contra filtros (Listas OFAC/FINCEN/etc.) (Manejo de Casos “WorkFlow” para investigación ampliada EDD) Reportes (SAR/CTR) – Impresión y generación de interfases EDD MANEJO DE CASOS NOTAS: PRINCIPIOS BASILEA PARA EL CDD El programa KYC de un banco debe incluir políticas y procedimientos para la aceptación del cliente, identificación del cliente, monitoreo continuo de las cuentas de alto riesgo y administración del riesgo. (parábola 16)__________________________________________________________ Para el caso de CIP los clientes pueden Pedir exceptuarse de proveer su documentación Ser reticentes a proveer documentación El cliente tiene dificultades a describir su negocio o le falta conocimiento El cliente tiene multiples cuentas sin motivo aparente Comparte direcciones con otros clientes ____________________________________________________________ GENERACION DE REPORTES ___________________ 38

Esquema General de un sistema PLD
SISTEMAS CORE / LEGACY BANCO REPORTES SAR / CTR www E T L CUENTAS CORRIENTES CLIENTES TRANSFER SWIFT CLEARING FRONT END / SEGURIDAD MODULOS / SERVIDOR OF. CUMPLIMIENTO ADM. SEGURIDAD BASE DE DATOS MOTOR DE REGLAS SERVIDOR HTTPS ADM. SISTEMA Empezar con Datos de Alta Calidad ETL – Circuitos , manejo de exepciones. Ingresos de datos por fuera del sistema CORE Diferencia entre adm. Seguridad y adm. Del sistema Motor de Reglas – Pruebas de efectividad. Base de Datos – Seguridad – Resguardos de información Reportes SAR/CTR errores en la integración Cruzamiento listas. Alertas de ingreso de novedades. “Watch Lists” CONTROL LISTAS MODULO CIP/KYC ADMINISTADOR DE CASOS LISTAS OFAC / UIF ___________________

Practicas de Control - Evaluación Independiente de PLD
Cuando se evalúa un Sistema aplicado al proceso de PLD un auditor deberá preguntarse: ¿Quién es el dueño y controla el sistema? ¿Cómo se administran las interfases de entrada al sistema? ¿Cómo se determinan los derechos de acceso lógicos al nivel de la aplicación y la Base de Datos? (SOX) ¿Qué tipos de criterio de visualización o reglas utiliza el sistema y quien las establece? ¿Han habido cambios o recalibraciones al sistema desde la ultima auditoría? Y si es así ¿están debidamente justificados y documentados los cambios? ¿Hay alguna excepción de clientes o productos o servicios que no sean capturados por el esquema de monitoreo? ¿Es válido el criterio que soporta tal decisión? ¿Cómo se crean las alertas en el sistema? ¿Funcionan adecuadamente las reglas? (Prueba de transacciones) ¿Cómo es el proceso de escalada de las alertas? ¿Tiene el sistema características de auto cerrado de investigaciones o reportes? ¿quién las dispara? ¿Esta el criterio y el mecanismo para cerrar alertas totalmente documentado? ¿Cómo se generan los reportes de salida e informes del tipo SAR/STR/ROS o CTR/ROE? NOTAS: ____________________________________________________________ ___________________ 40

Practicas de Control - Marco COBIT para la evaluación de PLD
1) ¿Quien es el dueño y controla al sistema? PC2 Definir la pertenencia del sistema – PO4.9 Propiedad de Datos y de Sistemas Asignar dueño para cada proceso de TI, definir claramente las responsabilidades del dueño. Como por ejemplo su diseño e interacción con otros procesos, responsabilidad de rendir cuentas por los resultados. Los propietarios toman decisiones sobre la clasificación de la información. Riesgos: Comportamiento del proceso poco confiable. Mala interacción con otros procesos/ Información de negocio mal protegida. Errores no solucionados. Valor: Procesos operando confiablemente / Reducción en las pérdidas financieras por perdida de la info. Interacción efectiva con el entorno. Problemas claramente identificados y resueltos. Mejora Continua. NOTAS: La definición incluye al propietario de lado de TI como también al propietario del lado del negocio, responsable a su vez de los datos su clasificación y su protección____________________________________________________ ________En cuanto a los dueños de TI definir las responsabilidades y relacionarlas con la estructura y asegurarse que las mismas sean aceptadas por los diferentes roles____________________________________________________ ____________________________________________________________ ___________________ 41

2) ¿Cómo se administran las interfases de entrada al sistema? Enfocar el control en el módulo de ETL – Extracción, Transformación y carga. AI7.5 Conversión de datos y sistemas Planificar la conversión de datos y la infraestructura de migración como parte de los métodos de Desarrollo incluyendo pistas de Auditoría, puntos de recupero de información, tratamiento de excepciones de datos y resultados previos/posteriores de la conversión. Validar las transformaciones (mapa) correspondencia de datos y Totales de Control. Verificar especialmente si se aplican filtros que excluyan registros de clientes, productos o sucursales. En el caso que existan verificar los documentos que soportan tal decisión Riesgos: Falta de integridad en los datos. Resultados poco confiables en la conversión de datos. Perdida de registros. Valor: Nuevo sistema operando como fue diseñado y soportando el proceso de negocio adecuadamente. NOTAS: ____________________________________________________________ ___________________ 42

3) ¿Cómo se determinan los derechos de acceso al nivel de la aplicación y de la Base de Datos? Es importante focalizarse en la integridad de la Base de Datos ya que ninguna transacción será garantizada sin la apropiada seguridad y monitoreo. (SOX) AI2.4 Seguridad y Disponibilidad de la Aplicación Identificar la seguridad y los requerimientos de disponibilidad de la aplicación en respuesta a los riesgos identificados alineados con la arquitectura de la información y la arquitectura de seguridad Riesgos: Violaciones de Seguridad no detectadas. Controles compensatorios Costosos. Brechas entre los controles de seguridad y las amenazas. Valor Seguridad preventiva y detectiva. Asegurar la confidencialidad, integridad y disponibilidad de la información. Mantener la disponibilidad del sistema para el procesamiento del negocio. NOTAS: ____________________________________________________________ ___________________ 43

3) ¿Cómo se determinan los derechos de acceso al nivel de la aplicación y de la Base de Datos? DS5.2 Plan de Seguridad de TI - DS5.3 Manejo de Identidad Asegurarse que todos los usuarios internos externos y temporarios y su actividad en los sistemas sean identificados unívocamente. Asegurarse que los derechos de accesos sean requeridos por la gerencia y aprobados por el Dueño del Sistema e implementadas por el administrador de Seguridad Mantener las identidades de acceso en un repositorio único. Riesgo: Cambios no autorizados al hardware y al software. Gerenciamiento de los accesos no alineado con los requerimientos y comprometiendo al seguridad de los sistemas críticos para el negocio. Violación de la segregación de tareas. Valor: Implementación efectiva de los cambios. Investigación adecuada de una actividad impropia de los usuarios. Comunicación segura asegurando transacciones del negocio aprobadas. NOTAS: ____________________________________________________________ ___________________ 44

4) ¿Qué tipos de criterios de visualización o reglas utiliza el sistema y quien las establece? Las mismas deben ser establecidas por el Oficial de Cumplimiento en conjunto con la Gerencia y el Directorio y con la supervisión de las Unidades Financieras o Reguladores de cada país. AI2.5 Configuración e Implementación del Sistema Aplicativo para cumplir con los objetivos del negocio. ME3.3 Evaluación del cumplimiento con requerimientos regulatorios. Riesgos: Perdida del foco del negocio. Perdidas financieras y penalidades. Falta de identificación de la faltas al cumplimiento que impacten en el desempeño y la reputación de la organización. Disponibilidad e integridad del sistema reducidas. Valores: Contar con un sistema configurado para cumplir con los requerimientos del negocio. Buenas prácticas para el tratamiento con las leyes y regulaciones, incorporadas a la Organización. Es clave contar con la aprobación de los propietarios del proceso para llevar a cabo configuraciones de este tipo de software aplicativo en cuanto a las reglas de proceso. NOTAS: En muchos casos se deberá considerar también que implicancias tiene esta personalización y si requerirá una reevaluación de ciertas estrategias. Se deberán evaluar regularmente los patrones de falta de cumplimiento y realizar una actualización de las politicas en los casos necesarios. AI2.5 Configuración e implantación de software aplicativo adquirido Personalizar e implantar la funcionalidad automatizada adquirida con el uso de procedimientos de configuración, aceptación y prueba. Los aspectos a considerar incluyen la validación contra los términos contractuales, la arquitectura de información de la organización, las aplicaciones existentes, la interoperabilidad con las aplicaciones existentes y los sistemas de bases de datos, la eficiencia en el desempeño del sistema, la documentación y los manuales de usuario, integración y planes de prueba del sistema. ME3.3 Evaluación del cumplimiento con requerimientos regulatorios Evaluar de forma eficiente el cumplimiento de las políticas, estándares y procedimientos de TI, incluyendo los requerimientos legales y regulatorios, con base en la supervisión del gobierno de la gerencia de TI y del negocio y la operación de los controles internos. __________________________________________________________ ____________________________________________________________ ___________________ 45

5) ¿Han habido cambios o recalibraciones al sistema desde la ultima auditoría? Y si es así ¿están debidamente justificados y documentados los cambios? AI6.2 Manejo de Cambios – Evaluación de Impacto. Prioridades y Autorización Todo requerimiento de cambio debe ser evaluado en una forma estructurada para determinar el impacto en el sistema y su funcionalidad. Asegurando su autorización. Riesgos: Problemas Colaterales No identificados. Efectos adversos en la capacidad y el desempeño de la infraestructura. Valores: Análisis de impacto formalmente definidos basados en las expectativas y el riesgo del negocio y la medida del desempeño. Procedimientos de cambio consistentes. Nuevamente contar con la aprobación de los propietarios del negocio. NOTAS: ____________________________________________________________ ___________________ 46

5) ¿Han habido cambios o recalibraciones al sistema desde la ultima auditoría? Y si es así ¿están debidamente justificados y documentados los cambios? AI6.5 Cierre de los cambios y Documentación Asegurarse que cuando los cambios estén implementados toda la documentación y procedimientos relativos este debidamente actualizada Someter la documentación al mismo nivel de pruebas que el cambio mismo. Riesgos: Incremento de la dependencia en individuos clave. Falla en la documentación de configuración en reflejar el estado actual del sistema. Falta de Documentación de los procesos de negocio. Valores: Procedimientos de cambio y documentación consistentes. Expectativas Formalmente definidas. NOTAS: ____________________________________________________________ ___________________ 47

6) ¿Hay alguna excepción de clientes o productos que no sean tomados por el monitoreo?¿Es valido el criterio que soporta tal decisión? ME3.1 Identificación de los requerimientos de cumplimientos legal, regualtorios y Contractuales Asegurarse en una base de continuidad que las leyes locales e internacionales, las reglamentaciones y cualquier otro requerimiento externo que deba ser cumplido, este incorporado en las políticas estándares, procesos (y por consiguiente sistemas) de la Organización. Determinar el impacto que esto tiene en los sistemas Riesgos: Posibles perdidas financieras. Incrementar el riesgo de la continuidad del negocio debido a sanciones impuestas por los reguladores. Riesgo de no cumplimiento debido a la ignorancia de ciertas leyes Identificación de las buenas prácticas. Valores: Mejoramiento de la conciencia de los requerimientos legales. Desempeño mejorado de la Corporación. NOTAS: ____________________________________________________________ ___________________ 48

SE DEBE REALIZAR AL MENOS UNA VEZ AL AÑO
Practicas de Control - Marco COBIT para la evaluación de PLD 7) ¿Funcionan adecuadamente las reglas? Prueba de transacciones ME2.5 Monitorear y Evaluar el control interno – Aseguramiento del Control Interno Los Examinadores/Auditores deben realizar una prueba de las transacciones para evaluar la conformidad del cumplimiento del Banco con los requerimientos regulatorios, determinar la efectividad de sus políticas, procedimientos y procesos y evaluar los sistemas de monitoreo de la actividad sospechosa. La prueba de transacciones es un factor importante para formarse una conclusión de los controles generales y los procesos de administración de riesgos. La prueba de transacciones debe ser hecha en cada evaluación. La extensión de las pruebas y las actividades involucradas se basa en varios factores como por ejemplo el juicio de valor del riesgo que haga el auditor y el alcance esta directamente relacionado y puede abarcar todos los temas identificados o las preocupaciones que surjan durante la evaluación. Los auditores deben documentar su decisión en función de lo anteriormente expuesto. SE DEBE REALIZAR AL MENOS UNA VEZ AL AÑO NOTAS: La calidad de un sistema de PLD, estará directamente relacionada con la calidad de sus reglas de detección. __________________________________________________________ ME2.5 Aseguramiento del control interno Obtener, según sea necesario, aseguramiento adicional de la completitud y efectividad de los controles internos por medio de revisiones de terceros. Dichas revisiones pueden ser realizadas por la función de cumplimiento corporativo o, a solicitud de la gerencia, por auditoría interna o por auditores y consultores externos o por organismos de certificación. Se deben verificar las aptitudes de los individuos que realicen la auditoria, por ej. Un Auditor de Sistemas de Información Certificado TM (CISA® por sus siglas en Inglés) debe asignarse. ____________________________________________________________ ____________________________________________________________ ___________________ 49

10) ¿Esta el criterio y el mecanismo para cerrar alertas totalmente documentado? AI2.3 Control y Auditabilidad de las Aplicaciones Cuando se rompe un a regla se genera una alerta y se generan reportes. La auditoría de TI debe evaluar el Workflow de EDD, realizando una investigación de los circuitos y las pistas de auditoría del sistema. El esquema de alertas debe responder a los siguientes criterios. Básicamente de todas las alertas se deben tener dos estados: Desestimadas Investigación abierta Solo se debe poder cerrar un reporte de alertas si las mismas se marcadas con alguno de los dos estados mencionados. Las investigaciones abiertas entran en otro circuito de las investigaciones como fue ejemplificado anteriormente (Workflow). En el caso de desestimarse una alerta luego de una investigación se debe justificar el porque se desestima la misma para poder cerrarlo en el sistema. NOTAS: _AI2.3 Control y auditabilidad de las aplicaciones Asegurar que los controles del negocio se traduzcan correctamente en controles de aplicación de manera que el procesamiento sea exacto, completo, oportuno, aprobado y auditable. Los aspectos que se consideran especialmente son: mecanismos de autorización, integridad de la información, control de acceso, respaldo y diseño de pistas de auditoría. ___________________________________________________________ ______Valores: Posibilitar la reconstrucción histórica de transacciones. ______________________________________________________ ____________________________________________________________ ___________________ 50

11) ¿Cómo se generan los reportes de salida e informes del tipo SAR/STR/ROS o CTR/ROE? El auditor deberá revisar el proceso de generación de los reportes identificando los procesos Manuales (formularios PDF o manuales) o procesos Automáticos involucrados en las misma. En el caso de los procesos Automáticos deberá evaluar que los mecanismos de reporte incluyan: Interfases automáticas (Diseño estructurado). Encriptación de Datos. ME3.4 Aseguramiento positivo del cumplimiento. AC4 Validez e Integridad del procesamiento Definir e implantar procedimientos para obtener y reportar un aseguramiento del cumplimiento. Mantener la integridad a lo largo de todo el ciclo de vida del procesamiento. Definir los procedimientos de manejo de errores durante la generación de los datos que aseguran de forma razonable la detección, el reporte y la corrección de errores e irregularidades. Riesgo: Falta de evidencia en los errores producidos. Errores de datos no detectados. Valor: Errores de procesamiento detectados oportunamente. Posibilidad de investigar errores. FINCEN tiene publicado un documento sobre los errores comunes al llenar un formulario de SAR Como por ejemplo el tema narrativas QUIEN COMO CUANDO u otros datos básicos como el nro de TE.- ME3.4 Aseguramiento positivo del cumplimiento Definir e implantar procedimientos para obtener y reportar un aseguramiento del cumplimiento y, donde sea necesario, que el propietario del proceso haya tomado las medidas correctivas oportunas para resolver cualquier brecha de cumplimiento. Integrar los reportes de avance y estado del cumplimiento de TI con salidas similares provenientes de otras funciones de negocio AC4 Que el flujo de transacciones invalidas no interrumpa el flujo de transacciones validas. ____________________________________________________ ____________________________________________________________ ___________________ 51

PLD y TI : Mitos La tecnología es la solución para todos los problemas. La solución estándar funcionará. Todos los sistemas automáticos son iguales. Cuanto mas sofisticado y caro sea un sistema será mejor. Los departamentos de TI/SI no tendrán ningún inconveniente en implementar un sistema nuevo de PLD. El sistema de PLD capturará todos los clientes, transacciones y productos. El manual del usuario del sistema es la política de PLD. Con la implementación de un sistema se necesitarán menos personas para el monitoreo. NOTAS: ____________________________________________________________ ___________________ 52

PLD y TI : Conclusiones Las instituciones financieras deben contar con la Tecnología PLD para: Detección de comportamientos sospechosos. Toma de decisiones. Filtrado de bases de datos u otro tipo de archivos. Monitoreo de transacciones. La única manera de cumplir eficientemente con las obligaciones de cumplimiento de PLD es con la ayuda de un Software que este alineado con este proceso de negocio. No existe una solución fija que pueda ser implementada uniformemente en todos las entidades Financieras. La sistematización de los controles nunca eliminan el “Factor Humano”. NOTAS: ____________________________________________________________ ___________________ 53

PLD y TI : Conclusiones - Final
El desarrollo y la capacitación de los recursos humanos tanto en áreas de cumplimiento como tecnológicas es un factor critico para el éxito de los programas de PLD. Los desafíos técnicos que presenta esta infraestructura de detección deben ser enfocados con adecuadas prácticas de Control (COBIT) para lograr que los sistemas se conviertan en una herramienta invalorable y no en una carga para la Organización. Los costos de implementar y mantener un esquema automatizado de PLD pueden ser altos. Los costos de no implementar y mantener un esquema automatizado de PLD pueden ser MAS altos. NOTAS: ____________________________________________________________ ___________________ 54

¿PREGUNTAS? Preguntas ¡¡MUCHAS GRACIAS!! EDUARDO OSCAR RITEGNO
¿PREGUNTAS? NOTAS: ____________________________________________________________ ___________________ 55

La Auditoría de TI aplicada al proceso de

Presentaciones similares

Presentación del tema: "La Auditoría de TI aplicada al proceso de"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

La Auditoría de TI aplicada al proceso de

Presentaciones similares

Presentación del tema: "La Auditoría de TI aplicada al proceso de"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback