Mostrando entradas con la etiqueta AUDISIS. Mostrar todas las entradas
Mostrando entradas con la etiqueta AUDISIS. Mostrar todas las entradas

viernes, 27 de abril de 2012

REQUERIMIENTOS OPERATIVOS MÍNIMOS DE SEGURIDAD PARA INSTRUMENTOS ELECTRÓNICOS DE PAGO


 
El Banco Central de Bolivia en el marco de sus atribuciones de regulación del sistema de pagos nacional y conforme lo establecido en el Artículo 15 del Reglamento de Instrumentos Electrónicos de Pago, aprobados a través de R.D. No. 126/2011 de 04.10.11 y modificado con R.D. 025/2012 de 23.02.12, remite para su aplicación y cumplimiento los requerimientos minimos de seguridad operativa para tarjetas de pago, órdenes electrónicas de transferencia de fondos y billeteras móviles.

BCB fija medidas de seguridad para banca electrónica

Control. Incluyen a tarjetas de pago, órdenes electrónicas y billeteras móviles

ANF / La Paz


El Banco Central de Bolivia (BCB) fijó medidas mínimas de seguridad para instrumentos electrónicos de pago e instruyó que sean implementadas por las entidades financieras que operan en el país. Los requerimientos mínimos de seguridad abarcan a tarjetas de pago, órdenes electrónicas de transferencia de fondos y billeteras móviles, según una circular externa del BCB.
En el comunicado se hace referencia a las tarjetas de pago, donde el BCB fija exigencias mínimas de seguridad como ser el grabado de nombre del emisor, número de tarjeta y, además, la fecha de vencimiento. “Se deben aplicar algoritmos de cifrado para autenticar la tarjeta con chip y los datos de la operación”, dice la resolución.
Los últimos cuatro dígitos embozados, grabados o impresos en la tarjeta, deben coincidir con los del recibo que se extiende por retiros o compras presenciales. La banda magnética de las tarjetas de pago debe llevar el número de cuenta principal, fecha de vencimiento, valor de verificación del PIN, valor de verificación de la tarjeta.
“El código de validación de la tarjeta” o “los datos de validación del PIN no podrán almacenarse en sistemas o bases de datos”.  Para las órdenes electrónicas de transferencia de fondos, los servicios deben emplear “canales de comunicación encriptados” de servidores seguros.  La página web “debe indicar el nombre de la entidad que emite el certificado y un vínculo a la entidad certificadora”.

Fuente:  www.la-razon.com

sábado, 24 de marzo de 2012

Auditoría de monitoreo continuo de las operaciones

Introducción y aspectos generales

A medida que pasa el tiempo, las organizaciones, principalmente las de gran tamaño, se apoyan, cada vez más, en las tecnologías de información para realizar y controlar sus operaciones.
Los sistemas de información utilizados pueden ser simples o complejos, dependiendo de varios factores como: la cantidad de operaciones, el tamaño de la empresa, la dispersión geográfica de los centros de trabajo que la conforman, etc. En este sentido, conviene señalar que la mayoría de los sistemas y el software que existe en la actualidad tienen una arquitectura basada en el concepto ERP (Enterprise Resource Planning, Planeación de Recursos Empresariales), SCM (Supply Chain Management, Administración de la Cadena de Abastecimiento), CRM (Customer Relationship Management, Administración de Relaciones con los Clientes) y BI (Business Intelligence, Inteligencia de Negocios), cada una tiene una serie de módulos, cuyas operaciones son registradas en una base de datos central, a la cual se accede por medio de una red, desde lugares remotos, independientemente del lugar donde operen; todo lo anterior, bajo la denominación genérica de e-Business. Algunos de los módulos son los de recursos humanos, adquisiciones, almacenes, tesorería, ventas, proyectos de inversión, presupuesto y contabilidad.

Ante este entorno, los auditores no pueden ser ajenos a la evolución tecnológica y, por lo tanto, tienen que crear esquemas o mecanismos de auditoría de acuerdo con las circunstancias y apoyarse con estos medios. Por ello, las áreas de auditoría están incorporando auditores especializados en tecnologías de información, quienes, además de revisar aspectos técnicos como los procedimientos y desempeño de los centros de cómputo, seguridad de la información y desarrollo de sistemas —entre otros—, participan en las revisiones de las operaciones del negocio y en el desarrollo de monitoreos junto con otros auditores, apoyándolos de manera alternativa, así como en la construcción de sistemas especializados para responder a las necesidades de administración de la propia área y de la ejecución del proceso de auditoría interna.
En la actualidad, se cuenta con una gran variedad de software, tanto para la administración del área de auditoría como para la extracción y análisis de datos, monitoreo continuo de las operaciones, administración de riesgos, de cumplimiento con la Ley Sarbanes-Oxley (SOX), etc. Al contar con esta gama de herramientas, el departamento de auditoría cuenta con la flexibilidad necesaria para aplicar la mejor tecnología a cada tarea específica, dependiendo también de diversos factores y de la complejidad, objetivos, alcances y tareas a lograr por cada revisión.

Algunos de los puntos básicos que consumen una considerable cantidad de tiempo del grupo de auditores son, precisamente, los relacionados con la revisión de los aspectos normativos, los cuales presentan una gran oportunidad para incrementar la productividad en la auditoría, ya que pueden automatizarse. Esto permite a los auditores dedicar mayor tiempo a otros aspectos que deben generar propuestas de alto valor.
En este sentido, los auditores pueden utilizar software especializado sistemas con el propósito de analizarla y verificarla, principalmente, en cuanto al cumplimiento normativo. De hecho, este enfoque es considerado una mejor práctica por The Institute of Internal Auditors (IIA), organización que cada año realiza una encuesta sobre el uso de este tipo de herramientas, la que refleja un importante incremento en su uso.

Por otra parte, la Ley SOX que regula a las empresas que cotizan en la Bolsa de Valores de los Estados Unidos de Norteamérica, y las obliga a contar con sistemas de control interno robustos, ha propiciado que muchas de éstas opten por implementar controles internos basados en el Modelo COSO, mismo que considera dentro de los elementos de control a los procesos de autoevaluación o CRSA (Control Risk Self Assessment), dentro del que incluimos al monitoreo, el cual se puede llevar a cabo mediante el diseño y uso de procedimientos automatizados. En consecuencia, el desarrollo de este concepto ha traído grandes beneficios en los últimos años, tanto a las áreas operativas, como a la propia área de auditoría, por lo que consideramos importante compartir estas experiencias.

La auditoría de monitoreo continuo está compuesta de procedimientos de auditoría automatizados, diseñados para recabar información en línea directamente de las bases de datos de los sistemas de información, con el propósito de evaluar las operaciones de la organización y el grado de  cumplimiento de la normatividad externa e interna.

Su implementación consiste en la evaluación del control interno de las operaciones para identificar riesgos, y con base en estos, diseñar los procedimientos automatizados de auditoría, que permitan formular propuestas para administrar estos riesgos y realizar revisiones periódicas a estas operaciones, para vigilar su cumplimiento tanto por la misma área como por auditoría interna.
A juicio del auditor en TI se seleccionan las herramientas que mejor se adapten al tipo de sistema que se va a auditar.

