PBarberán - Auditoría de Sistemas Informáticos. Enfoque Metodológico PDF

AUDITORÍA DE SISTEMAS INFORMÁTICOS.
ENFOQUE METODOLÓGICO
AUDITORÍA DE SISTEMAS
INFORMÁTICOS.
PATRICIO BARBERÁN ARBOLEDA
657.458
B234a
BARBERÁN ARBOLEDA, PATRICIO
Auditoría de sistemas informáticos: enfoque metodológico.-
Guayaquil: 1ª edición.- Dirección de Publicaciones
de la Universidad Católica de Santiago de Guayaquil, 2017
144 p.
ÁREA: ADMINISTRACIÓN
1. AUDITORÍA INTERNA.
2. ADMINISTRACIÓN DE EMPRESAS.
3. ADMINISTRACIÓN DE SISTEMAS COMPUTACIONALES.
ISBN: 978-9942-904-62-1
TEDICIÓN
DALIANA DEL CARMEN RODRÍGUEZ CAMPOS
DISEÑO Y DIAGRAMACIÓN
OMAR GUTIÉRREZ GRANELA
SOBRE LA PRESENTE EDICIÓN

© DIRECCIÓN DE PUBLICACIONES DE LA UCSG, 2017
ISBN
XXX-XXXX-XXX-XX-X
DEPÓSITO LEGAL
GYE-XXXXXX
DIRECCIÓN DE PUBLICACIONES
DE LA UNIVERSIDAD CATÓLICA
DE SANTIAGO DE GUAYAQUIL QUEDA RIGUROSAMENTE PROHIBIDA, SIN LA AUTORIZACIÓN ESCRITA
AV. CARLOS JULIO AROSEMENA, KM. 1,5 DE LOS TITULARES DEL COPYRIGHT, BAJO LAS SANCIONES ESTABLECIDAS
TELÉFONO: +593 4 220 9210 EN LAS LEYES, LA REPRODUCCIÓN TOTAL O PARCIAL DE ESTA OBRA POR
GUAYAQUIL, ECUADOR CUALQUIER MEDIO O PROCEDIMIENTO, COMPRENDIDO LA REPROGRAFÍA Y EL
correo electrónico: editorial@cu.ucsg.edu.ec TRATAMIENTO INFORMÁTICO, Y LA DISTRIBUCIÓN DE EJEMPLARES DE ELLA
http://www.ucsg.edu.ec MEDIANTE ALQUILER O PRÉSTAMOS PÚBLICOS.
ÍNDICE
PRÓLOGO 9
IDEAS PRELIMINARES 17
INTRODUCCIÓN 21
PARTE I 25
I. INTRODUCCIÓN A LA AUDITORÍA Y AUDITORÍA DE SISTEMAS 29
II. FUNCIONES DEL AUDITOR DE SISTEMAS 45
III. EVALUACIÓN DE APLICACIONES 65
PARTE II 99
IV. EVALUACIÓN DEL DEPARTAMENTO DE SISTEMAS 103
BIBLIOGRAFÍA 139
PRÓLOGO
El objetivo general de este libro es la presentación de una metodología que
puede aplicarse a las auditorías de sistemas en las empresas. Esta publicación
es el resultado de la amplia experiencia profesional y esfuerzos del autor para
proporcionar a los auditores y a cualquier persona con responsabilidad en los
sistemas de control interno contable o preparación de información financie-
ra, una herramienta que les permita afrontar los desafíos profesionales que
representa el alto desarrollo tecnológico que han experimentado las empresas
para el procesamiento de la información, que en ciertos casos constituyen un
elemento de ventaja competitiva dentro del segmento de mercado donde actúan.
Las empresas han crecido y el volumen de sus operaciones ha aumentado
a tal punto que el funcionamiento actual de las mismas no se concibe sin la
presencia del computador, que no solo se usan para automatizar los procesos
manuales del pasado, sino que incorporan técnicas analíticas orientadas a
proporcionar información para la toma de decisiones. En consecuencia, un
auditor en la ejecución de su trabajo, no solo se enfrenta a un computador,
sino también a nuevos conceptos tecnológicos de sistemas de información.
No existe ninguna duda de que los procedimientos de auditoría se afec-
tan en función del tamaño y las características del sistema de información
implementado por cada compañía. Por esta razón, el auditor necesita
un conocimiento suficiente de los computadores, del procesamiento de la
información y de las maneras en que puede usarlos para ejecutar las pruebas
de auditoría.
Este texto está enfocado en su primer capítulo a identificar y desarrollar
las principales funciones de un auditor de sistemas, dando al lector una me-
todología de cómo aplicarlas en las empresas. Describe el marco conceptual
que conforma la responsabilidad de un auditor con respecto a las tecnologías
implementadas en las empresas.
En los siguientes dos capítulos se desarrollan temas relacionados con las
tecnologías que se presentan en las empresas, las revisiones de las aplicaciones
10 AUDITORÍA DE SISTEMAS INFORMÁTICOS. ENFOQUE METODOLÓGICO
implementadas, y la evaluación de los controles y nivel de seguridad existente

en el departamento de sistemas. Los resultados de dichas evaluaciones tienen
un efecto directo en el trabajo de un auditor. La falta de control o la confianza
depositada en los mismos, influyen en el enfoque de una auditoria, tanto
interna como financiera.
En el desarrollo de este enfoque de auditoría de sistemas, existen dos temas
interesantes que facilitan y estandarizan las evaluaciones: la metodolo-
gía utilizada para el desarrollo de cada una de ellas, y el enfoque que el
autor propone para la evaluación de las aplicaciones y del departamento de
sistemas.
Con respecto al enfoque metodológico, la primera tarea es investigar sobre
el tema a evaluar, luego se solicita la información requerida para el trabajo.
Con el resultado de estas dos actividades se procede a cruzar la información in-
vestigada versus la solicitada, generando los elementos para definir el esquema
de evaluación a aplicar. Posteriormente, se comienza el proceso de evaluación
y finalmente se elabora el informe.
Este esquema se aplica en todos los riesgos detallados en el presente libro,
por ello se convierte en una metodología lógica, fácil de usar y práctica, pues
apoya el proceso de evaluación de temas como la tecnología de información.
El enfoque metodológico propuesto en este libro para la evaluación
divide a cada uno de ellos en cuatro riesgos, lo que permite efectuar revisiones
independientes de acuerdo a las necesidades de la empresa o al enfoque del
auditor. En los procesos de evaluación no existe dependencia entre ellos.
Con respecto a la evaluación de las aplicaciones, el primer riesgo es el
acceso: personal no autorizado con acceso a opciones de las aplicaciones puede
ingresar, modificar, eliminar o consultar información. El segundo riesgo
está enfocado al proceso del ingreso de la información en las aplicaciones: al
ingresar la información, puede estar incompleta, imprecisa o ingresada más
de una vez. Los otros dos riesgos en las aplicaciones están relacionados con la
información rechazada por las aplicaciones: no existen controles adecuados,
la posibilidad de no ser procesada; y finalmente, la información procesada
podría tener fallas internas por el aplicativo de no garantizar su adecuado
procesamiento.
En relación con el departamento de sistemas, los riesgos están enfocados
a la evaluación de políticas y procedimientos, al acceso físico y lógico de los
elementos críticos, riesgos operativos y de gestión críticos, y estructura del
personal del departamento de sistemas. En esencia, el objetivo de evaluar
estos riesgos tanto en las aplicaciones como en el departamento de sistemas,
es determinar si la empresa cuenta con controles sobre los mismos.
PRÓLOGO 11
Probablemente, la mayor dificultad que tienen los auditores internos, las

empresas pequeñas y medianas de auditoría externa y el personal docente
de las universidades y otras instituciones educativas, en relación con la
auditoría de sistemas de información, es la asignación de personal ade-
cuadamente entrenado en estas tecnologías. Las empresas PYMES generalmen-
te no cuentan en sus estructuras con un auditor de sistemas; y relativamente
pocos auditores han recibido capacitación en este tipo de especialización como
parte de su entrenamiento formal.
El autor ha concebido este libro como un «book for dummies», con el propósito
de que sea una guía práctica en el desarrollo de las auditorías de sistemas y
fuente de consulta para los estudiantes de las carreras profesionales afines en
el área de auditoría.
CPA RAÚL G. ORTIZ.

AUDITORÍA DE SISTEMAS INFORMÁTICOS.
DEDICATORIA
A mi madre Genoveva y mi tía Lucila, siempre estarán en mi corazón.

Gracias.
AGRADECIMIENTO
A Fernando Accini Saavedra, por haberme apoyado en este mundo

de la auditoría de sistemas
A la Universidad Católica Santiago de Guayaquil, por su apoyo

en mi formación profesional y académica.
IDEAS PRELIMINARES
Mi primer trabajo fue en el área de Sistemas, como programador. Estuve
laborando por año y medio en dichas funciones cuando un exjefe me llamó
para que trabajara en una firma de auditores como auditor de sistemas. En
realidad, no sabía mucho de las funciones que iba a realizar, pero me pareció
interesante trabajar como auditor de sistemas, era algo diferente.
Desde esa época hasta el día de hoy, he trabajado en diferentes empresas
como auditor de sistemas y tengo que agradecer a dicha especialización el
haber alcanzado muchos objetivos personales y profesionales en mi vida.
Adicionalmente, daré dos razones por lo que la auditoría de sistemas es
importante en su formación.
La primera: el desarrollo de la tecnología ha hecho que las empresas de-
penden más de la misma, como apoyo en su gestión; eso significa que, en el
proceso de ventas, el pago de la nómina en el proceso productivo, el registro
del ingreso y salida de mercadería del inventario, entre otras actividades, se
realice a través de programas de computación.
Si las ventas, la nómina, producción, inventario, la realizan con el soporte
de aplicaciones, lo más lógico es que su contabilidad sea el producto o el resul-
tado de una información procesada por un programa de computación.
Entonces, si Ud. como Auditor, va a revisar y opinar sobre una información
contable, considero que es de mucha utilidad o necesario el que tenga una vi-
sión de las aplicaciones implementadas en la empresa, qué riesgo presentan,
cómo se procesa la información, qué es lo que llega a la contabilidad, entre
otros puntos.
Es ahí donde sirven los conceptos que vamos a revisar en este libro, de
manera que los apoyen en su trabajo o en su formación académica.
La segunda: que Ud. se pregunte ¿por qué? Revisando su formación acadé-
mica, ha recibido muchas materias y en ciertos casos las ha complementado
con cursos, los cuales han servido en su formación, entonces por qué «audito-
ría de sistemas» le va a servir.
La razón fundamental es que auditoría de sistemas es de aquellos temas

que lo orientará en una especialización, que le permitirá obtener una ventaja
competitiva con respecto a sus otros compañeros o colegas de profesión. Un
especialista es más apreciado por las empresas y tiene mayores oportunidades
profesionales.
Otro punto de importancia es conocer cuáles son los requisitos para el tema
que vamos a revisar; podría contestarles con dos palabras opuestas: muchos o
ninguno.
Por lo indicado, ¿en cuál de estos dos grupos se encuentra usted?
La realidad es esa; durante el desarrollo de cada capítulo conocerá y se le
indicará lo que necesite conocer, por lo que no existen requisitos para aplicar lo
visto en este libro. Pero si recomiendo ciertas indicaciones que van a apoyar su
aprendizaje, que le servirán para una mejor comprensión o una mejor visión
de los temas a tratarse.
CERRAR LA BRECHA
Nosotros vamos a auditar al Dpto. de Sistemas o aplicaciones que son maneja-
das desde un computador, por lo cual necesitamos conocer o familiarizarnos
con temas de sistemas.
Una opción que le brinda el mercado sería matricular en una carrera de
Ingeniería de Sistemas u otras afines a la misma; considero que es una buena
idea, pero tal vez no aplicable, por lo cual le propongo cerrar la brecha tecnoló-
gica que existe entre ustedes y la tecnología.
Esto implica incorporar en su estilo de vida diferentes actividades, tales como:
▪▪ Leer revistas de tecnología que existen en el mercado.

▪▪ Revisar artículos relacionados con nuevas tecnologías, en pe-
riódicos, internet, otros.
▪▪ Buscar amigos cuya formación sea técnica y conversar con ellos
sobre temas de sistemas.
Lo que se conseguirá será familiarizarse con conceptos de sistemas, con lo

cual le va a ser más fácil auditar un Dpto. de Sistemas, poder conversar con
mayores elementos de juicio con el responsable de dicha área, entre otras
ventajas.
Espero que hayan aceptado mi recomendación. Lo que sí puedo indicarle
es que lo recomendado le va a servir de manera general en su vida, pues la
tecnología está en todo.
INTRODUCCIÓN
INTRODUCCIÓN
ESTRUCTURA DEL LIBRO

El libro está compuesto por cuatro capítulos, los mismos han sido desarrollados
con la intención de llegar a ustedes de manera sencilla y práctica. Se tratará
de no usar términos técnicos, buscando en el mayor de los casos, ejemplos y
actividades para reforzar el concepto impartido.
En el primer capítulo se revisa el concepto de la auditoría de sistemas, y se
desarrollan las dos primeras actividades sobre el conocimiento necesario que
hay que poseer antes de iniciar cualquier trabajo.
Luego se revisará cuáles son las funciones de un Auditor de sistemas, lo
cual va a servir para identificar las nuevas responsabilidades.
Finalmente, una vez que ya conocida la importancia de la auditoría de
sistemas y revisados los temas técnicos, se propondrá una metodología
de trabajo para realizar una auditoría de sistemas.
El uso de esta metodología permitirá efectuar trabajos de auditoría de siste-
mas en empresas pequeñas, medianas o grandes, empresas relacionadas con
el ámbito industrial, comercial, financiero y de servicios. Luego se revisará la
metodología propuesta para la evaluación de las dos principales funciones de
un Auditor de sistemas:
▪▪ Evaluación de las aplicaciones.

▪▪ Evaluación del Dpto. de Sistemas.
OBJETIVOS DE ESTE LIBRO
GENERAL
Lograr que el lector sea capaz de: manejar metodologías, técnicas y he-
rramientas para plantear y efectuar evaluaciones en las aplicaciones
y en el Departamento de Sistemas, estructurando metodológicamente planes

de trabajo y emitiendo informes con observaciones y recomendaciones.
ESPECÍFICOS
▪▪ Obtener un conocimiento del concepto de la auditoría de siste-

mas.
▪▪ Conocer una metodología para levantamiento de información
del Dpto. de Sistemas.
▪▪ Comprender las funciones del Auditor de sistemas.
▪▪ Identificar los riesgos existentes en una aplicación o sistema de
computación.
▪▪ Conocer una metodología para la evaluación de los riesgos exis-
tentes en una aplicación o sistema de computación.
▪▪ Identificar los riesgos existentes en un Dpto. de Sistemas.
▪▪ Conocer una metodología para la evaluación de los riesgos exis-
tentes en un Dpto. de Sistemas.
RESULTADOS DE APRENDIZAJE
▪▪ Utilizar una metodología para el levantamiento de información

del Dpto. de Sistemas
▪▪ Identificar las funciones del Auditor de sistemas.
▪▪ Identificar los riesgos existentes en una aplicación o sistema de
computación.
▪▪ Utilizar una metodología para la evaluación de los riesgos exis-
tentes en una aplicación o sistema de computación.
▪▪ Identificar los riesgos existentes en un Dpto. de Sistemas.
▪▪ Utilizar una metodología para la evaluación de los riesgos exis-
tentes en un Dpto. de Sistemas.
▪▪ Formular observaciones y recomendaciones de las evaluaciones
efectuadas a las aplicaciones y Dpto. de Sistemas.
DESTINATARIOS
Enfocado a profesionales de la carrera de Contaduría Pública, adicionalmente
puede ser utilizado como material referencial por profesionales técnicos del
área de sistemas. Además, pueden utilizarlo empresas auditoras medianas,
que no cuentan en su estructura personal técnico de auditoría de sistemas.
INTRODUCCIÓN 23
Emplearse también como material de referencia en la formación de audito-

res e ingenieros en sistemas por los diferentes centros de enseñanza superior
o técnicos.
PARTE I
I. INTRODUCCIÓN A LA AUDITORÍA
Y AUDITORÍA DE SISTEMAS
INTRODUCCIÓN A LA AUDITORÍA Y AUDITORÍA DE SISTEMAS
INTRODUCCIÓN
En este capítulo está planificado inicialmente revisar una introducción de
las NIIF en el Ecuador y la importancia de la auditoría de sistemas. Con esta
introducción se analizará el concepto de auditoría de sistemas, para lo cual se
han tomado como referencia a dos autores.
El objetivo de revisar dicho concepto es tener una visión del alcance de la
auditoría de sistemas y cómo puede servir en la formación profesional y
laboral.
Una vez que tenemos definido en qué consiste la auditoría de sistemas, las
primeras actividades que ustedes deberían realizar antes de cualquier inicio
de un trabajo al aplicar auditoría de sistemas, son:
▪▪ Conocimiento del negocio.

▪▪ Conocimiento del departamento de sistemas.
Con respecto al conocimiento del negocio, actividad que no se desarrolla en el

presente libro, se considera que en la formación los estudiantes han adquirido
los conocimientos que les permitirán realizar la misma.
En relación con el conocimiento del departamento de sistemas: en este
capítulo se detallarán las actividades que se efectúan para tener un
conocimiento de dicho departamento, para lo cual se explicará una me-
todología propuesta que ayude y guíe en el desarrollo de dicho conocimiento.
La metodología propuesta detalla qué deben investigar, pedir, revisar y
preguntar, y como toda metodología, es una guía que ayudará a dar un li-
neamiento del trabajo a realizar; sin embargo, la misma debería ser aplicada
y adaptada a las situaciones propias del negocio y a la experiencia individual.
TEMA 1: LAS NORMAS INTERNACIONALES DE INFORMACIÓN FINANCIERA (NIIF)

EN ECUADOR
En el año 2006, de acuerdo a la resolución No. 06.Q.ICI.004, emitida por el
Superintendente de Compañías, publicada en el Registro Oficial No. 348,
se resuelve que Ecuador adopte las Normas Internacionales de Información
Financiera y las aplique con carácter obligatorio a todas las empresas que se
encuentran reguladas por la Superintendencia de Compañías desde el 1 de
enero del 2009, derogando así las Normas Ecuatorianas del Contabilidad.
La Superintendencia de Compañías, mediante resolución No. 08.G.DSC.010
de 2008.11.20, R.O. y No. 498 de 2008.12.31, estableció el cronograma de apli-
cación obligatoria de las NIIF, en 3 grupos desde el 2010 y hasta el 2012
El objetivo de adoptar las NIIF es presentar los estados financieros en un
lenguaje mundial, de tal manera que todos los usuarios puedan entender,
interpretar y analizar la información financiera de la empresa para la toma
de decisiones, al considerar una misma base y armonizar los principios según
se rige la contabilidad a nivel mundial.
Al aplicar las NIIF, las empresas en Ecuador obtuvieron diferentes ventajas,
entre las que podemos mencionar:
▪▪ Información financiera fiable y razonable para la toma de de-

cisiones.
▪▪ Posibilidad de cotizar en bolsa.
▪▪ Armonía de los principios contables.
▪▪ Facilidad para informar la realidad financiera con empresas
que poseen casa matriz en el exterior.
▪▪ Apertura de nuevos mercados mediante un solo lenguaje con-
table.
▪▪ Facilidad de comparar la información financiera con competi-
dores claves.
De la misma forma la aplicación de las NIIF en Ecuador permitió a los entes re-
guladores tener un mayor grado de control sobre la información que presenten
las empresas anualmente y llevó a que las empresas apliquen diferentes estra-
tegias para realizar su adopción de forma práctica y ordenada. Las empresas
optaron por diseñar un programa que incluya principalmente:
▪▪ Modificar los manuales y políticas contables.

▪▪ Identificar ajustes por diferencias entre NEC y NIIF.
▪▪ Identificar deficiencias y debilidades de los sistemas de información.
▪▪ Actualizar procesos existentes y sistemas de información.
▪▪ Cambiar los software y sistemas de contabilidad existentes ajus-

tándose a las necesidades de información.
▪▪ Diseñar una estrategia para soportar los nuevos procesos me-
diante sistemas de información eficaces.
TEMA 2: IMPORTANCIA DE LA AUDITORÍA DE SISTEMAS

El desarrollo de nuevos sistemas de información, actualización de sistemas
y aplicación de nuevos softwares lleva a que sea de suma importancia aplicar
estrategias y programas para evaluar los sistemas utilizados por la empresa.
En un mundo que se encuentra en constante desarrollo resulta indispensable
la evaluación de los sistemas de información.
Toda la información con la que actualmente se maneja la contabilidad es
obtenida de una aplicación de tecnología de información (TI), conjunto de
programas de cómputo que utiliza la empresa para ingresar información y
procesar transacciones, también existe información preparada directamente
por las empresas en hojas de Excel, dicha información requiere ser evaluada,
es ahí cuando nace la importancia de la auditoría de sistemas y las validacio-
nes de la información producida por la empresa.
Entre los principales riesgos que se presentan en la información producida
por la entidad (IPE) podemos listar los siguientes:
▪▪ Los datos procesados por la aplicación de TI en donde la IPE se

produce no es integra ni exacta.
▪▪ Los datos extraídos de la aplicación de TI y convertida a IPE no
son los datos correctos o no están completos.
▪▪ Los datos ingresados por el usuario son inapropiados.
▪▪ Los cálculos o clasificaciones realizadas en la creación de la IPE
no son exactos.
▪▪ Los datos entregados por la aplicación a la herramienta de
cómputo del usuario final se modifica o se pierde cuando se
transfiere.
La información añadida o cambiada (incluidos nuevos cálculos o clasificacio-

nes) usando alguna herramienta o programa externo es incompleta, inexacta
o inapropiada
El auditor deberá aplicar procedimientos para mitigar los riesgos existen-
tes en la información producida por la entidad o evidencia electrónica, con el
propósito de mitigar todos los riesgos existentes, ya sea por accesos, ingresos
de datos, rechazos y procesamientos de datos.
El auditor financiero normalmente aplica procedimientos para mitigar

riesgos de incorrección material, ya sea debido a fraude o error, los proce-
dimientos realizados por el auditor para responder a los riesgos de acuerdo
a la NIA 330 (International Federation of Accountants, 2011: 2-5) comprenden los siguientes
procedimientos:
▪▪ Pruebas de controles.
▪▪ Procedimientos sustantivos (analíticos sustantivos y pruebas
de detalle).
Las pruebas de controles son realizadas por el auditor una vez que se ha
obtenido evidencia suficiente sobre los procesos de la empresa, considerando
solamente los controles implementados por la empresa para prevenir, detectar
y corregir incorrecciones inmateriales. En un ambiente de control el auditor
tiene una mayor confianza y grado de seguridad en el desarrollo de la auditoría
financiera.
Los procedimientos sustantivos comprenden la realización de procedi-
mientos para cada tipo de transacción, saldo contable e información a revelar.
(International Federation of Accountants, 2011: 15)
De acuerdo a (Martínez, 2015): «Los procedimientos analíticos sustantivos
son procedimientos que utiliza el auditor con el fin de evaluar la razonabili-
dad de una cuenta y consisten en comparar lo registrado con expectativas del
auditor».
Para analizar los métodos académicos nos enfocaremos en la evaluación de
los riesgos existentes en la información producida por la entidad y utilizada
en la realización de pruebas de detalle, debido a que las mejores respuestas
a los riesgos pueden incluir una combinación de procedimientos analíticos
sustantivos (basado en expectativas) y pruebas de detalle.
Las pruebas de detalle pueden incluir principalmente los siguientes pro-
cedimientos:
▪▪ Confirmaciones de saldos con terceros.

▪▪ Observación física de activos.
▪▪ Conciliaciones de reportes con libros contables.
▪▪ Revisiones documentales.
▪▪ Recálculos de saldos de cuentas.
TEMA 3: CONCEPTO DE AUDITORÍA DE SISTEMAS

