0% encontró este documento útil (0 votos)
30 vistas82 páginas

Auditoría en Desarrollo de Sistemas TI

Este documento describe la importancia de la participación del auditor en el desarrollo de sistemas. Explica que la participación del auditor debe darse durante el desarrollo del sistema para que los controles necesarios se incorporen en las diferentes etapas. También describe las metodologías de desarrollo de sistemas y el papel del auditor en cada etapa como identificar, sugerir e implementar controles necesarios.

Cargado por

Wuilian Torres
Derechos de autor
© All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
30 vistas82 páginas

Auditoría en Desarrollo de Sistemas TI

Este documento describe la importancia de la participación del auditor en el desarrollo de sistemas. Explica que la participación del auditor debe darse durante el desarrollo del sistema para que los controles necesarios se incorporen en las diferentes etapas. También describe las metodologías de desarrollo de sistemas y el papel del auditor en cada etapa como identificar, sugerir e implementar controles necesarios.

Cargado por

Wuilian Torres
Derechos de autor
© All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd

Auditoria 5

Unidad III
PARTICIPACIÓN DEL AUDITOR EN EL
DESARROLLO DE SISTEMAS
(APLICACIONES)
CONTENIDO
• Introducción
• Ventajas
• Su importancia
• Su oportunidad
• Metodología
• Papel del CPA en cada etapa
• Grado de Intervención
Introducción
• Los negocios operan utilizando un conjunto de aplicaciones.
• Las organizaciones buscan la adquisición de un sistema para
automatizar sus procesos, que esté hecho justamente como
ellos lo desean y que se acople a su estructura de trabajo.
• Para algunas empresas es necesario elaborar una solución
informática para la automatización de ciertas tareas
complicadas.
Introducción
• Uno de los retos más importantes es definir cómo desarrollar
un software de negocios.
• Se busca muchas veces que la solución ofrezca una gran
potencia o sea exclusivamente para resolver un problema
específico.
• Se fija el objetivo que al desarrollar el software sea confiable,
que ofrezca reducción de costos y el cumplimiento de rigurosos
plazos de entrega.
• Dadas las necesidades concretas o particulares de los procesos
suelen hacerse «a medida».
Adquisición de Software
(comprar o desarrollar un software?)
• Evaluar las diferentes alternativas que ofrecen los proveedores
con relación a las necesidades planteadas, determinando así,
si se compra o si de desarrolla.
• Evaluar la forma en que el nuevo sistema interactuará con los
distintos usuarios.
• Evaluar el diseño del nuevo software, que cumpla con las
necesidades planteadas por el comité directivo.
Adquisición de Software
(comprar o desarrollar un software?)
• Verificar que si el software anterior tenía un diseño o estilo de
informe determinado y unos formularios previamente diseñados
con cierto objetivo, estos deben ser respetados.
• Evaluar en caso que sea compra de software, que se hayan
realizado pruebas de aceptación del sistema, el cual debe ser
coherente con el catálogo de requisitos y con la especificaciones
funcionales del sistemas.
Ventajas de un desarrollo a la
medida:
• Se desarrolla tomando en cuenta sus necesidades
• Lleva los módulos que usted requiera
• La interfaz de usuario se desarrolla como usted la desee
• Se desarrolla en las tecnologías que usted desee (si esto es
relevante para usted)
• Se desarrollan los reportes que usted necesite
Porqué es importante la participación?

• Estadísticas:
McKinsey & Company, junto con la Universidad de Oxford, realizó
un estudio publicado en Octubre de 2012, enfocado a Grandes
Proyectos de TI cuyo presupuesto inicial excedía los 15 millones
de dólares.
De acuerdo a esta investigación, de los más de 5,400 proyectos
de TI consultados:
45% han excedido su presupuesto
07% han excedido su cronograma y
56% entregan menos valor que el predicho.
Porqué es importante la participación?

• International Data Corporation (IDC), tiene un estudio de Junio


del 2009 titulado “Improving IT Project Outcomes by
Systematically Managing and Hedging Risk”, por Dana Wiklund y
Joseph C. Pucciarelli, donde se indica que:
• El 25% de los proyectos de TI fracasan sin más ni más
• Del 20 al 25% de ellos no proporcionan retorno de la inversión
(ROI)
• Hasta un 50% de los proyectos requiere reelaboración.
Porqué es importante la participación?