A continuación se presenta el funcionamiento conceptual de este tipo de auditorías (gráfica 1).


Desarrollo del monitoreo
La gráfica 2 presenta los elementos y las actividades a realizar para desarrollar el esquema de monitoreo continuo.

Para iniciar los trabajos se debe contar con auditores de perfil informático y experiencia en el proceso a revisar, así como una capacitación continua sobre herramientas y lenguajes informáticos, ya que, por lo general, es necesario conectarse a las bases de datos que contiene la información a revisar. Asimismo, se requieren auditores financieros u operacionales de preferencia con la especialidad de los procesos a revisar, para dirigir y explotar al máximo la información.

Adicionalmente, se necesita acceso a la red, licencias de software y claves de usuario con permisos de consulta a los sistemas. Lo anterior, permite mantener independencia del área de auditoría, respecto de las áreas usuarias e informáticas, al tener acceso directo a los lugares donde se almacena la información. Una vez satisfechas estas condiciones, se deben realizar las actividades siguientes:

Análisis del proceso seleccionado e identificación de riesgos.

Es importante evaluar y conocer el proceso para identificar los riesgos y los puntos de control que los mitiguen. Asimismo, la normatividad que regula el proceso para ser incluida en el análisis realizado, ya que contiene las condiciones a las que se apega el proceso y las desviaciones que pueden convertirse en excepciones, debilidades o deficiencias de control.

Definición y diseño de monitoreo.
Una vez identificados los riesgos, se puede realizar el modelo conceptual del monitoreo, a partir de las debilidades identificadas y contemplando los controles existentes en el proceso.
Posteriormente, se diseña el monitoreo en sí, analizando el procesamiento y la arquitectura de la información, así como el registro informático de las operaciones. A partir de todo lo anterior, se desarrollan los procedimientos automatizados, determinando las consultas a realizar y los parámetros a cumplir.

Obtención de herramientas informáticas. 
 Una vez concluido el diseño, se puede identificar la herramienta a utilizar de manera individual o combinada. A continuación se mencionan algunas:
—Paquetes de auditoría (ACL, IDEA Fastsearch, etcétera).
—Módulo de auditoría de SAP (AIS).
—Herramientas de extracción y análisis de información
(Business Objects, Access, etcétera).
—Paquetería genérica (Microsoft Office).
—Utilerías de bases de datos (Oracle, SQL Server, etcétera).
—Lenguajes de programación (C++, ABAP de SAP, Visual
Basic, etcétera).

Desarrollo de aplicaciones.  
Una vez seleccionadas las herramientas y diseñado el monitoreo, se procede a construir la aplicación y crear los procedimientos automatizados de auditoría, realizando las pruebas sistémicas correspondientes.

Liberación del monitoreo.  
Al concluir el desarrollo, se deben realizar las pruebas operativas necesarias a los procedimientos creados, con la finalidad de verificar la oportunidad y la operación, adecuarlas según sea el caso y capacitar al personal sobre la operación de la solución  desarrollada.

Puesta en producción.  
Finalmente, los procedimientos se ponen a disposición de las áreas operativas y de los auditores para que los utilicen en el desarrollo continuo de sus revisiones.

Procedimiento general para la ejecución de auditorías de monitoreo
Una vez liberado el sistema de monitoreo, se realizan revisiones periódicas sobre la información de los sistemas, desarrollando las siguientes actividades:

Ejecución de procedimientos automatizados de monitoreo sobre la totalidad de las operaciones. Esta actividad es utilizada, principalmente, para obtener la información del universo y poder detectar posibles desviaciones o indicios de deficiencias de control de acuerdo a los monitoreos realizados.

Determinación del alcance de la auditoría. Una vez definido el universo, se seleccionan las operaciones o las condiciones de los registros a las que se les darán énfasis durante la revisión. Lo anterior con la finalidad de acotar las transacciones a revisar y cumplir con los objetivos y alcances planteados en la auditoría.

Obtención de reportes de cumplimiento normativo o desempeño de las operaciones. Esto se refiere a la obtención de la información a evaluar para verificar el cumplimiento normativo o el correcto desempeño de las actividades por parte de las áreas operativas.

Análisis de los reportes e investigación de causas. Se documenta y se integra el análisis de los componentes del problema hasta determinar la causa que originó la desviación, para lo cual es necesario definir el problema, determinar el impacto, la evidencia y, con base en la causa, determinar la recomendación que elimine la causa y nos ayude a eliminar o administrar el riesgo y, por consiguiente, a acabar con el problema. Si las desviaciones detectadas no fueron corregidas
durante la auditoría, se formalizan las recomendaciones correspondientes.

Seguimiento de las acciones de corrección, prevención y mejora. Se ejecutan los procedimientos automatizados para verificar que se hayan realizado las correcciones necesarias en los controles y que los errores detectados sean subsanados.
La aplicación de estos procedimientos debe tener una periodicidad determinada, principalmente por la naturaleza y riesgos de las operaciones revisadas, misma que puede ser establecida por el historial de hallazgos y las tendencias que han presentado estas operaciones.
Algunos ejemplos de las transacciones que son susceptibles de verificar por este método, las cuales dependen de las operaciones de cada negocio, pueden ser:

Nóminas y recursos humanos. Cálculo de la nómina y descuentos al personal, su registro contable y depósito bancario en cada una de las cuentas de los empleados; número de jornadas laboradas y pagadas; tiempo extra; préstamos y su recuperación; viáticos, personal en nómina, controles de asistencia, jubilaciones, liquidaciones, y otros conceptos.

Adquisiciones e Inventarios. Disponibilidad presupuestal; solicitudes de cotización enviadas y recibidas; tendencia de precios; adquisiciones por año, proveedor, grupo y tipo de compras y comprador; por tipo de compra, modificaciones a pedidos; anticipos, pagos, devoluciones, circulación de saldos, etcétera.

Almacenes. Recepción de bienes, de acuerdo con lo solicitado, movimientos de los bienes en el almacén, antigüedad del inventario, identificación de bienes de lento movimiento y situación de las mercancías en tránsito, etcétera.

Contabilidad y Finanzas. Desviaciones en la aplicación contable; comparación de importe entre montos contratados y pagados; transferencias y posiciones de caja; conciliaciones bancarias, validación del cálculo de la depreciación y amortizaciones, ministración de fondos, control de inversiones y rendimientos por instrumento financiero, etcétera.


Beneficios

Identificación de riesgos. Diagnóstico oportuno del riesgo a que están sujetas las operaciones de la organización, ya que se analiza el proceso y la normatividad correspondiente.

Cobertura total del universo a revisar y en menor tiempo. Es posible revisar todas las transacciones realizadas, directamente, en los registros del sistema, lo cual se ejecuta rápido y se obtienen reportes de excepciones para su análisis.

Efecto disuasivo al tener presencia vía electrónica en las áreas de registro de los centros de trabajo. Derivado de la oportunidad creada al revisar la mayor cantidad de transacciones y el tiempo reducido, se actúa rápido para solucionar la desviación. Los usuarios, al percatarse de esta situación, ponen más atención a las labores que realizan. En el caso de la Banca existen desarrollos que reportan excepciones en línea al momento que se generaba en cualquier área ó sucursal, proporcionando alertas para su atención inmediata; por ejemplo, préstamos, cambios de moneda por arriba de los límites permitidos, etcétera.

