AUDITORIA DE SISTEMAS APORTE TRABAJO COLABORATIVO N.

2 TUTOR FRANCISCO NICOLAS SOLARTE ALEJANDRA OLIVIA PABA GARCA CDIGO: 36677425 ESCUELA DE CIENCIAS BSICAS, TECNOLOGA E INGENIERA UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD CEAD VALLEDUPAR 2010 1. Cuales serian las caractersticas o puntos negativos que influiran en el rediseo de un sistema informatizado. Justifique las respuestas dadas. Una de las caractersticas ms importante es: determinacin de requerimientos Donde se estudia un sistema para conocer como trabaja y donde es necesario efectuar mejoras. Prever caractersticas del sistema Anticipacin en base a experiencias estudio, documentacin del sistema actualizando actividades en Investigacin, tcnicas de recoleccin para la determinacin Anlisis de flujo de dato de requerimientos Anlisis de decisin Anlisis de los datos que describen el sistema que es la especificacin de desempeo Requerimientos y estrategias nuevas. . Donde se sugiere proyectos por dos razones. a. Para experimentar en problemas que les lleven por si mismo a soluciones de sistemas. b. Para reconocer oportunidades y hacer mejoras mediante la actualizacin, alteracin o instalacin de nuevos sistemas. c. La falta o debilidad de los controles es un descubrimiento importante en cualquier investigacin de sistemas. PUNTOS NEGATIVOS PUEDEN SER: Frecuencia y volumen del proceso La frecuencia con la que se presentan las actividades en una empresa cambia mucho. El volumen de artculos manejados, puede aumentar el tiempo necesario para completar la actividad. Aunque la frecuencia de esta actividad es muy baja cuando el calendario inicia la actividad al finalizar cada trimestre, el volumen de trabajo es muy grande ya que,

en ocasiones, se necesitan prepara decenas de miles de estados de cuenta. La cantidad total de pasos de que consta una actividad, puede generar problemas especiales para el estudio que efecta el analista, aun cuando la actividad ocurra con poca frecuencia. -En las empresas, los departamentos dependen unos de otros para brindar servicios, fabricar productos y satisfacer a los clientes. Por consiguiente, el trabajo hecho en un departamento afecta al de los otros. Cuando los analistas estudian sistemas para un departamento tambin deben evaluar las implicaciones para los dems departamentos con los que interacta el sistema bajo investigacin. Algunas veces los sistemas fabrican el trabajo de varios departamentos. Es responsabilidad del analista identificar las dependencias entre departamentos y determinar como les afecta un proyecto de un sistema. Un proyecto de rediseo de un sistema comienza con problemas y oportunidades de mejora dentro de un negocio. Una vez que es sugerido un proyecto, el analista trabajara rpidamente con los tomadores de decisiones, para determinar si es factible, si es aprobado se har un estudio de sistemas completo. 2. A travs de una matriz de riesgos identifique y clasifique los riesgos encontrados en el trabajo colaborativo 1. Impacto/probabilidad de ocurrencia: Moderado. Casi certeza: Medio alto. Probable: Medio alto. Posible: Medio alto. Improbable: Bajo. Casi imposible: bajo. 3. Elabore un plan de auditora para la empresa a la cual se aplico la tcnica de la entrevista en el trabajo anterior. Justifique el por qu de este plan. 1. Considera que el Departamento de Sistemas de Informacin: d los resultados esperados? Si ( ) No ( ) Por que? 2. Cmo considera usted, en general, el servicio proporcionado por el Departamento de Sistemas de Informacin? Deficiente ( ) Aceptable ( ) Satisfactorio ( )

Excelente ( ) Por que? 3. Cubre sus necesidades el sistema que utiliza el departamento de cmputo? No las cubre ( ) Parcialmente ( ) La mayor parte ( ) Todas ( ) Por que? 4. Hay disponibilidad del departamento de cmputo para sus requerimientos? Generalmente no existe ( ) Hay ocasionalmente ( ) Regularmente ( ) Siempre ( ) Por que? 5. Son entregados con puntualidad los trabajos? Nunca ( ) Rara vez ( ) Ocasionalmente ( ) Generalmente ( ) Siempre ( ) Por que? 6. Que piensa de la presentacin de los trabajadores solicitados al departamento de cmputo? Deficiente ( ) Aceptable ( ) Satisfactorio ( ) Excelente ( ) Por que? 7. Que piensa de la asesora que se imparte sobre informtica? No se proporciona ( ) Es insuficiente ( ) Satisfactoria ( ) Excelente ( ) Por que? 8. Que piensa de la seguridad en el manejo de la informacin proporcionada por el sistema que utiliza? Nula ( ) Riesgosa ( ) Satisfactoria ( ) Excelente ( ) Lo desconoce ( ) Por que?

