Auditoria de Sistemas

Bienvenida

Saludos a todos, les doy la Bievenida a este blog cuyo titulo es:  Auditoria de Sistemas, el cual contiene diferentes temas,  videos, referentes al titulo que nos servira para conocer y entender de que se trata la Auditoria de Sistemas.

Ds9 Administración de la configuración

• Ds9 Administración de la configuración

Objetivo: Dar cuenta de todos los componentes de TI, prevenir alteraciones no autorizadas, verificar la existencia física y proporcionar una base para el sano manejo de cambios

Para ello se realizan controles que identifiquen y registren todos los activos de TI así como su localización física y un programa regular de verificación que confirme su existencia y toma en consideración:

• Registro de activos estableciendo procedimientos para asegurar que sean registrados únicamente elementos de configuración autorizados e identificables en el inventario, al momento de adquisición
• Administración de cambios en la configuración asegurando que los registros de configuración reflejen el status real de todos los elementos de la configuración
• Chequeo de software no autorizado revisando periódicamente las computadoras personales de la organización
• Controles de almacenamiento de software definiendo un área de almacenamiento de archivos para todos los elementos de software válidos en las fases del ciclo de vida de desarrollo de sistemas

·          

Breve Introduccion al modelo COBIT

COBIT,  es una herramienta de gobierno de TI que ha cambiado la forma en que trabajan los profesionales de TI. Vinculando tecnología informática y prácticas de control, COBIT consolida y armoniza estándares de fuentes globales prominentes en un recurso crítico para la gerencia, los profesionales de control y los auditores.

COBIT se aplica a los sistemas de información de toda la empresa, incluyendo las computadoras personales, mini computadoras y ambientes distribuidos. Esta basado en la filosofía de que los recursos de TI necesitan ser administrados por un conjunto de procesos naturalmente agrupados para proveer la información pertinente y confiable que requiere una organización para lograr sus objetivos.
Misión: Investigar, desarrollar, publicar y promover un conjunto internacional y actualizado de objetivos de control para tecnología de información que sea de uso cotidiano para gerentes y auditores.

  

Metodologia de una Auditoria en Sistemas

METODOLOGÍA DE UNA AUDITORÍA DE SISTEMAS

Existen algunas metodologías de Auditorias de Sistemas y todas dependen de lo que se pretenda revisar o analizar,

Pero como estándar analizaremos las cuatro fases básicas de un proceso de revisión:

• Estudio preliminar
• Revisión y evaluación de controles y seguridades
• Examen detallado de áreas criticas
• Comunicación de resultados

 Estudio preliminar:

Incluye definir el grupo de trabajo, el programa de auditoria, efectuar visitas a la unidad

Informática para conocer detalles de la misma, elaborar un cuestionario para la obtención de información para

Evaluar preliminarmente el control interno, solicitud de plan de actividades, Manuales de políticas, reglamentos,

Entrevistas con los principales funcionarios del PAD.

Revisión y evaluación de controles y seguridades:

Consiste de la revisión de los diagramas de flujo de procesos,

Realización de pruebas de cumplimiento de las seguridades, revisión de aplicaciones de las áreas criticas, Revisión de

Procesos históricos (backups), Revisión de documentación y archivos, entre otras actividades.

Examen detallado de áreas criticas:

Con las fases anteriores el auditor descubre las áreas críticas y sobre ellas hace

Un estudio y análisis profundo en los que definirá concretamente su grupo de trabajo y la distribución de carga del

Mismo, establecerá los motivos, objetivos, alcance Recursos que usará, definirá la metodología de trabajo, la

Duración de la auditoría, Presentará el plan de trabajo y analizará detalladamente cada problema encontrado con todo

Lo anteriormente analizado.

Comunicación de resultados:

Se elaborará el borrador del informe a ser discutido con los ejecutivos de la empresa

Hasta llegar al informe definitivo, el cual se presentará esquemáticamente en forma de matriz, cuadros o redacción

Simple y concisa que destaque los problemas encontrados, los efectos y las recomendaciones de la Auditoría.