Enfoque de procesos. Permite revisar las operaciones desde su inicio hasta su conclusión, privilegiando el cumplimiento normativo y validando la efectividad y eficacia del proceso.

Mayor oportunidad y credibilidad en la detección de posibles desviaciones, abandonando en lo posible el muestreo. Este esquema permite evaluar, de modo rápido, el universo y enfocarse a las desviaciones, lo cual hace que disminuya la utilización del muestreo estadístico como base de la revisión y para la elaboración de conclusiones.

Incrementa la independencia del auditor respecto de las áreas, tanto informáticas como usuarias. Al tener acceso directo a la información, los auditores no tienen que esperar que las áreas usuarias o informáticas la envíen.

Mayor seguridad, precisión y objetividad en los resultados. Debido a que los procedimientos son automatizados garantizan que los resultados mostrados son los registrados en el sistema auditado.

Proporciona información para la ejecución de auditorias especificas. Mediante este esquema se puede dirigir la selección de la información por alguna característica en particular.

Valor agregado a las revisiones y a la función. Los hallazgos y la precisión que se puede tener de las desviaciones, permiten que la función de auditoría agregue mayor valor, mediante una mejor determinación de las causas que las originaron derivado del análisis del problema, según se comentó en párrafos anteriores.
El auditor deberá estar al tanto de los cambios que se realicen a los sistemas, para evitar que los procedimientos automatizados se vuelvan obsoletos, al perder la compatibilidad con las nuevas versiones de sistemas. En este caso, el auditor deberá participar en los grupos de trabajo que realicen las modificaciones a los sistemas, con el propósito de conocer los cambios a éstos y verificar en que grado afectan los controles establecidos originalmente y, si es necesario, proponer nuevos, así como modificar los procedimientos automatizados de auditoría.

Conclusión
Las áreas de auditoría deben enfatizar en evolucionar al mismo ritmo tecnológico que lo hacen sus empresas y continuar creando los esquemas y mecanismos necesarios con el apoyo de las tecnologías de información para mantener la independencia de las áreas usuarias e informáticas.
Para lograr lo antes descrito, el auditor, entre otras herramientas de apoyo, cuenta con el esquema de auditoría de monitoreo continuo de las operaciones, cuyo concepto puede aplicarse en cualquier organización, sin importar el tamaño de ésta o las tecnologías de información que utiliza.
Las grandes ventajas de este esquema son que se aplica con mayor oportunidad a todo un universo para determinar las excepciones a revisar, lo que redunda en un mejor análisis y en la eficacia y eficiencia del trabajo del auditor.


C. P. Héctor Aguiñaga Pérez
C. P. Estanislao Sánchez y López
Ing. Gabriel Iñesta Ocampo

Fuente: Revista Contaduría Pública www.contaduriapublica.org.mx del Instituto Mexicano de Contadores Públicos www.imcp.org.mx

domingo, 8 de enero de 2012

MITOS Y REALIDADES SOBRE HIPAA

Health Insurance Portability & Accountability Act - HIPAA

La Ley de responsabilidad y transferibilidad de los seguros médicos.


MITO: Hay que guardar los récords de los pacientes bajo llave.

HIPAA: Sólo asegurar los récords.

REALIDAD: Esto no quiere decir bajo llave. Existen alternativas razonables.

MITO: Hay que hablar en un lugar donde otros no puedan escuchar la conversación entre el profesional y el paciente.

MITO: Hay que construir lugares a prueba de sonido.

MITO: Tengo que construir e instalar barreras de sonido en mis topes o “counters“.

HIPAA: Falso , sólo tomar medidas razonables para mantener la privacidad de la información de salud del paciente.

REALIDAD: Esto quiere decir, bajar el volumen, ir a una esquina a conversar si hay otras personas en el lugar, pedir a los visitantes que le permitan hablar en privado, atender a una persona a la vez, hablar en otro tono de voz, etc.

MITO: Tienes que comprar un programa de computadoras.

HIPAA: Falso, entre otras cosas, hay que elaborar una política de privacidad, la documentación y procedimientos necesarios para cumplir con las reglas y adiestrar todo el pesonal de la entidad.

REALIDAD: Se puede cumplir completamente con HIPAA sin

comprar nada nuevo.

MITO: Existen programas de computadoras certificados y/o que llevan a cumplir con HIPAA automáticamente.

HIPAA: Falso, los únicos que pueden cumplir con HIPAA son planes, proveedores y “clearinghouses”.

REALIDAD: No existe programa en el universo que esté certificado por o para HIPAA, ni que lo haga cumplir con HIPAA automáticamente. Lo más que pudieran es ser “conformes” con HIPAA.

MITO: Puedes ir a la cárcel si no cumples con HIPAA

HIPAA: Se establecen multas y cárcel como sanciones por la violación de la ley.

REALIDAD: El que cometa actos delictivos en violación de una ley se arriesga a ser sancionado. El DHHS dará todas las oportunidades de cumplir con la ley y llevará a cabo todas las orientaciones necesarias antes de proceder a imponer las sanciones.

MITO: El Departamento de Salud Federal y/o Medicare certifican personas, programas de computadoras y/o sistemas como especialialistas o como que logran el cumplimiento con HIPAA.

HIPAA: Falso, ni Medicare ni el Departamento de Salud Federal certifican personas, ni programas, ni sistemas como especialistas que logran cumplimiento con HIPAA

MITO: No se pueden llamar los pacientes por nombre.

HIPAA: Falso, se puede seguir llamando pacientes por su nombre. (Ver situaciones discutidas en el Federal Register).

REALIDAD: Esta medida númerica es práctica para algunos escenarios, pero no es requerida.

MITO: Los expedientes no se pueden guardar por número de seguro social o por orden alfabético.

HIPAA: Sólo se requiere asegurar la confidencialidad de los récords.

REALIDAD: Falso, quisiéramos saber de dónde sale ésta premisa.



Fuente: http://www.salud.gov.pr

martes, 6 de diciembre de 2011

¿QUÉ ES LA HIPAA?

La Ley de responsabilidad y transferibilidad de los seguros médicos (Health Insurance Portability & Accountability Act) de 1996 (21 de agosto 21), ley pública 104-191, que modifica el código del Internal Revenue Service de 1986. También conocida como la Ley de Kennedy-Kassebaum.

El Título II incluye una sección, Simplificación administrativa, que exige:

1. Mayor eficiencia en la asistencia médica por medio de la estandarización del intercambio electrónico de datos, y
2. La protección de la confidencialidad y seguridad de los datos médicos, a través del establecimiento y cumplimiento de estándares.

Más específicamente, la HIPAA pide:

1. La estandarización de los datos electrónicos administrativos, financieros y de salud de los pacientes
2. Identificadores médicos únicos para personas, empleados, planes de salud y proveedores de cuidados médicos
3. Normas de seguridad que protejan la confidencialidad y la integridad de la "información médica identificable a nivel personal" pasada, presente o futura.

En resumen: cambios radicales en la mayoría de los sistemas de información administrativos y de transacciones médicas.