9. Existen fallas de exactitud en los procesos de informacin? Cules? 10. Cmo utiliza los reportes que se le proporcionan? 11. Cules no Utiliza? 12. De aquellos que no utiliza por que razn los recibe? 13. Que sugerencias presenta en cuanto a la eliminacin de reportes modificacin, fusin, divisin de reporte? 14. Se cuenta con un manual de usuario por Sistema? SI ( ) NO ( ) 15. Es claro y objetivo el manual del usuario? SI ( ) NO ( ) 16. Que opinin tiene el manual? NOTA: Pida el manual del usuario para evaluarlo. 17. Quin interviene de su departamento en el diseo de sistemas? 18. Que sistemas deseara que se incluyeran? 19. Observaciones: -Este plan de auditora para una empresa se hizo con la tcnica de la entrevista: Con el fin de cumplir la Misin, filosofa, fortaleza, debilidades, oportunidades y amenazas de la organizacin. El cual Durante la entrevista con el usuario con esta informacin se puede comenzar a realizar la entrevista para determinar si los servicios proporcionados y planeados por la direccin de Informtica cubren las necesidades de informacin de las dependencias. REFERENTES BIBLIOGRFICOS www.eumed.net/ce/2009a/cgs.htm www.biblioteca.usac.edu.gt/tesis/03/03_0448 www.udem.edu.co/.../LineadeEnfasisenRiesgoFinancieroabril282006.doc www.utpl.edu.ec/eva/descargas/material/184/E159031.pdf

Auditoria
1. Cuales serian las caractersticas o puntos negativos que influiran en el rediseo de un sistema informatizado. Justifique las respuestas dadas.

El xito del Proyecto vendr condicionado por la capacidad de conseguir y mantener los siguientes factores: 1. Formacin a usuarios finales previa al arranque. 2. Traspaso de conocimientos a usuarios claves de la empresa. 3. Mentalizacin de que la implantacin de una solucin estndar no se ajustar al 100% a la manera actual de trabajar de los usuarios. 4. Definir claramente los roles y responsabilidades de cada participante en el proyecto. 5. Realizacin por los usuarios de las tareas que son de su responsabilidad en los plazos pactados. 6. Tener definido en la primera fase del proyecto las jerarquas y estructuras requeridas. 7. Tener la necesaria involucracin de los usuarios claves de cada rea. 8. Apoyo al proyecto por parte de la direccin de la empresa desde del inicio del mismo. 9. Conocimiento de los objetivos del proyecto. 10. Poder de decisin adecuado al interlocutor de la empresa, con el fin evitar demoras en el desarrollo del proyecto. 11. Desde el inicio del proyecto los procesos de gestin de cambios e incidencias. 12. Ajustar las especificaciones al estndar, para asegurar su rendimiento. 13. Aprobacin de las funcionalidades por los responsables del proyecto por parte de la empresa. 14. Entrega y aceptacin de los entregables dentro de los plazos establecidos. 15. Tener un control adecuado del planinng del proyecto. 16. Disponibilidad de todos los equipos, adecuados para el buen funcionamiento del programa. Todos estos factores irn en funcin de Menor a Mayor importancia dentro de una responsabilidad baja a alta, componindose los factores de organizacin, de informacin, procedimiento y tcnicos.