El informe debe contener lo siguiente:

• Motivos de la Auditoría

• Objetivos

• Alcance

• Estructura Orgánico-Funcional del área Informática

• Configuración del Hardware y Software instalado

• Control Interno

• Resultados de la Auditoria

PLAN DE CONTINGENCIA

Consiste en la identificación de aquellos sistemas de información y/o recursos informáticos aplicados que son susceptibles de deterioro, violación o pérdida y que pueden ocasionar graves trastornos para el desenvolvimiento normal de la organización, con el propósito de estructurar y ejecutar aquellos procedimientos y asignar responsabilidades que salvaguarden la información y permitan su recuperación garantizando la confidencialidad, integridad y disponibilidad de ésta en el menor tiempo posible y a unos costos razonables.

El plan de contingencia debe cubrir todos los aspectos que se van a adoptar tras una interrupción, lo que implica suministrar el servicio alternativo y para lograrlo no solo se deben revisar las operaciones cotidianas, sino que también debe incluirse el análisis de los principales distribuidores, clientes, negocios y socios, así como la infraestructura en riesgo. Esto incluye cubrir los siguientes tópicos: hardware, software, documentación, talento humano y soporte logístico; debe ser lo más detallado posible y fácil de comprender.

Se debe evaluar el nivel de riesgo de la información para hacer:

• Un adecuado estudio costo/beneficio entre el costo por pérdida de información y el costo de un sistema de seguridad.
• Clasificar la instalación en términos de riesgo (alto, mediano, bajo) e identificar las aplicaciones que representen mayor riesgo.
• Cuantificar el impacto en el caso de suspensión del servicio.
• Determinar la información que pueda representar cuantiosas pérdidas para la organización o bien que pueda ocasionar un gran efecto en la toma de decisiones.

Cuando ocurra una contingencia, es esencial que se conozca al detalle el motivo que la originó y el daño producido mediante la evaluación y análisis del problema donde se revisen las fortalezas, oportunidades, debilidades y amenazas, lo que permitirá recuperar en el menor tiempo posible el proceso perdido.

El plan debe incluir una lista de los sistemas, aplicaciones y prioridades, igualmente debe identificar aquellos elementos o procedimientos informáticos como el hardware, software básico, de telecomunicaciones y el software de aplicación, que puedan ser críticos ante cualquier eventualidad o desastre y jerarquizarlos por orden de importancia dentro de la organización. También se deben incluir en esta categoría los problemas asociados por la carencia de fuentes de energía, utilización indebida de medios magnéticos de resguardo o back up o cualquier otro daño de origen físico que pudiera provocar la pérdida masiva de información.

Por todos es bien conocida la importancia que reviste en mantener activa y con fluidez la articulación Universidad – Empresa, de tal forma que el conocimiento impartido en las aulas de clase pueda ser contrastado con las realidades que se vive en las diferentes empresas, resultando beneficiadas ambas partes con planteamientos y soluciones acorde a las necesidades particulares que demanda la región y el país.

