Clases de Auditoria Informatica FINAL

Apuntes para Clases de
AUDITORÍA INFORMÁTICA
Prof. Jorge Antonio Fernández F. - Auditor de Sistemas de Información 1

conintegral@gmail.com
www.ruoti.com.py
2 Material editado para el desarrollo de las clases de postgrado de FOTRIEM

y otros que deseen utilizarlo con mención de la fuente.

www.ruoti.com.py
EDITORA
© EMPRENDIMIENTOS NORA RUOTI S.R.L.
Tte. Héctor Vera Nº 1761 e/ Bélgica y Viena - Villa Morra - Asunción
Teléfonos: (595 21) 660 088 R.A. Fax: (595 21) 612 753 www.ruoti.com.py
Coordinación General y Elaboración

Nora Lucía Ruoti Cosp
nrc@noraruoti.com.py
Autor
Ing. Jorge Antonio Fernández Franco
Cel.: (0971) 309351 - (0982) 976406
Edición General
Mauro Mascareño
mauro@noraruoti.com.py
Diseño y Diagramación
Gustavo Ravetti
publicidad@noraruoti.com.py
Impresión
A.G.R. Servicios Gráficos S.A.
Distribución y Ventas:
Emprendimientos Nora Ruoti S.R.L.
Marzo 2011
Asunción - Paraguay
El presente material forma parte de la Colección de Apuntes para Clases desarrollado por
los profesores de diversas cátedras en el Instituto Superior de Formación Tributaria y
Empresarial (FOTRIEM). El contenido del mismo es didáctico e ilustrativo. La Editora ni
el autor se responsabilizan por las consecuencias de su uso.
En caso de dudas, comunicarse con el Centro de Atención al Cliente de Emprendimientos

Nora Ruoti SRL. Tel.: (595 21) 660 088 R.A.
emprendimientos@noraruoti.com.py

Presentación del Material
Cuando hablamos de “Auditoría Informática”, creo que a Uds le puede pasar lo

mismo que yo he pensado. Yo no entiendo nada de computadoras, tengo mi técnico
y él me arregla todo. ¿Para qué se debe conocer este tema?
Algunos auditores más responsables y versados en la materia, en lugar de utilizar

simplemente una Planilla Excel para cruzar datos, han adquirido la poderosa
herramienta “COBIT” u otra similar.
Es allí donde nos damos cuenta el gran aporte de las herramientas informáticas para
el trabajo de auditoría, contabilidad y para la administración general del Instituto.
Sin embargo, el Módulo de Auditoría Informática de nuestro Post Grado en Auditoría

y Master en Impuestos y Auditoría ha destinado 30 horas cátedras a tener una noción
de lo que se debe controlar en un proceso de auditoría general de una empresa.
Es como recordarnos los temas básicos y elementales, pero no por ello menos
importantes. Debo reconocer que he leído este material preparado brillantemente
por el Profesor Jorge Antonio Fernández, varias veces y cada vez me sorprendía
más y más lo que que se puede “descubrir” con simples cruces o “los riesgos” a
los que estamos expuestos.
La riqueza de este material es invalorable, pues en sus 10 Capítulos el Profesor Jorge

Fernández no solamente muestra su gran conocimiento sobre la materia, sino su
calidad de persona quien “sin egoísmo y restricciones” brinda todo a sus alumnos:
Desde los aspectos teóricos más relevantes y sobre todo los aspectos prácticos
como ser: cuestionarios, papeles de trabajo, check list e indicaciones prácticas.
Los alumnos deben realizar en clase el análisis de 15 “Casos Prácticos” extraídos

de hechos de la vida real. Como profesionales o como empresarios, al leer los
mismos, les aseguro que “no dormirán tranquilos” porque los fraudes, las bombas
lógicas y exposiciones a hackers que se comentan, se aplican en su mayoría en
cada una de nuestras empresas, independientemente al tamaño de las mismas.
www.ruoti.com.py
Hemos complementado el libro con un capítulo que transcribe las reglamentaciones
más importantes de la Subsecretarìa de Estado de Tributación a fin de dar
cumplimiento a las exigencias de la Resoluciòn Nº 412/04 y sus modificaciones
que regulan la registración contable y su empleo por medios computacionales.
El profesor también ha confeccionado especialmente los “papeles de trabajo”
aplicables para el efecto.
Adicionalmente, y a los efectos didácticos se adjunta un CD que contiene el Manual

de COBIT y el Manual del Banco Central del Paraguay.
Como en los demás ejemplares de esta colección, también se encuentran

disponibles los DVD de las clases presenciales del profesor y que forma parte de
nuestro sistema e-learning.
Si aún no se ha unido a nuestro selecto grupo de profesionales altamente capacitados,

y piensa que no tiene tiempo para capacitarse, le decimos que con nuestro sistema
de aprendizaje con DVD’s de capacitación, libros preparados especialmente para
cada materia y el foro de discusión, esa es la “mejor excusa” para aquellos que no
desean distinguirse de los demás logrando no solamente ventajas profesionales,
sino también satisfacción personal. Los invito a tomar el desafío.
Nora Lucía Ruoti Cosp

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Agradecemos a SYS&CON por la información proveída

para este material, especialmente como representante de
MAYCOR COBIT.

Índice General
Capítulo I
La Auditoría de Sistemas de Información
1. La Auditoría de Sistemas de Información 25

2. Nacimiento de la Auditoría 27
3. El alcance de la Auditoría de Sistemas de Información 28
3.1. Control de integridad de registros 28
3.2. Control de validación de errores 28
4. Características de la Auditoría de Sistemas de Información 28
5. Síntomas de necesidad de una Auditoría de Sistemas de
Información 29
5.1. Síntomas de descoordinación y desorganización 29
5.2. Síntomas de mala imagen e insatisfacción de los usuarios 29
5.3. Síntomas de debilidades económico-financiero 30
5.4. Síntomas de Inseguridad: Evaluación de nivel de riesgos 30
5.5. Continuidad del Servicio. 30
5.6. Centro de Proceso de Datos fuera de control. 30
5.7. Planes de Contingencia 30
6. Tipos y clases de Auditoría de Sistemas de Información 31
7. Auditoría Informática de Explotación 32
7.1. Control de Entrada de Datos 32
7.2. Planificación y Recepción de Aplicaciones 33
7.3. Centro de Control y Seguimiento de Trabajos 33
7.4. Operación. Salas de Ordenadores 33
7.5. Centro de Control de Red y Centro de Diagnosis 34
8. Auditoría Informática de Desarrollo de Proyectos o Aplicaciones 34

www.ruoti.com.py
9. Auditoría Informática de Sistemas 37

9.1. Sistemas Operativos 37
9.2. Software Básico 37
9.3. Software de Teleproceso (Tiempo Real) 38
9.4. Tunning 38
9.5. Optimización de los Sistemas y Subsistemas 38
9.6. Administración de Base de Datos 39
9.7. Investigación y Desarrollo 39
10. Auditoría Informática de Comunicaciones y Redes 40
11. Auditoría de la Seguridad Informática 41
11.1. Elementos que comprenden el Sistema Integral de Seguridad 42
11.2. Pruebas en la Auditoría Informática 43
11.3. Principales herramientas de las que dispone el auditor informático 44
12. Perfil del Auditor de Sistemas de Información 44
13. Escenarios de la Auditoría de Sistemas de Información 45
13.1. Ambiente de Informática 45
13.2. Organización 45
13.3. Aplicativos 45
13.4. Base de datos 46
13.5. Redes de comunicación y micro computadores 46
13.6. Desarrollo de sistemas 46
14. Elementos de la Informática 46
14.1. Elemento Físico (Hardware) 46
14.2. Elemento lógico (Software) 46
14.3. El elemento humano (personal informático) 47
14.4. Sistemas de Información 48
14.5. Usos de los Sistemas de Información 50

Capítulo II
Auditoría en el Ambito Judicial - Auditoría Forense
1. Definición y alcance de la auditoría forense 51

2. Auditoría forense: ¿Quiénes demandan este servicio? 52
3. Evidencia Digital 52
4. Características de una evidencia digital 53
Capítulo III
Estandares Internacionales - COBIT (Control Objectives for Information and
related Technology), Cobit versión 4.1 - Derechos de autor (Copyright ©) 2007 por el IT
Governance Institute.
1. COBIT, Misión y Visión 54

1.1. Misión 54
1.2. Visión 55
2. COBIT cubre cuatro dominios 55
2.1. Planificación y Organización 55
2.2. Adquisición e Implementación 56
2.3. Servicios y Soporte 56
2.4. Monitoreo 57
3. Aceptabilidad General del COBIT 58
3.1. Usuarios interesados en COBIT 59
4. Marco de Trabajo completo de Cobit 60
5. Navegación en el marco de trabajo de Cobit 61
6. Introducción a los componentes esenciales de cobit 61
6.1. Formas de visualizar el contenido del desempeño del proceso 62
6.2. Usuarios de los Componentes de COBIT 63
7. Areas de Enfoque del Gobierno de TI 64
7.1. Directrices Gerenciales 64

www.ruoti.com.py
Capítulo IV
ITIL (Biblioteca de Infraestructuras de Tecnologías de Información)
1. Concepto 66
2. El alcance de ITIL 66
3. Niveles de certificación ITIL para profesionales 67
Capítulo V
MCIIEF - Manual de Control Interno Informático para Entidades Financieras de la
Superintendencia de Bancos, del Banco Central del Paraguay
1. Planificación y Organización 68
2. Adquisición e Implementación 70
3. Producción y Servicios 71
4. Monitoreo 73
5. Indíce del Manual de Control Interno Informático para Entidades
Financieras de la Superintendencia de Bancos 73
Capítulo VI
Modelo de Redacción de NCI
1. Modelo de NC 01 - Evaluación de Estructura de TI 76

1.1. Ubicación estructural del área de servicios de TI 76
2. Organización de la Estructura de TI 77
2.1. Inexistencia de un responsable del área de ti de la dependencia
Jefe/Encargado 77
2.2. Inexistencia de un Administrador de bd 78
2.3. Inexistencia de un Administrador de Redes 78
2.4. Inexistencia de un Administrador de Sistemas 79
2.5. Inexistencia de una estructura de soporte técnico/asistencia a
usuarios 79

2.6. Inexistencia de una estructura de desarrolladores internos de

sistemas 80
2.7. Nombramiento del administrador de seguridad de ti 80
2.8. Separación de funciones - Personal clave de tecnología de
información 81
2.9. Definición de propietario de datos, determinación de
responsabilidades 82
3. Evaluación de Gestión de TI - Gerenciamiento 82
3.1. Plan de ti a largo plazo, enfoque y estructura, aprobación 82
3.2. Plan de ti a corto plazo, planificación de la capacidad de la
infraestructura tecnológica 84
3.3. Cambios al plan de ti a largo plazo 84
3.4. Evaluación permanente del plan estratégico de tecnología de
información 85
3.5. Metodología de Control de Adquisiones - Procedimientos 85
4. Sistemas de Información 86
4.1. Integración de módulos – ERP (Los Sistemas del tipo ERP
(Enterprise Resource Planning) se han definido como un
sistema global de planificación de los recursos y de gestión de la
información) 86
4.2. Control de versiones del código fuente y autorización para el
traspaso al entorno de producción 87
4.3. Pruebas del sistema en forma paralela antes del traspaso a
producción 87
4.4. Prueba de aceptación final antes del traspaso a producción 88
4.5. Estructura de desarrollo paralelo – servidor independiente 88
4.6. Procedimientos aplicados ante la eventual caída del sistema 89
4.7. Mecanismo para el cierre diario del sistema – participantes –
aprobación 89
4.8. En casos de ajustes eventuales de registros ya procesados, ¿cómo
se realiza y quien autoriza? 90

www.ruoti.com.py
5. Evaluación del desarrollo y mantenimiento de sistemas - Equipo

Interno 91
5.1. Procedimientos de controles de seguridad aplicados en la etapa de
análisis y diseño del sistema 91
5.2. Seguridad en los sistemas de aplicación, validación de datos de
entrada 91
5.3. Política de utilización de controles criptográficos, encriptación 92
5.4. Protección de los datos de prueba del sistema, aplicación de otras
bd para pruebas 93
5.5. Control de cambios a datos operativos, manipulación de datos a
través de un mgbd 94
5.6. Mecanismo, registro y control de acceso a las bibliotecas de
programas fuentes 94
6. Evaluación del desarrollo y mantenimiento de sistemas –
consultoría externa 95
6.1. Acuerdos de licencias, propiedad de código y derechos conferidos 95
6.2. Requerimientos contractuales con respecto a la calidad del código
y la existencia de garantías. 96
6.3. Procedimientos de certificación de la calidad, que incluyan
auditorías internas de sistemas. 97
6.4. Acuerdos de custodia de las fuentes del software. 97
7. Seguridad Física 98
7.1. Disponibilidad de los planes de continuidad de las actividades de
ti (plan de contingencia) 98
7.2. Ensayo, Mantenimiento y Evaluación de los Planes de Continuidad
de Ti (Pruebas) 99
7.3. Aprobación por la alta gerencia del plan de contingencias 100
7.4. Disponibilidad del plan de seguridad TI 101
7.5. Aprobación del Plan de Seguridad de TI 102
8. Evaluación de la Sala de Servidores - Data Center y Alta
Disponibilidad 103

8.1. Sala de servidores independiente y restricción de accesos, controles

de acceso físico. 103
8.2. Restricción de accesos a la sala de servidores, bitácora de accesos 104
8.3. Evidencia del mantenimiento de equipos preventivos 104
8.4. Lista de Servidores 105
8.5. Servidor espejado - Fuera del recinto principal 106
8.6. Arquitectura Servidor - Clon 106
8.7. Sistema Operativo Server - Propietario - Libre 107
8.8. Rack de protección, protegido con llave 107
8.9. Cableado de red ordenado, identificado por usuarios 108
8.10 Certificado del Cableado de Red 108
8.11. Identificación de materiales inflamables, en el recinto del Data
Center 109
8.12. Disponibilidad de detectores de humo y calor 110
8.13. Extintores especiales contra incendios 110
8.14. Licencias de los sistemas operativos de redes 110
8.15. Disponibilidad del Sistema de puesta a tierra 111
8.16. Suministro de energía eléctrica, UPS 111
8.17. Suministro de energía eléctrica, generador de electricidad 112
9. Relevamiento de Inventarios y manuales técnicos 113
9.1. Manuales de usuarios - Impresos - Interactivos 113
9.2. Manuales DFD, UML, AOO – Disponibles - Actualizados 113
9.3. Manuales de ER – Disponibles - Actualizados 114
9.4. Disponibilidad de inventario de activos – Hardware - Actualizado 114
10. Evaluación de la Administración de Proyectos 115
10.1 Definición y esquema de Administración de Proyectos de TI 115
10.2 Evidencia de solicitud de prórroga 115
10.3. Solicitud de reajustes 116

www.ruoti.com.py
10.4. Solicitud de recepción técnica provisoria 116

10.5. Solicitud de recepción técnica definitiva 117
10.6. Contrato de mantenimiento hardware- vencimiento- cronograma 117
10.7. Contrato de mantenimiento software- vencimiento 118
10.8. Contrato de licencias de software propietario 118
Capítulo VII
Ejercicios Prácticos
1. Caso: Omega Engineering INC: 119

1.1. Tema: Fallas en la seguridad y el delito computacional 119
1.2. Preguntas del estudio del caso 121
2. Otros casos de fraudes y abusos computacionales 121
2.1. Presentación del ejercicio 121
2.2. El Caso del Guardia Honesto 122
2.3. El Caso de la Cinta baleada 122
2.4. El Caso del Ataque Terrorista 123
2.5. El caso de las Cintas de Hewlett Packard 123
2.6. El caso del computador que se iba al agua 123
2.7. El caso de la lista de clientes robada 124
2.8. El caso del sobre tiempo 124
2.9. El Caso del Historial Clínico 125
2.10. El caso del Seguro de Cesantía 125
2.11. El caso de la Demanda a la Víctima 126
2.12. El caso del fraude a Texaco 127
2.13. El caso del SUPERZAP 127
2.14. El Empleado Inexistente 128
2.15. El Caso del Ataque Terrorista 128
2.16. El caso de los negocios extras 129

2.17. El Caso del Correo de Votantes 129

3. Práctica de auditoría de sistemas de información 130
3.1. Fallas en la seguridad y el delito computacional 130
3.2. Trabajo a desarrollar 131
4. Ejercicio Práctico de Proceso de Auditoría 132
Capítulo VIII
Directrices y papeles de trabajo para la realización de una Auditoría Informática
1. Pasos a seguir para recomendación de soluciones 136

2. Modelo de Nota de Control Interno 136
3. Papeles de trabajo de controles de TI 137
4. Modelo de Propuesta de Servicios 154
4.1. Objetivo 154
4.2. Aspectos relevantes del plan de auditoría 155
4.3. Alcance de los servicios 155
4.4. Metodología 156
4.5. Presentación de Informes 156
4.6. Validéz de la oferta 156
4.7. Honorario y forma de pago 157
5. Modelo de Carta Gerencial 157
5.1. Objetivo General 157
5.2. Objetivo Específico 157
Capítulo IX
Glosario de Términos Técnicos
1. Glosario de Términos Técnicos 159

www.ruoti.com.py
Capítulo X
Anexos
1. Disposiciones reglamentarias sobre la Registración Contable por

medios computacionales. Matriz de verificación para el Auditor
Informático. 174
1.1. Resolución Nº 412/04. Por la cual se adecuan a la legislación
vigente las disposiciones reglamentarias de registración contable
y de su empleo por medios computacionales. 174
1.2. Resolución Nº 535/04. Por la cual se aclara disposiciones
contenidas en la resolución nº 412 del 1 de octubre de 2004
“por la cual se adecuan a la legislación vigente las disposiciones
reglamentarias de registración contable y de su empleo por medios
computacionales”. 180
1.3. Resolución General Nº 23/09. Por la cual se aclaran aspectos
relativos a los Certificados de Cumplimiento Tributario, a la
utilización de medios computacionales para la registración
contable, a la comunicación de cesión de cuotas parte y de acciones
a la recepción y gestión de las solicitudes de constancias de no
retención de impuestos, se modifican los Artículos 8º y 13º de la
Resolución Nº 412/04 y los Artículos 2º y 18º de la Resolución
General Nº 15/07, se precisa la forma de llenado del Formulario Nº
108 – Impuesto a la Renta y se derogan los Artículos 9º y 11º de la
Resolución Nº 412/04 y el Art. 5º de la Resolución Nº 535/04. 182
1.4. Cuestionario para verificación del cumplimiento de la RG Nº
412/04. 183

Programa de Postgrado
Especialización en Auditoría
Módulo Auditoría Informática
Fundamentación
• Independientemente del enfoque del control interno (de confiabilidad o sustan-

tivo), si existe información significativa para la auditoría que es procesada por
una computadora, debemos obtener un entendimiento de la instalación y de los
controles generales de un área informática existente en la entidad auditada.
ÍNDICE GENERAL
• Cuando hemos efectuado una planeación del enfoque de confiabilidad, efectuamos
pruebas de los controles generales para hacer una evaluación sobre la efectividad
de los mismos.
• El auditor encargado es responsable de obtener entendimiento y recopilar infor-
mación descriptiva sobre la instalación del área informática y de los controles
generales que en ella son realizados.
• Normalmente el entendimiento y la información descriptiva acerca de la ins-
talación y de los controles generales se obtienen por medio de indagación, Ob-
servación e inspección limitada de documentos. Dichos procedimientos también
puede proveer evidencia de la auditoría sobre la efectividad del diseño y la ope-
ración de los procedimientos pertinentes de control y servir prueba de control.
Objetivos
• Proveer los conceptos, conocimientos y las herramientas, necesarios para un

acabado dominio para el desarrollo de una auditoría informática.
• Disponer de conocimientos básicos y avanzados de los conceptos de Auditoría In-
formática.
• Planear una auditoría como proyección para un seguimiento de los puntos
relevados.

www.ruoti.com.py
• Aplicar el conocimiento como una herramienta para la especialización en el

campo de la Auditoría Informática.
• Acompañar el desarrollo de sistemas con la inclusión de la auditoría como mé-
todo para verificación.
• Promover la investigación aplicada en el área de la Auditoría de los Sistemas
de Información.
• Fomentar la divulgación de trabajos de investigación en la seguridad del mane-
jo de la información a través de medios informáticos.
• Agrupar a profesionales, académicos y estudiantes con interés en mantenerse al
día en el tema de Auditoría y control de los Sistemas de Información.
• Colaborar en el intercambio de información actualizada en la seguridad y con-
trol de los Sistemas de Información.
• Estar capacitado para elaborar y leer un dictamen de auditoría.
Metodología
El desarrollo del curso estará sujeto a los siguientes lineamientos metodológicos

• El curso enfoca los diversos conocimientos básicos y avanzados de los concep-
tos de Auditoría informática, así como las técnicas para la realización de una
auditoría informática.
• Se enfocarán diversos ejemplos de auditorías desarrollados en nuestro mercado,
así como ejemplos de casos prácticos.
• Se dará especial énfasis a los métodos de auditoría aplicado en las entidades
financieras y las normas establecidas por el Banco Central del Paraguay, a tra-
vés del MCIIEF (Manual de control interno para entidades financieras).
• Será desarrollado una auditoría real a empresa de nuestro medio, conside-
rando las áreas del entorno informático con la elaboración de los papeles de
trabajos y los informes respectivos, el trabajo será encuadernado y presentado
en clase, sobre esta base considerará la evaluación académica.
• Todos los trabajos de investigaciones, serán presentados en plenaria, así como
la documentación y encuadernación, y entrega en medios magnéticos.

Contenido
Capítulo I
1.1 La Auditoría de Sistemas de Información
1.2 La auditoría
1.3 El alcance de la Auditoría de Sistemas de Información
1.4 Características de la Auditoría de Sistemas de Información
1.5 Síntomas de necesidad de una Auditoría de Sistemas de Información
1.6 Tipos y clases de Auditoría de Sistemas de Información
1.7 Auditoría Informática de Explotación
1.8 Auditoría Informática de Desarrollo de Proyectos o Aplicaciones
1.9 Auditoría Informática de Sistemas
1.10 Auditoría Informática de Comunicaciones y Redes
1.11 Auditoría de la Seguridad informática
1.12 Perfil del Auditor de Sistemas de Información
Capítulo II
2.1. Escenarios de la Auditoría de Sistemas de Información
2.1.1 Ambiente de Informática
2.2.2 Organización
2.2.3 Aplicativos
2.2.4 Base de datos
2.2.5 Redes de comunicación y micro computadores
2.2.6 Desarrollo de sistemas
Capítulo III
3. Auditoría en el ambito Judicial - Auditoría Forense
3.1 Definición y alcance de la auditoría forense

3.2 Auditoría forense: ¿quiénes demandan este servicio?
3.3 Evidencia Digital
3.4 Características de una evidencia digital

www.ruoti.com.py
Capítulo IV
4. Estandares Internacionales - COBIT
4.1 COBIT cubre cuatro dominios
4.1.1 Planificación y Organización
4.1.2 Adquisición e Implementación
4.1.3 Servicios y Soporte
4.1.4 Monitoreo
Capítulo V
Programa de auditoría de evaluación de TI y descripción de indicadores
Cuestionario 01 - Evaluación de la estructura

Cuestionario 02 - Sistemas de Información
Cuestionario 03 - Seguridad Lógica
Cuestionario 04 - Seguridad Física
Cuestionario 05 - Documentaciones de TI
Cuestionario 06 - Evaluación de RR.HH.
Modelo de propuesta de servicio
Modelo de carta gerencial
Casos prácticos
Caso I
Caso II
Caso III
Caso IV
Sistema de Evaluación
Las evaluaciones de los participantes están establecidas con base en un total de 100 puntos.
Estos puntos podrán otorgados de la siguiente manera:
No. Actividad Puntos

I Trabajo de investigación grupal y presentación en plenaria. 60

El trabajo contendrá los siguientes indicadores:

1 – Carátula
2 – Índice
3 – Introducción
4 – Cuerpo:
Desarrollo de una auditoría real, con los siguientes
indicadores:
Propuesta de auditoría
Papeles de trabajo de auditoría de TI
Carta Gerencial
Desarrollo de las Notas de Control Interno de TI
5 – Conclusión
6 – Fuentes Consultadas
II Desarrollo del Caso Práctico I – II 15
III Desarrollo del Caso Práctico II - IV 25
Formato Del Trabajo
- Encuadernación tipo anillado/Archivo
- Hoja carta
- Letra Arial/Times New Roman, 16 para los títulos, 14
para los subtítulos, 12 para el cuerpo
Total Puntos 100
Actividades del Curso
A – Asistencia y Participación:
La asistencia y participación en clase es obligatoria, los alumnos deberán cumplir

con el porcentaje mínimo exigido por la institución. Si no se alcanzase el porcentaje
mínimo requerido perderá automáticamente los puntos asignados a este efecto. En
cuanto a la participación en clase, esta deberá ser Activa y Participativa.
Esto implica que los alumnos deberán emitir sus opiniones, criticas, experiencias,
anécdotas, sugerencias, etc. Todo esto dentro de un marco de respeto profesional
hacia los compañeros y el docente.

www.ruoti.com.py
B – Desarrollo de Trabajo
Será desarrollado una auditoría real a empresa del medio, considerando las áreas
del entorno informático con la elaboración de los papeles de trabajos y los informes
respectivos, el trabajo será encuadernado y presentado en clase, sobre esta base
considerará la evaluación académica, así mismo se desarrollará dos casos prácticos
presentado por el instructor y que será anexado al trabajo principal.
C- Resolución de Ejercicios en Equipos
Se resolverán en clase ejercicios de manera a disponer de prácticas en lo concerniente

a la auditoría de sistemas de información.
Cronograma tentativo de Clases
En lo posible trataremos de ceñirnos al siguiente cronograma de clases.
Clase Contenido Actividades

I Presentación del Curso, Objetivos, Metodología, Esquema Presentación-
de Trabajo y Evaluaciones. docente
Desarrollo de Contenido
La auditoría
I Presentación del Curso, Objetivos, Metodología, Esquema Presentación-
de Trabajo y Evaluaciones. docente
Desarrollo de Contenido
La auditoría
Presentación del curso, objetivos, metodología, esquema Presentación-
II de trabajo y evaluaciones. docente
Desarrollo de contenido
Escenarios de la auditoría de sistemas de información Presentación-
Ambiente de Informática docente
Organización

Aplicativos
Base de datos
Redes de comunicación y micro computadores
Desarrollo de sistemas
Auditoría en el ambito judicial - auditoría forense
Definición y alcance de la auditoría forense
Auditoría forense: ¿quiénes demandan este servicio?
Evidencia Digital
Características de una evidencia digital
Desarrollo de casos práctico I - II
III Estandares Internacionales - COBIT Presentación-
docente
COBIT cubre cuatro dominios
Planificación y Organización
Adquisición e Implementación
Servicios y Soporte
Monitoreo
Programa de Auditoría Informática
Programa de auditoría de evaluación de TI y descripción de
indicadores
Presentación-
Cuestionario 01 - Evaluación de la estructura
docente
Cuestionario 02 - Sistemas de Información
IV Programa de Auditoría Informática Presentación-
Programa de auditoría de evaluación de TI y descripción de docente
indicadores
Cuestionario 03 - Seguridad Lógica
Cuestionario 04 - Seguridad Física
Cuestionario 05 - Documentaciones de TI
Cuestionario 06 - Evaluación de RR.HH.
V Desarrollo y revisión de trabajos Trabajo en
grupo
VI Presentación de los trabajos de investigación Presentación-
en plenaria

www.ruoti.com.py
Bibliografía Adicional a este Material
Bibliografía Nacional
Sistemas de Información Gerencial, Walter Daniel Ovelar, Strategika Editora 2008

Asunción - Paraguay.
Manual de Información Técnica CISA de la ISACA. 2005 Information Systems audit.
And Control Association.
Programa de Auditoría Informática, 2005 – Procedimientos y Técnicas, AYCA –
Auditores y Consultores Asociados.
Bibliografía Extranjera
Lardent R. Alberto, 2001, Sistema de Información para la Gestión Empresarial,

Procedimientos, Seguridad y Auditoría, Argentina, Editorial Prentice Hall.
Lardent R. Alberto, 2001, Sistema de Información para la Gestión Empresarial,
Planeamiento, Tecnología y Calidad, Argentina, Editorial Prentice Hall.
Etchenique José Antonio, 1999, Auditoría Informática, México, Editorial Prentice
Hall.
Webgrafía
www.ilo.org/public/spanish/region
www.ub.es/geocrit
www.iso.org/iso
www.iso.org/iso/en/Standards
www.ieee.org
www.ieee.org.mx
www.computer.org
www.iee.org

Capítulo I
1. La Auditoría de Sistemas de Información
A finales del siglo XX, los Sistemas Informáticos se han constituido en las
herramientas más poderosas para materializar uno de los conceptos más vitales y
necesarios para cualquier organización empresarial, los Sistemas de Información de
la empresa.
La Informática hoy, está subsumida en la gestión integral de la empresa, y por eso las
normas y estándares propiamente informáticos deben estar, por lo tanto, sometidos a
los generales de la misma. En consecuencia, las organizaciones informáticas forman
parte de lo que se ha denominado el “management” o gestión de la empresa. Cabe
aclarar que la Informática no gestiona propiamente la empresa, ayuda a la toma de
decisiones, pero no decide por sí misma. Por ende, debido a su importancia en el
funcionamiento de una empresa, existe la Auditoría Informática.
El término de Auditoría se ha empleado incorrectamente con frecuencia ya que se ha

considerado como una evaluación cuyo único fin es detectar errores y señalar fallas.
A causa de esto, se ha tomado la frase “Tiene Auditoría” como sinónimo de que, en
dicha entidad, antes de realizarse la auditoría, ya se habían detectado fallas.
El concepto de auditoría es mucho más que esto. Es un examen crítico que se

realiza con el fin de evaluar la eficacia y eficiencia de una sección, un organismo,
una entidad, etc.
La palabra auditoría proviene del latín auditorius, y de esta proviene la palabra

auditor, que se refiere a todo aquel que tiene la virtud de oír.
Por otra parte, el diccionario Español Sopena lo define como: Revisor de Cuentas
colegiado. En un principio esta definición carece de la explicación del objetivo
fundamental que persigue todo auditor: evaluar la eficiencia y eficacia.
www.ruoti.com.py
De todo esto sacamos como deducción que la auditoría es un examen crítico pero
no mecánico, que no implica la preexistencia de fallas en la entidad auditada y que
persigue el fin de evaluar y mejorar la eficacia y eficiencia de una sección o de un
organismo.
Los principales objetivos que constituyen a la auditoría Informática son el control

de la función informática, el análisis de la eficiencia de los Sistemas Informáticos
que comporta, la verificación del cumplimiento de la Normativa general de la
empresa en este ámbito y la revisión de la eficaz gestión de los recursos materiales
y humanos informáticos.
El auditor informático ha de velar por la correcta utilización de los amplios recursos

que la empresa pone en juego para disponer de un eficiente y eficaz Sistema de
Información. Claro está, que para la realización de una auditoría informática eficaz,
se debe entender a la empresa en su más amplio sentido, ya que una Universidad, un
Ministerio o un Hospital son tan empresas como una Sociedad Anónima o empresa
Pública. Todos utilizan la informática para gestionar sus “negocios” de forma rápida
y eficiente con el fin de obtener beneficios económicos y de costos.
Por eso, al igual que los demás órganos de la empresa (Balances y Cuentas de
Resultados, Tarifas, Sueldos, etc.), los Sistemas Informáticos están sometidos al
control correspondiente, o al menos debería estarlo. La importancia de llevar un
control de esta herramienta se puede deducir de varios aspectos. He aquí algunos:
Las computadoras y los Centros de Proceso de Datos se convirtieron en blancos

apetecibles no solo para el espionaje, sino para la delincuencia y el terrorismo.
En este caso interviene la Auditoría Informática de Seguridad.
Las computadoras creadas para procesar y difundir resultados o información

elaborada pueden producir resultados o información errónea si dichos datos
son, a su vez, erróneos. Este concepto obvio es a veces olvidado por las
mismas empresas que terminan perdiendo de vista la naturaleza y calidad de
los datos de entrada a sus Sistemas Informáticos, con la posibilidad de que se
provoque un efecto cascada y afecte a Aplicaciones independientes. En este
caso interviene la Auditoría Informática de Datos.
Un Sistema Informático mal diseñado puede convertirse en una herramienta peligrosa

para la empresa: como las maquinas obedecen ciegamente a las órdenes recibidas y la
modelización de la empresa está determinada por las computadoras que materializan

los Sistemas de Información, la gestión y la organización de la empresa no puede
depender de un Software y Hardware mal diseñados.
Estos son solo algunos de los varios inconvenientes que puede presentar un Sistema
Informático, por eso, la necesidad de la Auditoría de Sistemas.
2. Nacimiento Auditoría
La auditoría nace como un órgano de control de algunas instituciones estatales y

privadas.
La función auditora debe ser absolutamente independiente; no tiene carácter

ejecutivo, ni son vinculantes sus conclusiones. Queda a cargo de la empresa
tomar las decisiones pertinentes. La auditoría contiene elementos de análisis,
de verificación y de exposición de debilidades y disfunciones. Aunque pueden
aparecer sugerencias y planes de acción para eliminar las disfunciones y
debilidades antedichas; estas sugerencias plasmadas en el Informe final reciben
el nombre de Recomendaciones.
Las funciones de análisis y revisión que el auditor informático realiza, puede chocar
con la psicología del auditado, ya que es un informático y tiene la necesidad de realizar
sus tareas con racionalidad y eficiencia. La reticencia del auditado es comprensible
y, en ocasiones, fundada. El nivel técnico del auditor es a veces insuficiente, dada la
gran complejidad de los Sistemas, unidos a los plazos demasiado breves de los que
suelen disponer para realizar su tarea.
Además del chequeo de los Sistemas, el auditor somete al auditado a una serie de
cuestionario. Dichos cuestionarios, llamados Check List, son guardados celosamente
por las empresas auditoras, ya que son activos importantes de su actividad. Las
Check List tienen que ser comprendidas por el auditor al pie de la letra, ya que si
son mal aplicadas y mal recitadas se pueden llegar a obtener resultados distintos a
los esperados por la empresa auditora. La Check List puede llegar a explicar cómo
ocurren los hechos pero no por qué ocurren.
El cuestionario debe estar subordinado a la regla, a la norma, al método. Sólo

una metodología precisa puede desentrañar las causas por las cuales se realizan
actividades teóricamente inadecuadas o se omiten otras correctas.

www.ruoti.com.py
El auditor sólo puede emitir un juicio global o parcial basado en hechos y situaciones
incontrovertibles, careciendo de poder para modificar la situación analizada por él
mismo.
3. El alcance de la Auditoría de Sistemas de Información
El alcance ha de definir con precisión el entorno y los límites en que va a desarrollarse

la auditoría informática, se complementa con los objetivos de ésta. El alcance ha
de figurar expresamente en el Informe Final, de modo que quede perfectamente
determinado no solamente hasta que puntos se ha llegado, sino cuales materias
fronterizas han sido omitidas.
Ejemplo: ¿Se someterán los registros grabados a un control de integridad exhaustivo*?

¿Se comprobará que los controles de validación de errores son adecuados y
suficientes*? La indefinición de los alcances de la auditoría compromete el éxito de
la misma.
3.1. Control de integridad de registros

Hay Aplicaciones que comparten registros, son registros comunes. Si una Aplicación
no tiene integrado un registro común, cuando lo necesite utilizar no lo va encontrar
y, por lo tanto, la aplicación no funcionaría como debería.
3.2. Control de validación de errores

Se corrobora que el sistema que se aplica para detectar y corregir errores sea
eficiente.
4. Características de la Auditoría de Sistemas de Información
La información de la empresa y para la empresa, siempre importante, se ha convertido