¿A QUIÉN AFECTA? A todas las organizaciones de salud. Esto incluye a todos los proveedores de asistencia médica, contando a los consultorios de un solo médico, a los planes de salud, empresas, autoridades de salud, compañías de seguros, cámaras de compensación, agencias de facturación, proveedores de sistemas de información, organizaciones de servicios y universidades.

¿HAY SANCIONES? La HIPAA pide sanciones civiles y penales graves en caso de incumplimiento, como multas de hasta 25,000 dólares por violaciones reiteradas del mismo estándar en un solo año, multas de hasta 250,000 dólares o hasta 10 años de prisión por el mal uso consciente de la información de salud identificable a nivel personal.

PLAZOS DE APLICACIÓN La mayoría de las entidades disponen de 24 meses desde la fecha de entrada en vigor de la regla final, para cumplirla en su totalidad. Normalmente, la fecha de entrada en vigor es 60 días después de la publicación de una regla. La Regla sobre transacciones se publicó el 17 de agosto de 2000. Por lo tanto, la fecha de cumplimiento de esa regla es el 16 de octubre de 2002. La Regla sobre confidencialidad se publicó el 28 de diciembre de 2000, pero debido a pequeños problemas técnicos, no entró en vigor hasta el 14 de abril de 2001. El cumplimiento de la regla sobre confidencialidad se exige a partir del 14 de abril de 2003.


¿CÓMO SE APLICARÁ?
De manera amplia y profunda. Las respuestas de cumplimiento exigidas no son estándar, ya que las organizaciones tampoco lo son. Por ejemplo, una organización con una red de cómputo deberá poner en funcionamiento uno o más mecanismos de acceso con autenticación de seguridad, basados en los usuarios, las funciones o el contexto, dependiendo del entorno de red.

Un cumplimiento efectivo requerirá de una aplicación en toda la organización. Los pasos incluirán:

Fomentar el conocimiento inicial de la HIPAA en toda la organización.
Evaluar de forma completa los sistemas de seguridad de la información, los reglamentos y los procedimientos de la organización.
Desarrollar un plan de acción con plazos y fechas límite.
Desarrollar una infraestructura técnica y de administración para poner el plan en funcionamiento.
Poner en marcha un plan de acción completo que incluya
el desarrollo de nuevos reglamentos, procesos y procedimientos
Crear acuerdos de "cadena de confianza" con la organización de servicios.
Rediseñar una infraestructura de información técnica que cumpla los requisitos.
Adaptar o adquirir nuevos sistemas de información
Desarrollar nuevas comunicaciones internas
Capacitación y aplicación
Ahora, exploraremos el siguiente nivel de particularidades de la HIPAA que, para muchos de nosotros, son más fuente de confusión que de entendimiento. Intentemos simplificar la "Simplificación administrativa".

La disposición sobre "Simplificación administrativa" de la HIPAA consta de cuatro partes, cada una de las cuáles genera varias "reglas" y "estándares". Muchas de las reglas y estándares están aún en la fase de "propuesta" (por el DHHS); sin embargo, está previsto que la mayoría de ellas se conviertan en reglas "finales" en el año 2000. Para complicar el asunto aún más, cuando las reglas sean finales, la mayoría de ellas tendrá diferentes fechas de aplicación.

Las cuatro partes de la simplificación administrativa son:
ESTÁNDARES PARA TRANSACCIONES ELECTRÓNICAS RELACIONADAS CON LA SALUD
IDENTIFICADORES ÚNICOS
ESTÁNDARES DE SEGURIDAD Y FIRMAS ELECTRÓNICAS
ESTÁNDARES DE PRIVACIDAD Y CONFIDENCIALIDAD

I. ESTÁNDARES PARA TRANSACCIONES ELECTRÓNICAS RELACIONADAS CON LA SALUD
El término "transacciones electrónicas relacionadas con la salud" incluye las reivindicaciones médicas, la elegibilidad para los planes de salud, la inclusión y exclusión, los pagos de primas de los planes de salud y asistencia, el estado de las reclamaciones, los primeros informes de lesiones, la coordinación de prestaciones y las transacciones relacionadas.

En la actualidad, los proveedores de cuidados y los planes de salud usan un gran número de formatos electrónicos distintos. La aplicación de un estándar nacional significa que todos usaremos un solo formato, lo que "simplificará" y mejorará la eficiencia de las transacciones en todo el país. La regla propuesta exige el uso de formatos electrónicos específicos desarrollados por el ANSI (American National Standards Institute) para la mayoría de las transacciones, con excepción de las reclamaciones y los primeros informes de lesión. La reglamentación propuesta para estas excepciones aún no se conoce.

Prácticamente todos los planes de salud tendrán que adoptar estos estándares, aunque la transacción se realice en papel, por teléfono o por fax. Los proveedores que usan transacciones no electrónicas no tendrán que adoptar los estándares, pero si no lo hacen, deberán contratar a un centro de cambio y compensación que proporcione los servicios de conversión.

Las organizaciones de salud también deben adoptar CONJUNTOS DE CÓDIGOS ESTÁNDAR para utilizarlos en todas las transacciones médicas. Por ejemplo, los sistemas de codificación que describen las enfermedades, las lesiones y otros problemas de salud, así como sus causas, síntomas y medidas adoptadas deberán ser uniformes. Todas las partes de una transacción deberán usar y aceptar los mismos códigos. Una vez más, esto tiene como fin reducir, a la larga, los errores, la duplicación de esfuerzos y los costos. Afortunadamente, muchos planes de salud, centros de compensación y proveedores de cuidados de la salud ya utilizan los conjuntos de códigos que se proponen como estándares de la HIPAA, lo que facilitará la transición.

II. IDENTIFICADORES ÚNICOS PARA PROVEEDORES, EMPRESARIOS, PLANES DE SALUD y PACIENTES
El sistema actual nos permite tener varios números de Id. para distintas relaciones entre nosotros; la HIPAA considera que esto es confuso, caro e induce a errores. Se espera que los identificadores estándar reduzcan estos problemas.

III. ESTÁNDARES DE SEGURIDAD DE LA INFORMACIÓN MÉDICA Y FIRMA ELECTRÓNICA
El nuevo estándar de seguridad proporcionará un nivel de protección uniforme a toda la información médica que se aloje o se transmita electrónicamente, y pertenezca a una persona. Además, las organizaciones que usen firmas electrónicas deberán cumplir con un estándar que garantice la integridad del mensaje, la autenticación del usuario y la ausencia de rechazo.

El estándar de seguridad obliga a tener sistemas de protección para el almacenamiento y mantenimiento físicos, para la transmisión y el acceso a la información de salud de una persona. Esto es válido no sólo para las transacciones que se lleven a cabo después de la entrada en vigor de la HIPAA, sino para toda la información de salud de una persona que se conserve o se transmita. El estándar de firma electrónica, sin embargo, sólo se aplica a las transacciones realizadas después de la entrada en vigor de la HIPAA.

El estándar de seguridad no exige el uso de tecnologías específicas; las soluciones variarán de una organización a otra, dependiendo de las necesidades y la tecnología de cada lugar. Asimismo, no se exige actualmente la firma electrónica para ninguna de las transacciones realizadas según la HIPAA.