• Gartner, en un artículo de Enero de 2011 titulado “How to


Increase Your IT Project Success Rate” por Susan Tan,
proporciona, basado en el análisis de los resultados de 845
proyectos de TI completados con la ayuda de un proveedor de
servicios externo (PSE). Tres estadísticas de la investigación
indican que de los proyectos realizados con la ayuda del PSE:
• El 42,5% no entregaron todos los beneficios esperados
• El 44% se entregaron por encima del presupuesto
• El 42% no fueron entregados a tiempo.
Porqué es importante la participación?

Una encuesta realizada por Gartner en Octubre de 2011 a 154


organizaciones de 5 países y de varios tipos de industrias con
ganancias anuales sobre los 500 millones de dólares. observándose
que el porcentaje de fracaso de los proyectos de TI era de:
• 28% en los Proyectos de TI Grandes (cuyo presupuesto excede
el millón de dolares),
• 25% en los Proyectos de TI Medianos (cuyo presupuesto está
entre 350 mil y un millón de dólares) y del
• 20% en los Proyectos de TI Pequeños (cuyo presupuesto era
menor de 350 mil dólares).
Porqué es importante la participación?

• El último estudio del 2012 indica que el 39% de todos los proyectos
son exitosos, 43% fueron deficientes y el 18% fracasaron.

• Considerando solo los proyectos ágiles, el 46% de todos los


proyectos son exitosos, 48% fueron deficientes y el 6% fracasaron.
Su Importancia
La participación del Auditor en el desarrollo de
sistemas es muy importante y puede darse:
1. Identificando controles
2. Sugiriendo controles
3. Implementando controles
4. Evaluando los controles que sean necesarios,

Desde diferentes campos de actuación:


• Consultor en Sistemas
• Auditor Externo
• Auditor Interno
Su oportunidad

La participación del auditor interno en el


desarrollo de sistemas debe darse
precisamente en el desarrollo del
mismo, a efecto de que los controles
que se consideran necesarios, sean
incorporados en las diferentes fases o
etapas del desarrollo, ya que una vez
funcionando el sistema, es mas difícil y
costoso efectuar las modificaciones.
Para que la auditoria interna esté en
condiciones de hacer un trabajo efectivo,
son necesarios los aspectos mínimos
siguientes:

1 Respaldo total de la administración


2 Comunicación fluida y permanente con el
departamento de T.I.
3 Personal de auditoria interna con
suficientes conocimientos (por lo menos
teóricos al principio) en materia de T.I.
Metodología Clásica de los Programadores
para el Desarrollo de Aplicaciones

La metodología utilizada para el


desarrollo de sistemas consiste en
dividir el esfuerzo en 3 fases o
etapas, claramente definidas,
pueden clasificarse así:
1. Planificación del sistema
a) Investigación preliminar
b) Estudio de factibilidad
c) Planificación inicial
Metodología Clásica de los Programadores
para el Desarrollo de Aplicaciones

2. Desarrollo de sistemas
(Programación)
a) Desarrollo de modelos
solución
b) Diseño del modelo elegido
c) Programación
d) Prueba
Metodología Clásica de los Programadores
para el Desarrollo de Aplicaciones

3. Implantación del sistema


a) Preparación de la implantación
b) Implantación operativa
c) Revisión post-implantación y
seguimiento
Planificación del sistema
Es el auditor, quien tiene la función de comprobar la existencia de
los procedimientos de control y de verificar su correcta aplicación
en cada etapa del ciclo de vida del desarrollo del nuevo proyecto
de ingeniería de software.
Planificación del sistema

1. Análisis de requisitos del sistema