La auditoría de sistemas: «es la revisión técnica, especializada y exhaustiva
que se realiza a los sistemas computacionales, software e información utiliza-
dos en una empresa, sean individuales, compartidos y/o redes, así como a sus
instalaciones, telecomunicaciones, mobiliarios, equipos periféricos y demás
componentes. Dicha revisión se realiza de igual manera a la gestión infor-
mática, el aprovechamiento de sus recursos, las medidas de seguridad y los
bienes de consumo necesarios para el funcionamiento del centro de cómputo.
El propósito fundamental es evaluar el uso adecuado de los sistemas para el
correcto ingreso de los datos, el procesamiento adecuado de la información y la
emisión oportuna de sus resultados en la institución, incluyendo la evaluación
en el cumplimiento de las funciones, actividades y operaciones de funciona-
rios, empleados y usuarios involucrados con los servicios que proporcionan los
sistemas computacionales a la empresa.» (Muñoz, 2002: 19)
«La Auditoría Informática es el proceso de recoger, agrupar y evaluar evi-
dencias para determinar si un sistema informatizado salvaguarda los activos,
mantiene la integridad de los datos, lleva a cabo eficazmente los fines de la
organización y utiliza eficientemente los recursos.» (Piattini y del Peso, 2001:
28-29)
TEMA 4: LEVANTAMIENTO DE INFORMACIÓN

Las primeras actividades que deben realizarse antes de cualquier inicio de
trabajo son:

4.1 CONOCIMIENTO DEL NEGOCIO

Tener un conocimiento del negocio es fundamental para enfocar cualquier
trabajo de auditoría financiera-contable o de auditoría de sistemas. Si bien
se pueden efectuar ciertas revisiones o evaluaciones de temas puntuales,
sin tener un conocimiento del negocio, las mismas podrían no enfocarse en
los principales riesgos del negocio. Por ello la primera actividad que se debe
realizar es el conocimiento del negocio.
Cabe recalcar la importancia de la misma, por ser la primera actividad que
deben realizar.
4.2. CONOCIMIENTO DEL DEPARTAMENTO DE SISTEMAS

Es una actividad importante y requerida para iniciar cualquier tipo de trabajo
de auditoría dentro de una empresa.
Los beneficios de efectuar dicha actividad están enfocados en tener infor-
mación y conocer el Dpto. de Sistemas que se debe auditar, y efectuar un acer-
camiento con el personal responsable de la dirección de dicho departamento.
4.2.1 METODOLOGÍA PROPUESTA

La metodología recomendada para aplicar cuando se realice un trabajo de
auditoría de sistemas está enfocada en cinco actividades que deberán ser
consideradas para cumplir cada trabajo efectuado; detallamos las mismas.
▪▪ Investigar sobre el tema a revisar.

▪▪ Solicitar información del área auditada.
▪▪ Cruzar la información investigada versus solicitada.
▪▪ Preparar lista de preguntas o check list como guía para el tra-
bajo a realizar.
▪▪ Reunirse con los involucrados.
Al utilizar la presente metodología cumplimos con los siguientes objetivos:
▪▪ Estar preparado para la reunión, tema fundamental cuando

se realiza un trabajo donde no existe experiencia previa y hay
ciertas limitaciones técnicas, con el enfoque metodológico se
busca que al investigar se cierre esa brecha del conocimiento.
▪▪ Profesionalizar los trabajos realizados.
4.2.2 DESARROLLO DE LA METODOLOGÍA PROPUESTA PARA OBTENER UN CONOCIMIENTO DEL DEPARTAMENTO

DE SISTEMAS
La primera inquietud que se presenta es qué investigar: claro está que los te-
mas de sistemas son muy amplios, y si la investigación se realizó en Internet,
dicha actividad puede volverse muy compleja por el manejo de la cantidad de
información y selección de la misma.
Se recomiendan los siguientes temas que ayudan a optimizar la investiga-
ción y obtener un conocimiento del departamento de sistemas:
▪▪ Tipos de estructuras organizativas que pueden aplicarse al

administrar un Dpto. de Sistemas.
▪▪ Cargos y funciones principales existentes en un Dpto. de Siste-
mas.
▪▪ Áreas críticas que existen en un Dpto. de Sistemas y cuáles son
sus principales funciones.
▪▪ Cuáles son los principales equipos críticos en un Dpto. de Siste-
mas y sus funciones.
▪▪ Qué aplicaciones existen en el mercado que soporten la gestión
y operación de la empresa donde va a efectuar la revisión, y cuál
es el objetivo y beneficios de las mismas.
▪▪ Principales riesgos en un Dpto. de Sistemas.

▪▪ Principales inconvenientes en un Dpto. de Sistemas.
▪▪ Principales controles en un Dpto. de Sistemas.
La siguiente actividad dentro de la metodología es solicitar información al

responsable del Dpto. de Sistemas, la misma que está alineada con la infor-
mación investigada; de acuerdo a lo indicado se solicitaría:
▪▪ Organigrama del Dpto. de Sistemas.

▪▪ Manual de funciones del personal del Dpto. de Sistemas.
▪▪ Detalle de las áreas críticas del Dpto. de Sistemas y por qué se
consideran tales.
▪▪ Detalle de equipos críticos que son utilizados por el personal
del Dpto. de Sistemas y detallar qué servicio soportan en la
empresa.
▪▪ Detalle de los principales riesgos del Dpto. de Sistemas.
▪▪ Inventario de las aplicaciones implementadas, detallando:
●● Nombre de la aplicación.
●● Breve descripción.
●● A qué áreas soporta.
●● Si es desarrollo local o comprado.
●● Fecha de implementación.
●● Cambios significativos que haya tenido, y en qué fecha se
han presentado los mismos.
▪▪ Plan de trabajo del presente año y del año anterior del Dpto. de
Sistemas, con el análisis de cumplimiento de los mismos.
▪▪ Principales inconvenientes que se han presentado en los temas
de infraestructura, aplicaciones y personal, correspondiente al
año anterior y al actual.
▪▪ Informes de auditorías de sistemas efectuadas correspondien-
tes a los últimos tres años.
▪▪ Informes de consultorías realizadas en el Dpto. de Sistemas en
el último año.
En conclusión, podemos indicar que lo investigado y la información solicitada

al responsable del Dpto. de Sistemas deberían estar enfocados en los siguien-
tes temas:
▪▪ Estructura
▪▪ Equipos
▪▪ Aplicaciones implementadas
▪▪ Gestión del Dpto. de Sistemas
Cabe indicar que toda información debe ser canalizada a través del respon-
sable del Dpto. de Sistemas; el no cumplir dicho lineamiento puede generar
malestar al responsable del mismo, o la persona que nos entrega la informa-
ción podría entregarnos datos errados sin que exista responsabilidad en dicha
entrega; adicionalmente esta solicitud debería ser enviada formalmente a
través de un correo.
El siguiente procedimiento es cruzar la información investigada versus lo
entregado, pues nos podemos encontrar en ciertas situaciones con respecto al
cruce de la información:
1. La primera situación que se puede presentar es que existan

temas que fueron identificados en nuestra investigación reali-
zada y que no se encuentran en la información entregada por
la empresa.
Estos serían puntos considerados en la reunión con el responsable del Dpto.

de Sistemas:
▪▪ Por qué no han sido considerados.

▪▪ Que riesgos existen por no contar con dicho tema.
▪▪ O que han efectuado para mitigar dicho tema.
Como ejemplo detallamos: en lo investigado se indica que un riesgo en el

departamento de sistemas es la falta de respaldo de la información y el res-
ponsable del Dpto. de Sistemas no lo consideró como riesgo. Ante lo indicado
se debería evaluar dicho tema, si han existido inconvenientes, por qué no lo
considera como riesgo dicha actividad.
La otra situación que nos podemos encontrar es la contraria, que existan
temas que están en la información entregada por el responsable del Dpto. de
Sistemas y no en la información investigada.
En estos casos se debería preguntar al responsable del Dpto.de Sistemas:
▪▪ Por qué lo incluyó.

▪▪ Cuál es beneficio para la empresa.
Preparar lista de preguntas o check list como guía para el trabajo a realizar, la
misma que estará enfocada para las siguientes personas:
▪▪ Responsable del Dpto.de Sistemas.

▪▪ Responsables de las áreas críticas.
▪▪ Auditor.
El número de preguntas para el responsable del Dpto.de Sistemas van a ser

mayores en relación con los responsables de las áreas críticas y al Auditor. Las
preguntas para el responsable del Dpto. de Sistemas serán técnicas y puntua-
les, en cambio, para los demás entrevistados, serán preguntas generales y no
técnicas.
Las preguntas para el responsable del Dpto. de Sistemas estarán enfocadas
con los siguientes lineamientos:
▪▪ Solicitar una explicación de la información proporcionada por

el responsable del Dpto. de Sistemas de acuerdo a nuestro re-
querimiento; el objetivo es aclarar o ampliar inquietudes sobre
la información entregada.
▪▪ Preguntar sobre las novedades que se identificaron en la activi-
dad de cruzar lo investigado versus lo entregado.
Para los temas que se investigaron y la empresa no cuenta con los mismos, se
deberían efectuar las siguientes preguntas:
▪▪ Por qué no lo tienen, sea por falta de presupuesto, o porque

tienen otro elemento que mitiga dicha ausencia.
▪▪ Qué riesgo me genera por no tenerlo.
▪▪ Qué medidas de control (manual/automatizado) se han im-
plementado para minimizar el riesgo por la ausencia de dicho
control.
Con respecto a las preguntas que se deberían realizar a los responsables de las
áreas críticas y al Auditor:
▪▪ Qué aplicaciones o sistemas se utilizan en el área.

▪▪ Cuál aplicación es la más crítica y por qué.
▪▪ Qué limitaciones tienen las aplicaciones.
▪▪ Qué mejoras se pueden realizar en las aplicaciones.
▪▪ Qué trabajos se realizan de forma manual.
▪▪ Si han existido fraudes con apoyo de los sistemas de computa-

ción.
Reunirse con los involucrados: esta actividad no debería causar inconvenien-

tes en su ejecución por las actividades efectuadas anteriormente, hemos
investigado, se ha solicitado información de la empresa, la misma que se la ha
revisado y finalmente se ha preparado una guía de preguntas, estos elementos
ayudarán a que estén preparado en la reunión.
Se deben de mantener reuniones por separado con las siguientes personas:
a. Responsable del Dpto. de Sistemas.

b. Responsables de las áreas críticas.
c. Auditor interno o Contralor.
Es importante que al iniciar cada reunión se detalle el objetivo de la reunión

para dar confianza a los entrevistados. El tiempo de la reunión con el
responsable del Dpto. de Sistemas debería ser máximo de una hora a hora y
media. Las reuniones con los responsables de las áreas críticas y el Auditor no
deberían durar más de treinta minutos.
Otro punto importante en la reunión con el responsable del Dpto. de Siste-
mas es aprender a decir «no sé»; muchas ocasiones nuestro ego profesional nos
limita a reconocer que existen temas que no conocemos y esto sucede en mayor
escala cuando tratamos temas tecnológicos.
Adicionalmente, si la posición del responsable del Dpto. de Sistemas en la
reunión es utilizar un lenguaje técnico, debemos indicarle que nuestro perfil
no es técnico sino de controles; que el aporte de nosotros estará en apoyarlo
en su gestión desde el punto de vista de controles, por lo cual no debe utilizar
términos técnicos para obtener mejores resultados de la presente reunión.
ACTIVIDADES
A continuación, se detallan ciertas actividades que tienen como objetivo ayu-
dar a reforzar los conceptos y lineamientos indicados en el presente material.
Actividad 1: Investigar otros conceptos de auditoría de sistemas.
Lineamientos de la actividad recomendada:
Investigar conceptos adicionales de auditoría de sistemas (mínimo dos), y
efectuar las siguientes actividades para cada uno de los conceptos investiga-
dos:
▪▪ Analizar y obtener una conclusión de los conceptos investiga-
dos.
▪▪ Diferencias o aportes de los conceptos investigados versus lo deta-

llado en el presente libro.
Estas diferencias que ustedes pueden identificar en base a su investigación y

análisis deben ser evaluadas posteriormente si son cubiertas en el capítulo dos
(Funciones del Auditor de Sistemas) del presente libro, donde se detallan las
funciones del Auditor de sistemas.
El objetivo de esta actividad es motivar la investigación y relacionar otros
conceptos y conocimientos con el material que se está revisando.
Material requerido para el desarrollo de la actividad:
El material de lectura para el presente trabajo se incluye en el capítulo 1,
tema 3: Concepto de auditoría de sistemas.
Actividad 2: Análisis de la metodología propuesta para obtener un conocimiento
del departamento de sistemas.
Lineamientos de la actividad recomendada a efectuar:
Efectuar un análisis y evaluación de la misma, considerando los siguientes
lineamientos:
▪▪ Dudas e inquietudes sobre la Metodología propuesta.

▪▪ Dudas e inquietudes sobre las actividades a desarrollar para
aplicar la metodología propuesta para obtener un conocimiento
del departamento de sistemas.
▪▪ Otros temas considerados que deberían incluirse en las activi-
dades que tienen que desarrollar para obtener un conocimiento
del Departamento de Sistemas.
▪▪ Limitaciones que podrían presentarse al desarrollar las activi-
dades propuestas.
Cada duda o inquietud que se presente, deberían investigarla y ampliar sobre

el tema adicionalmente, es muy productivo investigar otras metodologías que
apoyen un conocimiento del departamento de sistemas.
El objetivo de esta actividad es analizar, evaluar y cuestionar la metodo-
logía propuesta, lo cual permitirá identificarse con la misma, y adaptarla a
ciertas condiciones propias, como son: nivel de conocimiento, el enfoque de
auditoría que se desea aplicar y ciertas características propias del negocio.
El material de lectura para el presente trabajo se incluye en los siguientes
temas:
▪▪ Capítulo 1, tema 4 - Levantamiento de información

▪▪ Capítulo 1, tema 4.2.1 - Metodología propuesta

▪▪ Capítulo 1, tema 4.2.2 - Desarrollo dela metodología propuesta
para obtener un conocimiento del departamento de Sistemas
RESUMEN
En este capítulo se han visto dos temas fundamentales, el concepto de au-
ditoría de sistemas y las primeras actividades que deben realizar antes de
cualquier inicio de trabajo, las mismas que son:

Con respecto al conocimiento del negocio, es una actividad que no se

desarrolló en el presente libro, ya que en la formación recibida en sus estudios
básicos facilitará los conocimientos que permitirá realizar la misma.
Con respecto al conocimiento del departamento de sistemas es una activi-
dad importante y requerida para iniciar cualquier tipo de trabajo de auditoría
dentro de una empresa. Los beneficios están enfocados a tener información y
conocer sobre el Dpto. de Sistemas que se va a auditar, y efectuar un acer-
camiento con el personal responsable de la dirección de dicho departamento.
La metodología propuesta para efectuar cualquier trabajo de auditoría de
sistemas está enfocada en las siguientes actividades:
▪▪ Investigar sobre el tema a revisar.

▪▪ Solicitar información del área auditada.
▪▪ Cruzar la información investigada versus lo solicitado.
▪▪ Preparar lista de preguntas o check list como guía para el
trabajo a realizar.
▪▪ Reunirse con los involucrados.
En conclusión, podemos indicar que lo investigado y la información solicitada

al responsable del Dpto. de Sistemas deberían estar enfocados en los siguien-
tes temas:
▪▪ Estructura
▪▪ Equipos
▪▪ Aplicaciones implementadas
▪▪ Gestión del Dpto. de Sistemas

MAPA CONCEPTUAL
Auditoría de sistemas. Conocimientos requeridos

II. FUNCIONES DEL AUDITOR
DE SISTEMAS
FUNCIONES DEL AUDITOR DE SISTEMAS
INTRODUCCIÓN
En el presente capítulose definen las funciones de un auditor de sistemas, las
cuales servirán como lineamiento de las actividades que se realizarán en cada
trabajo, a diferencia de las funciones que realicen; si son auditores financieros-
contables o auditores de sistemas deben considerar estas funciones dentro de
sus nuevas actividades en su empresa o donde desempeñan sus labores.
El tener un conocimiento de las funciones los hará responsables de sus
nuevos retos y obligaciones dentro de su desempeño profesional.
Una vez detalladas las catorce funciones de un auditor de sistemas, para
cada una de ellas se procederá a definir una guía de los temas o consideracio-
nes que deben evaluarse para realizar. Cabe mencionar que, las dos principa-
les funciones del auditor de sistemas, se detallarán en los siguientes capítulos
del presente libro.
Una vez detallada las funciones y revisada la guía de cómo evaluarlas, la
siguiente actividad es determinar cómo dar prioridad según importancia a
las mismas, considerándolas desde el punto de vista de un auditor. Estaprio-
rización es un criterio personal y depende de otros elementos como el tipo de
negocio, cultura organizacional de la empresa, riesgo existente en el negocio,
entre otros temas.
Finalmente, en este capítulo se elaborará un concepto de auditoría de sis-
temas considerando las principales funciones; cabe indicar que cada auditor
puede elaborar su propio concepto de auditoría de sistemas según la informa-
ción revisada en este presente capítulo.
TEMA 1: FUNCIONES DEL AUDITOR DE SISTEMAS

Funciones que debe ejercer un Auditor de sistemas:
▪▪ Diseño de un programa formal de auditoría de sistemas que

cubra los diferentes ámbitos computacionales (hardware, soft-
ware, comunicaciones, procedimientos de seguridad y control).
▪▪ Revisión de los riesgos existentes en las aplicaciones y sus con-
troles.
▪▪ Revisión de los riesgos existentes en el Dpto. de Sistemas y sus
controles.
▪▪ Apoyar a la auditoría operativa, financiera y administrativa por
medio de la automatización de sus pruebas y la modernización
de sus herramientas.Evaluación de las políticas y procedimien-
tos existentes en el Dpto. de Sistemas.
▪▪ Análisis de datos de la información registrada en las aplicacio-
nes
▪▪ Participación en la reglamentación y formalización de la perio-
dicidad y tipo de análisis sobre los diferentes tipos de «logs» y
archivos sensitivos.
▪▪ Evaluar las pistas de auditoría de las aplicaciones y equipos en
funcionamiento.
▪▪ Elaborar informe de las evidencias observadas como parte de
los trabajos efectuados con sus respectivas recomendaciones, y
efectuar un seguimiento a los mismos.
▪▪ Participación activa en el diseño y desarrollo de las aplicaciones
con el propósito de que estas sean auditables desde un comienzo,
tengan controles adecuados y cumplan con los requerimientos
definidos.
▪▪ Clasificación y priorización de las aplicaciones en funciona-
miento.
▪▪ Dar los lineamientos para el desarrollo de software de auditoría
a la medida.
▪▪ Participar en el Comité de Seguridades.
▪▪ Participación en las pruebas realizadas para la aceptación de
aplicaciones y modificaciones importantes en las mismas.
TEMA 2: DESARROLLO DE LAS ACTIVIDADES QUE SE DEBEN CONSIDERAR PARA CUMPLIR

LAS PRINCIPALES FUNCIONES DEL AUDITOR DE SISTEMAS
El esquema propuesto para la revisión de las funciones del Auditor de sistemas
será, para cada una de las principales funciones se detallarán las actividades
que deben realizarse para cumplir las mismas, con el objetivo, no solo de
conocer cuáles son las funciones, sino tener los lineamientos de los pasos que
deben realizarse:
2.1. DISEÑO DE UN PROGRAMA FORMAL DE AUDITORÍA DE SISTEMAS
Un programa formal de auditoría de sistema debe realizarse en noviembre,
para que en diciembre la Administración lo haya aprobado, y el primer día del
siguiente año exista un documento formal de cuáles serán las actividades a
realizar.
Si el auditor se incorpora a una empresa a mediados de año, debe revisar
la planificación de trabajo existente y evaluar si la misma incluye actividades
que cubren las funciones del auditor de sistemas; en caso contrario debe eva-
luarse la situación y ajustar el plan de trabajo.
Un programa formal de auditoría de sistemas incluye la siguiente infor-
mación:
▪▪ Actividades o revisiones a realizar.

▪▪ Objetivos cubiertos con cada una de las actividades.
▪▪ Fecha de inicio.
▪▪ Fecha de finalización.
▪▪ Recursos requeridos.
Para elaborar el programa de auditoría de sistemas, se recomiendan los si-

guientes pasos:
1. Conocer el negocio, esta es una actividad para la que el auditor

financiero-contable tiene los conocimientos necesarios, por lo que no
se detallarán los pasos que se deben realizar para ejecutar la misma.
Lo importante es que, al finalizar la revelación de la información para
conocer del negocio, el auditor de sistemas debe tener definido:
a. Cuáles son los procesos críticos del negocio.

b. Riesgo en el negocio.
c. Cambios significativos en el negocio efectuados en el último
año.
d. Los planes estratégicos de la empresa.
e. Otros temas relevantes.
2. Investigar temas relacionados al Dpto. de Sistemas que ayuden en la

planificación; como ejemplo detallamos:
a. Principales riesgos en el Dpto. de Sistemas.

b. Aplicaciones críticas enfocadas al tipo de negocio de la
empresa donde está efectuando el trabajo.
c. Equipos críticos que soporten la gestión de la empresa.
3. Solicitar información al responsable del Dpto. de Sistemas, donde

detallamos:
a. Organigrama del departamento de sistema.

b. Manual de funciones del personal del departamento de sistema.
c. Inventario de aplicaciones que incluye: breve descripción, cuáles
son críticas y por qué, cambios significativos realizados en las
mismas en el último año.
d. Inventario de equipos detallando cuáles son críticos y por qué.
e. Principales cambios realizados en el último periodo de análisis
(año) y en el presente periodo.
f. Planificación de trabajo actual con el porcentaje de cumplimiento
de las actividades a la fecha.
g. Planificación de trabajo del periodo anterior (año), con el cumpli-
miento del mismo.
h. Presupuesto del Dpto. de Sistemas del periodo anterior y del ac-
tual.
i. Principales debilidades del área.
j. Informe de consultorías efectuadas para el Dpto. de Sistemas
relacionadas a temas de seguridades.
4. Solicitar al Auditor informes de auditorías externas y de sistemas

efectuados en periodos anteriores.
5. Cruzar la información investigada versus lo solicitado.
6. Reunirse con los responsables de las áreas críticas y preguntar:
a. Cuáles son las aplicaciones críticas y por qué.

b. Qué inconvenientes han tenido o tienen con los sistemas.
c. Qué cambios se han efectuado en los últimos meses.
d. Qué temas se manejan manualmente.
e. Qué temas relacionados con el Dpto. de Sistema no han sido aten-
didos y que riesgos o efectos se generan por lo indicado.
7. Reunirse con el responsable del Dpto. de Sistemas; en dicha reunión

debe revisarse la información solicitada y temas o inquietudes que
salieron de la reunión con los responsables de las áreas críticas, así

como inquietudes de temas que investigaron.
8. Reunirse con el auditor general; el objetivo es revisar qué necesidades
tiene, y evaluar su planificación de trabajo para determinar si en
alguna actividad requiere el apoyo de la auditoría de sistemas. Es
fundamental que antes de tratar cualquier tema con el auditor gene-
ral, primero se efectúe una explicación de las funciones del auditor de
sistemas y de cómo puede ayudar en su trabajo.
9. Reunirse con el gerente general; el objetivo es darle a conocer los bene-
ficios de la auditoría de sistemas y preguntarle si existe algún tema o
área que considera debería ser evaluada.
10. Elaborar una planificación.
Temas a considerar de lo detallado:
▪▪ Es importante solicitar información antes de las reuniones, ya

que eso permitirá una mejor preparación.
▪▪ Reunirse primero con los responsables de las áreas críticas y
luego con el responsable del Dpto. de Sistemas, con el objetivo
de obtener mayor información para la reunión con la parte
técnica.
▪▪ Es importante la reunión con el auditor general, ya que los
trabajos de auditoría de sistemas deben relacionarse y enfocar-
se hacia los trabajos financieros contables.
2.2. REVISIÓN DE LOS RIESGOS EXISTENTES EN LAS APLICACIONES Y SUS CONTROLES

Corresponde a una de las principales funciones que un Auditor de sistemas
debe realizar; los principales puntos a considerar para la ejecución de la mis-
ma son:
▪▪ El punto fundamental para ejecutar está función es determinar qué

aplicación es la que se va a revisar, para lo cual se debe realizar una matriz
de riesgo que soporte dicha definición.
▪▪ Para la aplicación seleccionada se debe determinar qué procesos críticos del
negocio se van a evaluar. De igual manera se debería realizar un matriz
de riesgo para la determinación de los mismos.
▪▪ Una vez definida la aplicación y el proceso crítico del negocio
para ser evaluado, se debe determinar qué actividades generan mayor riesgo, y se les
efectuará una auditoría de sistemas a dichas actividades.
Se utilizará un enfoque metodológico de evaluación de aplicaciones, compues-