en un Activo Real de la misma, como sus Stocks o materias primas si las hay.
Por ende, han de realizarse inversiones informáticas, materia de la que se ocupa la
Auditoría de Inversión Informática.
Del mismo modo, los Sistemas Informáticos han de protegerse de modo global y
particular: a ello se debe la existencia de la Auditoría de Inversión Informática
en general, o a la auditoría de Seguridad de alguna de sus áreas, como pudieran ser
Desarrollo o Técnica de Sistemas.
Cuando se producen cambios estructurales en la Informática, se reorganiza de alguna

forma su función: se está en el campo de la Auditoría de Organización Informática.
Estos tres tipos de auditorías engloban a las actividades auditoras que se realizan
en una auditoría parcial. De otra manera: cuando se realiza una auditoría del área
de Desarrollo de Proyectos de la Informática de una empresa, es porque en ese
Desarrollo existen, además de ineficiencias, debilidades de organización, o de
inversiones, o de seguridad, o alguna mezcla de ellas.
5. Síntomas de necesidad de una Auditoría de Sistemas de Información
Las empresas acuden a las auditorías externas cuando existen síntomas bien
perceptibles de debilidad. Estos síntomas pueden agruparse en clases:
5.1. Síntomas de descoordinación y desorganización
No coinciden los objetivos de la Informática de la Compañía y de la propia

Compañía.
Los estándares de productividad se desvían sensiblemente de los promedios

conseguidos habitualmente.
[Puede ocurrir con algún cambio masivo de personal, o en una reestructuración

fallida de alguna área o en la modificación de alguna Norma importante]
5.2. Síntomas de mala imagen e insatisfacción de los usuarios
No se atienden las peticiones de cambios de los usuarios. Ejemplos: cambios de

Software en los terminales de usuario, resfrecamiento de paneles, variación de los
ficheros que deben ponerse diariamente a su disposición, etc.
No se reparan los desperfectos del Hardware ni se resuelven incidencias

en plazos razonables. El usuario percibe que está abandonado y desatendido
permanentemente.
No se cumplen en todos los casos los plazos de entrega de resultados periódicos.

Pequeñas desviaciones pueden causar importantes desajustes en la actividad del
usuario, en especial en los resultados de Aplicaciones críticas y sensibles.
www.ruoti.com.py
5.3. Síntomas de debilidades económico-financiero
Incremento desmesurado de costos.

Necesidad de justificación de Inversiones Informáticas (la empresa no está
absolutamente convencida de tal necesidad y decide contrastar opiniones).
Desviaciones Presupuestarias significativas.
Costos y plazos de nuevos proyectos (deben auditarse simultáneamente a Desarrollo
de Proyectos y al órgano que realizó la petición).
5.4. Síntomas de Inseguridad: Evaluación de nivel de riesgos
Seguridad Lógica.
Seguridad Física.
Confidencialidad.
Los datos son propiedad inicialmente de la organización que los genera. Los
datos de personal son especialmente confidenciales.
5.5. Continuidad del Servicio.
Es un concepto aún más importante que la Seguridad. Establece las estrategias de

continuidad entre fallos mediante Planes de Contingencia* Totales y Locales.
5.6. Centro de Proceso de Datos fuera de control.

Si tal situación llegara a percibirse, sería prácticamente inútil la auditoría. Esa es la
razón por la cual, en este caso, el síntoma debe ser sustituido por el mínimo indicio.
5.7. Planes de Contingencia

Por ejemplo, la empresa sufre un corte total de energía o explota, ¿Cómo sigo
operando en otro lugar? Lo que generalmente se pide es que se hagan Backups de la
información diariamente y que aparte, sea doble, para tener un Backup en la empresa
y otro afuera de ésta.
Una empresa puede tener unas oficinas paralelas que posean servicios básicos (luz,
teléfono, agua) distintos de los de la empresa principal, es decir, si a la empresa
principal le proveía teléfono Telecom, a las oficinas paralelas, Telefónica. En este

caso, si se produce la inoperancia de Sistemas en la empresa principal, se utilizaría
el Backup para seguir operando en las oficinas paralelas.
Los Backups se pueden acumular durante dos meses, o el tiempo que estipule la
empresa, y después se van reciclando.
6. Tipos y clases de Auditoría de Sistemas de Información
El departamento de Informática posee una actividad proyectada al exterior, al

usuario, aunque el “exterior” siga siendo la misma empresa. He aquí, la Auditoría
Informática de Usuario. Se hace esta distinción para contraponerla a la informática
interna, en donde se hace la informática cotidiana y real. En consecuencia, existe una
Auditoría Informática de Actividades Internas.
El control del funcionamiento del departamento de informática con el exterior,

con el usuario se realiza por medio de la Dirección. Su figura es importante, en
tanto en cuanto es capaz de interpretar las necesidades de la Compañía.
Una informática eficiente y eficaz requiere el apoyo continuado de su Dirección
frente al “exterior”. Revisar estas interrelaciones constituye el objeto de la
Auditoría Informática de Dirección. Estas tres auditorías, mas la auditoría
de Seguridad, son las cuatro Áreas Generales de la Auditoría Informática más
importantes.
Dentro de las áreas generales, se establecen las siguientes divisiones de Auditoría

Informática: de Explotación, de Sistemas, de Comunicaciones y de Desarrollo
de Proyectos. Estas son las Áreas Especificas de la Auditoría Informática más
importantes.
Áreas Generales
Áreas Específicas
Interna Dirección Usuario Seguridad
Explotación
Desarrollo
Sistemas
Comunicaciones
Seguridad

www.ruoti.com.py
Cada Área Específica puede ser auditada desde los siguientes criterios
generales:
Desde su propio funcionamiento interno.

Desde el apoyo que recibe de la Dirección y, en sentido ascendente, del grado
de cumplimiento de las directrices de ésta.
Desde la perspectiva de los usuarios, destinatarios reales de la informática.
Desde el punto de vista de la seguridad que ofrece la Informática en general
o la rama auditada.
Estas combinaciones pueden ser ampliadas y reducidas según las características
de la empresa auditada.
7. Auditoría Informática de Explotación
La Explotación Informática se ocupa de producir resultados informáticos de

todo tipo: listados impresos, ficheros soportados magnéticamente para otros
informáticos, ordenes automatizadas para lanzar o modificar procesos industriales,
etc. La explotación informática se puede considerar como una fabrica con ciertas
peculiaridades que la distinguen de las reales. Para realizar la Explotación Informática
se dispone de una materia prima, los Datos, que es necesario transformar, y que
se someten previamente a controles de integridad y calidad. La transformación se
realiza por medio del Proceso informático, el cual está gobernado por programas.
Obtenido el producto final, los resultados son sometidos a varios controles de calidad
y, finalmente, son distribuidos al cliente, al usuario.
Auditar Explotación consiste en auditar las secciones que la componen y sus

interrelaciones. La Explotación Informática se divide en tres grandes áreas:
Planificación, Producción y Soporte Técnico, en la que cada cual tiene varios
grupos.
7.1. Control de Entrada de Datos:
Se analizará la captura de la información en soporte compatible con los Sistemas, el

cumplimiento de plazos y calendarios de tratamientos y entrega de datos. La correcta
transmisión de datos entre entornos diferentes. Se verificará que los controles de
integridad y calidad de datos se realizan de acuerdo a la Norma.

7.2. Planificación y Recepción de Aplicaciones:

Se auditarán las normas de entrega de Aplicaciones por parte de Desarrollo,
verificando su cumplimiento y su calidad de interlocutor único. Deberán realizarse
muestreos selectivos de la Documentación de las Aplicaciones explotadas. Se
inquirirá sobre la anticipación de contactos con Desarrollo para la planificación a
medio y largo plazo.
7.3. Centro de Control y Seguimiento de Trabajos:
Se analizará cómo se prepara, se lanza y se sigue la producción diaria. Básicamente,

la explotación Informática ejecuta procesos por cadenas o lotes sucesivos (Batch*),
o en tiempo real (Tiempo Real*). Mientras que las Aplicaciones de Teleproceso
están permanentemente activas y la función de Explotación se limita a vigilar y
recuperar incidencias, el trabajo Batch absorbe una buena parte de los efectivos de
Explotación. En muchos Centros de Proceso de Datos, éste órgano recibe el nombre
de Centro de Control de Batch. Este grupo determina el éxito de la explotación,
en cuanto que es uno de los factores más importantes en el mantenimiento de la
producción.
* Batch y Tiempo Real:

Las Aplicaciones que son Batch son Aplicaciones que cargan mucha información
durante el día y durante la noche se corre un proceso enorme que lo que hace es
relacionar toda la información, calcular cosas y obtener como salida, por ejemplo,
reportes.
O sea, recolecta información durante el día, pero todavía no procesa nada. Es
solamente un tema de “Data Entry” que recolecta información, corre el proceso
Batch (por lotes), y calcula todo lo necesario para arrancar al día siguiente.
Las Aplicaciones que son Tiempo Real u Online, son las que, luego de haber
ingresado la información correspondiente, inmediatamente procesan y devuelven
un resultado. Son Sistemas que tienen que responder en Tiempo Real.
7.4. Operación. Salas de Ordenadores

Se intentarán analizar las relaciones personales y la coherencia de cargos y
salarios, así como la equidad en la asignación de turnos de trabajo. Se verificará la

www.ruoti.com.py
existencia de un responsable de Sala en cada turno de trabajo. Se analizará el grado

de automatización de comandos, se verificara la existencia y grado de uso de los
Manuales de Operación.
Se analizará no solo la existencia de planes de formación, sino el cumplimiento
de los mismos y el tiempo transcurrido para cada Operador desde el último Curso
recibido. Se estudiarán los montajes diarios y por horas de cintas o cartuchos, así
como los tiempos transcurridos entre la petición de montaje por parte del Sistema
hasta el montaje real. Se verificarán las líneas de papel impresas diarias y por horas,
así como la manipulación de papel que comportan.
7.5. Centro de Control de Red y Centro de Diagnosis

El Centro de Control de Red suele ubicarse en el área de producción de Explotación.
Sus funciones se refieren exclusivamente al ámbito de las Comunicaciones, estando
muy relacionado con la organización de Software de Comunicaciones de Técnicas
de Sistemas. Debe analizarse la fluidez de esa relación y el grado de coordinación
entre ambos. Se verificará la existencia de un punto focal único, desde el cual sean
perceptibles todos las líneas asociadas al Sistema.
El Centro de Diagnosis es el ente en donde se atienden las llamadas de los

usuarios-clientes que han sufrido averías o incidencias, tanto de Software como de
Hardware.
El Centro de Diagnosis está especialmente indicado para informáticos grandes y

con usuarios dispersos en un amplio territorio. Es uno de los elementos que más
contribuyen a configurar la imagen de la Informática de la empresa. Debe ser
auditada desde esta perspectiva, desde la sensibilidad del usuario sobre el servicio
que se le dispone. No basta con comprobar la eficiencia técnica del Centro, es
necesario analizarlo simultáneamente en el ámbito de Usuario.
8. Auditoría Informática de Desarrollo de Proyectos o Aplicaciones
La función de Desarrollo es una evolución del llamado Análisis y Programación

de Sistemas y Aplicaciones. A su vez, engloba muchas áreas, tantas como sectores
informatizables tiene la empresa. Muy escuetamente, una Aplicación recorre las
siguientes fases:
Prerrequisitos del Usuario (único o plural) y del entorno

Análisis funcional
Diseño
Análisis orgánico (Pre programación y Programación)
Pruebas
Entrega a Explotación y alta para el Proceso.
Estas fases deben estar sometidas a un exigente control interno, caso contrario,
además del disparo de los costos, podrá producirse la insatisfacción del usuario.
Finalmente, la auditoría deberá comprobar la seguridad de los programas en el sentido
de garantizar que los ejecutados por la maquina sean exactamente los previstos y no
otros.
Una auditoría de Aplicaciones pasa indefectiblemente por la Observación y el

análisis de cuatro consideraciones:
a Revisión de las metodologías utilizadas: Se analizaran éstas, de modo que se

asegure la modularidad de las posibles futuras ampliaciones de la Aplicación y
el fácil mantenimiento de las mismas.
b Control Interno de las Aplicaciones: se deberán revisar las mismas fases que
presuntamente han debido seguir el área correspondiente de Desarrollo:
• Estudio de Vialidad de la Aplicación. Importante para Aplicaciones
largas, complejas y caras.
• Definición Lógica de la Aplicación. Se analizará que se han observado
los postulados lógicos de actuación, en función de la metodología elegida
y la finalidad que persigue el proyecto
• Desarrollo Técnico de la Aplicación. Se verificará que éste es ordenado
y correcto. Las herramientas técnicas utilizadas en los diversos programas
deberán ser compatibles.
• Diseño de Programas. Deberán poseer la máxima sencillez, modularidad
y economía de recursos.
• Métodos de Pruebas. Se realizarán de acuerdo a las Normas de la
Instalación. Se utilizarán juegos de ensayo de datos, sin que sea permisible
el uso de datos reales.

www.ruoti.com.py
• Documentación. Cumplirá la Normativa establecida en la Instalación,

tanto la de Desarrollo como la de entrega de Aplicaciones a Explotación.
• Equipo de Programación. Deben fijarse las tareas de análisis puro, de
programación y las intermedias. En Aplicaciones complejas se producirían
variaciones en la composición del grupo, pero estos deberán estar
previstos.
c Satisfacción de usuarios: Una Aplicación técnicamente eficiente y bien
desarrollada, deberá considerarse fracasada si no sirve a los intereses del usuario
que la solicitó. La colaboración del usuario proporciona grandes ventajas
posteriores, ya que evitará reprogramaciones y disminuirá el mantenimiento
de la Aplicación.
d Control de Procesos y Ejecuciones de Programas Críticos: El auditor no
debe descartar la posibilidad de que se esté ejecutando un módulo que no se
corresponde con el programa fuente que desarrolló, codificó y probó el área de
Desarrollo de Aplicaciones.
Se ha de comprobar la correspondencia biunívoca y exclusiva entre el programa
codificado y su compilación. Si los programas fuente y los programa módulo
no coincidieran podrían provocar, errores que producirían graves y altos costos
de mantenimiento, hasta fraudes, pasando por acciones de sabotaje, espionaje
industrial-informativo, etc.
Por ende, hay normas muy rígidas en cuanto a las Librerías de programas;
aquellos programas fuente que hayan sido dados por bueno por Desarrollo, son
entregados a Explotación con el fin de que éste:
• Copie el programa fuente en la Librería de Fuentes de Explotación, a la
que nadie más tiene acceso
• Compile y monte ese programa, depositándolo en la Librería de Módulos
de Explotación, a la que nadie más tiene acceso.
• Copie los programas fuente que les sean solicitados para modificarlos,
arreglarlos, etc. en el lugar que se le indique. Cualquier cambio exigirá
pasar nuevamente por el punto 1.
Como este sistema para auditar y dar el alta a una nueva Aplicación es bastante
ardua y compleja, hoy (algunas empresas lo usarán, otras no) se utiliza un sistema

llamado U.A.T (User Acceptance Test). Este consiste en que el futuro usuario de
esta Aplicación use la Aplicación como si la estuviera usando en Producción para
que detecte o se denoten por sí solos los errores de la misma.
Estos defectos que se encuentran se van corrigiendo a medida que se va haciendo el

U.A.T. Una vez que se consigue el U.A.T., el usuario tiene que dar el Sign Off (“Esto
está bien”). Todo este testeo, auditoría lo tiene que controlar, tiene que evaluar que el
testeo sea correcto, que exista un plan de testeo, que esté involucrado tanto el cliente
como el desarrollador y que estos defectos se corrijan.
Auditoría tiene que corroborar que el U.A.T. prueba todo y que el Sign Off del
usuario sea un Sign Off por todo.
9. Auditoría Informática de Sistemas
Se ocupa de analizar la actividad que se conoce como Técnica de Sistemas en todas

sus facetas. Hoy, la importancia creciente de las telecomunicaciones ha propiciado
que las Comunicaciones, Líneas y Redes de las instalaciones informáticas, se
auditen por separado, aunque formen parte del entorno general de Sistemas.
9.1. Sistemas Operativos
Engloba los Subsistemas de Teleproceso, Entrada/Salida, etc. Debe verificarse

en primer lugar que los Sistemas están actualizados con las últimas versiones del
fabricante, indagando las causas de las omisiones si las hubiera.
El análisis de las versiones de los Sistemas Operativos permite descubrir las

posibles incompatibilidades entre otros productos de Software Básico adquiridos
por la instalación y determinadas versiones de aquellas.
Deben revisarse los parámetros variables de las Librerías más importantes de los
Sistemas, por si difieren de los valores habituales aconsejados por el constructor.
9.2. Software Básico
Es fundamental para el auditor conocer los productos de software básico que han
sido facturados aparte de la propia computadora. Esto, por razones económicas y por

www.ruoti.com.py
razones de comprobación de que la computadora podría funcionar sin el producto

adquirido por el cliente.
En cuanto al Software desarrollado por el personal informático de la empresa, el

auditor debe verificar que éste no agreda ni condiciona al Sistema.
Igualmente, debe considerar el esfuerzo realizado en términos de costos, por si

hubiera alternativas más económicas.
9.3. Software de Teleproceso (Tiempo Real)
No se incluye en Software Básico por su especialidad e importancia. Las

consideraciones anteriores son válidas para éste también.
9.4. Tunning
Es el conjunto de técnicas de Observación y de medidas encaminadas a la evaluación

del comportamiento de los Subsistemas y del Sistema en su conjunto. Las acciones
de tunning deben diferenciarse de los controles habituales que realiza el personal de
Técnica de Sistemas. El tunning posee una naturaleza más revisora, estableciéndose
previamente planes y programas de actuación según los síntomas observados. Se
pueden realizar:
• Cuando existe sospecha de deterioro del comportamiento parcial o general

del Sistema
• De modo sistemático y periódico, por ejemplo cada 6 meses. En este caso sus
acciones son repetitivas y están planificados y organizados de antemano.
El auditor deberá conocer el número de Tunning realizados en el último año, así

como sus resultados. Deberá analizar los modelos de carga utilizados y los niveles e
índices de confianza de las observaciones.
9.5. Optimización de los Sistemas y Subsistemas
Técnica de Sistemas debe realizar acciones permanentes de optimización como

consecuencia de la realización de tunnings preprogramados o específicos. El auditor
verificará que las acciones de optimización* fueron efectivas y no comprometieron la
Operatividad de los Sistemas ni el plan crítico de producción diaria de Explotación.
* Optimización:
Por ejemplo: cuando se instala una Aplicación, normalmente está vacía, no tiene
nada cargado adentro. Lo que puede suceder es que, a medida que se va cargando,
la Aplicación se va poniendo cada vez más lenta; porque todas las referencias a
tablas es cada vez más grande, la información que está moviendo es cada vez
mayor, entonces la Aplicación se tiende a poner lenta. Lo que se tiene que hacer
es un análisis de performance, para luego optimizarla, mejorar el rendimiento de
dicha Aplicación.
9.6. Administración de Base de Datos
El diseño de las Bases de Datos, sean relaciones o jerárquicas, se ha convertido en

una actividad muy compleja y sofisticada, por lo general desarrollada en el ámbito
de Técnica de Sistemas, y de acuerdo con las áreas de Desarrollo y usuarios de la
empresa.
Al conocer el diseño y arquitectura de éstas por parte de Sistemas, se les encomienda

también su administración. Los auditores de Sistemas han observado algunas
disfunciones derivadas de la relativamente escasa experiencia que Técnica de
Sistemas tiene sobre la problemática general de los usuarios de Bases de Datos.
La administración tendría que estar a cargo de Explotación. El auditor de Base

de Datos debería asegurarse que Explotación conoce suficientemente las que son
accedidas por los Procedimientos que ella ejecuta.
Analizará los Sistemas de salvaguarda existentes, que competen igualmente a

Explotación. Revisará finalmente la integridad y consistencia de los datos, así como
la ausencia de redundancias entre ellos.
9.7. Investigación y Desarrollo
Como empresas que utilizan y necesitan de informáticas desarrolladas, saben que

sus propios efectivos están desarrollando aplicaciones y utilidades que, concebidas
inicialmente para su uso interno, pueden ser susceptibles de adquisición por otras
empresas, haciendo competencia a las Compañías del ramo.
La auditoría informática deberá cuidar de que la actividad de Investigación y

www.ruoti.com.py
Desarrollo no interfiera ni dificulte las tareas fundamentales internas.
La propia existencia de aplicativos para la obtención de estadísticas desarrollados

por los técnicos de Sistemas de la empresa auditada, y su calidad, proporcionan al
auditor experto una visión bastante exacta de la eficiencia y estado de desarrollo
de los Sistemas.
10. Auditoría Informática de Comunicaciones y Redes
Para el informático y para el auditor informático, el entramado conceptual que

constituyen las Redes Nodales, Líneas, Concentradores, Multiplexores, Redes
Locales, etc. no son sino el soporte físico-lógico del Tiempo Real.
El auditor tropieza con la dificultad técnica del entorno, pues ha de analizar situaciones
y hechos alejados entre sí, y está condicionado a la participación del monopolio
telefónico que presta el soporte.
Como en otros casos, la auditoría de este sector requiere un equipo de especialistas,

expertos simultáneamente en Comunicaciones y en Redes Locales (no hay que
olvidarse que en entornos geográficos reducidos, algunas empresas optan por el uso
interno de Redes Locales, diseñadas y cableadas con recursos propios).
El auditor de Comunicaciones deberá inquirir sobre los índices de utilización de las

líneas contratadas con información abundante sobre tiempos de desuso.
Deberá proveerse de la topología de la Red de Comunicaciones, actualizada, ya

que la desactualizacion de esta documentación significaría una grave debilidad.
La inexistencia de datos sobre la cuantas líneas existen, cómo son y donde están
instaladas, supondría que se bordea la Inoperatividad Informática.
Sin embargo, las debilidades más frecuentes o importantes se encuentran en las

disfunciones organizativas. La contratación e instalación de líneas va asociada a
la instalación de los Puestos de Trabajo correspondientes (Pantallas, Servidores
de Redes Locales, Computadoras con tarjetas de Comunicaciones, impresoras,
etc.). Todas estas actividades deben estar muy coordinadas y a ser posible,
dependientes de una sola organización.

11. Auditoría de la Seguridad Informática
La computadora es un instrumento que estructura gran cantidad de información, la

cual puede ser confidencial para individuos, empresas o instituciones, y puede ser
mal utilizada o divulgada a personas que hagan mal uso de esta.
También puede ocurrir robos, fraudes o sabotajes que provoquen la destrucción

total o parcial de la actividad computacional. Esta información puede ser de suma
importancia, y el no tenerla en el momento preciso puede provocar retrasos
sumamente costosos.
En la actualidad y principalmente en las computadoras personales, se ha dado otro

factor que hay que considerar: el llamado “virus” de las computadoras, el cual,
aunque tiene diferentes intenciones, se encuentra principalmente para paquetes
que son copiados sin autorización (“piratas”) y borra toda la información que se
tiene en un disco.
Al auditar los sistemas se debe tener cuidado que no se tengan copias “piratas”
o bien que, al conectarnos en red con otras computadoras, no exista la posibilidad
de transmisión del virus. El uso inadecuado de la computadora comienza desde la
utilización de tiempo de máquina para usos ajenos de la organización, la copia de
programas para fines de comercialización sin reportar los derechos de autor hasta
el acceso por vía telefónica a bases de datos a fin de modificar la información con
propósitos fraudulentos.
La seguridad en la informática abarca los conceptos de seguridad física y seguridad

lógica. La seguridad física se refiere a la protección del Hardware y de los soportes
de datos, así como a la de los edificios e instalaciones que los albergan. Contempla
las situaciones de incendios, sabotajes, robos, catástrofes naturales, etc.
La seguridad lógica se refiere a la seguridad de uso del software, a la protección

de los datos, procesos y programas, así como la del ordenado y autorizado acceso
de los usuarios a la información.
Un método eficaz para proteger sistemas de computación es el software de control

de acceso. Dicho simplemente, los paquetes de control de acceso protegen contra el
acceso no autorizado, pues piden del usuario una contraseña antes de permitirle el
www.ruoti.com.py
acceso a información confidencial. Dichos paquetes han sido populares desde hace
muchos años en el mundo de las computadoras grandes, y los principales proveedores
ponen a disposición de clientes algunos de estos paquetes.
Ejemplo: Existe una Aplicación de Seguridad que se llama SEOS, para linux,
que lo que hace es auditar el nivel de Seguridad en todos los servidores, como ser:
accesos a archivos, accesos a directorios, que usuario lo hizo, si tenía o no tenía
permiso, si no tenía permiso porque falló, entrada de usuarios a cada uno de los
servidores, fecha y hora, accesos con password equivocada, cambios de password,
etc. La Aplicación lo puede graficar, tirar en números, puede hacer reportes, etc.
La seguridad informática se la puede dividir como Área General y como Área

Especifica (seguridad de Explotación, seguridad de las Aplicaciones, etc.). Así, se
podrán efectuar auditorías de la Seguridad Global de una Instalación Informática
–Seguridad General- y auditorías de la Seguridad de un área informática determinada
– Seguridad Especifica .
Con el incremento de agresiones a instalaciones informáticas en los últimos años, se
han ido originando acciones para mejorar la Seguridad Informática a nivel físico.
Los accesos y conexiones indebidos a través de las Redes de Comunicaciones,
han acelerado el desarrollo de productos de Seguridad lógica y la utilización de
sofisticados medios criptográficos.
11.1. Elementos que comprenden el Sistema Integral de Seguridad
El sistema integral de seguridad debe comprender:
Elementos administrativos:
• Definición de una política de seguridad
• Organización y división de responsabilidades
• Seguridad física y contra catástrofes (incendio, terremotos, etc.)
• Prácticas de seguridad del personal
Elementos técnicos y procedimientos:
• Sistemas de seguridad (de equipos y de sistemas, incluyendo todos los
elementos, tanto redes como terminales.

• Aplicación de los sistemas de seguridad, incluyendo datos y archivos

• El papel de los auditores, tanto internos como externos
• Planeación de programas de desastre y su prueba.
La decisión de abordar una Auditoría Informática de Seguridad Global en una

empresa, se fundamenta en el estudio cuidadoso de los riesgos potenciales a los que
está sometida. Se elaboran “matrices de riesgo”, en donde se consideran los factores
de las “Amenazas” a las que está sometida una instalación y los “Impactos” que
aquellas puedan causar cuando se presentan. Las matrices de riesgo se representan
en cuadros de doble entrada “Amenaza-Impacto”, en donde se evalúan las
probabilidades de ocurrencia de los elementos de la matriz.
Ejemplo:
Impacto Amenaza 1: Improbable
Error Incendio Sabotaje 2: Probable
Destrucción
- 1 1 3: Certeza
de Hardware
Borrado de -: Despreciable
3 1 1
Información ……..
El cuadro muestra que si por error codificamos un parámetro que ordene el borrado
de un fichero, éste se borrará con certeza.
11.2. Pruebas en la Auditoría Informática
En la realización de una auditoría informática el auditor puede realizar las siguientes

pruebas:
• Pruebas clásicas: Consiste en probar las aplicaciones / sistemas con datos de
prueba, observando la entrada, la salida esperada, y la salida obtenida. Exis-
ten paquetes que permiten la realización de estas pruebas.
• Pruebas sustantivas: Aportan al auditor informático las suficientes evidencias y
que se pueda formar un juicio. Se suelen obtener mediante observación, cálculos,
muestreos, entrevistas, técnicas de examen analítico, revisiones y conciliaciones.
Verifican asimismo la exactitud, integridad y validez de la información.

www.ruoti.com.py
• Pruebas de cumplimiento: Determinan si un sistema de control interno fun-

ciona adecuadamente (según la documentación, según declaran los auditados y
según las políticas y procedimientos de la organización).
11.3. Principales herramientas de las que dispone el auditor informático
• Observación
• Realización de cuestionarios
• Entrevistas a auditados y no auditados
• Muestreo estadístico
• Flujogramas
• Listas de checkeo
• Mapas conceptuales
12. Perfil del Auditor de Sistemas de Información
A un auditor informático se le presupone cierta formación informática y experiencia

en el sector, independencia y objetividad, madurez, capacidad de síntesis y análisis
y seguridad en sí mismo.
Profesión Actividades y conocimientos deseables

Informático Generalista Con experiencia amplia en ramas distintas.
Deseable que su labor se haya desarrollado
en Explotación y en Desarrollo de Proyec-
tos. Conocedor de Sistemas.
Experto en Desarrollo de Amplia experiencia como responsable de
Proyectos proyectos. Experto analista. Conocedor de
las metodologías de Desarrollo más im-
portantes.
Técnico de Sistemas Experto en Sistemas Operativos y Soft-
ware Básico. Conocedor de los productos
equivalentes en el mercado. Amplios co-
nocimientos de Explotación.

Experto en Bases de Datos y Con experiencia en el mantenimiento de

Administración de las mismas. Bases de Datos. Conocimiento de produc-
tos compatibles y equivalentes. Buenos co-
nocimientos de explotación
Experto en Software de Alta especialización dentro de la técnica
Comunicación de sistemas. Conocimientos profundos de
redes. Muy experto en Subsistemas de te-
leproceso.
Experto en Explotación y Gestión Responsable de algún Centro de Cálculo.
de CPD´S Amplia experiencia en Automatización de
trabajos. Experto en relaciones humanas.
Buenos conocimientos de los sistemas.
Técnico de Organización Experto organizador y coordinador. Espe-
cialista en el análisis de flujos de informa-
ción.
Técnico de evaluación de Costos Economista con conocimiento de Informá-
tica. Gestión de costos.
13. Escenarios de la Auditoría de Sistemas de Información
13.1. Ambiente de Informática
Este tipo de auditoría cubre las áreas de seguridad física y lógica, planes de
contingencias y operación de TI.
13.2. Organización
Este tipo de auditoría engloba aspectos generales, tales como: políticas, normas,
y procedimientos de la Compañía, responsabilidades organizacionales del Área se
Informática, gerencia de personal, y planeamiento de capacidad.
13.3. Aplicativos
Al auditar un aplicativo, se debe considerar aspectos técnicos de informática

www.ruoti.com.py
(entrada, procesamiento y salida de datos) y aspectos legales relacionados al área al

cual el sistema aplicativo atiende. (Sistema de Facturación - Datos, S.A.F., S.I.R.D.,
SEGDOC, etc.)
13.4. Base de datos
Este tipo de auditoría se refiere a todas las actividades envueltas en la administración

de datos (controles, disponibilidades, integridad, recuperación, etc.)
13.5. Redes de comunicación y micro computadores
Esta es el área de TI que más se desarrolló en los últimos años. Para realizar un buen
trabajo, se debe identificar primeramente las tecnologías utilizadas por la unidad
a ser auditada y capacitarse antes de iniciar la auditoría. En este tipo de auditoría
serán verificadas las actividades de la gerencia, operación y seguridad de redes de
comunicaciones y micro computadoras. También serán analizados los controles de
software de red y de micros.
13.6. Desarrollo de sistemas
Este tipo de auditoría cubre las metodologías de desarrollo de sistemas, proyecto,

estudio de factibilidad, diseño, implementación, operación y mantenimiento de
sistemas de informática.
14. Elementos de la Informática
14.1. Elemento Físico (Hardware)
Es el elemento físico de un sistema informático, es decir, todos los materiales que lo

componen.
14.2. Elemento lógico (Software)
Es el conjunto de elementos lógicos necesarios para que se puedan realizar las tareas
encomendadas al mismo.

Una aproximación al concepto software es la que se representa en el siguiente esquema.
Ideas
Software Datos o informaciones
Conjunto de órdenes
Componentes del Software
Software de base (Sistema Operativo)

Software Programas
Software de aplicación +
Datos
14.3. El elemento humano (personal informático)
El Elemento Humano es el más importante de los que constituyen la informática. Es

el conjunto de personas que desarrollan las distintas funciones relacionadas con el
uso de las computadoras.
Clasificación del Personal Informático
Personal Informático • De dirección

• De análisis
• De programación
• De explotación y operación
Personal de gerencia/ Es el encargado de coordinar un Departamento de Tec-
dirección: nología Informática.
Personal de análisis: Es el encargado del desarrollo de aplicaciones en lo
que respecta a su diseño.
Personal de Es el encargado de transcribir en un determinado len-
programación: guaje de programación los algoritmos diseñados por el
personal de análisis.

www.ruoti.com.py
Personal de explotación Este grupo se encarga de ejecutar los programas y apli-

y operación: caciones construidas.
14.4. Sistemas de Información
Un sistema de información es un conjunto de elementos que interactúan entre sí

con el fin de apoyar las actividades de una empresa o negocio.
Esquema de un sistema de PED no complejo

Esquema de un sistema de PED complejo
Ejemplo de los procesos de un sistema de información:
Entradas:
• Datos generales del cliente: nombre, dirección, tipo de cliente, etc.
• Políticas de créditos: límite de crédito, plazo de pago, etc.
• Facturas (interfase automático).
• Cobros contado, créditos etc.
Proceso:
• Cálculo de antigüedad de saldos.
• Cálculo de intereses moratorios.
• Cálculo del saldo de un cliente.

www.ruoti.com.py
Almacenamiento:
• Movimientos del mes (pagos, depuraciones).
• Catálogo de clientes.
• Datos Facturas.
Salidas:
• Reporte de pagos.
• Estados de cuenta.
• Asientos contables (interfase automática)
• Consultas de saldos en pantalla de una terminal – Modo WEB.
14.5. Usos de los Sistemas de Información
Los Sistemas de Información cumplen tres objetivos básicos dentro de las or-
ganizaciones:
• Automatización de procesos operativos.

• Proporcionar información que sirva de apoyo al proceso de toma de decisiones.
• Lograr ventajas competitivas a través de su implantación y uso.

Capítulo II
Auditoría en el Ambito Judicial - Auditoría Forense
1. Definición y alcance de la auditoría forense
Exponen Cano y Lugo, “Técnicas de Investigación en Auditoría Forense” :

La Informática Forense se encarga de analizar sistemas informáticos en busca
de evidencia que colabore a llevar adelante una causa judicial o una negociación
extrajudicial.
“La Auditoría Forense es una alternativa para combatir la corrupción, porque

permite que un experto emita ante los jueces conceptos y opiniones de valor
técnico, que le permiten a la justicia actuar con mayor certeza, especialmente en
lo relativo a la vigilancia de la gestión fiscal, de esta manera, se contribuye a
mejorar la economía del país.
También se lo define como la aplicación de técnicas y herramientas de hardware y

software para determinar datos potenciales o relevantes.
La necesidad de este servicio se torna evidente desde el momento en que la enorme

mayoría de la información generada está almacenada por medios electrónicos.
En informática forense se habla ya no sólo de recuperación de información sino

de descubrimiento de información dado que no hubo necesariamente una falla del
dispositivo ni un error humano sino una actividad subrepticia para borrar, adulterar
u ocultar información.
Es por lo tanto esperable que el mismo hecho de esta adulteración pase

desapercibido.
En la auditoría forense, las estrategias, procedimientos y métodos investigativos, son

especialmente estudiados a fin de preservar y priorizar el interés público.
www.ruoti.com.py
El rol de la auditoría forense en el sector público es facilitar la prevención, detección

e investigación del crimen económico. Esto incluye los siguientes aspectos:
La iniciación de un programa de prevención del crimen económico con una visión

amplia para resaltar la existencia de riesgos potenciales y de la necesidad de una
estrategia de prevención en cada institución pública;
http://www.interamericanusa.com/articulos/Auditoría/Audi-fore-tec-inv.htm.
Una revisión del sistema criminal de justicia para determinar los crímenes
económicos en el sector público y toda la legislación relevante con una visión para
identificar cualquier deficiencia material y reportarla adecuadamente;
El desarrollo de unas políticas y normas necesarias, incluyendo un modelo apropiado

de riesgos para auditorías y otros propósitos.
2. Auditoría forense: ¿Quiénes demandan este servicio?
Entidades de carácter gubernamental, según sea la vulnerabilidad de sus sistemas

de gestión y control.
Entidades Financieras que dada la naturaleza de sus transacciones están expuestas

a un riesgo mayor de fraudes.
Entidades de carácter público como son las compañías que cotizan sus valores
en bolsas de comercio, cuyos accionistas pueden estar expuestos en sus intereses,
especialmente aquellos accionistas minoritarios que no tienen injerencia en las
decisiones de la compañía.
3. Evidencia Digital
La evidencia digital, es un término utilizado de manera amplia para describir

“cualquier registro generado por o almacenado en un sistema computacional que
puede ser utilizado como evidencia en un proceso legal”.
La evidencia digital es la materia prima para los investigadores donde la tecnología

informática es parte fundamental del proceso.
La evidencia digital puede ser dividida en tres categorías:

a) Registros almacenados en el equipo de tecnología informática (correos

electrónicos, archivos de aplicaciones de ofimática, imágenes, etc.)
b) Registros generados por los equipos de tecnología informática (registros de
auditoría, registros de transacciones, registros de eventos, etc.).
c) Registros que parcialmente han sido generados y almacenados en los
equipos de tecnología informática. (hojas de cálculo financieras, consultas
especializadas en bases de datos, vistas parciales de datos, etc.).
4. Características de una evidencia digital
a) Es volátil
b) Es anónima
c) Es duplicable
d) Es alterable y modificable
e) Es eliminable