• En esta etapa el auditor debe implementar varios controles
para verificar:
• La participación activa de los usuarios
• Existe un plan de entrevista detallado con fecha, hora y lugar,
tipo de entrevista, se entrevista a todas las partes afectadas y
se cumpla con el plan.
Planificación del sistema
• El auditor debe verificar que el catálogo de requerimientos ha
sido revisado y aprobado por las partes afectadas e
interesadas
• En esta fase, el auditor debe comprobar que para solucionar
los problemas existen más de una alternativa de solución,
entre estas alternativas puede ser comprar la solución o un
desarrollo interno o externo y se debe verificar los criterio de
selección de la solución del proyecto.
Planificación del sistema
• Además el auditor debe revisar que el nuevo sistema incluirá los
requisitos de seguridad y de auditoria, planes de pruebas y los
procedimientos para el cambio o reajuste al proyecto o
especificaciones del él.
• Existe un documento aprobado por el comité de dirección en el que
se determina formalmente el grupo de usuario que participa en el
proyecto.
• Los usuarios elegidos son suficientemente representativos de las
distintas funciones que se lleva a cabo en las unidades afectadas
por el nuevo sistema.
Planificación del sistema

• Se les han comunicado a los usuarios su participación en el


proyecto.
• Se desarrolló un plan detallado de entrevistas con el grupo de
usuarios del proyecto y con los responsables de las unidades
afectadas por el nuevo cambio del sistema.
• Evaluar que las preguntas en la entrevista permitan obtener
información sobres las funciones que se realiza y cuáles son los
problemas que necesita resolver.
Planificación del sistema
• Evaluar que se hayan definido alternativas de construcción para el
desarrollo de nuevo proyecto
• Verificar que exista un modelo lógico de los procesos.
• Evaluar que se haya buscado en el mercado alternativas para la
adquisición del software
• Evaluar que estos requerimientos vayan acorde con las respuestas
obtenidas en la entrevista
• Evaluar que se estén cumpliendo los requerimientos de
seguridad, rendimiento, copia de seguridad
AUDITORIA DE LA FASE DE DISEÑO

• Definir el entorno tecnológico.


• El auditor debe evaluar que se haya definido desde el principio
del proyecto el entorno tecnológico requerido.
• Evaluar que los equipos de cómputos, sistema operativo
seleccionado, equipo de trabajo, conexiones de red, protocolos de
transferencias, sean los adecuados y estén en condiciones
óptimas para el desarrollo del proyecto de ingeniería de software.
AUDITORIA DE LA FASE DE DISEÑO

• Verificar que todos los elementos necesarios tantos


tecnológicos como humanos se encuentren acorde a los
estándares del departamento de informática,
• Evaluar que los componente o programas de uno proyecto de
ingeniería de software se hayan definido de acuerdo al sistema
donde funcionaria.
• Constatar que se haya realizado un plan de prueba con el diseño
tecnológico sugerido por los usuarios.
Implantación del sistema

• Guía de control. Se revisarán las disposiciones de la metodología


del proceso de desarrollo de aplicaciones informáticas
• 1. Revisar, los contratos de adquisición de los paquetes de
proyecto de desarrollo, poder determinar si:
• a. La documentación proporcionados en los programas son los
adecuados.
• b. Los paquetes fueron pagados.
Implantación del sistema

• Verificar, para los proyectos de desarrollo de aplicaciones


informáticas seleccionados, que para cada paso del trabajo los
operadores individuales especifican:
• a. La función del programa.
• b. Los requisitos hardware.
• c. Los requisitos software
PAPEL DEL AUDITOR INTERNO/CONSULTOR EN LAS
DISTINTAS ETAPAS DEL DESARROLLO DE SISTEMAS

PLANIFICACIÓN DEL SISTEMA


• Solicitud del Usuario:
Conocer y verificar la necesidad y sus objetivos.

• Estudio de Factibilidad:
Conocer el dictamen que justifica el proyecto. Planear la
participación de la auditoria.

• Análisis del Sistema:


Determinar los controles de que debe constar el nuevo sistema.

DESARROLLO O DISEÑO DEL SISTEMA


• Diseño del Sistema:
Precisar que el proyecto sea acorde con las necesidades del
usuario y que cuente con los controles suficientes.
PAPEL DEL AUDITOR INTERNO EN LAS DISTINTAS ETAPAS
DEL DESARROLLO DE SISTEMAS