to de las siguientes revisiones:
▪▪ Seguridades.
▪▪ Ingreso de datos.
▪▪ Rechazo de datos.
▪▪ Procesamiento de datos.
▪▪ Por ser una de las funciones más importantes del Auditor de
sistemas, estos puntos serán revisados en detalle en el capítulo
tres del presente libro.
2.3. REVISIÓN DE LOS RIESGOS EXISTENTES EN EL DEPARTAMENTO DE SISTEMAS Y SUS CONTROLES

Corresponde a una de las principales funciones que un auditor de sistemas
debe realizar, para lo cual se utilizará el siguiente enfoque metodológico:
▪▪ Políticas y procedimientos del Dpto. de Sistemas.

▪▪ Acceso físico y procedimientos del Dpto. de Sistemas.
▪▪ Riesgos operativos y de gestión críticos del Dpto. de Sistemas.
▪▪ Estructura del Dpto. de Sistemas.
La aplicación de la presente metodología va a requerir que se ejecuten trabajos

en temas técnicos propios del Dpto. de Sistemas, lo cual en muchas ocasiones
limita al auditor financiero-contable a realizar dichos trabajos, pero aplicando
la metodología propuesta (capítulo 4, tema 1, Metodología para la evaluación
de un Dpto. de Sistemas) se obtienen los conocimientos requeridos para efec-
tuar dichas revisiones.
Por ser una de las funciones más importantes del auditor de sistemas, este
tema será revisado en detalle en el capítulo cuatro del presente libro.
2.4. APOYAR A LA AUDITORÍA OPERATIVA, FINANCIERA Y ADMINISTRATIVA POR MEDIO DE LA AUTOMATIZACIÓN

DE SUS PRUEBAS Y LA MODERNIZACIÓN DE SUS HERRAMIENTAS
Es una de las funciones importante del auditor de sistemas, con ella le puede
ayudar al auditor financiero-contable en su trabajo, al considerar:
▪▪ Evaluando los riesgos de una aplicación se puede concluir que si

dicha aplicación tiene buenos controles el enfoque de la audito-
ría puede cambiar a un tipo de auditoría de cumplimiento, en
donde se optimizan los trabajos realizados y el número de horas
de trabajo invertidas.
▪▪ Pruebas establecidas en un plan de trabajo de una auditoría

pueden realizarse por el auditor de sistemas, con lo cual se
obtienen beneficios como:
●● Optimización del tiempo en la elaboración de dicha prueba.

●● Un mayor alcance de la prueba realizada; si se realiza ma-
nualmente se toma una muestra… si el auditor de sistemas
la realiza, puede ejecutar dicha prueba para todo el universo
definido.
Como ejemplo de pruebas que pueden efectuarse existen:
▪▪ validar que todas las facturas han sido registradas al precio de

venta autorizado.
▪▪ verificar que el número de hora extras reportadas por los obreros
no exceden lo establecidos por las normas laborales y políticas
internas de la empresa, entre otros.
▪▪ Apoyo en actividades definidas en el plan de trabajo de la au-
ditoría a realizar, por ejemplo ayudar a seleccionar la muestra
y elaborar las cartas de circularización de manera automática,
elaborar reporte de información requerida, entre otros.
2.5. EVALUACIÓN DE LAS POLÍTICAS Y PROCEDIMIENTOS EXISTENTES EN EL DPTO. DE SISTEMAS

En toda área crítica deben existir políticas y procedimientos; es decir, todas
las actividades de dicha área deben estar normadas a través de políticas y pro-
cedimientos. El departamento de Sistemas es un área crítica, por lo que todas
sus principales actividades deben estar sujetas por políticas y procedimientos.
Las mismas deben cumplir con ciertas características básicas:
▪▪ Actualizadas.
▪▪ Aprobadas.
▪▪ Formalizadas y conocidas por el personal involucrado.
Detallamos los pasos que deberían efectuarse para dicha evaluación:
▪▪ Definir qué procesos críticos del Dpto. de Sistemas van a ser eva-
luados, para lo cual se debe realizar una matriz de riesgo para
determinar qué procesos son de mayor riesgo en el negocio. Más
adelante detallaremos consideraciones para la elaboración de la
matriz de riesgo.
▪▪ Investigar sobre políticas y procedimientos que se aplican en los

procesos críticos seleccionados.
▪▪ Investigar en metodologías existentes qué buenas prácticas
existen sobre los procesos críticos seleccionados.
▪▪ Solicitar al responsable del Dpto. de Sistemas las políticas y
procedimientos de los procesos críticos seleccionados del Dpto.
de Sistemas.
▪▪ Analizar la información investigada y entregada por el res-
ponsable del Dpto. de Sistemas.
▪▪ Elaborar listado de preguntas a realizar en base al análisis
efectuado.
▪▪ Reunirse con el personal operativo involucrado en los procesos
críticos seleccionados y realizar pruebas de verificación del
cumplimiento de las políticas y procedimientos evaluados.
▪▪ En los casos que sea necesario solicitar información de soporte
o evidencias.
▪▪ Preguntarle al personal operativo sobre las debilidades o me-
joras que pueden aplicarse en las políticas y procedimientos
evaluados.
▪▪ Reunirse con el personal técnico responsable de la elaboración
de las políticas y procedimientos para determinar cuáles son
los procedimientos y controles para garantizar que los mismos
estén actualizados y comunicados a los involucrados.
▪▪ Elaborar informe.
De lo que pudimos observar con respecto a las diferentes actividades que se

recomiendan para la evaluación de las políticas y procedimientos, podemos
mencionar que generalmente el auditor efectúa dichas funciones en las dife-
rentes áreas de la empresa; sin embargo, nunca ingresa al departamento de
sistemas a evaluar sus políticas y procedimientos.
Considero que dicha posición se debe por la falta de seguridad que el auditor
tiene en ingresar al departamento de sistemas.
2.6. ANÁLISIS DE DATOS DE LA INFORMACIÓN REGISTRADA EN LAS APLICACIONES

Es una actividad importante del auditor de sistemas y de acuerdo al enfoque
de la revisión a realizar puede servir de apoyo para evaluar la seguridad o los
controles implementados en los sistemas de computación, tanto para el ingre-
so o procesamiento de la información.
Para efectuar dicha función se debe reunir con el responsable del Dpto.
del Sistemas para que le autorice a entrevistarse con el analista de sistemas;
caso que no exista dicho cargo, se reunirá con la persona que efectúa tales
funciones.
El analista de sistemas es la persona encargada de efectuar el análisis
de las aplicaciones existentes en la empresa, actividad requerida cuando se
desarrolla una aplicación o cuando se modifica, por lo cual conoce como está
diseñada una aplicación y sus tablas.
Información requerida para efectuar un análisis de datos de la informa-
ción registrada en las aplicaciones:
▪▪ La primera información que se debe solicitar es un inventario

de las aplicaciones que tienen implementadas en la empresa y
una breve descripción.
▪▪ Adicionalmente, solicitará un inventario de las principales
tablas que tiene cada una de las aplicaciones, con una breve
descripción de qué información se guarda en las mismas.
Con dicha información y definido cuál es el trabajo que se realizará, se so-

licitan las tablas requeridas, para lo cual se recomienda tener presente las
siguientes observaciones:
▪▪ La información requerida debe entregarse en un archivo forma-

to Excel, en caso que la información sea mayor a la capacidad
que permite trabajar Excel, se solicitará que la información sea
dividida en diferentes archivos u hojas.
▪▪ Al solicitar la información se debe definir para qué periodo de
análisis se requieren los datos.
▪▪ Una vez entregada la información, revisar qué campos contie-
nen dicha tabla y revisar la misma.
Una vez terminada de efectuar dicha revisión, se valida con el analista de

sistemas la información concluyente con respecto a los campos de las tablas y
cualquier inquietud sobre la información entregada.
Es importante validar toda la información; un error en la interpretación
afecta todo el trabajo y los resultados obtenidos. Por ejemplo, si solicitó la tabla
de facturas y luego de la revisión se determinó que en la primera columna
está el código del cliente, en la segunda columna está la fecha y en la tercera
columna el valor. Esa información debe validarla el analista de sistemas,
verificando si el punto de vista es correcto.
Antes de cualquier análisis igualmente se confirma que los datos entre-
gados sean los correctos. Por ejemplo, si solicité la tabla de facturas, se deben
sumar todas las facturas del mes y cruzar con el total de ventas registrado en
la contabilidad.
Una limitación que podría afectar la ejecución de esta función es que la
aplicación evaluada sea una aplicación comprada y no se cuenta con los sufi-
cientes conocimientos o con la información técnica de las tablas.
2.7 PARTICIPACIÓN EN LA REGLAMENTACIÓN Y FORMALIZACIÓN DE LA PERIODICIDAD Y TIPO DE ANÁLISIS

SOBRE LOS DIFERENTES TIPOS DE «LOGS» Y ARCHIVOS SENSITIVOS
Los archivos «logs» son una bitácora digital que mantiene información de
eventos o sucesos ocurridos en las aplicaciones o en el ambiente informático.
Para una mejor compresión, podría relacionarse como la bitácora que
mantiene un guardia de seguridad en el ingreso a un área; en ella registra
la fecha, hora, nombre de la persona que ingresa, número de cédula. Este
elemento de control servirá si se necesita conocer quién ingresó o salió de la
empresa en un momento dado.
El mismo concepto es aplicado en los sistemas computacionales, en un
archivo digital se puede registrar quien ingresó a la aplicación, a qué hora,
desde qué computador o IP, qué transacción ejecutó, qué cambio efectuó en la
información.
Dicha información es valiosa y fundamental si se desea efectuar una
auditoría forense, pero existen ciertas limitaciones técnicas que restringen
el uso de los archivos «logs», ya que ocupan espacio en disco y tiempo de
procesamiento, por lo cual hay que efectuar una evaluación muy técnica para
determinar qué archivos «logs» es información que debe guardarse.
Por lo indicado la función del Auditor de sistemas es:
Determinar qué eventos deben mantener un archivo «logs».

▪▪ Ejemplos de eventos: ingreso a la red de la empresa, ingreso al
aplicativo de nómina, consulta de los sueldos de los empleados,
modificación de un sueldo.
▪▪ Qué información debe guardarse en cada evento.
▪▪ La ejecución de dicha función debe corroborrarse con los usua-
rios y personal técnico de sistemas, enfocándose en:
●● Usuario: es el personal involucrado en los procesos críticos

del negocio, tanto operativo como gerencial y serán las per-
sonas que indicaran cuáles son puntos clave que requieren
un control de un archivo «logs».
●● Personal técnico: es el analista de sistemas, quien aporta
al indicar en las aplicaciones cuales son los temas o puntos
que debe controlar un archivo «logs»; adicionalmente, el

responsable del Dpto. de Sistemas también puede aportar
con el tema.
2.8. EVALUAR LAS PISTAS DE AUDITORÍA DE LAS APLICACIONES Y EQUIPOS EN FUNCIONAMIENTO

Es una actividad importante y de acuerdo al enfoque aplicado podría servir
para evaluar la seguridad en las aplicaciones o determinar cambios no
autorizados, las mismas son funciones del auditor de sistemas; entre ellas
indicamos:
▪▪ Revisión de la seguridad: en los archivos «logs» queda registrado

el usuario que realizó una transacción en la aplicación, desde
que máquina lo efectuó, en que día y a qué hora, lo cual nos per-
mite efectuar revisiones en temas de seguridades, por ejemplo:
al revisar una tabla «logs» de ventas, se obtiene un resumen de
todos los nombres de usuarios que han ingresado las facturas
en la aplicación para identificar que un usuario ha ingresado
una factura y el mismo no es una persona autorizada.
La definición de la seguridad en las aplicaciones puede generar debilidades, al

existir usuarios con acceso a opciones no autorizadas o no requeridas por sus
funciones. Si la transacción ejecutada es en un horario en que el funcionario o
empleado no estuvo en la empresa, se concluye que no se cumplen las políticas
recomendadas en el manejo de las claves, que las mismas son personales, o
en su efecto alguien está utilizando dicho usuario de manera no autorizada.
▪▪ Determinación de cambios no autorizados: en los archivos

«logs» puede guardarse la información crítica de los sistemas
que ha sido cambiada por los usuarios, al quedar el rastro de
quién lo hizo, en qué fecha, cuál era el valor original y el nuevo
valor cambiado.
Al analizar la misma, se puede determinar si los cambios fueron realizados

por personal autorizado o analizar todos los cambios para identificar transac-
ciones dudosas. Por ejemplo, se puede evaluar los cambios efectuados en los
datos del cliente respecto al tipo de cliente, si identificó que un cliente cambia
frecuentemente de minorista a mayorista, podría darse el caso de cambio de
tipología de cliente para favorecerlo con un precio especial.
2.9. ELABORAR INFORME DE LAS EVIDENCIAS OBSERVADAS COMO PARTE DEL TRABAJO, CON SUS RESPECTIVAS
RECOMENDACIONES, Y REALIZAR UN SEGUIMIENTO A LOS MISMOS
La experiencia adquirida como auditores hace que esta función sea fácil de
ejecutar; sin embargo, se detallan ciertas recomendaciones:
▪▪ Los temas que se revisan en el Dpto. de Sistemas son técnicos.

No se deben utilizar conceptos técnicos en el desarrollo de los
informes, ya que se puede caer en el error de no utilizar apropia-
damente los mismos.
▪▪ El enfoque de las observaciones será detallar lo observado e
indicar el riesgo, si bien este último tema es cuestionado en
ciertas empresas, ya que no se sienten cómodos cuando se les
indica el riesgo expuesto.
▪▪ Las recomendaciones deben ser generales.
▪▪ Los informes deben comenzar con un párrafo positivo de la
gestión en la administración del Dpto. de Sistemas del área
evaluada.
▪▪ Todos los informes deben revisarse en un borrador preliminar
con el personal técnico del Dpto. de Sistemas o personal invo-
lucrado.
2.10. PARTICIPACIÓN ACTIVA EN EL DISEÑO Y DESARROLLO DE LAS APLICACIONES CON EL PROPÓSITO DE QUE ESTAS
SEAN AUDITABLES DESDE UN COMIENZO, TENGAN CONTROLES ADECUADOS Y CUMPLAN CON REQUERIMIENTOS
No es una función principal del auditor de sistemas, y auqnue puede aportar

con sus puntos de vista, no deber involucrarse en el diseño y desarrollo de
aplicaciones.
2.11. CLASIFICACIÓN Y PRIORIZACIÓN DE LAS APLICACIONES EN FUNCIONAMIENTO

No es una función principal del auditor de sistemas, puede aportar con sus
puntos de vista, pero no debería involucrarse en dicho proceso.
2.12. DAR LOS LINEAMIENTOS PARA EL DESARROLLO DE SOFTWARE DE AUDITORÍA A LA MEDIDA

Es una actividad importante que debe considerarse una vez efectuado el
trabajo de auditoría de sistemas. También debe evaluarse que en el mercado
existen herramientas que apoyan dicha función, tales como el ACL o el IDEA .
2.13. PARTICIPAR EN EL COMITÉ DE SEGURIDAD

Es una función importante y el Auditor de sistemas debe formar parte de este
Comité en la empresa.
Temas a considerar en la formación del Comité de Seguridad:
▪▪ Determinar qué cargos van a integrar dicho comité; deben ser

los responsable sde las áreas críticas y personas que tengan el
poder de tomar decisiones.
▪▪ Establecer cuáles son las funciones del Comité.
▪▪ Determinar la periodicidad de las reuniones; mínimo trimes-
tralmente.
2.14. PARTICIPACIÓN EN LAS PRUEBAS REALIZADAS PARA LA ACEPTACIÓN DE APLICACIONES Y MODIFICACIONES

IMPORTANTES
No es una función principal del Auditor de sistemas y considero que el mismo
debería evitar realizar dicha función, y aunque puede aportar sus puntos de
vista, podría involucrarse en dicho proceso y perder independencia.
TEMA 3: PRIORIZACIÓN DE LAS FUNCIONES

Una vez revisada las catorce funciones del auditor de sistemas, y en aras de
establecer una prioridad en las mismas, para lo cual se utilizó un criterio per-
sonal y profesional, enfocándolo en la importancia para el auditor financiero-
contable como soporte en su gestión.
Las principales funciones del Auditor de sistemas serían:
▪▪ Diseño de un programa formal de auditoría de sistemas.

▪▪ Revisión de los riesgos existentes en las aplicaciones y sus con-
troles.
controles.
▪▪ Apoyar a la auditoría operativa, financiera y administrativa por
de sus herramientas.
▪▪ Evaluación de las políticas y procedimientos existentes en el
Dpto. de Sistemas.
nes.
▪▪ Evaluar las pistas de auditoría de las aplicaciones y equipos en
funcionamiento.
los trabajos efectuados y emitir recomendaciones y efectuar un
seguimiento a los mismos.
Otra alternativa de priorización es considerar las funciones más fáciles de

ejecutar o realizar para un auditor financiero-contable:
▪▪ Evaluación de las políticas y procedimientos existentes en el

Dpto. de Sistemas.
nes.
los trabajos efectuados, emitir recomendaciones y efectuar un
seguimiento a los mismos.
Adicionalmente, priorizar la ejecución de dichas funciones dependerá de

diferentes variables:
▪▪ Perfil profesional, que podría ser técnico o no, por lo que la revi-
sión de los riesgos del Dpto. de Sistemas y sus controles requiere
de un perfil más técnico, al recomendar que a dicha función se
le asigne una prioridad menor de ejecución.
▪▪ Características propias del negocio.
▪▪ Requerimientos puntuales de la Administración.
El objetivo de estas alternativas es realizar una auditoría de sistema en una

empresa, tomando en cuenta:
▪▪ Una evaluación de las políticas y procedimientos del Dpto. de

Sistemas, para los procesos críticos de dicho departamento.
▪▪ La toma de una aplicación sencilla o la que más dominen y efec-
tuar una «revisión de los riesgos existentes en las aplicaciones y
sus controles», la metodología para dicha evaluación se revisará
en el capítulo tres del presente libro.
▪▪ Finalmente, ingresar al Dpto. de Sistemas y evaluar la segu-
ridad física del mismo, inmerso en la función «revisión de los
riesgos del Dpto. de Sistemas y sus controles», que se analizará
en detalle en el capítulo cuatro del presente libro.
TEMA 4: FORMULACIÓN DE UN CONCEPTO DE AUDITORÍA DE SISTEMAS BASADO

EN SUS FUNCIONES
De acuerdo a la información revisada, donde hemos visto las catorce funciones
de un auditor de sistemas (tema 2) y su priorización, considerando algunas
alternativas y el perfil de auditor financiero-contable (tema 3) estamos en la
capacidad de desarrollar nuestro propio concepto de auditoría de sistemas. La

auditoría de sistemas es:
La ciencia que se «encarga de revisar los riesgos existentes en las aplica-

ciones y en el Dpto. de Sistemas, recomendando controles para minimizar
dichos riesgos a través de informes entregados a la Administración de la
misma».
Este concepto es puntual; se enfoca en los riesgos existentes en las aplicaciones

y en el Dpto. de Sistemas, elementos fundamentales que soportan la gestión
de una empresa. También se puede desarrollar un concepto considerando las
principales funciones del auditor de sistemas, e indicamos:
Es la encargada de revisar los riesgos existentes en las aplicaciones y en el

Dpto. de Sistemas de la empresa, evalua sus políticas y procedimientos,
apoya la auditoría operativa, financiera y administrativa por medio de la
automatización de pruebas y analiza las bases de datos y archivos «logs»
propios de las aplicaciones con el objetivo de recomendar controles para
minimizar riesgos a través de informes entregados a la Administración.
ACTIVIDADES
Actividad 1: Análisis de las funciones del Auditor de sistemas.
Lineamientos de la actividad:
En base al material detallado con respecto a las funciones del auditor de
sistemas, efectuar un análisis y evaluación de las mismas, considerando los
siguientes lineamientos:
▪▪ Dudas e inquietudes de la información entregada en el presente

material.
▪▪ Qué otras funciones consideran que pueden ser incluidas.
▪▪ Actividades que se deben realizar para cumplir las funciones
detalladas, qué otras actividades se pueden incluir.
▪▪ Qué limitaciones se pueden presentar al realizar las actividades
detalladas en cada una de las funciones y por qué.
Cada duda o inquietud que se presente, deben de investigar y ampliar sobre

el tema, adicionalmente, es muy productivo investigar otras funciones del
auditor de sistemas.
El objetivo de esta actividad es familiarizarse con las funciones del auditor

de sistemas, analizar, evaluar y cuestionar la metodología propuesta para
valorar cada una de dichas funciones.
Material requerido para el desarrollo de la actividad: El material de lectura
para el presente trabajo se incluye en el capítulo 2, tema 2: Desarrollo de las
actividades que se deben considerar para cumplir las principales funciones del
Actividad 2: Presentar una propuesta de priorización de las funciones del
Auditor de sistemas.
Lineamientos de la actividad: En base a la información detallada de las fun-
ciones del auditor de sistemas, evalúe y proponga una priorización de las
funciones de acuerdo a:
▪▪ Su perfil profesional.
▪▪ La planificación de la auditoría interna o financiera.
▪▪ Consideraciones propias de un negocio.
El objetivo de esta actividad es comenzar a aplicar las funciones del auditor

de sistemas, adicionalmente, esta actividad servirá para complementar la
planificación de trabajo de la auditoría interna o financiera.
Material requerido para el desarrollo de la actividad: El material de lectura
para el presente trabajo se incluye en el capítulo 2, tema 3: Priorización de las
funciones.
RESUMEN
En este capítulo se revisaron las catorce funciones del auditor de sistemas con
su respectiva guía o lineamientos de las actividades que deben efectuarse para
cumplir con las mismas, dándole prioridad desde su importancia para el audi-
tor financiero-contable, se detallan las mismas en un orden de importancia:
▪▪ Diseño de un programa formal de auditoría de sistemas.

▪▪ Revisión de los riesgos existentes en las aplicaciones y sus controles.
controles.
▪▪ Apoyar la auditoría operativa, financiera y administrativa por
de sus herramientas.
▪▪ Evaluación de las políticas y procedimientos.
▪▪ Análisis de datos de la información registrada en las aplicaciones.
▪▪ Evaluar las pistas de auditoría de las aplicaciones y equipos.
▪▪ Elaborar informe de las evidencias observadas.
Otra alternativa de priorización de las funciones del auditor de sistemas, es

considerar aquellas que son más fáciles de ejecutar por parte de un auditor
financiero-contable, por lo que detallamos las mismas en orden de facilidad
de ejecución:
▪▪ Evaluación de las políticas y procedimientos.

▪▪ Análisis de datos de la información registrada en las aplicaciones.
▪▪ Elaborar informe de las evidencias observadas.
Es importante mencionar que priorizar la ejecución de dichas funciones de-

penderá de diferentes variables como:
▪▪ Perfil profesional.
▪▪ Características propias del negocio.
▪▪ Requerimientos puntuales de la Administración.
En conclusión, en este capítulo se definen las funciones de un auditor de siste-

mas, las cuales servirán como lineamiento de las actividades que se proyecten
como auditores. Tener un conocimiento de las funciones confiere responsabi-
lidad en nuevos retos y obligaciones dentro del desempeño profesional.
MAPA CONCEPTUAL
Auditoría de sistemas funciones

III. EVALUACIÓN DE APLICACIONES
EVALUACIÓN DE APLICACIONES
INTRODUCCIÓN
En este capítulo se ofrecen los lineamientos para una revisión de las aplica-
ciones y sus controles, como se indicó en el capítulo 2, tema 3: Priorización
de las funciones. En primera instancia se revisará la definición de aplicación
y ejemplos de las mismas, para definir cuál de esas aplicaciones son las que
tienen un mayor riesgo en el negocio, y en consecuencia evaluarla.
Lo fundamental en cualquier revisión es poder contar con una metodolo-
gía, por lo que en este capítulo se presenta un esquema de trabajo que consiste
en la evaluación de cuatro riesgos:
▪▪ Riesgo I - Acceso a funciones de procesamiento.

▪▪ Riesgo II - Ingreso de datos/información.
▪▪ Riesgo III - Ítems rechazados/suspensos.
▪▪ Riesgo IV - Procesamiento.
Lo interesante de esta metodología es la facilidad que tiene para utilizar y es