auditoria de sistemas CURSO: AUDITORIA DE SISTEMAS INTRODUCCION. La Auditoria, es una disciplina expresada en normas, conceptos, tcnicas, procedimientos y metodologa, que tiene por objeto examinar y evaluar crticamente una determinada realidad, para emitir una opinin independiente Sobre un aspecto o la totalidad del objeto auditado. Qu es una Matriz de Riesgo? Una matriz de riesgo es una herramienta de control y de gestin normalmente utilizada para identificar las actividades (procesos y productos) ms importantes de una institucin financiera, el tipo y nivel de riesgos inherentes a estas actividades y los factores exgenos y endgenos que engendran estos riesgos (factores de riesgo). Igualmente, una matriz de riesgo permite evaluar la efectividad de una adecuada gestin y administracin de los riesgos financieros, operativos y estratgicos que impactan la misin de la organizacin. Una efectiva matriz de riesgo permite hacer comparaciones objetivas entre proyectos, reas, productos, procesos o actividades OBJETIVOS Identificar el propsito de la auditoria informtica Comprender la importancia de realizar una adecuada planificacin de una auditoria para garantizar los resultados en un proceso de auditora. Actividades Cuales serian las caractersticas o puntos negativos que influiran en el rediseo de un sistema informatizado. Justifique las respuestas dadas. A travs de una matriz de riesgos identifique y clasifique los riesgos encontrados en el trabajo colaborativo 1. Ver anexo 1. Elabore un plan de auditora para la empresa a la cual se aplico la tcnica de la entrevista en el trabajo anterior. Justifique el por qu de este plan. DESARROLLO DE LA ACTIVIDAD 1. Lo que puede pasar en el rediseo del sistema (en mi opinin) es que se puede dar el hecho de que no funcione igual que el sistema original o que no tenga la misma amigabilidad (facilidad de uso) que el sistema original.

La Reingeniera o rediseo no persigue modificar lo que existe, sino crear lo que no existe, sin embargo ignorar los procesos existentes puede crear altos riesgos. Muchas empresas fracasan al poner en prctica procesos totalmente nuevos en operaciones ya existentes. Difcilmente se podra redisear aquello que no se conoce, por lo que definitivamente esta etapa ayuda a recopilar informacin del proceso que va a sufrir cambios. Entender los procesos existentes es importante para realizar el rediseo. Sin embargo, no debe realizarse un anlisis demasiado detallado de los procesos existentes y ms bien enfocarse en el nuevo. El alcance de los cambios que a menudo necesita Reingeniera de procesos, significa que muchos de los retos existen, no tanto en la comprensin de los procesos y cmo pueden redisearse, sino ms bien cmo poner en prctica el cambio necesario para lograr una mejora potencial. No es necesario llegar al nivel de detalle requerido para un rediseo sistemtico. Sin embargo, es importante identificar los procesos centrales. Generalmente existirn aproximadamente de 6 a 8 procesos centrales y puede analizarse las etapas claves de cada uno de ellos, antes de dar por terminado el estudio. Este paso incluir un anlisis de los resultados que actualmente estn rindiendo estos procesos. REDISEO DE UN SISTEMA El propsito de redisear es que los sistemas existentes tomen ventajas de las nuevas tecnologas. El rediseo tiene el potencial de mejorar la productividad y calidad de cualquier sistema a travs de todo el ciclo de vida. El rediseo casi siempre implica cambiar la forma de un sistema y mejorar su documentacin. En este caso, la funcionabilidad del sistema no es cambiada; slo su forma es modificada. En otros casos, El rediseo va ms all de la forma e incluye cambiar la funcionabilidad del sistema para buscar mejores requerimientos de los usuarios. El rediseo puede ayudar a entender sistemas existentes y descubrir los componentes de software que son comunes en todo el sistema. Estos componentes comunes pueden ser re-usados en el desarrollo (o redesarrollo) de sistemas y as reducir el tiempo y riesgos del desarrollo de sistemas. El rediseo requiere tiempo; implica un coste de dinero enorme y absorbe recursos que de otro modo se podran emplear en preocupaciones ms inmediatas. Por todo esto, El rediseo no se lleva a cabo en unos pocos meses, ni siquiera en unos pocos aos. El rediseo de sistemas de informacin es una actividad que absorber recursos de las tecnologas de la informacin durante muchos aos. PORQUE EL REDISEO