www.ruoti.com.py
Capítulo III
Estandares Internacionales - COBIT (Control Objectives for

Information and related Technology), Cobit versión 4.1 - Derechos
de autor (Copyright ©) 2007 por el IT Governance Institute.
1. COBIT, Misión y Visión
COBIT (Objetivos de Control para Tecnología de Información y Tecnologías

relacionadas), lanzado en 1996, es una herramienta de administración de TI que ha
cambiado la forma en que trabajan los profesionales de TI. Vinculando tecnología
informática y prácticas de control, COBIT consolida y armoniza estándares de
fuentes globales prominentes en un recurso crítico para la gerencia, los profesionales
de control y los auditores.
COBIT se aplica a los sistemas de información de toda la empresa, incluyendo

las computadoras personales, mini computadoras y ambientes distribuidos. Está
basado en la filosofía de que los recursos de TI necesitan ser administrados por un
conjunto de procesos naturalmente agrupados para proveer la información pertinente
y confiable que requiere una organización para lograr sus objetivos.
1.1. Misión
“Investigar, desarrollar, publicar y promover un conjunto actualizado de objetivos

de control para la tecnología de información que sea de uso cotidiano para gerentes
y auditores”.
La Gerencia: para apoyar sus decisiones de inversión en TI y control sobre el

rendimiento de las mismas, analizar el costo beneficio del control.
Los Usuarios Finales: quienes obtienen una garantía sobre la seguridad y el control
de los productos que adquieren interna y externamente.

Los Auditores: para soportar sus opiniones sobre los controles de los proyectos de
TI, su impacto en la organización y determinar el control mínimo requerido.
Los Responsables de TI: para identificar los controles que requieren en sus áreas.
1.2. Visión
COBIT ofrece una visión y ámbito de aplicación mucho más allá de una auditoría.
Se trata de la convergencia entre los requerimientos de negocio, los recursos de

TI y los procesos de TI. Se podría afirmar que la auditoría es una pequeña parte
del COBIT, que conformará la percepción sobre la calidad y procesos e incluso
propondrá algunas buenas prácticas para la mejora.
2. COBIT cubre cuatro dominios
* Planificación y Organización
* Adquisición e Implementación
* Servicio y Soporte
* Monitoreo
2.1. Planificación y Organización
La Planificación y el dominio de Organización cubren el empleo de tecnología y

como esto puede ser usado en una empresa para ayudar a alcanzar los objetivos.
Esto también destaca la forma de organización e infraestructura de TI que debe
tomar para alcanzar los resultados óptimos y generar ventajas del empleo de TI. La
mesa siguiente cataloga los objetivos de control de nivel alto para el dominio de
Organización y la Planificación.
* Planificación y Organización
PO1 Definen un Plan Estratégico de TI

www.ruoti.com.py
PO2 Definen la Arquitectura de Información

PO3 Determinan Dirección Tecnológica
PO4 Definen los Procesos de TI, Organización y Relaciones
PO5 Manejan la Inversión TI
PO6 Comunican Objetivos de Dirección
PO7 Manejan Recursos Humanos de TI
PO8 Manejan Calidad
PO9 Evalúan y Manejan Riesgos de TI
PO10 Manejan Proyectos
2.2. Adquisición e Implementación
Para llevar a cabo la estrategia de TI, las soluciones deben ser identificadas,
desarrolladas o adquiridas, así como implementadas e integradas dentro del proceso
del negocio. Además, este dominio cubre los cambios y el mantenimiento realizados
a sistemas existentes.
AI1 Identifican Soluciones Automatizadas

AI2 Adquieren y Mantienen Software de aplicación
AI3 Adquieren y Mantienen Infraestructura de Tecnología
AI4 Desarrollan y Mantienen procedimientos relacionados con TI
AI5 Instalan y Acreditan Sistemas
AI6 Administran Cambios
2.3. Servicios y Soporte
En este dominio se hace referencia a la entrega de los servicios requeridos, que abarca
desde las operaciones tradicionales hasta el entrenamiento, pasando por seguridad

y aspectos de continuidad. Con el fin de proveer servicios, deberán establecerse
los procesos de soporte necesarios. Este dominio incluye el procesamiento de los
datos por sistemas de aplicación, frecuentemente clasificados como controles de
aplicación.
DS1 Definir niveles de servicio

DS2 Administrar Servicios de Terceros
DS3 Administrar Desempeño y Capacidad
DS4 Asegurar Servicio Continuo
DS5 Garantizar la Seguridad de Sistemas
DS6 Identificar y Asignar Costos
DS7 Capacitar Usuarios
DS8 Asistir a los Clientes de TI
DS9 Administrar la Configuración
DS10 Administrar Problemas e Incidentes
DS11 Administrar Datos
DS12 Administrar Instalaciones
DS13 Administrar Operaciones
2.4. Monitoreo
Todos los procesos necesitan ser evaluados regularmente a través del tiempo para
verificar su calidad y suficiencia en cuanto a los requerimientos de control.
M1 Monitoreo del Proceso

M2 Evaluar lo adecuado del Control Interno

www.ruoti.com.py
M3 Obtención de Aseguramiento Independiente

M4 Proveer Auditoría Independiente
3. Aceptabilidad General del COBIT
COBIT se basa en el análisis y armonización de estándares y mejores prácticas

de TI existentes y se adapta a principios de gobierno generalmente aceptados. Está
posicionado a un nivel alto, impulsado por los requerimientos del negocio, cubre el
rango completo de actividades de TI, y se concentra en lo que se debe lograr en lugar
de cómo lograr un gobierno, administración y control efectivos.
Por lo tanto, funciona como un integrador de prácticas de gobierno de TI y es de

interés para la dirección ejecutiva; para la gerencia del negocio, para la gerencia
y gobierno de TI; para los profesionales de aseguramiento y seguridad; así
como para los profesionales de auditoría y control de TI. Está diseñado para ser
complementario y para ser usado junto con otros estándares y mejores prácticas.
La implantación de las mejores prácticas debe ser consistente con el gobierno y el

marco de control de la empresa, debe ser apropiada para la organización, y debe estar
integrada con otros métodos y prácticas que se utilicen.
Los estándares y las mejores prácticas no son una panacea y su efectividad depende de
cómo hayan sido implementados en realidad y de cómo se mantengan actualizados.
Son más útiles cuando se aplican como un conjunto de principios y como un punto
de partida para adaptar procedimientos específicos.
La gerencia y el equipo deben entender qué hacer, cómo hacerlo y porqué es

importante hacerlo para garantizar que se utilicen las prácticas.
Para lograr la alineación de las mejores prácticas con los requerimientos del
negocio, se recomienda que COBIT se utilice al más alto nivel, brindando así un
marco de control general basado en un modelo de procesos de TI que debe ser
aplicable en general a toda empresa.
Las prácticas y los estándares específicos que cubren áreas discretas, se pueden
equiparar con el marco de trabajo de COBIT, brindando así una jerarquía de

materiales guía.
3.1. Usuarios interesados en COBIT
• Dirección ejecutiva: Para obtener valor de las inversiones y para balancear

las inversiones en riesgo y control en un ambiente de TI con frecuencia
impredecible.
• Gerencia del negocio: Para obtener certidumbre sobre la administración y

control de los servicios de TI, proporcionados internamente o por terceros.
• Gerencia de TI: Para proporcionar los servicios de TI que el negocio

requiere para dar soporte a la estrategia del negocio de una forma controlada
y administrada.
• Auditores: Para respaldar sus opiniones y/o para proporcionar asesoría

a la gerencia sobre controles internos COBIT ha sido desarrollado y es
mantenido por un instituto de investigación sin ánimo de lucro, tomando la
experiencia de los miembros de sus asociaciones afiliadas, de los expertos
de la industria, y de los profesionales de control y seguridad. Su contenido
se basa en una investigación continua sobre las mejores prácticas de TI y se
le da un mantenimiento continuo, proporcionando así un recurso objetivo y
práctico para todo tipo de usuario.
COBIT está orientado a los objetivos y al alcance del gobierno de TI, asegurando que
su marco de control sea integral, que esté alineado con los principios de Gobierno
Corporativo y, por lo tanto, que sea aceptable para los consejos directivos, para la
dirección ejecutiva, para los auditores y reguladores.
En el Apéndice II, se ofrece un mapa que muestra cómo los objetivos de control
detallados de COBIT se relacionan con las cinco áreas de enfoque del gobierno de
TI y con las actividades de control de COSO.

www.ruoti.com.py
4. Marco de Trabajo completo de Cobit

5. Navegación en el marco de trabajo de Cobit
Para cada uno de los procesos TI de COBIT, se proporciona un objetivo de control de

alto nivel, junto con las metas y métricas clave en forma de cascada.
6. Introducción a los componentes esenciales de cobit
El marco de trabajo de COBIT está compuesto de los siguientes componentes

esenciales, incluidos en el resto de esta publicación y organizados en los 34 procesos
de TI, brindando así una visión completa de cómo controlar, administrar y medir cada
proceso. Cada proceso está cubierto en cuatro secciones, y cada sección constituye
aproximadamente una página, de la manera siguiente:
www.ruoti.com.py
• La sección 1 contiene una descripción del proceso que resume los objetivos del
proceso, con el objetivo de control de alto nivel representado en formada de
cascada. Esta página también muestra el mapeo de este proceso con los criterios
de información, con los recursos de TI y con las áreas de enfoque de gobierno
de TI, indicando con una P la relación primaria y con una S la secundaria.
• La sección 2 contiene los objetivos de control detallados para este proceso.
• La sección 3 contiene las entradas y salidas del proceso, la matriz RACI, las
metas y las métricas.
• La sección 4 contiene el modelo de madurez para el proceso.
6.1. Formas de visualizar el contenido del desempeño del proceso
• Las entradas del proceso son lo que el dueño del proceso requiere de otros.
• Los objetivos de control en la descripción del proceso describen lo que el
dueño requiere hacer.
• Las salidas del proceso son lo que el dueño debe entregar.
• Las metas y las métricas describen cómo se debe medir el proceso.
• La matriz RACI define qué se debe delegar y a quién.
• El modelo de madurez muestra qué se debe hacer para mejorar.
Los roles en la matriz RACI están clasificados para todos los procesos como sigue:
• Director ejecutivo (CEO)
• Director financiero (CFO)
• Ejecutivos del negocio
• Director de Informática (CIO)
• Dueño del proceso de negocio
• Jefe de operaciones
• Arquitecto en jefe
• Jefe de desarrollo

• Jefe de administración de TI (para empresas grandes, el jefe de funciones

como recursos humanos, presupuestos y control interno)
• La oficina o función de administración de proyectos (PMO)
• Cumplimiento, auditoría, riesgo y seguridad (grupos con responsabilidades
de control que no tienen responsabilidades operativas de TI).
Ciertos procesos específicos tienen un rol adicional especializado específico para ese
proceso, Ej., mesa de servicio/administrador de incidentes para DS8.
Se debe observar que, a pesar de que el material es recolectado de cientos de

expertos, después de una rigurosa investigación y revisión, las entradas, salidas,
responsabilidades, métricas y metas son ilustrativas y no así preceptivas o exhaustivas.
Proporcionan una base de conocimiento base del cual cada empresa debe seleccionar
lo que aplica de forma eficiente y efectiva, con base en las metas y políticas de la
estrategia empresarial.
6.2. Usuarios de los Componentes de COBIT
La gerencia puede emplear el material de COBIT para evaluar los procesos de

TI empleando las metas de negocio y las metas de TI detalladas en el apéndice I
para clarificar los objetivos de los procesos de TI y los procesos de los modelos de
madurez para evaluar el desempeño actual.
Los implementadores y auditores pueden identificar requisitos de control aplicables

desde los objetivos de control y responsabilidades desde las actividades y matrices
RACI asociadas.
Todos los usuarios potenciales se pueden beneficiar del uso del contenido de COBIT
como una aproximación completa a la gestión y gobierno de TI, junto con otros
modelos de estándares detallados como:
• ITIL para la entrega de servicio

• CMM para la entrega de soluciones
• ISO 17799 para seguridad de la información
• PMBOK o PRINCE2 para la administración de proyectos

www.ruoti.com.py
7. Areas de Enfoque del Gobierno de TI
7.1. Directrices Gerenciales
Las entradas y salidas se han añadido para ilustrar lo que los procesos necesitan de
otros y lo que típicamente generan.
También se proporcionan actividades y responsabilidades asociadas. Las entradas
y las metas de las actividades reemplazan a los factores críticos de éxito de COBIT
3ra Edición.
Las métricas ahora se basan en una cascada consistente de metas de negocio, metas
de TI, de proceso y de actividades. El juego de métricas de COBIT 3ra Edición
también se corrigió y mejoró para hacerlo más representativo y medible.
Desde Entradas
PO5 Reportes de costo / beneficio
PO9 Evaluación de riesgo
PO10 Portafolio de proyectos actualizado
DS1 Requerimientos de servicio nuevos / actualizados; portafolio de servicios actualizado
* Estrategia y prioridades del negocio
* Portafolio de programas
ME1 Entradas a desempeño de planeación de TI
ME4 eporte del estado del gobierno de TI; dirección estratégica de la empresa para TI
* Entradas provenientes de fuentes externas a COBIT

Salidas Hacia
Plan estratégico de TI PO2... PO6 PO8 PO9 AI1 DS1
Plan táctico de TI PO2...PO6 PO9 AI1 DS1
Portafolios de proyectos de TI PO5 PO6 PO10 AI6
Portafolio de servicios de TI PO5 PO6 PO9 DS1
Estrategia de contratación externa de TI DS2
Estrategia de adquisición de TI AI5
Matriz RACI
Funciones

www.ruoti.com.py
Capítulo IV
ITIL (Biblioteca de Infraestructuras de Tecnologías de

Información)
1. Concepto
ITIL (Biblioteca de Infraestructuras de Tecnologías de Información) es una es-

tructura propuesta por la OGC (Oficina Gubernamental de Comercio) del Reino Uni-
do que reúne las mejores prácticas del área de la gestión de servicios de Tecnología
Informática (TI) en una serie de guías aplicables a cualquier tipo de organización.
También lo definen a “IT Infrastructure Library” (ITIL) como un conjunto de

publicaciones para las mejores prácticas en la gestión de servicios TI e incluye op-
ciones que pueden ser adoptadas y adaptadas según necesidades, circunstancias y
experiencia de cada proveedor de servicios.
El objetivo de ITIL es proporcionar a los administradores de sistemas de TI las

mejores herramientas y documentos que les permitan mejorar la calidad de sus
servicios, es decir, mejorar la satisfacción del cliente al mismo tiempo que alcan-
zan los objetivos estratégicos de su organización. Para esto, el departamento de
TI debe ser considerado como una serie de procesos estrechamente vinculados.
Los departamentos de TI no son las únicas organizaciones que se benefician con

el enfoque ITIL, ya que éste consiste en hacer que los departamentos de TI sean
conscientes de que la calidad y disponibilidad de las infraestructuras de TI tienen un
impacto directo sobre la calidad global de la compañía.
2. El alcance de ITIL
La ITIL está dividida en nueve áreas, que abarcan todos los problemas encontrados
por los administradores de sistemas de TI. Los dos primeros se consideran el núcleo
del método ITIL:

a) Soporte técnico del servicio

b) Entrega del servicio
c) Administración de infraestructura
d) Administración de aplicaciones
e) Administración del servicio
f) Perspectiva empresarial
g) Requisitos empresariales
h) Tecnología
3. Niveles de certificación ITIL para profesionales
• Foundation Certificate (Certificado Básico): Acredita un conocimiento

básico de ITIL en gestión de servicios de tecnologías de la información
y la comprensión de la terminología propia de ITIL. Está destinado a
aquellas personas que deseen conocer las buenas prácticas especificadas
en ITIL.
• Practitioner’s Certificate (Certificado de Responsable): Destinado a

quienes tienen responsabilidad en el diseño de procesos de administración
de departamentos de tecnologías de la información y en la planificación
de las actividades asociadas a los procesos.
• Manager’s Certificate (Certificado de Director): Garantiza que quien

lo posee dispone de profundos conocimientos en todas las materias
relacionadas con la administración de departamentos de tecnologías de
la información y lo habilita para dirigir la implantación de soluciones
basadas en ITIL.

www.ruoti.com.py
Capítulo V
MCIIEF - Manual de Control Interno Informático para

Entidades Financieras de la Superintendencia de Bancos, del
Banco Central del Paraguay
De modo a demostrar y comentar las normativas que afectan a la seguridad del área
de informática, en nuestro mercado la única instancia de control, y que se encuentra
implementado para las entidades regidas por la Superintendencia de Bancos del
Banco Central del Paraguay, es el Manual de Control Interno para Entidades
Financieras, aprobado por resolución Nº 188 del año 2002.
Está basado primariamente en Normas de Control Interno en el ámbito de la TI,

provenientes de publicaciones de instituciones de renombre internacional y autores
destacados especialistas en el tema, y en especial, las Normas contenidas en los
que a juicio de la Superintendencia de Bancos, constituyen los principales cuerpos
normativos actuales en la materia.
El Manual se encuentra redactado y clasificado según las medidas de control que

deben ser aplicadas en las diversas áreas de actividad relacionada con la TI.
A continuación, se detallan el alcance de dicho manual, lo cual se encuentra

desarrollado íntegramente, las áreas definidas a efectos del Manual de Control
Informático son las siguientes:
1. Planificación y Organización
Abarca las decisiones estratégicas y tácticas que definen la manera en que la TI

contribuirá de mejor manera para el logro de los objetivos de la Entidad. También
se refiere a la manera en que esta visión estratégica genera planes, organización,
infraestructura tecnológica y procedimientos administrativos.
Definición del Plan La TI como parte de los Planes de la Entidad, Plan de TI
Estratégico de TI: a Largo Plazo, Método, Estructura en la elaboración Planes

de TI a Largo Plazo, Modificaciones del Plan de TI a Largo

Plazo, Plan de TI a Corto Plazo, Evaluación de los Sistemas
existentes.
Definición de la Modelo de la Arquitectura de Información, Diccionario de
arquitectura de Datos Corporativo y Reglas de Sintaxis de Datos, Esquema
información: de Clasificación de Datos, Niveles de Seguridad de Datos.
Determinación Plan de Infraestructura Tecnológica, Monitoreo de
de la dirección Tendencias Futuras y Regulaciones, Planes de Contingencia
tecnológica: e Infraestructura Tecnológica, Planes de Adquisición de
Hardware y Software, Normas Tecnológicas.
Definición de la Comité de Dirección y Planificación de los Servicios de TI,
Organización y Ubicación, Estructural del Área de Servicios de TI, Revisión
Relacionamientos estructural de la Gerencia de TI de la Entidad, Funciones y
de la Unidad Responsabilidades, Responsabilidad de la Seguridad Física
Funcional de TI: y Lógica, Propiedad y Custodia de Datos y Sistemas.
Separación de Dotación de Personal de Servicios de TI, Descripción de
Responsabilidades: Cargos del Personal de Servicios de TI, Personal clave de TI,
Relacionamiento.
Administración Presupuesto anual de la Unidad Funcional de Servicios de
de la inversión en TI Monitoreo del Costo/Beneficio, Justificación de Costos y
TI: Beneficios.
Administración Calificación del personal, Entrenamiento del personal,
de Recursos Personal de respaldo, Evaluación del trabajo del Personal.
Humanos:
Cumplimiento Revisión de los Requisitos Externos, Prácticas y
de requisitos Procedimientos para Cumplir con requisitos Externos,
externos: Operaciones Electrónicas, Cumplimiento de los
requerimientos de Compañías de Seguros.
Administración Esquema de Administración de Proyectos de TI de la Entidad,
de Proyectos: Participación de Usuario en el inicio del Proyecto, Formación
del Equipo de Proyecto y Asignación de Responsabilidades,
Definición del proyecto, Aprobación del proyecto, Estudio

www.ruoti.com.py
Administración de Viabilidad Tecnológica, Estudio de Viabilidad Económica,

de Proyectos: Conversión, Aprobación de Fase de proyecto, Plan Maestro
del Proyecto, Plan de Control de Calidad de Sistemas,
Planificación de Métodos de Seguridad, Formalización de la
Administración de Riesgos del Proyecto, Plan de Pruebas del
Proyecto, Plan de Entrenamiento.
Administración Plan General de Calidad, Esquema de Garantía de Calidad,
de la Calidad: Compatibilidad de la revisión de Garantía de Calidad con
las Normas y Procedimientos habituales en funciones de
TI, Metodología de Desarrollo de Sistemas, Actualización
de la Metodología de Desarrollo de Sistemas respecto a
Cambios en la TI, Coordinación y Comunicación, Relaciones
con Proveedores que Desarrollan Sistemas, Normas de
Documentación de Programas.
Normas de Normas respecto a la Prueba de Sistemas, Pruebas Piloto
Pruebas de o en Paralelo, Documentación de las Pruebas de Sistemas,
Programas: Evaluación del cumplimiento de Garantía de Calidad de las
Normas de Desarrollo, Revisión de Garantía de Calidad del
logro de los Objetivos de la Unidad Funcional de TI.
2. Adquisición e Implementación
Para poner en práctica las estrategias definidas se deben identificar soluciones de TI,
adquirirlas o desarrollarlas, y por supuesto hacerlas operativas, implementando e
integrándolas como procedimientos del día a día.
Forman parte de esta área todas las modificaciones que hacen posible la continuidad
operativa de lo implantado, tanto para adecuaciones que devienen de cambios en el
entorno como aquellas que se refieren a mejoras operativas.
Identificación de Control de Adquisiciones, Definición de Requisitos de la

Soluciones: Información, Requisitos de Servicios de Terceros, Diseño
de Pistas de Auditoría, Selección de Software de Base,
Aceptación de Tecnología.

Desarrollo y Métodos de Diseño Grandes de Cambios en los Sistemas

Mantenimiento Existentes, Aprobación del Diseño, Aprobación de la
de Software de Funcionalidad del Sistema, Definición de Requisitos
Aplicación: de Archivos y Documentación, Especificaciones de los
Programas Críticos, Definición de las Interfases, Definición
de Requisitos de Proceso y Documentación, Requisitos de
Control, Verificación de Software de Aplicación, Guías del
Usuario y Materiales de Apoyo.
Adquisición y Evaluación del Nuevo Hardware y Software, Mantenimiento

Mantenimiento de Preventivo del Hardware, Instalación de Software de Base,
la Infraestructura Seguridad de Software de Base, Mantenimiento de Software
de Tecnología: de Base, Control de Cambios del Software de Base.
Instalación y Criterio para Pruebas Piloto y Pruebas en Paralelo, Prueba

Autorización de de Cambios, Prueba de Aceptación Final, Prueba de la
Sistemas: Seguridad y Autorización, Paso a Producción.
Administración de Pedido de Cambios y Control, Evaluación del Impacto,

Cambios de Siste- Documentación y Procedimientos, Autorización del
mas de Aplicación: Mantenimiento, Distribución de Software.
3. Producción y Servicios
Esta área abarca las actividades que relacionadas con los sistemas en producción
de los servicios de TI, engloban las actividades tradicionales de producción, las de
entrenamiento, los procedimientos para garantizar la continuidad de los servicios,
operaciones de seguridad, etc.
También abarcan las actividades de soporte a los sistemas en producción. Esta área
incluye el procesamiento de los datos por sistemas de aplicación.
Administración Mantenimiento del Software Adquirido de Terceros, Contratos

de Servicios de de Servicios, Calificaciones Proveedores, Monitoreo.
Terceros:

www.ruoti.com.py
Garantizar la Plan de Continuidad de TI, Mantenimiento del Plan de

Continuidad del Continuidad de TI, Prueba del Plan de Continuidad de
Servicio: TI, Entrenamiento respecto al Plan de Continuidad de TI,
Distribución del Plan de Continuidad de TI, Recursos
Fundamentales de TI, Local y Hardware de Respaldo.
Garantizar la Administración de las Medidas de Seguridad, Identificación,

Seguridad de los Autenticación y Acceso, Seguridad de Acceso en Línea
Sistemas: a los Datos, Administración de las Cuentas del Usuario,
Violaciones e Informes de Actividad de Seguridad,
Mantenimiento de Privilegios de Acceso, Administración de
Claves de Encriptación, Medidas de Seguridad y Conexiones
con Redes Públicas.
Asistencia y Área de Asistencia a Usuarios, Registro de Solicitudes de

Asesoría a Usuarios, Priorización de Solicitudes de Usuarios, Monitoreo
Usuarios: de Soluciones a las Solicitudes de Usuarios, Análisis de
Tendencias e Informes.
Administración Verificación de Exactitud, Integridad y Validez, Tratamiento

de Datos: de Errores de Datos de Entrada, Integridad del Procesamiento
de Datos, Tratamiento y Retención de Salidas, Distribución
de la Salida, emitidas en el departamento de TI, Protección de
Datos Confidenciales durante su Transmisión y Transporte,
Responsabilidades de Administración de la Biblioteca de
Medios de Almacenamiento, Respaldo, Almacenamiento y
Restauración.
Administración Seguridad Física, Escolta del Visitante, Protección contra

de Soportes y Factores del Medio Ambiente, Alimentación Eléctrica no
Seguridad Física: Interrumpible.
Administración Software no Autorizado, Procedimientos de Operación y

de Operaciones: Manual de Instrucciones, Continuidad del Procesamiento,
Registro de Operaciones, Operaciones Remotas.

4 Monitoreo
Todos los procesos de TI deben ser evaluados regularmente, tanto en cuanto

a su calidad, como al cumplimiento de los requerimientos de control. Esta área
atiende la participación de la gerencia y demás órganos de línea en los procesos de
retroalimentación de los mecanismos de verificación y la evaluación proveniente de
auditorías internas y externas.
Obtención de Certificación Independiente de la Seguridad y el Control

Certificación Interno de TI, Certificación Independiente de la Seguridad y
Independiente: Servicios de Proveedores Externos, Evaluación Independiente
de la Efectividad de los Servicios de TI, Certificación
Independiente de Cumplimiento con Leyes, Regulaciones,
Normativas y Compromisos Contractuales.
Implementación Carácter de la Auditoría Informática, Independencia, Ética

de Auditoría Profesional y Normas.
Informática
Interna:
Calificación de Planificación del trabajo de Auditoría Informática,

los Auditores Desempeño del Trabajo de Auditoría Informática, Informes
Internos: de Auditoría Informática.
5. Indice del Manual de Control Interno Informático para Entidades

Financieras de la Superintendencia de Bancos
Capítulo I
Instrucciones para uso del manual 1
1. Uso del manual 1
1.1 Contenido 1
1.2 Formato 2
1.2.1 Encabezado

www.ruoti.com.py
1.2.2 Texto
1.2.3 Pie
2. Actualizaciones 3
2.1 Versión
2.2 Revisiones
2.3 Reemplazo de Paginas
2.4 Inclusión de Pagina
Capítulo II
Introducción 4
Capítulo III
Objetivos 6
Capítulo IV
Marco De Referencia MCIIEF 8
Capítulo V
Planificación y Organización 9
Definición del Plan Estratégico de TI 9
Definición de la arquitectura de información 12
Determinación de la dirección tecnológica 14
Definición de la organización de la Unidad de TI 16
Administración de la inversión en TI 20
Administración de Recursos Humanos 22
Cumplimiento de requisitos externos 25
Administración de proyectos 27
Administración de la calidad 31
Capítulo VI
Adquisición e Implementación 35
Identificación de soluciones 35
Adquisición y mantenimiento de software de aplicación 38
Adquisición y mantenimiento de tecnología 42

Instalación y autorización de sistemas 44

Administración de cambios 47
Capítulo VII
Producción y Servicios 50
Administración de servicios de terceros 50
Garantizar la continuidad del servicio 53
Garantizar la seguridad de los sistemas 56
Asistencia y asesoría a usuarios 59
Administración de datos 61
Administración de soportes 64
Administración de operaciones 66
Capítulo VIII
Monitoreo 69
Obtención de certificación independiente 69
Implementación de Auditoría interna informática 71
1ra. Edición – Julio 2002

Versión 01, revisión 00 de Manual de Control Interno Informático para Entidades
Financieras (MCIIEF)
Importante
* El presente manual es un instrumento confeccionado y preparado por

la Superintendencia de Bancos sobre las Normas y Control Interno
Informático para las Entidades Financieras, a ser distribuidas a todas las
Entidades Financieras, Firmas y personas profesionales habilitadas para
prestar servicio de Auditoría Independiente y Servicios Relacionadas al
Sistema Financiero Nacional.
* Queda estrictamente prohibida su reproducción parcial o total sin la

expresa autorización de la Superintendencia de Bancos.

www.ruoti.com.py
Capítulo VI
Modelo de redacción de NCI
1. Modelo de NC 01 - Evaluación de Estructura TI
1.1. Ubicación estructural del área de servicios de TI
Objetivo de control: La ubicación de la unidad funcional de los servicios de TI en el

organigrama de la Entidad, deberá contar con el apropiado nivel de autoridad.
Observación: Hemos observado que la Entidad dispone de una de estructura funcional

de TI, a nivel Gerencial, “Gerencia”, no obstante la administración y control del
área de tecnología informática no se encuentran coordinados íntegramente por esta
instancia, quedando otras áreas como: “citar las gerencias y áreas afectadas”,
gerenciados independientemente, tanto en la ejecución de proyectos, actividades
operativas, y ejecución presupuestaria.
Riesgo: La no centralización y gestión adecuada de las actividades del área

de tecnología informática, no permitirá un control y seguimiento adecuado al
cumplimiento de los objetivos de la Entidad.
recomendación: El Directorio debe ubicar a la Unidad Funcional de Servicios

de TI en el organigrama de la Entidad, de tal manera que la misma cuente con el
apropiado nivel de autoridad, la cantidad adecuada de personal, así como la suficiente
independencia de los Usuarios de las demás Unidades Funcionales para garantizar
la implantación de soluciones tecnológicas efectivas y oportunas, así como para
que la misma pueda establecer una relación cooperativa con el Directorio a fin de
ayudarla a tomar conciencia, tener una mejor comprensión y desarrollar habilidades
de identificación y resolución de problemas de TI.
Recomendamos a la “Alta Gerencia”, considerar la centralización de todas las

áreas funcionales de TI de la Entidad como ser: “Planes estratégicos y operativos
de tecnología informática, gestión de adquisiciones y ejecución presupuestaria,
seguridad física y lógica, control de ejecución de contratos, administración de

sistemas, entre otros” en la Gerencia de TI, abarcando todas las áreas operativas de
gestión de la tecnología de información de la Entidad.
2. Organización de la Estructura de TI
2.1. Inexistencia de un responsable del área de ti de la dependencia Jefe/

Encargado
Objetivo de control: La entidad deberá contar con la figura de un responsable del

gerenciamiento de las actividades de TI.
Identificación del responsable de la Gerencia/Jefatura de TI
Observación: Hemos observado que el “departamento/dependencia….” de la

Entidad, no dispone un encargado que sea responsable y coordine las tareas de
informática y que sea el enlace con la “Gerencia”, únicamente se ha visualizado
personales que realizan trabajos de soporte técnico y asistencia a usuarios.
Riesgo: La carencia de un encargado del área de informática del “departamento/

dependencia….” no permite coordinar las tareas en forma efectiva que afectan a
las actividades TI, así mismo mencionamos que la no administración eficiente de
los sistemas, redes y base de datos, “no garantiza la seguridad de los sistemas, ante
errores involuntarios o dolo”.
.
recomendación: Recomendamos a la Entidad, analizar dicha situación y evaluar el
nombramiento oficial de un “Encargado, Jefe de TI del departamento…”, de manera
a poder disponer de una estructura de recursos humanos del área informática que
realice y coordine básicamente las tareas básicas descritas a continuación:
• Brindar una estructura sólida para la seguridad física del área informática
• Brindar una estructura sólida para la seguridad lógica de los sistemas

informáticos y red de área local, esto implica el control de la administración
de los sistemas, administración de red y administración de base de datos

www.ruoti.com.py
2.2. Inexistencia de un Administrador de bd
Objetivo de control: La entidad deberá contar con un responsable de la Administración

de la Base de Datos, responsable de la creación, administración y mantenimiento de
base de datos.
Identificación del responsable de la administración de Base de Datos – evaluar la

segregación de la tarea de la administración de BD.

Entidad, no dispone un encargado que sea responsable de la administración de la
base de datos “del sistema….”, “no se ha observado un nombramiento oficial”.
Riesgo: La inexistencia de un administrador de base de datos no permitirá asegurar

lógicamente los datos contenidos en la base de datos del “del sistema….”.
recomendación: Recomendamos a la “Gerencia de TI/Alta Gerencia”, nombre

formalmente al administrador de base de datos, que sea el encargado del
mantenimiento y definición de perfiles de usuarios, así como las activaciones de las
pistas de auditoría interna, a nivel de base de datos.
2.3. Inexistencia de un Administrador de Redes

de Redes, responsable de la administración, mantenimiento, creación de usuarios y
definición de perfiles.
Identificación del responsable de la administración de Redes – evaluar la segregación

de la tarea de la administración de Redes.

Entidad, no dispone un encargado que sea responsable de la administración de redes
del “sistema operativo”, “no se ha observado un nombramiento oficial”.
Riesgo: La inexistencia de un administrador de redes no permitirá asegurar

lógicamente los datos contenidos en la red de área local.


formalmente al administrador de redes, que sea el encargado del mantenimiento y
definición de perfiles de usuarios, así como las activaciones de las pistas de auditoría
interna, a nivel de los sistemas operativos de redes.
2.4. Inexistencia de un Administrador de Sistemas

de Sistemas, responsable de la administración, mantenimiento, creación de usuarios
y definición de perfiles.
Identificación del responsable de la administración de Sistemas – evaluar la

segregación de la tarea de la administración de Sistemas.

Entidad, no dispone un encargado que sea responsable de la administración de
sistemas del/los “sistemas”, “no se ha observado un nombramiento oficial”.
Riesgo: La inexistencia de un administrador de sistemas no permitirá asegurar

lógicamente los datos contenidos en los “sistemas informáticos”.

formalmente al administrador de sistemas de los “sistemas”, que sea el encargado
del mantenimiento y definición de perfiles de usuarios, así como las activaciones de
las pistas de auditoría interna, a nivel de los sistemas de gestión.
2.5. Inexistencia de una estructura de soporte técnico/asistencia a usuarios
Objetivo de control: La entidad deberá contar con un responsable de soporte técnico,