aplicable para todo tipo de negocio; por ejemplo, la misma metodología se
puede aplicar en empresas comerciales, industriales, bancarias o de servicios.
Adicionalmente, cabe señalar que no importa el tamaño de empresa,
puede ser grande, mediana o pequeña, en la que al revisar una aplicación se
pueden evaluar los cuatro riesgos.
En conclusión, la metodología es flexible, ya que permite evaluar cada
riesgo independientemente, seleccionar la revisión de ventas y solo evaluar la
seguridad de dicha aplicación, sin estar obligado a examinar los demás riesgos.
TEMA 1: METODOLOGÍA PARA LA EVALUACIÓN DE APLICACIONES

La primera actividad que se debe efectuar es la selección de qué aplicación se
evaluará, para lo cual detallaremos ciertos lineamientos que apoyen en dicha
actividad.
1.1 SELECCIÓN DE LA APLICACIÓN PARA SER EVALUADA

Definamos qué es una aplicación, o también desde el punto de vista técnico,
sistema o módulo.
Según Murdick «el sistema es un conjunto de elementos organizados que se
encuentran en interacción, que busca alguna meta o metas comunes, operan-
do para ellos sobre datos o información sobre energía o materia u organismos
en una referencia temporal para producir como salida información energía o
materia u organismos» (Murdick, 2000: 33)
Un sistema informático es un sistema que permite almacenar y procesar

información; como todo sistema, es el conjunto de partes interrelaciona-
das: en este caso, hardware, software y personal informático. El hardware
incluye computadoras o cualquier tipo de dispositivo electrónico inteligen-
te, que consisten en procesadores, memoria, sistemas de almacenamiento
externo, etc. El software incluye al sistema operativo, firmware y aplica-
ciones, siendo especialmente importante los sistemas de gestión de bases
de datos. Por último, el soporte humano incluye al personal técnico que
crean y mantienen el sistema (analistas, programadores, operarios, etc.) y
a los usuarios que lo utilizan. (Wikipedia)
Sobre la base de lo indicado podemos detallar ciertos ejemplos de aplicaciones

como: banco, cuentas por cobrar, cuentas por pagar, inventario, nómina,
recursos humanos, producción, logística, entre otras.
En ciertos tipos de negocios existen aplicaciones puntuales, en el sector
bancario existen otras aplicaciones como cartera, depósitos monetarios,
entre otros. O también existen aplicaciones especializadas, como control
biométrico para el ingreso y salida del personal, control de GPS para equipos y
maquinarias, entre otras.
Ante lo indicado la primera actividad que se debe realizar es la selección de
la aplicación a revisar, para lo cual existen las siguientes opciones:
▪▪ Complemento o apoyo al trabajo del auditor: en la planificación

de auditoría revisar es un tema puntual; el auditor de sistemas
puede apoyar dicho trabajo revisando la aplicación relacionada
al tema. El auditor de sistemas puede complementar el trabajo
del auditor y revisar la aplicación de ventas o puntualmente el

proceso de facturación.
La intervención del auditor de sistemas al revisar la aplicación puede ayudar
a cambiar el enfoque de trabajo; con una confianza en los controles de la apli-
cación, el trabajo de auditoría estaría enfocado a pruebas de cumplimiento.
▪▪ Solicitud de la administración para la revisión de una aplicación

puntual: ejemplo, en la empresa terminaron de implementar el
proceso de facturación electrónica, por lo que el gerente general
solicitó que se revise la aplicación.
▪▪ Como parte de la planificación del auditor de sistemas, revisar
una aplicación critica dentro de la empresa.
Para los primeros dos casos no existen limitaciones; el auditor de sistemas

debe efectuar dichas revisiones.
En el tercer punto el auditor de sistemas tiene que definir qué aplicación
revisar, se recomienda que se elabore una matriz de riesgo para determinar
cuál aplicación es la más crítica en la empresa.
El objetivo del presente libro no está en explicar cómo se elabora una matriz
de riesgo, conocimiento que debe poseer el auditor. Cabe mencionar que lo
fundamental de la matriz de riesgo es la selección de los criterios.
La excepción se da cuando es el primer trabajo revisando aplicaciones como
auditor de sistemas; ante dicha situación es recomendable seleccionar la apli-
cación considerando los siguientes puntos:
▪▪ La aplicación que más tiene experiencia.

▪▪ La aplicación donde cuente con personal de la empresa que lo
apoye en su trabajo.
▪▪ Una aplicación sencilla.
1.2. METODOLOGÍA PARA LA EVALUACIÓN DE APLICACIONES

Utilizar una metodología sirve como guía de los pasos que se deben considerar
para efectuar un trabajo, y adicionalmente ayuda a estandarizar el mismo.
Para que la metodología sea aplicable debe tener ciertas características
como:
▪▪ Fácil de ejecutar.
▪▪ Aplicable a la mayoría de las situaciones, como tipo de negocios,
tamaño de la empresa, entre otros.
Ante lo indicado la propuesta metodológica para evaluar una aplicación está

enfocada en los riesgos existentes en la misma; se identifican cuáles existen
en una aplicación, luego se evalúa y se determina si los controles existentes
mitigan o disminuyen dichos riesgos.
Cabe indicar que el riesgo siempre va a existir, lo que hacen los controles
es minimizarlo, ante lo cual la propuesta metodológica para evaluar una
aplicación está enfocada en los siguientes cuatro riesgos:
Riesgo I- Acceso a funciones de procesamiento.

Personas no autorizadas pueden tener acceso a las funciones de procesa-
miento de transacciones de los programas de aplicación, permitiéndoles
leer, modificar, agregar o eliminar datos o ingresar transacciones no
autorizadas para su procesamiento.
Riesgo II- Ingreso de datos/información.

Los datos permanentes y de transacciones ingresados para el procesamien-
to pueden ser imprecisos, incompletos o ingresados más de una vez.
Riesgo III- Ítems rechazados/suspensos.

Los datos rechazados y las partidas en suspenso pueden no ser identifica-
das, analizadas y corregidas.
Riesgo IV- Procesamiento.

Las transacciones reales ingresadas para su procesamiento o generadas
por el sistema pueden perderse o ser procesadas o registradas de forma
incompleta, inexacta o en el periodo contable incorrecto.
Esta metodología para evaluar aplicaciones tiene ciertas características im-

portantes que se detallan:
▪▪ Puede ser utilizada en aplicaciones de todo tipo de empresa,

tanto comerciales, industriales, bancarias o de servicios.
▪▪ El tamaño de la empresa puede ser grande, mediana o pequeña.
▪▪ Cada riesgo puede ser evaluado de manera independiente, no
requiere que se evalúen los cuatros riesgos.
▪▪ Toda aplicación tiene los cuatros riesgos detallados (acceso–in-
greso–rechazo–proceso).
Como ejemplo de la metodología propuesta podemos indicar: un usuario in-

gresó a la aplicación de un banco y emitió un cheque por 10.000 dólares, según
esta premisa podríamos indicar:
Riesgo I- Acceso a funciones de procesamiento, el riesgo es que el cheque
pudo ser emitido por una persona no autorizada y este haber dado un mal uso
al mismo. La aplicación no tenía los niveles de seguridad adecuadamente de-
finidos, de manera que permitió efectuar dicha transacción por una persona
no autorizada.
Riesgo II- Ingreso de datos/información, en el momento de ingresar la
información, la aplicación no valida los datos ingresados y permite digitar un
nombre equivocado, lo que genera que dicho cheque sea anulado. Adicio-
nalmente, si el sistema no tiene controles en el ingreso, puede haber digitado
otro beneficiario para dicho cheque generándose un fraude en la empresa.
Riesgo III- Ítems rechazados/suspensos, este riesgo ocurre cuando en el
momento del ingreso no se cuenta con toda la información requerida por la
aplicación, por lo que el sistema la rechaza y no permite generar el cheque.
Riesgo IV- Procesamiento, en el momento que el sistema termina de
ingresar el cheque el usuario digita enter para grabar dicha transacción, in-
ternamente ocurren algunos procesos, como actualizar las tablas de bancos,
proveedores o cuentas por cobrar, contabilidad, entre otras. En cualquiera de
esos procesos la aplicación puede presentar inconvenientes operativos; es ahí
donde se genera el riesgo de procesamiento, y provoca que la información de
los diferentes módulos no será consistente.
TEMA 2: EVALUACIÓN DEL RIESGO I- ACCESO A FUNCIONES DE PROCESAMIENTO
2.1 INTRODUCCIÓN
De acuerdo a lo definido en las funciones del auditor de sistemas, la segunda
función es «Revisión de los riesgos existentes en las aplicaciones y sus contro-
les», y como lo indicamos anteriormente es una de las funciones principales
para un auditor de sistemas.
Igualmente, de acuerdo a lo indicado con respecto a la metodología utiliza-
da para evaluar una aplicación está enfocada en cuatro riesgos:
▪▪ Acceso a funciones de procesamiento

▪▪ Ingreso de la información
▪▪ Rechazo de la información
▪▪ Proceso de la información
En este tema vamos a revisar el primer: acceso a funciones de procesamiento,

donde se indica: «Personas no autorizadas pueden tener acceso a las funciones
de procesamiento de transacciones de los programas de aplicación, permi-
tiéndoles leer, modificar, agregar o eliminar datos o ingresar transacciones
no autorizadas para su procesamiento.»
En la aplicación de la metodología de evaluación del primer riesgo de una
aplicación, existen temas que deberían haberse cubierto por partes de uste-
des, detallamos los mismos:

▪▪ Conocimiento del Dpto. de Sistemas.
▪▪ Haber seleccionado que aplicación se va a revisar por medio de
una matriz de riesgo.
Estos puntos nos son obligatorios, pero el desarrollo de los mismos puede
contribuir a un mejor trabajo.
2.2. CONOCIMIENTOS TÉCNICOS REQUERIDOS PARA LA EVALUACIÓN DEL PRIMER RIESGO

Para una mayor comprensión de la metodología y obtención de mejores resul-
tados de la evaluación a efectuar, existen ciertos temas que son importantes y
se relacionan con dichos conceptos:
▪▪ En qué consiste un Módulo de seguridad en las aplicaciones,

cuál es su función y cómo opera.
▪▪ En que consiste un Perfil de usuario, para qué sirve y que infor-
mación registra.
▪▪ En qué consiste un ambiente de producción y desarrollo, quié-
nes lo usan y para qué.
▪▪ Funciones del Administrador de Seguridades.
▪▪ Funciones del Analista de Sistemas.
2.3. METODOLOGÍA PARA EVALUACIÓN DEL PRIMER RIESGO – ACCESO A FUNCIONES DE PROCESAMIENTO
EN LAS APLICACIONES
Una vez definida la aplicación, se debe evaluar el primer riesgo, para lo cual
se recomienda aplicar la metodología que se indicó para la primera reunión
con el responsable del Dpto. de Sistemas, y tener un conocimiento de dicho
departamento. Sin embargo, se han incluido actividades adicionales como so-
porte para la presente revisión. Este nuevo esquema metodológico se utilizará
en la evaluación de todos los riesgos, tanto de aplicaciones como del Dpto. de
Sistemas:
▪▪ Investigar sobre la aplicación o proceso crítico del negocio a

evaluar y sus riesgos.
▪▪ Solicitar información de la aplicación o proceso crítico del nego-
cio auditado.
▪▪ Definir el esquema de revisión.
▪▪ Preparar lista de preguntas y pruebas a efectuar como guía para
el trabajo a realizar.
▪▪ Primera reunión para revisar con los involucrados las revisiones
definidas.
▪▪ Revisar los resultados obtenidos.
▪▪ Segunda reunión para ampliar cualquier inquietud sobre las
revisiones efectuadas.
▪▪ Elaboración de informe.
A continuación, desarrollamos cada uno de los pasos detallados en la me-

todología propuesta para la evaluación del primer riesgo de acceso en una
aplicación:
1. Investigar: En base al riesgo, definir qué tipos de investigacio-

nes se podrían realizar con el objetivo de obtener información;
detallamos ciertas guías que podrían servir de ayuda para
dicho trabajo:
▪▪ Controles/seguridades sobre el acceso a las aplicaciones.

▪▪ Problemas/inconvenientes en el acceso a las aplicaciones.
▪▪ Fraudes/robos por debilidades en el acceso a las aplicacio-
nes.
▪▪ Responsable de las seguridades en las aplicaciones.
▪▪ Políticas de seguridades en las aplicaciones.
▪▪ Qué información se debe guardar en un perfil de usuario.
El leer sobre los temas indicados y otros ofrecerá una mayor visión e informa-
ción sobre el riesgo a evaluar, lo cual se verá reflejado en la información que
solicitarán (paso dos de la metodología) o en las preguntas o revisiones que se
realizarán (paso cuatro de la metodología).
2. Solicitar información dela aplicación o procesos críticos del

negocio auditado: se solicitará de la aplicación o proceso crítico
del negocio que se va a evaluar:
▪▪ Organigrama
▪▪ Manual de funciones del administrador de seguridades
▪▪ Manual de funciones del personal del área que se va a
revisar
▪▪ Políticas de seguridad
▪▪ Listado de personal
▪▪ Listados de usuarios
▪▪ Perfiles de usuarios (es un archivo - BD)
La información detallada se la solicitará a:
▪▪ Recursos Humanos: listado de personal.

▪▪ Recursos Humanos u Organización y Métodos: organigrama,
manual de funciones y políticas de seguridad.
▪▪ Administrador de seguridades: listado de usuarios y perfiles de
usuarios.
Cabe mencionar que como auditor la información debe cruzarse con dos usua-
rios diferentes para validar la misma, a excepción de los listados de usuarios y
perfiles de usuarios que son temas técnicos, y el Administrador de Seguridad
es el único que maneja dicho tema.
3. Cruzar la información investigada versus lo solicitado: Al efec-

tuar esta actividad encontraremos los siguientes escenarios:
▪▪ Información que la empresa tiene y no está detallado en lo

investigado.
▪▪ Información que está en lo investigado y la empresa no lo
tiene implementado.
▪▪ Información que se identificó en lo investigado y en la
empresa esta implementado.
En el primer caso, se debería preguntar:
▪▪ Por qué esta implementado.

▪▪ Cuál es el beneficio para el proceso crítico o para la aplicación.
▪▪ Qué riesgo mitiga.
En el segundo caso, se debería preguntar:

▪▪ Por qué el proceso crítico o la aplicación no cuenta con el mismo.

▪▪ Qué riesgo se crea.
▪▪ Cómo se mitiga dicho riesgo.
4. Definir el esquema de revisión: Los esquemas que existen para

la revisión del presente riesgo son:
▪▪ Revisión con el usuario en el ambiente de producción.

▪▪ Revisión con el usuario o el analista en el ambiente de
prueba.
▪▪ Análisis de datos.
Los tres esquemas son interesantes y tienen puntos positivos y negativos, más
adelante en la revisión de la «Primera reunión para revisar con los involucra-
dos las revisiones definidas» se amplía este tema.
5. Preparar lista de preguntas y pruebas a efectuar como guía

para el trabajo a realizar: De acuerdo a la información inves-
tigada, información entregada, cruce efectuado y el esquema
definido se debería elaborar la lista de preguntas y pruebas a
realizar.
Sobre los controles/seguridades investigadas y que la empresa no los tiene

implementados, preguntar:
▪▪ Por qué no se ha implementado.

▪▪ Que otro control compensa al mismo.
▪▪ Qué riesgo existe si no se tiene implementado dicho control.
Sobre los inconvenientes en el acceso a las aplicaciones investigadas y que no

fueron mencionados por el responsable del Dpto. de Sistemas dentro de la
información solicitada, preguntar:
▪▪ Para cada uno de ellos si se han presentado en la empresa.

▪▪ Frecuencia.
▪▪ Qué riesgo generaron.
▪▪ Qué controles existen para identificar oportunamente dichos
inconvenientes.
Para fraudes/robos, se efectuarían las mismas preguntas que el punto ante-

rior.
Con respecto a la información investigada sobre las políticas de seguridad
y funciones del responsable que no están detalladas en la información facili-
tada por el responsable del Dpto. de Sistemas:
▪▪ Por qué no están implementadas.

▪▪ Qué riesgo se genera por la falta de las mismas.
▪▪ Información guardada en el perfil de usuario: se revisaría
aquella información investigada y que la empresa no la está
registrando, preguntando:
▪▪ Por qué no se guarda dicha información.
▪▪ Qué limitaciones se tendría por no contar con la misma.
En base a la información entregada se podrían elaborar las siguientes pregun-

tas o pruebas:
Preguntas o pruebas relacionadas a usuarios operativos.
▪▪ Cruzar la información de los usuarios definidos en el sistema,

que estos estén en el listado del personal activo en la empresa.
▪▪ Seleccionar a los usuarios a quienes se les revisará que las opcio-
nes que tienen registradas en la aplicación estén relacionadas
con sus funciones.
Preguntas o pruebas relacionadas a políticas de seguridad.
▪▪ Seleccionar una muestra de las políticas de seguridad para

validar su cumplimiento.
▪▪ Preguntas o pruebas relacionadas a funciones.
▪▪ Verificar el cumplimiento de las funciones del Administrador
de Seguridad.
▪▪ Verificar si existe segregación de funciones en el personal del
área a revisar.
▪▪ Que otras funciones debería realizar el responsable de las se-
guridades para apoyar la gestión de control en las aplicaciones.
Preguntas o pruebas relacionadas a controles.
▪▪ Verificar y confirmar la información de los campos en la tabla

de los perfiles de usuarios (es un archivo-BD).
▪▪ Que información se debe guardar en un perfil de usuario.

▪▪ Que otros controles/seguridades se podrían aplicar para contro-
lar el acceso a las aplicaciones.
6. Primera reunión para revisar con los involucrados las revisio-
nes definidas.
De acuerdo al detalle de preguntas elaborado en el punto anterior se efectua-

rán las reuniones con los diferentes involucrados:
▪▪ Administrador de Seguridades.
▪▪ Responsable del Dpto. de Sistemas.
▪▪ Usuarios operativos.
Una vez concluida las reuniones, se efectuará una revisión operativa del nivel
de riesgo del acceso a las aplicaciones, lo cual dependerá del esquema de eva-
luación definido:
a. Revisión con el usuario: esta prueba se realizará en el ambiente

de producción, por lo que es limitado el alcance de las revisiones
realizadas, se recomienda:
▪▪ Probar las diferentes opciones que tiene acceso en el sis-

tema y verificar si las mismas son requeridas por dicho
usuario y si están detalladas en el manual de funciones.
▪▪ No forzar al usuario a realizar o procesar transacciones en
el sistema.
▪▪ No ingresar ninguna transacción.
b. Revisión en el ambiente de prueba: esta revisión la pueden reali-

zar con el propio usuario o con el analista de sistemas, y lo intere-
sante en este tipo de ambiente es que no existen limitaciones en
el alcance del trabajo a realizar.
De igual manera que en el punto anterior, se debería ingresar con el usuario y

ver las diferentes opciones que tiene acceso en la aplicación y verificar que las
mismas estén de acuerdo a sus funciones.
c. Análisis de datos: para esta revisión se solicitarán ciertas tablas

de los procesos críticos del negocio que se van a evaluar, y se analizará
la información de control registrada en las mismas, tales como:

usuario que ingresó, proceso que ejecutó, fecha y hora de ingreso
o de ejecución del proceso, punto de datos desde donde accedió,
entre otros.
TEMA 3: EVALUACIÓN DEL RIESGO II- INGRESO DE DATOS/INFORMACIÓN

EN LAS APLICACIONES
3.1. INTRODUCCIÓN
De acuerdo a lo definido en temas anteriores con respecto a la metodología uti-
lizada para evaluar una aplicación, la misma está enfocada en cuatro riesgos:

En este tema vamos a revisar el segundo riesgo «la información ingresada al

sistema puede ser incompleta, imprecisa o ingresada más de una vez (dupli-
cada)».
Para puntualizar el concepto de «incompleta», tomemos como ejemplo que
un usuario está ingresando una factura en la aplicación, si en dicho proceso
el usuario no ingresó el RUC y la aplicación le permitió grabar dicha infor-
mación, la información guardada en las diferentes tablas estará incompleta.
En este punto se vuelve crítico el riesgo, ya que la aplicación está desarrollada
para procesar una factura que tiene toda la información requerida para sus
procesos de manera completa, y en este caso no cuenta con el RUC; ante dicha
situación la aplicación va a emitir información inconsistente, por ejemplo,
puede ser que no cuadre la información de ventas con el detalle cartera y se
genere un reporte de venta y la aplicación no considere dicho movimiento,
entre otros.
Con respecto al concepto de «imprecisa», analicemos la misma situación
ingresando una factura, el personal de la empresa no anotó el código del pro-
ducto correcto, al grabarse la información en la aplicación, la misma se guar-
dará en las diferentes tablas, sin embargo, la información estará imprecisa, si
emito un listado de kárdex las cantidades reflejadas en el mismo no van a ser
reales, los stocks de ciertos productos no serán de información precisa.
Con respecto al concepto de ingresada más de una vez, en el último caso
el asistente de ventas estaba ingresando la factura y justo al terminar dicho
proceso, recibió una llamada telefónica, la atendió y al finalizar la misma

vuelve a darle enter en la aplicación, con lo que duplica la transacción.
Esta situación hace que se duplique la información registrada en las dife-
rentes tablas, es decir, las ventas van a estar sobrevaloradas, el inventario va
a estar de menos, la cuenta por cobrar estará reflejando valores mayores a los
reales.
Este es el riesgo que existe cuando uno ingresa información en cualquier
pantalla de una aplicación, por lo cual deberían contar con controles en el
ingreso de los datos de manera que minimicen dicho riesgo.
Entre los controles que podemos incluir tenemos:
▪▪ Controles de edición y validación:
●● Formato
●● Campos faltantes
●● Límites
●● Validación
●● Correlación de campos
●● Dígito verificador
●● Balanceo
●● Procesamiento duplicado
▪▪ Doble ingreso
●● Procesamiento por lote
▪▪ Control de edición y validación-formato: cuando se habla de

ingreso de información en una aplicación, esta puede tener los
siguientes formatos:
●● Numérico
●● Alfanumérico
●● Fecha
●● Booleano, tiene dos estados Si/No, Verdadero/Falso o 1/0.
Al efectuar la revisión del segundo riesgo en cualquier pantalla de una aplica-

ción, se evaluaría que en el ingreso de la información la misma cumpla con
los formatos establecidos, en caso contrario la aplicación debería enviarle un
mensaje al usuario indicándole el error y no debería permitirle continuar en
el ingreso de la información hasta que la misma sea corregida. Por ejemplo,
en el ingreso de la factura, el RUC debería ser numérico, la información in-

gresada en fecha debe tener un formato de fecha, las cantidades deberían ser
numéricas, entre otros.
Cualquier ingreso que no esté dentro del formato de cada campo, la aplica-
ción no permitirá su ingreso.
▪▪ Control de edición y validación-campos faltantes: este control

está enfocado a que el usuario esté obligado a ingresar una
información en los campos donde se han definido que son re-
queridos por la aplicación.
En el ingreso de una factura se debe evaluar qué campos son los que se ingresan
en la aplicación y de dichos campos determinar cuáles son requeridos; para
los mismos se valida que el sistema exija su ingreso al usuario, por ejemplo;
ruc, código del producto, cantidad, son campos mínimos requeridos en dicho
proceso.
Existe otras informaciones no necesariamente obligatorias, dependerá de
la empresa o de la situación propia de la transacción, tales como: dirección,
teléfono, ciudad, descripción, descuento, entre otros; los mismos no son
requeridos, es decir, el usuario, al ingresar una factura podría ingresar infor-
mación en los mismos o no, y el sistema le permitirá grabar dicho documento.
▪▪ Control de edición y validación-limites, este control consiste

en, al ingresar una información esta se valide de manera que
esté dentro de un rango definido por la empresa, por ejemplo:
cuando se digita el ruc de un cliente o proveedor, el límite es
que esté dentro de los 13 caracteres; si tiene más o menos, el
sistema no debería permitir continuar.
En el ingreso de la fecha de la factura, las buenas prácticas recomiendan que

dicho campo no sea ingresado por el usuario, sino que sea generado automá-
ticamente por el propio aplicativo; sin embargo, si en la empresa se ingresa la
fecha de la factura, se debería validar que la misma corresponda al presente
mes; ese sería el límite… ingresar una factura de un mes atrás o de meses
futuros generaría inconvenientes con el SRI, peor si corresponden a años
diferentes.
▪▪ Control de edición y validación-validación: es el principal con-

trol en el ingreso de la información en las aplicaciones; consiste
en que la información ingresada es validada con otra informa-
ción existente en las diferentes tablas de las aplicaciones, como