• Un Plan de Contingencia es la herramienta que cualquier empresa debe tener, para desarrollar la habilidad y los medios de sobrevivir y mantener sus operaciones, en caso de que un evento fuera de su alcance le pudiera ocasionar una interrupción parcial o total en sus funciones. Las políticas con respecto a la recuperación de desastres deben de emanar de la máxima autoridad Institucional, para garantizar su difusión y estricto cumplimiento.
• Deben realizarse pruebas para determinar la eficacia del plan de contingencia y de los procedimientos de recuperación ante desastres. Las deficiencias deben resolverse y comprobarse inmediatamente. En un plan de contingencia, el objetivo consiste en ejecutar varias tareas en el menor tiempo posible. Cualquier deficiencia en la documentación, capacitación o, incluso, en los aspectos administrativos, pone en peligro la continuidad del negocio.
• La puesta en marcha de los planes a seguir es responsabilidad del encargado de la seguridad, pero también debe existir un compromiso por parte de los usuarios del sistema de información, ejecutivos y todas las personas que de alguna u otra forma ayudan a que el sistema cumpla con los requerimientos para el que fue diseñado, manteniendo sobre todo la integridad y confidencialidad de la información.
• El plan de contingencias tiene diferentes niveles de complejidad y flexibilidad según las necesidades y características de los grupos, empresas u organizaciones. Nunca se contará con los recursos suficientes para estar totalmente preparados, de ahí que el proceso deba ser paulatino e ir evolucionando según el contexto.
• El cambio es inevitable en la construcción de sistemas basados en computadoras; por ello se deben desarrollar mecanismos de evaluación, control e implementación de modificaciones al sistema ocasionadas por nuevos requerimientos de los usuarios, por disposiciones internas de la organización y/o gubernamentales, para corregir errores, para aprovechar los nuevos avances tecnológicos, para satisfacer nuevas necesidades o para mejorar los sistemas en funcionamiento.
• Se debe tener una adecuada seguridad orientada a proteger todos los recursos informáticos desde el dato más simple hasta lo más valioso que es el talento humano, motor de desarrollo y vida de los sistemas de información; pero no se puede caer en excesos diseñando tantos controles y medidas que desvirtúen el propio sentido de la seguridad, por consiguiente, se debe hacer un análisis de costo/beneficio evaluando las consecuencias que pueda acarrear la pérdida de información y demás recursos informáticos, así como analizar los factores que afectan negativamente la productividad de la empresa. 

Riesgos Informaticos

 Riesgo es la incertidumbre que ocurra un evento que podría tener un impacto en el logro de los objetivos.

Los riesgos cuando se materializan, se denominan errores, irregularidades u omisiones, los cuales pueden generar una pérdida monetaria, en la imagen de la empresa o incumplimiento de normativa externa.

 Riesgo = Impacto * Probabilidad

• Impacto: es el efecto o consecuencia cuando el riesgo se materializa
• Probabilidad: representa la posibilidad que un evento dado ocurra.

Clasificacion de los reisgos informaticos:

 Riesgo Inherente:

Riesgo inherente son aquellos riesgos propios de la materia y/o componentes de ésta. Se entiende que una materia por su naturaleza tiene riesgos que surgen por diversas fuentes, como los errores, irregularidades o fallas que pudieran ser importantes en forma individual o en conjunto con otros riesgos. Los riesgos inherentes a la materia pueden tener o no controles elaborados por la dirección para mitigar su probabilidad o su impacto.

Los riesgos inherentes a la materia bajo análisis pueden ser relativos al entorno, ambiente interno, procesos, información, etc.

• Riesgo de Crédito: Exposición a una pérdida real o el costo de oportunidad como consecuencia del incumplimiento de pago de una persona natural o jurídica.
• Riesgo Financiero: ocurrencia de un imprevisto por variaciones o cambios en la economía local o internacional que podría afectar los descalces de caja o posiciones asumidas por inversiones y su liquidez, como asimismo los descalces globales de activos.
• Riesgo Operacional: Se define como el riesgo de pérdida debido a la inadecuación o fallas en los procesos, el personal y los sistemas internos o bien a causa de acontecimientos externos (fraudes, daños activos materiales, fallas en procesos,etc). Incluye riesgos legales y normativos.

Riesgo de Integridad de la Información: Agrupa todos los riesgos asociados con la autorización, integridad, y exactitud de las transacciones según se ingresan, se procesan, se resumen y se informan en los sistemas computacionales de una organización, manifestándose en los siguientes componentes de un sistema:

•  Interfaz usuaria; se refiere a si existen restricciones que hagan que los trabajadores de una organización estén autorizados a desarrollar funciones de negocio sobre necesidad del negocio y la necesidad de lograr una segregación de funciones razonable.
• Procesamiento; se relacionan a la existencia de controles que aseguran que el procesamiento de datos se ha completado y realizado a tiempo.

 Riesgo de Acceso; puede ocurrir en cada uno o todos de los siguientes cinco niveles:

•  Red, el riesgo en esta área está generado por el riesgo de acceso inapropiado a la red a pc´s y servidores.
• Ambiente de Procesamiento, el riesgo se genera con el acceso indebido al ambiente de procesamiento a los programas y datos que están almacenados en ese ambiente.
• Sistemas de Aplicación, está dado por una inadecuada segregación de funciones que podría ocurrir si el acceso a los sistemas estuviese concedido a personas con necesidades de negocio sin definiciones claras.
• Acceso Funcional, dentro de aplicaciones (Código fuente)
• Acceso a nivel de campo o dato.

Riesgo de Disponibilidad

• Riesgos asociados con la interrupción de los sistemas a corto plazo donde las técnicas de restitución/recuperación se pueden utilizar para minimizar el alcance de la interrupción
• Riesgos asociados con desastres que causan interrupciones en el procesamiento de la información a largo plazo y que se centran en controles como backups y planes de contingencia. La capacidad de la empresa para continuar con sus operaciones y procesos críticos puede depender en gran medida de la disponibilidad de determinados sistemas de información.

Riesgo de Infraestructura una organización no tenga una infraestructura eficaz de información tecnológica (HW, SW, personas y procesos) para apoyar eficazmente las necesidades actuales y futuras del negocio de una forma eficiente y eficaz en términos de costos y controles. Principalmente están relacionados con:

• Planificación organizacional; el riesgo de que los planes de información tecnológica no estén integrados con los planes del negocio presentes y futuros, afectando el proceso de toma de decisiones y planificaciones inadecuadas.
• Definición y despliegue de sistemas de aplicación; el riesgo de que las definiciones y necesidades de los usuarios para nuevas soluciones de sistemas provoquen diseños ineficaces o incompletos. Los esfuerzos de desarrollo no siguen un enfoque consistente para confirmar la satisfacción del usuario y del negocio. Los esfuerzos de implantación no consideran adecuadamente el entrenamiento

 MATRIZ DE RIESGO

Herramienta fundamental, para evaluar los controles que deben de estar presentes tanto en las aplicaciones como en su entorno. Seleccionadas aquellas funciones que constituyen riesgos y causas de riesgo, pueden ser evaluados con precisión, el éxito alcanzado por cada control, determinando aquellos, que por débiles o insuficientes, actúan adversamente o con un efecto inversamente proporcional al esperado (causas de riesgos).

 Análisis de Riesgos Informáticos

El análisis de riesgos informáticos es un proceso que comprende la identificación de activos informáticos, sus vulnerabilidades y amenazas a los que se encuentran expuestos así como su probabilidad de ocurrencia y el impacto de las mismas, a fin de determinar los controles adecuados para aceptar, disminuir, transferir o evitar la ocurrencia del riesgo.

El proceso de análisis de riesgo genera habitualmente un documento al cual se le conoce como matriz de riesgo. En este documento se muestran los elementos identificados, la manera en que se relacionan y los cálculos realizados. Este análisis de riesgo es indispensable para lograr una correcta administración del riesgo. La administración del riesgo hace referencia a la gestión de los recursos de la organización. Existen diferentes tipos de riesgos como el riesgo residual y riesgo total así como también el tratamiento del riesgo, evaluación del riesgo y gestión del riesgo entre otras. La fórmula para determinar el riesgo total es: RT (Riesgo Total) = Probabilidad x Impacto Promedio A partir de esta fórmula determinaremos su tratamiento y después de aplicar los controles podremos obtener el Riesgo Residual.

Como se describe en el BS ISO / IEC 27001:2005, la evaluación del riesgo incluye las siguientes acciones y actividades.

• Identificación de los activos

• Identificación de los requisitos legales y de negocios que son relevantes para la identificación de los activos

• Valoración de los activos identificados

• Teniendo en cuenta los requisitos legales identificados de negocios y el impacto de una pérdida de confidencialidad, integridad y disponibilidad.

• Identificación de las amenazas y vulnerabilidades importantes para los activos identificados.