encargado del mantenimiento preventivo y/o correctivo de los equipos y/o periféricos,
así mismo deberá contar con un cronograma de servicio de mantenimiento.
Descripción de la estructura de soporte técnico, interno, o tercerizado.

Entidad, no dispone un encargado o estructura para las tareas de soporte técnico, y
asistencia a usuarios, “no se ha observado un nombramiento oficial”.
www.ruoti.com.py
Riesgo: La inexistencia de un encargado o estructura para las tareas de soporte

técnico y asistencia a usuarios, no permitirá asegurar la asistencia inmediata para
tareas de soporte técnico, así como los mantenimientos preventivos y correctivos a
los equipos computacionales de la Entidad.

formalmente a un encargado para las tareas de soporte técnico y asistencia a
usuarios, de manera a brindar asistencia técnica inmediata a los usuarios y prevenir
contingencias leves y graves.
2.6. Inexistencia de una estructura de desarrolladores internos de sistemas
Objetivo de control: Descripción de la estructura de desarrolladores, indicar los

principales desarrolladores

Entidad, no dispone un “encargado/desarrolladores…”, para los “sistemas…”, “no
se ha observado un nombramiento oficial…”.
Riesgo: La inexistencia de un encargado o estructura para las tareas de desarrollo y

mantenimiento “para los sistemas…”, no permitirá asegurar la asistencia inmediata
para el mantenimiento y mejoramiento de los sistemas informáticos de la Entidad.

formalmente a un “equipo de desarrollo/encargado de desarrollo…”, para los
“sistemas…”, de manera a brindar asistencia técnica inmediata a los usuarios y
prevenir contingencias leves y graves, que podría afectar a los sistemas informáticos
de la Entidad.
2.7. Nombramiento del Administrador de Seguridad de ti
Objetivo de control: La Entidad debe asignar formalmente la responsabilidad de

asegurar tanto la seguridad lógica como la física de los activos de TI.
Identificación del responsable de la administración de Seguridad – evaluar la
segregación de la tarea de la administración de Seguridad.

Observación: No hemos identificado la figura de un Administrador de Seguridad

de TI nombrado por la Entidad, que cumpla con la función de establecer los
procedimientos de seguridad a aplicar a los bienes tangibles e intangibles, de la
sociedad así como la aplicación de normativas que afectan al área tecnológica.
Riesgo: La inexistencia de un Administrador de Seguridad de TI, no permitirá

asegurar tanto la seguridad lógica como la física de los activos de TI de la Entidad.
recomendación: El Directorio debe asignar formalmente la responsabilidad de

asegurar tanto la seguridad lógica como la física de los activos de TI de la Entidad a un
Administrador de Seguridad de TI, el cual reporte al Directorio. Las responsabilidades
del Administrador de Seguridad de TI, al menos deben ser establecidas en el ámbito
de la Entidad como un todo, a fin de que se complementen y armonicen con las
medidas de Seguridad General de la Entidad.
Recomendamos a la Entidad, establecer como política la implementación de la figura

del Administrador de Seguridad de TI, de manera a cumplir con los requisitos de
seguridad establecidos en las normas internacionales de auditoría informática y con
el Plan de Seguridad de Sistemas de Información de la Entidad.
2.8. Separación de funciones - Personal clave de tecnología de información
Objetivo de control: El Área de TI debe definir e identificar al personal clave de

TI, de manera a evitar la excesiva dependencia del mismo. Así mismo deberá buscar
alternativas para disponer para caso de contingencias.
Observación: Hemos observado la necesidad de segregación de funciones para

las áreas de “desarrollo de los sistemas..., administración de base de datos…,
administración de redes….”
Riesgo: Alta dependencia del/los personales para las tareas mencionadas.
recomendación: Recomendamos a la Entidad, establecer como política la separación

adecuada de funciones de las “tareas críticas…..”, de manera a evitar una excesiva
dependencia, con los mismos, y el cumplimiento del Plan de Seguridad de Sistemas
de Información.

www.ruoti.com.py
2.9. Definición de propietario de datos, determinación de responsabilidades
Observaciones: No hemos observado que la Entidad disponga de una documentación

formal en el que se especifique la independencia en el manejo de datos, así como en
la responsabilidad de la generación de los mismos por cada área (usuarios).
Riesgo: La falta de una definición clara en el manejo de la información así como

la no reglamentación de los mismos, obliga al departamento de TI, la realización
de tareas no propias de su área, y por lo tanto la responsabilidad no es deslindada
correctamente.
Recomendación: Aplicando como referencia el Manual de Control Interno

Informático para Entidades Financieras de la SB - BCP, en su apartado, PO4.6
Propiedad y Custodia de Datos y Sistemas, describe:
La Gerencia de TI debe crear un procedimiento para nombrar formalmente a los

Propietarios y Custodios de los Datos y Sistemas. Sus funciones y responsabilidades
deben estar definidas claramente, en cuanto a la clasificación de datos en materia de
seguridad, así como a los derechos de acceso
Los propietarios habitualmente delegan la custodia al Grupo de Operaciones, y

delegan las responsabilidades de seguridad al Administrador de Seguridad. Sin
embargo, los Propietarios permanecen con la responsabilidad de establecer y
mantener las medidas apropiadas de seguridad.
Sugerimos documentar claramente las responsabilidades en el manejo y custodio de

los datos, definiendo la responsabilidad directa de los datos almacenados en cada
uno de los módulos a los usuarios responsables de cada área, deslindando al área de
informática de la administración de los mismos.
3. Evaluación de Gestión de TI - Gerenciamiento
3.1. Plan de ti a largo plazo, enfoque y estructura, aprobación
Objetivo de control: La Gerencia de TI debe establecer y aplicar un enfoque

estructurado en la elaboración del Plan de TI a Largo Plazo. Esto debe dar como
resultado un Plan de TI a Largo Plazo de alta calidad, el cual cubra las cuestiones
básicas respecto a que, quien, cómo y cuándo.
El Plan de TI a largo plazo debe estar alineado con el Plan de Negocios a largo plazo
de la Empresa.
Observación: Hemos observado que el área de tecnología informática de la Entidad,

no dispone de un plan estratégico de TI de largo plazo, en el que se especifiquen las
decisiones futuras que afectan a dicha área.
Riesgo: La no disponibilidad de los planes y objetivos no permite al área tecnológica de

la Entidad proyectar a futuro las aplicaciones de hardware, software, comunicaciones
y recursos humanos.
recomendación: El área de TI debe establecer y aplicar un enfoque estructurado en

la elaboración del Plan de TI a Largo Plazo. Esto debe dar como resultado un Plan de
TI a Largo Plazo de alta calidad, el cual cubra las cuestiones básicas respecto a que,
quien, como y cuando.
Recomendamos la elaboración del mismo cumpliendo con una de las funciones

básicas de gerenciamiento, especificando las actividades, recursos y tiempo, citamos
brevemente lo que detalla el MCIIEF para el cumplimiento de dicho plan:
• Lista de propuestas informáticas correspondientes al ejercicio.

Estudios de factibilidad de las propuestas, con estimación aproximada de los
•
costos.
• Evaluación de los riesgos de las propuestas.
• Beneficios estimados de las propuestas.
• Prioridad de cada propuesta.
Oportunidad para concretar las propuestas en un calendario o cronograma de
•
alto nivel para la implementación.
• Presupuesto asignado al plan.
Esquema global de la nueva estructura del sistema de información y de la
•
infraestructura tecnológica.
El área de TI debe asegurarse de que el proceso de planificación cumple con los

www.ruoti.com.py
plazos establecidos. Además, debe adecuar el Plan a los cambios que acontecen en
TI y a los cambios en los Planes a largo Plazo de la Entidad.
3.2. Plan de ti a corto plazo, planificación de la capacidad de la infraestruc-

tura tecnológica
Objetivo de control: El Responsable Funcional del Área de TI, o el personal que

éste designe, efectuará el monitoreo de las necesidades de capacidad de los sistemas
en operación y proyectar las futuras demandas, a fin de garantizar un procesamiento
y almacenamiento adecuado.
El Plan de TI a corto plazo debe estar alineado con el Plan de Negocios a corto plazo
de la Entidad.
Observaciones: No hemos evidenciado que la Gerencia de TI, realice un monitoreo

de las necesidades de capacidad de los sistemas en operación y proyectar las futuras
demandas, a fin de garantizar un procesamiento y almacenamiento adecuado.
Riesgo: Probabilidad de obsolescencia del equipamiento y hardware de la Entidad.
Recomendaciones: La Gerencia de TI, tomará en cuenta además los nuevos

requerimientos de los sistemas así como las tendencias actuales y proyectadas en
el procesamiento de la información de la Entidad para el período estipulado de
vida útil de cada componente. Asimismo, informará las necesidades detectadas a
las autoridades competentes para que puedan identificar y evitar potenciales cuellos
de botella, que podrían plantear una amenaza a la seguridad o a la continuidad del
procesamiento, y puedan planificar una adecuada acción correctiva.
Recomendamos a la Gerencia de TI, la planificación permanente de la capacidad de

infraestructura tecnológica de la Entidad, de manera a evitar posibles contingencias
en la prestación de servicios de tecnología.
3.3. Cambios al plan de ti a largo plazo
Objetivo de control: El área de TI debe asegurarse de que el proceso de planificación

cumple con los plazos establecidos.

Además, debe adecuar el Plan a los cambios que acontecen en TI y a los cambios en
los Planes a largo Plazo de la Entidad.
Observaciones: Hemos observado que los cambios surgidos en la actividad anual,

no ha sido actualizado en un nuevo plan de TI, por lo tanto los mismos han quedado
desfasado.
Riesgo: Disponibilidad de un plan no actualizado y realista.
Recomendaciones: Recomendamos a la Gerencia de TI, la actualización

permanente de los planes de TI, de manera a disponer de un documento que refleje
los acontecimientos surgidos en el ambiente de TI.
3.4. Evaluación permanente del plan estratégico de tecnología de información
Objetivo de control: El área de TI debe evaluar el Plan Estratégico de Tecnología

de Información, en cuanto al grado de automatización de la Entidad, funcionalidad,
estabilidad, complejidad, costo, fortalezas y debilidades, a fin de determinar el grado
en el cual los sistemas actuales se adecuan a las necesidades de la Entidad.
Observaciones: No hemos evidenciado que la Gerencia de TI, haya realizado una

evaluación permanente de la implementación del Plan Estratégico de Tecnología
de Información correspondiente al actual período, según lo establece el Plan de
Seguridad de Sistemas de Información de la Entidad.
Riesgo: Riesgo de incumplimiento de los objetivos de automatización y en los planes

y proyectos de TI desarrollados.
Recomendaciones: Recomendamos a la Gerencia de TI, la evaluación permanente

de los planes de TI, de manera a acompañar y evaluar la implementación de las
soluciones.
3.5. Metodología de Control de adquisiciones - Procedimientos
Objetivo de control: El Área de TI debe elaborar e implementar un Esquema de

Adquisiciones de TI que describa el conjunto de procedimientos y normas a ser

www.ruoti.com.py
seguidos en la adquisición de equipos de TI y accesorios necesarios, materiales de

TI, software, y servicios relacionados. Todos los productos recibidos deben revisarse
y probarse antes de ser cancelados en su totalidad.
Observaciones: No hemos evidenciado que la Gerencia de TI, disponga de una

Metodología Formal de Control de Adquisiciones de TI, según lo establece el Plan
de Seguridad de Sistemas de Información de la Entidad.
Riesgo: Riesgo de incumplimiento de normativas de control de adquisiciones y

posibles desviaciones en los objetivos trazados.
Recomendaciones: Recomendamos a la Gerencia de TI, la implementación de un

Esquema de Adquisiciones de TI, de manera a salvaguardar los activos tangibles e
intangibles de la Entidad.
4. Sistemas de Información
4.1. Integración de módulos – ERP (Los Sistemas del tipo ERP (Enterprise
Resource Planning) se han definido como un sistema global de planifica-
ción de los recursos y de gestión de la información)
Objetivo de control: Describir los sistemas aplicados, módulos integrados y módulos

o sistemas no integrados, métodos de integración, en línea o por lotes.
Observación: Hemos observado que no existe una adecuada integración de los

módulos del Sistema. El método de integración es por {lotes o en línea}.
Riesgo: Esta situación podría afectar la información en la suficiente confidencialidad,

disponibilidad e integridad.
recomendación: Recomendamos al área de TI { }] que los módulos de los sistemas

{ } estén debidamente integrados con la finalidad de proteger la información.
Recomendamos a área de TI { }, realizar la integración con el método {línea}.

4.2. Control de versiones del código fuente y autorización para el traspaso al

entorno de producción
Objetivo de control: La gerencia de ti debe definir e implementar procedimientos

formales para controlar el paso de sistemas del ambiente de desarrollo y pruebas al
ambiente de producción. los ambientes citados deben estar lógicamente separados y
protegidos apropiadamente.
Observaciones: El código fuente modificado por el entorno de desarrollo no pasa

a un entorno de prueba que es inexistente en la realidad de la entidad, de la misma
forma las documentaciones de las versiones son endebles muchas veces por la
premura del pedido de modificación del usuario en exigencia.
Riesgo: el riesgo se contempla en la alteración de los sistemas productivos sin

documentación requerida ni de instancias adecuadas para proteger la puesta a
producción del código fuente.
4.3. Pruebas del sistema en forma paralela antes del traspaso a producción
Objetivo de control: La gerencia de ti debe establecer procedimientos para asegurar

que las pruebas en paralelo se han realizado de acuerdo con el plan pre-establecido
y que el criterio para terminar y aprobar el proceso de la comprobación se ha
especificado de antemano.
Observaciones: Hemos observado que para pruebas pilotos y en paralelo la tendencia

es planteado por las dependencias { }, sin una continuidad y formalismos necesarios
de los sistemas { } que estén de acuerdo al plan preestablecido.
Riesgo: Se tiene los riesgos de pérdida de la información en el proceso de

implementación del nuevo sistema si no se hace las correctas operaciones de pruebas
en paralelo, en el caso que el nuevo sistema a ser implementado tenga falencias de
acuerdo a los resultados que debe dar en la salida.
recomendación: La empresa proveedora del servicio debe acompañar a con el

técnico de la proveedora a los usuarios del viejo sistema { }, en la implementación
con el nuevo sistema { } de la dependencia { }.

www.ruoti.com.py
4.4. Prueba de aceptación final antes del traspaso a producción
Objetivo de control: La gerencia de ti debe establecer procedimientos como parte

de la aceptación final o como parte de los procedimientos de garantía de calidad de
todo proyecto, una evaluación y aprobación formal de los resultados de las pruebas,
por la gerencia de la unidades funcionales de usuarios afectados por el sistema.
Observación: Hemos observado deficiencias o errores que se encuentra en el

sistema argumentado por los usuarios finales de diferentes niveles, que no llegan
a los requerimientos necesarios para que el mismo sea funcional de acuerdo al
relevamiento del sistema.
Riesgo: Están los riesgos de dar la aceptación final sin tener los requerimientos
necesarios del sistema en donde al empresa proveedora podría dejar de realizar los
cambios exigidos por la entidad al tener el documento de conformidad final de los
mismos.
recomendación: Los procedimientos deben exigir, como parte de la aceptación

final o como parte de los procedimientos de garantía de calidad de todo proyecto una
evaluación y aprobación formal de los resultados de las pruebas, por la gerencia de la
unidades funcionales de usuarios afectados por el sistema, así como por la gerencia
de ti.
Se requiere cumplir con todos los procedimientos que formalicen la calidad del
sistema antes de dar la aceptación final.
4.5. Estructura de desarrollo paralelo – servidor independiente
Objetivo de control: La gerencia de ti, debe establecer un esquema de servidores

separados físicamente para desarrollo, prueba y producción.
Observación: Hemos observado que en la instalación de los servidores se encuentran

en el mismo sitio físico, los aspectos de seguridad para siniestros eventuales se
visualizó estar desprovisto de dispositivos para proteger los servidores.
Riesgo: El riesgo inminente de pérdida de la información en la continuidad del

negocio de la entidad y los costos que pueden involucrar el siniestro ocasionado a

los servidores y sus instalaciones.
Recomendación: Se recomienda que en todas las salas de servidores, sin excepción,

deberán existir detectores de calor y humo, instalados en forma adecuada y en número
suficiente como para detectar el más mínimo indicio de incendio. los detectores
deberán ser probados de acuerdo a las recomendaciones del fabricante o al menos
una vez cada 6 meses y estas pruebas deberán estar previstas en los procedimientos de
mantenimiento y de control del manual de seguridad física. se deben tener extintores
de incendios debidamente probados, y con capacidad de detener fuego generado por
equipo eléctrico, papel o químicos especiales.
4.6. Procedimientos aplicados ante la eventual caída del sistema
Objetivo de control: La gerencia de ti, debe definir un esquema a ser aplicados en

caso de una eventual interrupción de los servicios de ti.
Observación: Hemos observado que existen procedimientos internos de las

dependencias { } ante la posibilidad de caída del sistema, los mismos no están en su
mayoría aprobada por la superioridad de la misma forma no podemos confirmar si
las normas planteadas son las correctas para dicho caso.
Riesgo: Si existen falencias en los procedimientos de caída del sistema, se pueden

perder las informaciones con la correspondiente pérdida para la entidad por dichas
debilidades.
4.7. Mecanismo para el cierre diario del sistema – participantes – aprobación
Objetivo de control: Los propietarios de datos, deben definir criterios a aplicar para
el cierre de los sistemas principales, facturación, contabilidad, caja entre otros
Observación: No existen procedimientos aprobados por el directorio para el cierre

de los sistemas principales, los mecanismos internos fueron realizados internamente
por los usuarios del mismo.
Riesgo: No se da certeza de la exactitud de los procedimientos implementados en el

www.ruoti.com.py
cierre de los sistemas de producción, que podría implicar falencias en la seguridad

de las mismas y su riesgo correspondiente.
Recomendación: Evaluación de criterios que aplica la entidad para el cierre de los

sistemas principales de la entidad, facturación, contabilidad, caja, entre otros.
Chequeo de los controles asumidos por las dependencias { }, en los sistemas { }, por
los órganos creados para la misma dentro de la entidad.
4.8. En casos de ajustes eventuales de registros ya procesados, ¿cómo se rea-

liza y quien autoriza?
Objetivo de control: Determinar qué mecanismos se aplican para casos de eventuales

ajustes al sistema, por ejemplo reproceso de facturaciones, reproceso de sueldos,
ajuste de existencia de mercaderías cuentas contables entre otros, quien autoriza y
verifica los procesos.
Observación: Los ajustes casuales de registros procesados se manejan de manera

informal entre los programadores de la empresa proveedora de servicios y los usuarios
que por la premura de su pedido lo hacen en forma informalmente telefónica, también
existe un programador para cada sistema o módulo en donde ese técnico se dedica
exclusivo a ese y la ausencia del técnico determina la falencia para trabajar en su
módulo o sistema.
Riesgo: Se tiene el riesgo de la pérdida de los registros de modificaciones ocasionados

por la falta del formulario de control de modificaciones y de la misma forma dejar
todo a un solo programador determina una pérdida del know how de la información
planteada por los usuarios en donde los otros programadores no lo poseen y deben
empezar de nuevo.
En caso de alteración de procesos críticos como facturación, pago de sueldo,

aguinaldo o anticipo en la quincena también recae el riesgo de falencia si lo hace sin
registros, también están las autorizaciones no documentadas.
Recomendación: Que se determine un equipo de trabajo para cada sistema de

la dependencia { } y del sistema { } para asegurar la continuidad del trabajo en
cuestión.
5. Evaluación del desarrollo y mantenimiento de sistemas - Equipo Interno
5.1. Procedimientos de controles de seguridad aplicados en la etapa de aná-

lisis y diseño del sistema
Objetivo de control: Los requerimientos para nuevos sistemas o mejoras a los

existentes especificarán la necesidad de controles. estas especificaciones deben
considerar los controles automáticos a incorporar al sistema, como así también
controles manuales de apoyo.
Observación: No hemos evidenciado que la gerencia de ti cuente con procedimientos

adecuados de controles de seguridad aplicados en la etapa de análisis y diseño del
sistema, según lo establece el plan de seguridad de sistemas de información de la
entidad.
Riesgo: Al no contar con procedimientos formales aprobados, no permite realizar

la evaluación de riesgos y no se definirán los requerimientos de seguridad en su
totalidad, y tampoco se identificarán los controles apropiadamente.
Recomendción: Recomendamos a la gerencia de ti la elaboración y aprobación de

procedimientos de control de seguridad que se apliquen desde la etapa de análisis y
diseño, a fin de minimizar los riesgos y costos del sistema.
5.2. Seguridad en los sistemas de aplicación, validación de datos de entrada
Objetivo de control: Se definirá un procedimiento que durante la etapa de diseño,

especifique controles que aseguren la validez de los datos ingresados, tan cerca del
punto de origen como sea posible, controlando también datos permanentes y tablas
de parámetros.
Observación: Se verifico que no existen procedimientos suficientes para la validación

de datos de entrada.
No existen procedimientos de control de monto limite de operaciones por usuario.
No existen controles de rango de valores posibles.

www.ruoti.com.py
No existe un procedimiento para realizar revisiones periódicas de contenidos de

campos claves o archivos de datos, definiendo quién lo realizará, en qué forma, con
qué método, y quiénes deberán ser informados del resultado.
No se definió un procedimiento que explique las alternativas a seguir para responder

a errores de validación en un aplicativo.
No se encuentra vigente un procedimiento que permita determinar las responsabili-

dades del personal que introducen los datos.
Riesgo: No se podrán controlar ni filtrar datos que provengan del exterior.

Podría incrustarse código maligno en los campos ocasionando errores en los
sistemas.
Perdida de información a causa de códigos ocultos que puedan introducirse en los
campos.
Recomendación: Se recomienda definir procedimientos adecuados que controlen la

validez y seguridad de los datos introducidos en los campos.
Elaborar un procedimiento que permita determinar las responsabilidades del personal

involucrado en el proceso de entrada de datos.
5.3. Política de utilización de controles criptográficos, encriptación
Objetivo de control: Se utilizarán controles criptográficos para la protección de

claves de acceso a sistemas, datos y servicios, para la transmisión de información
clasificada, fuera del ámbito de la entidad y para el resguardo de información, cuando
así surja de la evaluación de riesgos realizada por el propietario de los datos y el
responsable de seguridad de la información.
Observación: Hemos observado que no se utilizan controles criptográficos de

encriptación para la protección de claves de acceso al sistema, y transmisión de
información clasificada fuera de la entidad
Riesgo: El sistema presentará vulnerabilidades en cuanto acceso y contra ataques

mal intencionados de terceros.
Los datos transmitidos no presentarán seguridad, y la información reservada carecerá

de confidencialidad.
Recomendación: Recomendamos que se implementen controles criptográficos para

la protección de claves de acceso a sistemas, datos y servicios, para la transmisión
de información clasificada, fuera del ámbito de la entidad y para el resguardo de
información, cuando así surja de la evaluación de riesgos realizada por el propietario
de los datos y el responsable de seguridad de la información.
5.4. Protección de los datos de prueba del sistema, aplicación de otras bd

para pruebas
Objetivo de control: Para proteger los datos de prueba se establecerán normas y

procedimientos que contemplen lo siguiente:
a) Prohibir el uso de bases de datos operativas. en caso contrario se deben

despersonalizar los datos antes de su uso. aplicar idénticos procedimientos
de control de acceso que en la base de producción.
b) Solicitar autorización formal para realizar una copia de la base operativa

como base de prueba, llevando registro de tal autorización.
c) Eliminar inmediatamente, una vez completadas las pruebas, la información

operativa utilizada.
Observación: Hemos observado que no se cuenta con un servidor y un ambiente de

pruebas de desarrollo. la actualización de procedimientos almacenados de la base de
datos y/o modificaciones en las configuraciones del sistema se realizan directamente
en producción y no pueden ser probados sus riesgos en la totalidad.
Riesgo: Podrían ocurrir procesamientos erróneos en las transacciones y posibles

errores en las informaciones de los clientes. existe el peligro de generar inconsistencias
en las aplicaciones y podrían generar caídas o fallas del sistema, si las modificaciones
no son probadas previamente para un íntegro funcionamiento. lo que podría causar
pérdidas monetarias o de imagen a la entidad.

www.ruoti.com.py
Recomendación: Recomendamos que el “departamento de sistemas – gtif”, cuente

con un servidor de desarrollo para realizar pruebas de los procedimientos modificados
del sistema, por lo que se sugiere evaluar en la brevedad posible la adquisición del
citado servidor a fin de que pueda ser utilizado en paralelo al sistema en producción
con la finalidad de mantener la integridad, disponibilidad y confidencialidad de la
información.
5.5. Control de cambios a datos operativos, manipulación de datos a través

de un mgbd
Objetivo de control: La modificación, actualización o eliminación de los datos

operativos serán realizadas a través de los sistemas que procesan dichos datos y
de acuerdo al esquema de control de accesos implementado en los mismos. una
modificación por fuera de los sistemas a un dato, almacenado ya sea en un archivo
o base de datos, podría poner en riesgo la integridad de la información. los casos en
los que no fuera posible la aplicación de la precedente política, se considerarán como
excepciones. el responsable de seguridad de la información definirá procedimientos
para la gestión de dichas excepciones.
Observación: Hemos observado que los cambios en los datos operativos no se

realizan a través de los sistemas que procesan dichos datos, tampoco de acuerdo al
esquema de control de acceso al sistema.
Riesgo: Se pondría en riesgo la integridad de la información. esto además daría lugar

a sospechas en cuanto a borrado intencional de datos del sistema.
Recomendación: Se recomienda la implementación de procedimientos para la

modificación, actualización o eliminación de los datos operativos que estén acordes
a un esquema de control de accesos. se sugiere que se definan los responsables y los
medios con que se realizarán una modificación en los datos.
5.6. Mecanismo, registro y control de acceso a las bibliotecas de programas

fuentes
Objetivo de control: El responsable funcional del área de ti, propondrá para

su aprobación por parte del superior jerárquico que corresponda la función de

“administrador de programas fuentes” al personal de su área que considere adecuado,

quien tendrá en custodia los programas fuentes y deberá:
• Proveer al área de desarrollo los programas fuentes solicitados para su
modificación, manteniendo en todo momento la correlación programa fuente/
ejecutable.
• Llevar un registro actualizado de todos los programas fuentes en uso, indicando
nombre del programa, programador, analista responsable que autorizó,
versión, fecha de última modificación y fecha / hora de compilación y estado
(en modificación, en producción).
• Verificar que el analista responsable que autoriza la solicitud de un programa
fuente sea el designado para la aplicación, rechazando el pedido en caso
contrario.
• Registrar cada solicitud aprobada.
• Administrar las distintas versiones de una aplicación.
• Asegurar que un mismo programa fuente no sea modificado simultáneamente
por más de un desarrollador.
Observación: Hemos observado que no se cuenta con un administrador de programas

fuente que custodie los mismos.
Riesgo: aumento de la probabilidad de la alteración de los programas fuente que

provoquen un mal funcionamiento del sistema.
Recomendación: Se recomienda que “el responsable funcional del área de ti”,

proponga para su aprobación por parte del superior jerárquico que corresponda la
función de “administrador de programas fuentes” al personal de su área que considere
adecuado, quien tendrá en custodia los programas fuentes.
6. Evaluación del desarrollo y mantenimiento de sistemas –consultoría externa
6.1. Acuerdos de licencias, propiedad de código y derechos conferidos.
Objetivo de control: Los contratos de tercerización de desarrollo deben contemplar

los acuerdos de licencias, y propiedad del código fuente.
www.ruoti.com.py
Observación: Hemos constatado que el “sistema o contrato” no cuenta con un

acuerdo donde se especifique las condiciones de licenciamiento del “programa
informático o sistema”.
Hemos observado que “la consultora o el desarrollador” no especifica una

asistencia pos venta o mantenimiento del sistema.
Riesgo: No se puede identificar el alcance del uso del sistema.
Recomendación: Se recomienda que en “la propuesta del sistema o contrato”, se

definan el tipo de licencia que se adquirirá (por licenciamiento anual o perpetuo).
Se sugiere que en caso de “la consultora o desarrollador” no pueda brindar una

asistencia pos venta o mantenimiento, los programas fuentes deben ser transferidos
“a la entidad o comprador” sin costo alguno, para asegurar la utilización y
mantenimiento.
6.2. Requerimientos contractuales con respecto a la calidad del código y la

existencia de garantías.

garantías de calidad y asistencia en los sistemas.
Observación: Hemos observado que en el contrato no se especifica una metodología

de desarrollo de sistemas que se ajusten a los estándares de desarrollo.
No se ha constatado que se contemple garantías del funcionamiento del sistema

en retribución a fallas que puedan ocasionar “daños o perdidas” debido a un mal
funcionamiento del sistema
Riesgo: Perdida de información o errores en los datos que pueden provocar una gran
pérdida a la entidad en materia de producción.
Recomendación: Se recomienda que se especifique la metodología de desarrollo a

ser aplicada a fin de contemplar la calidad de los programas fuentes.

La propuesta de “sistema y/o contrato” de desarrollo debe contemplar las garantías

del funcionamiento del sistema, en caso de producirse algún daño a raíz del mal
funcionamiento o error del sistema informático.
6.3. Procedimientos de certificación de la calidad, que incluyan auditorías

internas de sistemas.

procedimientos de certificación de la calidad y precisión del trabajo llevado a cabo
por el proveedor, que incluyan Auditorías, revisión de código para detectar código
malicioso, verificación del cumplimiento de los requerimientos de seguridad del
software establecidos.
Observación: Hemos observado que no existen procedimientos para la certificación

de la calidad de sistemas que incluyan auditorías internas y externas.
No existe un manual de calidad que se basen en las normativas iso
Riesgo: Podría generar una pérdida del control de los procesos.
Se podrían presentar riesgos en las distintas fases del ciclo de vida del sistema.
El sistema podría resultar incorrecto, ineficiente y difícil de usar.
Recomendación: Recomendamos que los contratos de tercerización de desarrollo

contemplen procedimientos de certificación de la calidad y precisión del trabajo
llevado a cabo por el proveedor, que incluyan Auditorías, revisión de código para
detectar código malicioso, verificación del cumplimiento de los requerimientos de
seguridad del software establecidos, etc.
6.4. Acuerdos de custodia de las fuentes del software.

acuerdos de custodia de las fuentes del software (y cualquier otra información
requerida) en caso de quiebra de la tercera parte.

www.ruoti.com.py
Observación: Hemos observado que no existen custodias suficientes de las fuentes

de software “mencionar software”
Riesgo: Inseguridad en la continuidad comercial del software si el desarrollador no

puede mantener el producto en el futuro
No se tendrá el control sobre las decisiones de adquirir nuevas tecnologías ya que no

se contarán con las fuentes de software
Recomendación: Recomendamos que se celebren acuerdos de custodia de las fuentes

de software para mantener la integridad, flexibilidad y seguridad del “sistema x”.
7. Seguridad Física
7.1. Disponibilidad de los planes de continuidad de las actividades de ti

(plan de contingencia)
Objetivo de control: La Gerencia de TI elaborará los planes de contingencia

necesarios para garantizar la continuidad de las actividades de la Entidad. Estos
procesos deberán ser propuestos por el Comité de Seguridad de la Información.
El proceso de planificación de la continuidad de las actividades considerará los
siguientes puntos:
a) Identificar y acordar respecto a todas las funciones y procedimientos de
emergencia.
b) Analizar los posibles escenarios de contingencia y definir las acciones
correctivas a implementar en cada caso.
c) Implementar procedimientos de emergencia para permitir la recuperación y
restablecimiento en los plazos requeridos. Se debe dedicar especial atención
a la evaluación de las dependencias de actividades externas y a los contratos
vigentes.
d) Documentar los procedimientos y procesos acordados.
e) Instruir adecuadamente al personal, en materia de procedimientos y procesos
de emergencia acordados, incluyendo el manejo de crisis.

f) Instruir al personal involucrado en los procedimientos de reanudación y

recuperación en los siguientes temas:
1. Objetivo del plan.
2. Mecanismos de coordinación y comunicación entre equipos (personal
involucrado).
3. Procedimientos de divulgación.
4. Requisitos de la seguridad.
5. Procesos específicos para el personal involucrado.
6. Responsabilidades individuales.
7. Probar y actualizar los planes.
Asimismo, el proceso de planificación debe concentrarse en los objetivos de las

actividades de la Entidad requeridos, por ejemplo, restablecimiento de los servicios
a los usuarios en un plazo aceptable. Deben considerarse los servicios y recursos
que permitirán que esto ocurra, incluyendo, dotación de personal, recursos que no
procesan información, así como acuerdos para reanudación de emergencia en sitios
alternativos de procesamiento de la información.
Observación: Hemos observado que los planes de contingencia con procedimientos

internos en las Dependencias auditadas, que muchos de ellos no están aprobados
por la Superioridad con la natural falta de verificación de los órganos de control de
la calidad de los mismos. En tanto otras dependencias no lo tienen.
Riesgo: En un caso de siniestro si los procedimientos de contingencia no están

probados y con entrenamiento del personal responsable, pueden acontecer fallas y
errores en las acciones de emergencias para proteger el patrimonio de la Entidad.
7.2. Ensayo, Mantenimiento y Evaluación de los Planes de Continuidad de

Ti (Pruebas)
Objetivo de control: Debido a que los planes de continuidad de las actividades

de la Entidad pueden fallar, por suposiciones incorrectas, errores o cambios en el
equipamiento, se establecen las siguientes pautas de acción:

www.ruoti.com.py
- El Comité de Seguridad de la Información establecerá un cronograma de pruebas

periódicas de cada uno de los planes de contingencia.
- El cronograma indicará quienes son los responsables de llevar a cabo cada una
de las pruebas y de elevar el resultado obtenido al citado Comité.
Observación: No se ha conformado hasta la fecha un comité de Seguridad para los

planes de emergencia. De la misma circunstancia no existen planes de pruebas de
contingencias, ni cronograma definido para entrenamiento.
Riesgo: Al no tener planes de prueba ni de entrenamiento de emergencia , se puede

caer en la falencia de fallas de los planes de contingencia implementados al momento
del siniestro.
7.3. Aprobación por la alta gerencia del plan de contingencias
Objetivo de control: La Alta Gerencia deberá aprobar la aplicación del plan de

contingencias de la Entidad, en base a lo resuelto por la Gerencia de TI.
Observación: Hemos observado que la aprobación por el Directorio de los

planes de contingencia son pocas en las Dependencias que tienen implementados
que generalmente solo lo tienen internamente y no están respaldados por la
Superioridad
Riesgo: Al desconocer el Directorio de un plan de contingencia, no poseerá el

respaldo ni apoyo de la Superioridad en el caso de su implementación por causas de
sucesos de fuerza mayor.
Recomendación: El Presidente del Directorio deberá aprobar la aplicación del plan

de contingencias de la Entidad, en base a lo resuelto por elDirectorio de la Entidad.
Se recomienda que el Directorio envié una circular a todas las Dependencias
para proceder en la elaboración de cada Dependencia de un anteproyecto de plan
de contingencia para el estudio por los órganos de control definidos y aplicar su
aprobación si así lo decidiere.

7.4. Disponibilidad del plan de seguridad TI
Objetivo de control: La Gerencia de TI elaborará los planes de seguridad de la