Los viejos sistemas son muy similares a los grandes y viejos edificios. Ellos tienen los mismos problemas de mantenimiento, un hecho en gran parte irreconocible por parte de la comunidad corporativa. Muchos de esos edificios son demolidos por qu no son mantenibles y ya no sirven para las necesidades de sus ocupantes. Los clientes demandan que las nuevas capacidades sean agregadas al cdigo escrito en sus viejos sistemas. Casi siempre, las empresas encuentran que no pueden modificar su cdigo el programador que lo mantena muri recientemente o nadie sabe programar en el lenguaje en el que fue escrito. Por lo que la funcionalidad de ese programa quedar as para siempre. Algunas de las razones por las que es aplicable el rediseo de sistemas de informacin: Frecuentes fallas de produccin (fiabilidad cuestionable). Problemas de rendimiento. Tecnologa obsoleta. Problemas de integracin del sistema. Cdigo de calidad pobre. Dificultad (peligroso) al cambio. Dificultad para probar. Mantenimiento caro. Incremento de problemas del sistema. Estas razones pueden ser solucionadas al aplicar un proceso de mantenimiento de software, pero cuando dicho mantenimiento deja de ser viable, entonces se toma la decisin de aplicar el rediseo. RIESGOS DEL REDISEO: No proporcionar asistencia automatizada para el mantenimiento del sistema. No lograr reducir los errores y costos del mantenimiento del sistema rediseado. Disminuir la intercambiabilidad del grupo de mantenimiento del sistema rediseado. No lograr hacer sistemas fciles de entender, cambiar y probar. Deshabilitar la conversin y migracin de sistemas. Entorpecer las respuestas a peticiones de mantenimiento. Empeorar el estado de nimo del grupo de mantenimiento. Dejar vulnerable y colocar la vida del sistema en peligro. Compaeros este es el ejemplo de una matriz de riesgos, ms bajo encuentran el formato que va a quedar en el trabajo. Despus de terminar la de abajo se quita esta. [pic] |Impacto/ probabilidad de |Insignificante |Catastrfico | |Dbil |Moderado |Grave

|ocurrencia | |Improbable | | | | | | | |Casi imposible |

| | | | | |

| | | | | |

| | | | | |

| | | | | |

| | | | | |

Matriz Riesgos que se encontraron, causas y recomendaciones Existen tcnicas y herramientas de monitoreo que permitan supervisar el trabajo de los usuarios de la B.D? NO |Condicin y criterio | |Administracion del proceso de los datos | | | |Riesgo | |Toda informacin de la institucin es susceptible de ser monitoreada y modificado o hurtado su contenido por personas ajenas a la | |institucin, generando problemas de seguridad, que en la mayora de los casos es grave para la informacin afectada. | | | |Causa | |LA informacin transmitida y que va a ser operado no es transmitida correctamente por el administrador encargado en ese momento. | | | |Recomendaciones | |Transmitir solo la informacin necesaria para minimizar el impacto de una posible intromisin o robo de la misma. | | | |Compromiso del auditado | |Instalar mdulos de encriptacin que permitan garantizar la integridad de la informacin. Llevar a cabo un seguimiento de planes de |

|seguridad para verificar su cumplimiento, documentacin y elaborando los cambios pertinentes. | Existen controles para realizar modificaciones d la BD? NO |Condicin y criterio | |Controles de acceso a la BD | | | |Riesgo | |Debido al ingreso no autorizado de la BD, no se garantiza la seguridad e integridad de la informacin. | | | |Causa | |No est configurada adecuadamente la seguridad de la Base de Datos y no se ha establecido reglas claras de restriccin a los | |usuarios. | | | |Recomendaciones | |Restringir el acceso a la informacin, verificando el derecho de cada grupo y usuarios. | | | |Compromiso del auditado | |La restriccin a los usuarios es de vital importancia ya que permite diferentes tipos de informacin y por ende los diferentes | |niveles de confidencialidad. | Se encuentra especificado dentro del manual de funciones los pasos previos y autorizaciones para realizar cambios o modificaciones en la B.D? NO |Condicin y criterio | |Seguridad del diccionario de datos | | |

|Riesgo | |Debido al ingreso no autorizado de la BD, se pueden cambiar las normas establecidas en el diccionario de datos. | | | |Causa | |Acceso no autorizado o realizacin de modificaciones sin la autorizacin del administrador o la personas que en ese momento se | |encuentre a cargo de la administracin de sistema.. | | | |Recomendaciones | |Creacion de claves de acceso y determinar quin es el principal responsable de la administracin de la BD. | | | |Compromiso del auditado | |Evaluar quien es el responsable de la administracin de la BD para que este realice las modificaciones, pruebas y dems actividades | |en el ingreso de los datos en la BD. | Existe un manual de procedimientos acerca de la seguridad de la B.D? NO |Condicin y criterio | |Manual de procedimientos para la seguridad de la BD. | | | |Riesgo | |Se presenta desorganizacin en la asignacin y delegacin de tareas, no es posible llevar un control de las actividades y el acceso | |de los usuarios | | | |Causa | |No se posee documentacin que haga suponer la existencia de un programa de seguridad establecido y mucho menos de su cumplimiento. |