• Programación:
Definir que el programa contemple todos los controles analizados
anteriormente.
• Pruebas:
Probar el sistema con sus propios datos.
IMPLANTACIÓN DEL SISTEMA:
• Implantación:
Realizar de ser necesario las pruebas en paralelo para garantizar la
efectividad del sistema.
• Documentación del Sistema:
Constatar que la documentación se encuentre completa y
debidamente formalizada, revisando las medidas de seguridad
adoptadas.
• Revisión Pos implantación y seguimiento:
Constatar que la implantación del nuevo software funcione
correctamente y cumple con todos los controles establecidos y
satisfaga las necesidades de los usuarios.
GRADO DE INTERVENCIÓN DE LOS INVOLUCRADOS EN LA CONSTRUCCIÓN DE
UNA APLICACIÓN

ADMON. T.I. USUARIOS A.I.


PLANIFICACIÓN DEL SISTEMA
- INVESTIGACIÓN PRELIMINAR S P P S
- ESTUDIO DE FACTIBILIDAD S P P M
- PLANIFICACIÓN INICIAL P P M M

DESARROLLO DEL SISTEMA


- DESARROLLO DE MODELOS SOLUCIÓN M P M M
- DISEÑO DEL MODELO ELEGIDO P P P P
- PROGRAMACIÓN Y PRUEBA S P S S

IMPLANTACIÓN DEL SISTEMA


- PREPARACIÓN DE LA IMPLANTACIÓN M P P P
- IMPLANTACIÓN OPERATIVA P P P P
- REVISIÓN POST - IMPLANTACIÓN Y
SEGUIMIENTO M M P P

S = Superficial M = Media P = Profunda


Referencias Bibliográficas
• Materiales del Curso Auditoria V (Auditoria en Procesamiento
Electronico de Datos –USAC – Facultad CCEE, Escuela de
Auditoria.
• Imágenes de Google
• [Link]
GRACIAS!!!
CPA – M.A Sergio Arturo Sosa Rivas – Coordinador
sergiososa@[Link]
CPA - Nelton Estuardo Mérida
es.tu2010@[Link]
CPA-Oscar Noé López Cordón, MsC
oscarnoe@[Link]
CPA-Víctor Manuel Sipac
victorsipac@[Link]

Auditoria 5 USAC 2020


Auditoria 5

Unidad IV
Planeación: Proceso que nos dirá que se
hará y de que manera.

Son cursos de acción


detallados que señalan los pasos
Programa:
específicos que habrán de
realizarse para lograr los
objetivos.
Estimación programada de los
Presupuesto:
ingresos y egresos.
1) PLANEACIÓN DE LA AUDITORIA DE
SISTEMAS COMPUTACIONALES
 Identificar el origen de la auditoria.
 Realizar una visita preliminar al área que será
evaluada.
 Establecer los objetivos de la auditoria
 Determinar los puntos que serán evaluados en la
auditoría.
 Identificar los métodos, herramientas,
instrumentos y procedimientos.
 Asignar los recursos y sistemas computacionales
para la auditoria.
2)EJECUCIÓN DE LA AUDITORIA DE
SISTEMAS COMPUTACIONALES
 Realizar las acciones programadas.
 Aplicar los instrumentos y herramientas
programadas.
 Identificar y elaborar los documentos de
desviaciones encontradas.
 Elaborar el dictamen preliminar.
 Integrar el legajo de los papeles de trabajo.
3) DICTAMEN DE LA AUDITORIA DE SISTEMAS
COMPUTACIONALES

Analizar la información y elaborar un


informe de situaciones encontradas
Elaborar el dictamen final
Presentar el informe de auditoría
1 IDENTIFICAR EL ORIGEN DE LA AUDITORIA
 Por solicitud expresa de procedencia interna
 Por solicitud expresa de procedencia externa
 Por riesgos y contingencias informáticas
 Por resultados obtenidos de otras auditorias
2 REALIZAR UN VISITA PRELIMINAR AL AREA A
EVALUAR
 Contacto inicial con funcionarios y empleados
 Identificación de la problemática de área
 Prever los objetivos iniciales
 Calcular los recursos y personas necesarias
3 ESTABLECER LOS OBJETIVOS DE AUDITORIA
 Objetivos Generales
 Objetivos Particulares
 Objetivos Específicos (Auditoría Sistemas)
4 DETERMINAR LOS PUNTOS QUE SERAN
EVALUADOS
 Funciones y Actividades Del Personal
 Áreas Administrativas del Centro de Computo
 Los Sistemas, Equipos, Instalaciones y
Componentes
 La seguridad que tienen los Sistemas de