ejemplo, en el ingreso de los datos de una factura, el número
del RUC, se podría validar con la tabla de cliente para ver si está
registrado el mismo; en caso de ser un cliente nuevo podría va-
lidarlo con información del SRI para confirmar si dicho número
es válido.
De igual manera cuando ingreso el código de un producto podría validarlo con

la tabla de producto de la aplicación de inventario, para ver si es un código
valido. Al registrar la cantidad a facturar se podría validar con la tabla de
inventario la disponibilidad de dicho producto.
Adicionalmente, antes de facturar, podría validar si el cupo de crédito de
ese cliente le permite efectuar dicha compra o si está dentro de las políticas.
Este control es el más importante y el éxito es que sea realizado por el propio
aplicativo, de manera que garantice que siempre se realizará.
▪▪ Control de edición y validación-correlación de campos: es el

mismo enfoque de validación, pero efectuando dicho proceso
con los datos que se están ingresando en la pantalla en ese
momento, a diferencia del control de validación que se realiza
contra tablas de las aplicaciones. Por ejemplo, en el proceso de
facturación, si se detalla que se va a dar un descuento, la apli-
cación debería obligar a que se ingrese el valor o porcentaje de
descuento.
▪▪ Control de edición y validación – digito verificador: este control
aplica solo para el ingreso de números enteros. Es la utilización
de un algoritmo en el ingreso, de manera que al aplicar el mis-
mo se genera un número que es el digito verificador, el cual es
ubicado al final del número.
En caso de ingresar un número en la aplicación y que exista un error en dicho ingreso,

la aplicación al calcular el algoritmo no va a corresponder el digito verificador,
por lo que el aplicativo identificará que existe una falla en dicho ingreso. Por
ejemplo, este control se usa en las cédulas de identidad.
▪▪ Control de edición y validación-balanceo, este control es el

usado en el momento del ingreso de un asiento contable, donde
el total del débito debe de ser igual al total del crédito; si es así
dicho asiento esta balanceado y puede ser procesado.
De igual manera puede aplicarse dicho control en otros tipos de ingreso de

información.
Control de doble ingreso; corresponde que en el proceso del ingreso la infor-
mación es digitada dos veces, con lo que se valida que la misma sea correcta. Si
bien dicho control no es eficiente desde el punto de vista de productividad, es
muy eficiente cuando la información ingresada es crítica.
Un ejemplo típico es todo los aplicativos cuando le obligan a cambiar su
clave; la aplicación le solicita que digite dos veces su nueva clave, para validar
que sea la correcta. Es el mismo concepto que se puede aplicar en el ingreso de
cualquier dato crítico en una aplicación.
▪▪ Control de procesamiento por lote, es un control que se utiliza

poco, ya que las aplicaciones actuales todas son en línea.
3.2. CONOCIMIENTOS TÉCNICOS REQUERIDOS PARA LA EVALUACIÓN DEL SEGUNDO RIESGO

Para una mayor comprensión de la metodología y obtención de mejores
resultados de la evaluación, existen temas importantes para investigar y se
relacionan con dichos conceptos:
▪▪ Conocimiento de en qué consiste el ambiente de producción y

desarrollo.
▪▪ Investigar sobre ejemplos de controles de edición y validación.
▪▪ Diseño de pantallas de ingreso de datos en las aplicaciones.
Los puntos mencionados nos son obligatorios, pero el desarrollo de los mismos
puede contribuir en un mejor trabajo.
3.3. METODOLOGÍA PARA EVALUACIÓN DEL SEGUNDO RIESGO – INGRESO DE DATOS/INFORMACIÓN

EN LAS APLICACIONES
Una vez definida la aplicación y el proceso de ingreso de información que re-
visará, se recomienda aplicar la metodología utilizada para evaluar el primer
riesgo de acceso en las aplicaciones:

cio auditado.

definidas.
▪▪ Revisar informe con los involucrados.
▪▪ Entrega de informe final.
A continuación, desarrollamos cada uno de los pasos definidos en dicha me-

todología para poder evaluar el segundo riesgo de ingreso de la información:
Investigar: en base al riesgo «La información ingresada al sistema puede
ser incompleta, imprecisa o ingresada más de una vez (duplicada)» se debe
definir qué tipos de investigaciones se podrían realizar con el objetivo de
obtener información sobre los procesos críticos del negocio definidos para ser
evaluados, detallamos ciertas guías que podrían servir de ayuda para dicho
trabajo:
▪▪ Que tipos de modelos de procesos existen.

▪▪ Que políticas se pueden implementar en los procesos críticos
seleccionados.
▪▪ Las mejores prácticas que podrían ser aplicados en los procesos
críticos seleccionados.
▪▪ Responsable de las diferentes actividades en los procesos críticos.
▪▪ Controles (manuales o automatizados) que deberían constar en
dichos procesos críticos.
▪▪ Principales inconvenientes que se presentan en dichos procesos
críticos.
▪▪ Fraudes/robos que se han presentado en dichos procesos críticos.
▪▪ Fraudes/robos efectuados por ingreso de información no autori-
zados en las aplicaciones.
▪▪ Que archivos «logs» pueden activarse en los procesos críticos
que se están evaluando y que información se registra.
El leer sobre los temas indicados y otros se tendrá una mayor visión e informa-
ción sobre el riesgo a evaluar, lo cual se verá reflejado en la información que
solicitarán (paso dos de la metodología) o en las preguntas o revisiones que se
realizarán (paso cuatro de la metodología).
Solicitar información de la aplicación o proceso críticos del negocio audi-

tado: La siguiente información se solicitará de los procesos críticos a revisar:
▪▪ Procedimiento de los procesos críticos seleccionados.

▪▪ Controles implementados en el ingreso de la información.
▪▪ Manual de políticas de los procesos críticos seleccionados.
▪▪ Manual de funciones de los involucrados en los procesos críticos
definidos.
▪▪ Principales inconvenientes en los procesos definidos.
▪▪ Han existido fraudes/robo en los procesos críticos que se van a
evaluar.
▪▪ Que archivos logs están activos y que información se registra.
Esta información se la solicitará a:
▪▪ Recursos Humanos u Organización y Métodos: procedimiento,

políticas, controles y funciones.
▪▪ Usuarios u Organización y Métodos: procedimiento, políticas,
controles, funciones, principales inconvenientes y fraudes/
robos.
▪▪ Responsable del Dpto. de Sistemas: procedimiento, políticas,
controles, funciones, principales inconvenientes y fraudes/
robos, archivos «logs».
Esta información debe ser validada, la misma información debería ser pedida
a dos usuarios diferentes.
Cruzar la información investigada versus lo solicitado: Al efectuar dicha
actividad nos vamos a encontrar con los siguientes escenarios:
▪▪ Información que la empresa tiene y no está detallada en lo

investigado.
▪▪ Información que está en lo investigado y la empresa no lo tiene.
▪▪ Información que existe en lo investigado y en la empresa.
▪▪ En el primer caso, se debería preguntar:
▪▪ Por qué está implementado.
▪▪ Cuál es el beneficio para el proceso o para la aplicación.

▪▪ Por qué el proceso o la aplicación no cuenta con el mismo.

Definir el esquema de revisión: Los esquemas que existen para la revisión del
presente riesgo son:
▪▪ Revisión con el usuario en el ambiente de producción

▪▪ Revisión con el usuario o el analista en el ambiente de prueba
Preparar lista de preguntas y pruebas a efectuar como guía para el trabajo a

realizar: De acuerdo a la información investigada, información entregada,
cruce efectuado y el esquema definido se elabora la lista de preguntas y
pruebas a realizar; detallamos ciertos lineamientos para la elaboración de la
misma:
En base a la información investigada se podrían elaborar las siguientes
preguntas o pruebas:
▪▪ Sobre los controles (manuales/automatizados) en el ingreso de

la información investigados y que la empresa no los tiene im-
plementados, se debería preguntar:
▪▪ Qué otro control compensa al mismo.
Sobre los inconvenientes en el ingreso de la información a las aplicaciones

investigadas y que no fueron mencionados por el responsable del Dpto. de
Sistemas dentro de la información solicitada, preguntar:
▪▪ Si se han presentado en la empresa y con qué frecuencia.

▪▪ Qué riesgo generaron.
▪▪ Qué controles existen para identificar oportunamente dichos
inconvenientes.
Fraudes/robos, se efectuaría las mismas preguntas que el punto anterior.

Con respecto a la información investigada sobre las modelos de procesos,
políticas, mejores prácticas y los responsables de las funciones que no están
detalladas en la información entregada por el personal de OYM, responsable
del Dpto. de Sistemas y Usuario, le consultaría:

Sobre los archivos «logs» investigados que se pueden activar y que la empresa
no los tiene implementados, se debería preguntar:

En base a la información entregada se podrían elaborar las siguientes pregun-

tas o pruebas.
Preguntas o pruebas relacionadas a usuarios operativos:
▪▪ Verificar el cumplimiento de las diferentes actividades detalla-

das en los procesos críticos seleccionados.
▪▪ Revisión de la información registrada en los archivos «logs».
Preguntas o pruebas relacionadas a funciones:
▪▪ Verificar si existe segregación de funciones en las actividades

desarrolladas en los procesos críticos seleccionados.
Preguntas o pruebas relacionadas a controles:
▪▪ Validar los controles implementados en el ingreso de la infor-

mación.
▪▪ Validar las políticas definidas en el ingreso de la información.
▪▪ Que otros controles se podrían aplicar en ingreso de la informa-
ción
▪▪ Que comentarios podrían indicar sobre las funciones desa-
rrolladas de manera que apoyen la gestión de control en los
procesos.
▪▪ Que otros archivos logs pueden activarse como medio de control.
Primera reunión para revisar con los involucrados las revisiones definidas: De
acuerdo al detalle de preguntas elaborado en el punto anterior se efectuarán
las reuniones con los diferentes involucrados:
▪▪ Analista de Sistemas.
Las reuniones deben ser realizarse en dicho orden, primero con los usuarios
operativos y luego con el personal de sistemas (Analista de Sistemas).
Una vez concluida las reuniones se debe efectuar una revisión operativa del
proceso del ingreso de la información a las aplicaciones, para lo cual depende-
rá del esquema de evaluación definido:
Revisión con el usuario, esta prueba se realizará en el ambiente de produc-
ción, por lo que es limitado el alcance de las revisiones realizadas, por lo que
se recomienda:
a. Probar los diferentes controles (edición y validación –doble ingre-

so– procesamiento por lote) que se implementan en el ingreso de
la información en los procesos críticos seleccionados.
b. No forzar al usuario a realizar o procesar transacciones en el
sistema.
c. Como auditor de sistemas no deben ingresar ninguna transacción
en la aplicación.
Revisión en el ambiente de prueba: esta revisión la pueden realizar con el

propio usuario o con el analista de sistemas, y lo interesante en este tipo de
ambiente es que no existen limitaciones en el alcance del trabajo a realizar.
De igual manera que en el punto anterior se deben probar los diferentes
controles (edición y validación –doble ingreso– procesamiento por lote) que
aplican en el ingreso de los datos en los procesos críticos seleccionados.
▪▪ Análisis de datos: para dicha revisión se solicitarán ciertas

tablas y archivos logs de los procesos que se van a evaluar y se
analizará información registrada en las mismas, consideran-
do:
●● Verificar si existe información inconsistente, lo cual podría
indicar que no existen controles en el ingreso de la informa-
ción en las aplicaciones.
TEMA 4: EVALUACIÓN DEL RIESGO III: RECHAZO/SUSPENSO DE LA INFORMACIÓN

EN LAS APLICACIONES
4.1. INTRODUCCIÓN
En este tema se darán los lineamientos que se deben considerar para efectuar
una revisión del siguiente riesgo que se presentan en las aplicaciones, que es el
rechazo. De acuerdo a lo definido en temas anteriores con respecto a la meto-
dología utilizada para evaluar una aplicación está enfocada en cuatro riesgos:

Cuando se evalúa este riesgo no interesa identificar o evaluar las situaciones

que generan el rechazo, el objetivo es enfocarnos a identificar qué controles
existen con la información que fue rechazada. Las situaciones que podrían
generar un rechazo en las aplicaciones podrían ser:
▪▪ Falta de información en el momento del ingreso.

▪▪ Inconsistencia en la información ingresada en la aplicación,
validada por los controles implementados en el aplicativo.
▪▪ Inconvenientes en los programas de la aplicación utilizados.
En el momento del ingreso de la información, si es rechazada, las aplicaciones

pueden actuar de dos maneras:
Rechazo/suspenso total de la información, la aplicación no permite
continuar con el proceso hasta que se regularicen los temas que generan el
rechazo y el aplicativo no guarda ningún tipo de información ni registro de
lo rechazado.
▪▪ Todos los controles deberían estar enfocados de manera ma-

nual.
Rechazo/suspenso con registro de la información, si bien la información no se

guardará en las tablas de producción, si quedan registros guardados en tablas
de trabajo.
▪▪ Los controles que se pueden implementar son manuales y con-

troles automatizados.
Una vez detallado los temas mencionados definimos como riesgo de rechazo:
a la información perdida y no procesada en la aplicación, por lo cual el esquema ideal desde el punto de vista de control es el
manejo del rechazo con registro de la información.
Pero solo el hecho de que se registre en tablas de trabajo la información
rechazada no minimiza el riesgo, por lo cual es fundamental que el aplicativo
tenga medios de control (reportes, alarmas) de manera que se identifique de
manera oportuna estos registros que están en los archivos de trabajo y solucio-
narlos para que actualicen a las tablas de producción.
4.2. CONOCIMIENTOS TÉCNICOS REQUERIDOS PARA LA EVALUACIÓN DEL TERCER RIESGO

tados de la evaluación a efectuar, existen ciertos temas que son importantes
investigar y se relacionen con dichos conceptos:
▪▪ Conocimiento en qué consiste una tabla de producción.

▪▪ Conocimiento en qué consiste una tabla de trabajo.
4.3. METODOLOGÍA PARA EVALUACIÓN DEL TERCER RIESGO – RECHAZO/SUSPENSODE LA INFORMACIÓN

EN LAS APLICACIONES
Una vez definida la aplicación y el proceso crítico del negocio que se va a re-
visar, se recomienda aplicar la metodología utilizada para evaluar el primer

cio auditado.
definidas.
A continuación, desarrollamos cada uno de los pasos definidos en dicha

metodología para poder evaluar el tercer riesgo de rechazo/suspenso de la
información en las aplicaciones:
Investigar: En base al riesgo «que la información ingresada al sistema pue-
de ser rechazada» se debería definir qué tipos de investigaciones se podrían
realizar con el objetivo de obtener información sobre los procesos críticos del
negocio definidos para ser evaluados; detallamos ciertas guías que podrían
servir de ayuda para dicho trabajo:
▪▪ Detalle de los diferentes ingresos que se presentan en los proce-

sos críticos seleccionados.
▪▪ Políticas implementadas en el ingreso de la información en los
procesos críticos seleccionados.
▪▪ Responsable de los ingresos de los procesos críticos selecciona-
dos.
Leer sobre los temas indicados y otros dará una mayor visión e información so-
bre el riesgo a evaluar, lo cual se verá reflejado en la información que solicitada
(paso dos de la metodología) o en las preguntas o revisiones que se realizarán
(paso cuatro de la metodología).
Solicitar información de la aplicación o proceso crítico del negocio audita-
do: La siguiente información se solicitará de los procesos críticos del negocio a
ser revisados, detallamos:
▪▪ Procedimiento de los procesos críticos del negocio seleccionados

▪▪ Manual de políticas de los procesos críticos del negocio seleccio-
nados.
definidos.

políticas y funciones.
▪▪ Usuarios Métodos: procedimiento, políticas, funciones, princi-
pales inconvenientes y fraudes/robos.
▪▪ Responsable del Dpto. de Sistemas: procedimiento, políticas,
funciones, principales inconvenientes y fraudes/robos.
Cabe mencionar que la información debe ser validada, es decir, la misma

información debería ser pedida a dos usuarios diferentes.
Cruzar la información investigada versus lo solicitado: Al efectuar dicha

investigado.
▪▪ Por qué está implementado.
▪▪ En el segundo caso, se debería preguntar:


cruce efectuado y el esquema definido, se debería elaborar la lista de pregun-
tas y pruebas a realizar, las cuales van a estar enfocadas a:
▪▪ Donde existe un ingreso existe la posibilidad de un rechazo, por

lo que se debería indicar como la aplicación actúa en caso de un
rechazo:
a. Rechazo total de la información

b. Rechazo con registro de la información.
Para cada uno de los casos se debe preguntar que controles se tienen imple-
mentados y pedir evidencia para confirmar el cumplimiento de los mismos.
Entre los controles para los rechazos totales de la información tenemos:
▪▪ Mantener una bitácora de manera manual de la información

que fue rechazada.
Para los rechazos con registros de la información tenemos:
▪▪ Reportes y consultas que le permitan al usuario conocer que

información esta con estatus de rechazo.
▪▪ Alarmas automatizadas, tales como el envío de un mail al
usuario, jefe inmediato o involucrado con la información que
está con estatus de rechazo/suspenso y desde qué fecha se en-
cuentra con dicho status.
las reuniones con los diferentes involucrados:
Las reuniones deberían ser realizadas en dicho orden, primero con los usuarios
y luego con el personal de sistemas (Analista de sistemas). En las reuniones se
debe efectuar una revisión operativa del nivel de riesgo del rechazo de la infor-
mación a las aplicaciones, para lo cual dependerá del esquema de evaluación
definido.
TEMA 5: EVALUACIÓN DEL RIESGO 4: PROCESO DE LA INFORMACIÓN EN LAS APLICACIONES
5.1. INTRODUCCIÓN
En este tema se darán los lineamientos que se deben considerar para la
revisión del siguiente riesgo que se presentan en las aplicaciones, que es el
procesamiento de la información. Cuando se evalúa este riesgo no interesa
identificar los temas o razones que generan los inconvenientes en el proceso
crítico de negocio evaluado, el objetivo es evaluar qué controles existen para
identificar oportunamente dichos inconvenientes.
Las situaciones que podrían generar inconvenientes en el proceso crítico
del negocio podrían ser, entre otras:
▪▪ Fallas en el diseño y programación de las aplicaciones.

▪▪ Inconvenientes en el hardware.
▪▪ Elementos externos que interfieran en el procesamiento de la

información.
▪▪ En el momento que se presenta un inconveniente en el proceso
crítico del negocio con la información pueden ocurrir dos situa-
ciones:
▪▪ Que el sistema de una alarma sobre el inconveniente presenta-
do en el proceso.
▪▪ Que el sistema no emita una alarma.
En las situaciones indicadas, la manera de cómo va manejar internamente el

sistema ante dicha situación es totalmente incierta, por lo que este es el riesgo
más difícil de identificar y evaluar, pero con la ayuda de la metodología que
vamos a revisar les facilitará su evaluación.
Conocimientos técnicos requeridos para la evaluación del cuarto riesgo: Es
fundamental que el auditor tenga un amplio conocimiento del proceso crítico
de la empresa que va auditar. Adicionalmente deberían investigar cómo opera
internamente un sistema de computación en el manejo de la información.
5.2. METODOLOGÍA PARA EVALUACIÓN DEL CUARTO RIESGO: PROCESO DE LA INFORMACIÓN EN LAS APLICACIONES
Una vez definida la aplicación y el proceso crítico de la empresa que se va a
revisar, se recomienda aplicar la metodología utilizada para evaluar el primer
▪▪ Investigar sobre la aplicación o proceso crítico de la empresa a

▪▪ Solicitar información de la aplicación o proceso crítico de la
empresa auditada.
definidas.
A continuación, desarrollamos cada uno de los pasos definidos en dicha

metodología para poder evaluar el cuarto riesgo de procesamiento de la infor-
mación en las aplicaciones:
Investigar: Este riesgo está relacionado con un proceso crítico dentro de la
empresa, por lo que ustedes deberían investigar sobre el mismo, consideran-
do:
▪▪ Revisar que políticas se pueden implementar en dicho proceso

crítico.
▪▪ Revisar procedimientos típicos sobre el proceso crítico seleccio-
nado.
▪▪ Que riesgos pueden presentarse en el proceso crítico a evaluar.
▪▪ Que controles existen para minimizar estos riesgos.
▪▪ Fraudes/robos efectuados por ejecución de procesos no autoriza-
dos en las aplicaciones.
Solicitar información del proceso crítico del negocio auditado: La siguiente

información es la que se solicitará de los procesos críticos del negocio a revisar,
detallamos:
▪▪ Procedimiento de los procesos críticos seleccionados

▪▪ Manual de políticas de los procesos críticos seleccionados
definidos.

políticas y funciones.
▪▪ Usuarios Métodos: procedimiento, políticas, funciones, princi-
pales inconvenientes y fraudes/robos.
Responsable del Dpto. de Sistemas: procedimiento, políticas, funciones, prin-

cipales inconvenientes y fraudes/robos.
La información debe ser validada, debe pedirse a dos usuarios diferentes.
Cruzar la información investigada versus solicitada: Al efectuar dicha

investigado.

▪▪ Por qué esta implementado.



cruce efectuado y el esquema definido se debería de elaborar la lista de pre-
guntas y pruebas a realizar, considerando:
▪▪ Se debe preguntar qué controles se tienen implementados y pe-

dir evidencia para confirmar el cumplimiento de los mismos,
estos controles pueden ser manuales o automatizados.
▪▪ Qué reportes y consultas existen que le permitan al usuario
poder identificar los inconvenientes presentados en el proceso
de la información.
▪▪ Existen alarmas automatizadas, que nos informe inconsisten-
cias en el proceso de la información.
las reuniones con los diferentes involucrados, detallamos:
En las reuniones se debe efectuar una revisión operativa del nivel de riesgo del
proceso en las aplicaciones considerando los siguientes esquemas de revisión:
▪▪ Revisión del proceso crítico del negocio a revisar y donde sea

factible efectuar pruebas de lo revisado.
▪▪ Mantener una reunión en base a la lista de preguntas y pruebas
definidas.
▪▪ Preguntarles a los usuarios con los que nos estamos reuniendo:
▪▪ Qué inconvenientes operativos han tenido en la ejecución del
proceso crítico del negocio en revisión.
▪▪ La frecuencia de los inconvenientes.
▪▪ Cómo fueron solucionados.
▪▪ Qué mejoras ustedes consideran que podrían aplicarse en dicho
proceso.
▪▪ Qué riesgos ustedes consideran que existen en dicho proceso.
ACTIVIDADES
Actividad 1:
Para la selección de una aplicación para ser evaluada se propone en el pre-
sente material la elaboración de una matriz de riesgo, ante lo cual se solicita:
▪▪ Detalle qué elementos o criterios pueden utilizarse para la ela-

boración de una matriz de riesgo.
▪▪ Seleccione una empresa y aplique la matriz de riesgo propuesta
por ustedes con los cinco principales criterios definidos.
El objetivo de esta actividad es que ustedes comiencen a aplicar metodologías

para los procesos de selección, lo cual profesionaliza su trabajo y lo vuelve
auditable.
tema 1.1: Selección de la aplicación para ser evaluada.
Actividad 2:
En base al material detallado con respecto a la metodología para la evalua-
ción del «Riesgo I - Acceso a funciones de procesamiento», efectuar un análisis
y evaluación de la misma, considerando los siguientes lineamientos:
▪▪ Dudas e inquietudes de la información detallada en el material.

▪▪ En el detalle de las actividades que se debe realizar para poder
cumplir las funciones detalladas, qué otras actividades se po-
drían incluir.
▪▪ Que limitaciones se pueden presentar al realizar las actividades
Cada duda o inquietud que se le presente, deberían investigar y ampliar sobre

el tema, lo cual les dará un mayor conocimiento que les permitirá desempe-
ñarse de mejor forma en el momento de la evaluación del riesgo. El objetivo de
esta actividad es analizar, evaluar y cuestionar la metodología propuesta, lo
cual les permitirá identificarse con la misma, y adaptarla a ciertas condicio-
nes propias, como son: su nivel de conocimiento, el enfoque de auditoría que
desea aplicar y de ciertas características propias del negocio.
tema 2: Evaluación del Riesgo I: Acceso a funciones de procesamiento.
En base a la información detallada sobre «Evaluación del Riesgo II: Ingreso
de datos/información en las aplicaciones», realice todas las actividades deta-
lladas en dicha metodología con las siguientes consideraciones:
▪▪ Seleccione una empresa real, preferiblemente mediana.