| | |Recomendaciones | |Elaborar un plan de seguridad, acorde a las necesidades de la organizacin, con procedimientos actualizados, que permitan llevar a | |cabo un control ponderizado de las actividades de los usuarios y administradores del sistema de informacin. | | | |Compromiso del auditado | |Llevar a cabo un seguimiento de planes de seguridad para verificar su cumplimiento, documentacin y elaborando los cambio | |pertinentes. | El ABD tiene control sobre la operatividad completa de la B.D? NO |Condicin y criterio | |Personal con acceso a la BD | | | |Riesgo | |Los usuarios no autorizados pueden entrar con libertad a la informacin almacenada. | | | |Causa | |Los listados de acceso para la administracin de seguridad no se encuentran adecuadamente documentados y no se prueba si su contenido| |es veraz. | | | |Recomendaciones | |Habilitar seguridades de la Base de Datos. | | | |Compromiso del auditado |

|Verificar el correcto funcionamiento de las seguridades y restricciones de los usuarios. | Existe validacin de permisos de usuarios? NO |Condicin y criterio | |Integridad y validacin de la BD | | | |Riesgo | |Al Cambio no autorizado de las normas establecidas en el diccionario de datos la informacin de la BD puede ser alterada. | | | |Causa | |Realizacin de modificaciones sin la autorizacin del administrador | | | |Recomendaciones | |Manejo responsable de las normas y polticas del diccionario de datos. | | | |Compromiso del auditado | |Evaluar quien es el responsable de la administracin de la BD para que este realice las modificaciones, pruebas y dems actividades | |en el ingreso de los datos en la BD. | El ABD es el encargado de otorgar las autorizaciones a los diferentes perfiles de usuario? NO |Condicin y criterio | |Niveles de Perfil de usuario | | | |Riesgo |

|No se ha establecido el responsable directo del manejo de la administracin de la Base de Datos y no se garantiza la seguridad e | |integridad de la informacin. | | | |Causa | |NO existe una organizacin adecuada en las diferentes reas y principalmente en el rea de sistemas. | | | |Recomendaciones | |Restringir el acceso a la informacin, verificando el derecho de cada grupo y usuarios. | | | |Compromiso del auditado | |La restriccin a los usuarios es de vital importancia ya que permite diferentes tipos de informacin y por ende los diferentes | |niveles de confidencialidad. | 3. EJEMPLO DE AUDITORA DE SISTEMAS AUDITORIA DE HARDWARE Y SOFTWARE EN ESTACIONES DE TRABAJO HOSPITAL CLNICA SAN RAFAEL. Alcance La auditoria se realizar sobre los sistemas informaticos en computadoras personales que estn conectados a la red interna de la empresa. Objetivo Tener un panorama actualizado de los sistemas de informacin en cuanto a la seguridad fisica, las politicas de utilizacion, transferencia de datos y seguridad de los activos. Recursos El numero de personas que integraran el equipo de auditoria sera de tres, con un tiempo maximo de ejecucion de 3 a 4 semanas. Etapas de trabajo: 1. Recopilacion de informacion bsica