Información
5 ELABORAR PLANES, PROGRAMAS Y
PRESUPUESTO
 Documento formal con el contenido de los planes
 Documento formal de los programas de auditoria
 Elaborar el presupuesto para la auditoria
6 SELECCIONAR METODOS, HERRAMIENTAS Y
PROCEDIMIENTOS NECESARIOS
 Cuestionarios
 Flujo gramas
 Muestreo, etc.
7 ASIGNAR RECURSOS
 Humanos, Materiales y Económicos
EJECUCIÓN DE LA AUDITORIA DE
SISTEMAS COMPUTACIONALES
REALIZAR LAS ACCIONES PROGRAMADAS PARA LA AUDITORIA

APLICAR LOS ASIGNAR LOS RECURSOS Y RECOPILAR LA


INSTRUMENTOS Y ACTIVIDADES CONFORME DOCUMENTACION Y
HERRAMIENTAS PARA LA A LOS PLANES Y EVIDENCIAS DE LA
AUDITORIA PROGRAMAS AUDITORIA

IDENTIFICAR Y ELABORAR LOS DOCUMENTOS DE DESVIACIONES

ELABORAR LOS INTEGRAR EL LEGAJO DE


DOCUMENTOS Y PAPELES DE TRABAJO DE INTEGRAR LOS
PRESENTARLOS A LA AUDITORIA DOCUMENTOS Y
DISCUSIÓN PRUEBAS EN
PAPELES DE
TRABAJO

ELABORAR EL BORRADOR DE DESVIACIONES


DICTAMEN DE LA AUDITORIA DE SISTEMAS
COMPUTACIONALES

La información y elaborar un informe de situaciones


detectadas

 Analizar los papeles de trabajo


 Señalar las Situaciones encontradas
 Comentar las situaciones encontradas con el
personal de las áreas afectadas
 Realizar las modificaciones necesarias
 Elaborar un documento de situaciones
relevantes
METODOLOGIA PARA REALIZAR AUDITORIAS DE SISTEMAS COMPUTACIONALES
ORIGEN DE LA AUDITORIA VISITA PRELIMINAR

ESTABLECER OBJETIVOS

DETERMINAR PUNTOS A
EVALUAR

AUDITORIA V
ELABORAR PLANES, PRESUPUESTOS Y PROGRAMAS

IDENTIFICAR Y SELECCIONAR HERRAMIENTAS, METODOS


TECNICAS Y PROCEDIMIENTOS

ASIGNAR LOS RECURSOS DE AUDITORIA Y SISTEMAS

APLICAR AUDITORIA

IDENTIFICAR DESVIACIONES Y ELABORAR BORRADOR DEL INFORME

PRESENTAR DESVIACIONES A DISCUSION

ELABORAR BORRADOR FINAL DE DESVIACIONES

PRESENTAR EL INFORME DE AUDITORIA


GRACIAS!!!
CPA – M.A Sergio Arturo Sosa Rivas – Coordinador
sergiososa@[Link]
CPA - Nelton Estuardo Mérida
es.tu2010@[Link]
CPA-Oscar Noé López Cordón, MsC
oscarnoe@[Link]
CPA-Víctor Manuel Sipac
victorsipac@[Link]

Auditoria 5 USAC 2020


Auditoria 5

Unidad V

ESTUDIO Y EVALUACIÓN DEL


CONTROL INTERNO EN
INFORMATICA
Eventos, Riesgos y
Oportunidades
• “Un evento es un incidente o acontecimiento procedente de
fuentes internas o externas que afecta la consecución de
objetivos y que puede tener un impacto negativo o positivo o
de ambos tipos a la vez.
• Se dice o se define el riesgo: como la posibilidad de que un
evento ocurra y que provocará que se afecte negativamente el
logro de los objetivos que se han establecido.”
QUÉ ES RIESGO?
• Es la probabilidad de que un impacto adverso afecte los
resultados o el capital de nuestra empresa.
• El Riesgo se mide en términos de impacto y probabilidad.
- Probabilidad de ocurrencia.
- Impacto de las consecuencias potenciales.