▪▪ Efectúe cada una de las actividades detalladas en la metodolo-
gía.
▪▪ Documente y soporte cada actividad.
El objetivo de esta actividad es que ustedes apliquen los conocimientos revisa-

dos en este libro
tema3: Evaluación del Riesgo II: Ingreso de datos/información en las aplica-
ciones.
RESUMEN
La «Revisión de los riesgos existentes en las aplicaciones y sus controles», es
una de las funciones principales para un auditor de sistemas.
De acuerdo a lo indicado con respecto a la metodología utilizada para eva-
luar una aplicación está enfocada en cuatro riesgos:
Riesgo I: Acceso a funciones de procesamiento, personas no autorizadas
pueden tener acceso a las funciones de procesamiento de transacciones de los
programas de aplicación, permitiéndoles leer, modificar, agregar o eliminar
datos o ingresar transacciones no autorizadas para su procesamiento.
Riesgo II: Ingreso de datos/información, la información ingresada al siste-
ma puede ser incompleta, imprecisa o ingresada más de una vez (duplicada).
Riesgo III: Ítems rechazados/suspensos, al momento de ingresar la infor-
mación al sistema, este la puede rechazar por diferentes situaciones.
Riesgo IV: Procesamiento, el momento de procesar la información en el
sistema, este presente inconvenientes.
En esencia, para efectuar una auditoría de sistemas a una aplicación la
primera actividad que se debe realizar es la selección de las mismas, para lo
cual existen las siguientes opciones que podrían ser consideradas:
▪▪ Como un complemento o apoyo al trabajo del Auditor.

▪▪ Solicitud de la administración para dicha revisión.
▪▪ Como parte de la planificación del auditor de sistemas en revi-
sar una aplicación critica dentro de la empresa.
Para los primeros dos casos no existen limitaciones, el auditor de sistemas

debería efectuar dichas revisiones.
Para el último caso donde el auditor de sistemas tiene que definir qué
aplicación debe revisar, se recomienda que se elabore una matriz de riesgo
para determinar cuál aplicación es la más crítica en la empresa, la misma que
debería ser evaluada.
MAPA CONCEPTUAL
Evaluación de Aplicaciones
PARTE II
IV. EVALUACIÓN DEL DEPARTAMENTO
DE SISTEMAS
EVALUACIÓN DEL DEPARTAMENTO DE SISTEMAS
INTRODUCCIÓN
Este capítulo trata los lineamientos que se deben considerar para una revi-
sión del Departamento de Sistemas en las empresas, como se indicó en el
capítulo 2, Tema 3 (Priorización de las funciones), al indicar que una de las
funciones principales que debe realizar un auditor de sistemas es la evalua-
ción de los principales riesgos en un Dpto. de Sistemas.
Lo primero que se debe identificar son las áreas existentes en un Dpto. de
Sistemas, adicionalmente se debería evaluar qué temas son de interés para un
auditor de sistemas; en base a dicha información se podría determinar cuáles
son los mayores riesgos que deben revisarse por el auditor de sistemas en dicho
departamento.
Existen muchos elementos que podrían ser de interés desde el punto de
vista de un auditor de sistemas, por lo que es fundamental en una evaluación
contar con una metodología que guíe dicho proceso, que consiste en cuatro
riesgos:
▪▪ Riesgo I: Políticas y procedimientos del Dpto. de Sistemas.

▪▪ Riesgo II: Acceso físico y lógico a elementos críticos del Dpto. de
Sistemas.
▪▪ Riesgo III: Riesgos operativos y de gestión críticos del Dpto. de
Sistemas.
▪▪ Riesgo IV: Estructura del Dpto. de Sistemas.
Lo interesante de esta metodología propuesta es que es fácil de utilizar y es

aplicable para todo tipo de negocio, por ejemplo, la misma metodología la
puedo aplicar en empresas comerciales, industriales, bancarias o de servicios.
Adicionalmente, no importa el tamaño de la empresa, puede ser grande,
mediana o pequeña.
En conclusión, la metodología propuesta es flexible, pues permite evaluar

cada riesgo independientemente, es decir podría seleccionar, revisar las polí-
ticas y procedimientos del Dpto. de Sistemas, o revisar los riesgos operativos
y de gestión críticos en el Dpto. de Sistemas. Cada riesgo se puede evaluar de
manera independiente.
TEMA 1: METODOLOGÍA PARA LA EVALUACIÓN DE UN DPTO. DE SISTEMAS
1.1. CONCEPTOS BÁSICOS

Para la evaluación de un Dpto. de Sistemas existen varios conceptos, los más
importantes son:
▪▪ Que áreas existen en un Dpto. de Sistemas, considerando los

siguientes temas:
a. Cuáles son los objetivos de cada una de las áreas.

b. Cuáles son los principales riesgos que están expuestas las
mismas.
c. Principales cambios significativos que se han presentado en
los últimos dos años para cada una de ellas.
d. Principales inconvenientes y cuáles son las consecuencias
de los mismos en el último año para cada una de ellas.
▪▪ Estructura de un Dpto. de Sistemas con sus principales funcio-

nes del personal.
▪▪ Principales procesos críticos en un Dpto. de Sistemas, conside-
rando los siguientes temas:
a. Cuáles son los objetivos de dichos procesos críticos.

b. Que riesgos están expuestos los mismos.
▪▪ Principales cambios significativos que se han presentado en los

últimos dos años para cada una de ellos.
▪▪ Principales inconvenientes y cuáles son las consecuencias de
los mismos en el último año para cada una de ellos.
▪▪ Principales elementos críticos en un Dpto. de Sistemas, consi-
derando:
a. Como apoyan dichos elementos críticos en el negocio.

b. Que riesgos están expuestos los mismos.
c. Que pasa para el negocio si los mismos fallan o dejan de operar.
d. Principales cambios significativos que se han presentado en los
últimos dos años para cada una de ellos.
e. Principales inconvenientes y cuáles son las consecuencias de los
mismos en el último año para cada una de ellas.
Áreas físicas que existen en un Dpto. de Sistemas: En un Dpto. de Sistemas

generalmente existen cinco áreas, las mismas pueden encontrarse bien
definidas o no en la empresa, o podrían estar manejadas por terceros. En
conclusión, el número de áreas y como estén agrupadas o que funciones
desempeñen, va a depender de la manera de administrar al departamento de
Sistemas; detallamos las áreas que generalmente encontramos:
▪▪ Área administrativa, donde se encuentra la Recepcionista, la

Asistente del responsable del Dpto. de Sistemas y es donde se
atiende al personal ajeno al Dpto. de Sistemas.
▪▪ Área de desarrollo, en esta área se encuentra el personal de-
dicado al desarrollo y cambios en las aplicaciones; es un área
restringida, ya que la información que maneja es sensitiva para
el negocio. En general el personal de esta área soporta todo lo
que corresponde a las aplicaciones en la empresa.
▪▪ Área técnica, esta es un área restringida, es donde se encuentra
el personal que da soporte a todo lo que corresponde al hard-
ware, redes y equipos de comunicaciones.
▪▪ Área de servidores, es el área más restringida del Dpto. de
Sistemas, es donde están ubicados físicamente los equipos ser-
vidores, equipos de comunicaciones y podría estar los equipos
de soporte en caso de falta de energía (UPS).
▪▪ Área operativa, en esta área se incluye al personal que realizan
actividades que soportan la gestión y administración de las
aplicaciones, tales como: responsable de los respaldos de la
información, administrador de base de datos, administrador
de seguridades, organización y métodos, auditor de sistemas,
control de calidad, entre otros.
ESTRUCTURA DE UN DPTO. DE SISTEMAS CON SUS PRINCIPALES FUNCIONES

El conocer de la estructura del Dpto. de Sistemas y sus funciones nos da la
información que nos ayudará al solicitar información de manera coordinada,
o definir con quien nos debemos reunir como parte de los trabajos de auditoría
de sistemas que se han planificado realizar en dicho departamento. Este pun-

to será desarrollo más adelante en el tema cinco del presente capítulo.
PRINCIPALES PROCESOS CRÍTICOS EN UN DPTO. DE SISTEMAS

El Dpto. de Sistemas es un área de servicio que debe de soportar a la empresa,
por lo que es fundamental el tener identificado los procesos críticos existente
en el Dpto. de Sistemas y como estos soportan a la gestión y operación de la
empresa, lo cual permitirá contar con información para definir los trabajos de
auditoría de sistemas que podrían realizarse; enfocándose a los que tengan un
mayor impacto en el negocio.
Es decir, por ejemplo, el proceso de respaldo es crítico ya que me va a servir
como contingencia ante cualquier inconveniente en la información o en la
infraestructura tecnológica de la empresa; entonces al revisar dicho proceso
y verificar su correcto funcionamiento, ustedes podrían concluir que existe
un nivel de confianza que garantiza la continuidad del negocio ante ciertos
niveles de contingencias en la operación de los sistemas.
En esencia, es fundamental investigar cuáles son los procesos críticos para
que ustedes puedan evaluar a los mismos, como guía detallamos los principa-
les procesos críticos de un Dpto. de Sistemas:
▪▪ Desarrollo/modificación de las aplicaciones (cambios a progra-

mas).
▪▪ Documentación de los desarrollos y modificaciones efectuadas
a las aplicaciones y configuraciones de los sistemas.
▪▪ Respaldo de la información.
▪▪ Administración de las bases de datos.
▪▪ Cambios directos a las bases de datos.
▪▪ Administración de las seguridades.
▪▪ Mantenimiento de servidores y equipos de comunicaciones.
▪▪ Administración de los proyectos tecnológicos.
▪▪ Administración de consultorías externas.
PRINCIPALES ELEMENTOS CRÍTICOS EN UN DPTO. DE SISTEMAS

El conocer cuáles son los elementos críticos del Dpto. de Sistemas les ayudaría
a ustedes a planificar una auditoría de sistemas al evaluar cómo estos ele-
mentos críticos del departamento de Sistemas podrían generar riesgos en el
negocio.
Sin embargo, cuando se menciona elementos críticos del departamento de
sistemas se está referenciando a equipos e infraestructuras tecnológicas, lo
cual podría limitar su revisión dependiendo del perfil profesional de cada uno
de ustedes.
Ante lo indicado, si el perfil de del auditor podrían tener limitaciones en
el desarrollo de las revisiones de estos elementos críticos, las cuales no van
a estar enfocadas en evaluar temas técnicos, como si dichos equipos están
dimensionados adecuadamente a la infraestructura de la empresa o si están
obsoletos, entre otros; lo que si van a poder efectuar son revisiones enfocándo-
las con su perfil profesional, que les van a permitir evaluar otros riesgos con
dichos equipos e infraestructuras tecnológicas, tales como: están asegurados,
existe una contingencia con los mismos, existe un contrato de mantenimien-
to, entre otros temas.
Entre los elementos críticos de un departamento de sistemas podemos
detallar:
▪▪ Equipos servidores
▪▪ Equipos de comunicaciones (switch, routers, antenas)
▪▪ Equipos de seguridad (firewall)
▪▪ Equipos de respaldos
▪▪ Equipos UPS
1.2. METODOLOGÍA DE EVALUACIÓN DE UN DPTO. DE SISTEMAS

Una metodología ayuda en cualquier trabajo como guía de los pasos que deben
realizarse, adicionalmente estandariza el mismo.
Pero para que la metodología sea aplicable debería tener ciertas caracterís-
ticas como son:
▪▪ Fácil de ejecutar.
▪▪ Aplicable a diferente tipo de situaciones, como son: tipo de
negocios, tamaño de la empresa, entre otros.
▪▪ Que integre el conocimiento de múltiples áreas y la experiencia.
Ante lo indicado la propuesta metodológica para evaluar un Dpto. de Sistemas

está enfocada en cuatro riesgos que están presentes en dicho departamento,
para lo cual habrá que evaluarlos y determinar si los controles existentes mi-
tigan dichos riesgos.
A diferencia de la metodología revisada para evaluar una aplicación, donde
se definían puntualmente los riesgos existentes, para el caso de la evalua-
ción del Dpto. de Sistemas se detallan temas que ustedes deberían evaluar,
ya que deficiencias en los mismos generan riesgo en la operación y gestión
de la empresa. Ante lo indicado, la metodología propuesta consta de cuatro te-

mas que de igual manera se los definirá como riesgos, detallamos los mismos:
Riesgo I-Políticas y procedimientos del Dpto. de Sistemas: El Dpto. de Sistemas sus procesos no
estén normados por políticas y procedimientos.
Riesgo II-Acceso físico y lógico a elementos críticos del Dpto. de Sistemas: Personal no autorizado pueda
ingresar de manera física o lógica a elementos críticos del Dpto. de Sistemas
sin la debida autorización.
Riesgo III-Riesgos operativos y de gestión críticos del Dpto. de Sistemas: La empresa no cuente con un
plan de contingencia para los riesgos más críticos y factibles en el departa-
mento de sistemas que puedan afectar la continuidad del negocio.
Riesgo IV-Estructura del Dpto. de Sistemas: La estructura del Dpto. de Sistemas podría no
soportar una segregación de funciones en su personal, y adicionalmente no
existan controles para mitigar la falta de dicha segregación.
Esta metodología para evaluar un Dpto. de Sistemas tiene ciertas caracte-
rísticas importantes que se detallan:
▪▪ Puede ser aplicada en empresas, tanto comerciales, industria-

les, bancarias o de servicios.
▪▪ El tamaño de la empresa puede ser grande, mediana o pequeña.
▪▪ Cada riesgo puede ser evaluado de manera independiente, no
requiere que se evalúen los cuatros riesgos.
TEMA 2: EVALUACIÓN DEL RIESGO I-POLÍTICAS Y PROCEDIMIENTOS

DEL DPTO. DE SISTEMAS
2.1. INTRODUCCIÓN
De acuerdo a lo definido en las funciones del auditor de sistemas, la tercera
función es «Revisión de los riesgos del Dpto. de Sistemas y sus controles», y
como lo indicamos anteriormente es una de las funciones principales para un
Igualmente, de acuerdo a lo indicado con respecto a la metodología utiliza-
da para evaluar al Dpto. de Sistemas está enfocado en cuatro riesgos:
▪▪ Políticas y procedimientos del Dpto. de Sistemas.

▪▪ Acceso físico y lógico a elementos críticos del Dpto. de Sistemas.
▪▪ Principales contingencias en el Dpto. de Sistemas.
▪▪ Estructura del Dpto. de Sistemas.
Es importante el recordar que cada uno de los riesgos puede ser evaluado de
manera independiente, no se requiere mantener un orden en su evaluación,
la decisión dependerá de ustedes como auditores cual consideren que les gene-
ra mayor riesgo para la empresa.
Otra variable que debería ser considerada en la evaluación de estos riesgos
técnicos del Dpto. de Sistemas, es con cuál ustedes se sienten más cómodo en
su evaluación, lo que los fortalecerá y motivara para que efectúen revisiones
en dicho departamento.
Con respecto al primer riesgo podríamos indicar que las áreas o departa-
mentos críticos en las empresas deben ser auditados con mayor frecuencia, y
sus procesos deberían estar controlados, y unos de los elementos fundamen-
tales de control desde el punto de vista de la auditoría es que existan políticas
y procedimientos que normen dichos procesos.
El Dpto. de Sistemas es un área crítica en la empresa, por lo que podemos
concluir que todos sus procesos deberían estar normados con políticas y proce-
dimientos formalizados en un documento físico o digital.
Pero la evaluación de dichas políticas y procedimientos del Dpto. de Sis-
temas es un tema que podría requerir de mayores conocimientos técnicos
de parte del auditor, ya que los mismos van a referirse a temas operativos y
de gestión muy propia del área de Sistemas, lo cual podría considerarse una
limitación para efectuar dicho trabajo.
Sin embargo, la metodología propuesta está enfocada a que el auditor
valide que existan dichas políticas y procedimientos y que las mismas sean
conocidas en el personal involucrado en el proceso, verificar el cumplimiento
de las mismas y ratificar que estén actualizadas, entre otros puntos, temas
que un auditor tiene una amplia experiencia.
Pero la realidad es que el auditor, revisa y evalúa políticas y procedimientos
de todas las áreas de la empresa, a excepción del área de Sistemas, entonces
nos deberíamos preguntar, ¿por qué no se evalúa las políticas y procedimien-
tos del Dpto. de Sistemas?, mi apreciación es que simplemente el auditor tiene
miedo de ingresar al área de Sistemas.
Por lo indicado, se recomienda que este riesgo sea evaluado como una de
las primeras actividades que ustedes efectúen como auditor de sistemas, ya
que le va a permitir ingresar realizar trabajos en el área de sistemas en un
tema que ustedes dominan como auditores, que es validar el cumplimiento de
las políticas y procedimientos. El efectuar esta actividad le va a dar seguridad
para futuros trabajos de auditoría de sistemas.
2.2. CONOCIMIENTOS TÉCNICOS REQUERIDOS PARA LA EVALUACIÓN DEL PRIMER RIESGO, POLÍTICAS
Y PROCEDIMIENTOS DEL DPTO. DE SISTEMAS
Para la evaluación delas políticas y procedimientos del Dpto. de Sistemas es
importante que ustedes conozcan e investiguen la siguiente información:
▪▪ Conocer físicamente un Dpto. de Sistemas.

▪▪ Investigar sobres las principales funciones de un Dpto. de Sistemas.
▪▪ Investigar lo que corresponde a ambiente de producción y am-
biente de desarrollo o prueba.
▪▪ Cuáles son los principales equipos en un Dpto. de Sistemas.
▪▪ Que es una base de datos.
▪▪ En que consiste el procedimiento de respaldo de información.
2.3. METODOLOGÍA PARA EVALUACIÓN DEL PRIMER RIESGO, POLÍTICAS Y PROCEDIMIENTOS

La metodología propuesta para la evaluación de los riesgos en el Dpto. de
Sistemas, es consistente con la propuesta en la evaluación de los riesgos de las
aplicaciones.
El objetivo de este enfoque es que ustedes conozcan una misma metodología
que será aplicada tanto en la evaluación de aplicaciones y Dpto. de Sistemas,
se detallan las actividades de la misma:
▪▪ Investigar.
▪▪ Solicitar información del área o elemento crítico a auditar.
definidas.
Para la revisión del riesgo de políticas y procedimientos del Dpto. de Sistemas

se aplicarán todos los pasos definidos en la metodología de evaluación deta-
llada.
A continuación, desarrollamos sólo los temas de la metodología de evalua-
ción que tienen un tratamiento particular con respecto al presente riesgo:
Investigar: Los temas que se deberían de investigar para tener información
sobre el riesgo de políticas y procedimientos del Dpto. de Sistemas que vamos
a evaluar corresponde a:
▪▪ Investigar de las principales políticas y procedimientos para los

procesos críticos en un Dpto. de Sistemas.
▪▪ Detalle de principales riesgos para los procesos críticos de un
Dpto. de Sistemas.
▪▪ Principales controles para los procesos críticos de un Dpto. de
Sistemas.
▪▪ Investigar buenas prácticas recomendadas en procedimientos
del Dpto. de Sistemas.
▪▪ Investigar sobre fraudes en los procesos críticos en un Dpto. de
Sistemas.
Solicitar información delas políticas y procedimientos utilizados en el

Dpto. de Sistemas: Esta información debería ser solicitada al encargado del Dpto.
de Sistemas, y al responsable de elaborar las políticas y procedimientos en la
empresa. Adicionalmente, para las políticas y procedimientos seleccionados
(muestra) se solicitará directamente a los responsables de dichas funciones en
el Dpto. de Sistemas.
▪▪ Manual de funciones del personal del Dpto. de Sistemas, en el

mismo se debería detallar cuales con las funciones principales
de cada personal.
▪▪ Inventario de las políticas existentes en el Dpto. de Sistemas.
▪▪ Inventario de los procedimientos existentes en el Dpto. de Sistemas.
▪▪ Detalle de las políticas existentes en el Dpto. de Sistemas para
la muestra seleccionada.
▪▪ Detalle de los procedimientos existentes en el Dpto. de Sistemas
para muestra seleccionada.
Los objetivos de solicitar el mismo documento físico o digital a diferentes

personas son:
▪▪ Validar que los responsables de cada una de las funciones co-

nozcan dicha información.
▪▪ Verificar que este formalizado en un documento físico o digital
dichas políticas y procedimientos.
▪▪ Verificar que las diferentes personas tengan la última versión
de las políticas y procedimientos.
Cruzar la información investigada versus lo solicitado: De igual manera como

se ha indicado durante todo el libro, se debería de cruzar la información in-
vestigada versus la entregada, las inconsistencias o novedades deberían de ser

puntos a considerar en la lista de preguntas y pruebas a efectuar.
Con respecto a la información entregada sobre las políticas y procedimien-
tos seleccionados versus lo investigado se validará considerando:
▪▪ Evaluar y analizar las actividades detalladas en los procedi-

mientos seleccionados versus los procedimientos investigados.
▪▪ La evaluación de los controles implementados en los procedi-
mientos seleccionados versus los controles investigados.
Definir el esquema de revisión: El esquema propuesto para la evaluación del

presente riesgo, es una herramienta que los auditores financieros-contables
dominan, tanto por su formación como por la frecuencia que lo utilizan den-
tro de sus trabajos, la misma que detallamos:
Para la evaluación de las políticas y procedimientos, el esquema propuesto
es seleccionar una muestra y validar el cumplimiento de los mismos.
Adicionalmente se efectuarán revisiones para verificar que dicho docu-
mento físico o digital este actualizado, que lo indicado en él mismo se esté
cumpliendo y que todas las personas involucradas en el procedimiento conoz-
can del mismo.
Preparar lista de preguntas y pruebas a efectuar como guía para el trabajo
a realizar: Con respecto al inventario proporcionado de las políticas y procedi-
mientos para normar la gestión y operación del Dpto. de Sistemas, los mismos
que deberían ser entregados y formalizados en documentos físicos o digitales,
se debería considerar efectuar los siguientes trabajos:
▪▪ Verificar que las políticas y procedimiento existentes normen

las principales funciones de cada una de las personas que for-
man parte del Dpto. de Sistemas.
▪▪ Verificar porque existen diferencias entre lo investigado y las
políticas y procedimientos que están implementados en el
Dpto. de Sistemas.
De los documentos físicos o digitales de las políticas y procedimientos selec-

cionados para ser evaluados y que fueron solicitados al personal del Dpto. de
Sistemas, se les efectuará un seguimiento para determinar si se están cum-
pliendo los mismos.
Este trabajo se lo debe realizar con el personal del Dpto. de Sistemas involu-
crado en dichas políticas y procedimientos, considerando:
▪▪ Verificar que se estén cumpliendo las diferentes actividades

definidas en los procedimientos y sus políticas.
▪▪ Solicitar y revisar soportes de los controles implementados en
dichos procesos, aun cuando sean temas técnicos, se debería
solicitar y verificar los mismos.
▪▪ En las políticas y procedimientos evaluados se deben verificar
que estén normadas las revisiones efectuadas y que acción se
debe efectuar con las novedades detectadas.
▪▪ Se deberá considerar que los controles implementados deben ser
preventivos, más que correctivos.
Para la evaluación de la estructura se recomienda utilizar la entrevista con

los involucrados. Para la evaluación de las políticas y procedimientos, el es-
quema propuesto es seleccionar una muestra y validar el cumplimiento de los
mismos.
Considerando los lineamientos indicados se detalla una guía de las pre-
guntas que se deberían considerar al realizar las evaluaciones respectivas:
▪▪ Referente a las novedades detectadas entre lo investigado y

lo existente en el Dpto. de Sistemas de la empresa, se debería
revisar:
▪▪ Porque no se ha implementado lo investigado, en los casos que
proceda pedir soporte sobre lo indicado.
▪▪ Qué riesgo existe para el Dpto. de Sistemas o para la empresa la
falta de dicha política o procedimiento.
▪▪ Con respecto a lo implementado que no se lo identifico en lo
investigado, preguntar las razones de porque se lo ha imple-
mentado, que riesgo mitiga, cual es el efecto económico.
▪▪ Revisión del procedimiento seleccionado como parte del trabajo
del auditor de sistemas debería estar enfocado en los siguientes
temas:
a. Que este actualizado dicho documento físico o digital.

b. Validar que se esté cumpliendo el mismo, se debería pedir
soporte y evidencia de dicho cumplimiento.
c. Que esté disponible de manera física o digital para los
usuarios involucrados en el procedimiento, la información
requerida para el cumplimiento de sus funciones.
d. Que el personal involucrado conozca del procedimiento y sus