Una semana antes del comienzo de la auditoria se envia un cuestionario a los gerentes o responsables de las distintas areas de la empresa. El objetivo de este cuestionario es saber los equipos que usan y los procesos que realizan en ellos. Los gerentes se encargaran de distribuir este cuestionario a los distintos empleados con acceso a los computadores, para que tambien lo completen. De esta manera, se obtendra una vision mas global del sistema. Es importante tambien reconocer y entrevistarse con los responsables del area de sistemas de la empresa para conocer con mayor profundidad el hardware y el software utilizado. En las entrevistas incluiran: Director / Gerente de Informatica Subgerentes de informatica Asistentes de informatica Tecnicos de soporte externo 2. Identificacin de riesgos potenciales Se evaluara la forma de adquisicion de nuevos equipos o aplicativos de software. Los procedimientos para adquirirlos deben estar regulados y aprobados en base a los estandares de la empresa y los requerimientos minimos para ejecutar los programas base. Dentro de los riesgos posibles, tambien se contemplaran huecos de seguridad del propio software y la correcta configuracion y/o actualizacion de los equipos criticos como el cortafuegos. Los riesgos potenciales se pueden presentar de la mas diversa variedad de formas. Objetivos de control Se evaluaran la existencia y la aplicacin correcta de las politicas de seguridad, emergencia y disaster recovery de la empresa. Se hara una revicion de los manuales de politica de la empresa, que los procedimientos de los mismos se encuentren actualizados y que sean claros y que el personal los comprenda. Debe existir en la Empresa un programa de seguridad, para la evaluacin de los riesgos que puedan existir, respecto a la seguridad del mantenimiento de los equipos, programas y datos. 3. Determinacion de los procedimientos de control Se determinaran los procedimientos adecuados para aplicar a cada uno de los objetivos definidos en el paso anterior. Objetivo N 1: Existencia de normativa de hardware.

 El hardware debe estar correctamente identificado y documentado. Se debe contar con todas las rdenes de compra y facturas con el fin de contar con el respaldo de las garantas ofrecidas por los fabricantes. El acceso a los componentes del hardware est restringido a la directo a las personas que lo utilizan. Se debe contar con un plan de mantenimiento y registro de fechas, problemas, soluciones y prximo mantenimiento propuesto. Objetivo N 2: Poltica de acceso a equipos. Cada usuario deber contar con su nombre de usuario y contrasea para acceder a los equipos. Las claves debern ser seguras (mnimo 8 caracteres, alfanumricos y alternando maysculas y minsculas). Los usuarios se desloguearan despus de 5 minutos sin actividad. Los nuevos usuarios debern ser autorizados mediante contratos de confidencialidad y deben mantenerse luego de finalizada la relacin laboral. Uso restringido de medios removibles (USB, CD-ROM, discos externos etc). 4. Pruebas a realizar. Son los procedimientos que se llevaran a cabo a fin de verificar el cumplimiento de los objetivos establecidos. Entre ellas podemos mencionar las siguientes tcnicas: Tomar 10 maquinas al azar y evaluar la dificultad de acceso a las mismas. Intentar sacar datos con un dispositivo externo. Facilidad para desarmar una pc. Facilidad de accesos a informacin de confidencialidad (usuarios y claves). Verificacin de contratos. Comprobar que luego de 5 minutos de inactividad los usuarios se deslogueen. 5. Obtencion de los resultados.

En esta etapa se obtendrn los resultados que surjan de la aplicacin de los procedimientos de control y las pruebas realizadas a fin de poder determinar si se cumple o no con los objetivos de control antes definidos. Los datos obtenidos se registrarn en planillas realizadas a medida para cada procedimiento a fin de tener catalogado perfectamente los resultados con el objetivo de facilitar la interpretacion de los mismos y evitar interpretaciones erroneas. 7. Conclusiones y Comentarios: En este paso se detallara el resumen de toda la informacin obtenida, asi como lo que se deriva de esa informacin, sean fallas de seguridad, organizacin o estructura empresarial. Se expondrn las fallas encontradas, en la seguridad fsica sean en temas de resguardo de informacin (Casos de incendio, robo), manejo y obtencin de copias de seguridad, en las normativas de seguridad como por ejemplo normativas de uso de passwords, formularios de adquisicin de equipos, y estudios previos a las adquisiciones para comprobar el beneficio que los mismos aportaran. Finalmente se vern los temas de organizacin empresarial, como son partes responsables de seguridad, mantenimiento y supervisin de las otras reas. 8. Redaccion del borrador del informe Se detalla de manera concisa y clara un informe de todos los problemas encontrados, anotando los datos tcnicos de cada una de las maquinas auditadas: Marca Modelo Numero de Serie Problema encontrado Solucin recomendada 9 . Presentacin del borrador del informe, al responsable de microinformtica Se le presentara el informe borrador a un responsable del rea informtica, como se aclaro en el punto anterior, con el mximo de detalle posible de todos los problemas y soluciones posibles recomendadas, este informe se pasara por escrito en original y copia firmando un documento de conformidad del mismo para adquirir un compromiso fuerte en la solucin de los mismos, de esta forma evitaremos posibles confusiones futuras. 10. Redaccin del Informe Resumen y Conclusiones. Es en este paso es donde se muestran los verdarderos resultados a los responsables de la empresa, el informe presentado dar a conocer todos los