PROBABILIDAD:
IMPACTO: La posibilidad de la ocurrencia
Consecuencia (s) de un de un evento que usualmente es
evento, expresado ya sea aproximada mediante una
en términos cualitativos o distribución estadística. En
cuantitativos. También es ausencia de información
suficiente, se puede aproximar
llamado Severidad. mediante métodos cualitativos.
Control Interno - Definición-
• El Control Interno conforme COSO “es un proceso
integrado a los procesos, y no un conjunto de pesados
mecanismos burocráticos añadidos a los mismos,
efectuado por el consejo de la administración, la
dirección y el resto del personal de una entidad,
diseñado con el objeto de proporcionar una garantía
razonable para el logro de objetivos incluidos en las
siguientes categorías:

– Eficacia y eficiencia de las operaciones (salvaguarda de activos).


– Confiabilidad de la información financiera.
– Cumplimiento de las leyes, reglamentos y políticas».
– Cumplimiento de los planes estratégicos
Marcos de Control (Estándares
Internacionales) para la Evaluación del
Control Interno en el Mundo

• KING Sudáfrica
• Cadbury Gran Bretaña
• Co. Co. Canadá
• COSO USA**
• Vienot Francia
• Peters Holanda

** El marco COSO ha sido adoptado en los [Link], por el Banco Mundial y


otros organismos financieros a través del mundo.
El informe COSO
COSO: COmmittee of Sponsoring Organizations of the
Treadway Commission)

El Sistema Integrado de Control Interno, es un informe que


establece una definición común de control interno y proporciona
un estándar mediante el cual las organizaciones pueden evaluar y
mejorar sus sistemas de control.

Surge como una forma de solucionar la diversidad de conceptos,


definiciones e interpretaciones existentes en torno al control
interno.
Formada por cinco organizaciones:
1. Financial Executives International
2. Institute of Internal Auditors
3. American Institute of Certified Public
Accountants
4. Institute of Management Accountants
5. American Accounting Association

Reconocido como el estándar internacional


para un marco integrado de control interno
Beneficios de COSO ERM
• Proporciona un marco integral del control interno y
herramientas de valuación para evaluar el sistema de
control
• Alinea el apetito de riesgo con la estrategia corporativa
• Proporciona respuestas integradas a los múltiples riesgos
• Mejora el nivel de las respuestas al riesgo
• Reduce la posibilidad de sorpresas y pérdidas
• Identifica y administra los riesgos a nivel corporativo
• Prepara a la empresa para tomar ventaja de las
10
oportunidades
• Ayuda a mejorar el uso del capital disponible
Componentes Claves del
ERM
Ambiente de Control

Establecimiento de
objetivos

Identificación de
eventos

Evaluación de Riesgos

Respuestas al Riesgo

Actividades de Control

Información y
Comunicación
11
Monitoreo
Métodos de Evaluación del C.I.
La evaluación del control interno se puede realizar mediante:
• Descripciones narrativas
• Cuestionarios especiales
• Diagramas de flujo
• Matrices/mapas de riesgos
ÍNDICES TECNOLÓGICOS
Etapas de la Administración del Riesgo

• Medición de la probabilidad de
• Segmentación factores de riesgo ocurrencia

• Identificación eventos de riesgo • Medición del impacto si ocurre

• Elaboración Matriz o Mapa de Riesgos

Medición o
Identificación
Evaluación

Monitoreo Control
• Revisión de programas, políticas,
normas y procedimientos existentes
• Monitoreo permanente
• Calificación de la efectividad de los
• Evaluaciones independientes controles

• Corregir las deficiencias detectadas • Establecimiento nivel de riesgo residual


MATRÍZ DE RIESGOS
PxI=
P = Probabilidad I = Impacto
Prioridad Respuesta al Recomendación
Posible resultado Responsable de la
No. Riesgo Síntomas riesgo (Control (Control a
(entonces) (Resutasdo acción de respuesta
(A=3/M=2/B=1) (A=3/M=2/B=1) establecido) implementar)
entre 1 y 9)

Identificar una señal de