IV. PRIVACIDAD Y CONFIDENCIALIDAD
La regla final de confidencialidad se publicó cuando terminaba el mandato del presidente Clinton, el 28 de diciembre de 2001. Ciertos problemas de papeleo retrasaron la comunicación al Congreso, por lo que la revisión del Congreso no comenzó hasta febrero, lo que retrasó la fecha de entrada en vigor de la regla hasta el 14 de abril de 2001. El Secretario del DHHS, Tommy Thompson, utilizó ese tiempo para solicitar comentarios adicionales durante el mes de marzo. El DHHS recibió más de 11,000 comentarios y como respuesta, tiene previsto emitir lineamientos y aclaraciones sobre la regla final. A partir del 14 de abril de 2003, se exigirá su cumplimiento por parte de la mayoría de las entidades.

En general, la privacidad se refiere a quién puede tener acceso a la información de salud que permite identificar a una persona. La regla abarca toda la información de salud con datos de identificación personal en manos de las entidades afectadas, independientemente de si dicha información está o estuvo en formato electrónico.

Los estándares de confidencialidad:

limitan el uso no consensuado y la divulgación de la información de salud privada;
dan a los pacientes derecho de acceso a sus registros médicos y a saber quién más ha tenido acceso a ellos;
restringen la divulgación de la información médica a lo mínimo necesario para los fines deseados;
establecen nuevas sanciones civiles y penales por el uso o divulgación indebidos;
establecen nuevos requisitos para el acceso a los registros por parte de los investigadores y otras personas.
La nueva regla refleja los cinco principios básicos planteados en ese momento:

Control del consumidor: la regla proporciona a los consumidores nuevos derechos críticos de control sobre la divulgación de su información médica
Límites: con pocas excepciones, la información de asistencia médica de una persona debe utilizarse exclusivamente para fines de salud legítimos, incluidos el tratamiento y el pago.
Contabilidad: con la HIPAA, por primera vez, habrá sanciones federales específicas si se viola el derecho a la confidencialidad de un paciente.
Responsabilidad pública: los nuevos estándares reflejan la necesidad de equilibrar la protección privada y la responsabilidad pública de apoyar prioridades nacionales, como la protección de la salud pública, el desarrollo de investigaciones médicas, la mejora de la calidad de la atención, y la lucha contra el fraude y el abuso en los servicios de salud.
Seguridad: es responsabilidad de las organizaciones a las que se confía la información médica protegerla contra el mal uso o la divulgación deliberada o accidental.

Fuente: www.hchdonline.com

miércoles, 31 de agosto de 2011

Hallazgos de Auditoria de Sistemas – Sector Público Nacional

De la evaluación/relevamiento realizada por el SIGEN (Sindicatura General de la Nación – Argentina) al sector Público Nacional el año 2005 previo a emitir las “Normas de Control Interno para Tecnología de Información” (Res. 48/2005 SIGEN), surgieron riesgos detectados que expresan la situación del Sector Público Nacional hasta el año 2005. A continuación se presentan la Condición y el Efecto de dichos Hallazgos de Auditoria de Sistemas:

1. La institución posee más de un sector responsable de los servicios de procesamiento de la información. (37%)
Riesgos:
Dificultades para llevar a cabo estrategias y planes unificados relativos a la TI
Posible duplicación de esfuerzos y tareas

2. Las áreas informáticas identificadas dependen de una de las áreas usuarias. (63%)
Riesgos:
Falta de independencia
Incorrecta gestión de prioridades en la prestación de servicios

3. Las áreas informáticas identificadas carecen de estructura interna formalmente definida. (61%)
Riesgos:
Falta de separación de funciones
Desconocimiento, por parte del personal, de sus responsabilidades
Dificultades ante eventuales necesidades de rendición de cuentas

4. Las áreas informáticas identificadas no disponen de planificación documentada (37%) y no dispone de planificación aprobada (51%)
Riesgos:
Falta de dirección y control de las actividades y proyectos informáticos encarados
Ineficiencia de los proyectos informáticos
“Malas” inversiones en TI
Disparidad entre los objetivos de la organización y de la TI

5. Las áreas informáticas identificadas carece de procedimientos aprobados para el desarrollo y mantenimiento de sistemas (69%)
Riesgos:
Modificaciones no autorizadas sobre los Sistemas
Incorrecta administración de prioridades
Falta de aplicación de estándares de programación y documentación
Implementación de Sistemas no probados

6. Las áreas informáticas identificadas carecen de procedimientos aprobados para la administración de la seguridad (69%)
Riesgos:
Accesos no autorizados a la información o los recursos del Organismo
Inexactitud o falta de confiabilidad de los datos o Sistemas
Falta de disponibilidad de la información o recursos necesarios

7. Las áreas informáticas identificadas carecen de plan de contingencias (74%)
Riesgos:
Interrupciones a la continuidad operativa del Organismo, con la consiguiente imagen negativa e incumplimiento de la misión asignada

8. Las áreas informáticas identificadas carecen de procedimientos documentados de back up (59%)
Riesgos:
Pérdidas de información
Interrupciones a la continuidad operativa del Organismo
Dependencia del personal que se encarga de la tarea

9. Las áreas informáticas identificadas carecen de procedimientos documentados para las actividades de soporte técnico (77%). Asimismo carecen de procedimientos documentados para la gestión de licencias de software (80 %)
Riesgos:
Administración deficiente de prioridades, disconformidad de los usuarios, etc.
Incumplimiento de la normativa aplicable.

10. La institución no realiza auditorías internas de sistemas de información
Riesgos:
Desequilibrio entre la informatización del organismo y la realización de auditorías.

Del producto de la evaluación que detectó los Hallazgos de Auditoria de Sistemas, el SIGEN redactó y aprobó un Modelo de Política de Seguridad basado en la ISO 17799, los puntos abarcados en el modelo son:

1. Organización Informática.
2. Plan Estratégico de TI
3. Arquitectura de la Información
4. Políticas y Procedimientos
5. Cumplimiento de Regulaciones Externas
6. Administración de Proyectos
7. Desarrollo, Mantenimiento o Adquisición de Software de Aplicación
8. Adquisición y Mantenimiento de la Infraestructura Tecnológica
9 Seguridad
10. Servicios de Procesamiento y/o Soporte Prestados por Terceros
11. Servicios de Internet / Extranet / Intranet
12. Monitoreo de los Procesos
13. Auditoría Interna de Sistemas

Fuente: www.arcert.org.ar


Comentario:

En el caso boliviano para el sector público se cuenta con un marco para la Gestión del sector público como es la Ley 1178 y sus decretos reglamentarios para los diferentes subsistemas (Sistema Organización Administrativa, Sistema de Presupuesto, Sistema de Control, etc.), al realizar una auditoría el marco Legal mínimo es el señalado anteriormente y para realizar una auditoría se deben seguir las Normas de Auditoría Gubernamental. Al redactar la normativa boliviana respecto a Gestión de Tecnologías de Información se procedió al revés, primero se aprobó la norma de auditoría (NAG 270 Normas de Auditoría de Tecnologías de la Información y la Comunicación), pero no se cuenta con una normativa de control interno para TI, más aún la NAG 270 indica que ante vacíos técnicos se debe considerar COBIT. Si un auditor aplica COBIT como marco normativo para realizar una auditoria de sistemas en el Sector Público Nacional, seguramente nos encontraremos no solamente con los 10 hallazgos mencionados anteriormente para el caso Argentino, más bien nos sorprenderían los resultados.