puntos evaluados durante la auditoria, resultados, conclusiones, puntaje y posibles soluciones. La conclusin tendr como temas los resultados, errores, puntos crticos y observaciones de los auditores. Mientras que en el resumen se vern las posibles soluciones de esos puntos crticos y fallas, as como recomendaciones para el buen uso y tambin recomendaciones sobre la forma incorrecta de realizar algunos procedimientos. 11. Entrega del informe a los directivos de la empresa. Esta es la ultima parte de la auditoria y en una reunion se formaliza la entrega del informe final con los resultados obtenidos en la auditoria. Tambien se fijan los parametros si asi se requieren para realizar el seguimientos de los puntos en los que el resultado no haya sido satifactorio o simplemente se quiera verificar que los que los objetivos de control se sigan cumpliendo a lo largo del tiempo. CONCLUSIONES La matriz de riesgo, constituye un elemento de gestin muy importante para el responsable de ese proceso permitindole una visin clara y fcilmente actualizable de sus riesgos. Forma parte de la documentacin de procesos, brindando a los usuarios un mayor conocimiento de los mismos, de sus actividades, riesgos y controles. Es importante crear un programa especial para revisar peridicamente en la base de datos dictar una poltica de seguridad que permita un control adecuado de la seguridad, que facilite e integre la gestin de la informacin. Configurar las seguridades del sistema operativo de tal forma que cada usuario sea responsable de la informacin propia de su labor y que restrinja la intromisin en la informacin que le es ajena a sus funciones dentro de la base de datos. FORMATO PARA LA AUTOEVALUACIN DEL GRUPO COLABORATIVO[1] |SI |1 | |2 x |3 |x |4 | |5 | |NO | |Trabajamos siguiendo un plan | |Trabajamos todos juntos | |Intentamos resolver la actividad de diferentes maneras | | |Resolvimos la actividad |Repasamos nuestro trabajo para asegurarnos que todos | | |x | |

| |Estamos de acuerdo | | | |6 |Le asignamos responsabilidades a cada miembro | | | | |Responsabilidad |Responsable | | | | |Andrea Gmez | | | | | | | | | | | | | | | | | |7 |Usamos los siguiente materiales o bibliografa | | |[1] Mdulo del curso de Auditoria de Sistemas | | |[2] http://www.buniak.com/negocio.php? id_seccion=8&id_documento=248 | | |[3] http://www.gestiopolis.com/canales8/ger/metodologia-para-evaluaciondiagnostico-y-diseno-de-procesos.htm | | | | | | | | | | |8 |Aprendimos: Se aprendieron temas muy importantes que nos ayudaron a comprender y entender cules son los pasos de cmo | | |se lleva a cabo una auditoria, y realizar una matriz de riesgos, en la cual logra identificar o evaluar los riesgos | | |valga la redundancia, que existen en una empresa u organizacin llevando a su posible causa y posible recomendacin. | | | | |9 |Resolvimos la actividad con la siguiente estrategia: | | | | | |Investigando en la empresa donde laboro, algunas herramientas que influyeron en la realizacin de auditoras, tambin | | |algunos conocimientos adquiridos en el Trabajo anterior, algunas fuentes de Internet nos ayudaron a complementar la | | |actividad. | |10 |Lo aprendido lo podemos aplicar en los siguientes contexto | | | | | |Esta actividad, ser un buen apoyo para poder llevarla a la prctica, cuando se requiera en la parte laboral y | | |profesional, tambin se podra decir que se adquiere una experiencia importante porque nos ensea que realizar una | | |auditora es algo muy grande y complejo y que como tal, debemos cumplir con todas las reglas, para poder tener |

| |resultados eficaces y eficientes. | |11 |Relaciono los participantes que apoyaron el trabajo | | | | |Andrea Gmez | [pic] ----------------------[1] Tcnicas y estrategias del pensamiento critico pag.166-168