Entidad. Estos procesos deberán ser propuestos por el Comité de Seguridad de la
Información.
El Plan de Seguridad de la Entidad considerará los siguientes puntos:
• Políticas y estándares de Seguridad del Personal
• Obligaciones de los usuarios
• Acuerdo de uso y confidencialidad
• Entrenamiento en Seguridad Informática
• Medidas disciplinarias
• Políticas y estándares de seguridad física y ambiental
• Resguardo y protección de la información
• Controles de acceso físico
• Controles de salida y entrada de equipos y otros
• Pérdida de Equipos
• Protección y ubicación de los equipos
• Mantenimiento de los equipos
• Uso de dispositivos especiales.
• Seguridad en áreas de trabajo.
• Políticas y estándares de seguridad y administración de operaciones de
cómputo.
• Uso de medios de almacenamiento.
• Instalación de software.
• Identificación del incidente.
• Administración de la configuración.
• Seguridad para la red.
• Uso del correo electrónico.

www.ruoti.com.py
• Controles contra código malicioso e Internet

• Políticas y estándares de controles de acceso lógico
• Controles de acceso lógico
• Administración de privilegios
• Administración y uso de passwords
• Control de accesos remotos
• Políticas y estándares de cumplimiento de seguridad informática.
• Derechos de propiedad intelectual.
• Revisiones del cumplimiento.
• Violaciones de seguridad informática.
Observación: Hemos observado que la disponibilidad del plan de seguridad de TI

tiene debilidades en la posesión de tal plan en el caso del traspaso de la confidencialidad
a otra persona como ser al secretario privado que no sea el propietario ni personal
autorizado, para con el jefe.
Riesgo: Falla directa en la confidencialidad del plan de seguridad para la continuidad

del negocio de la Entidad.
Recomendación: Dada la naturaleza confidencial del Plan de Continuidad de TI, el

mismo debe distribuirse sólo al personal autorizado y debe estar protegido contra
la divulgación no autorizada. Por consiguiente, las secciones del Plan deben ser
distribuidas sobre la base de la necesidad de conocimiento que tenga el personal
clave.
Se refuercen los controles de plan de seguridad sea cerrado exclusivamente a los
usuarios autorizados y claves de la Entidad
7.5. Aprobación del Plan de Seguridad de TI
Objetivo de control: La Alta Gerencia deberá aprobar la aplicación del Plan de

Seguridad de la Entidad, en base a lo resuelto por la Gerencia de TI.
Observación:
Riesgo:
Recomendación:
8. Evaluación de la Sala de Servidores - Data Center y Alta Disponibilidad
8.1. Sala de servidores independiente y restricción de accesos, controles de

acceso físico.
Objetivo de control: Las áreas protegidas se resguardarán mediante el empleo

de controles de acceso físico, los que serán determinados por el Responsable de
Seguridad de la información junto con el Responsable Funcional del Área de TI,
a fin de permitir el acceso sólo al personal autorizado, a la sala de servidores, así
mismo el Data Center deberá estar independiente a las demás oficinas, con los
requerimientos de seguridad requeridos, pisos falsos, detectores de humo y calor,
extintores especiales para equipos electrónicos, entre otros.
Observación: Hemos observado que no se registran la hora y fecha de los ingresos

a la sala de servidores
No existe una asignación de personal encargando exclusivamente para el acceso a la

sala de servidores
Se ha constatado que las autorizaciones de acceso a la sala de servidores se realizan

de formal verbal sin dejar registro alguno.
No se cuentan con los requerimientos de seguridad necesarios en la sala de servidores,

como ser, extintores especiales, pisos falsos, detectores de humo y calor, etc.
Riesgo: Posibilidad de sabotaje de los servidores, poniendo en riesgo los activos de

la Entidad.
No se podrá identificar quien o quienes tuvieron acceso a la sala de servidores cuando

se produjo un incidente.
En caso de que ocurra un accidente dentro de la sala, no se podrá actuar de manera

eficiente ya que no se cuentan con los equipos de seguridad necesarios.
www.ruoti.com.py
Recomendación: Recomendamos que las áreas protegidas se resguarden mediante

el empleo de controles de acceso físico, los que serán determinados por el Responsable
de Seguridad de la información junto con el Responsable Funcional del Área de
TI, a fin de permitir el acceso sólo al personal autorizado, a la sala de servidores,
así mismo el Data Center deberá estar independiente a las demás oficinas, con los
requerimientos de seguridad requeridos, pisos falsos, detectores de humo y calor,
extintores especiales para equipos electrónicos, entre otros.
8.2. Restricción de accesos a la sala de servidores, bitácora de accesos
Objetivo de control: El responsable de la sala de servidores, deberá llevar un registro

de las incidencias de la sala de servidores y los visitantes a la misma.
Observación: Hemos observado debilidades y flaquezas en las restricciones de

accesos a la sala de TI , bitácora y accesos del visitante, en donde determinamos que
muy poco se tiene en cuenta esta seguridad en lugares de prioridad de la Entidad.
Riesgo: Se puede violar fácilmente los controles en sitios de alta complejidad para
la continuidad del negocio de la Entidad como en la parte Técnica, Administrativa,
Comercial y la Gerencia de TI.
Recomendación: Se debe contar con procedimientos apropiados para asegurar que

los individuos que no son miembros de la Unidad Funcional de TI son escoltados
por algún miembro de esta Unidad Funcional cuando ellos deben ingresar al
Centro de Cómputos. El registro de acceso de visitantes debe guardarse y revisarse
regularmente.
8.3. Evidencia del mantenimiento de equipos preventivos
Objetivo de control: El Dpto. Técnico de la Gerencia de TI, deberá contar un informe

detallado de los mantenimientos realizado a los equipos informáticos y periféricos.
Observación: Se denotan insolvencias en el mantenimiento de los equipos

informáticos por falta de contrato, cronogramas no planteados o vencimientos de
plazos con los proveedores para los mantenimientos preventivos. Los procedimientos
para la continuidad de los mantenimientos preventivos son vistos raras veces en las
dependencias auditadas.
Riesgo: Se pone en riesgo de caída de los equipos informáticos con la falta de

mantenimiento especificado por los técnicos o los fabricantes, poniendo en abierta
violación de seguridad para resguardar los bienes de la Entidad.
Recomendación: Se realizará el mantenimiento del equipamiento para asegurar su

disponibilidad e integridad permanentes. Para ello se debe considerar:
a) Someter el equipamiento a tareas de mantenimiento preventivo, de acuerdo con
los intervalos de servicio y especificaciones recomendados por el proveedor y
con la autorización formal del Responsables del Área Informática. El Área de
Informática mantendrá un listado actualizado del equipamiento con el detalle
de la frecuencia en que se realizará el mantenimiento preventivo
b) Establecer que sólo el personal de mantenimiento autorizado puede brindar
mantenimiento y llevar a cabo reparaciones en el equipamiento.
c) Registrar todas las fallas supuestas o reales y todo el mantenimiento preventivo
y correctivo.
d) Registrar el retiro de equipamiento de la sede de la Entidad para su
mantenimiento.
e) Eliminar la información confidencial que contenga cualquier equipamiento
que sea necesario retirar, realizándose previamente las respectivas copias de
resguardo.
8.4. Lista de Servidores
Objetivo de control: El Dpto. Técnico de la Gerencia de TI, deberá contar un listado

actualizado de los servidores disponibles en la Entidad, con las configuraciones y
aplicaciones de cada una.
Observación: Se ha observado que no se dispone de un listado actualizado de los

servidores
Riesgo: No se tendrá disponible el listado de los servidores, y se desconocerá la

configuración correspondiente y usos respectivos de cada servidor.
Recomendación: Se recomienda actualizar el listado de servidores con sus

descripciones correspondientes.
www.ruoti.com.py
8.5. Servidor espejado - Fuera del recinto principal
Objetivo de control: El Dpto. Técnico de la Gerencia de TI, deberá contar con un

servidor espejado replicado en línea, fuera del Data Center, de manera a disponer
de una estructura paralela para los sistemas críticos de la Entidad, de manera poder
hacer operativo los servicios en caso de contingencias.
Observación: Hemos observado que no existe un servidor espejado fuera del recinto
principal.
Hemos observado que el Servidor espejado no esta sincronizado con el servidor

principal
Riesgo: En caso de caída del “sistema”, no se podrá revertir la situación de manera

rápida, ocasionando perdida en los ingresos de la “Entidad”.
El sistema no se encontrará disponible, por consiguiente la información no podrá

extraerse oportunamente.
Recomendación: Recomendamos que “El Dpto. Técnico de la Gerencia de TI”,

cuente con un servidor espejado replicado en línea, fuera del Data Center, a fin de
disponer de una estructura paralela para los sistemas críticos de la Entidad, de manera
poder hacer operativo los servicios en caso de contingencias.
8.6. Arquitectura Servidor - Clon
Objetivo de control: El Dpto. Técnico de la Gerencia de TI, deberá evaluar la

arquitectura de los servidores para el tipo de servicios que cumplen, determinando la
estructura de cada uno en función a la importancia.
Observación: Hemos observado que no se cuenta con una arquitectura de servidor

adecuada en el “Servidor x”
Riesgo: Los servidores podrían no cumplir con los servicios apropiadamente, o ser
inútiles de acuerdo al uso que se desee darle.


evalúe la arquitectura de los servidores para el tipo de servicios que cumplen,
determinando la estructura de cada uno en función a la importancia.
8.7. Sistema Operativo Server - Propietario - Libre

arquitectura de los Sistemas Operativos, determinando la estructura de cada uno en
función a la importancia.
Observación: Se ha observado que los sistemas operativos propietarios “Windows/

Otros” no presentan licencias de uso.
No se especifica garantía de soporte respectos a los sistemas operativos libres

observados “Linux / Otros”
Riesgo:: No disponibilidad de acceso al soporte técnico, actualizaciones y a las

capacidades confiables y soportadas que sólo se incluyen con el software Original
con licencia. Se presentarán los riesgos que acompañan al software falso, y no se
mantendrán los activos de informática en excelente funcionamiento.
Se podrían presentar problemas legales en caso de no poseer la licencia correspondiente

del S.O.
Recomendación: Se recomienda la adquisición de las licencias del Sistema Operativo

“Windows / Otros” para un mejor desempeño del mismo.
Se debería especificar una garantía del sistema operativo libre “Linux / Otros” en
cuanto a soporte pos-funcionamiento.
8.8. Rack de protección, protegido con llave

seguridad del Data Center y la protección física del mismo.
Observación: Hemos observado que el Rack de Protección no cuenta con seguro

de llave.
www.ruoti.com.py
Riesgo: Posibilidad de sabotaje de los discos duros, poniendo en riesgo la información

contenida.
Posibilidad de ocurrencia de un accidente que involucre la seguridad de los discos,

y no se podrá actuar de manera eficiente ya que no se cuentan con los equipos de
seguridad necesarios.
Recomendación: Recomendamos que “El Dpto. Técnico de la Gerencia de TI”evalúe

la seguridad del Data Center y la protección física del mismo.
8.9. Cableado de red ordenado, identificado por usuarios

estructura del cableado de red, determinando el grado de orden e identificación de
los usuarios por punto.
Observación: Se ha constatado que la instalación de los cables en “La Gerencia

de TI / Otros” se encuentra desordenada y los cables dedicados a las terminales de
trabajo no poseen una identificación por usuario.
Riesgo: Desconocimiento de la funcionalidad específica de cada cable instalados en

la “Gerencia de TI / Otros”. La localización y corrección de averías se complica
ya que los problemas no se pueden detectar fácilmente en un ámbito desordenado y
sin identificaciones.
El mal funcionamiento de un cable podría afectar a toda la red
Recomendación: Se recomienda una estructuración en el cableado y la identificación

de cada cable de acuerdo al usuario mediante cintas adhesivas pequeñas que puedan
ser pegadas al material
En cuanto a topología física se recomienda la implementación en Estrella.
8.10. Certificado del Cableado de Red
Objetivo de control: El Dpto. Técnico de la Gerencia de TI, deberá solicitar la

certificación del cableado de red, a través de especialistas.
“Todo cableado de red debe estar certificado por la empresa que ha desarrollado el
cableado estructurado. La certificación se realiza a través de equipos especiales, que
emiten un reporte de la calidad de la señal a través de rangos”.
Observación: Se ha observado que no existe un certificado de buen funcionamiento

por la empresa que desarrolló el cableado.
Se ha verificado que el cableado no cumple con los estándares de cableado

estructurado.
Riesgo: Perdida paquetes mientras se envía información por la red. Podría existir
perdida de intensidad de la señal de comunicaciones. Los datos podrían no estar
disponibles en momentos necesarios.
Recomendación: Se recomienda solicitar la certificación del cableado de red que

cumplan con los estándares de cableado estructurado, a través de especialistas, con el
objetivo de asegurar la comunicación y el envió de información a través de la red.
8.11. Identificación de materiales inflamables, en el recinto del Data Center
Objetivo de control: El Dpto. Técnico de la Gerencia de TI, deberá identificar la

existencia de materiales inflamables dentro del Data Center, en caso de existencia
deberá comunicar inmediatamente a la Gerencia de TI, para los recaudos
correspondientes.
Observación: Hemos observado que existen materiales altamente inflamables dentro

del recinto del Data Center
Riesgo: Podría generarse un incendio a causa de elevadas temperaturas, o bien

propagarse un incendio causado o accidental de manera rápida e incontrolable.
Recomendación: Recomendamos que “El Dpto. Técnico de la Gerencia de TI”

corrobore la existencia de materiales inflamables dentro del Data Center, en caso de
existencia, se sugiere comunicar inmediatamente a “la Gerencia de TI”, para los
recaudos correspondientes (Sustitución de los materiales).

www.ruoti.com.py
8.12. Disponibilidad de detectores de humo y calor
Objetivo de control: El Dpto. Técnico de la Gerencia de TI, deberá exigir la

instalación de los detectores de Humo y Calor en el Data Center.
Observación: Hemos observado que no se cuenta con detectores de humo y calor

dentro de las instalaciones de la sala de servidores
Riesgo: Desconocimiento de acontecimientos que puedan afectar a los servidores

debido a un exceso de calor o posibles incendios.

exija la instalación de los detectores de Humo y Calor en el Data Center.
8.13. Extintores especiales contra incendios

instalación de los extintores especiales contra incendio para equipos computacionales
en el Data Center.
Observación: Hemos observado que la sala de servidores no cuenta con extintores

contra incendios
Riesgo: En caso de ocurrir un incendio, no se podrá evitar la propagación del fuego

ocasionando daños irreversibles en los servidores

exija la instalación de los extintores especiales contra incendio para equipos
computacionales en el Data Center.
8.14. Licencias de los sistemas operativos de redes

instalación de software legal, caso contrario deberá informar inmediatamente a la
Gerencia de TI, para los recaudos necesarios.

Observación: Hemos observado que los sistemas operativos de redes no cuentan

con sus licencias correspondientes
Riesgo: No disponibilidad de acceso al soporte técnico, actualizaciones y a las

capacidades confiables y soportadas que sólo se incluyen con el software Original
con licencia. Se presentarán los riesgos que acompañan al software falso, y no se
mantendrán los activos de informática en excelente funcionamiento.
Se podrían presentar problemas legales en caso de no poseer la licencia correspondiente
del S.O.

exija la instalación de software legal, caso contrario deberá informar inmediatamente
a la Gerencia de TI, para los recaudos necesarios.
8.15. Disponibilidad del Sistema de puesta a tierra

instalación sistema puesta a tierra, el en el Data Center principalmente.
Observación: Hemos observado que la sala de servidores no dispone de un sistema

de puesta a tierra.
Riesgo: Un exceso de energía descargada en la parte metálica del hardware de

servidor podría generar un cortocircuito en dichos componentes.
Recomendación: Recomendamos que “El Dpto. Técnico de la Gerencia de TI”, deberá

exigir la instalación sistema puesta a tierra, el en el Data Center principalmente.
8.16. Suministro de energía eléctrica, UPS
Objetivo de control:
Riesgo: Procesos críticos que no pueden detenerse sufrirán cortes provocando

conflictos en el sistema.

www.ruoti.com.py
Observación: Hemos observado que la sala de servidores no cuentan con ups a fin
de suministrar la energía necesaria en caso de falta de la misma.
Recomendación: El equipamiento estará protegido con respecto a las posibles fallas

en el suministro de energía u otras anomalías eléctricas.
El suministro de energía estará de acuerdo con las especificaciones del fabricante o

proveedor de cada equipo principalmente deberá contar con un suministro de energía
ininterrumpible (UPS) para asegurar el apagado regulado y sistemático o la ejecución
continua del equipamiento que sustenta las operaciones críticas de la Entidad.
Recomendamos la utilización de ups especializadas en caso se necesite prolongar la

continuidad de un proceso critico.
8.17. Suministro de energía eléctrica, generador de electricidad
Objetivo de control: El equipamiento estará protegido con respecto a las posibles

fallas en el suministro de energía u otras anomalías eléctricas.
El suministro de energía estará de acuerdo con las especificaciones del fabricante o

proveedor de cada equipo principalmente deberá contar con un generador de respaldo
para los casos en que el procesamiento deba continuar ante una falla prolongada en
el suministro de energía.
Deberá realizarse un análisis de impacto de las posibles consecuencias ante una

interrupción prolongada del procesamiento, con el objeto de definir qué componentes
será necesario abastecer de energía alternativa.
Observación: Hemos detectado fallas en los suministros de electricidad que

alimentan los servidores.
Riesgo: Los servidores dejarían de funcionar normalmente, y tendría que esperarse

una estabilización de la corriente eléctrica para continuar con los procesos normales
de los sistemas en los servidores.

9. Relevamiento de Inventarios y manuales técnicos
9.1. Manuales de usuarios - Impresos - Interac.tivos
Objetivo de control: Disponibilidad de los manuales de usuarios – impresos -

interactivos, actualizados y disponibles.
Observación: Se ha señalado que los manuales de usuarios también son carentes

en muchos sistemas de Actividad de negocios de la Entidad, sin la exigencia de los
usuarios para la realización de los mismos por los desarrolladores del Sistema.
Riesgo: Se destaca que la carencia de manuales de usuarios podría ocasionar pérdida

para las Dependencias Afectadas en el caso de ausencia o traslado de un empleado
sin traspaso de la experiencia para el manejo del Sistema en ejecución.
Recomendación: Los manuales de usuarios deben ser exigidos por las autoridades
al Proveedor en tiempo y forma para asegurar su elaboración a los usuarios finales.
9.2. Manuales DFD, UML, AOO – Disponibles - Actualizados
Objetivo de control: Disponibilidad de Manuales DFD, UML, AOO, actualizados.
Observación: Se ha señalado que los manuales de DFD, UML, AOO también

son carentes en muchos sistemas de Actividad de negocios de la Entidad, sin la
exigencia de los usuarios o de las Autoridades para la realización de los mismos por
los Proveedores del Sistema. Las que se tienen no se encuentran actualizadas
Riesgo: Se destaca que la carencia de manuales de DFD, UML, AOO podría

ocasionar pérdida para las Dependencias Afectadas en el caso de revisión del Sistema
en cuestión por índoles de Análisis del Sistema en referencia, en donde los registros
de diseño del sistema estaría en peligro de continuidad y coherencia si no existen, O
si las hay no se encuentran actualizadas y su correspondiente pérdida de información
de modificaciones en sus versiones posteriores.
Recomendación: Se recomienda exigencia de disponibilidad y actualización por el

www.ruoti.com.py
Directorio a todas las Dependencias involucradas para asegurar su accesibilidad y a

vigencia actual.
9.3. Manuales de ER – Disponibles - Actualizados
Objetivo de control: Disponibilidad de Manuales de ER, actualizados y

disponibles.
Observación: Se ha señalado que los manuales de ER también son carentes en

muchos sistemas de Actividad de negocios de la Entidad, sin la exigencia de los
usuarios o de las Autoridades para la realización de los mismos por los Proveedores
del Sistema. Las que se tienen no se encuentran actualizadas
Riesgo: Se destaca que la carencia de manuales de ER podría ocasionar pérdida

para las Dependencias Afectadas en el caso de revisión del Sistema en cuestión
por índoles de Análisis del Sistema en referencia, en donde los registros de diseño
del sistema estaría en peligro de continuidad y coherencia si no existen, O si las
hay no se encuentran actualizadas y su correspondiente pérdida de información de
modificaciones en sus versiones posteriores
Recomendación: Se recomienda exigencia de disponibilidad y actualización por el

Directorio a todas las Dependencias involucradas para asegurar su accesibilidad y a
vigencia actual.
9.4. Disponibilidad de inventario de activos – Hardware - Actualizado
Objetivo de control: Disponibilidad de Inventario de activos - hardware –

actualizado.
Observación: Se ha denotado que no existen inventarios bien realizados en las

Dependencias auditadas, teniendo en cuenta su propietario, sitio y los bienes que se
relacionan con los Sistemas de información.
Riesgo: Si no se tiene bien implementado el inventario de Activos de la Entidad

se puede sufrir el riesgo de pérdida de activos o confusiones de los mismos por
cualquier motivo en los rubros de la Entidad.

Recomendación: Se recomienda crear un órgano contralor de inventario de activos

de la Entidad o Dependencia de control de los mismos para una realización formal
del control del patrimonio.
10. Evaluación de la Administración de Proyectos
10.1. Definición y esquema de Administración de Proyectos de Ti
Objetivo de control: El Área de TI debe establecer un Esquema de Administración

de Proyectos de TI que cubra como mínimo, la asignación de responsabilidades, el
detalle completo de las tareas, el cronograma, los recursos, los diversos puntos de
revisión, y los procedimientos para las aprobaciones.
Observación: Hemos constatado que la “Gerencia de TI” no cuenta con un esquema

formal de Administración de Proyectos de TI apropiado, de acuerdo a lo estipulado
en el PSSI 2.2.6.
Riesgo: Al no contar con un Esquema formalizado de Administración de Proyectos

de TI se podrían generar riesgos en el desarrollo del proyecto, que tendrían como
consecuencias los siguientes: fracasos en la obtención de beneficios anticipados,
mayores costos y tiempo de lo esperado en la implantación, sistemas resultantes
cuyo rendimiento técnico está por debajo de lo planificado y de los requisitos.
Recomendación: Recomendamos que en la brevedad posible la “Gerencia de TI”

establezca formalmente un Esquema de Administración de Proyectos de TI.
10.2. Evidencia de solicitud de prórroga
Objetivo de control: Descripción de solicitudes de prórrogas existentes y realizar

un seguimiento a los motivos del mismo, relevar los documentos pertinentes.
Observación: SLa solicitud de prórroga muchas veces no tienen argumentaciones

en sus evidencias y causales en donde la Contratista solicita la misma y el Directorio
lo rechaza ocasionándose las burocracias y resistencias normales al rechazo por las
partes.

www.ruoti.com.py
Riesgo: La pérdida de tiempo en el contrato por los papeleos de la adendas y y

postergaciones de las prorrogas en la ejecución del contrato.
Recomendación: Se recomienda que se recaben las evidencias reales y coherentes

para la aceptación del pedido de prórroga por la Contratista y evitar las postergaciones
de gestiones ejecutivas.
10.3. Solicitud de reajustes
Objetivo de control: Descripción de solicitudes de reajustes existentes y realizar un

seguimiento a los motivos del mismo, relevar los documentos pertinentes.
Observación: La misma situación de la prórroga para los reajustes en consecución

de las evidencias que no son tangibles para sus aceptaciones por el Directorio de la
Entidad.
Riesgo: El riesgo de salir del cronograma de la ejecución del contrato por burocracias
en las gestiones en el medio de la solicitud de reajustes y su vaivén en el proceso de
aceptación.
Recomendación: Se recomienda la verificación de los documentos y las pruebas para

las solicitudes de tal manera a asegurar su continuidad en la gestión de documentos
y celeridad
10.4. Solicitud de recepción técnica provisoria
Objetivo de control: Relevamiento de los procedimientos y documentaciones

aplicadas para las recepciones técnicas provisorias, funcionarios involucrados,
aprobación y autorizaciones.
Observación: La solicitud de recepción técnica provisoria se maneja sin

procedimientos previamente establecidos.
Riesgo: En donde los funcionarios designados no se encuentran informados, de la

misma forma las aprobaciones y autorizaciones se determina también informal.

Recomendación:Se recomienda establecer procedimientos claros para la recepción

técnica provisoria y confirmar todos los estamentos de acción de la misma.
10.5. Solicitud de recepción técnica definitiva
Objetivo de control: Relevamiento de los procedimientos y documentaciones

aplicadas para las recepciones técnicas definitivas, funcionarios involucrados,
aprobación y autorizaciones.
Observación: La solicitud de recepción técnica definitiva se maneja sin

procedimientos previamente establecidos.
Riesgo: En donde los funcionarios designados no se encuentran informados, de la

misma forma las aprobaciones y autorizaciones se determina también informal.
Recomendación: Se recomienda establecer procedimientos claros para la recepción

técnica definitiva y confirmar todos los estamentos de acción de la misma.
10.6. Contrato de mantenimiento hardware- vencimiento- cronograma
Objetivo de control: Determinación de la estructura interna del equipo de

soporte técnico, identificación del aseguramiento del mantenimiento a los equipos
principales, servidores y periféricos de comunicación, identificación de cronogramas
de mantenimiento de los equipos informáticos.
Observación: La falta en el cumplimiento del cronograma de mantenimiento

de equipos informáticos y de los principales servidores también periféricos de
comunicación en actividad.
Riesgo: Se verifica posibilidad de pérdidas en la Entidad por incumplimiento en lo

que respecta al Contrato y la consecuente pérdida de efectividad del mismo.
Recomendación: Se recomienda confirmar los controles que hacen los fiscales para
el fiel cumplimiento de los plazos en los trabajos establecidos en la ejecución del
contrato.

www.ruoti.com.py
10.7. Contrato de mantenimiento software- vencimiento
Objetivo de control: Relevamiento de los contratos de mantenimiento de software

vigencia de cada una.
Observación: Se ha observado falta de control en los contratos de mantenimientos

de Software en lo que respecta al seguimiento de los trabajos y los vencimientos de
los mismos.
Riesgo: Puede generar falencias en el mantenimiento de Software de producción

que está directamente relacionado a los objetivos de negocios de la Entidad.
Recomendación: Recomendamos fortalecer los controles del cronograma de

mantenimiento de Software de la Entidad para asegurar la productividad de los
mismos.
10.8. Contrato de licencias de software propietario
Objetivo de control: Relevamiento de los contratos de licencias de software

propietario vigencia de cada una.
Observación: Existen algunos Software de la Entidad que son Propietarios y que

sus licencias ya no existen, ni documentaciones básicas ya por su obsolescencia o
porque sus proveedores ya no se encuentran en el país.
Riesgo: Cualquier pedido de la fiscalía u organismos de control sobre este tema

acarrearía problemas legales y burocráticos para la Entidad.
Recomendación: Recomendamos el afianzamiento del control y vigencia de

los Software Propietarios de la Entidad para evitar inconvenientes posteriores en
cualquier situación legal de actividad.

Capítulo VII
Ejercicios Prácticos
1. Caso Omega Engineering INC.
1.1. Temas: Fallas en la seguridad y el delito computacional
Un ingeniero que había sido despedido y que se desempeñaba como administrador

de redes de la empresa donde trabajaba fue el autor de la peor pesadilla de seguridad
que haya vivido cualquier otra empresa estadounidense, cuando supuestamente lanzo
una bomba lógica que destruyó todo el software de la empresa causando daños por
un valor de US$ 10 millones.
¿Podría haberse evitado esto? Quizá ¿Podrían haberse minimizado los daños y el
tiempo de no operación por medio de unos mejores procedimientos de seguridad?.
Definitivamente si.
Esto es la evolución de los ejecutivos y expertos de seguridad de la empresa como

resultado de auto acusación de la semana pasada, de Timothy Lloyd de 30 años de
edad ex jefe administrador de redes y diseñador de programas de computacionales
en Omega Engineering Inc localizada en Bridgeport, nueva Jersey.
Omega es una empresa privada que produce instrumentos de control y medidas de

alta tecnología para organismos gubernamentales como la NASA y la Marina de los
Estados Unidos .La empresa tiene 1000 empleados en todo el mundo.
El auto de acusación por dos cargos que se anuncio en el distrito Federal de los Estados
Unidos, en Newark, Nueva Jersey, determina que Lloyd causó intencionalmente un
daño irreparable al sistema computacional de Omega al activar una bomba lógica
que borró de manera permanente todos los avanzados programas de software de la
empresa. Una bomba lógica es un programa doloso que se fija para que sea activado
en un determinado momento.
www.ruoti.com.py
“Omega es la situación clásica de un ataque interno de piratería informática, en

este caso una bomba lógica que inspira una admiración temerosa”. Que detona en
un determinado momento y hace explotar internamente la red. La defensa contra
este tipo de ataques es muy difícil dice William Cook, socio de Brink Hofer Wilson
& Llone, una empresa de abogados con sede en Chicago.
Esto es exactamente lo que sucedió dice Aldi Francesco, director de recursos humano
de Omega tres semanas después de que Lloyd fuera despedido nuestros empleados
llegaron a trabajar y no pudieron hacer trabajar sus computadores, dice el. La empresa
descubrió rápidamente que todos los archivos de la red habían sido borrados. Al
igual que muchas otras compañías que habían sido víctimas de este tipo de ataque,
Omega creía que tenía mecanismos de seguridad adecuados en funcionamiento.
La empresa tenía instalado un software de respaldo, recuperación y auditoría.

Estos rastros de auditoría condujeron a Lloyd, lo que dió como resultado su acusación
dijo DiFrancesco. Y Omega ciertamente canceló todos los privilegios y derechos de
acceso de Lloyd, cuando se le canceló su contrato unos pocos meses después.
Entonces, ¿qué es lo que salió mal? Para empezar además de ser el diseñador
jefe de los programas de redes computacionales de Omega, Lloyd también era el
administrador de redes de la empresa. Y sus 11 años en el cargo significa que
conocía todos los pormenores del sistema y tenía todos los privilegios de supervisión
para hacer ediciones cambios y eliminaciones dentro de las redes.
DiFrancesco dice que Lloyd utilizó su conocimiento para incrustar y codificar la

bomba lógica adentro del sistema operativo Novell Netware, e inhabilitar los medios
de respaldo y recuperación.
A raíz del daño ocasionado por la bomba lógica, omega ha instalado lo último en
sistemas de seguridad y la empresa ya no volverá a poner todos los huevos en una
sola canasta. Nos estamos asegurando de duplicar todas nuestras informaciones de
la base de datos, el código de software y los archivos además almacenaremos, todo
esto fuera del sitio dijo DiFrancesco.
El juicio de Lloyd debe comenzar el 20 de abril en la corte distrital de los Estados

Unidos ubicada en Newark. Si se le condena tendrá que enfrentar un máximo de 5
años en una prisión federal por cargos de piratería informática otros 10 años por el
robo de equipos computacionales de Omega por un valor de $$ 50.000. Cada cargo
conlleva una multa máxima que podría fluctuar entre $$ 250,000 y el doble de la
pérdida o ganancia del delito, informó en una declaración el despacho del procurador
de los Estados Unidos.
1.2. Preguntas del estudio del caso
1. ¿Cómo utilizó Timothy Lloyd una bomba lógica en Omega Engineering?

2. ¿Qué fallas de seguridad en Omega hicieron posible el ataque con la bomba
lógica?
3. ¿Cómo debería ser castigado Lloyd si se le condena? ¿Por qué?
4. ¿Con cuáles delitos informáticos nacionales podrían ser equiparados los
cometidos por Lloyd?
2. Otros casos de fraudes y abusos computacionales
2.1. Presentación del ejercicio
Leer la serie de casos reales de abusos y fraudes computacionales que se detallan en

las hojas siguientes y responda a estas preguntas:
1- ¿Es posible o no que algo similar ocurra en su empresa?
2- Marque los casos con una con una x y fundamente.
¿Es posible?
No
Caso No Tal Vez Si Observaciones
Se
Guardia Honesto
Cinta Baleada
Ataque Terrorista
Cintas Hewlett Packard
Computador al Agua
Lista de Clientes Robada
Sobre tiempo
Historial Clínico

www.ruoti.com.py
Seguro de Cesantía
Demanda a la Victima
Fraude a Texaco
El Zuperzap
Empleado Inexistente
Cumbre de Presidentes
Negocios Extras
Correo de Votantes
2.2. El Caso del Guardia Honesto
Un guardia nocturno que trabajaba en una bodega de la empresa de gas licuado,

además en las tardes, estudiaba computación. En la bodega donde trabajaba existía
un computador, el cual era usado para el proceso de inventario y facturación de los
despachos diarios. Este fue utilizado por el guardia para practicar sus conocimientos
computacionales.
Cierta noche, practicando con el comando FORMAT, el guardia borró toda la

información almacenada en el disco fijo.
La situación hubiera sido difícil de aclarar de no mediar el hecho que el propio

guardia se presentó ante la gerencia de la empresa explicando la situación y pidiendo
las disculpas del caso.
Los archivos pudieron ser recuperados después de cierto trabajo, puesto que no
existían respaldos muy actualizados.
2.3. El Caso de la Cinta baleada
El 11 de septiembre de 1973, el centro de cómputos de IBM de Chile estaba ubicado

en el primer piso del edificio de calle Agustinas frente al Palacio de Gobierno.
Durante la refriega de ese día, una de las unidades de cinta fue atravesada por los
disparos de una ametralladora, dejándola inutilizada, sin poder recuperar los datos
ahí almacenados. Desde entonces, el centro de cómputos de IBM ha sido ubicado en
salas sin ninguna ventana a la calle.

2.4. El Caso del Ataque Terrorista
En 1980, el grupo separatista vasco ETA destruyó un centro de cómputos de una

Universidad en España. Los daños fueron calculados en un millón de dólares. El
grupo terrorista reclamaba que los vascos no eran aceptados en la universidad debido
a discriminaciones políticas.
2.5. El caso de las Cintas de Hewlett Packard
Un ingeniero de sistemas de Hewlett Packard ha sido acusado de robo y copia ilegal de

cintas computacionales. El ingeniero copió las cintas e inmediatamente dejó Hewlett
Packard y tomó un trabajo en Axion Inc., una empresa pequeña de Software.
Cuando llegó a Axion, el ingeniero encontró que el formato de grabación de las

cintas no eran posibles de leer con el hardware y software que disponía. Volvió
Hewlett Packard en un intento de reformatear las cintas. El ingeniero usó su antiguo
user y password para obtener acceso al sistema.
El cintotecario que estaba trabajando en el computador desde su casa, detectó la

presencia de un intruso y llamó a los guardias de seguridad para que fueran a la sala
del computador. Ellos confiscaron las cintas y llevaron al ex empleado a prisión.
Las cintas en cuestión contenían el código fuente de una versión del sistema operativo
UNIX. El valor en el mercado negro de las cintas podrá ser de varios millones de
dólares. El mencionado, Ingeniero quedó en libertad con una fianza de USS 10.000.
2.6. El caso del computador que se iba al agua
Un día lunes en la mañana la empresa de agua de Los Ángeles, California, activó el

procesamiento semanal de sus sistemas. El computador repentinamente “se cavó”,
repitiéndose esta situación cada vez que se reiniciaba la operación.
Veinte personas trabajaron en el problema por más de una semana. Finalmente, la

falla fue corregida y el sistema volvió a funcionar normalmente. De acuerdo con
declaraciones del Gerente Administrativo de la empresa, la situación fue producto
de un sabotaje.

www.ruoti.com.py
Aparentemente, alguien que conocía el sistema, tenía programada una bomba lógica,
la cual no destruyó datos pero retrasó el procesamiento. La investigación continuó,
sin encontrarse culpables.
2.7. El caso de la lista de clientes robada
La compañía ACME BOOT entregó a sus vendedores una lista de probables