Los hallazgos mencionados en el caso Argentino son del 2005, esto demuestra que en otros países se preocuparon varios años atrás en temas de Tecnologías de la Información y Seguridad de la Información, lo que no sucedió en Bolivia, quizá los eventos recientes (amenaza de Anonymos al Presidente Morales, hackeo a la página de YPFB) sirvan para movilizar al gobierno y específicamente a los legisladores a considerar estos aspectos en la legislación y en las políticas de Estado.

¿Mínimamente qué necesitamos del Gobierno Nacional?

- Un Decreto Supremo que establezca el Sistema o Subsistema de Control Interno para Tecnologías de Información para el Sector Público, a partir de este, cada organismo del sector público elaboraría su Reglamento Específico. Se podría adoptar (o adaptar) la ISO 27002, tal como lo hizo el gobierno peruano recientemente.

- Una Ley Específica de Delitos Informáticos o una Ley que modifique el Código Penal y que incluya delitos informáticos.
Este punto no es tan difícil de cumplirlo, se podía haber avanzado algo con la Ley 164 (Ley de Telecomunicaciones y TICs) que en su anteproyecto aprobado por los Diputados incluía delitos como: Manipulación Informática; Alteración, Acceso y uso Indebido; Propiedad Intelectual; Falsedad Material; Falsedad Ideológica; Falsificación de documentos; Violación de Correspondencia; Secretos de correspondencia; Suplantación de Identidad; Sabotaje Informático; Delitos Telecom. Estos delitos fueron excluídos de forma inexplicable de la Ley Promulgada.
Ahora me pregunto ¿Cómo y bajo que marco legal se perseguirá a los autores de la amenaza de Anonymos al Presidente Morales y del hackeo a la página web de YPFB?:
Respuesta 1: Nuestro actual Código Penal Establece por ejemplo para el delito de “Alteración, acceso y uso indebido de datos informáticos” la sanción de “prestación de trabajo hasta un año o multa hasta doscientos días”, ya me imagino a los culpables (hackers) dictando clases de Word, Excel, Internet durante un año, ¡Qué castigo más ejemplar NO????!
Respuesta 2: Bajo que marco legal se perseguirá a los hackers?, bueno pues, bajo el marco legal actual, no hay de otra. Cuando se imputa penalmente a una persona por ejemplo por el delito de “Manipulación Informática (3 a 5 años)”, se le imputa también por otros delitos como abuso de confianza, falsedad material, falsedad ideológica, uso de instrumento falsificado.

- Un organismo gubernamental como el ArCERT (Coordinación de Emergencias en Redes Teleinformáticas - Argentina) que sería una unidad de respuesta ante incidentes en redes, que centraliza y coordina los esfuerzos para el manejo de los incidentes de seguridad que afecten a los recursos informáticos de la Administración Pública Nacional (APN), es decir, cualquier ataque o intento de penetración a través de sus redes de información.

viernes, 15 de abril de 2011

SEGURIDAD DE INFORMACION PARA PyMES

Después de muchos años de estándares de seguridad (o buenas prácticas) dirigidos a corporaciones se está girando la mirada a las PyMES debido a su aporte económico (En Argentina representan cerca del 60% del PIB).

Otro caso en el que se le está dando la importancia debida a las PyMES es la "Mejora de procesos de Software para pequeñas empresas" como es COMPETISOFT y también el "Modelo de ciclo de vida de software para pequeñas empresas" ISO/IEC 29110.

Ya hablando de la NISTIR 7621, a muchos les parecerán recomendaciones muy obvias pero las PyMES seguramente valorarán en alto grado este documento si lo aplican. En 20 páginas incluidos los 3 anexos se presenta los fundementos básicos de seguridad de información para una PyME.

A continuación una traducción del índice del documento:

SEGURIDAD DE INFORMACION PARA PyMES(*): LOS FUNDAMENTOS
NISTIR 7621
Richard Kissel
Octubre 2009


Acciones "absolutamente necesarias" que las PyMES deberían tomar para proteger su información, sistemas y redes.
1. Proteger información/sistemas/redes del daño de virus, spyware y otros códigos maliciosos.
2. Proveer seguridad a las conexiones de Internet.
3. Instalar y activar programas firewalls en todos los sistemas del negocio.
4. Parchar los sistemas operativos y las aplicaciones.
5. Realizar copias de seguridad de los datos/información importantes.
6. Controlar el acceso físico a las computadoras y a los componentes de la red.
7. Securizar/asegurar los puntos de acceso de la red inalámbrica y de las redes.
8. Entrenar a los empleados en principios básicos de seguridad.
9. Requerir cuentas de usuario individual para cada empleado en las computadoras del negocio y para las aplicaciones de negocio.
10. Limitar el acceso de empleados a datos e información y limitar la autorización para instalar software.

Prácticas altamente recomendadas
1. Preocuparse acerca de la seguridad de los adjuntos de email y petición de emails con información sensible.
2. Preocuparse acerca de los enlaces web en los emails, mensajería instantánea, redes sociales y otros.
3. Preocuparse acerca de ventanas emergentes y otros trucos de hackers.
4. Hacer los negocios en linea o banca más segura.
5. Prácticas de personal recomendadas al contratar empleados.
6. Consideraciones de seguridad para la navegación web.
7. Problemas en descargas de software de Internet.
8. Como conseguir ayuda con la seguridad de información cuando lo necesites.
9. Como deshacerse de computadoras y medios de almacenamientos viejos
10. Como protegerse contra la Ingenieria Social

Otras consideraciones para información, computación y seguridad en redes.
1. Consideraciones de Planes de Contingencia y Recuperación de Desastres.
2. Consideraciones de anulación de costos en seguridad de información.
3. Políticas de negocio relacionadas a seguridad de información y otros tópicos.

Apéndice A: Identificando y priorizando los tipos de información de tu organización
Apéndice B: Identificando la protección necesaria para las prioridades por tipos de información de tu organización
Apéndice C: Estimando los costos de que sucedan cosas malas a la información importante del negocio.

(*) La traducción literal de "Samll business" es "pequeños negocios" sin embargo se optó en vez de esta por PyMES.

Descargar el documento completo (pdf)

jueves, 7 de abril de 2011

Continuidad del Negocio para PyMES

Como prepararse:

* Backup de datos electrónicos
Las PyMES pueden utilizar algunas herramientas para respaldar sus datos de las PCs en forma casi instantánea en la "nube". Pero claro deben tomarse las medidas necesarias de seguridad si la información es sensible o estratégica.

* Backup de documentos basados en papel
Las PyMES con las actuales tecnologías tienen la posibilidad de eliminar casi completamente la utilización del papel (paperless) en sus operaciones diarias y transferir todo a formatos digitales, para los casos en que la documentación en papel "debe" mantenerse, esta puede ser escaneada para propósitos de continuidad del negocio.