• Evaluación del riesgo, de las amenazas y las vulnerabilidades a ocurrir.

• Cálculo del riesgo.

• Evaluación de los riesgos frente a una escala de riesgo preestablecidos

Después de efectuar el análisis debemos determinar las acciones a tomar respecto a los riesgos residuales que se identificaron. Las acciones pueden ser:

• Controlar el riesgo.- Fortalecer los controles existentes y/o agregar nuevos controles.
• Eliminar el riesgo.- Eliminar el activo relacionado y con ello se elimina el riesgo.
• Compartir el riesgo.- Mediante acuerdos contractuales parte del riesgo se traspasa a un tercero.

Aceptar el riesgo.- Se determina que el nivel de exposición es adecuado y por lo tanto se acepta.

PROCEDIMIENTOS Y TECNICAS DE AUDITORIA.

Se requieren varios pasos para realizar una auditoría. El auditor de sistemas debe evaluar los riesgos globales y luego desarrollar un programa de auditoría que consta de objetivos de control y procedimientos de auditoría que deben satisfacer esos objetivos. El proceso de auditoría exige que el auditor de sistemas reúna evidencia, evalúe fortalezas y debilidades de los controles existentes basado en la evidencia recopilada, y que prepare un informe de auditoría que presente esos temas en forma objetiva a la gerencia. Asimismo, la gerencia de auditoría debe garantizar una disponibilidad y asignación adecuada de recursos para realizar el trabajo de auditoría además de las revisiones de seguimiento sobre las acciones correctivas emprendidas por la gerencia.

Planificación de la auditoria

Una planificación adecuada es el primer paso necesario para realizar auditorías de sistema eficaces. El auditor de sistemas debe comprender el ambiente del negocio en el que se ha de realizar la auditoría así como los riesgos del negocio y control asociado. A continuación se menciona algunas de las áreas que deben ser cubiertas durante la planificación de la auditoría:

1. Comprensión del negocio y de su ambiente. Al planificar una auditoría, el auditor de sistemas debe tener una comprensión de suficiente del ambiente total que se revisa. Debe incluir una comprensión general de las diversas prácticas comerciales y funciones relacionadas con el tema de la auditoría, así como los tipos de sistemas que se utilizan. El auditor de sistemas también debe comprender el ambiente normativo en el que opera el negocio. Por ejemplo, a un banco se le exigirá requisitos de integridad de sistemas de información y de control que no están presentes en una empresa manufacturera. Los pasos que puede llevar a cabo un auditor de sistemas para obtener una comprensión del negocio son: Recorrer las instalaciones del ente. Lectura de material sobre antecedentes que incluyan publicaciones sobre esa industria, memorias e informes financieros. Entrevistas a gerentes claves para comprender los temas comerciales esenciales. Estudio de los informes sobre normas o reglamentos. Revisión de planes estratégicos a largo plazo. Revisión de informes de auditorías anteriores.
2. Riesgo y materialidad de auditoria.  Se puede definir los riesgos de auditoría como aquellos riesgos de que la información pueda tener errores materiales o que el auditor de sistemas no pueda detectar un error que ha ocurrido. Los riesgos en auditoria pueden clasificarse de la siguiente manera: Riesgo inherente: Cuando un error material no se puede evitar que suceda por que no existen controles compensatorios relacionados que se puedan establecer. Riesgo de Control: Cuando un error material no puede ser evitado o detectado en forma oportuna por el sistema de control interno. Riesgo de detección: Es el riesgo de que el auditor realice pruebas exitosas a partir de un procedimiento inadecuado. El auditor puede llegar a la conclusión de que no existen errores materiales cuando en realidad los hay. La palabra "material" utilizada con cada uno de estos componentes o riesgos, se refiere a un error que debe considerarse significativo cuando se lleva a cabo una auditoría. En una auditoría de sistemas de información, la definición de riesgos materiales depende del tamaño o importancia del ente auditado así como de otros factores. El auditor de sistemas debe tener una cabal comprensión de estos riesgos de auditoría al planificar. Una auditoría tal vez no detecte cada uno de los potenciales errores en un universo. Pero, si el tamaño de la muestra es lo suficientemente grande, o se utiliza procedimientos estadísticos adecuados se llega a minimizar la probabilidad del riesgo de detección. De manera similar al evaluar los controles internos, el auditor de sistemas debe percibir que en un sistema dado se puede detectar un error mínimo, pero ese error combinado con otros, puede convertiré en un error material para todo el sistema. La materialidad en la auditoría de sistemas debe ser considerada en términos del impacto potencial total para el ente en lugar de alguna medida basado en lo monetario.
3. Técnicas de evaluación de Riesgos  Al determinar que áreas funcionales o temas de auditoría que deben auditarse, el auditor de sistemas puede enfrentarse ante una gran variedad de temas candidatos a la auditoría, el auditor de sistemas debe evaluar esos riesgos y determinar cuales de esas áreas de alto riesgo debe ser auditada. Existen cuatro motivos por los que se utiliza la evaluación de riesgos, estos son: Permitir que la gerencia asigne recursos necesarios para la auditoría. Garantizar que se ha obtenido la información pertinente de todos los niveles gerenciales, y garantiza que las actividades de la función de auditoría se dirigen correctamente a las áreas de alto riesgo y constituyen un valor.
4. Objetivos de controles y objetivos de auditoria. El objetivo de un control es anular un riesgo siguiendo alguna metodología, el objetivo de auditoria es verificar la existencia de estos controles y que estén funcionando de manera eficaz, respetando las políticas de la empresa y los objetivos de la empresa.
5. Procedimientos de auditoria.  Algunos ejemplos de procedimientos de auditoría son: Revisión de la documentación de sistemas e identificación de los controles existentes. Entrevistas con los especialistas técnicos a fin de conocer las técnicas y controles aplicados. Utilización de software de manejo de base de datos para examinar el contenido de los archivos de datos. Técnicas de diagramas de flujo para documentar aplicaciones automatizadas.