clientes. Esto puede sonar como un procedimiento común y rutinario. Pero lo que
hace a esta lista inusual es que había sido impresa del archivo de clientes de un
competidor. Frye Shoe Cornpany, el competidor demandó a ACME y pidió USS
100.000 por daños.
Frye no supo exactamente como había llegado el listado a manos de ACME, pero
si conocía el valor que éste representaba. Frye no había implantado las medidas
correctas que permitieran disminuir el riesgo de un robo. Actualmente todos los
listados son firmados por los empleados. Además, la empresa tiene un contrato
con una firma que recoge los restos de listados importantes que se encuentran
distribuidos en la firma.
En Chile, conocimos el caso de una empresa comercial, donde uno de sus operadores
computacionales respaldó a cinta la base de clientes de la empresa. Esta fue
ofrecida a una serie de empresas de la competencia de las cuales varias accedieron
a comprarla.
La transacción fue denunciada por una de las empresas a las que se le ofreció la
información, iniciándose acciones legales contra el operador y los ejecutivos de las
empresas compradoras. La acción legal fue bajo la Ley Nº 19923 que tipifica los
delitos relativos a la Informática, sin embargo, ninguno de los inculpados terminó
con penas de presidio.
2.8. El caso del sobre tiempo
Una empresa de Ferrocarriles en USA procesaba sus remuneraciones en un

computador. Todos los procesos manuales y los controles administrativos estaban
basados en el nombre del empleado. El computador, en cambio, basaba todos sus
procesos en el número del empleado. Un funcionario, que actuaba como controlador
de tiempo, se aprovechó de esta situación.

Usando los nombres de los empleados que trabajaban “sobre tiempo” (horas
extras) frecuentemente, este funcionario llenó formularios de “sobre tiempo”, pero
en muchos de ellos usó su propio número de empleado.
De este modo, obtuvo varios miles de dólares en el año por concepto de “sobre
tiempo”. Fue, finalmente descubierto por un auditor que notó el valor inusual del
monto de la renta durante una revisión del sistema de remuneraciones.
2.9. El Caso del Historial Clínico
Frank Russo, antiguo director de Análisis de Sistemas en el Hospital de la

Universidad Store Brook, New York, se apoderó de copias y vendió parte de los
datos almacenados en el sistema de pacientes avaluados en USS 300.000. Mr.
Russo vendió las copias del material al Centro Albert Einstein, en Philadelphia.
En 1979, el Hospital de la Universidad encargó un sistema de registro de pacientes
desarrollado por la empresa IBM. Mr. Russo, en esa época, fue asignado a tareas de
instalación. El sistema fue sujeto a contínuas modificaciones y adaptaciones. Poco
después Mr. Russo llegó a Director de Sistemas de Story Brook y en este cargo, llegó
a cometer el abuso.
De acuerdo al sumario. Mr. Russo “usó su posición de Director de Sistemas en

el Hospital Story Brook, para hacer una reproducción electrónica de ciertos
materiales científicos secretos con un valor sobre los US$ 300.000, sin el
conocimiento del hospital y vendió estos elementos”.
La pena para Mr. Russo fue de cuatro años de prisión. El sumario que se siguió
en este caso también alcanzó a la División Sistemas de Story Brook y los cargos
contra ella alcanzaron una pena de US$ 100.000.
2.10. El caso del Seguro de Cesantía
Un programador que trabajaba para la Minnesota Tipboard Co., puso en jaque a

la firma gracias a una bomba lógica que él tenía en el computador de la firma.
Conforme al programador si el era despedido, la bomba podía destruir todos los
registros de los archivos en el computador.
Un día, en la mañana, el programador fue despedido. Inmediatamente dijo a un
Vicepresidente de la compañía que el Presidente de Tipboard, Robert Finnerty debía
www.ruoti.com.py
llamarlo al medio día si no, lo lamentaría”. El señor Finnerty hizo la llamada, pero
usó un teléfono del departamento de policía de Minneapolis. De este modo aquella
conversación fue grabada.
El programador. Mr. P., deseaba recibir un salario de US$ 3000 por semana hasta que
encontrara trabajo. Si el dinero no se pagaba, el podía hacer funcionar una bomba
lógica cuando deseara. De este modo, alegaba tener poder sobre los archivos de
datos, con valor de US$ 500.000 para la firma. Puesto que Mr. P. había escrito la
mayoría de todos los sistemas de Tipboard, su amenaza fue tomada en serio.
Basados en la conversación grabada, los miembros de la policía investigaron el

departamento de Mr. P., tomaron las cintas, los listados y la documentación, y un
grupo de expertos chequeó las cintas para determinar su contenido.
La empresa contrató a dos consultores en informática para que ubicaran la bomba

lógica y la eliminaran. Sin embargo, Mr. P. había construido su propio sistema
defensivo.
La bomba lógica estaba en un archivo que tenía una protección de password que
cambiaba todos los días. Pero los consultores fueron capaces de eludir el password
y accesar el archivo, y de esta forma, la bomba lógica fue localizada y removida del
sistema.
El sistema estaba enganchado a Internet, de tal modo que era fácil que Mr. P.
planeara hacer funcionar su bomba desde una instalación remota.
Como un elemento más, Minnesota Tipboard había pagado por crear su propio
monstruo Mr. P. había recibido todos sus conocimientos computacionales gracias
a la compañía. Mr. P. no fue arrestado. Un representante legal señaló que los cargos
por extorsión fueron eliminados.
2.11. El caso de la Demanda a la Víctima
Un estudiante de 19 años de edad, en la Universidad de Texas A & M. fue acusado

de alterar sus registros de notas y las de sus amigos usando su computador, al
obtener el acceso no autorizado al sistema de calificaciones en el centro de datos de
la Universidad.

Los cargos contra el estudiante, sin embargo, fueron eliminados puesto que
su abogado acusó de negligencia a la Universidad debido al pobre sistema de
seguridad que tenía implantado en sus sistemas.
El director del centro de cómputos desconocía el hecho que los archivos de notas no
se encontraban debidamente protegidos.
2.12. El caso del fraude a Texaco
Un antiguo empleado de Texaco y su esposa fueron acusados de manipulación

fraudulenta de US$ 78.000 en cuentas de remuneraciones. El ex-programador
conocía el sistema de remuneraciones de Texaco y generó un contrato fraudulento
para su esposa.
El fraude fue detectado cuando una auditora descubrió cheques de pago que no
debieron hacerse. El cheque fue rastreado hasta la oficina postal para ver quien lo
recibía.
Finalmente, la pista llegó hasta el programador. ¿Quien dice que los Auditores
nunca detectan los fraudes computacionales?
2.13. El caso del SUPERZAP
Superzap es un poderoso utilitario de los sistemas mainframes IBM que puede

ser utilizado para eludir los controles y leer o modificar directamente los datos
almacenados en el computador. Generalmente este programa es usado solamente
en situaciones de emergencia y por su complejidad requiere que sea manejado por
Ingeniería de Sistemas.
Un Banco en New Jersey pasó por un problema cuando su proceso de corrección de
errores detuvo el funcionamiento del sistema. Las operaciones de emergencia se
vieron obligadas a incluir el uso del SUPERZAP para realizar las correcciones.
Impresionado por la facilidad con que usando este programa se podían sobrepasar
los controles y hacer cambios, el Jefe de Operaciones comenzó a transferir fondos
de cuentas a tres amigos.
Al tiempo, un cliente notó un error en sus cuentas y la investigación que se realizó
descubrió la manipulación. El banco había perdido US$ 128.000. Los perpetradores
fueron acusados y arrestados.
www.ruoti.com.py
2.14. El Empleado Inexistente
Un funcionario administrativo de remuneraciones con bastantes años en la empresa,

que manejaba el sistema de sueldos para 1.200 empleados, creó en el archivo maestro
de personal un registro con un empleado ficticio y comenzó a enviar los cheques de
este empleado a su propia cuenta bancaria.
Este funcionario estaba autorizado a preparar los formularios requeridos, para

agregar los registros al archivo maestro y para autorizar la creación de ellos.
El fraude fue descubierto durante una auditoría interna. Sin embargo, los auditores
tenían dos problemas:
• ¿Cómo investigar sin despertar las sospechas de quien controlaba los

archivos del sistema?
• ¿Cómo ubicar el nombre del empleado ficticio?
Afortunadamente, una agencia de gobierno había enviado recientemente una lista
alfabética de todos los empleados de la compañía y su número del seguro. Solamente
15 empleados no tenían número, lo cual no requería un gran trabajo para descubrir
que era el ficticio.
Una vez hecha la verificación con el Banco, los auditores pudieron determinar que el
poseedor de la cuenta tenía la misma dirección que el funcionario de remuneraciones.
El empleado fue despedido juzgado, acusado y enviado a prisión.
2.15. El Caso del Ataque Terrorista
En la reciente cumbre de presidentes realizada en Chile, el gobierno, a través de un

carrier de Internet, dispuso una página WEB para entregar información asociada
a la cumbre. En medio de la conferencia, se detectó que la página WEB había sido
adulterada, cambiando los títulos y textos de presentación y cambiando los punteros
de información a otras páginas relacionadas, por punteros a páginas pornográficas
de la misma Internet.
Se desconoce quien hizo tal “broma”, aún cuando hay rumores que esta pudo venir
de un “hacker” en Suecia o desde la red de la Universidad de Chile.

2.16. El caso de los negocios extras
En Los Ángeles dos programadores de una industria de alimentos fueron acusados

de ocupar su tiempo en el computador de la empresa para realizar sus propios
negocios. Los dos acusados operaban un servicio de computación que realizaba
procesamiento de datos de otra industria de alimentos.
Para mantener en secreto sus actividades “extras”, los dos programadores se

tomaban la precaución de esperar a que el sector de desarrollo de sistema estuviera
desocupado (generalmente después de las 17:30 hrs.).
En forma reiterada fueron sorprendidos trabajando, lo que empezó a crear

ciertas sospechas. Una investigación descubrió la verdadera naturaleza de este
proceso “secreto”. Los programadores fueron despedidos y acusados de fraude
computacional.
Un caso similar conocimos en Chile, hace unos años, cuando el gerente de una empresa
textil contrató a unos consultores para que seleccionaran un nuevo computador
que reemplazara al viejo WANG, ya que estaba copado. Durante el relevamiento
de antecedentes, se comprobó que en verdad el computador estaba absolutamente
copado (falta tiempo de proceso, espacio en disco y tiempo de impresión).
Sin embargo, uno de los consultores, que se quedó un día a trabajar fuera de
las horas normales, descubrió que durante la noche le llevaban la contabilidad a
una industria electrónica, usando los mismos programas de la empresa textil con
algunas modificaciones.
Curiosamente, como toda reacción, se compró un computador más grande y moderno

y no se despidió al personal involucrado.
2.17. El Caso del Correo de Votantes
El “San Francisco Examiner”, reportó que el Comité Watergate del Senado, estaba
investigando el uso secreto de un computador de propiedad de Herbcrt Kalm Bach,
secretario personal del Presidente Nixon.
Este computador fue usado para accesar el sistema de correos del comité “Mc Govern
for President” de California. El servicio computacional tenía por función destruir o
www.ruoti.com.py
retardar y, en algunos casos, modificar el archivo con el correo, de tal forma que la
literatura con la propaganda política llegar a la residencia de los votantes uno o más
días después de las elecciones municipales.
3. Práctica de auditoría de sistemas de información
3.1. Fallas en la seguridad y el delito computacional
La empresa TEXTILCON SAECA, es una empresa que se dedica a la elaboración de

textiles de distintas manufacturas, cuyo departamento de informática tiene control
del 80 % aproximadamente de los movimientos administrativos, financieros y de
manufactura.
Se realizó un análisis preliminar de la situación actual de la empresa, y se han
detectado inconvenientes que se orientan a una deficiencia del sector de tecnología
informática, por lo tanto los directivos han solicitado una auditoría de dicho sector.
Realizado una investigación preliminar se ha obtenido los siguientes datos:
Relevamiento de Hardware
• Un Servidor dedicado Pentium IV 2800 Mhz - ASUS, con 4 GB memoria RAM.

• Quince estaciones Clientes Pentium III 2000 con 512 MB memoria RAM.
• Diez estaciones Clientes Pentium III 1800 con 512 MB memoria RAM.
• Tres estaciones de impresión, impresora LX 300 matricial.
Relevamiento de Software
• Sistema operativo de red Windows 2000 Server.

• Windows XP con licencia para 25 usuarios.
• Sistemas de Contabilidad, Control de Materias primas, Control presupuestario,
Sueldos y Jornales, Tesorería.
Relevamiento de RR.HH.
• Encargado del Centro de Cómputo (Analista de Sistemas).

• Sub-encargado (3 programadores) desarrolladores.
Problemas detectados
1. No existe una adecuada planificación de las actividades ni objetivos definidos

del departamento de informática.
2. Los sistemas no se encuentran integrados entre sí.
3. No existe una verdadera certeza de los resultados arrojados por los distintos
módulos sean correctos.
4. Los personales consideran que los programas fuentes le corresponden.
5. No se disponen de extinguidores contra incendios para PC´s.
6. No se disponen de UPS para el servidor ni para las estaciones de trabajos.
7. No existe una política definida para los niveles de accesos a los sistemas.,
Cualquier usuario tiene acceso a todos los módulos.
8. Nadie se hace responsable de la administración de la red.
Tarea: Analizar otras debilidades que usted considere pertinente
3.2. Trabajo a desarrollar
Se solicita desarrollar los puntos de control interno, las implicancias y las

alternativas de solución para cada caso, teniendo en cuenta que la empresa invertirá
lo necesario para solucionarlo.
Ejemplo de Desarrollo del NCI
El problema o debilidad Especificar el título del problema o debilidad

Observación Descripción de la problemática o debilidad
Riesgo Descripción de lo que ocurriría si el problema o la
debilidad persiste
Recomendación Presentar las alternativas de recomendaciones
disponibles

www.ruoti.com.py
Inexistencia de una planificación de TI
Observación: Hemos constatado que la sociedad no dispone de una planificación

del área de TI a corto y largo plazo, así mismo no se ha evidenciado las definiciones
de objetivos del departamento.
Riesgo: La no disponibilidad de los planes y objetivos no permite al área

tecnológica de la sociedad proyectar a futuro las aplicaciones de hardware, software,
comunicaciones y recursos humanos.
Recomendación: De manera a cumplir con los requisitos del MCIIEF, en la que

establece rigurosamente los procedimientos a seguir para el desarrollo del área
tecnológica, recomendamos a la Gerencia de TI establecer los planes a corto y largo
plazo considerando básicamente las propuestas informáticas del período, estudios
de factibilidad con estimación aproximada de costos, evaluación de los riesgos,
beneficios, plan de implementación, entre otros.
4. Ejercicio práctico de proceso de Auditoría
Elaborar el proceso de Auditoría de Sistemas de Información a la Caja Paraguaya

de Jubilaciones y Pensiones
A continuación describimos la situación observada en el momento del
relevamiento:
Estructura de la Caja Paraguaya de Jubilaciones y Pensiones

La administración del área de TI corresponde al Sr. Pedro Paredes, estudiante de

Administración de Empresas 4° curso.
El departamento dispone 3 personales internos, encargados de las áreas de software,

redes y mantenimiento de hardware, todos ellos Analistas de Sistemas Sin embargo,
no se encuentra definido claramente las funciones del cada uno debido a que no se
dispone de documentaciones que así lo avalen.
A continuación describimos lo disponible en Hardware, Software y Recursos

Humanos:
Hardware
• Un servidor dedicado Pentium IV 3000 Mhz, con 1 Gb. de memoria RAM
• Un Servidor dedicado Pentium III 2000 Mhz, con 540 Mb. de memoria RAM
• Veinte estaciones Clientes Pentium III 1000 Mhz. con 128 memoria RAM
• Diez estaciones de impresión, impresora LX 300 matricial
• Cinco impresora HP 3650 inyección de tinta
Software
• Sistema operativo de red Windows 2003 Server, Sistema de red
• Windows XP con licencia para 3 usuarios
• Office XP con licencia para 3 usuarios
• Sistemas de producción: Contabilidad, Control presupuestario, Aportes,
Solidaridad, Jubilaciones, Sueldos y Jornales, Tesorería, Préstamos.
RR.HH
• Encargado del Centro de Cómputo: Pedro Paredes. Estudiante de Administración.
• Sub-encargado: 3 Analistas de sistemas.
Parametro Institucional
• Sede central: Asunción
• Sucursales en el interior: CDE y Concepción
• Cantidad de Funcionarios: 46
• Cantidad de Funcionarios con requerimientos de informática: 39
www.ruoti.com.py
La caja maneja un modelo potencial de 3600 beneficiarios, la tarea transaccional de

mayor envergadura es el sistema de préstamos.
Problemas identificados:
1. No se ha identificado ninguna documentación sobre los planes y políticas

del departamento de TI.
2. No existen comunicaciones con las sucursales del interior. Todas las
actualizaciones de datos son elaborados por lotes, a 1° hora del día, a través
de los documentos de transacciones.
3. Para cualquier transacción entre las sedes se realizan consultas de saldos de
socios a través de llamadas telefónicas.
4. No se dispone ningún documento (diagrama entidad relación, diagrama de
flujo de datos entre otros) del sistema.
5. No se disponen de los manuales de usuarios del sistema.
6. Los usuarios potenciales de las sucursales del interior no disponen
conocimientos de computación.
7. No existe un encargado de red, responsable de la red interna. Todos los
pedidos de creación de usuarios en la red, así como en el sistema corporativo
son realizados verbalmente.
8. No existe una política de manejo de las claves de accesos, tanto de los
sistemas corporativos, como del sistema operativo de red.
9. No existe restricción alguna de accesos a discos desde otra terminal.
10. No existe un plan de contingencias para seguir en caso de catástrofe, que
pueda ocurrir.
11. Las copias de respaldos son elaboradas diariamente, y son guardadas en
la caja fuerte de la institución. No existe una copia alternativa que sean
resguardadas fuera del local de la institución.
12. El mantenimiento a las computadoras los realizan los personales de la
Caja.
13. No se disponen de extinguidores para computadoras.

14. No existe seguridad de acceso en el departamento de informática. Cualquier

personal accede al mismo sin restricción.
15. Se dispone solamente de 3 licencias de Windows XP y Office XP.
16. Los sistema informáticos no se encuentran integrados entre si, esto significa
que todas las transacciones generadas por los módulos son cargadas
nuevamente en los módulos que lo requieran y principalmente en la
contabilidad.
17. No existe una clara definición de los derechos de los programas fuentes.
18. Los servidores no están protegidos con pisos falsos.
19. Las terminales de caja (Cobranzas), disponen de medios de almacenamiento
externos, disqueteras y grabadores de CD´s.
20. Existen diferencias entre la Cartera de Créditos y Aportes con la
Contabilidad
21. Se ha observado que actualmente no se efectúan cierres diarios de las
operaciones contables. Es posible las modificaciones de datos de asientos
con fechas anteriores al actual.
Tarea: Se solicita:
• Analizar otras debilidades que usted considere pertinente.

• Emitir un informe sobre la situación de la empresa.
• Elaborar las recomendaciones tendientes a mejorar el control interno del área de
informática.

www.ruoti.com.py
Capítulo VIII
Directrices y papeles de trabajo para la

realización de una Auditoría Informática
1. Pasos a seguir para recomendación de soluciones

• Identificación del problema.
• Analizar implicancias.
• Sugerir alternativas de solución.
Problema: El problema radica en la posibilidad de grabar asientos

desbalanceados
Implicancia: Informes no confiables del Diario, Mayor, Balance General, Estado

de Resultados, entre otros.
Recomendaciones: Recomendar la verificación detallada del programa de carga

del libro diario y/o generación automática de asientos desde otros módulos.
2. Modelo de Nota de Control Interno
Modelo I - Asiento desbalanceado
Durante la realización de nuestro trabajo hemos constatado que el sistema de

contabilidad utilizado en la empresa, permite grabar asientos desbalanceados,
(sumas no iguales, o dispares). Esta situación evidencia una falta de seguridad y
confiabilidad de los informes producidos por el sistema.
Recomendamos verificar el programa del Libro Diario, de manera a no permitir grabar
asientos desbalanceados, respetando los principios de contabilidad generalmente
aceptados, y brindar seguridad y confiabilidad en la operación del sistema así como
en los informes que arroja.
Modelo II
El problema: Especificar el título del problema o debilidad

Descripción del problema: Descripción de la problemática o debilidad
Tipificación del riesgo: Alto – Medio - Bajo
Descripción del riesgo: Descripción de lo que ocurriría si el problema o la
debilidad persiste
Recomendaciones: Presentar las alternativas de recomendaciones
disponibles
Inexistencia de una planificación de TI
Descripción del problema: Hemos constatado que la sociedad no dispone de una

planificación del área de TI a corto y largo plazo, así mismo no se ha evidenciado las
definiciones de objetivos del departamento.
Tipificación del riesgo: Alto
Descripción del riesgo: La no disponibilidad de los planes y objetivos no permite
al área tecnológica de la sociedad proyectar a futuro las aplicaciones de hardware,
software, comunicaciones y recursos humanos.
Recomendación: De manera a cumplir con los requisitos del MCIIEF, en la que
establece rigurosamente los procedimientos a seguir para el desarrollo del área
tecnológica, recomendamos a la Gerencia de TI establecer los planes a corto y largo
plazo considerando básicamente las propuestas informáticas del período, estudios
de factibilidad con estimación aproximada de costos, evaluación de los riesgos,
beneficios, plan de implementación, entre otros.
3. Papeles de trabajo de controles de TI
1 - Organigrama del área de TI.

1.1 Staff
1.2 Lineal
1.3 Dependiente

www.ruoti.com.py
1.4 No se dispone
1.5 Está desactualizado
Observación:
2 – Identificación del responsable de la Gerencia de TI.
2.1 Presidente
2.2 Gerente General
2.3 Gerente Administrativo
2.4 Administrador
2.5 Contador
2.6 Otros
Observación:
3 - Organización de la Gerencia de TI.
3.1 Gerente
3.2 Analista Funcional
3.3 Analista Programador
3.4 Administrador de BD
3.5 Administrador de Redes
3.6 Programador
3.7 Soporte Técnico
Observación:
4 - Manual de Funciones de TI.

4.1 Disponible y actualizado
4.2 Disponible y desactualizado
4.3 Los funcionarios tienen acceso
4.4 No Disponible
Observación:
5 - Manual de Procedimientos de TI.

5.1 Disponible y actualizado

5.2 Disponible y desactualizado

5.3 Los funcionarios tienen acceso
5.4 No Disponible
Observación:
6 – Segregación de Funciones de TI.
6.1 Análisis y Programación
6.2 Implementación, Soporte Técn.
6.3 Administración de Redes y BD
6.4 Personal imprescindible
Observación:
7 – Contactos claves en la Dirección de TI, para los trabajos de auditoría

Informática.
7.1 Se dispone
7.2 No se dispone
Observación:
8 – Control de productividad de desarrollo.

8.1 Se dispone
8.2 Reportado a la Alta Gerencia
8.3 Revisado
8.4 No se dispone
Observación:
9 – Aplicación de metodología formalizada para el desarrollo de sistemas.

9.1 Se dispone de un estándar
9.2 No se dispone de un estándar
Observación:
10 – Documentación del sistema (Diagrama Entidad Relación).

10.1 Actualizado y Normalizado
10.2 No está actualizado
10.3 No se dispone
Observación:

www.ruoti.com.py
11 – Documentación del sistema (Diagrama de Flujo de Datos).

11.1 Actualizado
11.2 No está actualizado
11.3 No se dispone
Observación:
12 – Administración y mantenimiento de Base de Datos.
12.1 Existe un responsable de la
Administración de Base de Datos.
12.2 No existe un responsable.
Observación:
13 – Propiedad y custodia de datos del sistema.
13.1 Definido la responsabilidad
13.2 No se ha definido
Observación:
14 – Plan Estratégico de TI (Mayor a 12 meses).
14.1 Disponible
14.2 No disponible
Observación:
15 – Plan Operativo de TI (Menor a 12 meses)..
15.1 Disponible
15.2 No disponible
Observación:
16 – Encuesta sobre rendimiento de TI.
16.1 Disponible
16.2 Se ha realizado un seguimiento
16.3 No disponible
Observación:
17 – Inventario de Hardware.
17.1 Disponible, actualizado.
17.2 No disponible
Observación:

18 – Relevamiento de Servidores, (Configuraciones).

18.1 Servidor de Aplicativos
18.2 Servidor de BD
18.3 Servidor de Correo
18.4 Servidor de Dominio
Observación:
19 – Responsable de la Sala de Servidores.
19.1 Existe un encargado.
Observación:
20 – Disponibilidad de Firewall.
20.1 Disponible
20.2 No disponible
Observación:
21 – Inventario de Software.
21.1 Disponible y actualizado.
21.2 No disponible
Observación:
22 – Relevamiento de Software.
22.1 Lenguaje de programación
22.2 Base de Datos
22.3 Sistema Operativo de RED
22.4 Sistema Operativo Cliente
22.5 Antivirus
22.6 Aplicaciones de producción
22.7 Módulos
Observación:
23 – Licencias de Software.
23.1 Actualizado y controlado
23.2 Desactualizado

www.ruoti.com.py
23.3 No disponible
Observación:
24 – Software propietario sin licencias.
24.1 Disponibilidad de software propietario sin licencia,
instalado en los servidores y estaciones de trabajos.
24.2 No existen software propietario sin licencias.
Observación:
25 – Conexión LAN.
25.1 Topología.
25.2 Protegido.
25.2 No existe un plano de instalación.
Observación:
26 – Aplicación de intranet.
26.1 Administrado por un responsable, para evitar accesos a páginas
no permitidas, así como programación para disminuir los SPAN.
Observación:
27 – Conexión externa.
27.1 Tipo de conexión.
27.2 Criterios de seguridad aplicado.
Observación:
28 – Contrato de mantenimiento de hardware.

28.1 Se dispone, vigente.
28.2 Se dispone, vencido.
28.3 No se dispone.
Observación:
29 – Contrato de mantenimiento de software.

29.1 Se dispone, vigente.
29.2 Se dispone, vencido.
29.3 No se dispone.
Observación:
30 – Migración de sistemas a nuevos entornos informáticos.

30.1 Planeado.
30.2 No planeado.
30.3 Inconsistencia de datos.
Observación:
31 – Implementación de nuevos sistemas - Planeamiento.

31.1 Planeado.
31.2 No planeado.
31.3 Problemas significativos.
31.4 Aplicación paralelo.
Observación:
32 – Volumen de mantenimiento y actualizaciones realizado sobre los sistemas.

32.1 Coordinado y dirigido.
32.2 No coordinado.
32.3 Mantenimiento significativo.
Observación:
33 – Identificación de problemas o deficiencias significativas en las funcionalidades

ofrecidas por los sistemas.
33.1 Óptimas condiciones.
33.2 Errores detectados (citar).
33.3 Se ha establecido mecanismos de corrección.
33.4 No se ha establecido mecanismos de
corrección.
Observación:
34 – Manipulación de datos a través de un MGBD.

34.1 Se ha detectado.
34.2 No se ha detectado.
34.3 Permite la operativa actual.
34.4 Bloqueado.
Observación:

www.ruoti.com.py
35 – Entornos separados para desarrollo de sistemas.

35.1 Red y servidor paralelo.
35.2 Misma red de producción.
Observación:
36 – Entornos separados para pruebas sobre datos de sistemas.

36.1 Red y servidor paralelo.
36.2 Misma red de producción.
36.3 Datos paralelos.
36.4 Prueba sobre datos de producción.
Observación:
37 – Control de versiones del código fuente para traspaso al entorno de producción.

37.1 Se dispone de una biblioteca de fuentes.
37.2 No se dispone de una biblioteca de fuentes.
37.3 Planilla de control.
37.4 No existe control.
Observación:
38 – Acceso del personal de desarrollo al entorno de producción.

38.1 Existen controles, queda registrado.
38.2 No existen controles.
38.3 No es permitido el acceso.
Observación:
39 – Control de la actualización de uso de la misma versión de un sistema, o los

elementos centrales del sistema al entorno de producción.
39.1 Existen controles de utilización de
versiones en las terminales del cliente.
39.2 No existen controles.
39.3 EXE instalados en el servidor.
Observación:

40 – Control de programación de pistas de auditoría interna a través del sistema de

aplicación.
40.1 Se han programado pistas de auditoría
interna, para las funciones sensibles.
40.2 No existen programaciones de pistas de
auditoría interna.
40.3 Las programaciones no son suficientes.
Observación:
41 – Restricciones de uso de sistemas de producción por niveles de usuarios.
41.1 Se han definido niveles de
usuarios por módulos.
usuarios por menúes.
usuarios por base de datos.
41.4 No existe restricción alguna.
Observación:
42 – Confiabilidad de los reportes arrojados por los sistemas.
42.1 Existen casos de exposición
incorrecta de informaciones – citar.
42.2 No existen casos.
Observación:
43 – Evaluación del sistema contable.
43.1 Están totalmente los módulos integrados entre sí
y con la contabilidad.
43.2 Es posible la eliminación de cuentas contables,
una vez generado movimientos con ello.
43.3 Es posible la modificación de asientos una vez
cerrado la contabilidad.
Observación:
44 – Procedimiento para administrar los cambios en los sistemas de una forma
controlada.
44.1 Están documentado los pedidos de adición y
modificaciones de programas, cual es el procedimiento.
44.2 No se encuentra documentado.

www.ruoti.com.py
44.2. Están documentado las aceptaciones de las

modificaciones.
44.3. No se encuentran documentados.
Observación:
45 – Monitoreo por parte de la Gerencia de TI de la ejecución de contratos con

terceros.
45.1 Existe un control de monitoreo a
través de planillas de control.
45.2 No se realiza ningún control.
Observación:
46 – Control de cumplimiento del proveedor sobre el mantenimiento del sistema –
Caso de adquisiciones de sistemas de terceros.
46.1 Existe un cronograma de
desarrollo, y es controlado.
46.2 No existe control alguno.
Observación:
47 – Disponibilidad de los programas fuentes.
47.1 Los programas fuentes son de
propiedad de la empresa.
47.2 Pertenece a terceros.
47.3 Existe un plan de adquisición.
Observación:
48 – Control por parte de la Gerencia de TI sobre la calidad funcional y operacional
de los sistemas.
48.1 Existe un control por parte de la Gerencia de
TI, del conocimiento de grado de aceptación de los
sistemas, a través de encuestas e indagaciones
48.2 No existe conocimiento, así como no son
realizado encuestas.
Observación:
49 – Participación de la Gerencia de TI en la realización de las pruebas sobre los
cambios en los sistemas.
49.1 El Gerente de Ti participa en las pruebas a
los sistemas

49.2 No existe participación

Observación:
50 – Control de contacto del personal de desarrollo con los usuarios finales de los
sistemas.
50.1 Existe una participación activa por parte del
personal de desarrollo.
50.2 Existe un contacto no suficiente, para
determinar las necesidades.
Observación:
51 – Responsable de la aprobación y definición de prioridades de las solicitudes de
cambio.
51.1 Existe un mecanismo formal para las
aprobaciones de los cambios, es decir se controlan
las prioridades.
51.2 No existe un control de prioridades
Observación:
52 – Control de procedimientos apropiados que aseguren que los cambios aprobados
se implanten puntualmente y que permitan hacer un seguimiento de su progreso.
52.1 Existe un control de implementación de los
cambios, y la agilidad de dichos cambios.
52.2 No existen controles sobre los cambios.
Observación:
53 – Manuales de Usuarios de sistema impreso.
53.1 Se disponen.
53.2 Están actualizados.
53.3 Están disponibles a los usuarios.
53.4 No se disponen.
Observación:
54 – Manuales de Usuarios de sistema interactivo.
54.1 Se disponen y están completos.
54.2 Están actualizados.
54.3 Están disponibles a los usuarios.
54.4 No se disponen.
Observación:
www.ruoti.com.py
55 – Normalización de datos.
55.1 Se encuentran normalizados
55.2 No se encuentran normalizados
Observación:
56 – Mecanismos y procedimientos para actualizar la documentación, cuando se
producen cambios en los sistemas.
56.1 Existen mecanismos para la actualización
de los manuales de documentaciones.
56.2 No existen mecanismos.
Observación:
57 – Definición de la cantidad de personas de informática asignadas al desarrollo y
mantenimiento de los sistemas.
57.1 Es suficiente la cantidad de
desarrolladores, considerando los proyectos.
57.2 No son suficientes.
Observación:
58 – Dominio acabado de los sistemas por parte del personal de desarrollo.
58.1 Los analistas tienen dominio acabado de
los sistemas y herramientas de desarrollo.
58.2 Es necesario más capacitaciones.
Observación:
59 – Capacitación adecuada de los usuarios para la utilización de los sistemas.
59.1 Se ha desarrollado capacitaciones adecuadas.
59.2 No se ha desarrollado capacitaciones.
59.3 No existe una capacitación adecuada y un
mecanismo de capacitaciones para nuevos usuarios.
Observación:
60 – Procedimientos para creación de usuarios de red.
60.1 Solicitud documentada por los usuarios
solicitantes, y autorizados por la jefatura inmediata, y
aprobada por la Gerencia de TI.
60.2 No se encuentra documentado, verbal.
Observación:

61 – Procedimientos para creación de usuarios de los sistemas aplicativos.

61.1 Solicitud documentada por los usuarios solicitantes,
y autorizados por la jefatura inmediata, y aprobada por la
Gerencia de TI.
61.2 No se encuentra documentado.
Observación:
62 – Definición de contraseñas.
62.1 La contraseña deberá ser diferente, de al menos 5
contraseñas anteriores.
62.2 Deberá existir un mínimo de caracteres.
62.3 Debe ser diferente al usuario.
Observación:
63 – Control de actualizaciones periódicas de usuarios de red y de aplicativos.
63.1 Existe comunicación por parte de RR.HH. referente
a los movimientos de personales – usuarios, es decir,
comunicación de renuncias, despidos, rotaciones entre
otros.
63.2 No existe una comunicación efectiva de lo referente
a RR.HH.
Observación:
64 – Control de vencimientos de contraseñas y/o claves en forma periódica, de
aplicativos y de red (LAN - Internet).
64.1 Se ha programado un vencimiento periódico de
contraseñas, para los aplicativos, LAN e internet.
64.2 No existe vencimientos de contraseñas.
Observación:
65 – Programación de bloqueo de intento de ingresos con claves inválidas,
principalmente en la red LAN, así como de aplicativos.
65.1 Se ha programado un bloqueo de intentos con claves
inválidas, para los aplicativos, LAN e internet, únicamente
es posible desbloquear a través de administrador de
sistemas..
65.2 No existe programación de bloqueos.
Observación:

www.ruoti.com.py
66 – Definición de privilegios y perfiles de usuarios, de los aplicativos, de red y de

BD.
66.1 Se ha programado los accesos a los módulos por
perfiles de usuarios.
66.2 Los privilegios de Select – Insert – Update -
Delete, están establecidos a nivel de base de datos, por
usuarios.
66.3 No están definidos ningún parámetro de perfiles.
Observación:
67 – Restricción de accesos a otras unidades de discos desde una estación de trabajo.
67.1 Se han programado a nivel de red, restricciones a
las ET, de la red, carpetas y recursos.
67.2 Se ha programado el acceso a las carpetas y
recursos, a través de contraseñas.
67.3 No existe restricción alguna.
Observación:
68 – Procedimientos de realización de copias de respaldo - Backup.
68.1 Medios.
68.2 Periodicidad.
68.3 Lugar de almacenamiento interno en caja fuerte.
68.4 Lugar de almacenamiento externo en empresas
especializadas de seguridad de datos.
68.5 Cantidad de copias.
68.6 Datos que se respaldan.
68.7 Software de realización.
68.8 Responsable de realización.
Observación:
69 – Planilla de control de realización de copias de respaldos – backup.
69.1 Existe una planilla controlada, de realización.
69.2 No existe un control de realización.
Observación:
70 – Detectores de humos en la sala de servidores
70.1 Se dispone de los aparatos detectores de humo y
calor.

70.2 No se dispone de los aparatos detectores de humo