* Sistio alternativo para las oficinas
En muchos de los casos será suficiente con que los trabajadores puedan realizar su trabajo desde sus hogares, pero el requisito será que estos tengan acceso computadoras/laptos/smarthpones e Internet con la debida seguridad implementada (Ej. las 2 semanas de alerta el año 2009 por la gripe H1N1 en la Argentina). Si el trabajo desde el hogar no es posible, siempre se puede optar por opciones rentadas (Ej. habitaciones de hotel u oficinas alquiladas por horas)

* Hardware
Si no es el caso de computadoas especiales para el uso en el negocio, será muy fácil encontrar una alternativa, (computadoras de casa o alquiler de las mismas).

* Equipo de trabajo ó Humanware backup
Quizá el elemento más importante y difícil de implementar.
Supongamos que un empleado clave no está disponibles, y por tanto es el la única persona que conoce ciertos aspectos (ej. contraseñas administrativas, los pasos necesarios para arrancar un proyecto, etc). Para estos casos dicha información deberá estar documentada, de tal manera que se puede utilizar sin que el empleado en cuestión esté presente.
Otro caso podría ser la pérdida de un empleado clave y ningún otro tiene el tiempo o las habilidades necesarias, en estos casos la preparación necesaria debe ser identificada para afrontar y asignar o contratar a otra persona en un corto tiempo. La clave en este punto es identificar a alguien con las habilidades y conocimientos necesarios.

Para concluir: no existe diferencia sustancial entre empresas grandes y pequeñas cuando se habla de continuidad del negocio, ambos tipos de empresas deberían pensar en forma detallada las necesidades para desarrollar la recuperación ante desastres. La diferencia está en el nivel de preparación, las PyMES lo deberán hacier con mucho menos inversión.

Fuente: Traducción parcial de: http://blog.iso27001standard.com/

Cabe mencionar que existen estándares para PyMES, por ejemplo se tiene
ISSA 5173: estándar para la seguridad de la información dirigido a PyMES información dirigido a Pymes

sábado, 11 de diciembre de 2010

La NASA vendió PCs sin borrado seguro de datos sensibles

La NASA reveló que 10 computadoras usadas en el programa de transbordadores se vendieron al público sin haber borrado en forma segura los datos sensibles.

Una otra computadora que fue confiscada antes que fuera vendida, contenía información relacionada a tecnología del programa de transbordadores, que está sujeta a control de exportación por Regulaciones Internacionales de Tráfico de Armas.

Además, computadoras que se preparaban para la venta fueron encontradas en el Centro Espacial Kennedy en su depósito de desechos conteniendo información de Protocolos de Internet de la NASA, la cual según dijeron los investigadores podría proporcionar a los hackers detalles necesarios para explotar las vulnerabilidades de la red de la NASA.

La NASA estaba vendiendo las computadoras al prepararse para retirar el programa de transbordadores después de 38 años con el lanzamiento del transbordador espacial progrmado para Junio 2011.

En una revisión interna, la agencia espacial encontró que los Centros Espaciales Kennedy y Johnson y el Centro de Investigación Ames utilizan software para borrado seguro (wipe) del equipamiento antes de disponer de ellos. El Centro de investigación Langley no requiere esta tecnología debido a que remueve los discos duros (hard drives) en forma previa a su disposición final. Aunque el centro Kenedy era el único que tenía un procedimiento de prueba implementado para verificar que los discos fueron realmente sometidos al proceso de borrado seguro (wiped) tal como los requieren las políticas de la NASA.

No obstante se identificaron debilidades en los cuatro centros sobre políticas de "sanitización".

Por ejemplo, Kennedy, Johnson y Ames utilizaban software de borrado seguro no aprobado, Langley no registraba o dejaba pista sobre los discos duros removidos, y en Kennedy no se notificaba a los administradores cuando la prueba de verificación de sanitización de las computadoras fallaba.

Se encontraron fallas en el proceso de verificación del centro Kennedy que resultó en la venta (y casi venta) de computadoras que contenían todavía datos sensibles.

"Esto ocurre porque los administradores de la NASA no supervisan adecuadamente el proceso de sanitización y disposición," dijo en su informe el inspector general de la oficina de la agencia espacial, el informe se denomina 'Preparación para el retiro del programa espacial de transbordadores: Una revisión de la disposición de equipos de tecnología de información de la NASA'

"Las políticas de sanitización de la NASA están incompletos y el personal responsable no sigue consistentemente las políticas aplicables o no eran conscientes de ellas"

Los investigadores independientes recomendaron al CIO (Chief Information Officer) de la NASA llevar a cabo futuras revisiones, tomar acciones correctivas y seguir la mejores prácticas.

Traducción por: frauditor
Fuente: www.networkworld.com

martes, 10 de agosto de 2010

Continuous Auditing Tool (CAT)

Continuous Auditing Tool (CAT)
Herramienta de Auditoria Continua

La Auditoría Contínua "es un método usado para ejecutar automáticamente controles y evaluación de riesgos con mayor frecuencia, y la tecnología es clave para el éxito de este enfoque." (David Coderre, Global Technology Audit Guide - GTAG 3).

Coninuous Auditing Tool (CAT) se diseñó como una herramienta tecnológica para implementar el enfoque de "Auditoría Contínua".

CAT permite ejecutar más de 50 procedimientos de auditoría predefinidos agrupados en diferentes módulos entre los cuales se tiene: Libro Diario, Inventario, Cuentas por Pagar/Cobrar, Logs de Seguridad.

Con CAT se podrá implementar un enfoque de "Auditoría Contínua" en el Departamento de Auditoría realizando las evaluaciones casi en tiempo real mediante la ejecución automática de procedimientos y con mayor frecuencia entre una Auditoría y Otra.

CAT es una de las tecnologías necesarias para acceder, manipular y analizar los datos contenidos en sistemas de información diferentes.

Lo único que tendrá que hacer con el software es importar los datos sujetos a análisis y todos los procedimientos de auditoría se realizan en forma automática, optimizando el tiempo del auditor para dedicarlo al análisis de los resultados, ya no tendrá que dedicarse a la tediosa tarea de diseñar sus pruebas.

El software garantiza la integridad de los datos importados ya que estos son de solo lectura.

Los resultados se pueden exportar a formatos como MS Excel.

Entre las funciones que aplicará cada procedimiento de auditoría se tienen:
- Análisis de Frecuencia Digital
- Pruebas redondeo de números
- Análisis de Duplicados
- Identificación de Faltantes
- Identificación de Registros Fantasmas
- Detección de Outliers
- Detección de Patrones Sospechosos
- Localizar Inconsistencias en datos
- Análisis de Registros por Usuario
- Identificación de registros con fechas/horas inusuales
- Localizar Registros con fechas aproximadas
- Cálculo de Antiguedad de fechas
- Cálculo de Índices
- Identificar Tendencias de Performance y Eficiencia
- Recálculo de fórmulas
- Cálculo del Tamaño de la Muestra
- Proyección de Resultados muestrales a la Población
- Selección Aleatoria de muestras

Nota1: Se podrá realizar la "customización" del software y añadirle nuevos módulos o nuevos procedimientos de auditoría de acuerdo a los requerimientos del Auditor.