obligaciones y responsabilidades sin necesidad de tener que
leer ningún documento físico o digital.
e. Que la información detallada sea clara y completa.
f. Que cubra todos los pasos requeridos para dicho proceso, sin
que se existan actividades pendientes de detallar.
▪▪ Evaluar los controles, en este tema lo fundamental que ustedes

deben validar es que los controles que estén implementados en
el procedimiento disminuyan el riesgo en dicho proceso. Ante
lo indicado las preguntas que debería realizarle al responsable
del proceso y personal involucrado en el mismo son:
a. ¿Qué controles existen para minimizar el riesgo en el pro eso

de evaluación?
b. Pedir evidencia de los controles existente y verificar que se
estén cumpliendo los mismos.
c. ¿Qué otros riesgos existen en dicho proceso y que controles se
han implementado?
d. Sobre los controles investigado y que no están cubierto en el
procedimiento actual en la empresa, preguntar por qué no
están implementado los mismos
▪▪ Con respecto a las novedades detectadas sobre el no cumpli-

miento de temas definidos en las políticas y procedimientos
revisados, preguntar:
a. Cuáles son los motivos que generan dichas novedades.

b. El no cumplimiento de lo detallado en la política y/o proce-
dimiento, qué riesgo genera para el área y para la empresa.
c. Lo identificado podría ser considerado como una excepción o
es un tema generalizado, solicitar soportes que sustenten la
respuesta dada por el personal del Dpto. de Sistemas.
d. Que limitaciones existen en laspolíticas y procedimientos
que se están evaluando, detallarlas y evaluar la posibilidad
de determinar el impacto para la empresa por las limitacio-
nes indicadas.
e. Que inconvenientes se han presentado en las políticas y
procedimientos que se están evaluando, que impacto han
generado dichos inconvenientes.
f. Que nuevos controles se pueden implementar para dismi-

nuir el nivel de riesgo en dicho proceso o política evaluada.
g. Que mejoras se podrían implementar a nivel operativo
(eficiencia-productividad) para mejorar dicho proceso o
política.
TEMA 3: EVALUACIÓN DEL RIESGO II-ACCESO FÍSICO Y LÓGICO A ELEMENTOS CRÍTICOS

3.1. INTRODUCCIÓN
En este tema vamos a revisar el segundo riesgo «Acceso físico y lógico a ele-
mentos críticos del Dpto. de Sistemas», cuando personal no autorizado pueda
ingresar de manera física o lógica a los elementos críticos del Dpto. de Siste-
mas sin la debida autorización y sin que existan controles en su ingreso.
Para iniciar en la aplicación de la metodología en la revisión del segundo
riesgo en la evaluación del Dpto. de Sistemas, definamos qué temas deberían
haberse cubierto por ustedes antes de la respectiva evaluación, detallamos:

▪▪ Conocimiento del Dpto. de Sistemas.
▪▪ Áreas físicas principales que existen en un Dpto. de Sistemas.
▪▪ Principales elementos críticos en un Dpto. de Sistemas.
3.2. CONOCIMIENTOS TÉCNICOS REQUERIDOS PARA LA EVALUACIÓN DEL SEGUNDO RIESGO: ACCESO FÍSICO
Y LÓGICO A ELEMENTOS CRÍTICOS DEL DPTO. DE SISTEMAS
tados de la evaluación que ustedes van a efectuar, existen ciertos temas que
son importantes que los investiguen y se relacionen con dichos conceptos.
En la evaluación de los riesgos del Dpto. de Sistemas, se van a revisar temas
más técnicos, por lo que es importante que le den la prioridad de cerrar la bre-
cha de conocimientos técnicos existente entre ustedes y el personal del Dpto.
de Sistemas. Detallamos los puntos que deberían ser investigados:
▪▪ Las áreas físicas importantes que existen en un Dpto. de Siste-

mas.
▪▪ Los principales elementos críticos en un Dpto. de Sistemas.
▪▪ Diferencias entre un acceso físico y lógico.
▪▪ Familiarizarse con ejemplos de controles para acceso físico y
lógico para elementos críticos de un Dpto. de Sistemas.
3.3. METODOLOGÍA PARA EVALUACIÓN DEL SEGUNDO RIESGO: ACCESO FÍSICO Y LÓGICO PARA ELEMENTOS CRÍTICOS
Como la metodología recomendada para la evaluación es la misma tanto para
las aplicaciones como para el Dpto. de Sistemas, sólo vamos a desarrollar los
pasos cuyas actividades tengan un manejo especial en la evaluación del pre-
sente riesgo del Dpto. de Sistemas.
Para aquellas actividades que no son desarrolladas en este riesgo, deberían
tomar como referencia lo visto en el capítulo uno y demás capítulos donde se
desarrolla la metodología para cada uno de los riesgos de las aplicaciones y del
Dpto. de Sistemas.
Detallamos el desarrollo de las actividades de la metodología para la eva-
luación del segundo riesgo del Dpto. de Sistemas:
Investigar: Como se detalló en el epígrafe 3.2 del presente capítulo, respecto
a los conocimientos requeridos para la evaluación del riesgo de «Acceso físico
y lógico de los elementos críticos al Dpto. de Sistemas», los puntos que ustedes
deben investigar son:
▪▪ Áreas físicas principales que existen en un Dpto. de Sistemas.

▪▪ Cuáles son los procesos críticos en un Dpto. de Sistemas.
▪▪ Controles para los principales elementos críticos identificados.
▪▪ Riesgos que están expuestos los principales elementos críticos
identificados.
▪▪ Fraudes que se han cometidos por debilidades en los controles
para los principales elementos críticos identificados.
Estos temas de investigación deberían ser cubiertos enfocándose con los si-
guientes lineamientos:
▪▪ Determinar cuáles son las áreas críticas en un Dpto. de Siste-

mas que pueden afectar en un negocio.
▪▪ Determinar cuáles son los procesos críticos en un Dpto. de Sis-
temas que pueden afectar en un negocio.
▪▪ Determinar cuáles son los elementos críticos en un Dpto. de
Sistemas que pueden afectar en un negocio.
▪▪ Para las áreas, procesos y elementos críticos determinar si exis-
ten riesgo de accesos no autorizados de manera física o lógica a
los mismos.
▪▪ Por qué son críticos dichas áreas, procesos y elementos.
▪▪ Qué riesgos generan para el negocio.
▪▪ Qué controles se pueden aplicar en dichas áreas, procesos y

elementos para minimizar los riesgos.
▪▪ Investigar que inconvenientes se pueden presentar en dichas
áreas, procesos y elementos, y como afectan a la operación del
negocio.
Solicitar información de las áreas, procesos y elementos críticos a auditar: La

información que se solicitará al responsable del Dpto. de Sistemas será:
▪▪ Inventario de las áreas, procesos y elementos críticos definidos

por el Dpto. de Sistemas, con un detalle de:
▪▪ Breve descripción para todas las áreas, procesos y elementos
críticos detallados.
▪▪ Justificativo de por qué son críticos los mismos.
▪▪ Detalle cuáles son los riesgos de accesos no autorizados para las
áreas, procesos y elementos críticos identificados, e identificar
el nivel de probabilidad de ocurrencia e impacto en el negocio
para los riesgos identificados.
▪▪ Detalle de los controles que se han implementado sobre las
áreas, procesos y elementos críticos con respecto al riesgo de
acceso no autorizado, considerando:
a. Cuál es el objetivo del control.

b. Como opera el mismo.
c. Quien lo realiza.
d. Con que frecuencia opera dicho control.
▪▪ Detalle de inconvenientes que se han presentado en el último

año en las áreas, proceso y elementos críticos detallados.
▪▪ Han existido intento o fraudes en dichas áreas, procesos y ele-
mentos críticos.
▪▪ Se han efectuados cambios en las áreas, procesos y elementos
críticos, si es afirmativa la respuesta favor indicar:
a. Detallar cuales han sido y el motivo de los mismos.

b. Cuál es el beneficio para cada cambio efectuado.
c. Se ha generado algún riesgo con dicho cambio efectuado.
Definir el esquema de revisión: En base a la información investigada y la

solicitada al responsable del Dpto. de Sistemas, ustedes deberían de aplicar el
esquema de revisión recomendado para el presente riesgo que es la entrevista

a los involucrados e inspección física a las áreas, procesos y elementos críticos
seleccionados.
El tema fundamental en el esquema de revisión es la definición de que
áreas, procesos y elementos críticos son los que se van a evaluar, para lo cual
se recomienda efectuar una matriz de riesgo para su determinación, conside-
rando los siguientes parámetros de evaluación:
▪▪ Nivel de riesgo, los de mayor riesgo son potenciales a ser revisa-

dos.
▪▪ Nivel de crítico, los más críticos son potenciales a ser revisados.
▪▪ Número de inconvenientes, los que cuenten con un mayor nú-
mero de inconvenientes son potenciales a ser revisados.
▪▪ Cambios efectuados, los que han tenido cambios en los últimos
años son potenciales a ser revisados.
▪▪ Fraudes, los que han sido susceptibles de fraudes son potencia-
les a ser revisados.
▪▪ Facilidad de evaluación, los que sean más fáciles de poderlos
revisar podrían ser considerados potenciales a ser revisados.

realizar: Para dichos elementos seleccionados se debería hacer una lista de
preguntas y pruebas que serán complementadas con una inspección física.
Primer grupo de actividades a efectuar.
El objetivo de este primer grupo de actividades es revisar y validar la
información entregada por el responsable del Dpto. de Sistemas y ampliar
cualquier inquietud sobre la misma.
Los detalles de las actividades a realizar son similares a la que se van a
efectuar en el tercer grupo de actividades, la diferencia está en con quien se la
realiza y cuál es la profundidad de la misma.
Ante lo indicado el enfoque de este grupo de actividades se lo realizará con
el responsable del Dpto. de Sistemas y el enfoque es general, no se debería
entrar a profundizar los temas.
Detallamos el primer grupo de actividades a realizar:
▪▪ Revisar el inventario de las áreas, procesos y elementos críticos
entregados por el responsable del Dpto. de Sistemas, conside-
rando:
a. Breve descripción para todas las áreas, procesos y elementos

críticos detallados.
b. Justificativo de por qué son críticos los mismos.
▪▪ Revisar el detalle cuáles son los riesgos de accesos no autoriza-

dos para las áreas, procesos y elementos críticos identificados,
e identificar el nivel de probabilidad de ocurrencia e impacto en
el negocio para los riesgos identificados.
▪▪ Revisar el detalle de los controles que se han implementado
sobre las áreas, procesos y elementos críticos con respecto al
riesgo de acceso no autorizado, este tema debería ser revisado
de manera general.
▪▪ Revisar el detalle de inconvenientes que se han presentado en
el último año en las áreas, procesos y elementos críticos deta-
llados.
▪▪ Revisar si han existido intento o fraudes en dichas áreas,
procesos y elementos críticos, este tema si debe ser revisado en
detalle y se debería pedir evidencias sobre lo conversado.
▪▪ Revisar si se han efectuados cambios en las áreas, procesos y
elementos críticos, si es afirmativa la respuesta favor indicar:
a. Detallar cuales han sido y el motivo de los mismos.

b. Cuál es el beneficio para cada cambio efectuado.
c. Se ha generado algún riesgo con dicho cambio efectuado.
Segundo grupo de actividad a efectuar.

El objetivo de este segundo grupo de actividad a efectuar es ampliar o
aclarar las inquietudes identificadas entre lo investigado y la información
entregada por el personal de la empresa. Cada tema tratado debería ser so-
portado con documentación y evidencias, esta actividad es efectuada con el
responsable del Dpto. de Sistemas.
Tercer grupo de actividades a efectuar.
El objetivo de este tercer grupo de actividades es efectuar un levantamiento
de información enfocado a la evaluación de las áreas, procesos y elementos
críticos seleccionados.
Este tercer grupo de actividades se la realiza con el o los responsables de las
áreas, procesos y elementos críticos seleccionados.
Los objetivos de estas actividades son ampliar información sobre las áreas,
procesos y elementos críticos definidos para la revisión, y validar la informa-
ción proporcionada por el responsable del Dpto. de Sistemas, cabe mencionar
que las mismas preguntas se las efectúo al responsable del Dpto. de Sistemas,
en el primer grupo de actividades detallada.
Detallamos las actividades a realizar:
▪▪ Revisar el detalle cuáles son los riesgos de accesos no autoriza-

dos para las áreas, procesos y elementos críticos identificados, y
determinar el nivel de probabilidad de ocurrencia e impacto en
el negocio para los riesgos identificados.
▪▪ Revisar el detalle de inconvenientes que se han presentado en
el último año en las áreas, procesosy elementos críticos deta-
llados.
▪▪ Revisar si han existido intento o fraudes en dichas áreas, proce-
sos y elementos críticos.
▪▪ Revisar si se han efectuados cambios en las áreas, procesos y
elementos críticos, si es afirmativa la respuesta favor indicar:
●● Detallar cuales han sido y el motivo de los mismos.

●● Cuál es el beneficio para cada cambio efectuado.
●● Se ha generado algún riesgo con dicho cambio efectuado.
Cuarto grupo de actividades a efectuar.

El objetivo de este cuarto grupo de actividades es efectuar el trabajo de
campo enfocado a la evaluación de las áreas, procesos y elementos críticos
seleccionados.
Este cuarto grupo de actividades se la realiza con el o los responsables de las
áreas, procesos y elementos críticos seleccionados.
Los objetivos de estas actividades son evaluar, verificar, obtener evidencias
sobre los riesgos y controles existentes sobre las áreas, procesos y elementos
críticos definidos para la revisión.
Detallamos las actividades a realizar:
▪▪ Efectuar una inspección física en cada área, proceso o elemento

crítico seleccionado, revisandolos riesgosque puedan afectar a
los elementos evaluados y los controles implementados en la
empresa que minimicen dichos riesgos, considerando:
●● Robo
●● Acceso de personas no autorizadas
●● Riesgos propios de la operación y gestión del negocio
●● Riesgo de inundaciones y naturales
●● Riesgo de incendio
●● Atentado
●● Otros
▪▪ Validar los controles que la empresa ha implementado sobre las

áreas, procesos y elementos críticos evaluados, considerando
●● Cuál es el objetivo del control.

●● Como opera el mismo.
●● Quien lo realiza.
●● Con que frecuencia opera dicho control.
●● Documentación que soporte la ejecución de dichos controles.
●● Están definidos los responsables de los mismos.
●● Que esté definido una periodicidad para validar la adecuada
operación de los controles implementados.
●● Revisar la documentación de los procedimientos y políticas
donde deberían estar formalizados todos los temas mencio-
nados anteriormente.
▪▪ Sobre los controles que la empresa ha implementado en las

áreas, procesos y elementos críticos evaluados, revisar:
●● Que temas no cubre el control implementado.

●● Se han efectuado cambios en los controles en los últimos, en
caso de ser positiva la respuesta, indicar los motivos de los
mismos.
▪▪ Revisar los inconvenientes presentados en la operación en el

último año en las áreas, proceso o elementos críticos evaluados,
considerando:
●● Identificación de los inconvenientes.

●● Ver las causas que generaron dichos inconvenientes
●● Que efectos se generó, existió algún riesgo para el negocio.
●● Qué medidas se han aplicado para minimizar la ocurrencia
de los mismos.
▪▪ Para los inconvenientes detallados, revisar y determinar si
los controles implementados operaron adecuadamente, pedir
documentación que soporte los comentarios de los responsables
de las áreas, procesos y elementos críticos evaluados.
TEMA 4: EVALUACIÓN DEL RIESGO III: RIESGOS OPERATIVOS Y DE GESTIÓN CRÍTICOS

4.1. INTRODUCCIÓN
La situación en algunas empresas es que no se tengan identificados los riesgos
operativos y de gestión más críticos y factibles que puedan afectar al Dpto. de
Sistemas, y que los mismos tengan incidencia significativa en la operación de
la empresa.
El tener identificado los riesgos permite elaborar un detalle de las activida-
des que deberían realizarse en caso de que sucedan los mismos, con el objetivo
de minimizar el impacto en la empresa, dicho detalle se lo conoce como un
plan de contingencia. Un plan de contingencia, es una guía de lo que se debe
de efectuar en caso de una contingencia; por ejemplo, si existe un incendio
que debe de hacer el personal del área afectada, como se debe de manejar al
recurso humano, a quien se debe de avisar, como se debe manejar a la prensa,
entre otros temas.
El documento donde está detallado cada paso de lo que se debe de hacer, es
lo que se llama plan de contingencia.
Lo fundamental de un plan de contingencia es que debe estar enfocado a
los riesgos más importantes y con mayor posibilidad de ocurrencia dentro de
la empresa.
En base a lo indicado, el concepto de riesgos y plan de contingencia, está
enfocado a la empresa, y no puntualmente al Dpto. de Sistemas, pero al ser
el Dpto. de Sistemas un área crítica dentro de la empresa aplica el concepto
de evaluar los riesgos operativos y de gestión críticos y revisar su plan de con-
tingencia, lo cual dará un nivel de confianza al auditor en la continuidad del
negocio.
Podemos indicar que existen tipos de negocios donde su dependencia
dela tecnología y del Dpto. de Sistemas es tan alta, que si no cuentan con los
servicios brindados por ellos, el negocio podría verse afectado; por ejemplo:
qué tiempo podría estar un banco sin sistemas en sus ventanillas; tengo una
empresa enfocada en comercio electrónico, qué pasaría si no tengo internet…
la respuesta para estos casos es que las empresas no podrían operar; igual que
en el banco, podrá estar por unas horas, pero luego de eso podría afectar la
imagen y al mismo negocio.
En esencia, ante lo indicado en esta introducción se ha determinado la
importancia de evaluar los riesgos operativos y de gestión críticos existen en
el Dpto. de Sistemas que tengan un alto nivel de probabilidad y que el impacto
es alto, para los cuales deberían de existir un plan de contingencia que ayude
a mitigar el impacto, ya que el objetivo no es prevenirlo.
Dentro de esa evaluación se determinará una metodología que permita

evaluar si los riesgos operativos y de gestión del Dpto. de Sistemas son los
adecuados, si existen un plan de contingencia para aquellos riesgos, si el
personal conoce qué hacer ante una contingencia, la empresa cuenta con los
recursos para poder reaccionar, esta actualizado el documento, se han hecho
pruebas para verificar la validez del plan de contingencia, entre otros puntos
que deberían ser evaluados por el auditor.
4.2. CONOCIMIENTOS TÉCNICOS REQUERIDOS PARA LA EVALUACIÓN DEL TERCER RIESGO – RIESGOS OPERATIVOS
Y DE GESTIÓN CRÍTICOS DEL DPTO. DE SISTEMAS
Para la evaluación delos riesgos operativos y de gestión críticos del Dpto. de
Sistemas es importante que ustedes conozcan e investiguen la siguiente in-
formación:
▪▪ Las áreas físicas importantes que existen en un Dpto. de Siste-

mas.
▪▪ Los principales elementos críticos en un Dpto. de Sistemas.
▪▪ Los principales servicios que brindan un Dpto. de Sistemas en
las empresas.
▪▪ En qué consiste un plan de contingencia.
▪▪ Los elementos fundamentales de un plan de contingencia.
4.3. METODOLOGÍA PARA EVALUACIÓN DEL TERCER RIESGO: RIESGOS OPERATIVOS Y DE GESTIÓN CRÍTICOS
Para la revisión de los riesgos operativos y de gestión críticos del Dpto. de Sis-
temas se aplicarán todos los pasos definidos en la metodología de evaluación
que ha sido utilizada en los diferentes riesgos revisados en el presente libro.
A continuación, desarrollamos sólo los temas de la metodología de evalua-
ción que tienen un tratamiento particular con respecto al presente riesgo:
Investigar: Los temas que se deberían de investigar para tener información
sobre los riesgos operativos y de gestión críticos del Dpto. de Sistemas que
vamos a evaluar corresponden a:
▪▪ Riesgos operativos internos y externos que afectan el negocio

que están evaluando.
▪▪ Riesgos de gestión internos y externos que afectan el negocio
que están evaluando.
▪▪ Riesgos ambientales que está expuesta la empresa por su ubi-
cación.
▪▪ Riesgos operativos internos y externos que afectan al Dpto. de

Sistemas que están evaluando.
▪▪ Riesgos de gestión internos y externos que afectan al Dpto. de
Sistemas que están evaluando.
▪▪ En qué consiste un plan de contingencia.
▪▪ Los elementos fundamentales de un plan de contingencia.
▪▪ Buenas prácticas y recomendaciones de temas que deberían
considerarse en un plan de contingencia.
Solicitar información sobre los riesgos operativos y de gestión críticos del

Dpto. de Sistemas que van a ser auditados: Los documentos físicos o digitales
que se solicitarán al responsable del Dpto. de Sistemas para la evaluación del
▪▪ Detalle de los riesgos operativos internos y externos que afectan

el negocio que están evaluando.
▪▪ Detalle de los riesgos de gestión internos y externos que afectan
el negocio que están evaluando.
▪▪ Detalle de los riesgos ambientales que está expuesta la empresa
por su ubicación.
▪▪ Detalle de los riesgos operativos internos y externos que afectan
al Dpto. de Sistemas que están evaluando.
▪▪ Detalle de los riesgos de gestión internos y externos que afectan
al Dpto. de Sistemas que están evaluando.
▪▪ Manual del plan de contingencia implementado en el Dpto. de
Sistemas.
▪▪ Matriz de riesgo utilizada para la elaboración del plan de con-
tingencia.
▪▪ Documentación y soportes de los simulacros y pruebas realiza-
das del plan de contingencia.
Cruzar la información investigada versus lo solicitado: La información entre-

gada versus lo investigado se validará considerando:
▪▪ La información considerada en la matriz de riesgo utilizada

para la elaboración del plan de contingencia de la empresa
deberíaser validada con la información referente a:
●● Los riesgos operativos internos y externos que afectan el

negocio que están evaluando.
●● Los riesgos de gestión internos y externos que afectan el
negocio que están evaluando.
●● Los riesgos ambientales que está expuesta la empresa por su
ubicación.
●● Los riesgos operativos internos y externos que afectan al
Dpto. de Sistemas que están evaluando.
●● Los riesgos de gestión internos y externos que afectan al
Dpto. de Sistemas que están evaluando.
▪▪ Los elementos que conforman el manual de contingencia de

la empresa debería cruzarse con la información investigada
y entregada por la empresa respecto a los riesgos de gestión y
operación del Dpto. de Sistemas y de la empresa.
▪▪ Evaluar que el plan de contingencia que cuenta la empresa tiene
las buenas prácticas y los elementos fundamentales de un plan
de contingencia.
Cualquier diferencia o inquietudes en el cruce de la información entre lo que

tiene la empresa versus lo investigado servirá de elementos para ser validados
en la reunión con el responsable del Dpto. de Sistemas y con el personal ope-
rativo.
Definir el esquema de revisión: El esquema de revisión para el presente
riesgo, es verificar y validar la información de la matriz de riesgo, que es el
elemento fundamental para determinar si la empresa ha identificado adecua-
damente los riesgos de gestión y operación del Dpto. de Sistemas.
Posteriormente se debería de revisar los riesgos de gestión y operación
del Dpto. de Sistemas definidos como críticos, para los mismos, la empresa
debería de contar con un plan de contingencia que permita mitigar el impacto
ante el suceso de alguna contingencia, por lo que se debería de revisar dicho
plan de contingencia.
Entre los lineamientos para dicha revisión está verificar que dicho do-
cumento este actualizado, validar los simulacros efectuados y que todas las
personas involucradas en el plan de contingencia conozcan del mismo, ente
otros temas.
a realizar:
El enfoque del trabajo recomendado para evaluar los riesgos operativos y
de gestión críticos del Dpto. de Sistemas está basado en los siguientes temas:
▪▪ Revisión de la definición de los riesgos operativos y de gestión

críticos en el Dpto. de Sistemas - matriz de riesgo.
▪▪ Revisión del documento del plan de contingencia.
▪▪ Revisión de las pruebas efectuadas que garanticen la factibili-
dad de lo detallado en el plan de contingencia.
▪▪ Evaluar que las personales involucradas en el plan de contin-
gencia conozcan del mismo.
Para cada una de los temas detallados se los va a desarrollar como guía para
su aplicación.
Revisión de la definición de los riesgos operativos y de gestión críticos en el
Dpto. de Sistemas - matriz de riesgo: En este punto lo fundamental que ustedes
deben validar es que los riesgos que están definidos como críticos sean los más
factibles de ocurrir en la empresa y que su impacto afecte significativamente
a la gestión del Dpto. de Sistemas.
Entre los tipos de riesgos que podrían considerarse tenemos:
▪▪ Riesgos ambientales, tales como: inundaciones, deslaves, te-