y calor.
Observación:
71 – Pisos falsos para los servidores
71.1 Se disponen los pisos falsos antiestática, para los
servidores.
71.2 No se disponen los pisos falsos antiestática, para
los servidores.
Observación:
72 – Cableado de red ordenado y organizado.
72.1 Cableado de red ordenado y organizado por
terminales.
72.2 No se encuentran ordenados y organizados por
terminales.
Observación:
73 – Certificación del cableado de red.
73.1 Se dispone de una certificación de red, realizado por
una empresa especializada.
73.2 No se dispone de una certificación.
73.3 No existe documentación alguna.
Observación:
74 – Disponibilidad de un servidor de respaldo (replicado – espejado).
74.1 Se dispone de un servidor de respaldo, espejado –
replicado.
74.2 No se dispone de un servidor de respaldo.
Observación:
75 – Disponibilidad de instalaciones de sistema de puesta a tierra.
75.1 Se disponen las instalaciones puesta a tierra.
75.2 No se disponen las instalaciones puesta a tierra.
Observación:
76 – Disponibilidad de extinguidores contra incendio especiales para equipos de
computación.
76.1 Se dispone, para equipos computacionales – tipo ABC.
76.2 Se dispone los convencionales.

www.ruoti.com.py
76.3 No se dispone.
Observación:
77 – Climatización adecuada del ambiente de la sala de servidores.
77.1 Existe una climatización adecuada.
77.2 No existe una climatización adecuada.
Observación:
78 – Control de acceso al departamento de informática, registros de bitácoras de
accesos.
78.1 Existe un control restringido, y se deja una bitácora
de acceso.
78.2 Existe una restricción de acceso, pero no se deja una
bitácora de acceso.
Observación:
79 – Seguridad de la sala de TI.

79.1 Existe un control restringido.
Observación:
80 – Disponibilidad de un Plan de contingencias.

80.1 Se dispone de un plan de contingencias, que describa
los pasos a seguir en caso de contingencias.
80.3 Se dispone de una estructura paralela, fuera del recinto
de TI, que permita seguir operando con los sistemas, de
manera a minimizar el impacto de la catástrofe.
80.3 Se dispone de un plan, pero desactualizado.
80.3 No se dispone de una estructura paralela.
80.3 No se dispone de un plan de contingencias.
Observación:
81 – Prueba realizada al plan de contingencias.

81.1 Se ha realizado una prueba al plan de contingencia.
81.1 No se ha realizado una prueba al plan de contingencia.
Observación:

82 – Aprobación por la Alta Gerencia del plan de contingencias.

82.1 El Plan de Contingencias ha sido aprobado
por la Alta Gerencia.
82.1 No existe aprobación del plan.
Observación:
83 – Disponibilidad de un Plan de seguridad de TI, y comunicación a los usuarios –

propietarios de los datos.
83.1 Se dispone de un plan de seguridad de Ti,
en la que se responsabiliza a los propietarios de
los datos, emanada de la Alta Gerencia.
83.3 No existe un plan de seguridad de TI.
Observación:
84 – Disponibilidad de Sistema de Alimentación Ininterrumpida – UPS.
84.1 Todos los equipos disponen de UPS.
84.2 Los principales equipos disponen de UPS.
84.3 Solo los servidores disponen de UPS.
84.4 No existen UPS.
Observación:
85 – Generador de electricidad.
85.1 Se dispone de generador.
85.2 No se dispone de generadores.
Observación:
86 – Sistema de control antivirus.
86.1 Existe software antivirus corporativo y
cliente, actualizado.
86.2 No existe software antivirus.
Observación:

www.ruoti.com.py
Conclusion de la Auditoría
En esta sección se especifican todas las observaciones no incluidas en los puntos de

control.
.....................................................
RESPONSABLE
Fecha:........./................/..................
4. Modelo de Propuesta de Servicios
__ de _________ de 20......
Señores
****El Cliente****
Dirección
De nuestra consideración:
Por el presente tenemos a bien presentarle nuestra propuesta técnica y económica de

prestación de servicios profesionales de auditoría informática.
4.1. Objetivo
Nuestra intervención como profesionales independientes tendrá como objeto realizar

un examen de auditoría que nos permita emitir nuestro informe profesional sobre el
estado actual del ambiente informático de la sociedad.
Nuestro plan buscará asegurar que los objetivos de auditoría se cumplan en tiempo
y de una manera eficiente.

4.2. Aspectos relevantes del plan de auditoría
Comentaremos a continuación los aspectos más relevantes de nuestro plan de

auditoría:
• Análisis de la organización actual: En esta etapa se analizará la organización
actual, ubicación del área informática dentro de la sociedad, los centros de
decisión, funciones y procedimientos.
• Análisis de los procesamientos actuales: En esta etapa se analizarán los
distintos tipos de procesamientos, manuales y automatizados; estudios de
documentaciones, estudios de archivos y definición de volúmenes. recursos
humanos, hardware y software, seguridad e integridad de datos, posibilidad
de manipuleo de datos.
• Diagnóstico de la situación Actual: Informe de la situación actual en que se
encuentra el ambiente informático de la institución.
4.3. Alcance de los servicios
Para cumplir con los objetivos trazados inicialmente, nuestro examen comprenderá,
entre otros los siguientes procedimientos:
• Relevamiento organizacional: Análisis del área informática recursos
humanos, hardware, software y comunicaciones.
• Auditoría a programas y usos de tablas: Seguimiento a la auditoría de
programas y tablas.
• Sistemas de archivos: Seguridad respecto a la posibilidad de recuperación de
los archivos dañados por corte de energía eléctrica, contaminación de virus
etc. Evaluación de los usuarios que acceden a las bases de datos.
• Evaluación de la seguridad: Del ambiente informático, de los distintos
niveles de accesos a los menús de los sistemas, confidencialidad de los datos,
seguridad de acceso físico al centro de cómputo, procedimientos a seguir en
casos de imprevistos; políticas sobre copias de seguridad y resguardo de
información, políticas sobre mantenimiento de hardware y software.
• Evaluación de los procedimientos: administrativos, segregación de funciones,

www.ruoti.com.py
ciclo de vida de desarrollo de sistemas.

• Auditoría de Base de Datos: Control de estructura, diseño lógico y físico,
control de Integridad referenciales y consistencia de datos, revisión de
políticas de acceso y control de claves (debilidad de claves, permisos de
manipulación de tablas, caducidad de claves, periodicidad de cambio de
claves), estabilidad del motor de base, rendimiento del motor (perfomance
por accesos concurrentes), políticas de backup del motor de base de datos.
• Auditoría de Estructura de Red: Revisión de la estructura física del montado
de la red, revisión de lo equipos concentradores y routers, verificación del
dominio (disponibilidad de políticas de dominio).
4.4. Metodología
Nuestra tarea será realizada de acuerdo a un cronograma que elaboraremos una

vez aceptada nuestra propuesta, ajustándonos a sus requerimientos. El trabajo se
realizará básicamente en dos etapas:
• La primera: Relevamiento general de los recursos disponibles y controles
internos aplicados, verificación de todos los sistemas informáticos.
• La segunda: Estudio riguroso sobre la situación actual, para su posterior
sugerencia y recomendaciones tendientes a mejorar el ambiente informático
de la sociedad.
4.5. Presentación de Informes
Como resultado de nuestro examen presentaremos los siguientes informes:
1- Informe sobre el resultado del trabajo realizado.

2- Informe sobre las sugerencias y recomendaciones tendientes a mejorar el control
interno del área informática.
4.6. Validéz de la oferta
Esta oferta tiene validez hasta 30 días de haber sido presentada la propuesta.

4.7. Honorario y forma de pago
El costo del servicio asciende a ...................................... El importe no incluye el

Impuesto al Valor Agregado.
5. Modelo de Carta Gerencial
Fecha...........,.............................de 20..........
Señor……
Presidente……….
El cliente…………….
Ciudad
De nuestra consideración:
Hemos efectuado la revisión sobre el actual procedimiento que se lleva a cabo en el

Departamento de informática del El cliente.
5.1. Objetivo General
Realizar una Auditoría Informática en la sociedad, permitiendo de esta manera

desarrollar los objetivos básicos de control definidos en las normas estándares de
Auditoría Informática CoBiT.
5.2. Objetivo Específico

• Verificar la estructura organizativa y las normas vigentes en el Departamento
de Informática, poniendo especial énfasis en la adecuada segregación de
funciones.
• Evaluar que las normas y procedimientos vigentes en el Departamento de
Informática se encuentren preparados para minimizar riesgos de cambios a
programas y evitar modificaciones no autorizadas a los sistemas informáticos.
• Evaluar que las políticas de seguridad de datos vigentes en el Departamento
de Informática estén elaborados para minimizar la posibilidad de accesos no
autorizados a los datos y programas.

www.ruoti.com.py
• Evaluar los planes de contingencias desarrollados por el Departamento de

Informática a efectos de asegurar la continuidad del procesamiento de la
información en caso de interrupciones en los servicios, originados por desastres
u otras contingencias.
• Controlar las aplicaciones de herramientas de auditoría a través del sistema
operativo de red y sistemas corporativos implementados en el Departamento de
Informática, a efectos de analizar los parámetros de seguridad de los sistemas y
la adecuación de los mismos a las políticas de seguridad vigentes.
• Evaluar los sistemas informáticos basados en el enfoque de confiabilidad de las
informaciones que son utilizadas en las operaciones de los sistemas corporativos,
la flexibilidad que proporcionan y el grado de satisfacción que brindan a los
usuarios.
• Evaluar la adecuada capacitación de los usuarios en las operaciones de los
módulos.
• Evaluar la planificación estratégica de informática desarrollada por el
Departamento de Informática.
En base a la labor realizada, en el marco de la auditoría del área observamos situaciones

que hemos considerado conveniente informar a la Presidencia. Los procedimientos y
funciones que actualmente no son considerados en el Departamento de Informática,
así como los temas observados, junto con sus recomendaciones para su corrección,
son detallados en el presente informe.
Aprovechamos la oportunidad para expresar nuestro agradecimiento por la

cooperación recibida del personal de la entidad durante el transcurso de nuestro
trabajo.
Atentamente,

Capítulo IX
Glosario de Términos Técnicos
Este documento fue extraído del Manual de Control Interno Informático para
Entidades Financieras, de la Superintendencia del Bancos del Banco Central del
Paraguay, de la dirección web – www.bcp.gov.py/sb-bcp.py, documento de uso
público.
Acceso lógico: Se refiere a la acción del usuario que le lleva a utilizar y/o visualizar,
y/o modificar y/o borrar datos o programas. Para que el usuario tenga acceso lógico,
en ocasiones no es necesario que tenga acceso físico a los medios computacionales,
pues el usuario que se encuentra en una ubicación remota respecto a los sistemas
computacionales a los cuales desea tener acceso lógico, puede tener dicho acceso a
través de sistemas de comunicación que hacen posible el acceso.
Acreditación: Documento que le da a uno la facultad de hacer alguna cosa.

Últimamente, diversas instituciones emiten certificados de acreditación que declaran
que las actividades de la empresa se ajustan a ciertas normas o reglas específicas.
Por ejemplo, que cumplen con las Normas de la Institución “X” que es un cuerpo
colegiado de especialistas, en contabilidad, informática, auditoría, etc., o que cumple
con las Normas de Calidad “ISO XXX”.
Actualización: Actualización de datos se refiere principalmente a las modificaciones

que van sufriendo ciertos datos de Archivos Maestros a causa de las operaciones.
Ej.: actualización del saldo de caja de ahorro, actualización del saldo de deuda,
actualización del total de horas trabajas en el mes.
Agenda: (Schedule - scheduling) El Grupo de Operaciones cuenta con una Agenda

en la cual se registran todos los trabajos a ser ejecutados por dicho Grupo, así como
consideraciones de horario, prioridades, etc.

www.ruoti.com.py
Archivo Maestro: Archivo de Datos principales, la mayoría de los cuales no varían

con la ejecución de operaciones. Ej.: archivo de cuentacorrentistas, archivo de
cuentas de contabilidad, archivo de personal.
ASTI: Profesional ASTI - Auditor de Sistemas de TI
Caballo de Troya: Programa insertado en un sistema por un hacker, y que va a hacer

ejecutar una función evidentemente inofensiva para el sistema, mientras ejecuta
alguna acción no autorizada de manera no detectable. Ej.: copia información de un
archivo confidencial a un archivo no confidencial, al cual el hacker puede acceder
luego, sin o conocimiento del Propietario o Custodio de los Datos.
Certificación: Documento emitido por alguien con la autoridad correspondiente

para comprobar de manera fehaciente alguna cosa. Un Auditor Independiente
puede emitir una certificación de que las actividades se cumplen conforme a las
normas y prácticas habitualmente aceptadas. En general, la certificación emitida
por una Entidad Independiente de renombre tendrá mayor credibilidad que una
emitida por personal de la propia Entidad auditada. La Acreditación es una forma
de Certificación.
Cuenta del Usuario: Un ambiente de empresarial de TI debe estar protegido por

procedimientos de Seguridad de acceso. El administrador de Seguridad de Acceso
habilita una Cuenta del Usuario para cada Usuario que puede acceder a los recursos
del Sistema. La Cuenta del Usuario consta básicamente de un identificador de
usuario, el cual es de público conocimiento, Un password o contraseña acceso del
usuario, que es de conocimiento exclusivo del usuario, Datos diversos del usuario,
opcional, Datos de lo que hizo el usuario, opcional, y con muy diversos niveles de
detalle.
Estructurado: Aquí se usa estructurado como sinónimo de top/down, Método de

Depuraciones Sucesivas, etc., que consiste en tener en primer lugar una visión poco
profunda del todo, e ir luego teniendo una visión cada vez más profunda de cada una
de sus partes, y así sucesivamente.
En línea: En informática se dice que la información está en línea, cuando el Usuario

puede acceder a la información desde una terminal, pantalla y teclado. El acceso en

línea puede ser solo para visualización de datos, o puede ser tanto para visualización
como para modificación de datos. Lo que el Usuario puede hacer con los datos,
depende de las funciones que estén habilitadas por el programa que esté utilizando,
así como los mecanismos de seguridad adicional que estén implementados en el
Sistema.
Calificación: Se refiere a las condiciones necesarias para que el profesional desempeñe

cierto tipo de funciones. Quien tiene la formación académica, la experiencia y puede
asumir los niveles de responsabilidad descriptos para el cargo, está calificado para
desempeñar ese cargo.
Comité de Dirección y Planificación de los servicios de TI: La Gerencia de TI es

un órgano de Servicios. Prácticamente todo lo que produce lo produce en beneficio
de otras Unidades Funcionales de la Organización. La Dirección General establece
las funciones y procedimientos de este Comité. Este Comité está integrado por un
representante de las Unidades Funcionales que son los usuarios actuales o potenciales
más importantes. El representante de cada Unidad Funcional debe ser del más alto
rango posible. Le compete en general establecer la Política de Informatización de la
Organización, la aprobación de los Planes Estratégicos de TI a corto y largo plazo,
la fijación de prioridades, la evaluación y seguimiento de las actividades de TI en la
organización, etc. Ver: 10.3.1. Comité de Informática, en Auditoría de la Dirección,
de Juan Miguel Ramos Escobosa, en el Compendio: Auditoría Informática, Un
enfoque Práctico, Editorial RA-MA.
Control de Cambios: La Gerencia de TI debe establecer un Procedimiento de

Control de Cambios. Las solicitudes de Cambio provienen en general de los usuarios,
pero pueden originarse por iniciativa de alguna de las Unidades Funcionales a cargo
de la Gerencia de TI. El Procedimiento de Control de Cambios debe establecer qué
tipos de cambios pueden ser solicitados por cada uno de los habilitados a tal efecto,
las aprobaciones de los niveles jerárquicos pertinentes para cada tipo de solicitud
de cambio, la manera en que se manejarán las prioridades y urgencias en la Unidad
Funcional de TI, etc. Todo el Capítulo AI.6 del MCIIIF se refiere al Control de
Cambios.
Custodio: Persona o Unidad Funcional que es nombrada responsable de la ejecución

www.ruoti.com.py
del Sistema o ejecución de los Procedimientos en nombre del Usuario.
Custodio de los Datos: Persona o Unidad Funcional que es nombrada responsable

de la guarda, seguridad y administración de acceso a datos, en nombre del Usuario
que es el “Propietario de los Datos”.
Data Mining: Software que accede a bases en modo OLAP o Data Warehouse, y es
capaz de ejecutar algoritmos avanzados tales como los de análisis de perspectivas
con distribución activa de la información. Utilizan masivamente algoritmos de
inteligencia artificial, tales como los de redes neuronales, lógica difusa, análisis
avanzado de regresión, teoría del caos, técnicas estadísticas, clustering, árboles de
decisión, etc. Se utilizan principalmente para predicción en base a grandes volúmenes
de datos. Soluciona incluso problemas en los cuales resulta difícil aislar variables
determinísticas.
Data Warehouse: Repositorio de datos corporativos producidos por los Sistemas

de Gestión de la Empresa. Básicamente se diferencias de las Bases de Datos
transaccionales, en el hecho de que no se encuentran en tercera forma normal,
sino que se aproximan a la primera. La idea radica en tener almacenamiento
corporativo en un formato más fácilmente comprensible por los usuarios.
Datos e Información: Los términos Datos e Información frecuentemente se usan

como sinónimos en estos manuales. Si embargo, existen básicamente dos criterios
de definición de datos e información. En estos escritos utilizamos ambos criterios, y
en general el sentido de la oración denota muy claramente cual es el sentido en que
se usan las palabras dato e información.
Diccionario de Datos: Un diccionario de datos contiene la descripción de: Archivos,

Registros, Campos, y Vínculos entre archivos. Anteriormente, los Analistas definían
Diccionarios de Datos en Papel, y hacían que los programas, por ejemplo en COBOL
definan siempre los Archivos, Registros y Campos de la misma manera en que estaban
definidos en el Diccionario. Por otra parte, en la definición de Vínculos se definían
las reglas de integridad. Dichas reglas de integridad debían ser implementadas,
muchas veces con bastante dificultad por la lógica de los programas de aplicación.
Actualmente los Diccionarios de Datos son en general Diccionarios Activos, es decir,
que una vez que el analista haya efectuado las definiciones dentro del mismo, estas
definiciones lógicas tienen efecto físico de creación de las estructuras en los medios,
por lo general en disco, también, las definiciones tienen efecto en todo el sistema,
puesto que sin volver a hacerlas en los programas, ya están disponibles dentro de
los mismos para su utilización directa, y por último, y lo que es más importante,
las reglas de integridad son implementadas automáticamente por los motores de
datos, de manera que ellas son respetadas aunque no hayan sido programadas en
los programas de aplicación. Ver Métodos formales de definición y evaluación
de diccionarios de datos en: Análisis Estructurado Moderno – Edward Yourdon –
Editora Campus: Capítulo 10; Análisis Estructurado de Sistemas – Chris Gane y
Trish Sarson – Editorial el Ateneo: Capítulo 4 Construcción y uso de un Diccionario
de Datos, y Capítulo 6, Definir el contenido de los Almacenamientos de Datos.
Diccionario de Datos Corporativo: Es el Diccionario de Datos que se refiere

a todos los datos de la Entidad. Esta modalidad de Diccionario de Datos se ha
impuesto por sobre aquella que se refiere a la de mantener Diccionario de Datos
del Sistema, modalidad que fue utilizada anteriormente, la cual está aún en uso en
algunos lugares.
Encriptar: Es codificar uno de los procedimientos de seguridad de datos más

utilizados es la encriptación, que consiste en transformar los datos a un formato
no reconocible por el usuario que no posea la clave para volver a transformarlos a
un formato legible, desencriptación. En la actualidad es muy frecuente encriptar
archivos para transmitirlos por las redes, pero también se encriptan archivos de datos
de alta confidencialidad, de tal manera que únicamente el usuario autorizado que
posee la clave pueda acceder a su contenido.
Esquema: Documento que define de manera esquemática algo. Definición de alto

nivel, en base a las cuales se efectúan definiciones de menor nivel. Un Esquema
por lo general es la definición estructurada de mayor nivel. Un Esquema define
cuales son los grupos principales componentes del todo, así como sus características
principales. Un Esquema sirve como guía para la Redacción de otros documentos
tales como Planes, Manuales, Metodología, Procedimientos, etc.
Esquema de Clasificación de Datos: Consiste en la definición y agrupamiento de las

diversas Clases de Datos, atendiendo a su nivel de confidencialidad, y describiendo
su tratamiento básico, en materia de seguridad de acceso.
www.ruoti.com.py
El Esquema de Clasificación de Datos es el primer esbozo en el cual se sustenta la

seguridad de datos. Los Propietarios de Datos recurren a él para Clasificar cada
grupo de Datos de su Propiedad, y establecer el Nivel de Seguridad requerido.
Los “Grupos” de datos se definen en cada organización, teniendo en cuenta las
características de los datos que la misma procesa o procesará mediante la TI, así
como las Políticas de la Organización.
Entrada: Se refiere al ingreso de datos al Sistema de TI. La mayoría de los datos

ingresan a través de los teclados, en general directamente desde los documentos tales
como cheques o boletas de depósito, esta es la tendencia actual, sin embargo, en
ocasiones se preparan otros formularios para ingresos de datos. Por otra parte existe
un volumen cada vez mayor de datos ingresados por transacciones electrónicas, tales
como: tarjetas de débito o crédito, débitos o créditos automáticos entre computadores
de proveedores de bienes y servicios y los operadores de tarjetas, así como otros
cargos generados automáticamente por Sistemas de TI.
Gerencia de TI: Es el cargo máximo en la Unidad Funcional de TI. A efectos

de este trabajo, es sinónimo de Gerencia de Sistemas de Información, Jefatura del
Centro de Cómputos, Jefatura del Departamento de Informática, etc.
Gerencia de Procesos de TI: Es un órgano de la Unidad Funcional de TI, se encarga

de hacer que se encuentren disponibles el computador, el software, los equipos
periféricos y equipos de comunicaciones necesarios, para que todos los usuarios
de los mismos puedan ejecutar las actividades de su competencia en el lugar y
momento apropiado. En los documentos presentados por esta Consultoría se usa
como sinónimo de Departamento de Operación, o Departamento de Producción.
Gerente o Gerencia: Se usa aquí en su significado general y amplio. Gerente es el

que administra y dirige la Unidad Funcional, así como Gerencia se puede usar en
sentido de Unidad Funcional.
Grupo de Desarrollo: Personal de la Unidad Funcional de TI, principalmente

Analistas de Sistemas y Programadores, dedicado al desarrollo de Nuevos Sistemas,
o nuevos programas, o modificación de programas y otros componentes de software
de sistemas en producción. En resumen, es el grupo de profesionales de desarrollo
y mantenimiento.
Grupo de Garantía de la Calidad de Servicios de TI: Personal de la Unidad

Funcional de TI cuya función es establecer procedimientos para el logro de la Calidad
en la prestación de Servicios de TI. En general se trata de una unidad funcional
estable dependiente de la Gerencia de TI, sin embargo, en las organizaciones en que
la función de TI es ejercida por una unidad funcional pequeña, el grupo puede ser
un Comité integrado por personal de la Unidad Funcional de TI. Sea cual fuere
su carácter organizativo, sus funciones, atribuciones, y procedimientos deben ser
establecidos por escrito. Tanto la planificación de sus actividades, la ejecución de las
mismas, y los resultados deben ser documentados apropiadamente. Ver: en 10.3.3 el
subtítulo: Aseguramiento de la Calidad, en Auditoría de la Dirección, de Juan Miguel
Ramos Escobosa; y 16.Auditoría de la Calidad, de José Luis Lucero Manresa, en el
Compendio: Auditoría Informática, Un enfoque Práctico, Editorial RA-MA.
Grupo de Operaciones: Personal de la Unidad Funcional de TI dedicado a la

Operación del Computador, Administración del Sistema, etc.
Grupo de Pruebas: Personal de la Unidad Funcional de TI dedicado a ejecutar

pruebas de programas individuales y otros componentes de software, así como de
todo un sistema nuevo o modificado, antes de que el mismo pase a producción. Los
trabajos del Grupo de Pruebas son acompañados activamente por miembros de las
Unidades Funcionales afectadas por los sistemas que se están probando.
Identificación, Autenticación y Acceso: Identificación se refiere a un código único

e inmutable que corresponde a cada usuario de TI. Este código de identificación
se habilita en una cuenta del usuario. Cada organización debe establecer un
procedimiento para asignar “cuentas” a su personal, así como a otros usuarios de sus
sistemas de TI. Autenticación: se refiere al procedimiento que hace que el software
reconozca como tal a cada usuario. El método más simple y más utilizado es la
introducción de una contraseña o “password” por el usuario. Existen otros métodos
más seguros, pero en general más caros y menos utilizados. La elección del método y
procedimientos de autenticación dependen del análisis de riesgos respecto al acceso
al sistema.
Acceso: Se refiere al hecho de que el usuario quede habilitado por el sistema

www.ruoti.com.py
para efectuar cierto tipo de operaciones. Se pueden dar como ejemplo: Acceso a
programas de aplicaciones, acceso al software de programación, acceso al software
de administración de datos, acceso al software de administración del sistema, acceso
de consulta y manipulación de bases de datos, etc.
Incidente de Seguridad: En general, el término Incidente se refiere a hechos

ocurridos que pueden significar intento de irregularidades, o directamente hechos
que se refieren a irregularidades. Incidente de Seguridad es un intento de acceso
a algo a lo cual el usuario no tiene autorización para acceder, o es efectivamente el
acceso a algo a lo cual el usuario no tiene autorización para acceder. En ocasiones, el
Incidente de Seguridad no es una irregularidad, puesto que por error y sin intención, el
usuario podría haber provocado su ocurrencia. Ver 15.4.4 Resolución de Incidentes,
en La Auditoría Técnica de Sistemas, de Julio Novoa Bermejo, en el Compendio
Auditoría Informática, Un enfoque práctico, Editora RA-MA.
Informe de Auditoría: Ver consideraciones en: El Informe de Auditoría de José

de la Peña Sánchez, en el Compendio Auditoría Informática, Un enfoque práctico,
Editora RA-MA.
Integridad referencial: Se refiere a la existencia de datos relacionados en diferentes

archivos. Por ejemplo, en un archivo de movimientos en que cada registro tiene el
código de cliente y el código del producto, se dice que existe integridad referencial
cuando en el archivo de clientes existen todos los clientes cuyo código está grabado
en el archivo de movimientos y en el archivo de productos existen todos los productos
cuyo código está grabado en el archivo de movimientos.
Interfase: Se lo utilizará en el sentido de un programa que se comunica con un

subprograma u otro programa, interfase interna.
Mantenimiento: Mantener es sinónimo de hacer que permanezca actualizado. En

Informática, mantenimiento se refiere principalmente a las modificaciones que se
hacen a los programas para que ellos cumplan con los nuevos requerimientos de
procesamiento.
Middleware: Software de conectividad, integración, e interoperatividad de diversas

plataformas de Sistema Operativo, Programas, Sistemas Gerenciadores de Bases
de Datos, etc. Consta básicamente de programas de Integración de aplicaciones

distribuidas.
Modelo de Datos Corporativo: Modelo es toda representación de la realidad.

Modelo de Datos es la representación de la manera en que están definidos los datos,
y las relaciones entre los mismos. Modelo de Datos Corporativo se refiere al modelo
de todos los datos de la organización. Ver Diccionario de Datos Corporativo.
Monitorear: Es mantener bajo observación. Observar frecuentemente. Verificar

continuamente.
Niveles de Seguridad de Datos: El Esquema de Clasificación de Datos define las

diversas “Clases de Datos”. La organización puede definir una o más clases sin
restricción de acceso, sin embargo, la mayoría de las clases, aunque tenga acceso
irrestricto respecto a la consulta, al menos tiene restricciones respecto a la grabación
o modificación de datos. Por lo general, sólo ciertos usuarios pertenecientes a
una Unidad Funcional, o de cierto Nivel Jerárquico pueden ejecutar cierto tipo
operaciones sobre los datos. Por otra parte, en toda organización existen datos
de extrema confidencialidad, y esto es particularmente crucial en las Entidades
Financieras. Los Propietarios de los Datos definen la “Clase” a la cual pertenecen
sus datos, y en base al tratamiento que corresponde a dicha Clase, determinan y/o
aprueban los Niveles de Seguridad, así como los procedimientos y medidas que se
establecen al respecto, los Custodios de los Datos pueden o no participar de las
definiciones, la responsabilidad de éstos es la implementación de los procedimientos
y medidas para mantener los Niveles de Seguridad por cada grupo de datos cuyo
nivel de confidencialidad requiera acceso restringido.
Nivel de Servicio: Está dado por los valores de una serie de parámetros cuya
medición es capaz de determinar objetivamente el mayor o menor grado de eficacia
de los servicios de TI prestados. Ver: en La Auditoría de Sistemas, de Julio Novoa
Bermejo, 15.3. El Nivel de Servicio, en el compendio Auditoría Informática – Un
Enfoque Práctico, Editora: RA-MA.
Normas de Standarización: La Gerencia de TI debe definir Normas de

Standarización a fin de evitar la incompatibilidad, minimizar costos de desarrollo y
mantenimiento de aplicaciones y hardware, y obtener el mejor rendimiento posible
www.ruoti.com.py
de la capacitación del personal. La standarización se refiere tanto a aspectos tales

como las interfases de las aplicaciones con el usuario, como a la estructura de datos
y sistemas, el software de ofimática, el software de desarrollo, y todo el software
de base en general, así como los equipos computacionales, sus periféricos, los
diversos accesorios y el equipo de comunicación. Las Normas de Standarización
requieren una revisión y actualización continua, en especial las referentes al
software de PC’s. Las definiciones de software de base llegan al nivel de productos
específicos y versiones, las de hardware a las arquitecturas de computadores, buses,
tipo de teclados, canales, tarjetas controladoras, periféricos, etc., y las del software
de aplicación a ejemplos concretos de las interfases, ejemplos de enfoques en la
estructura de datos y sistemas, etc. Estas normas deben respetar las definiciones del
Plan de Infraestructura Tecnológica.
OLAP: OnLine Analytical Processing: Software de base de datos multidimensional.

Provee facilidades múltiples para la ejecución de procesos de análisis retrospectivos
con distribución dinámica de datos en niveles múltiples. Utilizado principalmente
como soporte en la toma de decisiones. Probablemente la mejor herramienta actual
para la dar respuesta a la pregunta: “¿Qué es lo que ocurre?, o ¿Qué es lo que
ocurrió?”.
Oportuno: Realizado en el tiempo justo, en el momento preciso. Que no tiene

retrasos. Que respeta el cronograma.
Plan Estratégico de TI: Los cuerpos colegiados más destacados a nivel mundial,
que emiten directrices respecto al Control Interno en actividades de TI, establecen
que el Plan Estratégico de TI se refiere a las previsiones de la utilización de las
tecnologías de la información en la empresa, los cuales dependen de la Misión,
Objetivos y Planes Estratégicos de la propia empresa. Según el período que abarca,
el Plan Estratégico de TI puede dividirse en: Planes de TI a corto y largo plazo. Ver:
10.2.1 Plan Estratégico de Sistemas de Información, en Auditoría de la Dirección, de
Juan Miguel Ramos Escobosa, en el Compendio: Auditoría Informática, Un enfoque
Práctico, Editorial RA-MA; y Capítulo 18: Plan Estratégico de TI, en Introducción al
Análisis y Diseño de Sistemas de I.T.Hawryszkiewycz, Editorial Anaya.
Plan de Infraestructura Tecnológica: Los Planes de TI a corto y largo plazo se

refieren entre otras cuestiones a las estrategias empresariales respecto a:
La arquitectura de sistemas: Que se refiere al tipo de Sistemas que utilizará

la empresa, la manera en que se inter relacionarán los sistemas, el grado de
automatización al cual pretende llegar la empresa, el alcance de cada uno de los
sistemas, y aspectos similares.
La dirección tecnológica: Consiste en la elección de alguna línea de hardware

y software de base. En general lo habitual es que se decida la ejecución de cierto
tipo de aplicaciones utilizando una línea de hardware y software, y otra en otro
tipo de aplicaciones. Los tipos de aplicaciones pueden ser por ejemplo: Sistemas
Corporativos, Sistemas de Análisis de Datos, Sistemas de Toma de Decisiones,
Ofimática, Editoración Electrónica, Inteligencia Artificial, etc.
Las estrategias de migración: La constante evolución tecnológica exige cada vez

más frecuentes procesos de migración desde las plataformas anteriores a las nuevas.
Las estrategias de migración se refieren a la determinación de que sistemas serán
migrados, hacia qué tipos de plataforma, en qué momento, y de qué manera.
El Plan de Infraestructura Tecnológica se refiere principalmente a un mayor grado

de detalle en la definición de estos tres aspectos. Mientras los Planes de TI a corto y
largo plazo se refieren a la tecnología de manera conceptual, el Plan de Infraestructura
Tecnológica se refiere a la misma de manera más precisa, y puede llegar a especificar
fabricantes, marcas, y normas específicas.
El Plan de Infraestructura Tecnológica debe contemplar siempre aspectos de

contingencia tales como:
Redundancia: Las aplicaciones críticas que requieren niveles de servicio que no

aceptan interrupciones, como varias de las aplicaciones del sistema financiero,
requieren de la previsión de situaciones de contingencia tales como la falla del
procesador central, la falla del disco donde reside el sistema operativo, falla de
memoria central, etc., las cuales tienen soluciones tecnológicas con la introducción
de hardware redundante, tolerable a fallas y el software apropiado.
Flexibilidad: Se refiere a la posibilidad de utilizar equipos y componentes diversos

de diversas maneras, a fin de solucionar situaciones de contingencia con la aplicación
de ellos en los requerimientos prioritarios, en substitución de aquellos que hayan
www.ruoti.com.py
quedado fuera de servicio, a fin de cumplir con los niveles de servicio establecidos.
Adecuación: Las situaciones contingentes pueden afectar de diversas maneras al

software y hardware, por tanto deberían preverse diversas maneras en que se podrían
adecuar los procesos en caso de que cualquiera de dichas situaciones se presente. Por
ejemplo, en caso de que sea imposible procesar los datos con el equipo computacional
de la empresa, debería ser posible efectuar las adecuaciones necesarias en un tiempo
mínimo para que puedan ser procesados en otros equipos, de empresas con las cuales
se tenga un convenio vigente.
Adaptabilidad evolutiva del Plan: El Plan de Contingencia que forma parte del Plan
de Infraestructura Tecnológica debe estar en constante revisión y evolución, puesto
que ello llevará a soluciones de mayor calidad, es decir que permitan sobrellevar de
mejor manera las situaciones de contingencia, lo cual posibilita mejores niveles de
servicio en estos casos, y en consecuencia acarrea costos menores.
Plan General de Continuidad de Servicios de la Entidad: Como requisito del

Control Interno de la Entidad, la misma debe contar con un Plan General de Continuidad
de Servicios, en el cual se definan los procedimientos a seguir en caso de imprevistos
o desastres a fin de garantizar la continuidad de los Servicios, o minimizar el plazo
que le llevará a la Entidad restituir sus servicios. Este Plan se refiere absolutamente
a todos los recursos de la Entidad, desde el personal, hasta la infraestructura física,
y desde los equipos tecnológicos, hasta los materiales necesarios.
Planes de la Entidad a Corto y Largo Plazo: Se refiere a los Planes Estratégicos

de la Entidad como un todo, puesto que por el período de tiempo que abarcan, los
Planes Estratégicos de TI, habitualmente se denominan como Plan a Corto Plazo o
Plan a Largo Plazo.
Proceso fundamental: Proceso ejecutado con TI, de importancia vital para

el desenvolvimiento de las operaciones del día a día de la Entidad. Ej.: Cuentas
Corrientes bancarias, Ahorros en bancos, financieras y cooperativas, Reservas de
Pasajes de aerolíneas, etc.
Proactivo: Palabra muy utilizada actualmente en Administración. En general no