alarma o advertencia de
Especificar la Deben indicar si es
que el riesgo puede acción que el necesario alguna Nombre del
Evaluar el Priorizar los Equipo de
Evaluar la otra medida o responsable del
Especificar cuál ocurrir. Ejemplo: el impacto en el riesgos con
Detallar el proveedor no probabilidad de Trabajo llevará control a Equipo de Trabajo
sería el efecto en proyecto en caso ayuda de la
1 riesgo proporciona una que el riesgo a cabo para establecer para que llevará a cabo
caso de que el respuesta concreta, sólo ocurra. (Alto, de que el riesgo Matriz que se
identificado. muestra eliminar, reducir, mantener, la acción de
riesgo ocurra. da largas a la entrega del Medio y Bajo) ocurra. (Alto,
trasladar o compartir, explotar respuesta al
equipo. Recuerda que Medio y Bajo) abajo.
mitigar el el riesgo riesgo.
no todos los riesgos
tienen sintomas.
riesgo. identificado.

Por ejemplo
Ejemplo: Que
Por ejemplo: la Por ejemplo: la 3 X 3 = 9
no se entregue Ejemplo: Retraso
valoro como alta valoro como alta ESTO ES
el equipo en en el proyecto.
sería un tres = 3 sería un tres = 3 RIESGO
tiempo.
ALTO

EN EL MAPA DE
CALOR ESTO VA
EN COLOR ROJO
EJEMPLO DE LA TÉCNICA DE
PONDERACIÓN
PESO DE ACUERDO AL CRITERIO,
AREAS O PUNTOS
EXPERIENCIA, HABILIDAD Y
DE INTERES A
CONOCIMIENTO DEL AUDITOR
EVALUAR

PESO
FACTORES PRIMARIOS QUE SERAN
PONDERADOS AQUÍ SE DEFINEN
ESPECIFICO
LOS FACTORES DE
1 Objetivos del Centro de informatica 10%
MAYOR JERARQUIA
2 Estructura de la Organización 10%
O LOS MAS
3 Funciones 15%
4 Sistemas de información 20%
REPRESENTATIVOS
5 Personal y usuarios 15% DE UN GRUPO
6 Documentación de los sistemas 2%
7 Actividades y operaciones del sistema 14%
8 Configuración del sistema 4%
9 Instalación del centro de informática 10%
PESO TOTAL DE LA PONDERACION 100%
Definición de
Seguridad Informática
Elementos de Información
Análisis de Riesgo
Medios de Comunicación
• Lo óptimo es utilizar todo medio disponible a los
distintos usuarios en una empresa, tales como
Correos electrónicos, Mensajes en el boletín,
Comunicados oficiales, etc. Que sirvan para
comunicar los riesgos y controles como también
las responsabilidades de cada puesto.
Matriz para el Análisis de Riesgo
Reducción de Riesgo
1. ORGANIZACIÓN DEL
DEPARTAMENTO
ASPECTOS A CUBRIR
1.1 Diagrama de organización
1.2 Presupuesto de personal
1.3 Diagrama de configuración del sistema
1.4 Control sobre paquetes de software
1.5 Existencia de:
- Contratos con los proveedores
- Definición de características técnicas
1.6 Existencia de reporte de todos los programas
y aplicaciones en uso.
2. SEGUROS, CONTRATOS,
MANTENIMIENTO Y FIANZAS.
ASPECTOS A CUBRIR
2. 1 Pólizas de seguros
Equipos
Programas
Medios de almacenamiento
2.2 Riesgos cubiertos
2.3 Vigencia de seguros
2.4 Contratos de proveedores
Condiciones de uso del equipo
Uso de tiempo CPU
Uso de paquetes
Respaldo y garantía ofrecida
Soporte técnico
2.5 Servicios de mantenimiento
2.6 Fianzas de fidelidad (Caución)
3. MANUALES DE ORGANIZACIÓN
ASPECTOS A CUBRIR
3.1 Existencia de manuales de normas y procedimientos
- Para cada puesto del centro de procesamiento.
3.2 Separación de funciones entre:
Operación del computador.
Análisis
Programación
3.3 Accesos restringidos a los programadores para
operar el sistema.
3.4 Acceso restringido a operadores del computador a:
Datos
Diseño de archivos
Diseño de registros
4. POLÍTICAS DE SEGURIDAD
ASPECTOS A CUBRIR
4.1 Existencia de planes de contingencia.(Plan de continuidad de
negocios)
4.2 Convenios de respaldo de equipos.
4.3 Instrucciones para usos de locales alternos
4.4 Conocimiento con indicación de archivos críticos.
4.5 Prioridades para recuperación de registros.
4.6 Existencia fuera del centro de:
Programas fuentes
Copias actualizadas de los principales archivos
Copias del sistema operativo
Procedimientos de programas operativos
Planes de contingencia (Planes de continuidad de negocio)
Documentación de programas.
4.7 Políticas de respaldo (Backs up)
4.8 Contraseña para operar el sistema
4.9 Existencia documentada de investigación de procesos.
5. SISTEMAS Y MEDIDAS DE
SEGURIDAD
ASPECTOS A CUBRIR
5.1 Procedimientos escritos del sistema de seguridad
5.2 Localización del centro
5.3 Acceso al centro
5.4 Construcción del edificio
5.5 Registro para el ingreso de personas
5.6 Uso de gafetes de identificación
5.7 Vigilancias y alarmas
5.8 Dispositivos para detectar:
calor, fuego, y humo, imanes
5.9 Existencia de extintores
5.10 Estado de equipo de aire acondicionado
5.11 Localización de cables de electricidad e interruptores
5.12 Entrenamiento de personal para atender emergencias
5.13 Otros.
6. PROGRAMAS DE CAPACITACIÓN