Mas informacion sobre Auditoria de Sistemas

http://www.itchetumal.edu.mx/paginasvar/Maestros/mduran/Archivos/METODOLOGIA%20DE%20UNA%20AUDITORIA%20DE%20SISTEMAS.pdf

Caso para Analizar de Auditoria y Respuesta

Caso para Analizar de Auditoria:

Usted ha sido contratado por la Empresa ABC, como Auditor de Informática, reportando directamente al Gerente General, con la finalidad que genere un informe de evaluación con respecto al Hardware y software de las computadoras de la empresa X.

La incertidumbre o sospecha que tiene el Gerente son:

1. Que los software que tiene instalados en las PC’s están replicados con las mismas licencias en algunas maquinas, lo que le acarrearía una cuantiosa multa con BSA (Bussiness Software Aliance), empresa dedicada a multar las empresas que utilicen software ilegales .Por el momento le interesa el.

: MS Windows Office

: Antivirus

:  Sistema Operativo Windows

2. Que le certifique si la configuración inicial con la que fueron adquiridas las computadoras corresponde a lo descrito en la factura cuya descripción es la siguiente:

: Procesador 3.0 Ghertz

: Disco Duro de 120 GB

: Memoria 2 Gb

: Sistema Operativo Windows XP

3. Elabore un informe de evaluación a la Gerencia que muestre el Panorama y su criterio como Auditor Informático.

 Respuesta por parte de Auditor de Sistema:

Panamá, 12 abril de 2011

Licenciado

Luis Pérez

Gerente General

A.B.C.

E.S.D.

Licenciado Pérez,

Hemos realizado lo estipulado en el contrato para la evaluación de Hardware y Software del equipo informático de su empresa.

Para la realización de nuestra labor hemos utilizado las herramientas, 

1.      WinAudit  programa que analiza las computadoras  y te muestra toda la información referente a programas instalados, sistema operativo, procesador, memoria, discos duros. 