aparece en los diccionarios. Utilizada por primera vez por Víctor Frankl, psicólogo
freudiano y popularizada por Stephen Covey. Una conducta Reactiva: se refiere

a aquella que acontece en respuesta a un estímulo, mientras que Proactiva es la
conducta de quien se adelanta a los hechos, previendo su aparición y estableciendo
medidas para evitar los impactos indeseados, y/o para aprovechar las oportunidades
que se presentarán en las situaciones por venir.
Procedimientos de Privacidad de Datos y Flujo de Datos: Los procedimientos de

Privacidad de Datos se refieren a todos los procedimientos referentes a la creación,
modificación, manipulación y almacenamiento de datos confidenciales, según el
Nivel de Seguridad que haya sido definido. Involucra tanto a la fuente de datos,
como a los soportes de datos y las salidas. Los procedimientos de Flujo de Datos
se refieren al transporte de datos de un medio computacional a otro, o de un medio
computacional a un depósito de almacenamiento de respaldo, por medio de soportes
o cualquier tipo de transmisión por cables u ondas electromagnéticas.
Promoción: Ascenso de cargo. El hecho de que un empleado vaya a un cargo

superior se llama promoción.
Proyecto: Un proyecto TI puede ser:
Un Proyecto de Desarrollo, que incluye:
- La Identificación de una necesidad del usuario que puede ser satisfecha

mediante la TI
- El Relevamiento de necesidades
- El Estudio de factibilidad
- El Diseño
- El Desarrollo
- La Implantación
- Un Proyecto de Modificación que incluye los mismos pasos que se refieren
a un Proyecto de Desarrollo
- Un Proyecto de adquisición de un Paquete de Software
- Un Proyecto a ser Desarrollado por terceros
Un proyecto puede referirse a software, a hardware computacional y de

www.ruoti.com.py
comunicaciones, al entrenamiento de las personas, así como a cualquier combinación,

y por lo general a la inclusión de estos tres ítems.
Cuando el manual se refiere a “un Proyecto”, se entiende que se incluyen proyectos de

Desarrollo, Implantación o Modificación. En general Proyecto en estos documentos
es sinónimo de Proyecto Informático
Respaldo: Back-up copia de archivos de datos o de software igual a aquella que será
o está siendo utilizada. Los Respaldos se almacenan en Medios de Almacenamiento
en la Biblioteca y/o otros lugares a fin de utilizarlos para restaurar la funcionalidad
en caso de pérdida parcial o total que torne no operativos a los datos o software en
el ambiente de producción.
Salida: Todo dato o información producidos por la TI puede ser llamado Salida. Las
Salidas pueden estar impresas en papel, grabadas en medios magnéticos, ópticos, o
diversos otros medios.
Sistemas críticos: Aquellos sistemas de cuyo funcionamiento depende el giro del

negocio.
Software de Aplicación: Se refiere a los programas o sistemas mediante los cuales

los usuarios ejecutan sus actividades laborales propias de la Entidad. Ej.: Son
aplicaciones: Préstamos, Contabilidad, Sueldos, Cuenta Corriente, etc.
Software de Base: Es el conjunto de programas que sirven para hacer que el

computador funcione. Esta constituido generalmente por una serie de programas
tales como: El Sistema Operativo, los utilitarios, los compiladores, software de
comunicación, software de interfase con periféricos, etc. En ocasiones incluye
software de seguridad y software de acceso a datos.
Transacción: Conjunto de instrucciones que ejecutan operaciones sobre datos

almacenados. Una transacción puede consistir en un programa o una unidad de
software cualquiera, así como varias unidades de software.
Tratamiento y Retención de Salidas: Las leyes y normas vigentes, así como las
prácticas habituales de la Entidad pueden requerir la Retención, almacenamiento
en archivo de las Salidas por un período específico. Por otra parte, deben existir
procedimientos que indiquen el tratamiento que se debe dar a cada Salida, puesto
que las mismas no tan sólo podrían ser confidenciales implicando su divulgación
perjuicios para la Entidad o para Terceros, sino que ello podría violar leyes y normas
vigentes. Especial cuidado requieren las Salidas que comportan en sí mismas valores,
tales como las tarjetas de crédito o débito.
Unidad Funcional de Servicios de TI: Es el órgano de la Entidad, cuya

responsabilidad es la planificación, ejecución y monitoreo de los Servicios de
Tecnología de Información en la empresa. A efectos de este trabajo, es sinónimo
de Departamento de Computación, Departamento de Informática, Departamento de
Servicios de TI, Unidad Funcional de Servicios de TI, etc. La Unidad Funcional de
TI debe estar ubicada suficientemente alto en la jerarquía para disponer de autoridad
e independencia frente a las unidades funcionales usuarias. Ver: 10.3. Posición del
Departamento de Informática en la Empresa, en Auditoría de la Dirección, de Juan
Miguel Ramos Escobosa, en el Compendio: Auditoría Informática, Un enfoque
Práctico, Editorial RA-MA.
Volúmenes: Un volumen es una Unidad física de Almacenamiento de datos

y/o programas. Tradicionalmente los volúmenes son magnéticos, sin embargo,
actualmente es cada vez mayor la aparición de volúmenes de almacenamiento
óptico o magneto óptico. Ej.: son volúmenes: un carrete de cinta magnética, un
disco magnético, de uno o más platos, un diskette, un disco JAZ, un Compact Disc.
Volúmenes es sinónimo de Medios de Almacenamiento.

www.ruoti.com.py
Capítulo X
1. Disposiciones de la SET con relación al uso de sistemas infor-

máticos para efectos contables. Matriz de verificación para
el Auditor Informático.
1.1. Resolución Nº 412/04. Por la cual se adecuan a la legislación vigente las

disposiciones reglamentarias de registración contable y de su empleo por
medios computacionales.
Asunción, 1 de octubre de 2004.
Visto: Los Artículos 186, 189 (texto actualizado) y 192 de la Ley N° 125/91”Que
establece el Nuevo Régimen Tributario”; y del Titulo III de la Ley Nº 1034/83 “Del
Comerciante”,y las Resoluciones N° 33/92 y 168/92; y
Cosiderando: Que es necesario adecuar los reglamentos referidos a la Registración

Contable, unificarlos en un solo cuerpo, con el fin de facilitar su comprensión y
tratamiento por parte de los contribuyentes.
Que la Administración Tributaria dispone de la facultad de fijar normas generales

y dictar los actos necesarios para la fiscalización de los tributos y en este orden
cuenta con la prerrogativa suficiente a los efectos de exigir que los contribuyentes
lleven libros especiales o adicionales de sus operaciones.
Que la utilización del Libro Mayor facilitará la tarea del control y verificación
del cumplimiento de la obligación tributaria, resultando una medida conveniente
para que la Administración cumpla con mayor eficiencia y celeridad su función
fiscalizadora.
Que los constantes avances observados en el sector informático hace necesario

adecuar la normativa vigente sobre esta materia, enfocado principalmente a su
optimización y con este propósito resulta conveniente establecer las obligaciones

formales que los contribuyentes deben cumplir a fin de proceder a la registración

contable por medio de sistemas computacionales.
Que independientemente del sistema adoptado por el contribuyente, la legislación

comercial invocada, dispone con extrema precisión que la contabilidad se deberá
llevar mediante contador matriculado, siendo ambos responsables solidariamente de
que en los asientos se registren con fidelidad los documentos y constancias en cuya
base hayan sido extendidas, y que el método de contabilidad a ser utilizado es de
partida doble, para cuyo efecto se reflejarán las operaciones tanto en los libros como
en las hojas previamente rubricadas.
Que la experiencia recogida, en concordancia con los avances ya señalados,

demuestran la existencia en el mercado de varios programas elaborados para
tales efectos, cuyo uso están a cargo del profesional contable, quien en función
a su formación es la persona que debe determinar, si el mismo cumple con los
requisitos que tanto la ciencia contable como las disposiciones legales exijan.
Que, igualmente, el profesional técnico proveedor del programa es la persona que

debe conocer profusamente sus características y por ende es quien debe certificar la
inalterabilidad de los datos procesados y que todo error y posterior corrección de los
datos queden registrados en su historial.
Que el ordenamiento tributario nacional se encuentra en un período de transición,

motivo por el cual es preciso que los contribuyentes vayan adecuando sus registros
y sistemas ajustándolos con la debida anticipación
Por Tanto, el Viceministro de Tributación Resuelve:
Artículo 1º.- De los libros contables y su registración. Los contribuyentes deberán

llevar sus anotaciones contables de conformidad con las disposiciones legales y
reglamentarias que rigen la materia, y a los principios de contabilidad generalmente
aceptados.
Artículo 2°.- Libros contables. Los contribuyentes deban llevar registraciones

contables de conformidad con el artículo 74 de la Ley Nº 1034/83 y aquellos que
de acuerdo a las obligaciones tributarias a que estén afectados deban registrar,
igualmente, sus operaciones acorde con dicha normativa, además de los libros
obligatorios - Diario e Inventario - deberán contar y registrar sus operaciones en los

www.ruoti.com.py
libros contables que se detallan a continuación, sin perjuicio de los libros que por
disposiciones especiales estén obligados a llevar:
• Libro Mayor,
• Libros de Ventas y de Compras.
Artículo 3°.- Contabilidades Analíticas. En caso de contabilidades analíticas o
libros auxiliares (tales como: caja, compras, ventas y otros), podrán efectuarse en el
libro diario asientos sintéticos comprensivos de operaciones realizadas en períodos
de tiempo no mayores de un mes. Para ello será necesario que en los libros auxiliares
se asienten en forma detallada, las operaciones diarias, según el orden en que se
hubieran efectuado, de acuerdo con los principios aceptados en la técnica contable,
considerándose parte integrante del Diario, debiendo el libro auxiliar optado ser
rubricado previamente por el Registro Público de Comercio.
En ningún caso se acordará valor probatorio para el contribuyente a las anotaciones

efectuadas en planillas, hojas sueltas o similares y el mismo surgirá solamente de
su incorporación a los libros rubricados, salvo en el caso en que la contabilidad
sea por sistemas computarizados.
Artículo 4°.- Comprobantes de Contabilidad. Todas las operaciones contables

deberán estar respaldadas por sus respectivos comprobantes y solamente de la fe que
estos merecieran resultará el valor probatorio de aquellas.
Los comprobantes de contabilidad, las planillas y las cintas registradoras se deberán

mantener debidamente ordenados y conservarse a los fines de su fiscalización por el
término de prescripción.
Artículo 5°.- Libro Mayor. En el Libro Mayor se registrarán en forma clasificada y

sistemática los hechos contables ya registrados en el Diario, por orden cronológico,
de tal manera que se conozca el movimiento y saldo de cada una de las cuentas.
El Libro Mayor debe estar numerado en todas sus hojas, las cuales deberán estar
rubricadas o selladas, antes de su utilización, por el Registro Público de Comercio,
de conformidad a lo dispuesto en el artículo 78 de la Ley 1034/83.
Artículo 6°.- Libros de ventas y de compras. Los Contribuyentes que deban llevar
registros contables, de acuerdo a lo establecido en los Artículos 1º y 2º de esta

reglamentación y todos aquellos que realizan operaciones gravadas por el Impuesto

al Valor Agregado, deberán llevar libros de ventas y de compras en los que se anotarán
las transacciones realizadas.
También se podrá exigir otros registros especiales que permitan controlar el
movimiento de las operaciones gravadas, de las exentas y las de exportación.
También deberán llevar en sus registros contables, una cuenta especialmente

identificada que se nominará “Impuesto al Valor Agregado”, en la que se
acreditará el impuesto generado en cada operación gravada y se debitará el monto
del impuesto incluido en los comprobantes de compra de bienes y servicios.
En la misma, también se reflejarán los restantes actos que la afecten.

La mencionada cuenta no integrará los rubros de pérdidas ni de ganancias del estado
de resultados a los efectos del Impuesto a la Renta.
Los contribuyentes deberán discriminar en sus registros contables de caja, ventas,

compras y diario, las operaciones gravadas, exoneradas y de exportación, así como
las que eventualmente se realicen fuera del ámbito jurisdiccional del impuesto. El
IVA correspondiente a las operaciones gravadas deberá estar registrado en forma
separada, en la cuenta que llevará su misma denominación.
Artículo 7°.- Libro Inventario. Cuando en el Libro Inventario se consigna en forma

sintética los distintos rubros que integran el inventario y cuyo detalle figure en otros
registros, se consideran estos parte integrante de aquel y revestirá el carácter de
obligatorio.
Del empleo de medios computarizados para la registración contable.
Modificado por RG Nº 23/09. Artículo 8°.- Contabilidad Computarizada. Será

admitido contabilizar las operaciones en registros elaborados a base de sistemas
computarizados, siempre que el programa respectivo permita obtener los datos que
la Administración requiere para el cumplimiento de sus fines.
La Administración tendrá la facultad para acceder directamente a los programas y
a los datos de contabilidad a los efectos de la fiscalización de los impuestos que
administra.
El contribuyente que desee utilizar un sistema computarizado para el registro de sus

www.ruoti.com.py
operaciones contables deberá comunicar a la Administración, acompañado de los

datos y requisitos que se mencionan en la presente resolución.
Derogado por RG Nº 23/09. Artículo 9°.- Formulario de Comunicación.

Los contribuyentes que opten por emplear medios computacionales para llevar
registrada su contabilidad, comunicarán a la Administración, por medio del
formulario cuyo modelo y contenido consta en el anexo de la presente disposición
y forma parte de la misma.
El formulario deberá ir acompañado de los siguientes recaudos
• Fotocopia del RUC del contribuyente.

• Fotocopia de la Cédula de identidad de firmante, y
• Fotocopias autenticadas de los informes del contador y proveedor del software,
según lo previsto en el artículo siguiente,
En los casos de actualización de los sistemas utilizados, adjuntar copia de la

autorización emitida por la Administración.
Reglamentado por Resolución Nº 535/04, Artículo 10°.- Formulario de

Comunicación. El uso de medios computacionales deberá ser avalado por un Contador
Público, certificando que el programa a ser utilizado cumple con las exigencias de la
legislación vigente y con los Principios de Contabilidad Generalmente Aceptados.
Asimismo, deberá contar con el informe técnico de la empresa o profesional

proveedor del programa que garantice la inalterabilidad de la información
procesada en el sistema y que toda modificación debe quedar registrado en el
historial.
El contribuyente deberá conservar la documentación completa del software de

aplicación (en extenso) y la certificación del Contador Público. Asimismo, deberá
conservar en la empresa como parte integrante de su archivo tributario, las siguientes
informaciones:

1.- Plan de Cuentas: Este deberá considerar cuentas o sub cuentas representa-
tivas de las obligaciones tributarias que le afecte, tales como: IVA, Impuesto
a la Renta, Retenciones (IVA, Renta, Ganado); Impuestos Varios (Selectivo
al Consumo, Actos y Documentos, Inmobiliario, otros);
2.- Diagrama de flujo de datos (DFD):
3.- Diagrama de Entidad - Relación (DER):
4.- Diccionario de datos del sistema contable, con la siguiente información:
a) La Información general de la base de datos.
b) Las definiciones de todos los esquemas en la BD (tablas, índices, vistas,
clusters, sinónimos, secuencias, procedimientos, funciones, paquetes,
tiggers, etc).
c) El nombre del sistema, si lo posee.
5.- Descrípción de las medidas de seguridad para resguardo de la información;
6.- Rutina del proceso para recuperar el sistema en caso de falla de energía, o
problemas técnicos y otros accidentes que impidan el normal funcionamiento
del equipo;
Derogado por RG Nº 23/09. Artículo 11°.- Constancia. Las Reparticiones

señaladas en el artículo 13 siguiente, expedirán una constancia de recepción de
la comunicación formulada por el contribuyente, de haber optado por realizar sus
registros contables por medios computacionales, o su actualización en su caso,
identificado en el mismo al contador y al profesional o empresa proveedora del
sistema.
Artículo 12°.- Uniformidad Contable. La registración en los libros Diario,

Inventario, Mayor y los auxiliares utilizados conforme al artículo 3 de esta Resolución,
es indivisible, por lo que deben ser llevados simultáneamente y mediante la misma
modalidad (registración manual o computacional), de igual modo que el de ventas y
compras, si se llevan separados.
El resto de los libros auxiliares pueden ser llevados mediante el mecanismo que el
contribuyente estime conveniente.

www.ruoti.com.py
Modificado por RG 23/09. Artículo 13°.- Reparticiones Responsables. Serán

competentes para la recepción de las comunicaciones y la expedición de los
Certificados, las Direcciones Generales de Fiscalización Tributaria y de Grandes
Contribuyentes.
Artículo 14°.- Vigencia. Esta Resolución entrara a regir desde el día siguiente a su
publicación en dos diarios de circulación nacional, de acuerdo a lo que dispone el
articulo 188 (texto actualizado) de la Ley N° 125/91, con excepción de lo relativo a
la obligatoriedad de contar con el Libro Mayor que deberá ser aplicado a partir del
1° de enero de 2005.
Artículo 15°.- Transitorio. Hasta tanto se ponga a disposición de los contribuyentes el

formulario de comunicación mencionado en el artículo 8, los mismos, deberán adecuar
sus comunicaciones en hojas comunes con el formato y contenido aprobado.
Artículo 16°.- Derogaciones. Derogase los artículos 13°, 17° y 18° de la Resolución
N° 33/92 y la Resolución N° 168/92.
Artículo 17°.- Publíquese, comuníquese a quienes corresponda y cumplido,

archívese.
1.2. Resolución Nº 535/04. Por la cual se aclara disposiciones contenidas en la

Resolución nº 412/04 “Por la cual se adecuan a la legislación vigente las
disposiciones reglamentarias de registración contable y de su empleo por
medios computacionales”.
Asunción, 2 de diciembre de 2004.

Visto: La Resolución Nº 412 del 1 de octubre de 2004 “Por la cual se adecuan a la
legislación vigente las disposiciones reglamentarias de registración contable y
de su empleo por medios computacionales”; y
Considerando: Que es necesario aclarar debidamente algunas disposiciones

reglamentarias relativas al empleo del Libro de Compra – Venta IVA, como así
también, de la utilización de medios computacionales para la registración contable,
a los efectos de favorecer el buen cumplimiento de los reglamentos dictados por esta
Administración Tributaria.

Que, teniendo en cuenta el numero considerable de contribuyentes obligados a

contar con el Libro Mayor y que la obligatoriedad de su registración es a partir
del 1º de Enero de 2005, hace necesario conceder una dispensa legal en materia
de aplicación de sanciones en caso de atraso de su registración, con el objeto
de favorecer una correcta y ordenada implementación; sin perjuicio que en este
libro se registren sus operaciones a partir de la fecha señalada precedentemente,
independientemente a la fecha de su lubricación.
Por Tanto, El Viceministro de Tributación, Resuelve:
Art. 1º.- Del Libro Mayor: Dispónganse que los contribuyentes no serán pasibles de
sanciones por atraso en la registraciones en su Libro Mayor durante todo el ejercicio
fiscal 2005.
Art. 2º.- Libro Compra – Venta iva: La rubricación por parte del Registro Publico
de Comercio, del Libro Compra – Venta IVA es obligaciones para el contribuyente
que opte por registrar sus operaciones en el Libro Diario a través del método sintético
y el libro referencia sea utilizado como auxiliar del Diario.
La rubricación del mencionado libro, igualmente, no es obligatoria para el

contribuyente que esté alcanzando solo por el Impuesto al Valor Agregado, - por la
prestación de servicio de carácter personal.
Art. 3º.- De los Informes Técnicos: Aclarar el alcance de los informes técnicos
estipulados en el artículo 10º de la Resolución Nº 412/04:
a) Aval del Contador Publico o Licenciado en Contabilidad: El informe

Técnico se refiere al hecho de que el sistema computacional a ser utilizado por
el contribuyente, cumpla con los requerimientos dispuestos en la legislación
vigente – Leyes y Reglamentos – concernientes con la registración contable
y a los Principios de Contabilidad Generalmente Aceptados.
b) Inalterabilidad de la Información Procesal: La inalterabilidad de la

información procesada por medios computacionales hace referencia al hecho
de que el sistema debe prever que las modificaciones o correcciones por errores
en el procesamiento de la información contable se realicen exclusivamente
por medios de contrasientos.

www.ruoti.com.py
Art. 4º.- De la Guarda de la Información: La guarda y conservación de las

informaciones señaladas en los puntos 2), 3), 4) inc. a) y b) del artículo 10º de la
Resolución Nº 412/2004, estará a cargo de la empresa proveedora del software,
quien podrá ser citada por la Administración Tributaria para contestar o informar
acerca de las preguntas o requerimientos que se les formulen, levantándose el acta
correspondiente, quedando sin efecto la disposición anterior.
Derogado por RG Nº 23/09. Art. 5º.- Formularios de Comunicación: El

formulario de comunicación de utilización de medios computacionales para la
registración contable o su actualización estará disponible en la PAGINA WEB de esta
Subsecretaria de Estado (www.hacienda.gov.py/sset); autorizándose a la Dirección
de Apoyo a realizar las modificaciones necesarias para adecuar el formulario
aprobado por la Resolución Nº 412/04, ajustándolo a las aclaraciones señaladas en
la presente disposición y dejar sin efecto lo preceptuado en artículo 15º de la citada
reglamentación.
Art. 6º.- Prórroga: Disponer que la vigencia del articulo 12º de la Resolución Nº
412/04 sea obligatoria a partir del 1º de Enero de 2006.
Art.. 7º.- Publíquese, comuníquese a quienes corresponda y cumplido archívese.
1.3. Resolución General Nº 23/09. Parte pertinente a la utilización de medios

computacionales para la registración contable.
Asunción, 10 de Noviembre de 2009

Visto: Los Artículos 78º y 194º de la Ley Nº 125/91 “Que establece el nuevo
Régimen Tributario” y sus modificaciones; el Decreto Nº 6539/05, la Resolución
Nº 412/04, la Resolución Nº 535/04, la Resolución General Nº 15/07 y la Resolución
General Nº 8/08; y,
Considerando: Que, es necesario aclarar cuestiones relativas a la obligatoriedad

para la obtención del Certificado de Cumplimiento Tributario para determinados
actos.

Que, la correcta registración de la información contable merece especial atenciones
tributarias por parte de los contribuyentes.
Que los constantes avances observados en el sector informático hacen necesario

adecuar la normativa vigente sobre esta materia, enfocado principalmente a su
optimización y con este propósito resuelta conveniente establecer las obligaciones
formales que los contribuyente deben cumplir a fin de proceder a la registración
contable por medio de sistemas computacionales.
Por Tanto, El Viceministro de Tributación, Resuelve:
De la utilización de medios computacionales para la Registración Contable
Art. 2º.- Modifíquense los Artículos 8º y 13º de la Resolución Nº 412 del 1 de octubre
de 2004, los cuales quedan redactados de la siguiente forma (texto inserto en la RG
Nº 412/04).
Art. 3º.- Se aclara que la utilización de medios computacionales para la registración

contable, no implica la eximición de la impresión en papel – previa y debidamente
rubricados por el Registro Público de Comercio - de loso libros contables
obligatorios.
Art. 10º.- Deróganse los Artículos 9º y 11º de la Resolución Nº 412 del 1 de octubre
de 2004 y el Art. 5º de la Resolución Nº 535 del 2 de Diciembre de 2004.
Art. 11º.- Publíquese, comuníquese a quienes corresponda y cumplido archívese.
1.4. Cuestionario para verificación del cumplimiento de la RG Nº 412/04.
Programa de Auditoría de Evaluación de Ti
Entidad:
Ref.
P.T.:
Período:

www.ruoti.com.py
Resolución Nº 412/04 – SET (Subsecretaría de Estado de Tributación)

Objetivo de control:
El propósito de este formulario es evaluar el grado de cumplimiento de la
resolución 412/04 “Del Empleo de medios computarizados para la Registración
Contable”.
Relevamiento Riesgo
R Nci
(Describa 3=Alto
E Indicadores de Evaluación √-
la situación 2=Medio
F N/A
observada) 1=Bajo
1 – Informe Técnico
1.1 Certificando del contador de que
el programa a ser utilizado cumple
con las exigencias de la legislación
vigente y con los Principios
de Contabilidad Generalmente
Aceptados.
1.2 Informe técnico de la empresa o
profesional proveedor del programa
que garantice la inalterabilidad de la
información procesada en el sistema
y que toda modificación debe quedar
registrada en el historial.
2 – Informaciones disponibles referente a la resolución
2.1 Plan de Cuentas. Este deberá
considerar cuentas o sub cuentas
representativas de las obligaciones
tributarias que le afecten, tales
como: IVA, Impuesto a la Renta,
Retenciones (IVA, Renta, Ganado);
Impuestos Varios (Selectivo al
Consumo, Actos y Documentos,
Inmobiliario, otros).

2.2 Diagrama de flujo de datos (DFD) del

Sistema Contable.
2.3 Diagrama de Entidad – Relación
(DER) del Sistema contable.
3 – Diccionario de Datos del Sistema Contable
3.1 La información general de la base de
datos.
3.2 Las definiciones de todos los
esquemas en la BD (tablas,
índices, vistas, clusters, sinónimos,
secuencias, procedimientos,
funciones, paquetes, triggers, etc).
3.3 El nombre del sistema.
4 – Medidas de seguridad
4.1 Descripción de las medidas de
seguridad para resguardo de la
información.
4.2 Rutina del proceso para recuperar
el sistema en caso de falla de
energía, o problemas técnicos y otros
accidentes que impidan el normal
funcionamiento del equipo.

www.ruoti.com.py


www.ruoti.com.py


www.ruoti.com.py

Meycor Cobit Suite

“Software especializado para implantar COBIT”
Meycor COBIT CSA. • Generar reportes de resultados de la evaluación

El software Meycor COBIT CSA es una herramienta y recomendaciones.
de autoevaluación que posibilita la participación de la • Generar gráficas con los resultados de la
auditoría. Meycor COBIT CSA le permite diagnosticar evaluación.
el estado de su organización respecto al nivel de • Comparar las evaluaciones de los procesos de
seguridad, calidad, eficacia y eficiencia en Tecnología COBIT para los centros de análisis.
de la Información (TI) de acuerdo al marco Mundial
COBIT . Permite en general integrar múltiples • Realizar evaluaciones fuera de línea y luego
cuestionarios de normas y marcos de mejores prácticas consolidarlas en la base de datos.
constituyéndose en una herramienta de evaluación de • Adaptar los riesgos tecnológicos.
la conformidad. • Evaluar los riesgos tecnológicos.
Este módulo incluye también los riesgos asociados • Generar reporte con los resultados de la
a cada objetivo de control de COBIT 4.1 y permite evaluación de riesgos.
realizar evaluaciones de riesgos de TI en cumplimiento • Obtener el mapa de riesgos.
con el informe COSO.
• Asignar auditores a las preguntas.
Permite: • Auditar en forma independiente las evaluaciones
realizadas.
• Crear usuarios y asignarlos a procesos de • Ingresar las tareas de auditorías y generar
COBIT. Trabajar simultáneamente con varios informes con totales de horas.
centros de análisis cuyos resultados pueden ser
obtenidos de forma consolidada o individual. • Comparar el resultado de la autoevaluación con
la conclusión de auditoría.
• Definir los procesos a evaluar en cada centro
de análisis. • Crear planes de acción y asignar
recomendaciones a los mismos.
• Priorizar los procesos según las respuestas a
las planillas de apoyo incluidas. • Priorizar los proyectos mediante el impacto y la
relación costo/riesgo.
• Medir el grado de cumplimiento actual con la
Gobernabilidad en TI • Realizar evaluaciones de controles y riesgos en
diferentes períodos y comparar los resultados.
• Ingresar restricciones inherentes al estado de
los recursos de TI de COBIT.
Meycor COBIT MG
• Adaptar los cuestionarios de autoevaluación
de controles a distintas normas. Realizar la El software Meycor COBIT MG permite definir los logros
autoevaluación de controles. gerenciales de una organización de acuerdo al modelo
de madurez de las guías de gerenciamiento de COBIT
• Agregar nuevos dominios, procesos, objetivos, 4.1. Esta herramienta le permite realizar un diagnóstico
clasificaciones, preguntas, recomendaciones y de la situación actual de madurez para cada proceso
• procedimientos de auditoría. de COBIT, así como generar recomendaciones e
• Generar cuestionarios para responder y cargar implementar proyectos de mejora.
las respuestas Prof.
directamente al software.
Jorge Antonio Fernández F. -Permite
Auditor determinar
de Sistemasen forma rápida y efectiva
de Información la
191
www.ruoti.com.py
relación entre las metas del negocio, las metas de TI y Se incluyen las guías de auditoría de COBIT 3 y las
los correspondientes procesos de COBIT 4.1. guías de aseguramiento de COBIT 4.1.
Posibilita además realizar una evaluación del Permite:
desempeño de las actividades de cada proceso según
el RACI chart de COBIT 4.1. • Administrar plantillas con procedimientos de
Permite: auditoría.
• Crear proyectos de auditoría de 4 tipos
• Definir procesos para cada Centro de Análisis y diferentes: Auditoría de los Procesos de TI,
asignar permisos de acceso de usuarios a los Auditoría de Actividades/Tareas, Revisión de
mismos. Objetivos de Control de Alto Nivel y Revisión de
• Definir el nivel de maduración y establecer el Objetivos de Control Detallados; y seleccionar
objetivo de cada proceso con la ayuda de un entre 3 escalas de evaluación.
cuestionario. • Crear proyectos de auditoría según las
• Realizar una evaluación del cumplimiento de las evaluaciones realizadas en los módulos Meycor
distintas actividades de los procesos. COBIT CSA y Meycor COBIT MG.
• Obtener automáticamente recomendaciones de • Asignar centros de análisis, auditores, procesos,
mejora. objetivos y procedimientos de auditoría a cada
proyecto.
• Generar cuestionarios y cargar las respuestas
automáticamente en el software. • Definir permisos para usuarios en proyectos.
• Generar informes de resultados de la evaluación • Realizar evaluaciones para cada centro
y recomendaciones. de análisis de un proyecto y comparar las
evaluaciones de cada centro.
• Generar gráficas con los resultados de la
evaluación. • Ingresar observaciones y recomendaciones,
vincular archivos y registrar tareas de auditoría.
• Crear planes de acción y asignar
recomendaciones a los mismos. • Supervisar el trabajo de los auditores.
• Priorizar los proyectos mediante el impacto y la • Controlar la distribución de auditores y el avance
relación costo/riesgo. de los proyectos.
• Evaluar diferentes centros de análisis y comparar • Realizar una planificación de auditorías.
los resultados. • Generar el informe final de forma automática e
• Realizar evaluaciones fuera de línea y luego informes con resultados de las evaluaciones.
cargar estos datos en la base de datos. • Realizar el seguimiento de las
• Realizar evaluaciones en diferentes períodos y recomendaciones.
comparar los resultados. • Realizar evaluaciones en diferentes centros
de análisis y realizar comparaciones de los
mismos.
Meycor COBIT AG
• Realizar evaluaciones e ingresar datos fuera de
El software Meycor COBIT AG permite crear y
gestionar proyectos de auditoría de TI basado en línea y luego consolidarlos en la base de datos.
las Guías de Auditoría de COBIT. La estructura del
producto permite, para cada proyecto, definir los Sys&Con
objetivos de COBIT que serán evaluados, los centros Telefono: 225 222 R.A
que serán auditados, los procedimientos usados y los info@syscon.com.py - www.syscon.com.py
auditores asignados a cada objetivo.

www.ruoti.com.py


Clases de Auditoria Informatica FINAL

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Clases de Auditoria Informatica FINAL

Cargado por

Copyright:

Formatos disponibles

Apuntes para Clases de

Prof. Jorge Antonio Fernández F. - Auditor de Sistemas de Información 1

2 Material editado para el desarrollo de las clases de postgrado de FOTRIEM

Prof. Jorge Antonio Fernández F. - Auditor de Sistemas de Información 3

Coordinación General y Elaboración

En caso de dudas, comunicarse con el Centro de Atención al Cliente de Emprendimientos

4 Material editado para el desarrollo de las clases de postgrado de FOTRIEM

Presentación del Material

Cuando hablamos de “Auditoría Informática”, creo que a Uds le puede pasar lo

Algunos auditores más responsables y versados en la materia, en lugar de utilizar

Sin embargo, el Módulo de Auditoría Informática de nuestro Post Grado en Auditoría

La riqueza de este material es invalorable, pues en sus 10 Capítulos el Profesor Jorge

Los alumnos deben realizar en clase el análisis de 15 “Casos Prácticos” extraídos

Adicionalmente, y a los efectos didácticos se adjunta un CD que contiene el Manual

Como en los demás ejemplares de esta colección, también se encuentran

Si aún no se ha unido a nuestro selecto grupo de profesionales altamente capacitados,

Nora Lucía Ruoti Cosp

Agradecemos a SYS&CON por la información proveída

6 Material editado para el desarrollo de las clases de postgrado de FOTRIEM

1. La Auditoría de Sistemas de Información 25

Prof. Jorge Antonio Fernández F. - Auditor de Sistemas de Información 7

9. Auditoría Informática de Sistemas 37

8 Material editado para el desarrollo de las clases de postgrado de FOTRIEM

1. Definición y alcance de la auditoría forense 51

1. COBIT, Misión y Visión 54

Prof. Jorge Antonio Fernández F. - Auditor de Sistemas de Información 9

1. Modelo de NC 01 - Evaluación de Estructura de TI 76

10 Material editado para el desarrollo de las clases de postgrado de FOTRIEM

2.6. Inexistencia de una estructura de desarrolladores internos de

Prof. Jorge Antonio Fernández F. - Auditor de Sistemas de Información 11

5. Evaluación del desarrollo y mantenimiento de sistemas - Equipo

12 Material editado para el desarrollo de las clases de postgrado de FOTRIEM

8.1. Sala de servidores independiente y restricción de accesos, controles

Prof. Jorge Antonio Fernández F. - Auditor de Sistemas de Información 13

10.4. Solicitud de recepción técnica provisoria 116

1. Caso: Omega Engineering INC: 119

14 Material editado para el desarrollo de las clases de postgrado de FOTRIEM

2.17. El Caso del Correo de Votantes 129

1. Pasos a seguir para recomendación de soluciones 136

1. Glosario de Términos Técnicos 159

Prof. Jorge Antonio Fernández F. - Auditor de Sistemas de Información 15

1. Disposiciones reglamentarias sobre la Registración Contable por

16 Material editado para el desarrollo de las clases de postgrado de FOTRIEM

• Independientemente del enfoque del control interno (de confiabilidad o sustan-

• Proveer los conceptos, conocimientos y las herramientas, necesarios para un

Prof. Jorge Antonio Fernández F. - Auditor de Sistemas de Información 17

• Aplicar el conocimiento como una herramienta para la especialización en el

El desarrollo del curso estará sujeto a los siguientes lineamientos metodológicos

18 Material editado para el desarrollo de las clases de postgrado de FOTRIEM

3.1 Definición y alcance de la auditoría forense

Prof. Jorge Antonio Fernández F. - Auditor de Sistemas de Información 19

Cuestionario 01 - Evaluación de la estructura

No. Actividad Puntos

20 Material editado para el desarrollo de las clases de postgrado de FOTRIEM

El trabajo contendrá los siguientes indicadores:

Actividades del Curso

La asistencia y participación en clase es obligatoria, los alumnos deberán cumplir

Prof. Jorge Antonio Fernández F. - Auditor de Sistemas de Información 21

C- Resolución de Ejercicios en Equipos

Se resolverán en clase ejercicios de manera a disponer de prácticas en lo concerniente

Cronograma tentativo de Clases

En lo posible trataremos de ceñirnos al siguiente cronograma de clases.

Clase Contenido Actividades

22 Material editado para el desarrollo de las clases de postgrado de FOTRIEM