Nota2: Se realiza la implementación del software CAT para los Programas Generalizados de Auditoria (IDEA, ACL) en los cuales se implementa los procedimientos de auditoría del software CAT mediante Scripts específicos para cada herramienta.

Fuente: www.caatts.com.ar

jueves, 8 de enero de 2009

NIAs (2006)

El Colegio de Auditores de Cochabamba (Bolivia) puso a disposición las Normas Internacionales de Auditoría (NIAs versión 2006) en formato PDF en el siguiente enlace:
Normas Internacionales de Auditoria

ÍNDICE NIAs 2006
ÍNDICE NIAs 2006-ARREGLADAS
NICC 1 IFAC NIAs 2006
NIA 200 OBJETIVO Y PRINCIPIOS GENERALES QUE GOBIERNAN UNA AUDITORIA DE EE.FF.
NIA 210 TÉRMINOS DE LOS TRABAJOS DE AUDITORÍA
NIA 220 CONTROL DE CALIDAD PARA AUDITORÍAS DE INFORMACIÓN FINANCIERA HISTORICA
NIA 230 REVISADA DOCUMENTACION DE AUDITORIA
NIA 240 RESPONSABILIDAD DEL AUDITOR DE CONSIDERAR EL FRAUDE EN UNA AUDITORIA DE EE. FF.
NIA 250 CONSIDERACION DE LEYES Y REGLAMENTOS EN UNA AUDTORIA DE EE.FF
NIA 260 COMUNICACIONES DE ASUNTOS DE AUDITORIA CON LOS ENCARGADOS DEL GOBIERNO CORPORATIVO
Arreglada - NIA 300 PLANEACION DE UNA AUDITORIA DE ESTADO
NIA 315 ENTENDIEMIENTO DE LA ENTIDAD Y SU ENTORNO Y EVALUACIÓN DE LOS RIESGOS DE PRESENTACIÓN ER
Arreglada - NIA 320 IMPORTANCIA RELATIVA DE LA AUDITORIA
Arreglada - NIA 330 PROCEDIMIENTOS DEL AUDITOR EN RESPUESTA A LOS RIESGOS EVALUADOS
NIA 402 CONSIDERACIONES DE AUDITORIA RELATIVAS A ENTIDADES QUE UTILIZAN ORG. DE SERVICIO
NIA 500 EVIDENCIA DE AUDITORÍA
NIA 501 EVIDENCIA DE AUDITORIA - CONSIDERACIONES ADICIONALES PARA PARTIDAS ESPECIFICAS
NIA 505 CONFIRMACIONES EXTERNAS
NIA 510 TRABAJOS INICIALES - BALANCES DE APERTURA
NIA 520 PROCEDIMIENTOS ANALITICOS
NIA 530 MUESTREO DE LA AUDITORIA Y OTROS MEDIOS DE PRUEBAS
NIA 540 AUDITORIA DE ESTIMACIONES CONTABLES
NIA 545 AUDITORIA DE MEDICIONES Y REVELACIONES DEL VALOR RAZONABLE
NIA 550 PARTES RELACIONADAS
NIA 560 HECHOS POSTERIORES
NIA 570 NEGOCIO EN MARCHA
NIA 580 REPRESENTACIONES DE LA ADMINISTRACION
NIA 600 USO DEL TRABAJO DE OTRO AUDITOR
NIA 610 CONSIDERACIÓN DEL TRABAJO DE AUDITORÍA INTERNA
NIA 620 USO DEL TRABAJO DE UN EXPERTO
NORMA INTERNACIONAL DE AUDITORIA 700 _REVISADA_
NORMA INTERNACIONAL DE AUDITORIA 701
NIA 710 COMPARATIVOS
NIA 720 OTRA INFORMACIÓN EN DOCUMENTOS QUE CONTIENEN ESTADOS FINANCIEROS AUDITADOS
NIA 800 EL DICTAMEN DEL AUDITOR SOBRE TRABAJOS DE AUDITORÍA CON PROPÓSITO ESPECIAL

lunes, 24 de noviembre de 2008

AUDITORIA CERO

En los últimos 20 años el concepto de Control Interno ha ido evolucionando, esto se puede ver claramente en el sector gubernamental antes de la aprobación y aplicación de la Ley SAFCO (1990), esta Ley adopta el informe COSO como base para el desarrollo de los diferentes subsistemas (Programación, Organización, Presupuesto, Personal, Administración, Tesoreria, Contabilidad, Control).

El subsistema de Control Gubernamental está compuesto por:

El Control Interno Previo, ejercido por TODAS LAS UNIDADES de la entidad antes de la ejecución de sus operaciones y actividades o de que sus actos causen efectos.

El Control Interno Posterior practicado por los RESPONSABLES SUPERIORES y por la UNIDAD DE AUDITORIA INTERNA de la propia entidad.

El Control Externo Posterior que se aplicará por medio de la auditoría externa de las operaciones ya ejecutadas, este control es practicado por Empresas de Auditoria Externa o por la Contraloría General de la República.

A pesar de estos cambios, todavia encontramos en muchas instituciones la confusión al hablar de control o más específicamente de CONTROL INTERNO, se relaciona directamente con AUDITORIA INTERNA, sin considerar el concepto dado por el informe COSO que define al control interno como: "un proceso efectuado por el consejo de administración, la dirección y el RESTO DEL PERSONAL de una entidad, diseñado con el objeto de proporcionar un grado de seguridad razonable en cuanto a la consecución de objetivos"

De esto podemos concluir que la Unidad de Auditoría Interna es una parte más del Control Interno y no es la unidad encargada de REALIZAR EL CONTROL.

Con la finalidad de dar cumplimiento a los planes, programas y presupuestos de la entidad en concordancia con las políticas, objetivos y metas propuestas, quizás debemos retomar los conceptos del COSO y de las auditoria de calidad para dar lugar a la AUDITORIA CERO que a continuación se desarrolla:


Cumplimiento: Los sistemas de información de la entidad deben estar Formalizados, Implementados y Actualizados considerando las leyes y regulaciones para prevenir pérdidas financieras o de imagen.

Estrategia: Los sistemas de información (automatizados o manuales, comprados o desarrollados internamente) deben estar alineados con los objetivos de la organización y coadyuvar al logro de la misión de la entidad.

Reportes: Los sistemas de información deben producir información de una manera adecuada, completa y a tiempo.

Operación: Los sistemas de información deben cumplir con el criterio de operación, es decir deben ser acordes a la estructura, y características particulares de cada entidad. Así mismo deberán considerar el Riesgo Operacional para sus diferentes procesos operativos (Ej. Riesgo legal, financiero, mercadeo, crediticio, liquidez, informático).

Lineas arriba se hace mención a sistemas de información, entendiéndose como tales a los subsistemas de la Ley SAFCO o los subsistemas que diseñe la entidad. Entendiéndose que tales sistemas son operados por personas y son ellas las que aseguran el cumplimiento de la AUDITORIA CERO.

Con este enfoque de "Auditoria CERO" no es que los Auditores Internos desaparecerán sino que se le dará el verdadero valor al control interno y al Auditor Interno.
web stats