2.      SYNC Pro Inventory Manager es una herramienta para obtener información confiable sobre el software y hardware de todos los equipos en una red.

Luego de una revisión exhaustiva de su equipo informático, hemos llegado a la conclusión de:

Software

1.      5 computadoras sin licencia valida de MS Windows Office

2.      3 computadores con las sin actualizar el antivirus 

3.      7 computadoras con la licencia de duplicada

Hardware

1.      todas mantiene el mismo procesador

2.      todas mantienen el mismo sistema operativo Windows XP

3.      3 computadoras con disco duro de menor capacidad,  

4.      6 computadoras con de diferencia en la memoria, mayor capacidad,

Por lo anterior recomendamos, realizar la compra de las licencias y  actualizaciones de los software, cambiar los disco duro de menor capacidad.

Atentamente
Dorys Ruiz

¿ Que es Checklists?

Un checklist es un listado de procedimientos para la consecusion de un objetivo, en este caso, la instalacion y correcto funcionamiento de la aplicacion a investigar, Ademas, sierve para ayudar a asegurar la consistencia e integridad en el desarrollo de la tarea, de tal modo, que sea reproducible siguiendo todos los pasos que constituyen el checklist.

Es muy utilizado en el aseguramiento de la calidad en ingenieria de software, para comprobar la conformidad de procesos, estandarizacion de codigo, prevenciones de errores y otros.

Para vuestros proyectos, los checklist se encuentran generalmente en la misma web, bajo las instrucciones de instalacion o similares, indicando paso a paso su implementacion, la cual deben tomar como base, y complementar con sus comentarios sobre la instalacion, siempre que proceda.

Por ejemplo, un check list de una reunión contiene la lista del conjunto de temas a tratar, llamada también, orden del día. En el caso de las auditorías de calidad, un check list contiene el conjunto de aspectos del sistema de gestión de una organización que vamos a verificar. Lo que también se puede interpretar como una planificación del desarrollo de la auditoría.

Checklists en la auditoria de sistema.

El auditor profesional y experto es aquél que reelabora muchas veces sus cuestionarios en función de los escenarios auditados. Tiene claro lo que necesita saber, y por qué. Sus cuestionarios son vitales para el trabajo de análisis, cruzamiento y síntesis posterior, lo cual no quiere decir que haya de someter al auditado a unas preguntas estereotipadas que no conducen a nada. 

EJEMPLO DE LISTADO NO EXHAUSTIVO DE COMPROBACIONES

Verificar 1 o varios ejemplos para cada comprobación. Si se detecta que puede haber algún incumplimiento, investigar más ejemplos, 4 o 5):

: Que todos los registros se realizan siguiente el formato descrito en los Anexos de los Procedimientos.

: Que todos los procedimientos que aplican a cada dpto. (Según las casillas con X en Lista de Distribución de la Lista de Documentos Vigentes).

: Que únicamente se compra a los proveedores de la Lista de Proveedores, que todos los proveedores han sido evaluados con la Ficha de Evaluación de Proveedor.

: Que todos los proveedores con evaluación por “Certificado de Calidad” se dispone de copia del certificado ó que se ha solicitado al mismo la copia del certificado.

: Que todos los campos de los formatos se registran adecuadamente, en particular los que describen códigos o referencias a otros documentos.

: En departamento Comercial: seguir varias ventas desde el inicio hasta la entrega final del producto.

¦ En cada pedido del programa de pedidos debe verificarse que se registro el presupuesto de dicho pedido.

¦ En cada Albarán debería hacerse referencia al pedido interno y al pedido del cliente si lo hay.

¦  En cada factura se hace referencia al Albarán de Entrega, al pedido interno.

¦ Que se han respetado en facturación los precios pactados mediante presupuesto, las tarifas pactadas para el cliente o los precios del catálogo si no hay pactos o presupuestos.

: Que los Expedientes de Personal están actualizados con los Cursos internos realizados.

: Que los Cursos impartidos han sido evaluados por el formador, registrando el resultado para cada persona (APTO / NO APTO) y que se registra el método de evaluación (recomendable prueba práctica in situ).