rremotos, entre otros.
▪▪ Riesgos del negocio, tales como: atentado internos o externos,
leyes o reglamentos emitidos por organismos de control, entre
otros.
▪▪ Riesgos operativos, tales como: daños del servidor, caída de los
sistemas, interrupción del fluido eléctrico, entre otros.
Estos riesgos deberían ser determinados por los responsables de las principa-
les áreas de la empresa con el soporte de consultores externos que permitan
visualizar otros riesgos que afecten a la misma.
Para efectuar la revisión las preguntas que deberían realizarle al responsa-
ble del Dpto. de Sistemas son:
▪▪ ¿Cómo se determinaron los riesgos del plan de contingencia?

▪▪ ¿Qué metodología utilizaron para la determinación de los ries-
gos?
▪▪ ¿Quienes participaron en la definición de los riesgos?
▪▪ Solicitar soportes de la metodología y papeles de trabajo para
definición de la matriz de riesgo.
▪▪ ¿Qué riesgo considera el responsable del Dpto. de Sistemas que

sea importante y no hayan sido cubierto, por qué no se los ha
implementado?
▪▪ Sobre los riesgos investigados y que no están cubierto en el plan
de contingencia de la empresa preguntar:
●● La empresa está expuesta a dicho riesgo.
●● Por qué no fueron considerados los mismos.
Revisión del documento del plan de contingencia.

Para la revisión del documento del plan de contingencia se tomará una
muestra del mismo y se verificará quese cumplan los siguientes temas:
▪▪ Que esté actualizado dicho documento.

▪▪ Que esté disponible para todos usuarios involucrados los puntos
que le corresponden a cada uno de ellos.
▪▪ Que la información detallada sea clara y completa.
▪▪ Que cubra todos los pasos requeridos para la contingencia, sin
que se queden temas pendientes de detallar.
Revisión de las pruebas efectuadas que garanticen la factibilidad de lo detalla-

do en el plan de contingencia:
▪▪ Se debe revisar si el plan de contingencia ha sido probado a

través de simulacros.
▪▪ Se debería verificar que todos los simulacros están documen-
tados, con un detalle de los resultados e inconvenientes que se
presentaron.
▪▪ Validar que los inconvenientes detectados en el simulacro ha-
yan sido solucionados.
▪▪ Se debe verificar la fecha de cuando se realizaron los simulacros
y validar si es adecuada o no dicha fecha.
Temas que pueden afectar los periodos de los simulacros son: si habido
mucha rotación del personal que interviene en el plan de contingencia,
han existido cambios en el plan de contingencia significativos, han existi-
do cambios en el negocio que pueden afectar al plan de contingencia,
entre otros.
Evaluar que las personales involucradas en el plan de contingencia conozcan
del mismo: Para cubrir este punto se debería escoger una muestra de personas
que están involucradas en el plan de contingencia y preguntarles sobre los

puntos que deberían conocer sobre dicho documento.
En dichos casos el personal debe de conocer sus responsabilidades sin nece-
sidad de tener que leer ningún documento físico o digital.
Puntos que pueden servir de guía para la selección de la muestra a ser
seleccionada:
▪▪ Personal nuevo dentro de la empresa.

▪▪ Personal que está reemplazando en sus funciones a otra perso-
na.

TEMA 5: EVALUACIÓN DEL RIESGO IV: ESTRUCTURA DEL DPTO. DE SISTEMAS
5.1. INTRODUCCIÓN
El cuarto riesgo es que la estructura del Dpto. de Sistemas no soporte una se-
gregación de funciones en su personal y que no existan controles para mitigar
la falta de dicha segregación.
Para revisar este riesgo se debe considerar dos temas, el primero consiste en
evaluar la estructura del Dpto. de Sistemas y el segundo tema es la evaluación
de los controles implementados para mitigar la falta de segregación que puede
presentarse en un Dpto. de Sistemas. Los dos temas están muy relacionados
por qué al evaluar los controles implementados, estos mitigan el riesgo de
falta de segregación en la estructura del Dpto. de Sistemas.
Con respecto a la evaluación de la estructura del Dpto. de Sistemas es un
tema que considero que ustedes como auditores deberían manejarlo muy deli-
cadamente, ya que es un tema técnico y sensible porque está relacionado con
el personal que trabaja en un área crítica de la empresa.
5.2. CONOCIMIENTOS TÉCNICOS REQUERIDOS PARA LA EVALUACIÓN DEL CUARTO RIESGO: ESTRUCTURA
Los temas que deberían de investigar para poder evaluar el presente riesgo
son:
▪▪ Cargos que pueden existir en un Dpto. de Sistemas y conocer

cuál es el objetivo de dicho cargo y el detalle de sus principales
funciones.
▪▪ Segregaciones de funciones que deberían existir en el personal
del Dpto. de Sistemas de manera que soporten los controles.
▪▪ Ambiente de producción y desarrollo, identificando diferencias,
riesgos en cada uno de los ambientes.
5.3. METODOLOGÍA PARA EVALUACIÓN DEL CUARTO RIESGO: ESTRUCTURA DEL DPTO. DE SISTEMAS
Para la revisión del presente riesgo se aplicarán todos los pasos definidos en
la metodología de evaluación que ha sido utilizada en los diferentes riesgos.
A continuación, desarrollamos sólo los temas de la metodología de eva-
luación que tienen un tratamiento particular con respecto al presente riesgo,
detallamos los mismos:
Investigar: Los temas a investigar para la evaluación del presente riesgo
son:
▪▪ Cargos y funciones que pueden existir en un Dpto. de Sistemas.

▪▪ Segregación de funciones que deberían existir en el personal del
Dpto. de Sistemas que soporten los controles.
▪▪ Para cada función del personal de un Dpto. de Sistemas por
quienes pueden ser asumidas sin general riesgo para la empre-
sa.
▪▪ Que controles se pueden implementar en cada cargo de una
estructura de un Dpto. de Sistemas para controlar las funciones
que realizan.
▪▪ Fraudes efectuados por falta de segregación en la estructura del
Dpto. de Sistemas.
Solicitar información de la estructura del Dpto. de Sistemas a auditar: La

información que se solicitará al responsable del Dpto. de Sistemas sería:

de cada personal.
▪▪ Listado de usuarios que tienen acceso al ambiente de produc-
ción.
▪▪ Listado de usuarios que tienen acceso al ambiente de desarrollo.
▪▪ Inventario de los procedimientos existentes en el Dpto. de Siste-
mas para muestra seleccionada.
▪▪ Para las principales funciones del personal del Dpto. de Siste-
mas, entregar un detalle de los controles implementados para
dichas funciones, detallando cual es el objetivo del mismo, que
periodicidad se lo efectúa, cual es el soporte que se obtiene del
mismo.
La información que se solicitará al responsable de la elaboración de las políti-

cas y procedimientos en la empresa sería:

de cada personal.
▪▪ Inventario de los procedimientos existentes en el Dpto. de Siste-
mas para muestra seleccionada.
Los objetivos de solicitar los mismos documentos físicos o digitales a diferen-

tes personas son:
▪▪ Validar la información entregada como parte del trabajo que se

está efectuando.
▪▪ Verificar que sea la última versión del documento físico o digi-
tal.
Cruzar la información investigada versus lo solicitado: De igual manera como

se ha indicado durante todo el libro, se debería de cruzar la información in-
vestigada versus la entregada; las inconsistencias o novedades identificadas
deberían ser puntos a considerar en la lista de preguntas y pruebas a efectuar.
Definir el esquema de revisión: Los esquemas propuestos para la evalua-
ción del presente riesgo, son métodos que los auditores financieros-contables
dominan, tanto por su formación como por la frecuencia que lo utilizan den-
tro de sus trabajos. Para la evaluación de la estructura se recomienda utilizar
la entrevista con los involucrados.
a realizar sobre la estructura del Dpto. de Sistemas: Para evaluar la estructura
del Dpto. de Sistemas, existen ciertos conceptos y lineamientos que deben ser
considerados, detallamos:
▪▪ Existe personal que por sus funciones no deben tener acceso al

ambiente de producción como son:
●● Analistas
●● Programadores
●● Personal técnico, tales como: ingeniero de sistemas, help desk,
administrador de redes, administrador de servidores.
●● Organización y métodos.
●● Control de calidad
▪▪ Personal que por sus funciones requieren tener acceso al am-

biente de producción:
●● Administrador de seguridades.
●● Administrador de las bases de datos.
●● Responsable de los respaldos de la información.
●● Responsable de pasar a producción los cambios de los progra-
mas.
▪▪ Dependiendo de la estructura, existen ciertas funciones que

pueden ser asumidas por cierto personal del Dpto. de Sistemas
sin crear ningún riesgo de segregación de funciones, detalla-
mos los casos indicados:
●● Las funciones del analista pueden ser asumida por el progra-
mador o lo contrario.
●● Entre los ingenieros de sistemas, administrador de redes,
administrador de servidores y help desk; sus funciones pueden
ser asumidas entre ellos de acuerdo a su perfil profesional y
carga de trabajo.
▪▪ Las funciones de administrador de seguridades, administra-

dor de las bases de datos, responsable de los respaldos de la
información, responsable de pasar programas a producción,
sus funciones pueden ser asumidas entre ellos de acuerdo a su
perfil profesional y carga de trabajo.
En caso de que dicho personal no pueda asumir dichas funciones, estas debe-
rían ser asumidas por el responsable del Dpto. de Sistemas.
▪▪ Evaluar que los usuarios definidos en el ambiente de producción

sean los autorizados, para lo cual se revisará la información
solicitada con respecto a los usuarios registrados en el ambiente
de producción y en desarrollo.
Una vez indicados ciertos lineamientos que apoyan a la revisión del riesgo de
la estructura en el Dpto. de Sistemas, detallamos las preguntas y enfoque
de revisión que se deberían realizar:
▪▪ ¿Qué personal del Dpto. de Sistemas tienen acceso al ambiente

de producción y que funciones realizan?
▪▪ Para los usuarios que tienen acceso al ambiente de producción

verificar:
●● Cuáles son las funciones que desarrollan en el ambiente de

producción.
●● Que controles se han implementado para las funciones que
desarrollan en el ambiente de producción.
●● Revisar soportes de los controles implementados, aun cuan-
do sean temas técnicos, se debería solicitar y verificar los
mismos.
●● Los controles deben ser preventivos, más que correctivos.
●● Las funciones y controles indicados, deberían estar norma-
dos en un documento de políticas y procedimientos, solicitar
los mismos y validar dicha información.
▪▪ Sobre las novedades detectadas sobre el no cumplimiento de

temas definidos en las políticas y procedimientos revisados,
preguntar:
●● Cuáles son los motivos que generan dichas novedades.

●● El no cumplimiento qué riesgo genera para el área y para la
empresa.
●● Es una excepción o es un tema generalizado, solicitar sopor-
te.
▪▪ ¿Quién efectúa las funciones de Administrador de seguridades?

▪▪ ¿Quién efectúa las funciones de Administrador de las bases de
datos?
▪▪ ¿Quién efectúa las funciones de obtener los respaldos de la
información de los sistemas de la empresa?
▪▪ ¿Quién efectúa las funciones de pasar a producción los cambios
de los programas de computación?
▪▪ Novedades detectadas sobre el cruce de la información de los
usuarios que tienen acceso al ambiente de producción.
▪▪ La información preguntada debería ser validada con lo detalla-
do en los procedimientos.
ACTIVIDADES
A continuación, se detallan ciertas actividades que tienen como objetivo
ayudar a reforzar los conceptos y lineamientos indicados en el presente ma-
terial referente a una auditoría de sistemas al Dpto. de Sistemas, por lo que
recomiendo considerar efectuar las mismas, éxitos.
Actividad 1: Aplicación de metodología para el riesgo de políticas y procedi-
mientos del Dpto. de Sistemas.
En base a la información detallada sobre «Evaluación del Riesgo I: Políticas
y procedimientos del Dpto. de Sistemas», realice todas las actividades detalla-
das en dicha metodología con las siguientes consideraciones:
▪▪ Seleccione una empresa real, preferiblemente mediana.

▪▪ Seleccione una muestra de dos políticas y procedimientos.
▪▪ Efectúe cada una de las actividades detalladas en la metodolo-
gía para la muestra seleccionada.
▪▪ Documente y soporte cada actividad.
El objetivo de esta actividad es que ustedes apliquen los conocimientos revisa-

dos en este libro.
tema2: Evaluación del Riesgo I: Políticas y procedimientos del Dpto. de Siste-
mas.
Actividad 2: Análisis de la metodología para el riesgo de acceso físico lógico a
elementos críticos del Dpto. de Sistemas.
En base al material detallado con respecto a la metodología para la «Eva-
luación del Riesgo II: Acceso físico y lógico a elementos críticos del Dpto. de
Sistemas», deberían efectuar un análisis y evaluación de la misma, conside-
rando los siguientes lineamientos:
▪▪ Dudas e inquietudes de la información entregada en el presente

material.
▪▪ En el detalle de las actividades que se debe realizar para poder
cumplir las funciones detalladas, qué otras actividades se po-
drían incluir.
▪▪ Qué limitaciones se pueden presentar al realizar las actividades
El objetivo de esta actividad es que ustedes analicen, evalúen y cuestionen la

metodología propuesta, lo cual les permitirá identificarse con la misma, y
adaptarla a ciertas condiciones propias, como son: su nivel de conocimiento,
el enfoque de auditoría que desea aplicar y de ciertas características propias
del negocio.
tema3: Evaluación del Riesgo II: Acceso físico y lógico a elementos críticos del
Dpto. de Sistemas.
RESUMEN
La «Revisión de los riesgos existentes en el Dpto. de Sistemas», es una de las
funciones principales para un auditor de sistemas. De acuerdo a lo indicado
con respecto a la metodología utilizada para evaluar un Dpto. de Sistemas,
ella está enfocada en cuatro riesgos:
Riesgo I: Políticas y procedimientos del Dpto. de Sistemas.
Todo departamento o área crítica en una empresa debe estar normada y
soportada por políticas y procedimientos, ante lo indicado el Dpto. de Siste-
mas es un área crítica por lo que todos sus principales procesos deben estar
normados con políticas y procedimientos.
Es uno de los riesgos que para su evaluación el perfil de un auditor es exce-
lente, ya que es una actividad que frecuentemente la realiza en las diferentes
áreas de la empresa.
Riesgo II: Acceso físico y lógico a elementos críticos del Dpto. de Sistemas.
Personal no autorizado pueda ingresar a áreas físicas o lógicas restringidas
del Dpto. de Sistemas sin la debida autorización y sin controles en su ingreso.
En la evaluación física es un tema que los auditores tienen experiencia en
su evaluación, esta actividad la efectúan frecuentemente en las diferentes
áreas de la empresa, sin embargo, en el Dpto. de Sistemas no lo realizan, por
lo que deberían planificar efectuar la misma.
En lo referente al acceso lógico será una oportunidad de comenzar a cerrar
esa brecha de conocimiento.
Riesgo III: Riesgos operativos y de gestión críticos del Dpto. de Sistemas.
Los riesgos operativos y de gestión críticos del Dpto. de Sistemas deberían de
contar con un plan de contingencia que permita mitigar el impacto ante contingencia.
Riesgo IV - Estructura del Dpto. de Sistemas.
La estructura y la asignación de las funciones del personal del Dpto. de Sis-
temas pueden no soportar la segregación de funciones, lo cual es un elemento
de control y es de manera significativo en áreas críticas.
Para la evaluación de un Dpto. de Sistemas existen ciertos conceptos que
ustedes deberían investigar, de los cuales los más importantes son:
▪▪ Estructura de un Dpto. de Sistemas con sus principales funcio-

nes del personal.
▪▪ Que áreas existen en un Dpto. de Sistemas.
▪▪ Principales procesos críticos en un Dpto. de Sistemas.
▪▪ Diferencias entre ambiente de producción y de desarrollo.
▪▪ Que es un plan de contingencia.
▪▪ Que es una matriz de riesgo.
MAPA CONCEPTUAL
Evaluación del Dpto. de Sistemas
BIBLIOGRAFÍA
BIBLIOGRAFÍA
Asociación Española de Normalización y Certificación. (2016). AENOR. Ob-
tenido de www.aenor.es
Braga, G. (5 de 1 de 2015). www.Isaca.org. Obtenido de COBIT 5 aplicado al siste-
ma de registro contable informático argentino: http://www.isaca.org/
COBIT/focus/Pages/COBIT-5-Applied-to-the-Argentine-Digital-Accounting-
System-Spanish.aspx
Carlos Muñoz Razo. (2002). Auditoría en sistemas computacionales. Pren-
tice Hall.
Deloitte. (2016). Encuesta 2016 sobre tendencias de Cyber riesgos y seguridad de la información en Latonoamé-
rica. Deloitte. Obtenido de https://www2.deloitte.com/ec/es/pages/deloitte-
analytics/articles/Informativo-gerencial-Deloitte-Ecuador.html
Hernández Sampieri, R., Fernández Collado, C., & Baptista Lucio, P.
(2010). Metodología de la investigación (Quinta ed.). México D.F.: McGraw Hill.
Information System Audit and Control Foundation. EEUU.
International Federation of Accountants. (2011). Normas Internaciona-
les de Auditoría y Control de Cálidad.
International Federation of Accountants. (2011). NIA 330.
ISACF COBIT. (s.f.) Control Objectives for Information and Related Technology,
the
ISO/IEC IS 27000. (s.f.) Reference Model of Data Management.
Mario G. Piattini, Emilio del Peso. (2001). Auditoría informática, un enfoque práctico (Se-
gunda ed.). Alfaomega RAMA.
Martínez, V. (30 de 11 de 2015). Auditool. Obtenido de http://auditool.org/
blog/auditoria-externa/232-icomo-realizar-procedimientosanaliticos-sus-
tantivos-de-forma-efectiva
Murdick Robert, Munson John.(2000). Sistemas de Información Administrativo (Segunda
ed.). México D.F.: Prentice Hall.
PricewaterhouseCoopers. (2014). La auditoría del futuro y el futuro de la auditoría. España:
PricewaterhouseCoopers.
Quintero Gomez Luisa. (2015). En Modelo basado en ITIL para la gestión de los servicios de TI (pág.
18). Colombia: Universidad Autónoma de Manizales - Facultad de Ingenie-
ría, Maestría en Gestión y Desarrollo de Proyectos de Software.
Sánchez Peña Juan Jose, F. V. (2013). ITIL, COBIT and EFQM: Can They Work
Together? International Journal of Combinatorial Optimization Problems and Informatics Morelos, México, 62.
Sanchéz-Henarejos - et al. (2014). Guía de buenas prácticas de seguridad
informática en el tratamiento de datos de salud para el personal sanitario
en atención primaria. Revista Elsevier Doyma, España, 214-222.
Soto Peñafiel Bernardo. (abril de 2016). La auditoría y las TI. El futuro de la
auditoría. (I. M. Públicos, Ed.) Revista de Conatduría Pública.
Superintendencia de Compañías. (2008).Resolución No. 08.G.DSC.010 de
2008.11.20, R.O. No. 498 de 2008.12.3.
Superintendente de Compañías. (s/f). Resolución No.06.Q.ICI.004, publica-
da en el Registro Oficial No. 348.
Esta edición de
Auditoría de sistemas informáticos. Enfoque
metodológico,
se imprimió en 2017,
en la ciudad de Guayaquil, Ecuador.
Para su composición se emplearon las tipografías

PF Din Text Pro
–en sus variantes Display, Condensed y Compresed–,
del diseñador griego PanosVassiliou,
Fedra Serif B Pro
–en sus variantes BOOK, MEDIUM y BOLD–,
del holandés Peter Bilak;
y Wingding –en su variante Regular–
de los norteamericanos Kris Holmes y Charles Bigelow.

PBarberán - Auditoría de Sistemas Informáticos. Enfoque Metodológico PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

PBarberán - Auditoría de Sistemas Informáticos. Enfoque Metodológico PDF

Caricato da

Copyright:

Formati disponibili

AUDITORÍA DE SISTEMAS INFORMÁTICOS.

SOBRE LA PRESENTE EDICIÓN

implementadas, y la evaluación de los controles y nivel de seguridad existente

Probablemente, la mayor dificultad que tienen los auditores internos, las

CPA RAÚL G. ORTIZ.

A mi madre Genoveva y mi tía Lucila, siempre estarán en mi corazón.

A Fernando Accini Saavedra, por haberme apoyado en este mundo

A la Universidad Católica Santiago de Guayaquil, por su apoyo

La razón fundamental es que auditoría de sistemas es de aquellos temas

▪▪ Leer revistas de tecnología que existen en el mercado.

Lo que se conseguirá será familiarizarse con conceptos de sistemas, con lo

ESTRUCTURA DEL LIBRO

▪▪ Evaluación de las aplicaciones.

OBJETIVOS DE ESTE LIBRO

y en el Departamento de Sistemas, estructurando metodológicamente planes

▪▪ Obtener un conocimiento del concepto de la auditoría de siste-

▪▪ Utilizar una metodología para el levantamiento de información

Emplearse también como material de referencia en la formación de audito-

▪▪ Conocimiento del negocio.

Con respecto al conocimiento del negocio, actividad que no se desarrolla en el

TEMA 1: LAS NORMAS INTERNACIONALES DE INFORMACIÓN FINANCIERA (NIIF)

▪▪ Información financiera fiable y razonable para la toma de de-

▪▪ Modificar los manuales y políticas contables.

▪▪ Cambiar los software y sistemas de contabilidad existentes ajus-

TEMA 2: IMPORTANCIA DE LA AUDITORÍA DE SISTEMAS

▪▪ Los datos procesados por la aplicación de TI en donde la IPE se

La información añadida o cambiada (incluidos nuevos cálculos o clasificacio-

El auditor financiero normalmente aplica procedimientos para mitigar

▪▪ Confirmaciones de saldos con terceros.

TEMA 3: CONCEPTO DE AUDITORÍA DE SISTEMAS

TEMA 4: LEVANTAMIENTO DE INFORMACIÓN

▪▪ Conocimiento del negocio.

4.1 CONOCIMIENTO DEL NEGOCIO

4.2. CONOCIMIENTO DEL DEPARTAMENTO DE SISTEMAS

4.2.1 METODOLOGÍA PROPUESTA

▪▪ Investigar sobre el tema a revisar.

Al utilizar la presente metodología cumplimos con los siguientes objetivos:

▪▪ Estar preparado para la reunión, tema fundamental cuando

4.2.2 DESARROLLO DE LA METODOLOGÍA PROPUESTA PARA OBTENER UN CONOCIMIENTO DEL DEPARTAMENTO

▪▪ Tipos de estructuras organizativas que pueden aplicarse al

▪▪ Principales riesgos en un Dpto. de Sistemas.

La siguiente actividad dentro de la metodología es solicitar información al

▪▪ Organigrama del Dpto. de Sistemas.

En conclusión, podemos indicar que lo investigado y la información solicitada

1. La primera situación que se puede presentar es que existan

Estos serían puntos considerados en la reunión con el responsable del Dpto.

▪▪ Por qué no han sido considerados.

Como ejemplo detallamos: en lo investigado se indica que un riesgo en el

En estos casos se debería preguntar al responsable del Dpto.de Sistemas:

▪▪ Por qué lo incluyó.

▪▪ Responsable del Dpto.de Sistemas.

El número de preguntas para el responsable del Dpto.de Sistemas van a ser

▪▪ Solicitar una explicación de la información proporcionada por

▪▪ Por qué no lo tienen, sea por falta de presupuesto, o porque

▪▪ Qué aplicaciones o sistemas se utilizan en el área.

▪▪ Si han existido fraudes con apoyo de los sistemas de computa-

Reunirse con los involucrados: esta actividad no debería causar inconvenien-

a. Responsable del Dpto. de Sistemas.

Es importante que al iniciar cada reunión se detalle el objetivo de la reunión

▪▪ Diferencias o aportes de los conceptos investigados versus lo deta-

Estas diferencias que ustedes pueden identificar en base a su investigación y

▪▪ Dudas e inquietudes sobre la Metodología propuesta.

Cada duda o inquietud que se presente, deberían investigarla y ampliar sobre