ASPECTOS A CUBRIR
6.1 Plan de capacitación constante para el personal
6.2 Registro de adiestramiento que se ha dado a cada
persona.
6.3 Programas de rotación de funciones
6.4 Control sobre trabajo y desempeño del personal.
7. RECEPCIÓN DE TRABAJOS

ASPECTOS A CUBRIR
7.1 Que la recepción de trabajo se efectúe en base a:
Ordenes de trabajo
Registros adecuados
Volantes.
7.2 Comprobar que los registros de recepción
contengan:
Hora de recepción.
Número correlativo de orden de trabajo
Descripción del trabajo
Copias en que solicita el reporte.
7.3 Existencia de cifras de control
7.4 Persona autorizada para entregar trabajos
8. CONTROL DE CALIDAD
ASPECTOS A CUBRIR
8.1 Cotejo de totales entrada/salida
8.2 Verificación de listados de errores o inconsistencias
8.3 Estadísticas por aplicación de errores detectados
8.4 Norma sobre la calidad de impresión exactitud
de los datos
8.5 Número de copias de los reportes (autorizadas)
9. DESPACHO DE TRABAJOS

ASPECTOS A CUBRIR
9.1 Directorio de usuarios
9.2 Lista de usuarios autorizados para retirar
información
9.3 Controles sobre el envío de reportes
9.4 Chequeos para asegurar que el reporte producido
corresponda con el solicitado
9.5 Control sobre las ordenes de trabajo no retiradas
9.6 Protección de la información previo entrega al
usuario
10. CAPTURA DE DATOS

ASPECTOS A CUBRIR
10.1 Forma de recepción de los trabajos
10.2 Criterios para asignar tareas:
Experiencia del personal en determinados trabajos
Cargas de trabajo
Grado de dificultad de trabajo
10.3 Formas de reportar los errores detectados en la captura
10.4 Protección de documentos fuente
10.5 Supervisión del personal
11. PROCESO DE DATOS

ASPECTOS A CUBRIR
11.1 Formas de controlar las órdenes de trabajo
11.2 Existencias de los manuales de operación
de cada aplicación
11.3 Reportes de tiempos utilizados
11.4 Registros del mantenimiento de equipos
12. CINTOTECA
ASPECTOS A CUBRIR
12.1 Accesos a la cintoteca
• Control sobre el contenido de cada archivo
• Uso de etiquetas internas
• Existencia de un registro de todos los dispositivos de
almacenamiento
• Directorios del contenido de archivos
• Procedimientos de control sobre:
Cintas
Discos
Otros
Control sobre:
• Antigüedad, condiciones de uso y estado de los
dispositivos de almacenamiento.
• Control sobre el préstamo de dispositivos de
almacenamiento.
GRACIAS!!!
CPA – M.A Sergio Arturo Sosa Rivas – Coordinador
sergiososa@[Link]
CPA - Nelton Estuardo Mérida
es.tu2010@[Link]
CPA-Oscar Noé López Cordón, MsC
oscarnoe@[Link]
CPA-Víctor Manuel Sipac
victorsipac@[Link]

También podría gustarte