: Si se han realizado cambios en la documentación del Sistema de Calidad (procedimientos) comprobar que la Lista de Documentos Vigentes está actualizada con todos los documentos vigentes, según la última versión de los PGs y sus formatos (descritos en cada PG en los Anexos).

: Si se han incorporado o diseñado nuevos formatos o plantillas al Sistema de Gestión de Calidad, comprobar que se han incluido en algún procedimiento o al menos que se han incluido en la Lista de Documentos Vigentes, poniendo s/c (sin código) y quien revisa, archiva y redacta ese registro, y en fecha a partir de cuándo se utiliza. En versión no es necesario poner nada.

: Que los Perfiles de Puestos de Trabajo están actualizados si se han realizado cambios en los mismos (es decir, que si ahora si piden más requisitos de formación y experiencia para desempeñar el puesto de trabajo, se han incluido al perfil).

: Que los Expedientes de Personal de cada persona cumplen con los requisitos de Perfil de Puestos de los cargos que desempeñan actualmente. Ejemplo: si para ser Auditor Interno hace falta Curso de Auditorías Internas, en el Expediente Personal de los Auditores Internos deberá venir reflejada la realización de dicho curso y debería además adjuntarse una copia del diploma del curso.

: Que se ha realizado el Plan de Calidad para el año siguiente.

:  Que se han auditado todos los Departamentos y existe el correspondiente Informe de Auditoría.

: Que se ha realizado la revisión por la Dirección y que incluye todos los puntos descritos en el PG de Revisión por la Dirección.

: Que se han emitido las encuestas de Satisfacción del cliente y que se han analizado los resultados de las respuestas.

: Que se han registrado en Registro de Acciones Formativas los cursos realizados interna o externamente.

: Que se dispone de las Fichas de Datos de Seguridad de los productos químicos utilizados por el Departamento de Bobinados y Transformadores.

: Que la Política de Calidad sigue siendo válida para la organización.

: Que la Política de Calidad está en lugares visibles de la empresa.

: Que todas las Hojas de Ruta tienen una Hoja de Verificación, y que en dicha Hoja de Verificación se apunta la Hoja de ruta relacionada.

: Que las Facturas tienen el mismo importe que los Presupuestos Cerrados.

: Que todos los equipos para reparar tienen su Etiqueta de Producto del cliente.

:  Que todas las Instalaciones realizadas según Hojas de Ruta tienen su correspondiente Verificación del Montaje de Instalaciones. Si la empresa encargada de la instalación ha desarrollado un check listo propio de verificación, verificar que se ha registrado dicho Check list y que éste hace referencia al nº de Hoja de ruta.

:  Que todos los Partes de Intervención de Instalaciones reflejan la firma de aceptación del cliente.

: Que las Fichas de Mantenimiento de los equipos del Plan de Mantenimiento de Equipos de Fabricación reflejan todas las actividades de mantenimiento que se describen en el Plan y con la periodicidad establecida. Es decir, si el plan dice cambio de aceite mensual, la Ficha tiene que registrar un cambio de aceite por mes.

:  Que todos los Equipos de Inspección del Inventario de Equipos de Inspección tienen su correspondiente Ficha de Equipo de Inspección.

: Que se han realizado las calibraciones o verificaciones descritas en el Inventario de Equipos de Inspección, es decir, que no se ha superado la fecha “próxima” sin que exista al correspondiente Informe de Calibración por Laboratorio Externo o el formulario de Verificación Interna si se calibra internamente.

:  Que existe el correspondiente Plan de Auditorías Internas del año.

:  Que los Informes de No Conformidad han sido cumplimentados adecuadamente registrando el problema, el departamento, la causa, el tipo de no conformidad y la solución dada.

: Que los Informes de Acción Correctiva-Preventiva han sido cumplimentados adecuadamente registrando la medida tomada para evitar las no conformidades.

: Que se han realizado Acciones Correctivas para las No Conformidades repetitivas que son homogéneas o del mismo tipo.